Anthropic Labs를 만드는 법: Mike Krieger가 말하는 AI 제품·조직 운영 철학

URL: https://www.youtube.com/watch?v=DIULfa9PCJk 날짜: 2026-08-29 채널: Tech Bridge

---

📌 핵심 질문 / 핵심 논점

==AI가 코드를 더 빨리 만드는 시대에 제품·조직·창업자는 무엇을 위임하고, 무엇을 직접 판단하며, 어떻게 빠른 실험과 장기적인 지속 가능성을 함께 확보해야 하는가?==

• Mike Krieger는 Anthropic의 Labs에서 최종 상태(end state)를 설명하고 Claude가 구현·탐색하도록 맡기는 방식으로 자신의 역할과 개발 습관을 바꾸고 있다.
• 실험적인 Labs 조직은 2주마다 프로젝트를 persevere or pivot으로 심사하고, 프로젝트 수명에 맞춰 조직도를 재편하지 않도록 유연한 pod와 bet 구조를 사용한다.
• AI의 가치가 코드 생성 속도에만 있지 않으므로, 스타트업은 특정 도메인에 대한 집요한 이해·사용자 사랑·빠른 피드백을 경쟁력으로 삼아야 한다.
• 빠른 모델·제품 출시의 압박을 견디려면 관측 가능성, feature flag, 점진적 rollout, 검증 가능한 데이터, 감정의 언어화와 휴식이 모두 필요하다.

Anthropic에서 AI는 단순한 대화형 도구를 넘어 맥락과 기억을 보유하고 먼저 행동하는 팀원에 가까워지고 있다. 그만큼 사람의 일은 모든 코드를 직접 쓰는 일에서 목표·의도·트레이드오프를 명확히 정하고 결과를 검증하는 일로 이동한다. 실험을 많이 할수록 실패를 정상적인 종료 조건으로 받아들이는 조직 설계, 데이터와 감사 가능성을 갖춘 운영 기반, 그리고 장기전을 버틸 정신 건강이 함께 필요하다.

1. Mike Krieger의 역할 전환과 ‘최종 상태’ 중심 개발

1.1. Chief Product Officer에서 Individual Contributor로

1. 역할이 바뀐 직접적인 계기

   1. Mike Krieger는 Anthropic에서 처음 2년 동안 Chief Product Officer(CPO)로 일했다.
   2. 주변 사람들이 모델을 실제로 사용해 제품을 만들고 있는 모습을 보면서, 자신도 모델을 최대한 활용해야 한다는 FOMO(fear of missing out)가 계속 커졌다.
   3. 제품 전략 문서를 작성한 뒤 Claude에게 비평을 맡기는 workflow는 가능했지만, 직접 무언가를 만들며 모델과 순수하게 상호작용하는 경험과는 달랐다.
   4. 주말마다 모델로 무언가를 만들던 시간이 쌓이면서, 단순히 전략을 검토하는 역할에 머무르기보다 직접 빌드하는 쪽으로 이동해야 한다고 판단했다.

2. 조직 안에서 관찰한 공통적인 이동

   1. 다른 회사의 CTO였던 사람들이 Anthropic을 비롯한 여러 곳에서 Individual Contributor(IC) 역할로 합류하는 흐름이 나타났다.
   2. 모델이 강해질수록 관리·조정만 하는 고위 리더보다, 직접 모델을 활용해 결과물을 만드는 사람이 되고 싶다는 욕구가 커졌다.
   3. Krieger의 역할 전환은 직함을 낮추는 선택이 아니라, 모델을 가장 깊이 활용할 수 있는 작업 방식으로 이동하는 선택이었다.

1.2. 모델의 세대 변화가 바꾼 사고 순서

1. 내부 모델 snapshot과 개발 방식의 전환

   1. Krieger가 역할을 바꾼 시점은 훗날 Mythos와 Fable이 된 Anthropic 내부 snapshot을 사용하기 시작한 때와 가까웠다.
   2. 예전에는 아이디어를 머릿속에서 먼저 잘게 쪼개고, 자신이 평소 엔지니어링하던 순서대로 각각의 단계를 설계한 뒤 한 단계씩 진행했다.
   3. 새 방식에서는 목표를 설명하고 Claude가 작업하도록 보낸 다음, Claude가 발견한 트레이드오프와 중간 질문을 대화로 확인한다.
   4. 마지막에는 Claude가 어떤 결론에 도달했는지, 왜 그런 선택을 했는지, 다음에 어느 방향으로 갈지를 함께 결정한다.

2. 위임의 단위가 작업에서 결과 상태로 이동

   1. 핵심 변화는 특정 task를 하나씩 배정하는 task delegation에서 원하는 최종 상태를 표현하는 end-state delegation으로 이동한 것이다.
   2. 사람은 모든 구현 단계를 미리 규정하지 않고, 목표·제약·성공 조건을 제시한다.
   3. Claude는 그 목표를 향해 여러 접근을 시도하고, 사람이 예상하지 못한 선택지와 비용을 드러낸다.
   4. Krieger는 이 과정을 Claude가 목표를 받아 “가서 요리(cook)하는” 방식으로 표현했다.

3. 더 똑똑한 에이전트를 이해하기 위한 사람의 적응

   1. Krieger는 최근 다시 활성화된 Claude를 두고, 때때로 Claude가 자신보다 훨씬 똑똑하게 느껴진다고 농담했다.
   2. Claude가 작업을 끝내고 선택한 트레이드오프를 설명하면, Krieger는 “나보다 조금 덜 똑똑한 사람에게 설명하듯 풀어 달라”고 다시 요청해야 할 때가 있다.
   3. 에이전트가 더 많은 일을 처리할수록 사람이 결과를 이해할 수 있도록 설명의 수준과 형식을 요구하는 능력도 중요해진다.

2. ‘Be unreasonable’과 AI 활용의 야심

2.1. 비기술자까지 Claude를 직접 호출하게 하기

1. Tariq가 던진 한 문장

   1. 행사 전날 Tariq는 다음 날 신문에 실릴 발표 요약을 염두에 두고 “be unreasonable”이라고 조언했다.
   2. Krieger는 이 표현을 AI 사용의 태도를 바꾸는 좋은 framing으로 받아들였다.
   3. 모델의 현재 한계를 먼저 상상해 요청을 작게 만드는 대신, 원하는 결과를 얻기 위해 과감한 범위의 일을 시켜야 한다는 뜻이다.

