---
title: "Anthropic Ben Kuhn의 대형 프로젝트 운영법: 위기일수록 빛나는 PM 플레이북"
published: 2026-02-03T22:38:21.000Z
canonical: https://jeff.news/article/383
---
# Anthropic Ben Kuhn의 대형 프로젝트 운영법: 위기일수록 빛나는 PM 플레이북

Anthropic의 Ben Kuhn이 대형/위기 프로젝트 관리 플레이북을 공개함. 집중, 승리 계획, 빠른 OODA 루프, 과잉 소통, 하위 프로젝트 분리의 5가지 원칙과 DRI 스타터 킷(주간 미팅, 워킹 문서, Slack 규범, 회고 등)을 포함함.

- Anthropic에서 가장 생산적이었던 주들은 전부 위기 상황의 프로젝트 관리를 맡았던 때였다고 함
- 복잡한 상호의존성과 빡빡한 일정이 있는 환경에서 뛰어난 프로젝트 관리는 극도로 높은 레버리지를 가짐
- 본인이 특별히 대단한 걸 한 건 아니고 그냥 열심히 하면서 상식적인 일을 했을 뿐인데, 다른 사람들이 이걸 놓치는 경우를 자주 봤다고 함
- 핵심 전제: 기술적 맥락이 충분하고 조직의 신뢰를 받는 사람이 직접 PM을 해야 함. 덜 이해하는 사람에게 실행 관리를 위임하는 건 대부분 가짜 효율임

## Focus: 집중

- 위기 프로젝트 때마다 일정을 완전히 비우고 하루 6시간 이상을 프로젝트 관리에 투입함
- 정보 처리가 공짜 행동처럼 느껴지지만 실제로는 아님. 회의 진행, 업데이트 확인, Slack 스레드 소화, 다음 할 일 고민 등을 합치면 시간이 엄청나게 듦
- 시간 확보보다 더 중요한 건 프로젝트를 머릿속 최우선 주제로 만드는 것임
- 그렇지 않으면 프로젝트가 "자동 조종" 모드에 빠져서 목표 변경, 우선순위 조정 같은 비자명한 판단을 놓치게 됨
- 위기가 아닌 프로젝트에서도 매일 전용 시간을 확보해서 상태 확인, 우선순위 검토, 업데이트 공유를 하면 실행력이 크게 향상됨

## Plan for Victory: 승리를 위한 구체적 계획

- "승리 계획"이란 목표 달성까지의 구체적 단계를 최대한 상세하게 나열한 목록임
- 이게 중요한 이유: 계획 대비 진행 상황이 상황이 얼마나 잘/못 돌아가는지 파악하는 최선의 방법이기 때문
- 상황 파악이 되어야 추가 지원 요청, 스코프 축소, 문제 에스컬레이션 등의 타이밍을 잡을 수 있음
- **대형 프로젝트 실패의 가장 흔한 모드는 충분히 일찍 위기감을 느끼지 못하는 것**이고, 구체적 계획이 이에 대한 최고의 해독제임
- 실제 사례: 새로운 모델 구현체 릴리스 스프린트에서 상세한 작업 목록을 작성함
  - 긍정적 측면: 출시 3개월 전에 일정이 매우 빡빡하다는 걸 알아냈고, 다른 팀에서 인력을 빌릴 수 있었음
  - 부정적 측면: 몇 가지 컴포넌트를 크게 과소평가해서 결국 마지막에 엄청 쪼들렸음
- 계획이 완벽하게 구원해주진 못하지만, 없는 것보다 훨씬 나음. 부족했던 부분은 추정 경험 부족과 계획 대비 점검 빈도가 낮았던 것

## Fast OODA Loop: 빠른 관찰-판단-결정-행동 루프

- OODA = Observe(관찰), Orient(판단), Decide(결정), Act(행동). 새 정보를 바탕으로 계획과 행동을 업데이트하는 프로세스임
- 대부분의 대형 프로젝트는 불완전한 정보가 특징이고, **완전한 정보를 얻는 것 자체가 프로젝트의 어려운 부분**이며 전체 크리티컬 패스의 상당 부분을 차지함

### 트레이닝 런 디버깅 사례

