매니저가 된다는 것의 진실 — 시니어 엔지니어에 회의가 더해지는 일이 아니다

들어가며 — 열네 가지 "진실"의 공통점
출력 함수가 바뀐다 — 그로브의 등식
개인 처리량이라는 지표가 작동을 멈추는 세 가지 이유
피드백 루프가 느려지고, 읽기 어려워진다
첫 6개월에 반복되는 실패 세 가지
숫자를 찾아보면 거의 없습니다
IC로 돌아가야 하는지 판단하는 법
마치며 — 잘하고 있는지 알 수 없는 상태를 기본값으로 받아들이는 일
참고 자료

들어가며 — 열네 가지 "진실"의 공통점

2026년 7월 29일, GeekNews에 "매니저가 된다는 것의 진실"이라는 항목이 올라와 41포인트를 받았습니다. 원문은 Sofia Kodar라는 개인 블로거가 6월 21일에 쓴 The truth about being a manager이고, 그보다 이틀 뒤인 6월 23일에 Hacker News에 올라가 113포인트에 64개 댓글을 모았습니다.

먼저 이 글의 성격을 분명히 해 둘 필요가 있습니다. 이건 연구가 아니라 개인 경험 에세이입니다. 통계도, 인용된 논문도, 표본도 없습니다. 저자가 스스로 밝힌 이력(약 11년의 매니저 경험)이 유일한 근거이고, 그 이력도 외부에서 검증할 방법이 없습니다. 그러니 "진실"이라는 제목은 저자의 진실이라는 뜻으로 읽는 게 맞습니다.

그런데 이런 글이 반복해서 상단에 올라간다는 사실 자체는 정보입니다. 열네 개 항목을 늘어놓고 보면 대부분이 한 가지를 다른 각도에서 말하고 있습니다 — 더 이상 팀의 일부가 아니다, 지나가듯 한 말이 지시로 해석된다, 외롭다, 말할 수 없는 정보를 안고 다닌다, 하루 단위로 진척이 보이지 않는다. 업무량이 늘었다는 이야기가 아닙니다. 일의 종류가 바뀌었다는 이야기입니다.

원문은 그 이유를 설명하지는 않습니다. 이 글은 그 구조를 설명합니다. 매니저가 된다는 것은 시니어 엔지니어 역할에 회의가 얹히는 일이 아니라, 출력 함수 자체가 교체되는 일입니다. 그리고 그 교체의 부작용은 대부분 하나의 원인에서 나옵니다 — 피드백 루프가 느려지고, 읽기 어려워집니다.

출력 함수가 바뀐다 — 그로브의 등식

앤디 그로브가 High Output Management의 관리 레버리지 장에서 제시한 정의는 간단합니다. 매니저의 출력은 자기 조직이 낸 출력에, 자신의 영향권 아래 있는 인접 조직들이 낸 출력을 더한 값입니다.

이 정의에서 실제로 중요한 부분은 등식의 오른쪽이 아니라, 그 앞에 있는 구분입니다. 그로브는 활동(activity)과 출력(output)을 분리합니다. 하루에 회의 여덟 개를 소화하고 결정 열두 개를 내린 것은 활동입니다. 출력은 그 팀이 그 분기에 내놓은 것입니다. 둘은 상관이 있지만 같지 않고, 상관관계의 방향조차 자명하지 않습니다.

IC일 때는 이 구분이 거의 필요 없습니다. 활동과 출력의 거리가 짧기 때문입니다. 코드를 쓰는 활동은 머지된 변경이라는 출력으로 몇 시간에서 며칠 안에 이어지고, 그 사이에 개입하는 다른 사람의 수도 적습니다. 매니저가 되는 순간 이 사이에 사람과 시간이 끼어듭니다. 오늘 한 1on1의 출력은 이번 분기가 아니라 다음 분기에, 그것도 다른 사람의 손을 거쳐 나타납니다.

여기서 첫 번째 실무적 결론이 나옵니다. 매니저 역할에서 잘하고 있는지를 판단하려면, IC 시절에 쓰던 지표를 버리는 게 아니라 그 지표가 왜 오작동하는지를 이해해야 합니다.

개인 처리량이라는 지표가 작동을 멈추는 세 가지 이유

IC 시절의 자기 평가 방식은 대체로 개인 처리량입니다. 이번 주에 무엇을 머지했는가, 인시던트를 몇 개 껐는가, 설계 문서를 몇 개 썼는가. 이 지표가 매니저에게는 세 가지 이유로 고장 납니다.

