Skip to content

필사 모드: 엔지니어링 매니저 완전 전환 가이드 — IC에서 EM으로: 첫 90일·채용·해고·성과 평가·조직 확장·IC 복귀까지 2025-2026년 현실편

한국어
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.
원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> "Management is a career change, not a promotion." — Camille Fournier 『The Manager's Path』

[커뮤니케이션 가이드]에서 1:1·피드백·협상을 다뤘다. 이 기술을 **본격적으로 쓰는 직업**이 엔지니어링 매니저(EM)다.

많은 시니어 엔지니어가 EM 제안을 받고 고민한다. "승진이니까 받아야지"가 가장 흔한 실수다. **EM은 승진이 아니라 직업 전환**. 당신이 좋아하는 기술 문제는 줄어들고, 사람 문제가 늘어난다. 이 글은 그 결정을 정보에 근거해 내릴 수 있게 한다.

대상:

- EM 오퍼를 받은 시니어.

- EM 전환 후 첫 1년에 헤매는 사람.

- IC로 돌아오고 싶은 EM.

- 자신의 EM을 이해하고 싶은 IC.

목차

1. EM은 무엇을 하는가 — 역할 정의

2. IC vs EM 트랙 선택의 결정 트리

3. EM 첫 90일 플레이북

4. 위임·Delegation — 매니저의 가장 어려운 기술

5. 채용·면접·온보딩

6. 성과 평가와 승진 결정

7. 해고와 PIP — 가장 어려운 대화

8. 조직 확장과 Reorg

9. 기술 이해를 유지하는 법

10. IC로 돌아오는 경로

11. 한국 조직의 EM 현실

12. 체크리스트와 안티패턴

1. EM은 무엇을 하는가 — 역할 정의

1.1 하루의 변화

**IC 시니어의 하루**:

- 코딩 60%·리뷰 20%·미팅 20%.

- Deep work 블록 3~4시간 확보 가능.

**EM의 하루**:

- 1:1 30%·미팅 30%·계획·문서 20%·코드 리뷰 10%·직접 코딩 10%.

- Deep work 1~2시간, 중간 중간 interrupt.

1.2 성공의 측정 기준

- IC: 내 코드·설계·출력.

- EM: **팀의 출력**.

내가 아니라 팀이 잘하는 것을 봐야 한다. 이게 가장 큰 심리적 전환.

1.3 EM의 핵심 책임 5가지

1. **People**: 채용·성장·평가·해고.

2. **Delivery**: 프로젝트 완성.

3. **Strategy**: 방향·우선순위.

4. **Process**: 팀 운영·의례.

5. **Stakeholder**: 다른 팀·상위·PM과 조율.

1.4 EM 유형

**Tech Lead Manager (TLM)**:

- Google 전통. 기술 + 사람 반반.

- 팀 4~6명.

**Pure People Manager**:

- 기술 결정은 tech lead·staff engineer.

- 7~15명.

**Director (M2)**:

- Manager of Managers.

- 20~50명.

1.5 좋은 EM의 시그널

- 팀 engagement score 높음.

- Eng retention.

- 프로젝트 예측 가능성.

- 주니어 → 시니어 승진.

- 후속 EM·Staff 배출.

1.6 EM이 무엇이 아닌지

- 기술 감독관이 아님.

- PM 대체가 아님.

- 팀의 최고 기술자가 아님 (그게 Staff).

- 업무 분배 기계가 아님.

2. IC vs EM 트랙 선택의 결정 트리

2.1 EM이 맞을 수도 있는 신호

- 타인 성장에 에너지 충전.

- 복잡한 사람 관계 탐색 즐김.

- 글·1:1·미팅에서 에너지 소진 적음.

- 여러 프로젝트 동시 파악 즐김.

- 추상적·애매한 문제 견딤.

2.2 IC가 맞을 수도 있는 신호

- 깊이·기술 탐구가 주요 만족.

- 미팅 많으면 탈진.

- 여러 프로젝트 추적이 고통.

- 사람 문제 피로도 높음.

2.3 "해보면 안다"

- 대부분 회사가 **EM trial** 허용: 3~6개월.

