스태프 엔지니어 vs 엔지니어링 매니저

• 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? 참고

Staff Engineer가 유용한 상황

• 다음과 같은 경우에 Staff Engineer는 조직에 실질적 가치를 제공할 수 있음:
  • EM이 감당하기 어려운 기술 부담이 존재할 때
    • 예: 레거시 기술이 많고 지속적인 유지보수가 필요한 경우
    • 팀 간을 넘나드는 복잡한 솔루션이 존재하거나 깊은 기술 지식이 필요한 경우
    • (비추 패턴이지만) EM 자체가 기술적이지 않은 경우도 존재함
  • 기술 업무 중 일부에 대해 명확한 책임(accountability) 을 줄 수 있을 때
  • 기술의 범위가 하나의 EM이 관리할 수 있는 한계를 넘어설 때
• Staff Engineer는 사람이 아닌 기술에 대한 책임을 져야 함
  • 팀 멤버 관리나 성과 리뷰 등의 역할은 포함되지 않음
• 상황은 조직, 제품, 사람에 따라 다르기 때문에 모든 상황에 보편적 적용은 불가능함
• 참고: 책임(responsibility)과 책임감(accountability)은 미묘하게 다른 개념이며,
  • 이에 대한 구체적 차이는 Accountable vs Responsible 참고
• Staff Engineer는 다음과 같은 특징을 가져야 함:
  • 기술에 깊이 있는 이해와 높은 기술 문해력을 갖추고
  • 명확한 기술 책임(accountability) 을 가짐
  • 사람 관리 책임이 없기 때문에 기술 투자 시간이 더 많음
• 반면, EM도 기술 책임에서 완전히 손을 떼서는 안 됨
  • 여전히 기술에 일정 부분 관여하고 이해할 필요가 있음
• Staff Engineer의 진정한 가치는 여러 팀에 걸친 기술 리더십에서 나옴
• 한 팀 안에 Staff Engineer를 두면 다음과 같은 문제가 생길 수 있음:
  • 기술 책임이 중복됨
  • 역할 혼선이 생기고, 결국 하나의 역할을 여러 타이틀로 쪼개는 비효율 발생
    • 이에 대한 자세한 내용은 Breaking a role to multiple titles 참고

예외적으로 팀 단위로 활동할 수 있는 경우

• 일반적으로 Staff Engineer는 팀 간 기술 리더십에 집중하지만, 다음과 같은 상황에서는 팀 단위 활동도 일시적으로 가능함:
  • 신규 EM이 레거시 기술 스택을 빠르게 파악해야 할 때
  • 신규 Staff Engineer가 작은 범위부터 온보딩할 때
  • 기술 부채가 너무 많아 시스템 건강 지표가 악화된 경우
  • 기술 복잡도로 인해 유지 보수가 어려운 경우
• 이 경우 팀 단위 Staff Engineer는 임시적인 구성이어야 함

• Staff Engineer의 진정한 가치

  • 팀 간 연결자 역할(glue) 수행
  • 다른 엔지니어들과 현장에서 함께 일하며, 그들의 목소리를 경영진에게 전달
    • 보통 엔지니어는 급여, 휴가, 평가권한을 가진 사람보다는 동료 엔지니어와 더 솔직하게 대화함
  • 기술적으로 깊이 있는 리더십 수행
    • EM과 달리 회의, 1:1, 관리 업무가 적기 때문에 엔지니어링 역량과 기술적 깊이를 발전시키는 데 집중 가능

• 가장 큰 위험 요소: Ivory Tower Architect

  • 현실의 문제나 코드에서 멀어진 추상적 이론가가 되는 것
  • 이 문제는 Ivory Tower Architect에서 자세히 다룸

여러 팀에 걸친 시스템을 위한 Staff Engineer의 역할

• Staff Engineer는 한 팀이 아닌 전체 시스템을 아우르는 기술 리더십에 가장 적합함
• Will Larson의 에세이에서는 Staff Engineer의 4가지 유형(archetypes) 을 제시함:
  • Tech Lead: 팀 내 기술 리더
  • Architect: 시스템 아키텍처 설계자
  • Solver: 복잡한 기술 문제 해결자
  • Right Hand: 기술 조직의 리더를 보좌하는 오른팔
• 다이어그램에 나오는 팀 내 Tech Lead를 Staff Engineer라고 부르기엔 무리가 있음
  • 진짜 Staff Engineer의 가치는 팀 간 조정과 기술 통합에서 나옴
  • Introduction to Staff Engineering 참고
    • 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에서 확인 가능

    • 진단 (Diagnosis)

      • 문제 공간을 조사한 후, 해결해야 할 핵심 이슈와 그 이유를 규명함
      • 전략이 왜 필요한지를 설명함
      • 증상과 근본 원인을 식별하고, 그것들이 지금 중요한 이유를 분석함
      • 나쁜 전략에서는 종종 이 부분이 생략되거나 현 상태만 기술됨
      • 좋은 진단은 객관적인 조사와 탐정 같은 자세가 필요함

    • 방향성 정책 (Guiding Policy)

      • 확인된 문제를 해결하기 위한 고수준 접근 방식임
      • 해결책에 초점을 맞추고 조직 전체를 정렬시킴
      • 전술적 세부사항마다 다시 고민할 필요 없이 방향성을 제공함
      • 나쁜 전략은 이 정책(HOW)과 진단(WHY)의 연결이 부재함

    • 일관된 실행 (Coherent Actions)

      • 정책에 따라 진단 문제를 해결하기 위한 구체적인 실행 계획임
      • 누가(WWHO), 무엇을(WHAT), 언제(WHEN) 할지를 명확히 함
      • 핵심은 “일관성”으로, 다양한 팀이 조화를 이루며 같은 방향으로 나아감

기술 범위를 한 팀으로 줄이는 다른 방법: Kebab vs Cake 모델

• 기술이 여러 팀에 걸쳐 있지 않고 한 팀 내에서 해결되도록 조직 구조를 설계할 수도 있음
• 그 대표적인 방식이 바로 Kebab vs Cake 모델
  • 소비자 여정을 기준으로 팀을 구성해, 기술 책임 범위를 좁히는 구조적 접근
  • 이 모델에 대한 자세한 설명은 Kebab vs Cake organization 참고

  • 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)은 지양할 것 → 관련 글 보기