2. Labs 내부 제품에서 실제로 일어난 장면

   1. Krieger가 맡은 Labs initiative의 내부 제품에 한 사람이 “원하는 방식으로 작동하지 않는다”며 변경을 요청했다.
   2. Krieger는 직접 수정하기보다 “Claude에게 물어보라”고 권했다.
   3. 상대는 비기술자였지만, 바로 그 점이 중요했다. AI 제품팀은 비기술자도 직접 문제를 기술하고 해결을 시도하도록 가르쳐야 한다.
   4. 산업 전체가 모델을 제한된 보조 도구로만 취급하지 않고, 결과를 요구하는 실행 파트너로 사용하도록 교육해야 한다.

2.2. 첫 세대 AI 제품의 상자와 자유도

1. 도구 접근을 제한했던 초기 제품

   1. 1세대 AI 제품은 모델을 너무 좁은 상자 안에 넣고 tool access와 degrees of freedom을 제한했다.
   2. “이 일을 해 달라”고 요청해도 모델은 코드를 작성할 수 있을 뿐 실제로 실행하지 못하거나, 환경을 살펴볼 수 있어도 충분히 introspect하지 못했다.
   3. 도구와 실행 권한이 없으면 모델이 스스로 가설을 검증하거나 예상 밖의 해결책을 시도할 수 없으므로, 사용자도 unreasonable한 요청을 하기 어려워진다.

2. Co-work와 가상 머신이 여는 경로

   1. 모든 knowledge worker에게 Bash를 작성할 수 있는 virtual machine이 필요한 것은 겉보기에는 과한 선택이다.
   2. 그러나 내장 PDF 기능으로 문서를 parse하려다 실패한 뒤, 모델이 직접 스크립트를 작성해 다른 방식으로 읽을 수 있다면 상황이 달라진다.
   3. 모델이 내장 기능의 실패에서 멈추지 않고 자신에게 필요한 작은 도구를 만들어 문제를 우회하는 능력이 생긴다.
   4. 제품의 가치는 고정된 기능 목록보다 모델이 목표를 달성하기 위해 사용할 수 있는 도구·환경·자유도의 조합에서 커진다.

2.3. 수십만 줄 Python codebase를 주말에 TypeScript로 옮기기

1. Krieger가 선택한 비합리적인 요청

   1. Krieger는 Python을 특히 좋아하며 Instagram 전체가 Python으로 작성됐다고 말했다.
   2. Instagram이 이제 모델을 활용해 PHP로 변환할 수 있게 됐다는 농담이 나오자 객석에서 웃음이 터졌다.
   3. 한 Labs 프로젝트의 deployment를 살펴보던 Krieger는 Claude Code가 Bun을 이용해 더 나은 배포 경로를 찾아낸 사실을 발견했다.
   4. Bun 기반 배포를 활용하려면 프로젝트 전체를 Python에서 TypeScript로 포팅해야 했다.

2. 기존 엔지니어링 상식과 충돌한 범위

   1. 2010년대의 엔지니어링 관점이나 2020년대 초반의 관점에서 수십만 줄에 가까운 codebase를 주말에 다른 언어로 옮기는 일은 어리석어 보인다.
   2. 일반적인 사람이라면 전체 포팅의 비용·버그·검증 부담 때문에 작은 부분부터 순차적으로 바꾸려 할 것이다.
   3. Krieger는 이번에는 이 요청이 실제로 가능하다고 판단하고, 포팅·검증·재검토를 하나의 dynamic workflow로 묶었다.

3. 주말 동안 수행한 workflow

   1. Claude에게 프로젝트 전체를 Python에서 TypeScript로 옮기고 작동하게 만들며 배포 가능 상태까지 만들라고 요청했다.
   2. Claude는 포팅한 코드가 맞는지 확인하고 다시 점검했으며, 두 codebase를 읽고 비교하는 작업을 반복했다.
   3. 주말 내내 코드가 계속 churn하도록 두었고, Krieger는 월요일에 돌아와 포팅된 workflow가 완성되어 있는 것을 확인했다.
   4. “전체 Python codebase를 TypeScript로 옮겨 주말 안에 작동·배포 가능하게 하라”는 요청이 Krieger가 꼽은 가장 unreasonable한 사례 중 하나가 됐다.

3. 레거시 변환·배포·운영에서 사람의 역할

3.1. Python 3와 MonkeyType가 만든 점진적 이행

1. Instagram의 Python 확장 경험

   1. Python 3가 등장했을 때 Instagram 팀은 처음으로 type annotation을 코드에 추가할 수 있었다.
   2. 내부에서는 Python이 성장 동력을 잃는 것 아니냐는 논쟁이 있었지만, Krieger는 생각보다 훨씬 오래 Python을 확장할 수 있다고 봤다.
   3. 다만 팀이 자기 코드의 모호함에 발목 잡히지 않으려면 type 정보가 필요했다.

2. MonkeyType의 작동 방식

   1. Instagram은 MonkeyType이라는 도구를 만들었다.
   2. MonkeyType는 production에서 실제로 사용된 runtime type을 수집했다.
   3. 수집한 type을 codebase의 해당 위치에 다시 매핑해, 추측이 아니라 실제 실행 데이터에 기반한 type annotation을 만들었다.
   4. 운영 데이터가 코드 변환의 안전한 경계를 알려주는 테스트 자산으로 바뀌었다.

3. LLM을 이용한 cross-compile의 가능성

   1. LLM을 사용해 언어를 바꾸거나 cross-compile할 때 production data를 더 적극적으로 활용할 수 있다.
   2. 전체 애플리케이션을 한 번에 바꾸지 않고, 트래픽·기능·사용자 집단을 나눈 segmented test를 실행할 수 있다.
   3. 변환 대상의 경계와 검증 방법만 제대로 정하면, 기존의 수동 포팅보다 훨씬 넓은 범위의 이행을 시도할 수 있다.

3.2. ‘바다를 끓이지 않는’ 변환 경계

