Anthropic은 연구실의 교훈을 제품 개발에 어떻게 적용하는가

URL: https://www.youtube.com/watch?v=qqrk7CtkuIw
날짜: 2026-08-28
원본 발행일: 2026-08-27
채널: aiDotEngineer
출연: Mike Krieger — Instagram 공동 창업자, Anthropic Labs 기술 스태프

---

📌 핵심 질문 / 이 대화가 다루는 핵심 논점

==AI 시대의 가장 큰 변화는 사람이 코드를 한 줄씩 작성하는 속도가 아니라, 목표를 설명하고 모델이 자율적으로 탐색·검증하도록 맡기는 방식으로 일의 단위를 바꾸는 데 있다.==

• Mike Krieger는 Anthropic의 최고제품책임자(Chief Product Officer, CPO)에서 개인 기여자(Individual Contributor, IC)로 이동하며 모델을 직접 만드는 일에 뛰어들었다.
• Labs는 2주마다 프로젝트를 지속할지, 방향을 틀지, 종료할지 결정하면서 조직을 고정된 프로젝트별 계층이 아니라 유연한 베팅(bet) 중심 구조로 운영한다.
• 빠른 모델과 에이전트(Agent)가 개발을 가속해도 인간의 의도·트레이드오프(trade-off)를 이해하는 능력, 도메인 지식, 사용자 이해, 건강한 팀 문화는 여전히 병목이자 경쟁력이다.

Mike Krieger의 사례는 “작은 작업을 부탁하는 도구”에서 “목표와 책임을 맡길 수 있는 동료”로 AI를 재정의한다. Python 코드를 TypeScript로 주말 동안 포팅한 사례, Slack에서 Claude를 태그해 코드베이스의 책임을 맡긴 사례, 코드 리뷰를 코드 자체가 아닌 의도와 결과로 재구성한 사례가 모두 같은 방향을 가리킨다. 동시에 모델을 무제한 자유형으로 풀어놓는 것이 답은 아니며, 금융처럼 감사 가능성(auditability)과 데이터 출처(provenance)가 중요한 영역에서는 검증 가능한 기반과 에이전트의 유연성을 함께 설계해야 한다.

1. CPO에서 Labs의 개인 기여자로 이동한 이유

모델의 능력이 커질수록 제품을 지시하고 검토하는 것만으로는 직접 만드는 사람들의 경험을 따라갈 수 없었다.

1.1. 역할 전환과 FOMO

1. 제품 책임자에서 직접 제작자로 이동

   1. 첫 2년의 역할: Mike Krieger는 Anthropic에 합류한 뒤 처음 2년 동안 최고제품책임자(CPO)로 일했다.
   2. 간접 사용의 한계: 제품 전략 문서를 작성하고 Claude에게 비평(critique)을 요청하거나 워크플로를 조합할 수는 있었지만, 그것은 모델과 순수하게 함께 구축하는 경험과 달랐다.

2. 모델을 직접 쓰고 싶은 FOMO

   1. 주말의 실험: 주변 사람들이 모델로 무언가를 만드는 모습을 계속 보면서 놓치는 것에 대한 두려움(FOMO)이 커졌고, 주말마다 직접 구축을 시도했다.
   2. 결정의 순간: “지금은 너무 흥미로운 시대이므로 역할을 바꿔야 한다”는 결론에 도달했고, CPO 역할에서 Labs의 IC 역할로 옮겼다.

3. 고위 리더의 IC 전환이라는 흐름

   1. 관찰된 이동: 다른 회사에서 최고기술책임자(Chief Technology Officer, CTO)를 지냈던 사람들이 Anthropic이나 다른 AI 회사에 IC로 합류하는 사례가 여러 번 나타났다.
   2. 공통된 동기: 관리와 전략만으로는 모델을 실제로 활용해 만들어지는 가능성을 충분히 경험하기 어렵기 때문에, 직접 손을 움직이는 역할로 돌아가려는 욕구가 생겼다.

1.2. 작업 분해에서 목표 중심 위임으로

1. 전통적 엔지니어링 사고

   1. 아이디어의 세분화: 아이디어가 떠오르면 머릿속에서 평소의 엔지니어링 방식대로 쪼개고, 어떤 순서로 여러 단계를 실행할지 먼저 정한다.
   2. 작업 단위의 통제: 사람은 각각의 태스크(task)를 직접 정의하고 단계별 결과를 확인하는 방식에 익숙하다.

2. 새로운 목표 중심 패러다임

   1. 최종 상태를 설명: 달성하려는 목표와 원하는 상태를 설명한 뒤 모델이 그 목표를 향해 작업하게 한다.
   2. 결과와 트레이드오프를 대화: 모델이 작업 중 드러낸 질문과 선택지를 대화로 다루고, 최종적으로 어디에 도달했는지와 다음에 무엇을 할지 판단한다.

3. 모델에게 설명을 되돌려 받는 경험

   1. 모델의 속도와 지능: 새 모델이나 기능이 공개된 지 며칠밖에 되지 않은 시점에도 모델은 Mike보다 훨씬 똑똑하게 느껴지는 결과를 낸다.
   2. 인지 부하의 역전: 모델이 “내가 감수한 절충안은 이것”이라고 설명하면, Mike는 자신이 이해력이 부족한 사람인 것처럼 더 쉽게 풀어 달라고 요청한다.
   3. 핵심 변화: 단순히 일을 넘기는 것이 아니라 최종 상태를 명시하고 모델이 요리하듯 숙성시킨 결과를 함께 검토하는 방식으로 바뀌었다.

2. “더 무리한 요구를 하라”는 AI 활용 원칙

AI 제품 사용자는 아직도 초기 도구의 제약을 내면화해 작은 일을 부탁하지만, 실제 도구가 제공하는 실행 권한은 그보다 훨씬 넓다.

2.1. 불합리할 만큼 야심찬 요구를 가르치기

