들어가며 — "우리도 Netflix처럼 하자"
스타트업 창업자: "Netflix처럼 자유와 책임 문화 만들고 싶어요."
두 달 뒤: "왜 팀이 엉망이 됐죠?"
답: **Netflix 문화는 "최고 수준 성과자만"이 있는 전제 위에 세워졌다.** Keeper Test(이 사람 떠나면 붙잡을까?)가 작동하려면 **모두가 Keeper**여야 한다. 신입 포함 시니어 경력자만 뽑는 Netflix의 채용 필터 없이, 문화만 베끼면 재앙이다.
**문화는 이식 가능한가? 부분적으로만.** 조직 규모, 시장, 인재풀, 제품 성숙도가 다르면 다른 문화가 필요하다.
이 글은:
1. **5대 빅테크의 실제 문화** — Google, Meta, Amazon, Netflix, Apple
2. **한국 빅테크** — 네이버, 카카오, 쿠팡, 토스, 배민
3. **핵심 메커니즘** — 퍼프 리뷰, 코드 리뷰, 미팅 문화, 의사결정
4. **당신 회사에 맞는 문화 고르기** — 규모별 추천
을 비교·분석한다. Season 3 Episode 4. 지난 편 "스케일링 변곡점"에서 "Conway의 법칙"을 이야기했는데, 이번엔 그 반대편 — **문화가 어떻게 조직 구조를 정의하는가**다.
Chapter 1: Google — "Data-driven + Design Doc"
1.1 핵심 키워드
- **TGIF (Thank God It's Friday)**: 매주 금요일 전사 Q&A. 창업자가 직접 답변. (2020년 이후 축소)
- **Design Doc**: 코드 작성 전 반드시 문서 작성, 리뷰어 2~5명
- **Readability**: 특정 언어 코드 리뷰 자격증 제도
- **20% time**: 업무 시간의 20%를 다른 프로젝트에 쓸 수 있음 (Gmail, AdSense 탄생)
1.2 Design Doc 문화
Google 엔지니어가 중요한 코드를 쓰기 전:
1. **Design Doc 작성** (4~30 페이지)
- 문제 정의
- 목표 / Non-goals
- 아키텍처 대안 비교
- 선택한 해결책 + 이유
- 예상 영향(성능, 비용, 보안)
2. **리뷰어 지정** (보통 Staff+ 엔지니어 2~5명)
3. **피드백 반복** (1~4주)
4. **승인 → 코딩 시작**
**장점**:
- 잘못된 방향 조기 발견
- 조직 학습(doc 검색하면 과거 결정 이유 나옴)
- 신입 온보딩 교재
**단점**:
- 느림 (간단한 건 과한 오버헤드)
- 문서 쓰기 능력이 엔지니어링 평가에 큰 영향
1.3 Perf Review의 악명
Google Perf(Performance Review)는 복잡하기로 유명:
- **Self-assessment**: 분기/반기 자신의 기여 문서화
- **Peer review**: 동료 3~7명이 평가
- **Calibration**: 매니저들이 모여 등급 조정(force curve 비슷)
- **Promotion packet**: 승진 지원 시 수십 페이지 문서
**Stack Ranking 논란**: 명시적으론 없지만 사실상 존재. 하위 N% 개선 계획(PIP) 압박.
**2023년 개편**: "GRAD" (Googler Reviews and Development)로 단순화.
1.4 코드 리뷰 문화
- **LGTM (Looks Good To Me)**: 승인 표시
- **Readability 제도**: 특정 언어 LGTM 권한 시험 통과 필요
- **평균 리뷰어 2명** 이상
- **Critique (내부 도구)**: Gerrit 기반, 라인별 코멘트
**데이터** (Google 공개 연구):
- 평균 리뷰어: 1.7명
- 평균 피드백 수: 코멘트 4~5개
- 리뷰 턴어라운드: 중앙값 4시간
1.5 단점
- **의사결정 느림**: Design doc → 리뷰 → 승인 여러 층
- **정치**: Promo-driven development (승진에 유리한 프로젝트만)
- **프로젝트 폐기 악명**: Google Reader, Wave, Stadia... "Google Graveyard"
Chapter 2: Meta(Facebook) — "Move Fast and Break Things"
2.1 핵심 키워드
- **Move Fast**: 원래 "Move fast and break things", 2014년 "Move fast with stable infra"로 수정
- **Bootcamp**: 신입 6주간 여러 팀 체험 후 팀 선택
- **Dogfooding**: 자기 제품 자기가 씀
- **Hackathon**: 분기 1회, 48시간 집중
- **Done is better than perfect** (사무실 포스터)
2.2 Bootcamp의 독특함
일반 회사: 신입이 입사 시 팀 배정.
Meta: **6주 부트캠프 동안 3~5개 팀 프로젝트 체험 후 본인이 팀 선택**.
장점:
- 신입이 실제 경험으로 팀 선택
- 여러 팀과 네트워크 형성
- 채용 후에도 "매칭 미스" 줄임
단점:
- 6주 onboarding 비용
- 인기 팀 편중
2.3 Dogfooding 문화
- 직원은 **Facebook 앱, Instagram, WhatsApp을 일상적으로 사용**
- 내부 신규 기능 먼저 써봄
- Bug report 문화 정착
이게 중요한 이유: 제품 감각은 사용에서 온다.
2.4 Move Fast의 현실
예전: 초당 수만 배포, 파괴적 변경도 일단 배포.
2014년 이후: **"Move fast with stable infra"**. 이유:
- 플랫폼 안정성 (수십억 사용자 영향)
- 규제 대응 (GDPR 등)
- Review board 강화
여전히 **하루 수만 배포**하지만, Gating mechanism 증가.
2.5 Perf Review
**PSC (Performance Summary Cycle)**:
- 반기마다
- 자기/동료/매니저 평가
- 등급: Redefines Expectations / Greatly Exceeds / Exceeds / Meets All / Meets Most / Meets Some
- **Stack ranking 악명**: 하위 10%는 PIP(Performance Improvement Plan)
**2023년 "Efficiency Year"**: 대규모 레이오프. 문화 강경화.
Chapter 3: Amazon — "Two-Pizza + Working Backwards"
3.1 핵심 키워드
- **Leadership Principles (LP)**: 16가지(원래 14가지) 리더십 원칙
- **Two-pizza team**: 피자 2판으로 먹일 수 있는 크기
- **Working Backwards**: 제품 출시 보도자료를 먼저 쓰기
- **6-page narrative memo**: PowerPoint 금지, 6페이지 서술형 문서
- **OP1/OP2**: Operating Plan (연 2회 계획 수립)
3.2 6-page Memo
미팅 시작 30분간 **조용히 6페이지 문서 읽기**. 그 다음 토론.
**왜 PowerPoint 안 쓰는가**:
- 슬라이드는 생각을 단편화
- 발표자 위주, 청중은 수동적
- 화려한 도형 뒤에 부실한 논리 숨김
Bezos: *"The narrative structure of a good memo forces better thought and better understanding."*
**구성**:
- 맥락과 문제
- 데이터와 분석
- 제안과 대안
- 예상 반론과 답변
- Appendix (Raw data)
3.3 Working Backwards
신제품 제안 시:
1. **Press Release**: 출시일 기준으로 "이 제품이 출시되었습니다" 보도자료 작성
2. **FAQ**: 고객/기자가 물을 수 있는 질문과 답
3. **거꾸로 계획**: 이 보도자료가 가능하려면 지금 뭘 해야 하나
**효과**: 고객 가치 먼저, 기술 나중. "기술적으로 쉬운 것"이 아니라 "고객이 원하는 것"에서 시작.
3.4 Two-Pizza Team
Bezos:
> "팀은 피자 2판으로 먹일 수 있어야 한다 (~6-10명)."
근거:
- 소통 경로 = n*(n-1)/2. 10명이면 45경로, 20명이면 190경로.
- 작은 팀 = 빠른 결정, 오너십
- 큰 팀 = 정치, 지연
3.5 Leadership Principles (LP) — 16가지
- Customer Obsession
- Ownership
- Invent and Simplify
- Are Right, A Lot
- Learn and Be Curious
- Hire and Develop the Best
- Insist on the Highest Standards
- Think Big
- Bias for Action
- Frugality
- Earn Trust
- Dive Deep
- Have Backbone; Disagree and Commit
- Deliver Results
- Strive to be Earth's Best Employer (추가)
- Success and Scale Bring Broad Responsibility (추가)
**면접에서 LP 질문**: "Customer Obsession을 보여준 사례를 말해보세요."
**"Disagree and Commit"**: 반대해도 결정되면 전력으로 실행. 의사결정 마비 방지.
3.6 Frugality (검소함)
- 사무실 책상: 문짝으로 만듦 (초기, 지금도 일부)
- 공짜 점심 없음
- 출장 저렴한 항공편
메시지: **돈은 고객 가치에**.
Chapter 4: Netflix — "Freedom and Responsibility"
4.1 핵심 키워드
- **Culture Deck**: 2009년 125페이지 슬라이드, 실리콘밸리 필독서
- **Keeper Test**: 이 사람 떠나면 붙잡을까?
- **Stunning colleagues**: 최고 수준 동료
- **No rules rules**: 휴가 무제한, 경비 정책 없음
- **Informed captain**: 의사결정자 한 명이 책임
4.2 No Rules Rules
**휴가**: 무제한, 승인 불필요
**경비**: "Act in Netflix's best interest"
**드레스 코드**: 없음
**승인 절차**: 없음 (대부분)
**왜 작동하는가**: 모두가 A-player. 성인처럼 대하면 성인처럼 행동.
**왜 작동 안 할 수 있는가**: 신입은 규칙이 필요. 위계 문화에서는 남용.
4.3 Keeper Test
매니저가 정기적으로 자문:
> "만약 이 팀원이 내일 다른 회사로 간다고 하면, 나는 얼마나 열심히 붙잡을까?"
답이 **"많이 붙잡지 않겠다"**면, 해고 + 관대한 퇴직금.
**장점**: 지속적 고성과 유지.
**단점**: 심리적 안전감 부족. 리스크 회피.
4.4 Context, not Control
- 매니저는 **맥락을 제공**, 세세한 지시 X
- 직원은 **정보에 기반해 결정**
- 실수도 용인되지만, 동일한 실수 반복은 용인 X
4.5 Informed Captain
각 결정에는 **한 명의 Informed Captain**이 있다:
- 결정 전 다양한 의견 수집
- 결정은 Captain이
- 그 결정에 대한 책임도 Captain이
**핵심**: 합의(consensus) 피함. Amazon의 "Disagree and Commit"과 비슷.
4.6 Netflix가 되지 못하는 회사
Reed Hastings의 경고:
> "이 문화는 성숙한 회사 + 뛰어난 인재 + 단순한 제품(영상 스트리밍)의 조합에서 작동한다."
스타트업, 제조업, 의료, 금융에는 위험할 수 있음.
Chapter 5: Apple — "Secrecy + Integrated Excellence"
5.1 핵심 키워드
- **Secrecy**: 내부조차 프로젝트 정보 차단
- **DRI (Directly Responsible Individual)**: 모든 일에 단 한 명의 책임자
- **Functional organization**: 부서별 기능 조직 (Engineering, Design, Marketing)
- **Integration**: Hardware + Software + Services 통합 설계
- **Taste**: 엔지니어링 이상의 미적 기준
5.2 비밀주의
- **Project names**: 프로젝트를 코드명으로 지칭
- **Need-to-know basis**: 같은 프로젝트 다른 팀도 정보 격리
- **물리적 분리**: 특정 건물/층 출입 제한
- **NDA**: 혹독한 비밀 유지 계약, 위반 시 소송
이유:
1. **경쟁 우위**: 애플 제품 출시 전 경쟁사가 모름
2. **임팩트**: 예측 가능한 발표는 충격 없음
3. **지식재산 보호**
단점:
- 내부 협업 어려움
- 직원들이 맥락 없이 일할 때 있음
- 언론 관계 긴장
5.3 DRI 문화
모든 문제, 모든 기능, 모든 결정에 **단 한 명의 이름**이 붙는다:
> "이 버튼의 DRI는 누구인가?"
그 한 명이 질문받고, 결정하고, 결과에 책임진다.
**장점**:
- 책임 분산(diffusion) 방지
- 빠른 의사결정
- 품질 주인의식
**단점**:
- 해당자가 병목
- Single point of failure
5.4 Functional Organization
일반 회사: 제품별 사업부 (Product A division, Product B division).
Apple: **기능별 조직** (Hardware engineering, Software engineering, Design, Marketing).
- 한 제품(iPhone)을 각 기능 부서가 협업해 만듦
- 각 부서는 세계 최고 전문가
- Cross-functional 협업은 Steering Committee
**유일한 CEO에 보고하는 구조**: Steve Jobs, Tim Cook이 최종 조율.
**왜 이게 특이한가**:
- 대부분 회사는 규모 커지면 사업부제로 전환
- Apple은 여전히 기능 조직 (Steve Jobs 이후)
- 이유: 통합된 제품 경험 = 통합된 조직
5.5 Taste와 Reject
- Steve Jobs는 수천 아이디어를 "No" 했다고 유명
- "What we don't do defines us"
- 미팅에서 첫 디자인 보고 "쓰레기다" 말해도 놀랍지 않음
대부분 회사의 문제: **너무 많은 것을 만든다**. Apple은 포커스.
Chapter 6: 한국 빅테크 — 네이버, 카카오, 쿠팡, 토스, 배민
6.1 네이버
- **개발 문화**: 일본식 디테일 + 한국식 스피드
- **개발 조직**: NAVER Cloud, Search, AI Lab, etc. 계열사 분리
- **Perf**: 절대평가로 개편 시도(2020년대)
- **강점**: 검색, AI, 클로바X
- **약점**: 글로벌 시장 존재감, 신규 제품 출시 속도
6.2 카카오
- **개발 문화**: 영어 이름 사용, 평어 사용, "애자일" 강조
- **조직**: 크루(Crew) 기반, 평등 지향
- **문제**: 2022년 데이터센터 화재로 드러난 인프라/DR 문제, 이후 문화 개혁 요구
- **강점**: 메신저 생태계, 빠른 실험
- **약점**: 계열사 난립으로 복잡, 내부 정치
6.3 쿠팡
- **개발 문화**: Amazon DNA (Leadership Principles 유사)
- **강한 데이터 드리븐**: 실험, A/B, 수치 중심
- **Working Backwards** 차용
- **강점**: 물류, 데이터, 미국 상장(NYSE)
- **약점**: 혹독한 노동 강도 논란
6.4 토스
- **개발 문화**: "사일로(Silo)" 조직, 제품팀이 기술/디자인/PO 한 팀
- **TMT(Toss Mission Talk)**: 분기별 전사 공유
- **의사결정**: 사일로 리더가 실질적 권한
- **강점**: 제품 완성도, 빠른 출시, UX
- **약점**: 사일로 간 조율, 급성장 속 문화 유지
6.5 배민(우아한형제들)
- **개발 문화**: "송파구에서 일을 잘하는 방법" 포스터 유명
- **잡담, 회의, 주도권**: 구체적 실천 가이드
- **조직**: 제품 중심 조직
- **강점**: 개발자 채용 브랜드, 개발 블로그
- **약점**: DH(Delivery Hero) 인수 후 문화 변화
6.6 한국 빅테크 공통 특성
- **야근 문화 개선 중**: 주 52시간제 정착, 많이 나아짐
- **영어 사용**: 토스, 쿠팡은 영어 의사소통 보편
- **개발 블로그**: 브랜딩 수단으로 활발
- **주니어 친화적**: 신입 공채 + 자체 부트캠프(우테코, SSAFY)
- **이직 주기**: 2-3년이 보통, 빅테크 ↔ 스타트업 이동 활발
Chapter 7: 퍼프 리뷰 구조 비교
7.1 주기별
| 회사 | 주기 | 특징 |
|------|------|------|
| Google | 반기 | GRAD (간소화) |
| Meta | 반기 | PSC, Stack ranking |
| Amazon | 연 1회 (OLR) | Forced distribution |
| Netflix | 연 1회 | Continuous feedback 지향 |
| Apple | 연 1회 | 매니저 재량 큼 |
| 네이버/카카오 | 반기 | 절대+상대 혼합 |
| 쿠팡 | 반기 | Amazon 유사 |
| 토스 | 연 1회 | 사일로 리더 평가 |
7.2 등급 체계
- **Google**: Not Enough Impact / Significant Impact / Outstanding / Transformative
- **Meta**: Greatly Exceeds / Exceeds / Meets All / Meets Most / Meets Some
- **Amazon**: Top Tier / Highly Valued / Least Effective (URA — Unregretted Attrition Rate 목표치)
7.3 Stack Ranking의 그림자
Microsoft는 **2013년에 Stack Ranking 폐지**. 이유:
- 내부 경쟁 과열
- 협업 저해
- 팀 단위 저성과자 이동
여전히 많은 회사가 변형된 Stack Ranking 사용. **"필요악"인지 "해악"인지 논쟁 지속**.
Chapter 8: 코드 리뷰 문화 비교
8.1 리뷰어 수
- **Google**: 1~5명 (평균 1.7명, Readability 필요)
- **Meta**: 2~3명 (Phabricator 사용)
- **Amazon**: 1~2명 (CR 필수)
- **Netflix**: 자율적, 경우에 따라
- **Apple**: 비공개, 기능팀 내부
8.2 리뷰 스타일
- **Google**: 엄격, Readability 강조, 스타일 일관성 > 개인 취향
- **Meta**: 실용적, 빠른 배포 우선
- **Amazon**: "Are you sure?" 질문 중심, Dive Deep
- **한국**: 회사별 편차 큼. 토스는 까다로움, 배민은 실용적.
8.3 자동화 레벨
- **Google**: 사내 도구(Critique, Tricorder), 수백 개 linter
- **Meta**: Phabricator, Sapling(VCS), Infer(정적 분석)
- **Amazon**: Code Guru(자체), 파이프라인 내 수많은 게이트
- **일반적 스타트업**: GitHub + Actions + ESLint/Prettier
Chapter 9: 미팅과 커뮤니케이션 비교
9.1 미팅 문화
- **Amazon**: 6-page memo + 30분 독서 + 토론 — 문서 중심
- **Google**: Slides + Q&A — 발표 중심
- **Meta**: 짧은 standup + Workplace(내부 Facebook) 글 — 비동기 + 짧게
- **Netflix**: 작은 그룹 미팅, "Memo culture" 도입 중 — 적게
- **Apple**: DRI 중심, 작게 — 수직 보고
9.2 비동기 vs 동기
| 회사 | 경향 |
|------|------|
| Amazon | 문서 중심(비동기 가능) |
| Google | 혼합 |
| Meta | 동기 + Workplace 포스트 |
| Netflix | 작은 동기 + 메모 |
| GitHub/Automattic | 완전 비동기(거의 사라진 미팅) |
| 한국 | 대체로 동기(화상/대면) |
9.3 1-on-1
공통: **주 1회, 30분~1시간**.
- Google: 성장 코칭, 분기 OKR 점검
- Amazon: 결과 중심, 장애물 제거
- Netflix: Context 교환
- 토스: Pair PO/디자이너/개발자 구조에서 자주
Chapter 10: 채용 필터 비교
10.1 Google
- 4~6라운드 면접 (기술 + 리더십)
- Coding interview: 알고리즘 강함
- Hiring committee가 최종 결정 (채용 매니저 ≠ 결정권자)
- Level: L3 (신입) ~ L10 (VP)
10.2 Meta
- Coding 2라운드 + System design + Behavioral
- 피드백 이메일 직접 제공 (요청 시)
- Level: E3 ~ E9
10.3 Amazon
- "Bar Raiser": 외부 팀 면접관 포함 (편향 제거)
- LP 질문 집중
- 온사이트 5~6라운드
10.4 Netflix
- 시니어만 뽑음 (초기 경력 거의 없음)
- Culture fit 강조
- "Keeper test" 전제의 채용
- 연봉: 업계 최고 수준(Top of Market)
10.5 Apple
- 팀 특화 면접, 공통 과정 적음
- 비공식 Bar Raiser 느낌
- Secrecy 테스트: 면접 중에도 프로젝트 정보 공개 X
10.6 한국 빅테크
- 네이버/카카오: 코딩 테스트 + 2~4차 면접
- 쿠팡: Amazon 유사 (LP 기반)
- 토스: TMT(Toss Mission Talk) 겸 컬처 인터뷰
- 배민: 코딩 + 인성 + 컬처
Chapter 11: 문화 실패 사례
11.1 Uber의 독성 문화(2017)
**문제**:
- 공격적 성장 우선
- 내부 성희롱 은폐
- 창업자 Travis Kalanick의 행동
- "Hustle" 문화의 극단
**결과**: 창업자 사임, Susan Fowler의 블로그가 촉발.
**교훈**: 문화 결함은 결국 외부로 드러난다.
11.2 Zappos의 Holacracy 실험
Tony Hsieh는 2015년 **Holacracy**(매니저 없는 구조) 도입:
- 매니저 제거, 원형 조직
- 결과: 14% 직원 퇴사
- 완전 실패는 아니지만 확산되지 못함
**교훈**: 모든 조직에 맞는 문화는 없다.
11.3 Basecamp의 2021 정치 논쟁
Basecamp: 직장 내 정치/사회 이슈 토론 금지 선언 → **37% 직원 퇴사**.
**교훈**: 문화 변경은 기존 직원에게 신뢰 파괴.
Chapter 12: 문화 체크리스트 (12항목)
- [ ] **의사결정 속도**: 설계 문서 평균 승인 시간(주)
- [ ] **회의 시간 비율**: 엔지니어 기준 주당 회의 시간 %
- [ ] **배포 빈도**: 하루 몇 번 배포하는가
- [ ] **리뷰 턴어라운드**: PR 평균 머지 시간(시간)
- [ ] **온콜 부담**: 페이징 주당 회수, 야간 비율
- [ ] **심리적 안전감**: "실수를 말할 수 있다" 설문 점수
- [ ] **1-on-1 실행률**: 스킵률 %
- [ ] **Perf 투명성**: 평가 기준이 명문화됐는가
- [ ] **승진 사다리**: Staff/Principal 레벨 공개 정의
- [ ] **이직/유지 균형**: eNPS, voluntary attrition
- [ ] **비동기 문서 비율**: Slack 대비 Notion/Confluence
- [ ] **신입 온보딩**: 첫 PR까지 걸리는 시간
Chapter 13: 10가지 문화 안티패턴
1) Cargo-culting
Netflix 문화를 신생 스타트업이 복사. 전제 조건(시니어만, 단순 제품) 무시.
2) 문화 포스터 = 문화라는 착각
벽에 "Be yourself"만 붙이고 실천 없음. 문화는 **매니저의 매일의 결정**.
3) Founder-dependent Culture
창업자 있어야 유지되는 문화. 창업자 떠나면 붕괴. → 문화 의식화 필요.
4) "우린 가족" 슬로건
해고 시 충격. 가족은 해고 안 한다. **"프로 스포츠팀"**이 정직.
5) Stack Ranking 없이 Top Performer만 원하기
하위 개선 장치 없이 최고만 모이길 기대. 현실적 관리 불가.
6) 모든 것을 합의로
Consensus 환상. 빠른 결정 불가. **Disagree and Commit**.
7) 익명 설문 없음
진짜 이야기 못 들음. 리더 귀가 막힘. **eNPS + 익명 설문**.
8) Perf Review가 유일한 피드백
반기에만 피드백. 평상시엔 침묵. **Continuous feedback** 필요.
9) 회의만 있고 문서 없음
결정이 사라짐. 같은 논의 반복. **Design doc 문화** 도입.
10) "Hustle" 숭배
72시간 근무 영웅화. 단기엔 가능, 장기엔 번아웃/이직. **지속가능성**.
Chapter 14: 당신 회사에 맞는 문화 — 규모별 추천
14.1 시드~시리즈A (직원 5~30명)
- **추천**: "Done > Perfect", 모두가 모든 코드 봄, 비공식 커뮤니케이션
- **피해야**: Design Doc 강요, 계층적 퍼프 리뷰
- **벤치마크**: 배민 초기, Stripe 초기
14.2 시리즈B~C (30~200명)
- **추천**: 팀 분리, 명시적 1-on-1, 간단한 Perf(연 1회), 비동기 메모
- **피해야**: Stack Ranking, Microservices 강행
- **벤치마크**: Shopify 중반, 토스 중반
14.3 성숙기 (200~2000명)
- **추천**: Level ladder 공개, Promo 제도, Design Doc 필수, SRE 문화
- **피해야**: 규모 대비 의사결정 지나친 집중, Founder-bottleneck
- **벤치마크**: Notion, Figma
14.4 빅테크 (2000명+)
- **선택**:
- Google식(Data-driven, Doc)
- Amazon식(LP, Frugal)
- Netflix식(High-talent density) — 단, 채용 필터 전제
- **공통**: 매우 명시적인 프로세스, 강한 Culture statement
- **위험**: 관료화, 혁신 속도 저하
마치며 — 문화는 전략을 아침으로 먹는다
Peter Drucker의 유명한 말:
> "Culture eats strategy for breakfast."
**전략보다 문화가 중요하다**는 뜻이다. 아무리 좋은 전략도 문화가 실행을 막으면 실패한다.
원칙 1: 문화는 선언이 아니라 행동
"우린 Customer Obsessed다"라고 10번 말하는 것보다 **이번 분기에 고객 NPS 20% 올리기 위해 기능을 미루는 결정** 한 번이 더 강력하다.
원칙 2: 채용이 문화의 90%
나머지 10%는 지속적 관리. 잘못 뽑으면 교정 불가능.
원칙 3: 문화는 이식 가능하지 않다
맥락을 이해하고 부분만 가져오라. Amazon의 6-page memo는 가능, Netflix의 Keeper Test는 위험.
원칙 4: 문화는 진화한다
스타트업과 대기업은 다른 문화가 필요. 정체성은 유지하되 형태는 변해야.
원칙 5: 원본을 읽어라
- [Netflix Culture Deck (2009)](https://www.slideshare.net/reed2001/culture-1798664)
- [No Rules Rules - Reed Hastings](https://www.nytimes.com/2020/09/08/business/netflix-culture-reed-hastings.html)
- [Amazon Leadership Principles](https://www.amazon.jobs/en/principles)
- [Working Backwards - Colin Bryar & Bill Carr](https://www.workingbackwards.com/)
- [How Google Works - Eric Schmidt, Jonathan Rosenberg](https://www.howgoogleworks.net/)
- [우아한형제들: 송파구에서 일을 잘하는 방법](https://woowabros.github.io/)
다음 글 예고 — "세계적 개발자/CTO가 되는 길: 시니어에서 Staff, Principal, 그리고 VP까지"
Season 3 Ep 5는:
- Senior Engineer의 플래토우
- Staff+ 엔지니어는 무엇이 다른가
- Principal Engineer의 일상
- IC(Individual Contributor) 트랙 vs Manager 트랙
- CTO가 되기까지의 경로
- 유명 CTO/엔지니어의 경력 분석 (Jeff Dean, Sarah Drasner, Kelsey Hightower)
- 한국의 시니어 개발자 커리어 현실
- 이직, 컨설팅, 창업의 분기점
- 40대, 50대에도 코딩하는 방법
다음 글에서.
현재 단락 (1/367)
스타트업 창업자: "Netflix처럼 자유와 책임 문화 만들고 싶어요."