- 칩 납품 → 테스트 수행 → 성능 이상 발견 → 컴퓨팅 파트너에 에스컬레이션 → 대규모 디버깅 → 잘못된 벤치마크를 줬다는 걸 알게 됨 → 벤치마크 교체 → 개선안 배포 → 테스트 → 여전히 부족 → 반복
- 이 단계의 거의 전부가 코딩이 아닌 정보 처리에 관한 것임
- 파트너 측 디버깅 자체도 수십 명 사이의 정보 조율 속도에 제약을 받았음
- 프로젝트 타임라인은 컴퓨팅 파트너의 디버깅 팀 → 그쪽 테크리드 → 본인 → Anthropic 디버깅 팀 사이의 정보 왕복 속도에 강하게 제약됨

### OODA 루프를 빠르게 돌리는 방법

- **시간을 투자할 것**: 위기 모드에서 하루 6시간 이상을 쓰는 주된 이유가 이것
- **불편할 정도로 소통할 것**: 트레이닝 런 디버깅 때 파트너 카운터파트와 하루 두 번 통화(오전 9시, 오후 6시). 모델 구현 프로젝트 때는 여러 디버깅 그룹 사이를 끊임없이 오가며 업데이트를 수집하고 처리함
- **가장 큰 미해결 질문을 추적하고 우선순위를 매길 것**: 대부분의 프로젝트에서 가장 큰 미해결 질문/불확실성의 순위 목록을 살아있는 문서로 유지함. 이 불확실성을 해소하는 게 곧 프로젝트의 우선순위 목록이 됨
- **자주 한 발 물러서서 재정향할 것**: 업데이트 수집 외에 시간을 가장 많이 쓴 건 재정향이었음. 우선순위 목록을 보고 여전히 맞는지 확인하고, 사람들이 최우선 과제를 공략하고 있는지 점검. 하루에도 여러 번 했지만 변경이 필요 없는 경우도 많았음
- 불확실성 여러 개를 병렬로 작업할 수 있으면 속도가 크게 빨라짐. 위기 모드에서 병렬 처리 가능한 인원보다 우선순위가 더 많다면, 그게 바로 인력을 추가 투입할 시점임

## Overcommunicate: 과잉 소통

- 본인만 빠른 OODA 루프를 돌리는 것으로는 부족함. 큰 그룹에서는 모든 사람이 본인을 거치지 않고도 자율적으로 높은 품질의 우선순위 판단을 내려야 함
- 이를 위해 모두가 주변에서 무슨 일이 일어나는지, 자기 목표가 전체 프로젝트에서 어떤 위치인지를 **환경적으로 인식**하고 있어야 함
- 적절한 수준의 환경적 인식을 만들려면 직감적으로 예상하는 것보다 훨씬 더 많이 같은 이야기를 반복해야 함
- Anthropic 첫 팀에서 비동기 일일 스탠드업으로 시작했지만, 동기식 미팅이 공통 지식 형성과 재정향에 훨씬 효과적이어서 주 2회 동기식 스탠드업으로 전환함. 당시 Anthropic 기준으로는 "불편할 정도로 많은" 동기식 소통이었음

## Break Off Subprojects: 하위 프로젝트 분리

- 프로젝트 인원이 약 10명을 넘으면 혼자서 전체를 트래킹하기 어려워지고, 이 시점에서 위임이 필수적임
- 여기서 위임은 **실행이 아닌 프로젝트 관리**의 위임을 의미함. 작업 분배, 진행 모니터링, 블로커 에스컬레이션 등을 함께 해줄 사람이 필요함
- 이상적인 위임 단위는 **명확하고 심플한 고수준 목표**임. 다른 워크스트림과 겹침이 적어야 함
  - 좋은 예: "Y 네트워킹 프로토콜 위에서 X 트레이닝 기법이 Z 처리량으로 동작하게 하기"
  - 나쁜 예: "이 10단계 체크리스트를 따라서 트레이닝이 되길 바라기"
- **최고의 PM은 가장 강한 기술 IC가 아닌 경우가 많음**. 가장 중요한 자질은 고도의 조직력과 최종 목표에 레이저처럼 집중하는 능력이며, 때로는 성가실 정도로
- 서브프로젝트를 맡는 사람도 많은 시간을 PM에 쓰게 되므로 IC 생산성이 상당히 떨어짐. 이건 예상된 것이고 보통 그만한 가치가 있음

> **"Direction is more important than magnitude"** - 잘못된 목표를 향해 빠르게 달리는 것보다, 올바른 것에 집중하는 느린 프로젝트가 대부분 더 나음