1. 점진성의 핵심

   1. Krieger는 변환의 하늘이 한계가 없다고 보면서도, 가장 어려운 부분은 어디에서 incremental하게 시작할지 찾는 일이라고 했다.
   2. 시스템 전체를 하룻밤 사이에 바꾸려 하지 말고, production data와 segmented rollout으로 작은 경계를 정의해야 한다.
   3. 작은 성공 단위를 만들면 새 언어·새 런타임의 장점을 확인하면서 위험을 통제할 수 있다.

2. 검증 가능한 운영으로 연결하기

   1. 사용자는 결국 가장 실제적인 테스트다.
   2. 모든 미래의 장애를 사전에 예측하기보다, rollout infrastructure를 갖추고 실제 사용자 반응을 관찰하며 수정해야 한다.
   3. 어떤 기능이 언제 누구에게 노출되는지 제어할 수 있으면, 변환과 실험을 되돌리거나 빠르게 확대할 수 있다.

3.3. Instagram의 초기 장애가 남긴 두 가지 원칙

1. 첫 주에 모든 것이 녹아내린 launch

   1. Instagram 출시 첫 주에는 backend를 어떻게 운영해야 하는지 충분히 몰랐고, 시스템이 사실상 모두 녹아내리는 장애를 겪었다.
   2. 마침 그 주에 투자자 중 한 명이 Instagram을 위한 행사가 아니라 infrastructure lunch를 잡아 두었다.
   3. 팀은 그 자리에서 대화를 사실상 독점했고, 참석자들의 scaling 해결책을 모두 들었다.

2. 원칙 1 — 필요할 것 같은 수치를 미리 측정하기

   1. 아주 조금이라도 필요할 가능성이 있는 metric은 미리 측정해야 한다.
   2. 장애가 난 뒤 처음 metric을 추가하면 “이 숫자가 평소 수준인지 비정상적으로 높은지” 비교할 기준이 없다.
   3. 장애 순간에 관측 데이터를 새로 만들고 기다리는 것은 가장 나쁜 상황이므로, 측정은 장애보다 앞서 있어야 한다.

3. 원칙 2 — knobs와 feature flags를 1급 기능으로 만들기

   1. 초기 Instagram은 단순하지만 효과적인 ramp-up과 rollout 방식을 갖고 있었다.
   2. dynamic configuration으로 runtime 설정을 몇 초 안에 바꿔 부하를 감당할 수 있었다.
   3. 설정 변경을 임시 수작업이 아니라 제품·플랫폼의 first-class capability로 다루는 것이 핵심이었다.
   4. AI 시스템도 매 세대·매 기능마다 서로 다른 trade-off를 선택하므로, runtime configuration과 feature flag가 똑같이 중요하다.

4. Tag 기반 협업과 AI 팀원의 등장

4.1. 앱 하나가 아니라 3,000개의 flag를 가진 앱

1. 동적인 제품의 현실

   1. Anthropic의 코드는 오늘 60%대가량이 Tag 기반 방식으로 작성된다는 언급이 나왔다.
   2. 앱 하나를 출시한다는 말은 실제로는 약 3,000개의 flag를 가진 앱을 출시한다는 뜻에 가깝다.
   3. 사용자의 segment에 따라 어떤 기능을 언제 켤지 다르므로, 제품의 현재 상태를 “무엇을 만들고 있는가”라는 한 문장으로 고정하기 어렵다.

2. Claude Code와 Tag의 역할 분리

   1. 대화형 상호작용이 많거나 한 가지 구체적인 문제를 빠르게 주고받아야 할 때는 Claude Code가 적합하다.
   2. Anthropic 내부의 대부분의 사용은 Tag를 통해 더 많이 위임하는 형태로 이뤄진다.
   3. Tag는 Krieger가 오랫동안 내부에서 사용해 오던 방식을 외부에 드러낸 큰 ship이다.
   4. Krieger는 예전부터 무대에서 Anthropic 사람들이 모델을 어떻게 쓰는지 설명하기 어려웠지만, 실제 내부를 보면 이런 방식이 이미 널리 쓰였다고 말했다.

4.2. Multiplayer·비동기·선제적 협업

1. Midjourney의 Discord와 같은 학습 효과

   1. Tag가 흥미로운 이유는 여러 사람이 같은 공간에서 모델을 사용하는 multiplayer 구조이기 때문이다.
   2. Midjourney 사용자들이 Discord에서 서로의 사용법을 보며 새로운 가능성을 배운 것과 비슷한 효과가 난다.
   3. 다른 사람이 Claude에게 대담한 범위의 일을 맡기는 모습을 보는 순간, 자신이 모델을 지나치게 적게 활용했다는 사실을 깨닫게 된다.

2. 단순한 버그 수정에서 codebase 책임자로

   1. 한 사용자는 Claude를 태그하며 “이 버그만 고쳐라”라고 하지 않았다.
   2. 대신 특정 codebase 영역의 책임자가 되어 해당 부분을 관리하고, feedback channel을 모니터링하며, 새 task를 선제적으로 맡아 수정하라고 했다.
   3. API가 바뀌면 그 변경도 처리하라는 범위까지 맡겼다.
   4. 이 사례를 본 사람은 Claude를 Slack 안에서 쓰는 조금 편리한 Claude Code 정도로만 이용해 왔다는 사실을 깨닫게 된다.

3. AI를 동료로 보는 운영 모델

   1. 더 발전한 사용법은 Claude를 질문에 답하는 도구가 아니라 맥락과 memory를 보유한 teammate로 보는 것이다.
   2. Claude가 먼저 문제를 감지하고, 관련 channel의 신호를 읽고, 해야 할 일을 선택해 처리하는 proactive workflow가 가능해진다.
   3. Anthropic 내부의 운영 방식도 개인별 CLI 작업보다 multiplayer·async·proactive 협업에 가까워지고 있다.

5. 코드 리뷰의 병목은 코드 줄 수가 아니라 인간의 이해력

5.1. 여전히 남아 있는 review 병목

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

   1. Claude가 코드를 작성해도 Anthropic은 여전히 code review와 Git에서 병목을 겪는다.
   2. 특히 아키텍처의 중요한 부분을 건드리는 변경은 사람이 반드시 살펴봐야 한다.
   3. 단순히 review 시간을 더 확보하면 해결되는 문제가 아니라, 사람이 현재 무엇을 만들고 있는지 완전히 개념화하기 어려워지는 문제가 더 크다.

