Anthropic Ben Kuhn의 대형 프로젝트 운영법: 위기일수록 빛나는 PM 플레이북

• 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)