IC에서 엔지니어링 매니저로: 역할 전환의 100일 생존 가이드

• 서론: 가장 어려운 역할 전환
• 1장: IC와 EM - 근본적으로 다른 두 역할
  • 직접 기여 vs 간접 기여
  • 산출물의 변화: 코드에서 사람과 시스템으로
  • 피드백 루프의 차이: 즉각적 vs 장기적
• 2장: 역할 전환을 결정하기 전 - 자기 진단
  • 왜 매니저가 되고 싶은가?
  • IC 트랙 vs EM 트랙 비교
  • Staff+ Engineer vs Engineering Manager 선택 기준
• 3장: 첫 100일 로드맵
  • 1~30일: 경청과 관계 구축
  • 31~60일: 작은 개선과 신뢰 획득
  • 61~100일: 비전과 방향 설정
  • 100일 로드맵 요약
• 4장: 가장 어려운 전환 - 코딩을 내려놓기
  • Maker's Schedule vs Manager's Schedule
  • 기술적 기여와 매니지먼트의 균형
  • 코딩을 놓는 것이 어려운 이유
• 5장: 흔한 실수와 안티패턴
  • 안티패턴 1: "나는 더 잘할 수 있는데" 함정 (마이크로매니징)
  • 안티패턴 2: 모든 기술적 결정에 개입하기
  • 안티패턴 3: 팀원의 성장 기회를 가로채기
  • 안티패턴 4: 갈등 회피
  • 안티패턴 5: 모든 사람을 행복하게 만들려 하기
  • 안티패턴 종합 자가진단표
• 6장: 핵심 스킬 개발
  • 스킬 1: 1:1 미팅 운영
  • 스킬 2: 성과 평가와 피드백
  • 스킬 3: 채용과 면접
  • 스킬 4: 이해관계자 관리
  • 스킬 5: 프로젝트 관리
• 7장: 번아웃 예방과 자기 관리
  • EM의 번아웃이 특별한 이유
  • 자기 관리 체크리스트
• 8장: 다시 IC로 돌아가도 괜찮다 - 역할 전환의 가역성
  • 엔지니어/매니저 진자 운동
  • EM에서 IC로 돌아가는 것이 가치 있는 이유
  • 돌아갈 때의 주의사항
  • 역할 선택 의사결정 프레임워크
• 9장: 체크리스트 - EM 전환 후 100일 자기 점검
  • 첫 30일 점검
  • 31~60일 점검
  • 61~100일 점검
  • 100일 이후 장기 점검
• 10장: 실용적 프레임워크와 템플릿
  • 1:1 미팅 노트 템플릿
  • 주간 팀 상태 보고 템플릿
  • 신규 매니저의 90일 학습 계획
• 결론: 전환은 여정이다
• 참고 자료

서론: 가장 어려운 역할 전환

소프트웨어 엔지니어의 경력에서 가장 극적인 전환점 중 하나는 Individual Contributor(IC)에서 Engineering Manager(EM)로의 역할 전환이다. 이것은 단순한 승진이 아니다. 완전히 다른 직업으로의 전환이다.

Camille Fournier는 저서 The Manager's Path(2017)에서 이렇게 말했다.

"매니지먼트는 기술적 리더십의 자연스러운 다음 단계가 아니다. 그것은 완전히 다른 기술 세트를 요구하는 별도의 경력 트랙이다."

어제까지 Pull Request를 올리고 코드 리뷰를 하던 사람이, 오늘부터 1:1 미팅을 하고 성과 평가를 쓰고 채용 면접을 진행해야 한다. 성과의 기준이 "내가 무엇을 만들었는가"에서 "팀이 무엇을 달성했는가"로 완전히 바뀐다. 피드백 루프는 즉각적(컴파일, 테스트)에서 장기적(분기, 반기)으로 변한다.

이 글은 IC에서 EM으로의 전환을 고려하고 있거나, 이미 전환한 지 얼마 되지 않은 엔지니어를 위한 100일 생존 가이드다. 여러 경험과 참고 문헌을 바탕으로, 역할 전환의 전 과정을 실용적으로 안내한다.

1장: IC와 EM - 근본적으로 다른 두 역할

직접 기여 vs 간접 기여