2. 2,000줄 PR의 문제

   1. 2,000줄짜리 Pull Request(PR)를 받으면 “코드처럼 보이기는 하는데 무엇을 위해 바꿨는지 모르겠다”는 반응이 나온다.
   2. 줄 단위로 읽는 방식은 생성 속도가 빨라질수록 의도와 trade-off를 놓치기 쉽다.
   3. 사람이 검토해야 할 대상은 코드의 모든 줄뿐 아니라 변경의 목적과 운영 결과가 되어야 한다.

5.2. Claude Code Artifact로 의도와 트레이드오프 공유하기

1. Artifact가 제공하는 정보

   1. Anthropic은 몇 주 전 Claude Code Artifact를 출시했다.
   2. PR과 함께 변경의 설명, 의도, 선택한 trade-off를 공유하는 방식이다.
   3. 사람이 결과 코드만 읽는 대신 “왜 이 변경을 했는가”와 “어떤 대안을 버렸는가”를 먼저 파악할 수 있다.

2. 새로운 커뮤니케이션 단위

   1. 코드는 테스트와 실행 결과로 일정 부분 검증할 수 있다.
   2. 하지만 의도와 trade-off는 코드만 읽어서 완전히 복원하기 어렵다.
   3. 앞으로의 협업은 의도와 trade-off를 대화하고, production에서 실제 효과를 측정하는 방향으로 이동한다.

5.3. 인간 주도·Claude 지원 review

1. 모든 줄을 직접 읽지 않는 방식

   1. Krieger는 모든 Pull Request의 모든 줄을 검토한다고 말할 수 없다고 솔직히 밝혔다.
   2. 대신 코드에 대해 Claude에게 질문을 던지고, 자신이 가질 법한 의문을 조사하게 한다.
   3. 이는 Claude-powered code review지만 최종 방향과 판단은 사람이 주도하는 방식이다.

2. 변경의 중요도에 따른 검토 강도

   1. 중요한 변경은 의도·구조·운영 결과를 깊이 확인해야 한다.
   2. 시각적·화장품 수준의 변경은 문제가 드러나면 fix forward하는 방식으로 처리할 수 있다.
   3. 모든 변경을 같은 수준으로 심사하는 대신, 위험도에 따라 review 비용을 배분해야 한다.

6. Anthropic Labs의 조직 설계

6.1. Engineering Manager의 역할은 사라지지 않는다

1. 관리 역할에 대한 오해

   1. Krieger는 engineering manager discipline의 죽음이 크게 과장됐다고 말했다.
   2. 모델이 코드를 쓰더라도 coaching, interpersonal support, 개인의 development는 여전히 중요하다.
   3. 사람의 동기·성장·갈등을 지원하는 역할은 자동화된 코드 작성과 다른 종류의 책임이다.

2. Labs에서 관리자가 맡는 일

   1. 관리자는 특정 프로젝트의 영구적인 상사가 되기보다, 각 사람이 가장 흥미를 느끼고 가장 잘 일할 수 있는 대상에 배치되도록 돕는다.
   2. 빠르게 바뀌는 실험 환경에서 개인이 어느 프로젝트에 기여할지 조정하고, 필요한 coaching을 제공한다.
   3. 프로젝트가 사라져도 사람이 조직에서 길을 잃지 않도록 이동 경로와 성장을 관리한다.

6.2. 2주마다 열리는 ‘Persevere or Pivot’ 심사

1. Labs의 실험 cadence

   1. Labs의 모든 프로젝트는 2주마다 review를 받는다.
   2. 심사 결과는 persevere 또는 pivot이다.
   3. 계속할 프로젝트는 진행을 이어 가고, 방향을 바꿀 프로젝트는 pivot하며, 필요하면 완전히 shut down한다.

2. 프로젝트 종료를 실패로 보지 않기

   1. Labs의 임무는 빠르게 prototype하고, 내부에 ship하고, 초기 access까지 확장해 보는 것이다.
   2. 작동하지 않으면 프로젝트를 정리하는 것이 원래 설계된 의도다.
   3. 실제로 거의 모든 review cycle에서 프로젝트가 종료된다.
   4. 종료를 반복해서 경험할수록 “내 프로젝트가 닫혔으니 내가 실패했다”가 아니라 “Labs가 실험을 끝냈다”로 받아들이게 된다.

6.3. 프로젝트가 아니라 사람을 중심으로 고정하는 조직도

1. 프로젝트에 맞춰 조직도를 고정할 때 생기는 문제

   1. 프로젝트가 2주마다 pivot하거나 종료되는데 조직도를 개별 프로젝트에 맞추면 2주마다 reorg가 필요하다.
   2. 그런 구조는 구성원에게 불필요한 불안과 운영 비용을 만들며, 조직 전체를 악몽으로 만든다.
   3. 따라서 프로젝트의 수명과 조직의 수명을 분리해야 한다.

2. Pod·Team·Bet 구조

   1. 특정 bet을 수행하는 pod 또는 team은 product 담당자와 관련 팀의 사람을 필요에 따라 끌어온다.
   2. Krieger도 자신이 특별히 관심을 가진 제품이면 해당 팀에 합류해 함께 일한다.
   3. bet마다 bet lead 또는 DRI(directly responsible individual)가 있지만, 그 사람이 보통 다른 구성원을 직접 관리하지는 않는다.
   4. 이 느슨한 구조 덕분에 프로젝트가 작동하지 않을 때 팀을 해산하고 다음 실험으로 이동하기가 쉽다.

6.4. 성과가 확인된 제품의 점진적 고정

1. 느슨한 실험에서 정식 팀으로

   1. Claude Design은 처음에 ad hoc group 형태로 시작했다.
   2. 제품을 출시하고 traction을 얻은 뒤 6월에 큰 두 번째 release를 진행하면서 독립된 제품으로서 다리가 생겼다.
   3. 그 시점부터 특정 팀을 위해 사람을 채용하고 보다 분명한 구조를 만들었다.

