스태프 엔지니어(Staff Engineer)란 무엇인가?
- 시니어 엔지니어는 "최종 직급"이 아니며, 관련 역량이나 스킬을 더 이상 개발하지 않아도 되는 직급이 아니다.
- 시니어 단계에 이르더라도 꾸준히 자기 계발을 지속하면 "기술 전문 리더십" 수준에 도달할 수 있다.
- "기술 전문 리더십" 단계에 도달한 사람을 주로 "스태프 엔지니어"라고 부른다.
- 매니저의 역할이 관리 중심의 리더십 역량이 중요하다면, "스태프 엔지니어"는 기술 중심의 리더십 역량이 중요하다.
스태프 엔지니어 | 매니저 | 시니어 엔지니어 | |
요약 | 기술 전문 리더십 | 매니저 | 도메인 전문 리더십 |
핵심 관리 항목 | 기술 관리 *넓은 커버리지의 S/W 구조 설계 *특정 분야의 전문가 수준의 지식 |
사람, 프로젝트 관리 *관리 능력(프로젝트, 위기, 사람 ...) |
도메인 설계, 코드 관리 *비즈니스 설계, 구현의 최고 실력 |
빅 픽처 관점 | 기술 관점 빅 픽처 사고 | 전사 자원/효율, 비즈니스 관점 빅 픽처 사고 |
도메인 연관 범위 관점 빅 픽처 사고 |
목표 의식 | 견고한 시스템 구성 기술 환경이 적합하도록 유지 기술 이해 / 전파 / 교육 |
주어진 리소스를 적절히 활용해서 프로젝트를 제시간에 합의된 퀄리티로 완료 |
도메인 비즈니스 설계 설계, 코드 품질 유지 / 향상 일정 준수 비즈니스 이해 / 공유 |
지식/교육 역할 | 전문 영역의 기술 전파 | 프로젝트 관리 기법 조직 관리 기법 |
비즈니스 설계 / 개선 Best Practice 설계 / 구현 / 테스팅 기법 |
프로젝트 내 역할 | 대규모 프로젝트의 전체 또는 부분 아키텍처 구성 |
대규모 프로젝트의 관리(PM) | 도메인 개발(설계 주도 및 개발) 연관 도메인과 영향범위 판단 |
중점 관리 영역 | 적정 기술 수준 유지 (오버 엔지니어링 X) |
관리 체계 유지 / 개선 조직 성과, 만족도 관리 |
설계, 테스트, 개발(구현, 리펙토링) |
자기계발 | 프레임웍, 아키텍처, 오픈소스, 신기술 ... |
프로젝트 관리 - 일정, 리스트, 이슈,...보고 자원 관리 - 예산, 사람, 시간 구성원 관리 - 자기계발, 목표, 성과 |
데이터베이스, 코딩, 테스팅, 튜닝, 비즈니스 이해, 분석, 설계 |
부하 직원 | 없음 (또는 소수) | 팀 또는 조직 | 팀 또는 파트 |
주의사항 | 영향력 부족(전문성 부족, 너무 좁은 기술 범위) 기회비용 낭비(전문성을 회사 최대의 효율로...) 다른 엔지니어의 성장 방해 (시니어, 주니어 엔지니어의 성장 기회 박탈) 오버 엔지니어링(과도한 기술 도입) |
질문된 의사 결정 조직, 프로젝트 방치/방관 너무 과도한 매니징(위임, 책임 관리) 이것도 저것도 아닌 리더십 (기술형, 사람관리형, 기술+관리형) |
기술력 향상의 정체 설계 및 구현 수준의 타협 도메인 품질 방관/방치 잘못된 권한 사항 (일 떠넘기기, 적당히 넘어가기) |
깊게 팔 것인가? 넓게 팔 것인가?
개인이 선호하는 스타일이나, 조직의 요구사항에 따라 결정
조직과 사업의 기술 방향에 영향을 미치고 싶다면 폭넓게 파는 것이 적합
특정 기술 도메인(검색, AI, Cloud ...)의 전문가가 되고자 한다면 범위를 좁게 잡고 해당 분야의 전문가 수준까지 파야 함
스태프 엔지니어 유형
기술 책임자 -매니저와 협업해서 하나 이상의 팀을 이끈다. -관리적인 영역이 아닌 기술적인 리딩 -여러 도메인에 걸치기도 함 -인력 관리 책임을 포함하는 Tech Leader Manager 역할도 있음 통상 엔지니어 8명 당 1명의 기술 책임자 |
아키텍트 -핵심 분야의 기술 방향성과 퀄리티에 대한 책임 -기술 제약, 사용자 요구, 조직 수준 기술 리더십에 대한 심층적인 지식을 결함 - API 디자인, 프런트앤드 스택, 스토리지 전략, 클라우드 인프라 ... - 비즈니스 요구사항, 목표에 대한 깊은 이해를 바탕으로 아키텍처를 세움 - 일부 회사는 아키텍트가 코드베이스에 참여하기도 함 |
문제 해결사 -한 번에 하나의 문제를 해체 나간다. -필요에 따라 오랜 기간 하나의 영역에 집중 -핫스팟에서 핫스팟으로 이동 -기술부채가 쌓인 조직 -스프린트 중심(기능 구현)으로 오랜 기간 운영한 조직 |
오른팔 - 수백명 또는 그 이상의 엔지니어를 보유한 조직에 필요 -복잡한 조직을 운영하기 위해 범위와 권한을 빌려 레거시 개선 또는 확장 -리더의 회의에 참석하여 중요한 문제를 제거 -불 속으로 뛰어들어 접근 방식을 수정하고 적절한 팀에 실행을 위임한 다음 조직의 다른 곳에서 다음 불을 뿜음 -비즈니스, 기술, 사람, 문화 및 프로세스의 교차점이 이들이 해결해야 할 과제들 |
스태프 엔지니어 요약
- 정확한 역할은 정의되어 있지 않으며, 기업이나 조직의 환경에 따라 다양한 역할 범위가 결정된다.(또는 스스로 결정한다.)
- 매니저는 아니지만, 리더 역할을 한다.
- 탄탄한 기술력, 판단력 그리고, 경험치가 필요하다.
- 영향력의 범위와 분야를 명확하게 해야 한다.(스태프 엔지니어라고 모든 기술을 다 잘하는 것은 아니다.)
- 시간은 한정되어 있다. 중요한 일, 관심분야, 시간을 낭비하지 않는 주요 초점을 잘 선택하자.
- 경영진과 함께해라. 스태프 엔지니어의 역할이 무엇이고, 매니저의 생각은 어떤지, 무엇이 가치 있고 유익한지에 대해 함께 이해하라.
- 명백한 기대치를 모두에게 증명해라. 모든 기업에 모든 형태의 스태프 엔지니어가 필요한 것은 아니다.
- 가끔 이상한 일을 맡을 때도 있겠지만, 그 어떤 일이라도 기업(조직)에 필요한 일이라면 해결해 내야 한다.
네 가지 위험 요소들
우선순위 잘못 지정
모든 사람이 같은 것에만 신경을 쓰면 그 문제의 중요성이 필요 이상으로 부풀려지기 쉽다.
기존의 기술과 해결책만 참조해도 바퀴를 다시 발명하는데 시간을 낭비하지 않을 것이다.
공감대 상실
본인이나 본인의 기술에 집중한 나머지 다른 세상이 존재한다는 것을 망각하거나, 다른 사람이나 다른 기술을 사소하게 여길 수 있다.
다른 사람이 수행하는 업무나 적용 기술을 업신여겨서 여러 직원의 공감대를 잃을 수 있다.
주변 소음 조절 실패
기존 문제점이나 냄새에 익숙해진 나머지 이를 망각하거나, 문제의 핵심을 해결하지 않고, 차선책 마련에만 집중할 수 있다. 문제가 오래되면 익숙해지고, 이를 방치하면 문제를 넘어 위기나 재앙으로 커질 때까지 이를 인지하지 못할 수 있다.
업무 목적 망각
사일로 조직에서는 조직의 목표가 바뀌거나 다른 방법으로 해결되어도 프로젝트(작업)은 계속 진행될 수 있다. 그러나 프로젝트의 사소한 부분에 집중하다보면 목표가 없어진 일을 계속하게 될 수 있다. 계속해서 본인이 하고 있는 업무에 대한 윤리적인 시각을 뜨고 있어야 하며, 넓은 관점에서 전체를 바라봐서 해서는 안되거나, 할 필요가 없는 일을 하고 있지는 않은지 생각해야 한다.
SWE : Software Engineer SDE : Software Development Engineer
SWE = SDE
- 개발 프로세스 최적화 스킬
- 최신의 표준 기술 접근(분석, 검토, 기술 습득, 도입, 고도화)
- 용량 관리(H/W Spec, H/W 성능, 조직 처리 능력)
- 프로그래밍 / 시스템 디자인 / 시스템 통합
https://leaddev.com/career-ladders/who-are-staff-principal-and-distinguished-engineers
https://pulmuone.atlassian.net/wiki/spaces/dev/pages/2530377773
'프로그래밍' 카테고리의 다른 글
성능 최적화 기법(성능 최적화 패턴) (1) | 2023.10.04 |
---|---|
빅데이터분석-R 간단 연습 (0) | 2019.06.20 |
Anti cross-site scripting (XSS) filter (0) | 2019.05.21 |