1. 비기술 사용자에게도 Claude를 맡기기

   1. 내부 제품의 불편: Labs의 내부 제품을 쓰던 비기술 직원이 원하는 방식으로 작동하지 않는다고 말했다.
   2. 기존 반응과 다른 선택: Mike는 직접 수정 방법을 설명하는 대신 “왜 Claude에게 바꿔 달라고 하지 않느냐”고 되물었다.
   3. 제품팀의 교육 과제: 산업과 제품팀은 사용자에게 AI를 작게 사용하는 법이 아니라, 더 무리하고 야심찬 요구를 해도 된다는 감각을 가르쳐야 한다.

2. 초기 AI 제품의 상자(box) 문제

   1. 도구 접근 제한: 1세대 AI 제품은 모델을 제한된 인터페이스 안에 가두고 도구 접근과 자유도(degrees of freedom)를 지나치게 줄였다.
   2. 야심을 막는 응답: 사용자가 “이 일을 해 달라”고 해도 모델은 코드를 쓸 수는 있지만 실행할 수 없거나, 환경을 볼 수는 있지만 실제로 조작할 수 없다고 답하는 경우가 많았다.

3. Co-work와 가상 머신의 역설

   1. 표면적으로 과한 기능: 모든 지식 노동자(knowledge worker)에게 Bash를 실행할 수 있는 가상 머신(virtual machine)이 필요한 것은 아니다.
   2. 실행 권한의 가치: 내장 PDF 파서가 파일을 해석하지 못하면 모델이 직접 스크립트를 작성해 다른 방식으로 파싱할 수 있다.
   3. 자유도가 만드는 복원력: 모델이 한 내장 기능의 실패에서 멈추지 않고 주변 도구를 조합해 문제를 복구하는 능력이 더 큰 사용 사례를 연다.

2.2. Python에서 TypeScript로 주말 포팅

1. 가장 무리한 실험

   1. 애착이 있는 Python 프로젝트: Mike가 Labs에서 만든 프로젝트는 Python으로 작성되었고, Instagram 전체가 Python으로 만들어졌던 경험과도 연결되어 있었다.
   2. 배포상의 이유: Claude Code가 Bun을 이용한 더 나은 배포 방식을 찾아냈기 때문에 프로젝트 전체를 TypeScript로 포팅(porting)할 유인이 생겼다.

2. 전통적 판단이라면 어리석은 계획

   1. 규모: 포팅 대상은 수십만 줄이 아니라 “수십만 줄에 가까운 수백 천 줄(hundred-thousands of lines)” 규모로 표현될 만큼 큰 Python 코드베이스였다.
   2. 기존 엔지니어링 관점: 2010년대나 2020년대 초의 엔지니어링 감각으로는 이 작업을 주말에 통째로 시도하는 것은 무모하고 어리석은 계획이다.

3. 동적 워크플로로 실현

   1. 자율 반복: Mike는 동적 워크플로 설정을 만들고 모델에게 전체 코드를 TypeScript로 옮기게 했다.
   2. 검증 루프: 모델은 포팅, 작동 확인, 재확인, 양쪽 코드 읽기, 문제 수정과 반복을 계속 수행했다.
   3. 월요일의 상태: 주말이 끝난 월요일에 배포 가능한 포팅 버전의 완성된 워크플로가 남았다.
   4. 핵심 교훈: “전체 Python 코드베이스를 TypeScript로 옮기고 작동·배포 가능하게 만들어라”는 예전에는 불합리했던 요구가 이제는 실행 가능한 요구가 되었다.

2.3. 코드 변환에서 생산 데이터와 점진성을 쓰는 법

1. Instagram의 Python 3 전환 경험

   1. 타입 힌트(type hints): Python 3에서 처음 타입 힌트를 추가할 수 있게 되자 내부에서는 Python이 곧 한계에 다다를지 논의했다.
   2. 더 멀리 갈 수 있다는 판단: Mike는 Python으로 생각보다 훨씬 더 멀리 갈 수 있으며, 타입이 팀이 스스로 만든 혼란에 빠지는 일을 줄여 줄 것이라고 봤다.

2. MonkeyType의 역할

   1. 실행 중인 타입 수집: MonkeyType은 프로덕션에서 실제로 사용된 런타임 타입(runtime type)을 수집했다.
   2. 코드베이스 반영: 수집한 타입을 코드베이스의 해당 코드에 되돌려 매핑해 정적 정보로 활용했다.
   3. LLM 변환에 주는 시사점: LLM을 이용한 변환이나 크로스 컴파일(cross-compiling)에서는 생산 환경의 실제 데이터를 변환 기준으로 더 많이 활용할 수 있다.

3. 한 번에 바꾸지 않는 경계 설정

   1. 세그먼트 테스트: 전체를 한꺼번에 바꾸기보다 구간별 테스트(segmented tests)와 실제 사용 데이터를 이용해 안전하게 이동할 수 있다.
   2. 점진성의 시작점: 가장 어려운 판단은 어디에서부터 점진적으로 변환을 시작할지 정하는 것이다.
   3. 바다를 통째로 끓이지 않기: 모든 것을 하룻밤에 바꾸려 하지 말고, 생산 데이터와 사용자 검증을 보면서 경계를 나눠야 한다.

3. 확장 가능한 시스템은 측정·조절·사용자 검증에서 시작한다

AI 시스템도 Instagram의 초기 확장 경험처럼, 장애가 난 뒤에야 관측과 제어 장치를 추가하면 대응이 늦어진다.

3.1. Instagram의 첫 주와 인프라 점심

1. 출시 첫 주의 장애

   1. 백엔드 붕괴: Instagram을 출시한 첫 주에 팀은 백엔드에서 무엇을 하고 있는지 충분히 알지 못해 시스템 전체가 녹아내리는 경험을 했다.
   2. 우연한 기회: 그 주에 투자자가 팀을 위한 행사가 아니라 단순한 인프라 점심 모임을 마련했다.
   3. 문제 해결 세션으로 전환: 팀은 그 대화를 사실상 독점했고, 참석자들은 확장 문제를 고칠 방법에 대해 각자의 의견을 내놓았다.