2. 조직의 고정 시점

   1. 아이디어 단계에서는 구조를 느슨하게 유지해 실험 속도와 인력 이동성을 확보한다.
   2. 제품이 반복적으로 사용되고 성과를 보이며 더 큰 투자가 타당해지면 전담 인력과 관리 구조를 붙인다.
   3. Labs의 조직도는 처음부터 완성하는 설계도가 아니라, 제품의 생존 가능성이 확인될 때 점진적으로 굳어지는 결과다.

7. Claude Design의 다음 단계

7.1. 서비스 간 상호작용을 더 매끄럽게 만들기

1. 현재의 가장 큰 제약

   1. Claude Design이 더 좋아지려면 다른 Anthropic surface와의 interaction이 더 seamless해져야 한다.
   2. Krieger가 디자인을 구상하면서 Claude Code와 대화할 때, 디자인의 interactive한 상태와 코드 작업이 자연스럽게 이어지지 않는 문제가 있다.
   3. 여러 서비스가 충분히 서로 대화하지 못하는 상황이 Claude의 자유로운 활용을 막는다.

2. Surface 통합이 만드는 가능성

   1. 디자인에 관한 대화가 바로 구현·수정·실행으로 이어져야 한다.
   2. 사용자가 한 surface에서 정한 의도를 다른 surface로 복사해 전달하지 않아도 돼야 한다.
   3. 제품 간 경계가 낮아질수록 “어느 Claude 제품을 써야 하는가”보다 목표를 어떻게 달성할지에 집중할 수 있다.

7.2. 디자인과 앱의 경계 흐리기

1. 이미 나타난 비공식 사용법

   1. Claude Design에는 현재 persistence가 없지만, 사용자는 HTML과 JavaScript만으로 완전히 작동하는 게임까지 만들고 있다.
   2. 게임 제작은 Claude Design의 원래 설계 목표가 아니었지만, 사용자는 제공된 자유도를 다른 목적에 활용한다.
   3. 보기 좋은 design mockup과 실제로 동작하는 application의 차이가 점점 작아지고 있다.

2. Artifact로 이어지는 경로

   1. 출발점은 완성도 높은 화면과 상호작용을 가진 design이다.
   2. 다음 단계는 데이터를 persist하고 다른 사람과 share할 수 있는 artifact다.
   3. 사용자는 artifact를 기반으로 기능을 더 만들고, 디자인에서 실제 제품으로 이어지는 흐름을 만들 수 있다.
   4. 디자인 도구와 앱 빌더를 분리하는 기존 경계가 장기적으로 더 흐려질 것이다.

8. 무엇을 지울 것인가: AI 제품의 단순화

8.1. Burbn에서 Instagram으로의 삭제

1. Fable이 던진 질문

   1. Fable은 Krieger가 Instagram에 도달하기 위해 Burbn의 거의 전부를 삭제했다는 창업 일화를 바탕으로 질문을 만들었다.
   2. 질문은 “AI에서 무엇을 지울 것인가, 더 자극적으로는 Claude에서 무엇을 지울 것인가”였다.
   3. 좋은 제품은 기능을 계속 쌓는 능력뿐 아니라, 핵심 경험을 가리는 기능을 제거하는 취향(taste)도 필요하다.

2. 작은 사용률의 기능이 만드는 누적 복잡성

   1. Anthropic 내부 Slack에는 현재 제품에 무엇이 들어가 있는지 점검하는 Project Unship 채널이 있다.
   2. Instagram에서는 사용률이 4~5%밖에 안 되는 기능도 “그래도 꽤 쓰인다”고 보일 수 있었다.
   3. 그런 기능이 20개쯤 모이면 각기 다른 일부 기능을 쓰는 사용자가 많아지고, 전체 제품은 Microsoft Word처럼 복잡해진다.
   4. 각 기능의 작은 사용률만 보고 유지하면 제품 전체의 이해 가능성이 무너진다.

8.2. 한 세대의 primitive를 다음 세대로 교체하기

1. Styles에서 Skills로

   1. Claude의 더 젊은 제품 세대는 오래된 기능을 정리할 기회가 아직 많다.
   2. Anthropic은 최근 styles를 unship했다.
   3. Styles는 일부 사용자만 사용했고, AI-native한 방식으로 충분히 발전하지 못했으며, 사용법도 지나치게 prescriptive했다.
   4. Skills가 같은 목적을 더 유연하고 강력하게 달성하는 더 나은 primitive가 됐다.

2. 삭제·보완·대체의 원칙

   1. AI 제품팀은 한 세대의 primitive를 영원히 보존해야 한다는 의무에서 벗어나야 한다.
   2. 다음 세대의 모델과 workflow가 더 나은 해결책을 만들면 기존 primitive를 삭제할 수 있다.
   3. 완전히 제거하기 어렵다면 새로운 primitive로 보완하거나, 사용자를 더 좋은 경로로 이동시켜야 한다.

8.3. Claude Code·Co-work·Chat의 경계 없애기

1. 사용자가 이해하기 어려운 현재의 구분

   1. 사용자는 Claude Code, Co-work, Chat을 서로 다른 표면으로 구분해야 한다.
   2. 세 surface는 충분히 잘 상호운용하지 못하고, 서로에게 작업을 위임할 수도 없다.
   3. 일반 사용자는 왜 세 가지가 다른지 명확히 설명하기 어렵다.

2. 불필요하게 남은 2020년대식 workflow

   1. Co-work에서 무엇을 만들지 정확히 계획한 뒤, Claude Code에 붙여 넣을 문단을 만들어 달라고 다시 요청하는 흐름이 있다.
   2. 한 surface에서 만든 계획을 다른 surface에 수동으로 복사하는 일은 모델 간 협업이 가능한 시대에 맞지 않는다.
   3. 사용자는 도구 사이의 경계와 제품 복잡성을 관리하는 데 에너지를 쓰기보다, 해결하려는 문제에 집중해야 한다.

3. 삭제해야 할 것은 기능보다 복잡성

   1. Claude가 해야 할 일을 각 surface에 맞춰 사용자가 미리 분류해야 하는 부담 자체가 제거 대상이다.
   2. 하나의 목표가 상황에 맞는 모델·도구·실행 환경을 자동으로 선택하도록 만들면 제품 경험이 단순해진다.
   3. 제품의 다음 경쟁력은 기능을 더 추가하는 것뿐 아니라, 사용자에게 보이지 않는 통합으로 복잡성을 흡수하는 것이다.

