Chaos and Order

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

들어가며 — "우리도 Netflix처럼 하자"

스타트업 창업자: "Netflix처럼 자유와 책임 문화 만들고 싶어요."

두 달 뒤: "왜 팀이 엉망이 됐죠?"

답: Netflix 문화는 "최고 수준 성과자만"이 있는 전제 위에 세워졌다. Keeper Test(이 사람 떠나면 붙잡을까?)가 작동하려면 모두가 Keeper여야 한다. 신입 포함 시니어 경력자만 뽑는 Netflix의 채용 필터 없이, 문화만 베끼면 재앙이다.

문화는 이식 가능한가? 부분적으로만. 조직 규모, 시장, 인재풀, 제품 성숙도가 다르면 다른 문화가 필요하다.

이 글은:

5대 빅테크의 실제 문화 — Google, Meta, Amazon, Netflix, Apple
한국 빅테크 — 네이버, 카카오, 쿠팡, 토스, 배민
핵심 메커니즘 — 퍼프 리뷰, 코드 리뷰, 미팅 문화, 의사결정
당신 회사에 맞는 문화 고르기 — 규모별 추천

을 비교·분석한다. 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 엔지니어가 중요한 코드를 쓰기 전:

Design Doc 작성 (4~30 페이지)
- 문제 정의
- 목표 / Non-goals
- 아키텍처 대안 비교
- 선택한 해결책 + 이유
- 예상 영향(성능, 비용, 보안)
리뷰어 지정 (보통 Staff+ 엔지니어 2~5명)
피드백 반복 (1~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

신제품 제안 시:

Press Release: 출시일 기준으로 "이 제품이 출시되었습니다" 보도자료 작성
FAQ: 고객/기자가 물을 수 있는 질문과 답
거꾸로 계획: 이 보도자료가 가능하려면 지금 뭘 해야 하나

효과: 고객 가치 먼저, 기술 나중. "기술적으로 쉬운 것"이 아니라 "고객이 원하는 것"에서 시작.

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: 혹독한 비밀 유지 계약, 위반 시 소송

이유:

경쟁 우위: 애플 제품 출시 전 경쟁사가 모름
임팩트: 예측 가능한 발표는 충격 없음
지식재산 보호

단점:

내부 협업 어려움
직원들이 맥락 없이 일할 때 있음
언론 관계 긴장

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항목)

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 (직원 530명)

추천: "Done > Perfect", 모두가 모든 코드 봄, 비공식 커뮤니케이션
피해야: Design Doc 강요, 계층적 퍼프 리뷰
벤치마크: 배민 초기, Stripe 초기

14.2 시리즈BC (30200명)

추천: 팀 분리, 명시적 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: 원본을 읽어라

다음 글 예고 — "세계적 개발자/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대에도 코딩하는 방법

다음 글에서.