2. 사용자가 최종 테스트라는 관점

   1. 예측 불가능한 용도: 처음부터 사용자가 무엇을 위해 기능을 쓸지 모두 알 수 없을 때가 있다.
   2. 롤아웃의 가치: 실험과 롤아웃(rollout) 인프라를 먼저 갖추면 예상하지 못한 사용 방식도 안전하게 시험할 수 있다.

3.2. 2010년에 얻은 두 가지 운영 원칙

1. 필요할 수 있는 모든 것을 미리 측정하기

   1. 선행 계측(pre-measurement): 언젠가 필요할 가능성이 조금이라도 있는 지표는 장애가 나기 전에 미리 측정한다.
   2. 장애 중 판단 가능성: 장애가 발생했을 때 “이 숫자가 정상인가, 높은가”를 알 수 있어야 하며, 그때 막 추가한 지표로는 비교 기준을 세울 수 없다.

2. 노브(knob)와 기능 플래그(feature flag)를 일급 시민으로 만들기

   1. 점진적 램프와 롤아웃: 초기 Instagram은 단순하지만 효과적인 램프 아웃(ramp-out)과 롤아웃 방식을 갖고 있었다.
   2. 동적 구성(dynamic configuration): 부하에 대응하려면 많은 런타임 설정을 몇 초 안에 바꿀 수 있어야 했다.
   3. AI에의 적용: AI 시스템도 모델 품질·비용·속도·안전성 사이에서 계속 트레이드오프를 바꾸므로 런타임 구성 기능이 핵심이다.

3. 자기 자신을 이메일로 DDoS한 출시일

   1. 유명한 확장 일화: 인터뷰어가 Instagram이 출시 당일 이메일 때문에 스스로를 DDoS(distributed denial-of-service)한 이야기를 가장 좋아하는 확장 사례로 언급했다.
   2. 웃음 뒤의 교훈: Mike는 그 이야기를 확인했고, 아직 모르는 사람은 찾아보라고 권했다.

4. 태그 기반 멀티플레이어 위임과 인간 주도 코드 리뷰

Anthropic 내부의 중심 작업 방식은 개인 CLI에서 모델을 직접 조작하는 것보다, 여러 사람이 모델을 호출하고 맥락을 공유하며 비동기적으로 책임을 맡기는 쪽으로 이동했다.

4.1. 태그와 코드 작성의 다이내믹함

1. 코드의 60% 이상을 만드는 변화

   1. 주요 전환: 태그(tag) 기반 작업 방식은 현재 작성되는 코드의 60% 이상과 연결될 정도로 큰 변화로 소개되었다.
   2. 3000개의 플래그와 공존: 하나의 앱을 배포하되 약 3,000개의 기능 플래그로 인구집단별 기능을 다르게 제공하는 것처럼, 결과물은 정적이지 않고 동적으로 조합된다.

2. Claude Code와 태그의 역할 분리

   1. 대화형 작업: 특정 기능을 세밀하게 반복하고 높은 대역폭의 앞뒤 대화를 원할 때는 Claude Code를 사용한다.
   2. 대부분의 내부 사용: 대부분의 사용은 태그를 통한 위임으로 이루어지며, 개별 사용자가 자기 CLI만 붙잡고 있는 방식보다 비동기적이다.

4.2. 태그가 만드는 멀티플레이어 학습

1. Midjourney와 Discord의 비유

   1. 다른 사람의 사용법을 보는 효과: Discord에서 모두가 Midjourney를 쓰는 모습을 보며 새로운 사용법을 발견했던 경험과 태그 방식이 닮았다.
   2. 야심의 전염: 다른 사람이 모델에게 큰 범위의 책임을 맡기는 모습을 보면 자신도 처음부터 작은 요청만 할 필요가 없다는 사실을 깨닫는다.

2. 버그 수정에서 코드베이스 책임으로

   1. 좁은 요청: “이 버그를 고쳐라”는 기존의 단일 작업 위임이다.
   2. 넓은 책임: 모델에게 코드베이스의 특정 영역을 맡기고, 피드백 채널을 모니터링하며, 과제를 선제적으로 찾고 수정하게 할 수 있다.
   3. 변화 대응: 담당 영역의 API가 바뀌면 그 변경까지 알아서 반영하도록 책임 범위를 정의할 수 있다.

3. Claude를 동료로 대하는 단계

   1. 낮은 활용의 자각: Mike는 자신이 Claude를 Slack 안의 조금 더 좋은 Claude Code처럼만 쓰고 있었다는 사실을 깨달았다.
   2. 동료의 조건: 더 발전한 모델은 맥락(context)을 보유하고, 메모리(memory)를 유지하며, 사람의 새 지시를 기다리지 않고 선제적으로 행동하는 팀원이 된다.
   3. 운영 방식의 변화: Anthropic 내부 업무는 각자 CLI를 소유하는 방식에서 멀티플레이어(multiplayer)·비동기(async)·선제적(proactive) 협업으로 이동했다.

4.3. 코드 리뷰의 병목은 시간보다 이해다

1. 아키텍처를 건드리는 변경의 검토

   1. 여전히 존재하는 병목: AI가 코드를 빠르게 생성해도 아키텍처 조각을 건드리는 변경은 여전히 코드 리뷰(code review)에 막힌다.
   2. 시간 배분만의 문제가 아님: 리뷰 시간을 더 확보한다고 해결되는 문제가 아니라, 사람이 변경의 전체 개념을 머릿속에 담을 수 있는지가 더 근본적인 제약이다.

2. 2,000줄 PR과 아티팩트

   1. 기존 경험: 2,000줄짜리 풀 리퀘스트(pull request, PR)를 받으면 리뷰어는 “이건 그냥 코드처럼 보인다”고 느끼기 쉽다.
   2. Claude Code 아티팩트: 최근 출시한 Claude Code 아티팩트는 코드와 함께 변경의 설명, 의도, 감수한 트레이드오프를 전달하는 방식을 지원한다.
   3. 새로운 의사소통 단위: 코드는 도구와 테스트로 검증하되, 사람이 논의할 대상은 의도와 선택의 결과, 프로덕션에서 측정되는 변화가 된다.