9. Anthropic 시대에도 스타트업이 필요한 이유

9.1. AI가 해결하지 못하는 아이디어와 취향

1. Anthropic에 합류한 동기

   1. Krieger가 Anthropic에 합류한 주요 이유는 모델이 코드에 능숙해지는 과정에서 차세대 스타트업을 대량으로 가능하게 만들 것이라고 봤기 때문이다.
   2. AI는 아이디어를 떠올리는 감각이나 어떤 제품이 좋은지 판단하는 taste를 자동으로 해결하지 않는다.
   3. 하지만 실험을 훨씬 단순하게 만들고, 아이디어를 실제 결과물로 옮기는 시간을 크게 줄인다.

2. Instagram과 Google Photos의 비유

   1. Instagram 시절 투자자들은 Google이 사진 제품을 내놓으면 어떻게 할지 물었다.
   2. Krieger의 답은 Google이 매우 “Google다운” 사진 제품을 만들 것이며, 기존 Google 통합과 강점에 묶여 그 방식으로 경쟁할 것이라는 것이었다.
   3. 거대한 플랫폼은 강력한 자원을 갖지만, 이미 보유한 통합·조직·제품 논리의 영향을 받는다.
   4. 스타트업은 거대 플랫폼과 똑같이 만들기보다 자기만의 강점을 집요하게 밀어붙여야 한다.

9.2. Vertical과 사용자 사랑의 방어력

1. Labs가 얻기 어려운 도메인 이해

   1. Anthropic은 platform이므로, 특정 vertical·산업·소수 사용자 집단에 레이저처럼 집중할 수 있는 여지가 크다.
   2. 모델을 만드는 Labs가 각 산업의 세부 맥락과 사용자의 일상적 불편을 모두 깊이 이해하기는 어렵다.
   3. 특정 집단을 오래 관찰하고, 그들의 표현·workflow·구매 경로까지 아는 팀은 사용자 사랑과 채택률에서 우위를 얻는다.

2. 모델이 강해져도 남는 어려운 일

   1. 모델이 많은 일을 수행하면서 일부 기능은 skill로 일반화되고 독립 제품이 필요 없어질 수 있다.
   2. 그럼에도 사람의 실제 필요를 이해하고, 어디에서 사용자를 만나며, 이야기를 듣고, 빠르게 반복 개선하는 일은 여전히 어렵다.
   3. 네댓 명이 하나의 문제에 집요하게 몰입하면, 같은 사람들이 복잡한 대형 조직 안에서 일할 때보다 빠르게 움직일 수 있다.
   4. Anthropic 같은 Labs의 플랫폼 역량은 스타트업의 특정 문제 집착을 없애기보다, 그 집착을 구현하는 속도를 높인다.

3. 코드는 한계 병목이 아니었다

   1. 코드 작성은 일정 관점에서 시간을 잡아먹었지만, 스타트업의 성패를 가르는 궁극적인 제한 요소는 아니었다.
   2. 진짜 차이는 문제 공간과 사용자를 얼마나 잘 이해하는지에서 난다.
   3. AI가 코드를 거의 즉시 만들 수 있게 될수록 domain knowledge, distribution, listening, taste가 더욱 선명한 경쟁력이 된다.

10. Vertical AI, 특히 금융 분야의 설계 과제

10.1. 세대마다 좋아지는 금융 use case

1. 모델 성능의 진화

   1. 금융 분야는 모델 세대가 바뀔 때마다 실제 use case 성능이 뚜렷하게 좋아지는 영역이다.
   2. 이미 일부 vertical 금융 스타트업은 자체 eval을 만들고 특정 업무에 맞춘 성능을 추적하고 있다.
   3. Anthropic은 그 eval의 변화 자체를 금융 업무에서 모델이 실제로 나아지고 있는지 판단하는 유용한 barometer로 본다.

2. 일반 모델과 vertical 시스템의 관계

   1. Anthropic이 vertical 금융 스타트업의 eval을 그대로 따라가는 것은 아니지만, 현장 성능을 확인할 기준으로 참고할 수 있다.
   2. 범용 모델의 유연성과 산업별 시스템의 검증·정확성을 조합하는 것이 중요하다.
   3. 금융 사용자는 단순히 자연스러운 답변보다 근거와 재현 가능한 결과를 원한다.

10.2. 자유로운 생성과 검증된 데이터의 cutline

1. Just-in-time 분석의 장점

   1. 모델은 필요할 때 즉석에서 분석, dashboard, workflow를 만들어 낼 수 있다.
   2. 사용자가 미리 모든 경우의 수를 제품 기능으로 정의하지 않아도, 모델이 현재 질문에 맞는 결과물을 구성할 수 있다.
   3. 이 자유도는 금융 전문가가 고정된 보고서 밖의 질문을 탐색하게 해 준다.

2. 완전한 자유 형식의 위험

   1. 데이터 집합 전체를 아무 제약 없이 자유롭게 다루게 하면 혼란이 생긴다.
   2. 금융 서비스 회사 대부분은 어떤 데이터가 검증됐고, 어디서 왔고, 누가 언제 사용했는지 확인할 수 있어야 한다.
   3. 검증 가능한 데이터의 기준을 없애면 agent가 만든 dashboard와 workflow를 감사하거나 재현하기 어렵다.

3. 필요한 균형점

   1. verifiability, audit logging, data provenance를 확보하면서도 그 기준이 위에서 만들 수 있는 application의 종류를 과도하게 제한하지 않아야 한다.
   2. 검증 계층은 단단하게 두되, 그 위의 agentic workflow는 유연하게 만드는 것이 설계의 핵심이다.
   3. 현재 검증을 위해 구축된 많은 시스템은 agent가 그 위에서 일하기에는 태생적으로 유연하지 않다.
   4. 따라서 기초 데이터·감사 계층과 그 위의 agent/application 양쪽 모두에 혁신의 기회가 있다.

11. 빠른 산업에서 버티는 정신 건강

11.1. 996을 견디는 첫 번째 방법: 실제로 오프라인 되기