IC와 EM의 가장 본질적인 차이는 가치 창출의 방식이다.

Julie Zhuo는 The Making of a Manager(2019)에서 매니저의 역할을 이렇게 정의했다.

"매니저의 일은 팀이 더 나은 결과를 달성하도록 돕는 것이다. 그게 전부다."

단순해 보이지만, 이 정의는 깊은 함의를 갖는다. **"돕는 것"**이 핵심이다. 매니저는 직접 결과를 만드는 사람이 아니라, 결과를 만드는 사람들을 돕는 사람이다.

산출물의 변화: 코드에서 사람과 시스템으로

IC의 산출물은 가시적이다. 코드, PR, 시스템 설계 문서, 기술 블로그. 하루가 끝나면 "오늘 무엇을 했는가"에 대한 답이 명확하다.

EM의 산출물은 비가시적이다. 팀원과의 대화, 갈등의 해소, 방향의 설정, 장애물의 제거. 하루가 끝나도 "오늘 무엇을 했는가"에 대한 답이 불분명한 날이 많다.

Will Larson은 An Elegant Puzzle(2019)에서 이 차이를 이렇게 표현했다.

"매니저로서 가장 생산적이었던 날은, 외부에서 보면 아무것도 하지 않은 것처럼 보이는 날이었다."

이 변화에 적응하지 못하면, 새로운 매니저는 끊임없이 **"나는 오늘 무엇을 했지?"**라는 불안감에 시달린다. 코드를 작성하지 않은 하루는 비생산적인 하루처럼 느껴진다. 하지만 팀원의 blocker를 해결하고, 이해관계자와 커뮤니케이션하고, 팀의 다음 분기 방향을 설계한 하루는 실제로는 매우 생산적인 하루다.

피드백 루프의 차이: 즉각적 vs 장기적

IC에게 피드백은 빠르다. 코드를 작성하면 컴파일러가 즉시 오류를 알려주고, 테스트가 통과 여부를 보여주며, CI/CD 파이프라인이 배포 성공을 확인해준다. 이 즉각적 피드백은 도파민을 제공하고, 학습을 가속화한다.

EM에게 피드백은 느리다. 오늘 한 코칭이 팀원의 성장에 영향을 미치는 데 몇 주에서 몇 달이 걸린다. 오늘 설정한 프로세스가 효과를 발휘하는 데 한 분기가 걸린다. 이 지연된 피드백은 불안감과 자기 의심을 야기한다.

Michael Lopp는 Managing Humans(2016)에서 이 피드백 지연이 새 매니저들이 겪는 가장 큰 심리적 도전이라고 지적했다.

2장: 역할 전환을 결정하기 전 - 자기 진단

왜 매니저가 되고 싶은가?

역할 전환을 결정하기 전에, 동기를 정직하게 점검해야 한다. 잘못된 동기로 매니저가 되면, 본인도 팀도 불행해진다.

건강한 동기:

• 사람의 성장을 돕는 것에서 에너지를 얻는다
• 팀 전체의 성과를 끌어올리는 것에 관심이 있다
• 기술적 문제보다 조직적 문제에 더 끌린다
• 의사소통과 조율 업무를 즐긴다
• 더 넓은 범위의 영향력을 갖고 싶다

위험한 동기:

• "매니저가 되어야 승진할 수 있으니까" (조직 구조의 문제)
• "더 높은 연봉을 받고 싶어서" (IC 트랙에서도 가능한 경우가 많다)
• "코딩이 지겨워서" (매니지먼트가 대안은 아니다)
• "권한을 갖고 싶어서" (서번트 리더십과 반대되는 동기)
• "다음 직급이 매니저라서" (경력 경로를 재설계해야 할 수도 있다)

IC 트랙 vs EM 트랙 비교

Staff+ Engineer vs Engineering Manager 선택 기준

이 선택은 "더 높은 직급" vs "더 낮은 직급"의 문제가 아니다. 근본적으로 다른 두 가지 전문성의 선택이다.

Staff+ Engineer가 더 적합한 사람:

• 기술적 문제 해결에서 가장 큰 에너지를 얻는 사람
• 깊은 집중 시간이 없으면 불행한 사람
• 기술적 영향력으로 조직을 변화시키고 싶은 사람
• 코드와 시스템이 자신의 "작품"이라고 느끼는 사람
• 대인 갈등 해결보다 기술적 도전을 선호하는 사람