- 목표를 심플하게 유지하는 핵심은 깔끔한 재귀적 분해를 가능하게 하는 잠재 구조를 찾는 것임. 이를 위해 의외로 많은 인지적, 실무적 작업이 필요하지만, 무엇이 중요한지를 명확히 해주므로 투자 대비 효과가 큼

## Have Fun: 즐길 것

- Anthropic에서의 가장 좋은 기억 중 일부가 이런 대형 프로젝트를 도운 경험이었다고 함
- 강도가 높지만, 뛰어난 사람들이 모여서 야심 찬 무언가를 함께 만들어가는 느낌은 정말 특별함

## 부록: DRI 스타터 킷

Ben Kuhn이 팀원들에게 공유하는 프로젝트 DRI(Directly Responsible Individual) 실전 가이드의 핵심 내용임.

### 주간 미팅

- 최소 주 1회 30분 미팅을 프로젝트 참여자 전원과 진행
- 목적: (1) 비동기로 안 된 조율의 백스톱, (2) 목표/업데이트의 공통 지식 형성, (3) 진행 상황 트래킹
- 기본 아젠다: DRI의 주간 리뷰 5분 → 사일런트 라이트 & 코멘트 10분 → 동기식 토론 10분
- 미팅을 늘려야 할 신호: 매우 빡빡한 데드라인, 중요한 일에 집중 안 됨, 피드백이 자주 필요, 서로 발을 밟음

### 랜딩 페이지 / 워킹 문서

- 프로젝트의 모든 핵심 정보를 담은 단일 마스터 문서를 유지할 것
- 포함 사항: go/ 링크, 최상위 목표와 상위 목표와의 연결, 참여자 목록과 DRI, Slack 채널 링크, 관련 링크, 로드맵, 러닝 노트(회의록 + 업데이트)
- 중요한 미해결 질문/불확실성/리스크 목록을 유지하면서 시간에 따라 업데이트하면 리스크 제거에 집중하는 데 도움이 됨

### Slack 규범

- 프로젝트 대화는 DM이 아닌 채널에서 할 것. DM은 정보 발견과 공유를 어렵게 만듦
- 10개 이상의 메시지가 달린 스레드(centithread)는 대부분 5분 짜리 페어링 통화가 더 나음
- 불가피하게 긴 스레드가 생기면 아무도 안 읽는다고 가정하고, 채널에 요약을 올릴 것
- 적은 수의 크고, 시끄러운 채널이 나음. 채널이 너무 많으면 멤버십 관리, 대화 위치 결정, 토론 찾기가 다 어려워짐

### 주간 업데이트

- 주 1회, 미팅 직전이나 직후에 넓은 청중을 위한 짧은 업데이트를 작성
- 포함: 전체적인 분위기, 지난주 대비 변화, 다음 계획
- "X 작업을 했음"이 아닌 "Y를 달성함" 또는 "Z를 배움"으로 쓸 것
- 간결하게, 구체적으로, 실행 가능한 내용만. 포괄적일 필요 없음

### 회고

- 주기적으로 "지난 X주가 어떻게 더 나을 수 있었을까?" 질문을 던질 것
- 빈도: 바쁘면 2주마다, 작은 프로젝트는 4~8주마다
- 형식: 비동기 브레인스토밍 13분(잘된 점 / 개선 가능한 점) → 이모지 투표 2분 → 상위 항목 동기식 토론 10분

[원문 보기 (Ben Kuhn)](https://www.benkuhn.net/pjm/)

## 핵심 포인트

- 위기 프로젝트에서 하루 6시간 이상을 PM에 투입해야 하며, 정보 처리는 공짜가 아님
- 구체적인 승리 계획이 있어야 위기감을 제때 느낄 수 있음 - 대형 프로젝트 실패의 가장 흔한 원인이 늦은 경보
- 대부분의 프로젝트 타임라인은 코딩 속도가 아닌 정보 처리 속도에 제약을 받음 (OODA 루프)
- 10명 넘으면 PM 자체를 위임해야 하며, 최고의 PM은 최강 IC가 아닌 경우가 많음
- Direction is more important than magnitude - 올바른 방향의 느린 프로젝트가 잘못된 방향의 빠른 프로젝트보다 나음

## 인사이트

기술 기업에서 PM을 경시하는 경향이 있지만, Anthropic 같은 최전선 AI 기업에서도 프로젝트의 크리티컬 패스가 코딩이 아닌 정보 조율에 있다는 점이 인상적임. DRI 스타터 킷은 특히 실전에 바로 적용 가능한 수준의 구체성을 갖추고 있음.