첫째, 직접 경쟁 관계입니다. 개인 처리량을 유지하려면 팀의 출력을 만드는 데 쓸 시간을 깎아야 합니다. 1on1을 미루고, 채용 인터뷰를 넘기고, 인접 팀과의 조율을 뒤로 밀면 이번 주 개인 처리량은 유지됩니다. 그로브의 등식에서 왼쪽을 지키기 위해 오른쪽을 깎는 셈입니다.

둘째, 팀의 학습 총량이 줄어듭니다. 매니저가 직접 처리하는 일은 대개 가장 어렵고, 가장 재미있고, 학습 가치가 높은 일입니다. 마감이 다가올 때 매니저가 그 일을 가져가면 단기적으로는 영웅이 되지만, 그 일에서 배웠어야 할 사람은 배우지 못합니다. Camille Fournier가 신임 매니저의 흔한 실패로 기술적 결정을 위임하지 않고 쥐고 있는 패턴을 지적한 것도 같은 맥락입니다(다만 저는 이 글의 본문을 직접 확인하지 못했고 제목과 요지만 확인했습니다).

셋째, 병목이 됩니다. 개인 처리량이 높은 매니저는 자기 승인, 자기 리뷰, 자기 지식에 의존하는 경로를 만들어 냅니다. 그 경로는 매니저가 휴가를 가는 순간 드러납니다.

관리 범위 숫자를 여기에 겹쳐 보면 그림이 더 분명해집니다. Will Larson은 Sizing engineering teams(2018년 7월 14일)에서 매니저가 능동적으로 코칭하고 조율할 수 있는 상한을 6명에서 8명으로 봅니다. 그 위, 대략 8명에서 9명을 넘어가면 매니저의 역할은 코치가 아니라 "문제가 생겼을 때의 안전망"으로 축소된다고 적습니다. 반대로 4명 미만은 팀이라기보다 개인들의 집합에 가깝다고 봅니다. 이 숫자들이 말해 주는 건 조직도 모양이 아니라 시간 예산입니다. 6명에서 8명이라는 범위는 능동적 코칭에 필요한 시간을 근무 시간으로 나눈 결과에 가깝고, 개인 처리량은 바로 그 예산에서 나옵니다.

피드백 루프가 느려지고, 읽기 어려워진다

부작용들의 공통 원인은 여기 있습니다. 표로 정리하면 이렇습니다.

축	IC	매니저
출력 단위	머지된 변경, 복구된 장애	팀이 분기에 내놓은 결과
피드백 지연	분에서 일 단위(CI, 리뷰, 배포)	주에서 분기 단위(채용 결과는 반년, 조직 변경 효과는 1년)
판독 가능성	높음. 테스트가 빨간색이면 틀린 것	낮음. 팀이 잘 굴러가는 게 내 덕인지, 원래 좋은 사람들이 모여서인지 구분 불가
실패 신호	즉시, 자동으로 도착	지연되고, 대개 사람을 통해서만 도착
교정 비용	낮음. 되돌리면 됨	높음. 신뢰는 롤백되지 않음

이 표에서 가장 중요한 줄은 판독 가능성입니다. 지연만 문제라면 참으면 됩니다. 진짜 문제는 신호 대 잡음비입니다. 팀의 성과에는 매니저의 기여 외에 채용 시장, 제품 방향, 인접 팀의 상태, 그리고 그냥 운이 모두 섞여 들어갑니다. 그래서 좋은 분기가 자기 실력의 증거라는 보장이 없고, 나쁜 분기가 자기 잘못의 증거라는 보장도 없습니다.

학습은 피드백 루프의 함수입니다. 루프가 분기 단위이고 잡음이 크면, 사실상 지도 학습이 되지 않습니다. 여기서 두 번째 실무적 결론이 나옵니다. 매니저의 성장은 자연 발생하지 않습니다. 계측을 직접 만들어야 합니다. 구체적으로는 세 가지가 도움이 됩니다.

결정 로그. 어떤 결정을 언제, 어떤 근거로, 어떤 결과를 예상하고 내렸는지 한 줄로 남깁니다. 분기 말에 예측과 결과를 대조하면, 잡음 속에서 자기 판단의 편향만 따로 볼 수 있습니다.
선행 지표. 분기 결과는 늦게 오지만, 1on1에서 나쁜 소식이 얼마나 빨리 올라오는지, 온콜 인계가 얼마나 조용한지, 설계 리뷰에서 반대 의견이 나오는지 같은 것은 주 단위로 관찰됩니다.
외부 관찰자. 판독 가능성이 낮은 신호를 읽는 가장 싼 방법은, 같은 조직을 다른 각도에서 보는 사람(동료 매니저, 스태프 엔지니어)에게 정기적으로 묻는 것입니다.

첫 6개월에 반복되는 실패 세 가지