Engineering Manager가 더 적합한 사람:

• 사람들이 성장하는 것을 보면서 에너지를 얻는 사람
• 미팅과 대화가 에너지를 소모하지 않는 사람
• 조직의 시스템과 프로세스를 설계하는 데 관심이 있는 사람
• 팀의 성과가 자신의 성과라고 느끼는 사람
• 모호한 인간관계 문제에 인내심을 갖고 접근할 수 있는 사람

3장: 첫 100일 로드맵

1~30일: 경청과 관계 구축

첫 한 달의 목표는 관찰하고, 듣고, 이해하는 것이다. 변화를 만들려는 유혹을 참아야 한다.

모든 팀원과 1:1 미팅

첫 2주 안에 모든 직속 보고자(direct report)와 최소 30분 이상의 1:1 미팅을 진행한다. 다음 질문들을 활용한다.

• "이 팀에서 가장 좋은 점은 무엇인가요?"
• "가장 불만스러운 점이나 개선하고 싶은 점이 있다면?"
• "전 매니저에게서 더 받고 싶었던 것이 있나요?"
• "현재 하고 있는 일 중 가장 기대되는 것은?"
• "제가 당신을 어떻게 도울 수 있을까요?"
• "당신의 6개월, 1년 뒤 목표는 무엇인가요?"

기존 프로세스와 문화 관찰

이해관계자 맵 작성

팀이 상호작용하는 모든 이해관계자를 파악한다.

• 상위: 자신의 매니저, 디렉터, VP
• 동료: 다른 팀의 EM, PM, 디자이너
• 하위: 직속 보고자(팀원)
• 외부: 고객, 파트너, 벤더

각 이해관계자와의 관계 상태, 기대사항, 주요 커뮤니케이션 채널을 기록한다.

31~60일: 작은 개선과 신뢰 획득

두 번째 달의 목표는 Quick Win을 통해 신뢰를 구축하는 것이다.

Quick Win 식별과 실행

첫 달의 관찰에서 발견한 작은 문제점 중, 빠르게 해결할 수 있고 팀에 즉각적인 긍정적 영향을 미치는 것을 선택한다.

Quick Win 후보 예시:

• 불필요한 미팅 제거 또는 최적화
• 개발 환경 개선 (빌드 시간 단축, 도구 업그레이드)
• 온콜 프로세스의 작은 개선
• 기술 부채 해결을 위한 시간 확보
• 문서화 관행 개선

팀의 가장 큰 불만 해결

1:1 미팅에서 반복적으로 언급된 불만사항을 정리하고, 가장 많이 언급된 것부터 해결한다. "당신의 목소리를 듣고 있다"는 메시지를 행동으로 보여주는 것이 신뢰 구축의 핵심이다.

피드백 루프 구축

• 정기적 1:1 미팅 스케줄 확립 (주 1회, 30분)
• 팀 회고(Retrospective) 도입 또는 개선
• 익명 피드백 채널 운영 (설문, 제안함)

61~100일: 비전과 방향 설정

세 번째 달부터 마지막 달까지의 목표는 팀의 방향을 설정하고 장기 전략을 수립하는 것이다.

팀 목표 수립

• 회사의 전략적 목표와 팀의 기술적 목표를 연결한다
• 측정 가능한 분기 목표(OKR 또는 유사 프레임워크)를 설정한다
• 팀원들과 함께 목표를 수립하여 주인의식을 높인다

성장 계획 수립

• 각 팀원의 강점, 개선 영역, 경력 목표를 파악한다
• 개인별 성장 계획(Individual Development Plan)을 함께 작성한다
• 성장 기회(도전적 프로젝트, 멘토링, 교육)를 배분한다

프로세스 개선

첫 100일간의 관찰을 바탕으로, 근본적인 프로세스 개선을 시작한다.

• 코드 리뷰 프로세스 최적화
• 배포 파이프라인 개선
• 인시던트 대응 프로세스 정립
• 기술 부채 관리 전략 수립

100일 로드맵 요약

4장: 가장 어려운 전환 - 코딩을 내려놓기

Maker's Schedule vs Manager's Schedule