3. Claude가 돕고 사람이 결정하는 리뷰

   1. 모든 줄을 읽지 않음: Mike는 모든 PR의 모든 줄을 검토한다고 말할 수 없으며, 실제로 그렇게 하지 않는다.
   2. 질문 중심 조사: 코드에 대해 Claude와 대화하며 “내가 가질 법한 질문은 이것”이라고 전달하고, Claude에게 해당 부분을 조사하게 한다.
   3. 중요도에 따른 사람의 개입: 결과는 Claude가 보조하는 코드 리뷰이지만 사람 중심으로 진행되며, 중요한 변경은 인간이 판단한다.
   4. 시각적 변경의 예외: 장식적·시각적인 변경은 필요하면 나중에 고치는(fix forward) 접근을 취할 수 있다.

5. 2주 주기의 Labs와 프로젝트보다 오래가는 조직

빠르게 사라지는 프로젝트를 조직도에 고정하지 않고, 사람을 지속적으로 지원하는 관리 구조와 실험 단위를 분리하면 방향 전환 비용을 낮출 수 있다.

5.1. 엔지니어링 매니저의 역할은 사라지지 않았다

1. 관리자 규율의 과장된 죽음

   1. 코칭의 지속성: 엔지니어링 매니저(engineering manager)라는 규율이 사라졌다는 주장은 크게 과장되었다.
   2. 사람을 지원하는 일: 코칭(coaching), 대인관계(interpersonal) 조율, 개인의 성장과 발전은 Labs 같은 조직에서도 여전히 중요하다.

2. 프로젝트 리더와 사람 관리의 분리

   1. 베팅 리더: 각 실험에는 베팅 리드(bet lead) 또는 직접 책임자(Directly Responsible Individual, DRI)가 있다.
   2. 관리 권한의 비결합: 베팅 리드는 보통 다른 참여자를 직접 관리하지 않는다.
   3. 매니저의 초점: 엔지니어링 매니저는 개별 구성원이 가장 흥미를 느끼고 가장 잘 일할 수 있는 베팅에 배치되도록 돕는다.

5.2. “Persevere or Pivot”의 2주 리듬

1. 모든 프로젝트가 정기 심사를 받는다

   1. 주기: Labs는 2주마다 모든 프로젝트를 올려 지속(persevere)할지, 방향을 전환(pivot)할지 검토한다.
   2. 종료도 정상적인 선택: 필요하다면 프로젝트를 종료(shut down)하며, 실제로 거의 모든 주기에서 프로젝트가 종료되었다.

2. 종료는 실패가 아니라 설계다

   1. 프로토타입 목적: Labs의 목적은 빠르게 프로토타입을 만들고, 내부에 출시하고, 가능하면 얼리 액세스(early access)까지 보내 보는 것이다.
   2. 작동하지 않을 때: 초기 가설이 작동하지 않으면 프로젝트를 정리하는 것이 본래 설계된 경로다.
   3. 감정의 재해석: 반복할수록 “내 프로젝트가 종료됐으니 내가 실패했다”가 아니라 “Labs가 검증을 마치고 다음 베팅으로 이동했다”는 식으로 받아들이기 쉬워진다.

3. 조직도를 프로젝트에 맞추지 않는 이유

   1. 2주마다 재조직되는 악몽: 조직도를 개별 프로젝트와 강하게 결합하면 프로젝트가 바뀔 때마다 2주 간격으로 조직을 다시 짜야 한다.
   2. 유연한 팟(pod): 하나의 베팅은 제품 담당자, 엔지니어링 담당자, 특정 제품에 관심 있는 Mike 같은 사람을 필요에 따라 끌어모은다.
   3. 해산의 낮은 비용: 베팅이 작동하지 않으면 팟을 해산하고 구성원을 다음 관심 영역으로 보내면 되므로 큰 조직적 사건이 되지 않는다.

5.3. 임시 팀이 제품 팀으로 굳어지는 순간

1. Claude Design의 출발

   1. 애드혹 그룹: Claude Design은 처음에 특정 프로젝트를 위해 임시로 모인 그룹에서 시작했다.
   2. 제품의 다리: 출시 후 사용자의 견인력(traction)이 확인되고 6월에 큰 두 번째 릴리스가 나오면서 단기 베팅 이상의 지속성이 생겼다.

2. 발전 단계에 따른 구조화

   1. 전담 인력: 제품에 다리가 생기면 해당 제품을 위한 사람을 채용하고 팀 구조를 세운다.
   2. 운영 원칙: Labs는 처음에는 느슨하게 시작하고, 실제 가능성이 확인된 뒤 구체적인 조직으로 굳어진다.

6. Claude Design의 다음 단계와 제품 복잡성 제거

AI 제품의 다음 경쟁은 기능을 계속 늘리는 것이 아니라, 서로 다른 표면(surface)을 연결하고 사용자가 제품 경계를 의식하지 않게 만드는 데 있다.

6.1. Claude Design과 다른 표면의 연결

1. Claude Code와의 왕복

   1. 현재의 마찰: 디자인을 대화로 구상한 뒤 Claude Code에서 구현하고 다시 디자인으로 돌아오는 과정이 아직 매끄럽지 않다.
   2. 목표 상태: 디자인에 관해 이야기한 맥락과 구현 결과가 다른 표면 사이에서 자연스럽게 이어져야 한다.

2. 표면을 서로 말하게 하기

   1. 자유도를 막는 단절: Claude의 각 표면이 충분히 대화하지 못하는 것이 모델과 제품의 가능성을 제한한다.
   2. 미래의 방향: 사용자가 “어느 제품을 열어야 하는가”를 먼저 결정하지 않고도 같은 작업 맥락에서 디자인·코드·실행을 오갈 수 있어야 한다.

6.2. 디자인과 애플리케이션의 경계 흐리기

