Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> "We don't rise to the level of our goals, we fall to the level of our systems." — James Clear

[엔지니어링 매니저 전환 가이드]에서 개인 매니저의 역할을 다뤘다. 하지만 매니저 한 명이 만들 수 있는 것에는 한계가 있다. 진짜 레버리지는 **팀 문화라는 시스템**에 있다.

Google은 5년간 180개 팀을 연구한 Project Aristotle에서 **스타 엔지니어 비율·경력 구성·IQ 평균** 어느 것도 팀 성과의 예측 변수가 아니라는 결론을 냈다. 진짜 예측 변수는 **문화적 요인**이었고, 그 중 첫 번째가 Psychological Safety였다.

이 글은 엔지니어 팀 문화를 **설계 가능한 시스템**으로 본다. 감각·분위기가 아니라 구체적 ritual·process·문서로. 대상: EM, Staff Engineer, Tech Lead, 그리고 문화 설계에 영향력을 미치고 싶은 모든 시니어.

1. Project Aristotle — 팀 성과의 5가지 요인

1.1 구성원이 아닌 규범

Google re:Work 연구 (2015 발표):

> "Who is on a team matters less than how the team members interact, structure their work, and view their contributions."

5가지 요인 — 영향력 순서:

1. **Psychological Safety** (가장 중요).

2. **Dependability** — 믿고 맡길 수 있음.

3. **Structure & Clarity** — 역할·목표·프로세스 명확.

4. **Meaning** — 개인적 의미.

5. **Impact** — 실제 영향 있다는 인식.

1.2 반직관

- 스타 개발자 비율: **무관**.

- 경력 연차 평균: **무관**.

- IQ·MBTI 등 성격 분포: **무관**.

- 팀 규모: 약간 영향.

1.3 한국에서의 연구

- HBR·McKinsey·보스턴 컨설팅 한국 팀 연구: 유사 결론.

- 특히 Psychological Safety 낮은 편 (hierarchy 영향).

1.4 문화는 Gradient Descent다

- 한 번에 완성되지 않음.

- 작은 피드백 루프 반복.

- 매주·매월 개선 지표 확인.

2. Psychological Safety — 측정·진단·개선

2.1 정의 (Amy Edmondson)

> "The belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes."

**대인 관계적 위험을 감당할 수 있다는 공유된 신념**.

2.2 측정 — 7개 질문

Edmondson의 원 설문지:

1. 이 팀에서 실수하면 자주 내 실수로 책임이 씌워진다. (R)

2. 이 팀의 구성원들은 문제와 어려운 이슈를 꺼낼 수 있다.

3. 이 팀 사람들은 때로는 다르다는 이유로 타인을 거부한다. (R)

4. 이 팀에서 위험을 감수하는 것이 안전하다.

5. 이 팀 구성원에게 도움을 요청하기 어렵다. (R)

6. 이 팀에서 누구도 나의 노력을 일부러 훼손하려 하지 않는다.

7. 이 팀에서 일하면서 내 고유 기술·재능이 가치있게 여겨지고 활용된다.

(R)은 reverse scored. 분기별 익명 설문.

2.3 지표 해석

- **평균 4.0/5.0 이상**: 건강.

- **3.0~4.0**: 개선 여지.

- **3.0 미만**: 긴급 대응.

2.4 개선 방법

**리더 행동**:

- **Model vulnerability**: "나도 모른다"·"내 실수다".

- **Ask genuine questions**.

- **Thank for disagreement**.

**팀 ritual**:

- **Blameless post-mortem**.

- **Disagree & commit** 문화.

- **Failure celebration**: 실패 공유 주 1회.

**프로세스**:

- **Anonymous feedback** 채널.

- **Skip-level 1:1**.

- **360 review**.

2.5 Silence 신호

- 회의에서 주니어 발언 없음.

- 매니저가 모르는 이슈가 slack DM으로만.

- Post-mortem에 개인 탓.

- 고분고분한 "yes".