원문의 열네 항목, HN 댓글, 그리고 널리 읽히는 관리 문헌에서 반복해서 나타나는 실패 모드는 대략 세 가지로 수렴합니다.

개인 처리량을 놓지 못합니다. 가장 흔합니다. 스프린트 후반에 직접 코드를 짜서 막고, 어려운 인시던트를 직접 처리합니다. 앞 절에서 본 대로 이건 단기 이득과 장기 손실을 맞바꾸는 거래인데, 문제는 이 거래의 손실 쪽이 6개월 뒤에야 보인다는 점입니다. 피드백 루프가 느리다는 사실이 바로 이 실패를 오래 살아남게 합니다.

말의 무게를 오판합니다. 원문에서 가장 정확한 지적이라고 생각하는 부분입니다. IC 시절의 "이거 좀 이상하지 않아요?"는 질문이었지만, 매니저의 같은 문장은 2주짜리 리팩터링으로 돌아옵니다. 지시할 의도가 없었다는 것은 아무 방어가 되지 않습니다. 이건 화자의 의도가 아니라 청자의 위험 계산 문제이기 때문입니다. 실무적인 해법은 의도를 라벨로 붙이는 것입니다 — 이건 생각을 소리 내어 하는 중이고 결정이 아니라는 것, 또는 이건 결정이라는 것을 매번 명시하는 편이 낫습니다.

어려운 대화를 미룹니다. 성과 문제를 첫 분기에 말하지 않으면 다음 분기에는 말하기가 더 어려워집니다. 침묵이 길수록 상대 입장에서는 갑작스러운 통보가 되고, 그때는 내용의 정당성과 무관하게 절차의 문제가 됩니다. Camille Fournier가 I hate manager READMEs(2018년 11월 23일)에서 한 지적이 여기에 그대로 적용됩니다. 신뢰는 자기소개 문서로 만들어지는 것이 아니라, 예측 가능하고 윤리적인 행동이 반복되면서 쌓인다는 것입니다. 어려운 대화를 제때 하는 것은 그 반복의 일부입니다.

HN 댓글에는 원문에 대한 반론도 여럿 있었고, 그중 셋은 실제로 새겨 둘 만합니다. 한 댓글은 매니저가 나쁜 결정을 "팔아야" 한다는 원문의 주장에 정면으로 반대하면서, 투명한 매니저가 결과적으로 더 신뢰를 얻고, 가짜 긍정을 받는 쪽은 그것을 알아본다고 지적합니다. 다른 댓글은 시니어 IC도 회의, 이해관계자 관리, 권한 없는 리더십이라는 거의 같은 부담을 진다는 점에서 원문이 그린 IC와 매니저의 경계가 실제보다 선명하다고 봅니다. 또 다른 댓글은 경험이 쌓이면 실무와 리더십의 균형이 가능해진다며, 원문이 좋은 후보자를 겁줘서 쫓아낼 위험을 지적합니다.

숫자를 찾아보면 거의 없습니다

이 주제에서 가장 자주 인용되는 숫자는 "신임 매니저의 60퍼센트가 24개월 안에 실패한다"입니다. 보통 CEB(현 Gartner) 출처로 붙습니다. 이 글을 쓰면서 원 보고서를 찾아봤는데, 연도도 표본도 방법론도 확인되지 않았습니다. 수십 개의 매체와 블로그가 인용하지만 모두 서로를 인용하고 있고, 원본으로 이어지는 링크가 없습니다. 좀비 통계로 취급하는 게 안전합니다. 근처에서 자주 함께 인용되는 Leadership IQ의 46퍼센트 수치는 실재하는 조사이긴 하지만, 신임 매니저가 아니라 신규 입사자 전반을 대상으로 한 것이라 이 맥락에 그대로 쓸 수 없습니다.

반대로 출처가 분명한 것도 있습니다. DDI의 Global Leadership Forecast 2025는 리더 10,796명과 HR 전문가 2,185명을 50개국 이상에서 조사한 11번째 판인데, 스트레스를 겪는 리더의 40퍼센트가 웰빙을 위해 리더 역할을 떠나는 것을 고려한 적이 있다고 답했습니다. 이건 실패율이 아니라 이탈 의향이지만, 적어도 표본과 방법론이 공개되어 있습니다.

정직하게 적어 두면, 엔지니어가 매니저가 되었다가 IC로 돌아가는 비율에 대한 신뢰할 만한 통계는 찾지 못했습니다. 널리 회자되는 이야기는 많지만 인용 가능한 조사는 없습니다. 이 사실 자체가 이 주제를 읽는 방법을 알려 줍니다 — IC에서 매니저로 가는 전환에 대한 조언은 거의 전부 경험담이고, 경험담으로서 읽어야 합니다. 그중 다수가 서로 모순되는 이유도 그래서입니다.