1. HTML과 JavaScript로 가능한 것

   1. 현재의 기능성: Claude Design은 지속성(persistence)을 기본으로 제공하지 않더라도 HTML과 JavaScript만으로 완전한 기능의 결과물을 만들 수 있다.
   2. 예상 밖의 사용: 원래 설계 목적이 아니었는데도 사용자들이 게임까지 만들고 있다.

2. 정교한 디자인에서 공유 가능한 아티팩트로

   1. 다음 경로: 보기 좋고 잘 설계된 결과물을 실제로 데이터를 저장하는 아티팩트(artifact)로 발전시킬 수 있어야 한다.
   2. 협업성: 사용자가 그 결과물을 다른 사람과 공유하고, 공유된 결과에서 다시 만들 수 있어야 한다.
   3. 경계의 변화: 디자인은 정적인 시안이 아니라 실행·저장·공유가 가능한 애플리케이션의 출발점이 된다.

6.3. “무엇을 지울 것인가”와 Project Unship

1. Bourbon에서 Instagram으로의 삭제 경험

   1. 과거의 선택: Mike가 Instagram에 집중하기 위해 Bourbon의 거의 모든 것을 삭제했던 사례가 제품 선택의 극단을 보여 준다.
   2. Fable의 질문: Fable에게 무엇을 물어볼지 요청하자 Fable은 그 삭제 경험을 AI나 Claude에 적용해 무엇을 없앨지 물었다.

2. 낮은 사용률 기능의 함정

   1. 4~5%의 함정: Instagram에서는 어떤 기능이 4~5%만 사용되면 적어 보이지만, 그런 기능이 20개 있으면 각 사용자가 서로 겹치지 않는 기능 묶음을 쓰는 Microsoft Word 문제가 생긴다.
   2. 삭제의 어려움: 기능을 없애면 각 기능을 쓰던 사용자의 작은 집단을 잃게 되므로 전체 사용률만으로 결론을 내리기 어렵다.

3. 세대가 바뀌면 원시 기능도 바뀐다

   1. Styles의 언십(unship): 최근 Styles는 소수 사용자만 사용했고 AGI적인 유연성이 크지 않으며 동작 방식이 지나치게 처방적이어서 제품에서 제거되었다.
   2. Skills의 대체: Skills는 더 좋은 애플리케이션 단위를 제공하므로 기존 원시 기능을 보완하거나 대체할 수 있다.
   3. 제품 원칙: 한 세대의 AI 프리미티브(primitive)를 다음 세대가 더 잘한다면 기꺼이 제거·보완·대체해야 한다.

4. Code·Co-work·Chat의 경계 지우기

   1. 사용자에게 떠넘긴 복잡성: 현재 사용자는 Code, Co-work, Chat 중 무엇을 선택해야 하는지 판단해야 하지만 세 제품은 서로 잘 연동되지 않는다.
   2. 평범한 사용자의 관점: 일반 사용자는 세 가지가 왜 다른지 설명하기 어렵고, 서로에게 작업을 위임할 수도 없다.
   3. 낡은 중간 복사 단계: Co-work에서 원하는 결과를 정리한 뒤 Claude Code에 붙여 넣을 문단을 따로 만들어 달라고 요청하는 것은 2020년대 초의 낡은 워크플로다.
   4. 지향점: 제품 복잡성을 줄이면 Claude가 사용자의 목적에 맞는 표면과 도구를 스스로 선택하고 연결할 수 있다.

7. 거대 AI 연구소 시대에도 스타트업이 필요한 이유

모델 회사가 무엇이든 만들어 낼 수 있는 것처럼 보여도, 특정 산업과 사용자의 문제를 깊게 이해하고 빠르게 반복하는 작은 팀의 우위는 남아 있다.

7.1. 차세대 스타트업을 여는 모델

1. Anthropic에 합류한 동기

   1. 코딩 능력의 도약: Mike는 모델이 처음부터 코딩을 잘했던 것은 아니지만 빠르게 좋아지는 모습을 보았다.
   2. 실험의 가속: 모델은 아이디어를 내거나 제품의 취향(taste)을 정해 주지는 않지만, 실험을 훨씬 간단하게 만들고 더 빠르게 움직이게 한다.
   3. 차세대 회사의 기반: 이 가속은 다음 세대 스타트업이 더 짧은 시간에 가설을 만들고 검증하는 기반이 된다.

2. Google Photos와 Instagram의 비유

   1. 투자자의 걱정: Instagram 시절 투자자들은 Google이 사진 제품을 출시하면 어떻게 할 것인지 물었다.
   2. 대기업의 강점과 제약: Google은 Google다운 사진 제품을 만들 것이고, 기존 통합(integration)과 강점에 묶인 방식으로 경쟁할 것이다.
   3. 현재의 적용: Anthropic도 플랫폼이므로 모든 특정 산업과 사용자 집단을 깊이 이해하고 사랑받는 제품으로 만드는 데에는 한계가 있다.

7.2. 수직 시장의 집착과 도메인 지식

1. 작은 팀의 깊이

   1. 레이저처럼 좁은 집중: 특정 산업, 업무 영역, 잘 아는 사람들의 집단에 집착하는 팀은 그들의 문제를 연구소보다 깊게 이해할 수 있다.
   2. 채택과 사랑: 깊은 이해는 제품 채택(adoption)과 사용자 애착(user love)을 높이며, 범용 플랫폼이 따라가기 어려운 차별성을 만든다.

2. 모델이 대신할 수 없는 어려운 일

   1. 문제 이해: 사용자가 실제로 무엇을 필요로 하는지 이해하는 일은 여전히 어렵다.
   2. 도달과 경청: 사용자를 어떻게 만나고, 어떻게 듣고, 그 피드백을 어떻게 빠르게 제품에 반영할지 결정해야 한다.
   3. 네다섯 명의 속도: 하나의 문제에 집착하는 4~5명은 복잡한 조직 안에서 같은 사람들보다 빠르게 움직일 수 있다.