2.6 Toxic safety

- "안전해서 아무도 도전하지 않는 팀"도 위험.

- Safety + High standards 둘 다 필요 (Amy Edmondson 2x2 매트릭스).

3. DevEx — Developer Experience의 3 dimensions

3.1 DX Core 4 (Nicole Forsgren 2024)

DORA 이후의 새 프레임워크:

1. **Diff throughput**: 머지 주기.

2. **Time to 10th PR**: 신규 인원 생산성.

3. **Change lead time**: 커밋 → 프로덕션.

4. **Perceived ease of delivery**: 설문.

3.2 Abi Noda SPACE 프레임워크

1. **Satisfaction**.

2. **Performance**.

3. **Activity**.

4. **Communication**.

5. **Efficiency**.

3.3 DevEx 핵심 3 dimensions (DX 2023)

- **Feedback loops**: CI 속도·테스트 속도.

- **Cognitive load**: 스킬 매트릭스·의존성.

- **Flow state**: 방해 없는 deep work.

3.4 설문 vs 지표

- **System metrics**: CI time·build time·error rate.

- **Survey**: 주관 감정. Quarterly.

- 둘 다 필요. System metric이 좋아도 설문이 나쁘면 숨은 문제.

3.5 DevEx 투자 ROI

- DX Research: **DevEx 개선이 retention 2x**.

- 30% 시간이 "마찰"에 소비됨.

- Platform Engineering 투자로 회수.

3.6 흔한 DevEx 개선

- CI 시간 10분 → 3분.

- Local dev 환경 15분 setup → 5분.

- 문서 검색 unified (Algolia·Coveo).

- AI coding assistant (Copilot·Cursor).

- Feature flag로 merge 속도.

4. 팀 ritual 설계

4.1 Ritual의 목적

- **Sync**: 정보 공유.

- **Commit**: 약속.

- **Reflect**: 개선.

- **Celebrate**: 사기.

4.2 Daily Standup

**좋은 standup**:

- 15분 이하.

- "Yesterday·Today·Blockers" 또는 "walk the board".

- Face-to-face or video.

- Blocker 후속은 따로.

**나쁜 standup**:

- 매니저에게 보고.

- 30분 디스커션.

- 전원 참석 강제 but 의미 없는 참여.

**대안**: 비동기 standup (Slack bot, Standuply, Geekbot). 리모트 팀 적합.

4.3 Sprint Planning / Roadmap

- **주간·격주·월간** 중 택1.

- Backlog refinement 분리 (preread).

- **Capacity planning**: 현실적 예측.

- **Goal setting**: 이번 스프린트의 **핵심 3개**.

4.4 Retrospective

**Classic format (1시간)**:

- Set the stage (5분).

- Gather data (15분).

- Generate insights (15분).

- Decide what to do (15분).

- Close (10분).

**Format variations**:

- Start/Stop/Continue.

- Mad/Sad/Glad.

- 4Ls (Liked/Learned/Lacked/Longed for).

- Sailboat (Wind/Anchor/Rocks/Island).

**Action item 추적 필수** — 없으면 retro는 therapy.

4.5 Weekly Review / Eng All-hands

- 전체 팀 업데이트.

- 큰 결정·변화.

- Q&A 시간.

- 데모: 이번 주 완성한 것.

4.6 1:1 Cascading

- CEO → VP → Director → EM → IC.

- 정보 순환 구조.

4.7 Learning rituals

- **Reading group**: 월 1회 책·논문.

- **Tech talk**: 주 1회 발표.

- **Hackathon·FedEx day**: 분기 1회 자유 프로젝트.

4.8 Social rituals

- **Team lunch**: 주 1회.

- **Offsite**: 분기별·연 1회.

- **Gaming·hobby channel**: Slack.

리모트 팀 특히 사회적 ritual 의식적 설계.

5. 코드 리뷰 문화

5.1 목적 재확인

- **버그 발견** (의외로 큰 비중 아님).