Paul Graham은 2009년 에세이 "Maker's Schedule, Manager's Schedule"에서 두 가지 근본적으로 다른 시간 활용 방식을 구분했다.

Maker's Schedule (메이커의 일정):

• 최소 4시간 이상의 연속된 집중 시간이 필요
• 중간에 미팅이 끼면 전체 시간 블록이 파괴됨
• 한 번 집중이 끊기면 복구에 30분 이상 소요
• 코딩, 글쓰기, 디자인 등 창작 활동에 적합

Manager's Schedule (매니저의 일정):

• 1시간 단위의 미팅으로 하루가 구성
• 미팅 사이 짧은 전환 시간이 있으면 충분
• 다양한 맥락을 빠르게 전환하는 능력이 요구됨
• 의사결정, 커뮤니케이션, 조율에 적합

IC에서 EM으로 전환하면, Maker's Schedule에서 Manager's Schedule로의 강제 전환이 일어난다. 이것은 단순한 시간 관리의 문제가 아니라, 일하는 방식 자체의 근본적 변화다.

기술적 기여와 매니지먼트의 균형

많은 새 매니저들이 겪는 딜레마는 "얼마나 코딩을 계속해야 하는가"이다.

Charity Majors는 블로그 포스트 "The Engineer/Manager Pendulum"(2017)에서 이렇게 조언한다.

"매니저가 되면 코딩을 해서는 안 된다는 뜻이 아니다. 하지만 크리티컬 패스에 있는 코딩은 해서는 안 된다. 당신이 코딩을 놓아도 팀이 돌아가야 한다."

코딩을 계속해도 되는 경우:

• 기술적 맥락을 유지하기 위한 작은 작업 (버그 수정, 도구 개선)
• 팀에 블로커가 없고, 자신의 매니저 업무가 완료된 상태
• 크리티컬 패스에 있지 않은, 우선순위가 낮은 작업

코딩을 멈춰야 하는 경우:

• 자신이 코딩을 하느라 1:1을 미루거나 취소하는 경우
• 팀원이 해야 할 일을 자신이 대신 하고 있는 경우
• 코드 리뷰가 병목이 되어 팀의 속도를 늦추는 경우
• 코딩이 매니지먼트 업무를 회피하는 수단이 되는 경우

코딩을 놓는 것이 어려운 이유

코딩을 내려놓는 것이 어려운 이유는 심리적이다.

1. 정체성의 위기: "나는 개발자다"라는 정체성이 흔들린다. 코딩하지 않는 자신이 더 이상 엔지니어가 아닌 것 같은 느낌
2. 통제감 상실: 코드는 예측 가능하고 통제할 수 있지만, 사람은 그렇지 않다
3. 즉각적 보상의 부재: 코드를 작성하면 즉시 결과가 보이지만, 매니지먼트의 결과는 느리게 나타난다
4. 역량 불안: 새로운 영역에서의 부족함 대비 코딩에서의 자신감
5. 기술적 기여의 아쉬움: "내가 직접 하면 더 빠르고 잘 할 수 있는데"

이 감정들은 모두 자연스러운 것이며, 시간이 지나면서 새로운 형태의 만족감으로 대체된다. 팀원의 성장, 팀의 성취, 조직의 변화에서 오는 만족감은 코드 한 줄의 만족감과는 질적으로 다르지만, 충분히 깊고 의미 있다.

5장: 흔한 실수와 안티패턴

안티패턴 1: "나는 더 잘할 수 있는데" 함정 (마이크로매니징)

증상: 팀원의 코드를 보면서 "나였으면 이렇게 안 했을 텐데"라는 생각이 든다. Pull Request에 사소한 스타일 지적을 20개씩 남긴다. 팀원이 작성한 설계 문서를 자신이 다시 쓴다.

원인: IC로서의 기술적 자부심과 매니저로서의 통제 욕구가 결합. 코딩에서 얻던 만족감을 다른 형태로 대체하지 못한 상태.

해결: "80%만 내 기대에 부합하면 충분하다"는 원칙을 세운다. 팀원의 접근 방식이 자신과 다르다고 해서 틀린 것은 아니다. 결과가 아닌 방향만 설정하고, 실행은 팀원에게 맡긴다.