3. 전용 제품이 필요하지 않을 수 있는 영역

   1. Skill화: 모델이 많은 일을 수행하면 일부 기능은 독립적인 제품보다 Skill로 제공하는 편이 낫다.
   2. 남아 있는 난제: 그러나 사용자 이해, 신뢰, 도달 경로, 반복 개선처럼 어려운 일은 모델의 능력이 커져도 사라지지 않는다.
   3. 스타트업에 대한 확신: 코드를 작성하는 일은 과거에도 스타트업의 성패를 가르는 본질적 제한이 아니었고, 지금도 진짜 제한은 사용자와 문제를 이해하는 공간이다.

8. 수직 AI와 금융: 자유로운 에이전트와 감사 가능성의 균형

금융용 AI는 모델의 유연성만으로 충분하지 않으며, 검증된 데이터와 추적 가능한 의사결정 기록 위에서 자유로운 분석을 실행해야 한다.

8.1. 세대별 개선과 금융 평가

1. 모델의 세대별 향상

   1. 금융 사용 사례: 금융 영역은 모델이 세대가 바뀔 때마다 분명하게 좋아지는 분야다.
   2. 스프레드시트의 역할: Excel 스프레드시트처럼 구조화된 금융 작업은 모델의 계산·분석 능력을 시험하는 대표적인 사용 사례다.

2. 수직 금융 스타트업의 평가

   1. 자체 평가(evals): 금융 특화 스타트업은 자체 평가(evaluation)를 만들어 실제 사용 사례에서 모델이 좋아지는지 추적한다.
   2. 평가를 속이지 않는 기준: 평가 점수만 올리도록 모델을 조정한다는 뜻이 아니라, 실제 금융 업무가 개선되는지를 보는 유용한 바로미터(barometer)다.

8.2. Just-in-time 분석과 검증된 데이터

1. 자유로운 생성의 가치

   1. 그때그때 만드는 결과: 모델은 필요할 때 즉석 분석, 대시보드, 워크플로를 만들어 금융 전문가의 질문에 대응할 수 있다.
   2. 에이전트의 유연성: 모든 업무를 미리 고정된 애플리케이션으로 만들지 않아도 새로운 질문에 맞는 결과를 만들 수 있다.

2. 검증 가능한 데이터 기반

   1. 불변성보다 검증성: 데이터 세트가 영원히 불변(immutable)일 필요는 없지만, 적어도 검증된(verified) 집합이어야 한다.
   2. 금융사의 요구: 모든 데이터를 완전히 자유 형식으로 풀어 놓으면 혼란이 생기며, 금융 서비스 회사는 그런 방식을 원하지 않는다.
   3. 필요한 기록: 결과가 어떤 데이터에서 나왔는지 확인할 수 있는 감사 로그(audit logging)와 데이터 출처(data provenance)가 필요하다.

3. 유연성과 통제 사이의 절단선

   1. 핵심 설계 문제: 검증·감사·출처 정보를 보장하면서도 그 위에서 만들 수 있는 에이전트 애플리케이션의 종류를 제한하지 않는 절단선을 찾아야 한다.
   2. 기존 시스템의 한계: 검증 가능성과 감사 가능성을 위해 만든 기존 시스템은 설계상 에이전트 워크로드(agentic workload)에 충분히 유연하지 않은 경우가 많다.
   3. 스택 양쪽의 기회: 데이터·감사 기반과 에이전트 애플리케이션 양쪽에서 새로운 설계 기회가 생긴다.

9. 빠른 산업에서 번아웃을 피하고 오래 가는 팀 만들기

AI 산업의 속도가 사람의 자기감과 조직의 판단을 하루 단위의 출시와 반응에 묶어 놓지 않도록, 휴식·관점·감정 표현을 운영 원칙으로 삼아야 한다.

9.1. Instagram보다 훨씬 빠른 AI의 주기

1. 속도의 비교

   1. Instagram 시절: Instagram에서는 매년 한 번 열리는 Apple의 WWDC에서 무엇이 발표될지, 그것이 제품을 망가뜨릴지 끌어올릴지를 생각했다.
   2. 경쟁사 주기: 경쟁사가 새 제품을 내놓는 일도 대략 3~4개월마다 발생했다.
   3. AI 시절: 지금은 매주 수요일 올핸즈(all-hands)를 열 때가 되면 아직 수요일인데도 새 모델, 새 제품, 규제 소식이 연달아 등장한다.

2. 일주일 안에도 바뀌는 현실

   1. 주간 AI 슬라이드: Pinterest에서 “이번 주 AI”를 정리하는 슬라이드를 만들지만, 수요일이 되기 전에도 경쟁사가 모델을 출시하는 일이 생긴다.
   2. 정서적 피로: 타임라인을 계속 새로 고치며 따라가려는 행동은 성장 산업의 속도를 개인의 신경계에 직접 연결한다.

9.2. 오프라인 며칠을 허용하는 운영 원칙

1. 번아웃의 비가역적 비용

   1. 소진 뒤의 중단: 완전히 번아웃되면 일을 계속할 수 없고, 실제로 가까운 사람들이 그렇게 된 뒤 회복하는 데 오랜 시간이 걸리는 모습을 봤다.
   2. 휴식의 기준: 어떤 직업도 이틀 정도 오프라인 상태가 될 수 없을 만큼 중요하지 않다.
   3. 구조적 문제 신호: 정말 이틀을 비울 수 없다면 멘토와 이야기해 무엇이 막고 있는지 찾아야 하며, 조직이나 일의 설계에 문제가 있을 가능성이 있다.

2. 스포츠의 경기력 비유

   1. 최고와 최저 사이: 사람은 최고의 경기만큼 늘 잘하지도 않고, 최악의 경기만큼 늘 못하지도 않다.
   2. AI의 순환: “이제 끝났다”와 “우리가 완전히 돌아왔다”가 반복되는 AI의 순환도 같은 원리로 봐야 한다.
   3. 감정의 거리 두기: 한 번의 모델이나 제품 출시가 좋지 않았다고 해서 장기적인 역량과 팀의 가치를 매일 다시 판정할 필요는 없다.

9.3. 단기 위기를 장기 게임의 일부로 보기