IC로 돌아가야 하는지 판단하는 법

이 주제의 표준 참조점은 Charity Majors의 The Engineer/Manager Pendulum(2017년 5월 11일)입니다. 핵심은 셋입니다. 매니지먼트는 승진이 아니라 평행한 트랙으로의 수평 이동이라는 것, 가장 좋은 일선 엔지니어링 매니저는 실무에서 2년에서 3년 이상 떨어져 있지 않다는 것, 그리고 엔지니어링과 매니지먼트 중 한 번에 하나만 실력이 는다는 것입니다.

이 글도 연구가 아니라 관점입니다. 인용된 근거는 없고, 본인이 밝힌 출처는 당시 Sarah Mei와의 대화입니다. 흥미로운 건 이 글에 대한 본격적인 반론을 찾지 못했다는 점인데, 이건 합의가 이루어졌다는 뜻이라기보다 이 영역에 반증 가능한 데이터가 없다는 뜻에 가깝습니다.

그 위에서, 제 의견을 덧붙이자면 판단 기준은 이렇게 나뉩니다.

돌아갈 이유가 되지 못하는 것들부터 봅니다. 이번 분기가 힘들다는 것은 이유가 되지 않습니다. 앞에서 본 대로 첫 6개월은 피드백 루프가 느리고 판독이 어려운 상태를 처음 겪는 시기이고, 그 불쾌감은 실패의 신호가 아니라 역할의 기본값입니다. 코딩이 그립다는 것도 그 자체로는 이유가 되지 않습니다. 주말 프로젝트로 해소되는 종류인지 먼저 확인해 볼 만합니다.

돌아갈 이유가 되는 것은 세 가지라고 봅니다.

12개월에서 18개월이 지났는데 팀의 출력이 내가 오기 전과 구분되지 않을 때. 다만 이걸 판단하려면 앞 절의 계측을 미리 해 뒀어야 합니다. 계측 없이 하는 이 판단은 대개 그날의 기분입니다.
매니저 일의 "좋은 날"이 어떤 모양인지 여전히 그려지지 않을 때. 어떤 하루가 잘 보낸 하루였는지 스스로 정의하지 못한다면, 그 역할에서 개선의 방향이 정의되지 않습니다.
조직이 매니저에게 실제 레버를 주지 않을 때. 채용, 보상, 방향에 대한 권한이 없는데 결과에 대한 책임만 있다면 그로브의 등식이 성립하지 않습니다. 이건 개인의 적성 문제가 아니라 자리의 문제이고, 자리를 바꾸는 편이 빠릅니다.

돌아가는 것을 계획한다면 비용도 같이 봐야 합니다. 진자 모델을 따르면 왕복 자체는 자산이지만, 실제로 잃는 것이 하나 있습니다 — 시니어 IC 트랙에서 보냈을 시간입니다. 매니저로 보낸 2년은 스태프 엔지니어 트랙에서의 2년이 아닙니다. 이건 진자 모델이 잘 다루지 않는 부분이고, 결정할 때 계산에 넣는 게 정직합니다.

마치며 — 잘하고 있는지 알 수 없는 상태를 기본값으로 받아들이는 일

정리하면 이렇습니다.

매니저가 된다는 것은 업무량이 늘어나는 일이 아니라 출력 함수가 교체되는 일입니다. 그로브의 정의대로 출력이 팀의 출력으로 바뀌면, 활동과 출력 사이에 사람과 시간이 끼어듭니다.
그 결과로 피드백 루프가 분 단위에서 분기 단위로 늘어나고, 신호 대 잡음비가 나빠집니다. 원문이 나열한 열네 가지 증상 대부분이 여기서 파생됩니다.
개인 처리량은 매니저의 지표로 세 가지 이유에서 고장 납니다. 시간 예산과 직접 경쟁하고, 팀의 학습 총량을 줄이고, 병목을 만듭니다.
이 전환에 대한 조언은 대부분 검증되지 않은 경험담입니다. 널리 도는 실패율 통계는 원 출처를 찾을 수 없습니다.
IC로 돌아갈지는 기분이 아니라 계측으로 판단하는 편이 낫고, 그 계측은 전환 첫날부터 만들어 둬야 쓸 수 있습니다.

루프가 느린 시스템을 운영해 본 사람이라면 이미 아는 감각입니다. 관측 지연이 큰 시스템에서는 즉각적인 확신이 오히려 위험 신호입니다. 매니저 역할도 같습니다. 잘하고 있다는 확신이 매주 드는 상태가 정상이 아니라, 잘하고 있는지 알 수 없는 상태가 기본값이고 그 위에 계측을 얹는 것이 일입니다.