안티패턴 2: 모든 기술적 결정에 개입하기

증상: 모든 기술 논의에 참여한다. 아키텍처 결정, 라이브러리 선택, 변수명까지 자신이 최종 승인한다. 팀원들이 매니저의 승인 없이는 아무것도 결정하지 않는다.

원인: 기술적 통제력을 유지하려는 욕구. "내가 빠지면 잘못된 결정이 내려질 것"이라는 두려움.

해결: Camille Fournier는 The Manager's Path에서 "결정의 위임 매트릭스"를 제안한다.

안티패턴 3: 팀원의 성장 기회를 가로채기

증상: 기술적으로 도전적인 프로젝트가 오면 자신이 직접 한다. 중요한 발표나 이해관계자 미팅에 항상 자신이 참석한다. 팀원에게 "이건 내가 할게"라고 자주 말한다.

원인: 기술적 기여에 대한 향수. 팀원의 역량에 대한 불신. 자신의 가치를 기술적 기여로 증명하려는 욕구.

해결: "이 기회를 팀원에게 주면 누가 가장 성장할까?"를 먼저 생각한다. 직접 하고 싶은 일을 팀원에게 맡기고, 대신 코칭과 서포트에 집중한다. Zhuo는 이것을 **"자신의 대체자를 만드는 것"**이라고 표현했다.

안티패턴 4: 갈등 회피

증상: 팀원 간의 갈등을 목격해도 모른 척한다. 성과가 낮은 팀원에게 피드백을 주지 않는다. 어려운 대화를 계속 미룬다. "시간이 지나면 해결되겠지"라고 생각한다.

원인: 대인 갈등에 대한 불편함. "좋은 사람"이고 싶은 욕구. 갈등 해결 경험의 부족.

해결: 갈등은 무시하면 악화된다. Michael Lopp는 Managing Humans에서 "어려운 대화를 미룰수록 더 어려운 대화가 된다"고 경고한다. 문제가 작을 때 빠르게 대화하는 것이 핵심이다.

안티패턴 5: 모든 사람을 행복하게 만들려 하기

증상: 모든 요청에 "네"라고 답한다. 상충하는 요구사항 사이에서 우선순위를 정하지 못한다. 모든 사람의 기대를 충족시키려다 누구의 기대도 충족시키지 못한다.

원인: 거절의 어려움. 갈등 회피의 또 다른 형태. "좋은 매니저 = 모든 요청을 수용하는 매니저"라는 오해.

해결: "모든 사람을 만족시키는 것은 불가능하다"는 것을 수용한다. 대신 의사결정의 과정을 투명하게 공유한다. "이 결정에 동의하지 않을 수 있지만, 왜 이렇게 결정했는지 이해해주시면 좋겠습니다"라는 접근이 장기적으로 더 큰 신뢰를 구축한다.

안티패턴 종합 자가진단표

6장: 핵심 스킬 개발

스킬 1: 1:1 미팅 운영

1:1 미팅은 매니저의 가장 중요한 도구다. 잘 운영된 1:1은 팀원의 성장, 동기 부여, 문제 해결의 핵심 채널이 된다.

1:1 미팅의 구조:

1:1 미팅에서 물어야 할 질문:

• "이번 주에 가장 도전적이었던 일은?"
• "제가 도울 수 있는 블로커가 있나요?"
• "현재 하고 있는 일에서 배우고 있는 것이 있나요?"
• "팀에서 개선하고 싶은 것이 있나요?"
• "다음 몇 달간 시도해보고 싶은 것이 있나요?"

1:1 미팅에서 하면 안 되는 것:

• 상태 보고(Status Update)로만 시간을 쓰기 (이것은 스탠드업이나 비동기 업데이트로)
• 매니저만 말하기 (리스닝 대 스피킹 비율은 최소 60:40)
• 자주 취소하거나 미루기 (팀원에게 "당신은 우선순위가 아니다"라는 메시지)

스킬 2: 성과 평가와 피드백

효과적인 피드백의 SBI 프레임워크:

성과 평가 작성 팁:

1. 평가 기간 전체를 커버한다 (최근 한 달이 아닌 전체 기간)
2. 구체적 사례와 데이터에 기반한다
3. 강점과 개선 영역을 모두 포함한다
4. 다음 기간의 기대치를 명확히 한다
5. 팀원의 경력 목표와 연결한다