1. 스타트업의 “우리는 망했다” 순간

   1. 위기의 감정: Ben Horowitz의 『The Hard Thing About Hard Things』에는 스타트업이 “우리는 끝났고 회복할 수 없다”고 느끼는 순간이 담겨 있다.
   2. Instagram의 반복 경험: Instagram도 그런 순간을 몇 차례 겪었지만, 결국 통과했고 그 과정을 견딘 일이 회사를 정의했다.

2. Anthropic의 긴 게임

   1. 빠르지만 장기적인 사업: Anthropic은 빠르게 움직이지만 동시에 긴 게임을 하는 조직이다.
   2. 오늘의 출시가 전부가 아님: 오늘의 모델 출시와 시장 반응, 오늘의 제품 출시와 후속 반응만으로 조직의 미래를 판단하지 않는다.
   3. 팀과 문화에 대한 신뢰: 몇 달 전에도 비슷한 위치에 있었고 다시 빠져나왔다는 사실을 기억하며, 그런 변동을 견딜 팀과 문화를 만든다는 데 집중한다.
   4. 자기감의 확대 축소: 1년을 기다리지 않아도 3개월 전을 돌아보는 것만으로 관점을 넓힐 수 있으며, 자기감과 성공을 하루 단위 결과에 맡기지 않아야 한다.

9.4. 리더가 감정을 먼저 말하는 법

1. 감정은 팀 안에서 공유된다

   1. 코치의 조언: 자신이 어떤 감정을 느끼고 있다면 팀의 다른 사람들도 비슷하게 느끼고 있을 가능성이 크다.
   2. 감정의 언어화: “이 일 때문에 정말 스트레스를 받고 있다”, “이 Labs 이니셔티브를 종료하게 되어 정말 슬프다”라고 먼저 말하면 팀이 감정을 다룰 공간이 생긴다.

2. 종료 회의에서의 취약성

   1. 구체적 사례: 몇 달 전 열심히 작업한 이니셔티브를 종료하는 회의에서 Mike는 “슬프고 좌절했으며 이 일이 잘되기를 바랐다”고 회의를 시작했다.
   2. 공동의 감정 확인: 다른 구성원도 “나도 화가 났다”, “나도 슬프다”고 말할 수 있게 되었고, 감정을 숨기지 않은 덕분에 공동의 현실을 확인했다.
   3. 행동으로 이동: 감정을 먼저 인정하면 그다음에 “이제 무엇을 할 것인가”라는 실질적 질문으로 더 쉽게 이동할 수 있다.

3. 감정과 실행의 결합

   1. Stanford Touchy Feely와의 연결: AI Engineer 행사는 Stanford에서 Touchy Feely를 운영하는 Carol Robbins의 세션으로 시작했다.
   2. 마무리의 메시지: 기술 조직이 감정을 말하고 정신 건강을 관리하면서도 계속 출하(keep shipping)할 수 있다는 메시지로 대화가 끝났다.

주요 발언 모음

“지금은 너무 흥미로운 시대라서 역할을 바꿔야 했다.”

“최종 상태를 표현하고, 모델이 가서 그 위에서 요리하게 한다.”

“우리는 업계와 제품팀 차원에서 사람들에게 더 무리한 사용을 가르쳐야 한다.”

“전체 Python 코드베이스를 TypeScript로 옮기고, 작동하고 배포 가능하게 만들어라. 주말 안에.”

“사용자가 궁극적으로 테스트다.”

“사람이 무엇을 하는지 완전히 개념화하는 능력 자체가 병목이다.”

“Claude가 돕는 코드 리뷰지만 여전히 사람이 주도한다.”

“프로젝트가 종료되는 것은 Labs 팀의 의도다.”

“어떤 직업도 이틀 정도 오프라인이 될 수 없을 만큼 중요하지 않다.”

“최고의 경기만큼 잘하지도, 최악의 경기만큼 못하지도 않다.”

핵심 데이터 & 수치

• 영상 길이: 26분 10초다.
• 원본 발행일: 2026-08-27이다.
• Anthropic 합류 후 초기 역할: 첫 2년 동안 CPO로 일한 뒤 Labs IC로 이동했다.
• Python→TypeScript 포팅 규모: 수십만 줄에 가까운 대형 Python 코드베이스를 주말 동안 포팅했다.
• 태그 기반 코드 작성 비중: 현재 코드의 60% 이상이 태그 기반 방식과 연결된다고 설명했다.
• 기능 플래그 규모: 하나의 앱에 약 3,000개의 플래그를 둘 수 있다.
• 코드 리뷰 사례: 2,000줄 PR은 코드만으로는 의도와 트레이드오프를 파악하기 어렵다.
• Labs 의사결정 주기: 2주마다 모든 베팅을 “지속 또는 방향 전환(persevere or pivot)” 심사에 올린다.
• Instagram 기능 사용률의 함정: 기능 하나가 4~5%만 사용되어도 20개가 모이면 광범위한 사용자 집합을 구성할 수 있다.
• 수직 문제를 파고드는 팀 규모: 4~5명이 한 문제에 집착하면 복잡한 조직보다 빠르게 움직일 수 있다.
• Instagram 시절의 경쟁 주기: 대형 플랫폼 발표는 연 1회, 경쟁사 출시는 대략 3~4개월 주기였지만 AI는 주간 단위로 바뀐다.
• 휴식 권고: 번아웃을 피하려면 어떤 일도 이틀의 오프라인 휴식을 막을 정도로 중요하다고 보지 않는다.

결론 및 시사점

1. 요청의 단위를 작업에서 목표로 바꿔라

   1. 모델에게 작은 단계별 지시만 내리지 말고 원하는 최종 상태, 제약, 성공 조건을 설명한다.
   2. 모델이 스스로 탐색·검증하도록 허용하되, 의도와 트레이드오프를 사람이 확인한다.

2. 불합리한 요구를 실행 가능한 실험으로 바꿔라

   1. 수십만 줄 포팅처럼 과거에는 무모했던 작업도 모델의 반복·검증 루프와 적절한 배포 도구를 결합하면 시험할 수 있다.
   2. 다만 “하룻밤에 바다를 끓이기”보다 생산 데이터, 세그먼트 테스트, 점진적 롤아웃으로 안전한 경계를 찾는다.