- **지식 공유** (가장 큰 가치).

- **설계 개선**.

- **코드베이스 일관성**.

5.2 좋은 리뷰 원칙

- **24시간 내 첫 응답**.

- **Small PRs** (under 400 LOC).

- **LGTM with caveat**: 명확한 comment.

- **Nit vs Blocker** 구분.

- **"왜"를 설명**.

5.3 Google 스타일 가이드

- "The reviewer, not the author, should respond to the question 'is this code good enough?'"

- 대신 completeness가 아닌 개선을 목표로.

- **Reviewer must look at code within one business day**.

5.4 Tone

- **Positive reinforcement**: "좋은 패턴이네".

- **Question form**: "이거 왜 이렇게 했어?" 대신 "이 접근의 trade-off는?"

- **"We" over "You"**: "우리 코드베이스에서…"

5.5 AI 리뷰 도입 (2025)

- **CodeRabbit, Graphite AI, Greptile, Codium**.

- 1차 자동 리뷰: nit·스타일·명확한 버그.

- Human reviewer는 고차원 피드백 집중.

5.6 Stacked diff vs Big PR

- **Stacked**: Graphite·Sapling·Jujutsu.

- 작은 단위 리뷰, 빠른 피드백.

- Monorepo·빠른 팀 선호.

5.7 Review SLA

- 응답 1일 이내.

- 머지 3일 이내.

- Escalation: Slack ping.

6. 문서화 문화 — Handbook First

6.1 GitLab Handbook 모델

- 전세계 2,500명 fully-remote.

- **handbook-first culture**.

- 2,500+ 페이지 공개 문서.

- 의사결정·프로세스·사람·정책 모두 문서.

6.2 Handbook vs Wiki vs Docs

- **Handbook**: "how we work" — 규칙·프로세스·원칙.

- **Wiki**: 지식 저장소.

- **API/product docs**: 사용자용.

구분과 단일 정보 출처(Single Source of Truth).

6.3 문서의 3단계

1. **Discoverable** — 검색으로 찾을 수 있음.

2. **Readable** — 5분 훓어볼 수 있음.

3. **Actionable** — 따라할 수 있음.

6.4 Diátaxis 프레임워크

4 quadrant:

- **Tutorial**: 학습.

- **How-to**: 문제 해결.

- **Reference**: 조회.

- **Explanation**: 이해.

각 목적별 다른 스타일.

6.5 Internal wiki 도구

- **Notion**: 작은·중간 조직.

- **Confluence**: 대기업.

- **Slab·Slite·Almanac·Guru**: 특화.

- **Obsidian·Logseq**: 개인+팀 혼합.

6.6 "문서가 stale하다"의 해결

- **Doc ownership**: 명시적 소유자.

- **Review cadence**: 6개월마다.

- **"Delete > stale"**: 오래된 것은 삭제.

- **AI search**: Algolia AI·Coveo로 현대성 확인.

6.7 AGENTS.md 시대

- AI 코딩 에이전트 위한 가이드.

- 저장소 root에 `AGENTS.md` 파일 트렌드 (2025).

- 인간·AI 공통 온보딩 문서.

7. Inclusion과 Diversity

7.1 D&I의 엔지니어링 가치

- Diverse team이 **복잡한 문제**에 더 좋은 결정 (McKinsey·BCG).

- 사용자 대표성.

- 채용 pool 확대.

7.2 Inclusion 없는 Diversity는 Tokenism

- 뽑았지만 목소리 없음.

- 6~12개월 내 이탈.

- "왜 또 퇴사했을까" 반복.

7.3 실전 inclusion 체크

- **회의 발언 분포**: 성별·직급 편향 감지.

- **Mentorship 접근**: 공식 프로그램.

- **Interrupt rate**: 누가 누구 말 끊는가.

- **Idea attribution**: 같은 아이디어 남·여 제안 시 반응 차이.

7.4 Allyship

- **Listen**: 경험 공유 경청.