- 돌아갈 수 있다는 전제로 시도.

2.4 Dual-track 회사

- **Google, Meta, Stripe**: Staff/Principal IC 트랙 강함.

- **Amazon**: Principal Engineer 트랙 명확.

- **Apple**: IC 트랙 유명.

- 한국: 대기업 IC 트랙 아직 초기. 스타트업이 더 유연.

2.5 연봉 비교

- L5 수준: EM ≈ Senior IC.

- L6~L7: Staff IC > Senior EM (일부).

- L7+: Principal IC = Director.

즉, 연봉 상승을 이유로 EM 가는 건 **중간 레벨에만** 타당.

2.6 시간 지평

- **5년 후 어디에 있고 싶은가**.

- Founding CEO 되고 싶으면 EM 경험 유리.

- Deep tech researcher 되고 싶으면 IC 유지.

3. EM 첫 90일 플레이북

3.1 Week 1-2: Listen

- **1:1 전체 팀원 with**.

- **"What's broken? What should continue?"**.

- **아무것도 바꾸지 말기** (Chesterton's Fence).

3.2 Week 3-4: Map

- **Team charter**: 무엇 하는 팀인가.

- **Stakeholder map**: 누구와 일하는가.

- **Current projects**: 상태·health.

- **Team skill matrix**: 누가 무엇 잘함.

3.3 Week 5-8: Diagnose

- **문제 3가지 우선 순위**.

- Process·people·project.

- 내 boss와 합의.

3.4 Week 9-12: Act

- **최소 1개 변화**: quick win.

- **3개월 로드맵 제시**.

- **팀 ritual 조정** (standup·retro·review).

3.5 First 90 안티패턴

1. **즉시 reorg**: 맥락 없이.

2. **이전 EM 비난**.

3. **내 코드 스타일 강제**.

4. **모든 미팅 재설계**.

5. **1:1 건너뛰기**.

3.6 "관리자 신고식"

- 첫 해고.

- 첫 승진 추천.

- 첫 "no" 말하기.

- 첫 difficult 1:1.

각각이 경험 마일스톤.

4. 위임 — 매니저의 가장 어려운 기술

4.1 왜 위임이 어려운가

- **"내가 하면 더 빨라"** 함정.

- 실수 risk.

- Context 전달 비용.

하지만 위임 없이는 **scale이 안 된다**.

4.2 위임 매트릭스 (Tanya Reilly)

| Level | 설명 | 예 |

|---|---|---|

| 1 | Do exactly this | Task 명시 |

| 2 | Research and recommend | 조사 후 제안 |

| 3 | Decide and tell | 결정 후 보고 |

| 4 | Decide and do | 그냥 하라 |

주니어는 1~2, 시니어는 3~4.

4.3 Radical Responsibility

- 위임했어도 **결과 책임은 매니저**.

- 실패 시 "내 책임", 성공 시 "팀 공".

4.4 위임 후 체크인

- **너무 자주 체크**: micromanagement.

- **너무 드물게**: drift.

- **주간 1:1 + 중간 마일스톤** 균형.

4.5 "내 일" 목록 vs "내 관심 영역"

- 직접 하는 것 vs 팀이 하는 것.

- EM 시간의 10% 이하만 hands-on.

- 나머지는 enable.

4.6 Hands-on vs Hands-off

- 프로덕션 incident: hands-on으로 참여.

- Feature 구현: hands-off.

- 채용: hands-on.

5. 채용·면접·온보딩

5.1 채용은 매니저의 최우선

- **한 번의 잘못된 hire** = 6~12개월 후 PIP/해고.

- 좋은 채용 = 팀의 영구 자산.

5.2 JD 작성

- **Must-have vs Nice-to-have** 분리.

- **팀 맥락·성장 기회**.

- **연봉 밴드** 공개 (trust 신호).

5.3 면접 프로세스 설계

- **Phone screen** (30분 recruiter + 45분 hiring manager).

- **Technical**: coding (60~90분) + system design (60분).

- **Behavioral**: hiring manager + peer.

- **Bar raiser**: 타 팀·부서.

- **Debrief meeting**: 참여자 모여 결정.

5.4 Calibration

- **Scorecard**: 각 축 1-5.

- **강한 no = 거부**: 약한 yes 다수보다 강함.

- **Written feedback** 먼저, 토론 후.

5.5 Signal vs Noise

- **Code style 편향**: 내 스타일과 다른 걸 거부.

- **대학 이름·회사 이름** halo.

- **Likability bias**: 친근하면 더 좋아 보임.

→ **표준화된 rubric**이 방어선.

5.6 온보딩 30-60-90

- **30일**: 환경 설정·첫 PR·1:1 완료.

- **60일**: 중간 프로젝트 기여.

- **90일**: 독립적 owner.

5.7 한국 채용 맥락

- **평판·레퍼런스** 영향 큼.

- **지원자 풀** 적어서 유명 기업 경쟁 치열.

- **스타트업 경험** 편차 커서 검증 필요.

- **글로벌 원격 채용** 점점 흔해짐.

6. 성과 평가와 승진 결정

6.1 평가의 목적

- **성장 피드백**.

- **보상 결정**.

- **승진 자격**.

이 세 개가 혼합되면 솔직한 대화 어려움.

6.2 평가 축

- **Impact** (영향).

- **Technical execution**.

- **Collaboration·influence**.

- **Growth / Leadership**.

회사마다 가중치 다름.

6.3 Calibration 프로세스

- 매니저들이 모여 팀 간 비교.

- **Forced distribution** (bell curve): 논란.

- 상대 비교로 bias 조정.

6.4 승진 자격

- "이미 다음 레벨에서 일하고 있다"는 증거.

- **Promo packet**: artifacts·레퍼런스·self-assessment.

- 2~4 분기 일관된 성과.

6.5 승진 추천 준비

- 매니저가 6개월 전부터 준비.

- Peer 피드백 수집.

- 스코프 확장 기회 제공.

- 가시성 늘리기.

6.6 승진 안 됐을 때

- **1주 이내 솔직한 대화**.

- 이유 구체화.

- 다음 사이클 계획.

- 분노·퇴사 유혹 관리.

6.7 Compensation 대화

- **밴드 투명성**.

- **Delta 이유** 명확.

- **경쟁 오퍼 match** 정책.

7. 해고와 PIP — 가장 어려운 대화

7.1 해고는 빠를수록 인도적

- 나쁜 hire 유지 = 모든 팀원에게 부정적.

- "해고 결정을 1주 빨리 못 한 걸 후회한다"가 매니저 공통.

7.2 Performance Improvement Plan (PIP)

- 30~90일 공식 개선 기간.

- 명확한 기대치·측정 가능.

- 주 1~2회 체크인.

PIP 통과율: 회사·지역에 따라 다르나 일반적으로 20~40%.

7.3 해고의 법적·윤리적 절차

**미국**:

- At-will 고용 (대부분 주).

- Documentation 중요 (PIP·lettering).

- Severance + release.

**한국**:

- 정당한 사유 필요.

- 30일 전 통지 또는 통상 임금.

- 권고사직 vs 정리해고 구분.

7.4 해고 대화 스크립트

- **15분 미만**.

- **단도직입**: "오늘이 네 마지막 근무일이야."

- **이유**: 간결·사실 기반.

- **논쟁 금지**.

- **다음 단계**: HR·severance·benefit.

7.5 해고 후 팀 공지

- **24시간 내** 팀에 알림.

- **존중**: 이유 공개 금지.

- **재배치**: 업무 interim plan.

7.6 Layoff (대규모 해고)

- 2022~2024 tech 산업 대규모 layoff.

- **개인 잘못이 아님** 강조.

- **Severance·career transition 지원**.

- **남은 팀 morale** 집중.

7.7 자발 퇴사의 관리

- **Exit interview**: 솔직한 이유.

- **Counter offer는 함정**: 한번 떠나기 결정한 사람 거의 다시 떠남.

- **Off-boarding 깔끔**: 지식 이전·관계 유지.

- **Alumni network**: 재입사·추천.

8. 조직 확장과 Reorg

8.1 팀 크기의 phase transition

- **1~5명**: 모두 모든 것 알기.

- **5~10명**: role 분리 시작.

- **10~20명**: sub-team 고려.

- **20명+**: EM of EMs 필요.

8.2 언제 팀을 나누는가

- Stand-up이 30분 넘음.

- 지식 silos 생김.

- 서비스가 커뮤니케이션 복잡.

8.3 Reorg 설계 원칙

- **Why first**: 모두가 이해해야.

- **Team Topologies** 참조.

- **Minimal disruption**: 필요 최소한.

- **Champions**: 각 팀에 옹호자.

8.4 Reorg 발표

- **1주 전 매니저 라인에 sync**.

- **all-hands 발표**.

- **Individual 1:1** 후속.

- **FAQ 문서**.

8.5 Reorg 저항

- **상실감**: 팀·identity·관계.

- **Trust 비용**: 너무 자주 reorg 금물 (연 1회 이하 권장).

8.6 Span of Control

- **EM당 직속 5~8명** 권장.

- 10명 넘으면 depth 부족.

- 3명 이하면 under-utilized.

9. 기술 이해를 유지하는 법

9.1 위험 — 3년 후 기술 disconnect

- EM 5년 → 다시 IC는 힘듦.

- 시장에서 평가 애매.

- 팀 기술 결정에 권위 약화.

9.2 hands-on 유지 전략

- **매주 최소 4시간 코딩**: 작은 PR, prototype.

- **Major tech review** 참여.

- **On-call rotation** 1/월.

- **신기술 sandbox**: 새 LLM, 프레임워크 직접 사용.

9.3 독서·학습

- **주간 1시간** paper·blog.

- **오픈소스 훓기**.

- **컨퍼런스 참석 2~3회/년**.

9.4 Tech lead와의 협력

- **대부분 tech 결정은 Tech Lead·Staff가 주도**.

- EM은 **질문자·challenger** 역할.

- "왜?"와 "대안은?"으로 질 향상.

9.5 Technical radar

- **매월 팀 기술 스택 리뷰**.

- ThoughtWorks Radar·InfoQ.

10. IC로 돌아오는 경로

10.1 EM에서 IC로 = Career suicide?

과거엔 그랬다. 지금은 정상화.

- "Career pendulum": 회사 내 왔다갔다.

- **Staff IC** 수요 증가로 rehoming 가능.

10.2 언제 돌아와야 하나

- 매 1:1 전 dread.

- 하루 끝에 "I didn't build anything" 공허.

- People 문제보다 tech 문제에 에너지.

- 건강·정신 상태.

10.3 돌아가는 방법

- **매니저와 대화** 먼저.

- **Title·comp 협상**: 일부 회사는 downgrade, 일부는 horizontal.

- **1~3개월 transition**.

10.4 돌아온 후 적응

- **기술 갭 메꾸기**: 2~6개월 집중.

- **EM 경험이 자산**: 팀 이해·stakeholder 관리.

- **Tech Lead·Staff Engineer**로 빠르게 진입 가능.

10.5 EM → IC → EM 다시

- 가능. Charity Majors (Honeycomb CTO)가 대표적으로 옹호.

- "Engineer/Manager Pendulum" 블로그 글.

- 양쪽 경험이 각각을 강화.

11. 한국 조직의 EM 현실

11.1 전통 대기업

- **관리직이 전통적 출세 경로**.

- "부장·임원" 승진.

- 기술 잃어버린 매니저 비판.

11.2 테크·스타트업

- **EM·Staff 분리** 점진 정착.

- 네이버·카카오·쿠팡·토스·당근.

- 여전히 "나이 많으면 관리" 관행.

11.3 외국계 지사

- **Global track** 따름.

- IC 트랙 명확.

- 한국 채용 경쟁력 강점.

11.4 한국 특유 EM 도전

- **연공서열 vs 평가** 충돌.

- **"회식·야근"** 문화 vs 글로벌 수평.

- **외국인 동료** 증가에 high-context 문제.

11.5 한국 EM을 위한 추천

- **글로벌 표준 학습**: Camille Fournier·Will Larson.

- **해외 EM 네트워크**: LinkedIn·Meetup.

- **영어 커뮤니케이션** 훈련.

- **Dual-track 신호**: 조직이 Staff 트랙 있으면 건강한 신호.

12. EM 번아웃 관리

12.1 EM은 특히 번아웃 위험

- **감정 노동** 많음.

- Deep work 부족.

- 성과가 늦게 가시화.

12.2 에너지 관리

- **회의 back-to-back 금지**.

- **Buffer time**: 15분 회의간.

- **주간 deep work block**.

12.3 지원 네트워크

- **EM 동료 그룹**.

- **코칭 / 테라피** 고려.

- **멘토**: 1~2단계 위.

12.4 재충전

- **휴가 실제 off**: 업무 Slack 끄기.

- **Sabbatical**: 3~6개월.

- **취미**: 완전히 다른 결.

체크리스트

1. ☐ 매주 모든 직속 부하와 1:1을 한다.

2. ☐ 팀 스킬 매트릭스를 분기별 업데이트한다.

3. ☐ 마지막 6개월에 채용 인터뷰를 진행했다.

4. ☐ 직속 부하 중 최소 1명의 승진을 성공시켰다.

5. ☐ 팀 retrospective를 월 1회 한다.

6. ☐ 기술 hands-on 시간이 주 4시간 이상이다.

7. ☐ 나의 매니저와 매주 1:1.

8. ☐ Skip-level 1:1을 분기별로.

9. ☐ 해고·PIP 프로세스를 문서로 알고 있다.

10. ☐ 번아웃 전조 증상을 파악하고 있다.

11. ☐ IC 복귀 옵션을 매니저와 논의해본 적 있다.

12. ☐ EM 동료 네트워크 최소 3명.

자주 보는 안티패턴 10가지

1. **승진 이유로 EM 수락** — 적성 무시.

2. **첫 90일에 reorg**.

3. **기술 무관심** — 3년 후 IC 복귀 불가.

4. **해고 미룸** — 팀 전체 사기 파괴.

5. **Favoritism**: 편애.

6. **팀 성과를 내 것으로**.

7. **1:1 cancel 반복**.

8. **하향식 의사결정만** — 팀 autonomy 파괴.

9. **번아웃 무시**.

10. **Career pendulum 고정관념** — "한번 EM이면 영원히".

추천 리소스

- **Camille Fournier** — 『The Manager's Path』.

- **Will Larson** — 『An Elegant Puzzle』, 『Staff Engineer』.

- **Julie Zhuo** — 『The Making of a Manager』.

- **Lara Hogan** — 『Resilient Management』.

- **Michael Lopp (Rands)** — 『Managing Humans』, Rands in Repose.

- **Andy Grove** — 『High Output Management』.

- **Ben Horowitz** — 『The Hard Thing About Hard Things』.

- **Kim Scott** — 『Radical Candor』.

- **Charity Majors** — Honeycomb CTO 블로그 (E/M Pendulum).

- **Tanya Reilly** — 『The Staff Engineer's Path』.

다음 글 예고 — “엔지니어 팀 문화 설계 완전 가이드: Psychological Safety·DevEx·Rituals·Retrospective·Code Review·문서화까지”

EM이든 IC든, 팀이 **건강**해야 한다. 팀 문화는 설계 대상이다.

- Google Project Aristotle의 5가지 요인

- Psychological Safety 측정·개선

- DevEx (Developer Experience) 프레임워크

- 팀 ritual 설계 — standup·retro·review

- 코드 리뷰 문화

- 문서화 문화

- Inclusion과 diversity

- 갈등을 생산적으로

- 원격·하이브리드 팀 문화

개인 역량을 넘어 **팀 설계**의 예술. 다음 글에서 이어진다.

현재 단락 (1/320)

[커뮤니케이션 가이드]에서 1:1·피드백·협상을 다뤘다. 이 기술을 **본격적으로 쓰는 직업**이 엔지니어링 매니저(EM)다.

작성 글자: 0원문 글자: 8,130작성 단락: 0/320