엔지니어링 매니저는 몇 명의 직속 보고자를 가져야 할까요?

Source: Dev.to

연구에 따르면 5~9명이라고 합니다. 현실은 더 복잡합니다.

모든 엔지니어링 매니저는 결국 이 질문을 합니다: 실제로 몇 명을 관리해야 할까요?

답은 생각보다 중요합니다. 보고 대상이 너무 적으면 당신은 영예로운 테크 리드에 불과합니다. 너무 많으면 회의만 하는 기계가 되어 누구에게도 의미 있는 관심을 줄 수 없습니다.

연구 결과

가장 많이 인용되는 수치는 수십 년에 걸친 관리 연구에서 나온 것으로, 7 ± 2명의 직속 보고가 최적점이다.

• 5명 미만 – 관리자로서 충분히 활용되지 않을 가능성이 높다. 기업은 당신에게 개별 기여자(IC) 업무를 추가하거나(플레이어‑코치가 되게 되며, 이것도 자체적인 문제를 갖는다) 해당 역할 자체가 필요한지 의문을 제기한다.
• 5‑7명 – 딱 맞는 구간. 전담 관리 역할을 정당화할 만큼 충분한 인원이며, 동시에 의미 있는 주간 1:1을 진행하고, 실질적인 피드백을 제공하며, 각 사람이 무엇을 하고 있는지 실제로 알 수 있을 정도로 적은 인원이다.
• 8‑9명 – 팀이 고위직이고 자율적이라면 관리 가능하다. 시간을 어디에 쓸지에 대해 엄격히 관리해야 한다.
• 10명 이상 – 생존 모드에 진입한다. 1:1이 격주 혹은 피상적으로 변한다. 신호를 놓치게 된다 — 번아웃, 몰입도 저하, 악화되는 장애물 등.

아무도 이야기하지 않는 변수들

그 7 ± 2 숫자는 많은 가정을 포함합니다. 실제로 당신의 역량은 다음에 따라 달라집니다:

팀 시니어리티

자기 주도적이고 경험이 풍부한 시니어 엔지니어 팀은 멘토링, 코드 리뷰 가이드, 커리어 코칭이 필요한 다수의 주니어 개발자 팀보다 관리 오버헤드가 적습니다.

당신이 수행하는 IC(Individual Contributor) 작업량

아직도 코드를 40 % 정도 작성하고 있다면(스타트업에서 흔함), 실제 관리 역량은 절반에 불과합니다. 7명을 관리하는 플레이어‑코치는 실제로 3명 정도의 주의력으로 7명을 관리하는 셈입니다.

조직 복잡성

팀 간 의존성, 이해관계자 관리, 채용 등은 모두 사람 관리 대역폭을 소모합니다. 주당 30 %를 교차 기능 회의에 사용한다면, 실제 관리 범위가 축소됩니다.

팀에 EM(엔지니어링 매니저)과 테크리드가 분리되어 있는지 여부

일부 조직은 사람 관리(EM)와 기술 리더십(테크리드 또는 스태프 엔지니어)을 분리합니다. 아키텍처 결정과 기술 멘토링을 담당하는 강력한 테크리드가 있다면 더 많은 인원을 관리할 수 있습니다.

실제 규모에서 일어나는 일

• 스타트업 (< 50 엔지니어) – 매니저는 보통 4‑6명의 직속 부하를 두지만 동시에 플레이어‑코치 역할을 합니다. 실제 적정 범위는 3‑4명 정도입니다.
• 성장 단계 (50‑200 엔지니어) – 바로 여기서 범위 문제가 가장 크게 나타납니다. 빠른 채용으로 매니저가 갑자기 5명에서 10명 이상으로 늘어납니다. 이것이 제가 본 매니저 번아웃의 1위 원인입니다.
• 엔터프라이즈 (200+ 엔지니어) – 보통 5‑8명 비율을 유지하는 데 더 나은 편이지만, 조직 복잡성이 숨은 오버헤드를 추가합니다.

실제 질문: 각 사람에게 그들이 필요로 하는 것을 제공할 수 있나요?

• 매주 각 보고자와 의미 있는 1:1을 가질 수 있나요? 상태 업데이트가 아니라 그들의 업무, 성장, 그리고 장애물에 대한 진정한 대화입니다.
• 누군가 번아웃되는 것을 알아차릴 수 있을까요? 팀으로부터 충분한 신호가 없어 조기에 포착하지 못한다면, 보고자가 너무 많다는 뜻입니다.
• 각 사람에 대해 사려 깊은 성과 평가를 작성할 수 있나요? 일반적인 피드백을 복사‑붙여넣기 하고 있다면, 너무 얇게 퍼진 것입니다.
• 각 사람이 다음에 커리어에서 무엇을 하고 싶어 하는지 알고 있나요? 직함에 대한 포부가 아니라 실제 성장 영역과 관심사입니다.

이 중 하나라도 “아니오”라고 답했다면, 보고자가 너무 많거나 정보를 유지하기 위한 더 나은 시스템이 필요합니다.

확장 가능한 시스템 구축

제가 본 대규모 팀을 잘 관리하는 매니저들은 한 가지 공통점이 있습니다: 그들은 기억과 영웅주의에 의존하는 대신 시스템을 구축합니다.

도움이 되는 몇 가지 예시:

• 비동기 스탠드업을 일일 회의 대신 사용합니다. 캘린더 시간을 소모하지 않고 신호를 얻을 수 있습니다. Vereda와 같은 도구는 Slack에서 이를 실행하고 AI를 사용해 패턴을 드러냅니다 — 반복되는 차단 요소, 막힌 듯 보이는 사람들, 업무량 불균형 등.
• 구조화된 1:1 문서는 주마다 컨텍스트를 이어갑니다. 매 1:1을 “무슨 일 있어?”로 시작한다면 첫 10분을 컨텍스트 재구축에 낭비하게 됩니다.
• 경량 팀 건강 지표. 감시가 아니라, 어디에 집중해야 할지 알 수 있을 정도의 신호만 제공합니다. 스탠드업이 짧아지고 있나요(탈퇴 가능성)? 한 사람이 항상 같은 의존성에 막혀 있나요?

결론

5‑7은 대부분의 엔지니어링 매니저에게 최적의 범위입니다. 9 이상이면 아마도 하지 말아야 할 트레이드오프를 하게 됩니다. 4 이하라면 전담 관리 역할을 정당화할 만큼 충분한 가치를 제공하고 있는지 확인하세요.

하지만 숫자보다 각 사람에게 주는 관심의 질이 더 중요합니다. 8명의 직속 보고자를 두고 좋은 시스템을 갖춘 훌륭한 매니저는 5명을 담당하는 평범한 매니저보다 더 뛰어날 것입니다.

저는 Vereda를 만들고 있습니다 — 엔지니어링 팀을 위한 AI 분석이 포함된 무료 Slack 스탠드업 봇입니다. 팀이 성장함에 따라 회의를 추가하지 않고도 매니저가 정보를 파악하도록 돕습니다. 성장하는 팀을 관리하고 있다면, 확인해 보세요.