- **Amplify**: 회의에서 underrepresented voice 강조.

- **Sponsor**: 승진·기회 지지.

- **Challenge**: bias·joke 지적.

7.5 한국 맥락 D&I

- **여성 엔지니어 비율** 낮음 (대기업 15~20%).

- **나이 다양성** 부족 (35세+).

- **외국인** 점점 증가.

구체적 개입:

- 여성 멘토 프로그램.

- 시니어 재진입 경로.

- 외국인 onboarding 영어화.

7.6 Micro-aggression

- 사소한 차별 언어·행동.

- 누적 효과 큼.

- 교육·intervention으로.

8. 갈등을 생산적으로

8.1 갈등 없는 팀은 위험

Patrick Lencioni 『5 Dysfunctions of a Team』:

- Dysfunction 2: **Fear of conflict**.

- 건강한 팀은 생산적으로 갈등.

8.2 Conflict 유형

- **Task**: 아이디어·접근 차이. **Positive**.

- **Process**: 방법 차이.

- **Relationship**: 인격적. **Destructive**.

Task conflict는 확대·격려, Relationship은 조기 해결.

8.3 Decision frameworks

- **DACI**: Driver·Approver·Contributor·Informed.

- **RAPID**: Recommend·Agree·Perform·Input·Decide.

- **Disagree & Commit**: 결정 후 집중.

8.4 RFC 문화

- 기술 논쟁을 문서로.

- Comment·async thread.

- 실시간 싸움 방지.

8.5 Escalation 가이드

- **24시간 1:1 시도** → 해결 안 되면 매니저.

- **매니저 선에서 결정**.

- **Skip-level**은 최후 수단.

9. 리모트·하이브리드 팀 문화

9.1 2024~2026 트렌드

- 팬데믹 full-remote → 하이브리드 (2~3일 오피스).

- **RTO (Return To Office)** 강제화 논란.

- **Fully remote** 기업(GitLab·Zapier·Automattic) 여전히 성장.

9.2 Hybrid의 함정

- **Proximity bias**: 오피스 출근자 선호.

- **Info asymmetry**: 복도 대화 정보 독점.

- **Meeting quality 저하**: 하이브리드 화상·오피스 섞임.

9.3 "Async first" 설계

- Documentation 우선.

- Meeting default async (weekly update, decisions log).

- Sync meeting은 "협업·sensitive talk"에만.

9.4 Time zone 정책

- **Core hours**: 2~4시간 overlap.

- **Meeting 시간 공평 순환**: 한 쪽만 새벽 참여 X.

- **TZ 존중 가이드**.

9.5 Offsite 설계

- **분기 1회 또는 연 2회**.

- 2~5일 대면 집중.

- **목적**: 관계·비전·복잡 결정.

- **일정**: half work + half social.

9.6 Onboarding 리모트

- **Buddy 제도**.

- **Virtual coffee**: 10명 이상.

- **Video-first culture**.

- **Async first 90 days doc**.

9.7 Remote 건강

- 운동·햇빛·사회 인터랙션 부족.

- Co-working space 보조금.

- Mental health 지원.

10. 팀 온보딩과 오프보딩

10.1 First 30/60/90

- **Week 1**: 환경·1:1.

- **Day 30**: 첫 PR, 팀 소개.

- **Day 60**: 중간 기여.

- **Day 90**: 독립.

10.2 Buddy 제도

- Day-to-day 질문 답변자.

- 매니저와 별도.

- 2~3주 집중.

10.3 Onboarding doc 구조

- Welcome letter.

- First week checklist.

- People to meet.

- Key projects overview.

- Tool & account list.

10.4 Off-boarding

- **Knowledge transfer**: 문서·pair.

- **Alumni group**: 지속 연결.

- **Exit interview**: 솔직 피드백.

- **Re-employment policy**: boomerang 환영.

10.5 Boomerang

- 떠난 직원 재입사.

- 평균 3~5년 뒤.

- 외부 경험 + 내부 지식 = 높은 가치.

