# 스태프 엔지니어 vs 엔지니어링 매니저 > Clean Markdown view of GeekNews topic #20214. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=20214](https://news.hada.io/topic?id=20214) - GeekNews Markdown: [https://news.hada.io/topic/20214.md](https://news.hada.io/topic/20214.md) - Type: news - Author: [xguru](https://news.hada.io/@xguru) - Published: 2025-04-08T11:13:01+09:00 - Updated: 2025-04-08T11:13:01+09:00 - Original source: [blog.alexewerlof.com](https://blog.alexewerlof.com/p/staff-engineer-vs-engineering-manager) - Points: 31 - Comments: 4 ## Summary **Staff Engineer** 와 **Engineering Manager(EM)** 는 각각 **기술과 사람 관리**에 중점을 두며, 역할의 책임과 범위를 명확히 이해하는 것이 중요합니다. EM은 팀과 기술 산출물에 대한 책임을 지지만, 팀 규모가 크거나 기술이 복잡할 경우 Staff Engineer를 통해 기술 업무를 위임할 수 있습니다. Staff Engineer는 기술에 대한 깊이 있는 이해와 책임을 가지며, 여러 팀에 걸친 기술 리더십을 통해 조직의 기술 전략과 방향성을 이끌어 제품과 조직에 기여합니다. 현실과 동떨어진 Ivory Tower Architect가 되지 않도록 주의해야 하며, 조직 상황에 따라 역할과 책임은 유연히 정의해야 합니다. Staff Engineer가 항상 필요한 것은 아니며, EM이 기술적 역량을 충분히 갖춘 경우나 기술이 한 팀 내에서 완결될 때는 필요 없을 수 있습니다. ## Topic Body - Staff Engineer는 언제 필요하며, Engineering Manager와 어떤 차이가 있는가? - 많은 엔지니어와 매니저들이 두 역할에 혼란을 겪고 있음 - 사람 관리를 피하고 기술에 집중하고 싶은 EM, 기술 리더십을 맡고 싶은 Senior Engineer 등이 고민 중 - 각 역할의 책임과 범위를 명확히 이해하는 것이 중요함 ### 내가 받았던 질문들 - **EM**: "사람 관리 대신 기술에 집중하고 싶습니다. Staff Engineer가 저에게 적합할까요?" - **Senior EM**: "관리 업무가 너무 많습니다. Staff Engineer를 고용해 기술 작업을 맡길까요?" - **Staff Engineer**: "실질적으로 팀 매니저 역할을 하고 있는데 마음에 듭니다. EM으로 전환할까요?" - **Senior Engineer**: "Staff Engineer의 책임은 무엇인가요? 마치 은퇴한 개발자처럼 보입니다." - **New Staff Engineer**: "‘점선 보고 체계’란 무엇인가요? 제 라인 매니저가 있는데 다른 매니저에게 신경 써야 하나요?" ### Staff Engineer는 언제 필요할까? - 엔지니어들은 기술을 만들고 유지하지만, 기술은 혼자 존재하는게 아님 - 문제에 대한 솔루션이고, 문제는 **제품**으로 정의됨 - 제품은 최종 사용자 또는 내부 고객에게 서비스를 제공함 - 제품은 사용자의 문제를 해결하는 **수단**임, 예를 들어: - 달리기 거리를 측정하고 다른 사용자와 공유하는 앱 - 호텔 예약 웹사이트 - 다른 팀이 사용하는 인프라 플랫폼 - 근태 보고 시스템 - 이러한 제품을 개발하는 엔지니어들은 일반적으로 **Engineering Manager(EM)** 가 이끄는 팀에 소속되어 있음 - EM은 팀원(엔지니어)과 그들이 만들어내는 **기술 산출물(artifacts)** 에 대해 **책임(accountability)** 을 가짐 - 하지만 다음과 같은 경우, 모든 책임을 온전히 수행하기 어려움: - 팀 규모가 매우 클 때 - 기술이 너무 복잡할 때 - 혹은 위 두 가지가 동시에 존재할 때 - 이 경우 EM의 **시간과 에너지(대역폭)** 가 부족해지며, 사람과 기술 모두에 대한 책임을 완벽하게 수행하기 어려워짐 - EM이 책임을 다하기 어렵다면, **두 가지 위임 전략**을 고려할 수 있음: - **행정 업무 위임**: - HR 프로세스와 도구를 최적화하거나 - 어시스턴트를 고용하여 사람 관리 부담을 줄임 - 한 팀에 전담 어시스턴트를 두는 것이 과하다고 느낄 수 있지만, 여러 팀이 하나의 어시스턴트를 공유하는 사례도 있음 - AI 도구를 활용하여 일정 조율, 관리 질문 응답, 피드백 수집 같은 기계적인 업무를 일부 대체 가능 - 우수한 HR 시스템은 관리 부담을 획기적으로 줄여줌 - **기술 업무 위임**: - **Staff Engineer**를 채용하여 기술적인 부담을 나눌 수 있음 - 그러나, **어시스턴트나 AI**는 EM의 핵심 책임인 다음과 같은 **사람 중심 업무**를 대신할 수 없음: - 좋은 팀을 만드는 일 - 멘토링 - 성과 리뷰 - 채용 등 - 한편, **기술 업무 전부를 Staff Engineer에게 넘기는 것**은 **안티 패턴**으로 간주됨 - Staff Engineer는 **EM의 기술 번역기** 역할을 해서는 안 됨 - EM은 기술적 책임에서도 일정 수준 이상을 유지해야 함 - 따라서 **Engineering Manager는 기술적 감각을 유지하는 것이 필수적**이며, - 기술 역량을 유지하기 위한 방법에 대해서는 [How can engineer leaders stay technical?](https://blog.alexewerlof.com/p/how-can-engineer-leaders-stay-technical) 참고 ### Staff Engineer가 유용한 상황 - 다음과 같은 경우에 Staff Engineer는 조직에 **실질적 가치**를 제공할 수 있음: - **EM이 감당하기 어려운 기술 부담**이 존재할 때 - 예: 레거시 기술이 많고 지속적인 유지보수가 필요한 경우 - 팀 간을 넘나드는 복잡한 솔루션이 존재하거나 깊은 기술 지식이 필요한 경우 - (비추 패턴이지만) EM 자체가 기술적이지 않은 경우도 존재함 - 기술 업무 중 일부에 대해 **명확한 책임(accountability)** 을 줄 수 있을 때 - 기술의 범위가 **하나의 EM이 관리할 수 있는 한계를 넘어설 때** - Staff Engineer는 **사람이 아닌 기술에 대한 책임을 져야 함** - 팀 멤버 관리나 성과 리뷰 등의 역할은 포함되지 않음 - 상황은 조직, 제품, 사람에 따라 다르기 때문에 **모든 상황에 보편적 적용은 불가능**함 - 참고: 책임(responsibility)과 책임감(accountability)은 미묘하게 다른 개념이며, - 이에 대한 구체적 차이는 [Accountable vs Responsible](https://blog.alexewerlof.com/p/accountable-vs-responsible) 참고 - Staff Engineer는 다음과 같은 특징을 가져야 함: - **기술에 깊이 있는 이해**와 **높은 기술 문해력**을 갖추고 - 명확한 **기술 책임(accountability)** 을 가짐 - 사람 관리 책임이 없기 때문에 **기술 투자 시간**이 더 많음 - 반면, **EM도 기술 책임에서 완전히 손을 떼서는 안 됨** - 여전히 기술에 일정 부분 관여하고 이해할 필요가 있음 - Staff Engineer의 진정한 가치는 **여러 팀에 걸친 기술 리더십**에서 나옴 - 한 팀 안에 Staff Engineer를 두면 다음과 같은 문제가 생길 수 있음: - 기술 책임이 중복됨 - 역할 혼선이 생기고, 결국 하나의 역할을 여러 타이틀로 쪼개는 비효율 발생 - 이에 대한 자세한 내용은 [Breaking a role to multiple titles](https://blog.alexewerlof.com/p/breaking-role-to-titles) 참고 ### 예외적으로 팀 단위로 활동할 수 있는 경우 - 일반적으로 Staff Engineer는 팀 간 기술 리더십에 집중하지만, **다음과 같은 상황에서는 팀 단위 활동도 일시적으로 가능**함: - 신규 EM이 레거시 기술 스택을 빠르게 파악해야 할 때 - 신규 Staff Engineer가 작은 범위부터 온보딩할 때 - 기술 부채가 너무 많아 시스템 건강 지표가 악화된 경우 - 기술 복잡도로 인해 유지 보수가 어려운 경우 - 이 경우 **팀 단위 Staff Engineer는 임시적인 구성**이어야 함 - # Staff Engineer의 진정한 가치 - **팀 간 연결자 역할(glue)** 수행 - 다른 엔지니어들과 **현장에서 함께 일하며**, 그들의 목소리를 경영진에게 전달 - 보통 엔지니어는 급여, 휴가, 평가권한을 가진 사람보다는 **동료 엔지니어와 더 솔직하게 대화**함 - **기술적으로 깊이 있는 리더십** 수행 - EM과 달리 회의, 1:1, 관리 업무가 적기 때문에 **엔지니어링 역량과 기술적 깊이를 발전시키는 데 집중 가능** - # 가장 큰 위험 요소: Ivory Tower Architect - 현실의 문제나 코드에서 멀어진 **추상적 이론가**가 되는 것 - 이 문제는 [Ivory Tower Architect](https://blog.alexewerlof.com/p/ivory-tower-architect)에서 자세히 다룸 ### 여러 팀에 걸친 시스템을 위한 Staff Engineer의 역할 - Staff Engineer는 **한 팀이 아닌 전체 시스템**을 아우르는 기술 리더십에 가장 적합함 - [Will Larson의 에세이](https://staffeng.com/guides/staff-archetypes/)에서는 Staff Engineer의 **4가지 유형(archetypes)** 을 제시함: - **Tech Lead**: 팀 내 기술 리더 - **Architect**: 시스템 아키텍처 설계자 - **Solver**: 복잡한 기술 문제 해결자 - **Right Hand**: 기술 조직의 리더를 보좌하는 오른팔 - 다이어그램에 나오는 팀 내 Tech Lead를 Staff Engineer라고 부르기엔 무리가 있음 - **진짜 Staff Engineer의 가치는 팀 간 조정과 기술 통합에서 나옴** - [Introduction to Staff Engineering](https://blog.alexewerlof.com/p/introduction-to-the-role-of-staff) 참고 - Staff Engineer는 단순한 직책이 아니라 기술 리더십에 기반한 태도임 - 이 역할은 다양한 팀과 제품 전반에 걸쳐 기술적인 조율과 문제 해결을 담당함 - 사람이나 제품에 대한 공식적인 권한 없이도 영향력을 발휘하며, 조직 전체의 기술 전략과 방향성을 이끎 - 엔지니어링 매니저와 달리 관리보다는 깊이 있는 기술 전문성과 조직 간 협업을 통해 가치를 창출함 - 손에 흙을 묻히며 실무에 관여하고, 다른 엔지니어들의 성장을 돕는 멘토 역할도 수행함 - 실제 조직에서는 기술 시스템이 한 팀에 국한되지 않고 **여러 팀에 분산되거나** 팀 간에 긴밀히 연결됨 - 이런 경우에는 시스템 전체를 책임지는 **전담 Staff Engineer**가 필요함 - 각 팀이 어떤 부분을 맡고 있는지와 관계없이 **시스템 전체를 보는 시각과 책임감**이 요구됨 ### Staff Engineer는 기술만이 아닌 사람과 제품도 통과해야 함 - 핵심 포인트: **기술(tech)은 다른 쪽과 말하거나 듣지 않음** - 기술은 그 혼자로 존재할 수 없고, **사람(엔지니어)** 과 **제품(문제)** 을 통해 의미를 가짐 - Staff Engineer가 진짜 가치를 발휘하려면 다음을 반드시 거쳐야 함: - **엔지니어들과 협력** - **제품팀과 협의** - 이 때문에 Staff Engineer는 **도트 라인 보고 구조(dotted reporting lines)** 를 가짐 - 공식적이지 않지만 중요한 **조직 간 협업과 약속의 연결 고리**임 - 일부 관찰력이 있는 사람들은 Staff에서 더 아래 위치로 화살표가 향하는 이유를 묻기도 함 - 이유 1: **좋은 리더십은 권위가 아닌 협업에 기반함** - Staff Engineer는 팀 단위의 EM 또는 PM에게 **기술 개선을 위한 요청**을 협업 방식으로 전달함 - 독단적 지시가 아닌, **엔지니어와 제품 로드맵을 고려한 협력 방식**이어야 함 - 이유 2: Staff Engineer는 **IC(Individual Contributor)** 이므로 공식적인 직속 부하가 없음 - 만약 EM/PM과 **정기적 대화 채널**이 있다면, 단순 보고용이 아니라: - 기술의 현황(status quo) - 제품 문제 해결을 위한 기술 비전(vision) - 이를 위한 조직 기술 전략(strategy) - 이 세 가지에 대해 **양방향 대화**를 나누는 것이 이상적임 - 이렇게 얽혀 있는 보고 구조를 정리하고 팀 간 기술/제품 정렬을 돕기 위해 - **전사 전략 문서(strategy document)** 가 매우 유용함 - 이에 대한 기초는 [Strategy basics](https://blog.alexewerlof.com/p/strategy-basics)에서 확인 가능 - # 진단 (Diagnosis) - 문제 공간을 조사한 후, 해결해야 할 핵심 이슈와 그 이유를 규명함 - 전략이 **왜** 필요한지를 설명함 - 증상과 근본 원인을 식별하고, 그것들이 지금 중요한 이유를 분석함 - 나쁜 전략에서는 종종 이 부분이 생략되거나 현 상태만 기술됨 - 좋은 진단은 **객관적인 조사와 탐정 같은 자세**가 필요함 - # 방향성 정책 (Guiding Policy) - 확인된 문제를 해결하기 위한 **고수준 접근 방식**임 - 해결책에 초점을 맞추고 조직 전체를 정렬시킴 - 전술적 세부사항마다 다시 고민할 필요 없이 방향성을 제공함 - 나쁜 전략은 이 정책(HOW)과 진단(WHY)의 연결이 부재함 - # 일관된 실행 (Coherent Actions) - 정책에 따라 진단 문제를 해결하기 위한 **구체적인 실행 계획**임 - 누가(WWHO), 무엇을(WHAT), 언제(WHEN) 할지를 명확히 함 - 핵심은 “**일관성**”으로, 다양한 팀이 조화를 이루며 같은 방향으로 나아감 ### 기술 범위를 한 팀으로 줄이는 다른 방법: Kebab vs Cake 모델 - 기술이 여러 팀에 걸쳐 있지 않고 **한 팀 내에서 해결되도록 조직 구조를 설계**할 수도 있음 - 그 대표적인 방식이 바로 **Kebab vs Cake 모델** - 소비자 여정을 기준으로 팀을 구성해, **기술 책임 범위를 좁히는 구조적 접근** - 이 모델에 대한 자세한 설명은 [Kebab vs Cake organization](https://blog.alexewerlof.com/p/kebab-vs-cake) 참고 - # Kebab 아키텍처 - 팀은 제공 기능 중심으로 구성됨 - 사용자 여정은 여러 팀의 산출물을 관통함 - **장점**: 자율성과 느슨한 결합 - **단점**: 핸드오버 발생 위험 - # Cake 아키텍처 - 팀은 사용자 여정 중심으로 구성됨 - 추상화 계층을 통해 인지 부하를 관리함 - **장점**: 엔드투엔드 소유권과 핸드오버 감소 - **단점**: 인지 부하 증가 위험 - Staff Engineer는 단순한 기술 역할이 아니라 **시스템 전체에 대한 책임을 지는 소유자(owner)** 로 다음 3가지를 갖춰야 함: - **지식(Knowledge)**: - 기술 스택과 제품 문제에 대한 깊은 이해 - 필요 시 이를 설명하고 직접 구현할 수 있어야 함 - **권한(Mandate)**: - 기술이 어떻게 발전하고 유지될지에 대해 의견을 낼 수 있는 위치 - **책임(Responsibility)**: - 시스템의 건강 상태(장애, 기술 부채, 문서화, 기술 단절 등)에 대한 책임 - Staff Engineer는 **순수 기술 역할이 아니며**, 조직을 기술적으로 이끄는 데 있어 **소프트 스킬이 필수적** - 영향력 있는 커뮤니케이션, 협업 능력, 리더십 등이 요구됨 - 그러나 **소프트 스킬에만 치중할 경우** 다음과 같은 문제가 발생함: - 현실과 동떨어진 이상만 제시하고, 실제 코딩이나 문제 해결에는 참여하지 않는 - **Ivory Tower Architect**로 변질될 위험 ### 마무리 - 모든 조직이 Staff Engineer를 필요로 하는 것은 아님. 다음과 같은 경우에는 없어도 무방함: - **EM이 충분히 기술적 역량을 갖추고** 팀의 기술을 직접 리딩할 수 있을 때 - 기술 스택이 **건강하고 유지 관리가 쉬운 상태**일 때 - 기술이 **한 팀 내에서 완결되며**, 팀 간 의존성이 거의 없을 때 (Cake 조직 모델이 한 예) - 조직이 성숙하여 **특정 소유자가 없어도 전체 시스템을 잘 운영할 수 있을 때** - 반대로 Staff Engineer가 있는 조직이라면 다음을 명확히 해야 함: - **기술 소유권(technical ownership)** 을 분명히 설정하고 - 해당 책임에 대해 Staff Engineer에게 **명확한 accountability**를 부여할 것 - 핵심 정리: - **Ivory Tower Architect는 지양**해야 함 (현실성 없음) - **역할을 여러 타이틀로 쪼개는 것**은 비효율적임 - **비기술적인 EM**도 비효율적임 - 마지막으로, 이 글은 절대적인 법칙이 아닌 **참고용 에세이**임 - 조직, 기술, 제품, 운영, 사람은 모두 다르므로 **상황에 맞는 유연한 판단이 중요** - 맹목적인 모방(cargo culting)은 지양할 것 → [관련 글 보기](https://blog.alexewerlof.com/p/cargo-culting) ## Comments ### Comment 36963 - Author: kuthia - Created: 2025-04-09T19:43:47+09:00 - Points: 1 CTO의 수족들이라는 생각이 드네요 ### Comment 36915 - Author: bus710 - Created: 2025-04-09T01:22:25+09:00 - Points: 1 스태프 엔지니어: 해보다 해보다 안 될 때 괴롭히러 갈 사람. ### Comment 37010 - Author: bobross0 - Created: 2025-04-10T17:19:52+09:00 - Points: 1 - Parent comment: 36915 - Depth: 1 엌ㅋㅋㅋㅋ 공감 ### Comment 36887 - Author: ethanhur - Created: 2025-04-08T12:22:34+09:00 - Points: 2 글 내용과는 크게 관련 없지만, accountability와 responsibility에 대한 고민을 하고 있었던지라 다음 링크가 참 도움이 많이 되었습니다 https://blog.alexewerlof.com/p/accountable-vs-responsible