스킬 3: 채용과 면접

좋은 채용은 매니저가 할 수 있는 가장 영향력 있는 결정 중 하나다.

면접 평가 매트릭스:

스킬 4: 이해관계자 관리

EM은 팀 내부뿐 아니라 외부 이해관계자와의 커뮤니케이션도 관리해야 한다.

이해관계자 커뮤니케이션 전략:

스킬 5: 프로젝트 관리

기술 프로젝트의 성공은 리스크를 얼마나 빨리 식별하고 대응하느냐에 달려 있다.

프로젝트 건강 체크 프레임워크:

7장: 번아웃 예방과 자기 관리

EM의 번아웃이 특별한 이유

IC의 번아웃이 주로 기술적 도전의 과부하에서 오는 반면, EM의 번아웃은 감정 노동(Emotional Labor)의 과부하에서 온다.

매니저는 매일 다른 사람의 문제를 듣고, 갈등을 해결하고, 나쁜 소식을 전달하고, 해고를 결정해야 할 수도 있다. 이 모든 것은 감정적 에너지를 소모한다.

EM 번아웃의 전조 증상:

자기 관리 체크리스트

매일:

• 하루 중 최소 1시간의 방해받지 않는 시간 확보
• 점심 시간에 미팅을 잡지 않는다
• 하루 끝에 "오늘 잘한 것 하나"를 기록한다

매주:

• 동료 매니저와의 비공식적 대화 (서로의 고민 공유)
• 자신의 매니저와의 1:1에서 솔직하게 상태 공유
• 운동이나 취미 시간을 캘린더에 블록

매월:

• 자신의 에너지 수준을 1-10으로 평가
• "이번 달에 나를 가장 소모시킨 것"을 파악하고 대응 계획 수립
• 매니저 역할에 대한 만족도를 정직하게 점검

분기마다:

• 커리어 방향성 재검토
• 매니저 관련 학습 (책, 강연, 워크숍)
• 업무 외 인간관계 투자

8장: 다시 IC로 돌아가도 괜찮다 - 역할 전환의 가역성

엔지니어/매니저 진자 운동

Charity Majors는 유명한 블로그 포스트 "The Engineer/Manager Pendulum"(2017)에서 혁명적인 관점을 제시했다.

"가장 효과적인 리더는 IC와 매니저 사이를 오간 경험이 있는 사람이다. 한쪽에만 머무는 것보다 양쪽을 경험하는 것이 더 가치 있다."

이 "진자 운동(Pendulum)" 개념은 IC에서 EM으로의 전환이 일방향 문이 아님을 강조한다.

EM에서 IC로 돌아가는 것이 가치 있는 이유

돌아갈 때의 주의사항

1. 자존심을 내려놓아야 한다: "매니저에서 IC로 돌아가는 것 = 강등"이라는 인식이 있을 수 있다. 하지만 이것은 다른 전문성으로의 전환이다
2. 기술적 갭을 인정해야 한다: EM 기간 동안 기술적 깊이가 줄어들었을 수 있다. 겸손하게 학습 모드로 돌아가야 한다
3. 매니저 습관을 내려놓아야 한다: "팀을 이끌려는" 습관을 IC 역할에서는 조절해야 한다
4. 조직의 지원이 필요하다: IC로의 전환을 수월하게 해주는 조직 문화가 중요하다

역할 선택 의사결정 프레임워크

정기적으로(연 1회 정도) 자신에게 다음 질문을 던져본다.

9장: 체크리스트 - EM 전환 후 100일 자기 점검

첫 30일 점검

• 모든 직속 보고자와 최초 1:1을 완료했는가?
• 팀의 현재 프로세스와 문화를 문서화했는가?
• 이해관계자 맵을 작성했는가?
• 자신의 매니저와 기대 수준을 정리했는가?
• 팀원들의 이름, 역할, 강점, 관심사를 파악했는가?
• 큰 변화를 시도하려는 유혹을 참았는가?

31~60일 점검