11. 문화의 지표 — 측정 가능한 건강

11.1 정량 지표

- **eNPS (employee NPS)**: 분기별 "추천 의향".

- **Retention rate**: 12개월 유지.

- **Internal mobility**: 팀간 이동 비율.

- **Promotion rate**: 레벨별.

- **Diversity metrics**.

11.2 정성 지표

- **Team health survey**: 5~10 질문, 분기별.

- **Skip-level feedback**.

- **Retro patterns**: 반복 이슈.

11.3 Operational

- **On-call health**: 알림·해결 시간.

- **Meeting load**: 주당 시간.

- **PR cycle time**.

11.4 Leading vs Lagging

- Leading: 설문·참여.

- Lagging: 이탈·채용 실패.

- Leading 먼저 움직임.

11.5 대시보드

- Notion/Confluence 공개.

- 매니저 + 팀 투명.

- 월별 리뷰.

12. 문화를 바꾸는 법

12.1 Dan Pfeffer — "Culture is shaped by behavior"

- 선언이 아닌 **매일 행동**.

- 리더의 가장 작은 습관이 결정.

12.2 Tripwires

- **1주 내** Blameless retro.

- **1분기 내** Psychological Safety 평균 4.0+.

- **6개월 내** 새 ritual 정착.

12.3 Change management

- Why first.

- Pilot → expand.

- Champions.

- Measure → iterate.

12.4 문화 죽이는 것

- **Layoffs with no communication**.

- **Fake values**: poster vs reality.

- **Favoritism**.

- **Rewarding wrong behavior**.

- **Blame culture**.

12.5 문화 자산

- 좋은 문화는 **채용 마그넷**.

- 이직이 적어서 **지식 축적**.

- 오픈소스·컨퍼런스에서 가시적.

체크리스트

1. ☐ 팀 Psychological Safety 설문을 분기별 한다.

2. ☐ Blameless post-mortem 프로세스가 있다.

3. ☐ 주니어가 자주 반대 의견을 낸다.

4. ☐ DX/SPACE 같은 DevEx 설문이 있다.

5. ☐ Retrospective 후 action item이 다음 retro에 리뷰된다.

6. ☐ 코드 리뷰 SLA (예: 24시간)가 지켜진다.

7. ☐ 주요 프로세스가 handbook/wiki에 문서화돼 있다.

8. ☐ 여성·외국인·젊은 멤버의 회의 발언이 관찰된다.

9. ☐ RFC·Design Doc 문화가 있다.

10. ☐ Async first 문서화·meeting 정책.

11. ☐ 분기·연간 offsite가 있다.

12. ☐ eNPS와 retention이 측정·공유된다.

자주 보는 안티패턴 10가지

1. **문화 = 포스터·슬로건**: 실천 없음.

2. **Blameful post-mortem**.

3. **한 명의 스타에 의존**: 이탈 시 팀 붕괴.

4. **Meeting 중독**: Deep work 0.

5. **Documentation 무시**: 구두 의존.

6. **Tokenism**: D&I 숫자만.

7. **모든 갈등 회피**: 건강한 debate 억압.

8. **RTO 강제 without reason**.

9. **Exit interview 형식화**.

10. **지표 없이 "감으로" 문화 평가**.

다음 글 예고 — “시니어 엔지니어를 위한 AI 시대 생존 전략: Junior 대체·Staff 이상의 차별화·도메인 피벗·Lifelong Learning·Human Edge까지”

팀 문화까지 설계했다. 그런데 **AI가 엔지니어를 대체하면?** 이 불안에 대한 솔직한 답.

- Junior 엔지니어 수요 감소 데이터

- AI가 못하는 것 — Human Edge

- Staff 이상의 차별화

- 도메인 피벗 전략

- Lifelong learning 구조화

- 직업·정체성 다변화

- 수입 다각화 — 부업·creator 경제

모든 시리즈의 큰 마무리. 다음 글에서 이어진다.

목차