1. 속도가 만든 압박

   1. AI 산업은 과거 Instagram보다도 여러 배 강하고 빠르게 움직인다.
   2. Instagram에서는 Apple이 WWDC에서 무엇을 발표할지, 그것이 Instagram을 망치거나 도울지를 주로 1년에 한 번 걱정했다.
   3. 경쟁사의 큰 출시는 3~4개월마다 찾아왔지만, AI 업계에서는 모델·제품·규제 관련 변화가 거의 매주 발생한다.
   4. Anthropic의 수요일 weekly all-hands에는 weekend AI라는 괄호 속 슬라이드가 있는데, 아직 수요일인데도 그 주말 이후 새 모델·제품 또는 규제 이슈가 이미 생겨 있다.

2. 휴식이 선택 사항이 아닌 이유

   1. Krieger는 일부러 time off를 일정에 넣는 것이 상대적으로 제정신을 유지하는 첫 번째 방법이라고 했다.
   2. Co-founder는 번아웃이 오면 사실상 업무가 끝난다는 사실을 잘 알고 있어, 서로 쉬도록 강하게 권해야 한다.
   3. 가까운 사람에게 번아웃이 실제로 발생한 뒤 회복에 오랜 시간이 걸리는 경우를 봤다.
   4. 며칠간 offline일 수 없는 직업이라면, 그 일 자체의 설계나 우선순위가 잘못됐을 가능성이 높다.

11.2. 스포츠와 스타트업의 장기전 관점

1. 최고의 경기와 최악의 경기 사이

   1. Krieger는 스포츠에서 “최고의 경기만큼 잘하는 것도 아니고, 최악의 경기만큼 못하는 것도 아니다”라는 감각을 좋아한다.
   2. AI 업계의 “이제 다 끝났다”와 “우리가 완전히 돌아왔다”가 반복되는 주기도 같은 원리로 바라볼 수 있다.
   3. 어느 날의 모델 출시와 시장 반응이 전체 현실을 대표하지 않는다.

2. ‘We’re effed’의 순간을 통과하기

   1. Ben Horowitz의 『The Hard Thing About Hard Things』에는 “We’re effed, it’s over”라고 느끼는 순간을 다루는 장이 있다.
   2. 스타트업에서는 큰 사건 하나가 회사의 회복을 불가능하게 만든 것처럼 느껴질 때가 있다.
   3. Instagram도 그런 순간을 여러 번 겪었지만 결국 통과했고, 그 경험이 회사를 정의하는 일부가 됐다.

3. 오늘의 launch보다 긴 게임

   1. Anthropic의 경쟁은 오늘의 model launch나 product launch의 반응만으로 끝나지 않는다.
   2. 빠르게 움직이면서도 장기적으로 살아남을 팀과 문화를 쌓는 게임이다.
   3. 3개월 전에도 비슷한 위기에 있었음을 돌아보며 시야를 넓히면, 현재의 위기가 전부가 아니라는 사실을 확인할 수 있다.
   4. 개인의 자아감과 성공감을 하루 단위의 성과와 시장 반응에 전부 묶지 않는 것이 중요하다.

11.3. 감정을 말로 꺼내 조직의 공간 만들기

1. 코치에게 받은 핵심 조언

   1. 자신이 어떤 감정을 느끼고 있다면, 팀의 다른 사람도 비슷한 감정을 느끼고 있을 가능성이 높다.
   2. 감정을 숨기고 곧바로 해결책만 찾으려 하기보다 “이 일 때문에 정말 스트레스를 받고 있다”고 먼저 말해야 한다.
   3. 감정을 명시하면 다른 구성원도 자신의 감정을 표현할 수 있는 공간이 열린다.

2. Labs initiative를 닫던 실제 사례

   1. Krieger는 몇 달 전 열심히 작업하던 Labs initiative를 종료하는 회의를 시작하며 “이 일이 잘되지 않아 정말 슬프고 좌절했다”고 먼저 말했다.
   2. 그러자 다른 사람들도 “나도 화가 난다”, “나도 슬프다”고 말할 수 있었다.
   3. 감정을 숨기지 않고 공유한 뒤에야 “이제 무엇을 할 것인가”라는 실질적인 질문으로 이동할 수 있었다.

3. 지속 가능한 shipping의 조건

   1. 취약성을 보이는 리더는 실패나 종료를 개인의 가치와 분리할 수 있게 한다.
   2. 팀은 감정을 인정한 뒤 다음 bet으로 이동할 힘을 얻는다.
   3. 정신 건강을 관리하면서 계속 ship하는 능력이 빠른 Labs 조직의 장기 경쟁력이다.

주요 발언 모음

“Be unreasonable.”

“작업을 하나씩 위임하는 데서 최종 상태를 표현하고, 가서 요리하도록 맡기는 쪽으로 이동했다.”

“모델이 아이디어나 취향까지 해결해 주는 것은 아니지만, 실험을 훨씬 단순하게 만들고 더 빠르게 움직이게 해 준다.”

“가장 어려운 일은 바다 전체를 한 번에 끓이지 않고 어디에서 점진적으로 시작할지 찾는 것이다.”

“코드처럼 보이는 2,000줄보다 변경의 의도와 트레이드오프를 공유하는 편이 더 중요하다.”

“Engineering Manager discipline의 죽음은 크게 과장됐다.”

“작동하지 않는 프로젝트를 닫는 것은 Labs의 의도이며, 프로젝트 종료가 곧 개인의 실패는 아니다.”

“네댓 명이 하나의 문제에 집요하게 몰입하는 힘은 여전히 강력하다.”

“최고의 경기만큼 잘하는 것도 아니고 최악의 경기만큼 못하는 것도 아니다.”

“자신이 느끼는 감정을 말로 꺼내면, 다른 사람들도 자신의 감정을 말할 수 있는 공간이 열린다.”

핵심 데이터·수치