• 정기적 1:1 스케줄이 확립되었는가?
• 최소 하나의 Quick Win을 달성했는가?
• 팀원들로부터 초기 피드백을 수집했는가?
• 팀의 주요 블로커를 파악하고 해결을 시작했는가?
• 이해관계자들과의 커뮤니케이션 채널이 구축되었는가?
• 코딩 비중을 적절히 조절하고 있는가?

61~100일 점검

• 팀의 분기 목표가 수립되었는가?
• 각 팀원의 개인 성장 계획이 있는가?
• 프로세스 개선 사항이 하나 이상 실행되었는가?
• 팀원들이 자율적으로 의사결정을 하고 있는가?
• 자신의 에너지 수준과 번아웃 위험을 점검했는가?
• 매니저 역할에 대한 만족도를 정직하게 평가했는가?

100일 이후 장기 점검

• 팀의 생산성과 품질이 유지되거나 향상되었는가?
• 팀원들의 성장 속도가 가속화되었는가?
• 팀 내 심리적 안전감이 확보되었는가?
• 자신이 없어도 팀이 잘 돌아가는가?
• 이 역할에서 지속적인 학습과 성장을 하고 있는가?
• 여전히 이 역할이 자신에게 맞다고 느끼는가?

10장: 실용적 프레임워크와 템플릿

1:1 미팅 노트 템플릿

주간 팀 상태 보고 템플릿

신규 매니저의 90일 학습 계획

결론: 전환은 여정이다

IC에서 EM으로의 전환은 100일로 "완료"되는 것이 아니다. 그것은 지속적인 학습과 적응의 여정이다.

이 여정에서 기억해야 할 핵심 원칙들을 정리한다.

1. 겸손하게 시작하라: 첫 한 달은 듣고, 관찰하고, 이해하는 시간이다. 변화는 이해가 충분해진 다음에 시도한다
2. 코딩을 내려놓는 연습을 하라: 코딩에 대한 미련은 자연스럽지만, 매니지먼트에 집중하지 않으면 양쪽 모두에서 실패한다
3. 사람에 투자하라: 팀원의 성장이 매니저의 가장 중요한 산출물이다
4. 자기 자신을 돌보라: 감정 노동의 무게를 과소평가하지 말라. 번아웃은 팀 전체에 영향을 미친다
5. 돌아갈 수 있다는 것을 기억하라: EM이 맞지 않으면 IC로 돌아가는 것은 실패가 아니라 현명한 선택이다

Charity Majors의 말처럼, 가장 효과적인 기술 리더는 IC와 EM 양쪽의 경험을 가진 사람이다. 어느 쪽을 선택하든, 그 경험은 결코 낭비가 아니다.

"관리는 그 자체로 보상이 있는 직업이다. 하지만 그것은 코딩과는 완전히 다른 종류의 보상이다. 두 가지 보상 모두 가치가 있다." - Camille Fournier, The Manager's Path

역할 전환을 앞둔 모든 엔지니어에게, 그리고 이미 전환의 한가운데에 있는 모든 새 매니저에게. 불안함은 자연스러운 것이다. 완벽하지 않아도 괜찮다. 중요한 것은 매일 조금씩 더 나은 매니저가 되려고 노력하는 것이다.

참고 자료

1. Camille Fournier, The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change (2017) - IC에서 CTO까지의 경력 경로에 대한 종합적 가이드
2. Will Larson, An Elegant Puzzle: Systems of Engineering Management (2019) - 엔지니어링 매니지먼트를 시스템적으로 접근하는 방법론
3. Julie Zhuo, The Making of a Manager: What to Do When Everyone Looks to You (2019) - 신규 매니저를 위한 실용적 가이드
4. Paul Graham, "Maker's Schedule, Manager's Schedule" (2009) - 메이커와 매니저의 시간 활용 방식의 근본적 차이
5. Michael Lopp, Managing Humans: Biting and Humorous Tales of a Software Engineering Manager (2016) - 소프트웨어 엔지니어링 매니지먼트의 인간적 측면
6. Charity Majors, "The Engineer/Manager Pendulum" (2017) - IC와 EM 사이의 역할 전환에 대한 새로운 관점
7. Kim Scott, Radical Candor (2017) - 직접적이면서도 배려 있는 피드백 방법론
8. Lara Hogan, Resilient Management (2019) - 매니저로서의 회복탄력성과 팀 관리