3. AI를 개인 CLI가 아니라 팀 동료로 설계하라

   1. 모델에 코드 영역·피드백 채널·API 변경까지 포함한 책임을 맡기고, 맥락·메모리·선제성을 활용한다.
   2. 다른 사람이 모델을 어떻게 쓰는지 보게 하는 멀티플레이어 환경은 조직 전체의 야심과 학습 속도를 높인다.

4. 코드 리뷰의 중심을 줄 수에서 의도와 결과로 옮겨라

   1. 수천 줄의 코드만 보내지 말고 변경 목적·선택·트레이드오프를 설명하는 아티팩트를 함께 보낸다.
   2. Claude가 질문을 조사해도 중요한 아키텍처 판단과 프로덕션 검증은 인간이 맡는다.

5. 실험 조직은 프로젝트 수명과 사람의 성장 구조를 분리하라

   1. 2주 주기의 지속·전환·종료를 실패가 아닌 학습 설계로 만들고, 프로젝트가 사라져도 사람은 다음 베팅으로 이동하게 한다.
   2. 베팅 리드에게 책임을 주되 사람 관리는 엔지니어링 매니저가 맡으면 빠른 재편과 지속적인 코칭을 함께 유지할 수 있다.

6. 제품 간 경계를 사용자에게 떠넘기지 마라

   1. Code·Co-work·Chat·Design이 서로 위임하지 못하면 사용자가 복사·붙여넣기라는 낡은 통합 계층이 된다.
   2. 디자인을 실행·저장·공유 가능한 아티팩트로 연결하고, 모델이 목적에 맞는 표면을 넘나들게 해야 한다.

7. 범용 모델의 위협 속에서도 도메인 깊이를 쌓아라

   1. 코드 작성 속도보다 특정 사용자의 문제를 이해하고, 도달하고, 듣고, 빠르게 개선하는 능력이 스타트업의 방어력이다.
   2. 4~5명의 집요한 팀이 한 분야를 깊게 파고들면 거대 연구소가 얻기 어려운 채택과 사용자 사랑을 만들 수 있다.

8. 금융 AI는 자유도와 감사 가능성을 동시에 가져야 한다

   1. 즉석 분석·대시보드·워크플로를 허용하되, 검증된 데이터 집합·감사 로그·데이터 출처를 기반으로 삼는다.
   2. 기존 통제 시스템의 경직성을 에이전트 계층의 유연성으로 보완하는 것이 금융 AI의 핵심 설계 기회다.

9. 장기 게임의 팀은 휴식과 감정을 운영 인프라로 취급하라

   1. 이틀 오프라인을 허용하고 하루의 모델 출시가 자기감과 성공을 결정하지 않도록 시간적 관점을 넓힌다.
   2. 리더가 스트레스·슬픔·좌절을 먼저 언어화하면 구성원도 감정을 공유하고, 공동의 현실을 인정한 뒤 실행으로 이동할 수 있다.

핵심 요약 (20줄)

Mike Krieger는 Anthropic의 CPO에서 Labs의 IC로 옮겨 모델을 직접 만드는 일에 뛰어들었다.

주변 사람들이 모델로 만드는 모습을 보며 커진 FOMO가 역할 전환의 직접적인 동력이 되었다.

전통적 엔지니어링은 작업을 쪼개지만 새로운 방식은 최종 상태를 설명하고 모델의 결과를 검토한다.

모델이 선택한 트레이드오프를 설명하면 사람은 더 쉬운 언어로 다시 설명해 달라고 요청할 수 있다.

AI 제품은 모델을 상자 안에 가두지 말고 도구와 실행 환경에 충분한 자유도를 제공해야 한다.

Mike는 수십만 줄 규모의 Python 프로젝트를 Claude로 TypeScript에 포팅해 주말 동안 배포 가능한 상태로 만들었다.

MonkeyType은 프로덕션 런타임 타입을 수집해 Python 코드베이스에 되돌려 주는 방식으로 변환의 근거를 만들었다.

대규모 변환은 생산 데이터와 세그먼트 테스트를 활용해 점진적으로 진행하고 전체를 하룻밤에 바꾸지 않아야 한다.

Instagram의 확장 교훈은 필요한 지표를 미리 측정하고 런타임 노브와 기능 플래그를 준비하라는 것이다.

태그 기반 위임은 Anthropic 내부 코드 작성의 60% 이상과 연결되며 개인 CLI보다 멀티플레이어 협업에 가깝다.

Claude에게 코드베이스 일부와 피드백 채널을 맡기면 버그 수정자를 넘어 맥락과 메모리를 가진 동료가 된다.

AI 개발의 병목은 코드 리뷰에 걸리는 시간보다 사람이 변경 의도와 전체 구조를 이해하는 능력이다.

Labs는 2주마다 프로젝트를 지속하거나 전환하거나 종료하며 프로젝트 종료를 실패가 아닌 설계된 학습으로 본다.

Claude Design은 임시 그룹에서 출발해 사용자의 견인력과 릴리스를 확인한 뒤 전담 팀으로 구조화되었다.

Claude Design과 Claude Code가 맥락을 공유하고 디자인을 저장·공유 가능한 아티팩트로 바꾸는 것이 다음 과제다.

Code·Co-work·Chat의 복잡한 경계를 없애면 사용자가 제품 사이를 복사·붙여넣기할 필요가 줄어든다.

스타트업의 방어력은 코드 작성 속도가 아니라 특정 산업과 사용자의 문제를 깊이 이해하는 도메인 지식이다.

금융 AI는 즉석 분석의 자유도와 검증된 데이터·감사 로그·데이터 출처를 함께 제공해야 한다.

AI 산업의 주간 변화 속에서도 이틀 오프라인 휴식과 장기적 관점이 번아웃을 막는다.

리더가 감정을 먼저 말하면 팀은 슬픔과 좌절을 공유하고 정신 건강을 지키면서 계속 출하할 수 있다.