• 영상 길이: 25분 41초(yt-dlp duration 1541초 기준)다.
• 발행일: 2026-08-29다.
• Anthropic 내부 코드 사용 비중: Tag 기반 방식으로 작성되는 코드가 60%대라는 언급이 있다.
• Feature flag 규모: 하나의 앱에 약 3,000개의 flag가 존재할 수 있다.
• Instagram의 저사용률 기능: 개별 기능이 4~5% 사용률이어도 20개가 누적되면 제품 전체 복잡성이 크게 증가한다.
• Labs review cadence: 모든 프로젝트를 2주마다 persevere or pivot으로 심사한다.
• Instagram 경쟁 환경의 과거 속도: 큰 경쟁사 출시는 대략 3~4개월마다 나타났다.
• AI 산업의 정기 변화: Anthropic weekly all-hands에서 매주 새 모델·제품·규제 변화를 확인할 정도로 변화가 빠르다.
• Instagram 레거시 변환 사례: Python runtime type을 production에서 수집해 codebase의 type annotation으로 되돌리는 MonkeyType을 사용했다.
• 대규모 AI 포팅 사례: 수십만 줄 규모의 Python Labs 프로젝트를 주말 동안 TypeScript로 포팅하고 검증·배포 가능한 workflow로 만들었다.
• 초기 Instagram 장애: 출시 첫 주 backend가 감당하지 못해 시스템이 녹아내리는 장애를 겪었다.

결론 및 시사점

1. 목표를 위임하고 판단을 검증하라: AI 시대의 고부가가치 업무는 구현 순서를 모두 지시하는 데서 목표·제약·성공 조건을 정의하고 결과의 의도와 trade-off를 검증하는 쪽으로 이동한다.
2. 비합리적인 범위를 시도하라: 수십만 줄 codebase 포팅처럼 과거에는 말이 안 되던 요청도 production data·segmented test·자동 검증 workflow를 갖추면 현실적인 실험이 된다.
3. 운영 기반을 먼저 만들라: metric을 미리 측정하고 feature flag·knob·dynamic configuration·rollout을 first-class capability로 두면 실험 속도와 장애 대응력을 동시에 얻는다.
4. AI를 동료로 설계하라: 맥락·memory·feedback channel을 바탕으로 먼저 행동하는 AI는 단순한 채팅창보다 teammate에 가깝고, multiplayer·비동기 협업 구조와 결합할 때 활용도가 커진다.
5. 의도와 결과를 코드와 분리해 검토하라: Artifact·설명·trade-off 기록·production 측정을 통해 2,000줄의 구현을 사람이 줄 단위로만 읽는 병목을 줄여야 한다.
6. 조직은 실험에 맞춰 느슨하게, 성공에 맞춰 단단하게 만들라: 2주 단위 bet과 DRI로 실험 속도를 유지하고, traction이 확인된 제품에만 전담 팀과 고정된 구조를 붙여야 한다.
7. 삭제할 용기를 가져라: 사용률이 낮거나 prescriptive한 primitive는 다음 세대의 Skills 같은 더 나은 경로로 교체하고, Claude Code·Co-work·Chat 사이의 불필요한 제품 복잡성을 흡수해야 한다.
8. 스타트업의 핵심 방어력은 도메인 이해다: 모델이 코드를 빠르게 만들수록 특정 사용자·산업·workflow를 깊이 아는 팀의 taste, distribution, 사용자 사랑이 더 중요해진다.
9. 금융 AI는 자유도와 감사 가능성을 함께 설계하라: just-in-time 분석의 유연성 위에 verified data, provenance, audit logging을 놓아 agentic application이 신뢰성과 확장성을 동시에 갖게 해야 한다.
10. 장기전을 위한 휴식과 감정 표현을 운영 규칙으로 삼아라: 며칠간 offline할 수 있는 구조를 만들고, 불안·슬픔·좌절을 공개적으로 말한 뒤 다음 행동으로 이동해야 빠른 산업에서 계속 shipping할 수 있다.

핵심 요약 (20줄)

Mike Krieger는 Anthropic에서 CPO에서 IC로 역할을 바꾸며 모델을 직접 활용하는 시간을 늘렸다. 모델이 강해질수록 작업 단계를 세세하게 지시하기보다 원하는 최종 상태를 설명하는 방식이 효과적이다. Claude는 목표를 받은 뒤 구현과 탐색을 진행하고 사람에게 드러난 트레이드오프와 질문을 되돌려준다. AI 제품팀은 비기술자도 모델에게 직접 변경을 요청하도록 가르치며 unreasonable한 활용을 장려해야 한다. 도구 접근과 실행 환경을 제한한 초기 AI 제품은 모델과 사용자의 야심을 함께 좁혔다. 가상 머신과 스크립트 실행 권한은 PDF 파싱 실패처럼 예상 밖의 문제를 모델이 우회하게 한다. 수십만 줄 Python 프로젝트를 TypeScript로 주말에 포팅한 사례는 AI 시대의 새로운 실험 범위를 보여준다. MonkeyType은 production runtime type을 수집해 실제 데이터에 기반한 코드 변환과 annotation을 가능하게 했다. 대규모 변환은 전체 시스템을 한 번에 바꾸지 말고 production data와 segmented test로 점진적으로 진행해야 한다. 초기 Instagram 장애는 필요한 metric을 미리 측정하고 feature flag와 dynamic configuration을 갖추라는 교훈을 남겼다. Anthropic 내부의 Tag 기반 방식은 많은 사람이 Claude를 비동기적이고 선제적인 teammate로 활용하게 한다. AI 협업의 다음 단계는 버그 하나를 고치는 일을 넘어 codebase와 feedback channel의 책임을 Claude에게 맡기는 것이다. 코드 리뷰의 진짜 병목은 줄 수보다 사람이 변경의 의도와 아키텍처를 완전히 이해하는 능력이다. Claude Code Artifact는 코드와 함께 변경 의도와 trade-off를 전달해 인간 주도 review를 돕는다. Labs는 2주마다 프로젝트를 persevere 또는 pivot으로 심사하고 실패한 실험을 정상적으로 종료한다. 제품에 traction이 생기기 전에는 pod를 느슨하게 유지하고 성공이 확인된 뒤 전담 팀과 구조를 붙인다. Claude Design은 Claude Code와의 상호작용을 통합하고 디자인과 persistence를 가진 앱의 경계를 흐리는 방향으로 발전한다. AI 스타트업의 경쟁력은 코드 생성보다 특정 도메인과 사용자에 대한 깊은 이해와 집요한 실행에 있다. 금융 AI는 자유로운 분석 능력과 검증된 데이터·감사 로그·출처 추적을 함께 제공해야 한다. 빠른 산업에서 오래 shipping하려면 정기적인 오프라인 시간과 감정을 말로 표현하는 조직 문화가 필수다.