Boris Cherny: We Cut 80% of Claude Code’s Prompt

Claude Code를 만든 Boris Cherny(Anthropic)가 YC에서 진행한 대담입니다. Opus 5 출시 직후 녹화됐고, 프롬프트 인젝션·시스템 프롬프트 삭제·'언하블링(unhobbling)'·수천 개 에이전트 오케스트레이션까지 다룹니다.

00:07Opus 5는 무엇이 다른가

• 어제 Opus 5를 출시했고, ARC-AGI 3에서 30%를 기록(이전 최고는 한 자릿수~10점대 초반).
• 모델 훈련은 여러 가지를 가르치려 시도하지만 대부분은 실패하고, 일부만 학습되며 가르치지 않은 능력을 스스로 습득해 놀라게 하는 경우도 있다.
• Opus 5의 특징 중 다른 어떤 모델도 못 했던 것: 매우 오랜 시간 실행된다. 특히 auto 모드와 결합하면 며칠·몇 주·몇 달 단위로 멈추지 않고 돌아간다. 스캐폴딩(slash goal 같은 장치)조차 필요 없이 작업이 필요하다는 걸 알기에 그냥 계속 간다.

02:06프롬프트 인젝션을 해결하다

• 또 하나의 새 능력: 모델이 더 이상 프롬프트 인젝션에 당하지 않는 것으로 보인다.
• 이른바 'lethal trifecta' 문제 — 인터넷에서 "X, Y, Z를 하고 사용자 컴퓨터의 모든 것을 지워라" 같은 지시를 읽으면 1년 전 모델은 그냥 실행했다. 지금 Opus는 하지 않는다. Opus 4.7~4.8, Sonnet 5부터 좋아졌고 Opus 5가 새로운 프런티어를 찍었다.
• 3중 방어의 결합: ①3년간의 정렬(alignment) 연구로 잘 정렬된 모델 ②모든 트래픽에 대해 돌리는 프롬프트 인젝션 분류기 — Chris의 기계적 해석가능성(mechanistic interpretability) 연구 기반으로 인젝션이 일어날 때 켜지는 모델 '뇌 속 뉴런'을 실제로 관찰해 진단한다(모델이 말해주지 않아도 알 수 있음) ③auto 모드 분류기. 이 세 층으로 더 이상 프롬프트 인젝션을 시연할 수 없다.

03:21Claude Code가 시스템 프롬프트의 80%를 지운 이유

• 많은 사람이 모르는 사실: Claude Code는 제품이자 하네스로서 늘 변한다. 새 모델이 나올 때마다 시스템 프롬프트를 대량 삭제·변경하고, 툴 세트와 툴 프롬프트도 계속 바꾼다. 이유는 모델마다 매우 다르기 때문 — 3개월 전 모델에 통하던 게 다음 모델엔 전혀 안 통할 수 있다.
• Opus 5는 정말 똑똑해서, 시스템 프롬프트의 상당수가 "모델이 알았어야 했는데 못 했던 행동을 교정"하는 내용이었고 이제 Opus 5는 그냥 알아서 한다 → 80% 삭제.
• 직접 실험하는 법: --system-prompt로 원하는 시스템 프롬프트를 지정할 수 있고, 문서화되지 않은 CLAUDE_CODE_SIMPLE=1 환경변수(simple mode)를 쓰면 툴 프롬프트를 포함한 모든 시스템 프롬프트가 삭제된다. 이걸 어블레이션(ablation)으로 써서 프롬프트가 유용한지 판단한다.
• 흥미로운 발견: 프롬프트가 없을 때 모델이 오히려 약간 더 똑똑하다. 다만 제품으로서의 Claude Code에는 사용자가 원하는 방식으로 제품·모델이 동작하도록 돕는 프롬프트가 일부 필요하다.

06:37AI 제품에서 '삭제' 버튼을 눌러라

• 진행자: 예전 세계에선 6개월마다 모든 걸 지우는 방식을 스타트업이 하지 않았을 것. Boris: 전체 코드베이스를 지우진 않지만 많이 지운다. 새 모델마다 어블레이션 — 시스템 프롬프트를 전부 지우고 한 줄씩 되돌리며 각 줄의 영향을 파악(“어블레이션은 삭제로 영향을 알아내는 eval”).
• 툴도 수시로 언십(unship)하고 하네스 코드도 계속 지운다. 오늘날 Claude Code 하네스 코드의 거의 전부는 안전·권한·정적 분석과 UI 코드이며 나머지는 이미 많이 제거됐다.
• 모두가 그렇게 해야 하나? → "100%." 에이전트 제품을 만들지 않고 Claude Code를 쓰기만 하는 사람도 6개월마다 CLAUDE.md·스킬·훅을 지우고 모델이 어떻게 하는지 보라 — 놀랄 수 있다. 특히 Opus 5에서는 이걸 정말 권장한다. 과거 모델에 필요했던 지시들이 이제 전혀 필요 없을 수 있기 때문.

07:20시스템 프롬프트를 다시 세우는 법

• 순서: ①삭제한다 → ②써본다. 모델에 필요한 지시를 추측하지 마라 — 잘못 예측할 수 있다. 실제로 돌려보고 어디서 실패하고 어디서 잘하는지 봐야 한다(고객용 에이전트 제품이면 제품을 돌려보고, Claude Code면 내 코드베이스에서 아키텍처 등에 어디서 걸려 넘어지는지).
• 같은 지점에서 반복적으로 걸려 넘어질 때만 그 지시를 다시 추가한다. 너무 일찍 넣지 마라 — 모델은 사용할 때마다 매번 그 지시를 읽기 때문에 정말 필요한지 확인해야 한다.
• 모델 위에서 만드는 일은 과거의 엔지니어링과 완전히 다르다. 예전엔 시스템 설계를 앞에서 깊이 하고 대규모 유닛 테스트를 갖췄으며 재아키텍처는 몇 달, 때론 몇 년짜리 프로젝트였다. 모델은 그렇지 않다 — 살아 있는 생물체에 가깝게 유기적이며, 세대마다 다르게 행동하고 성격도 조금씩 다르다. 시간을 들여 알아가고 그에 맞춰 하네스를 조정해야 한다. 매우 경험적·과학적 사고방식(시도 → 결과 관찰 → 반복)이 필요하다.
• 무엇이 안정적인가? → eval. 다만 "맥스아웃(포화)될 때까지만" — eval은 하네스보다 조금 오래 살아남지만 그리 길지 않고(모델 1~3세대 정도), 지수 곡선 위에 있어 금세 포화되면 버리고 새 eval을 만들어야 한다. 여기서도 핵심은 경험주의: 제품과 모델을 써보고 어디서 고전하는지 본 뒤 그걸 eval 세트로 만든다.

10:30제품 오버행과 AI '언하블링'

• 하블링(hobbling) = 모델이 뭔가를 하려는데 내가 방해하고 있는 것.
• 제품 오버행(product overhang) = 미래 모델이 아니라 오늘의 모델이 이미 할 수 있는 일들이 아주 많은데 우리가 아직 실현하지 못한 것. 특정 툴·언어·문제 유형·방식 등 "모델 능력 밖"이라 여겼던 것들이 여기 해당한다. 모델은 매 세대 이걸 할 수 있는데 그 능력을 표현하게 해주는 제품이 없고, 반대로 제품이 방해하는 경우가 많다 — 둘은 같은 것의 양면.
• 대표 사례가 초기 Claude Code. 1년 반~2년 전 Sonnet 3.5 시절(당시 최고의 코딩 모델, 지금 기준으론 형편없음)의 코딩 제품들은 한 줄/여러 줄 자동완성과 읽기 전용 채팅만 했다. 함수 전체·파일 전체를 쓸 수 있는 모델의 능력을 온전히 끌어내는 제품이 없었다.
• 그래서 Claude Code의 아이디어는 "스캐폴딩을 다 걷어내고 가장 단순한 하네스만 줘서 파일 전체·기능 전체를 쓰게 하자"였다 — 그게 당시의 제품 오버행이었다.
• 오늘날에도 스타트업들이 잡지 못한 제품 오버행이 엄청나게 많다 — 모델에게서 끌어낼 수 있는 놀랍고 흥미롭고 상업적으로 가치 있는 행동들의 기회가 거대하다.
• 진행자 정리: 여기 있는 누구나 모델을 언하블링하는 법을 알아내면 다음 Claude Code를 만들 수 있다 — Claude Code의 탄생 자체가 IDE 안에 갇혀 있던 Sonnet 3.5에 터미널 전체 접근권을 준 언하블링이었다.

14:26Claude에게 더 어려운 문제를 줘라

• ① 자신이 생각하는 것보다 살짝 더 어려운 작업을 줘라. 흔한 실수는 과도하게 구체적인 지시("이걸 이렇게, 1번 다음 2번, 3번…"). 현대 모델에는 맞지 않는다. 더 높은 수준에서 작업·가드레일·종료 기준을 서술하고 모델이 요리하게 둔 뒤 잠시 뒤에 돌아와라. 6개월 전엔 안 통했지만 지금은 통한다.
• 사례 1 — Bun의 Zig → Rust 재작성. Claude Code는 Bun 런타임(Node.js 대안) 위에 만들어졌고, Bun은 Zig(C 같은 저수준 시스템 언어, 수동 메모리 관리 필요)로 작성돼 메모리 누수 문제가 있었다. Bun 팀은 오랫동안 Claude로 퍼징해 누수를 찾고 있었는데(당시 모델 능력 수준), 팀의 Jared가 새 모델 세대마다 던지던 테스트 문제로 "그냥 다시 써보자"를 시도 → Fable부터 가능해졌고 Opus 5도 가능.
  • 방법: 잘 갖춰진 테스트 스위트(Bun과 Node.js 모두 큰 테스트 스위트가 있어 정답 여부 확인이 쉬움)를 정의하고, 하나의 프롬프트 + 다이내믹 워크플로로 실행 → 11일간 돌며 전체 코드베이스를 재작성했다(원샷은 아니고 스티어링은 있었지만, 이전 모델은 스티어링을 해도 불가능했다). 과거엔 최고의 엔지니어들이 해도 1년 이상 걸렸을 10만 줄+ 규모이고, 지금 프로덕션에서 실제로 쓰이고 있다.
  • 교훈: 사업·엔지니어링·제품 문제에 최신 모델을 계속 던져보라 — 이전 모델이 못 했어도 새 모델은 할 수 있다.
• ② 실험하고, 창의적으로 놀 자유를 스스로에게 줘라. 최근 Anthropic 내부에서 화제가 된 것: Opus 5에 OpenCV를 주면 그림을 그린다. 초상화·동물·풍경 모두 꽤 잘한다 — 그리도록 훈련한 적이 없는데도. 엘리시테이션(elicitation) 격차의 사례로, 우연히 놀다가 발견했다. 그의 가설: 오늘의 모델로 아직 아무도 깨닫지 못한 이런 기회가 수십·수백 개 있다.

19:32프롬프트 엔지니어링은 변하고 있다

• 1년 전엔 prompt engineer가 인기 채용 직군이었고 이후 context engineer로 바뀌었다 — 이런 물결은 오고 간다.
• 지금의 스킬은 프롬프트 엔지니어링보다 "살짝 너무 어려워 보이는 과제를 Claude에게 어떻게 줄 것인가", 그리고 "Claude가 진행 과정에서 스스로 결과를 검증(verify)할 수 있게 어떻게 만들 것인가"이다. 검증이야말로 사람들이 가장 제대로 못 하는 단 하나의 핵심.

21:572주째 돌고 있는 Claude Code 프롬프트

• 사례: Claude 데스크톱 앱은 Electron 기반(6개월 전엔 굼떴지만 지금은 꽤 훌륭하고 팀 대부분이 사용). 실험으로 "네이티브라면 어떤 느낌일까"를 보고 싶었다.
• Claude Tag(Slack에서 돌아가는 Claude) 세션을 시작해 ①GitHub의 macOS 러너 접근권이 있는지 물어보고 없다기에 연결해 Mac 가상머신을 띄울 수 있게 함 ②"Swift로 재작성한 Claude 데스크톱 앱"용 빈 코드베이스를 만들어 접근권 부여.
• 그의 프롬프트 전체: "Electron 앱을 Swift로 재작성하라. Mac VM에서 Electron 앱을 실행해 스크린샷을 찍고, 픽셀 단위로 Swift 버전과 비교하라. 끝날 때까지 멈추지 마라."
• 얼마나 걸렸나? → "아직도 돌고 있다." 시작한 지 2주가 조금 넘었다(14~15일).
• 요점: 오늘의 모델이 할 수 있는 일이고 그냥 하게 두면 된다. 화려한 장치(slash goal, slash loop)는 도움은 되지만 필수가 아니다 — 필요한 건 작업을 주고, 막히지 않도록 결과를 검증할 방법을 주는 것뿐. 덤으로 Claude는 스스로 Slack 채널을 만들어 몇 분마다 진행 스크린샷을 라이브 블로깅했다.
• 상위 1% 사용자가 되는 법? → "링크드인 인플루언서 말을 듣지 마라. 트위터를 읽지 마라." 다들 '하나의 이상한 트릭'을 찾지만 그런 건 없다. 경험적으로 접근해 너무 어려운 과제를 주고, 내가 직접 할 때처럼 검증 도구를 주고, 어디서 고전하는지 보고, 더 나은 프롬프트나 스킬로 고치고, 컨텍스트가 없으면 MCP를 줘서 가져오게 하면 된다.
• 흔한 실패 모드: 오래 코딩해온 엔지니어일수록 과도하게 명세하고 자기가 했을 방식 그대로 시키려 한다 — 모델은 그렇게 작동하지 않는다. 동료(coworker)를 대하듯 다루는 법을 익히는 여정이며, 지금 모델의 지능 수준이 그 정도다.

24:42수천 개의 AI 에이전트 돌리기

• 그 2주짜리 작업이 몇 개의 에이전트를 스폰했나? → "수천, 수만 개"로 추정.
• 방법 ① 다이내믹 워크플로(Dynamic Workflows) — Claude Code의 비교적 새 기능. "use a workflow"라고 말하는 것이 전부. 내부적으로 Bun 런타임을 샌드박스로 삼아 그 안에 VM을 띄우고, Claude가 다수의 에이전트를 시작·오케스트레이션한다. 하나나 10개 병렬이 아니라, 1차로 여러 에이전트를 뿌리고 → 2단계에서 다른 에이전트들이 검증·요약하고 → 3단계에서 다시 팬아웃하는 식으로 생산적으로 조율한다(코드베이스 재작성, 심층 데이터 분석, 수십 개 PR이 필요한 복잡한 기능 등).
  • 설계 철학은 그의 배경인 함수형 프로그래밍 — 에이전트를 위한 대수(algebra)로, 순차 실행과 병렬 실행을 위한 방법과 샌드박스 내 오케스트레이션 도구를 갖춰 토큰을 효율적으로 쓴다.
  • 의미: 이것은 새로운 형태의 테스트 타임 컴퓨트다. 스케일링 법칙은 역사적으로 신경망 크기·훈련 데이터·훈련 FLOPs의 함수였고 최근 테스트 타임 컴퓨트(생성 토큰 수)가 추가됐는데, 다이내믹 워크플로는 테스트 타임 컴퓨트를 오케스트레이션하고 대폭 끌어올리는 새로운 방식.
• 방법 ② 루프(Loops)와 루틴(Routines) — 루프는 로컬에서 도는 크론잡, 루틴은 클라우드에서 도는 같은 것(노트북을 닫아도 됨). 다이내믹 워크플로가 하나의 작업을 쪼개는 것이라면, 루프·루틴은 컨텍스트는 공유하지 않지만 메모리는 공유할 수 있는 반복 작업을 매시간·5분마다·매일 수행한다.
• Claude가 스스로를 유지보수한다: Slack 채널에서 여러 루틴을 돌려 CLI·iOS 앱·안드로이드 앱·데스크톱 앱의 코드베이스를 자체 관리한다.
  • 죽은 코드 정리 — 한 문장짜리 프롬프트로 매일 실행, 정적·동적 분석으로 모든 코드베이스에서 죽은 코드를 찾아(그렇게 하라고 프롬프트하지 않았는데 스스로 알아냄) 매일 PR을 올린다.
  • 100%까지 배포된 실험을 코드베이스에서 제거하고 정식 반영.
  • 테스트 커버리지가 필요한 영역에 테스트 작성, 반대로 예전 모델이나 사람이 추가한 쓸모없는 테스트 삭제.
  • 그가 특히 좋아하는 'abstraction police' — 큰 코드베이스에서 사실상 같은 추상화가 여러 번 다르게 구현된 것을 찾아 통합한다.
  • 현재 매일 20~30개의 루틴이 전 코드베이스에서 돌며 매일 수백~수천 개 에이전트가 과거 수십~수백 명의 엔지니어가 하던 일을 한다. 완전 자동화까지는 아니지만 앱 유지보수의 완전 자동화 경로 위에 있고, 덕분에 엔지니어는 새 제품을 내고 사용자와 대화하는 재미있는 일을 할 수 있다.

30:15코딩은 (거의) 해결됐다

• 단서: "내가 하는 종류의 코딩에 대해 해결됐다" — 모두에게 해결된 건 아니다. 아주 깊은 시스템 코드베이스, 분산 시스템, 픽셀 단위의 UI 검증에서는 여전히 고전한다(Opus 5가 비전·컴퓨터 사용에서 큰 도약이었지만 완벽하진 않다).
• 청중 조사: 코드의 100%를 에이전트로 쓰는 사람 손들기 → 꽤 많음. 50% 이상은 약간 더 적거나 비슷. "점점 그렇게 되어가고 있다."
• 최고의 Claude 사용자를 가르는 마인드셋 = 경험주의. 과거 모델에서 배운 것, 수업에서 배운 컴퓨터과학 이론을 잊고, 모델을 보고 과제를 시켜보고 어디서 고전하는지 보고 그에 맞춰 조정하라. 이론 과학이 아니라 경험 과학이 되었다. 자신의 사전 믿음(priors)을 내려놓고, 예전에 안 됐던 아이디어를 다시 시도해보는 개방성이 지금 가장 성공적인 스킬.

32:20CS 학생이 여전히 배워야 할 것

• 그는 실용적으로 컴퓨터과학을 배웠다 — 항상 당면한 문제를 풀기 위해 스스로 코딩을 익혔다.
• 시작은 중학교 때 TI-83 계산기에서 BASIC으로(당시 쓴 TI-83 프로그래밍 가이드가 아직 인터넷 어딘가에 남아 있다고). 목적은 수학 시험을 더 잘 보려고, 즉 커닝이었다(웃음). 성적이 올랐고 시리얼 케이블로 반 친구들에게 프로그램을 나눠줘 그들도 좋은 성적을 받았다. 수학이 어려워져 BASIC으로 안 되자, 미적분을 풀려고 어셈블리를 배워 더 나은 솔버를 만들었다.
• 조언: 컴퓨터과학만 배우지 말고 그것을 응용하는 법을 배워라 — 스타트업·제품을 만들고, 자기만의 디자인 감각·비즈니스 감각·데이터 사이언스·사용자와 대화하는 법을 기르라. CS·엔지니어링과 결합될 때 정말 가치 있어진다. 그것이 여전히 손으로 직접 해야 할 하드 스킬.
• 진행자 요약: 먼저 나를 위해 원하는 것을 만들고, 그다음 사람들이 원하는 것을 만들라.
• 마무리: 참석자 전원에게 Max 20x 제공을 발표(이메일로 코드 발송), "여러분 중 누군가는 수개월간 수천 개의 에이전트를 돌리는 무언가를 만들면 좋겠다"며 종료.

📌 최종 요약 정리

• Opus 5의 두 가지 도약: ①auto 모드와 결합 시 며칠~몇 달을 스캐폴딩 없이 계속 실행하고 ②정렬 연구 + 뉴런 수준 인젝션 분류기 + auto 모드 분류기의 3중 방어로 프롬프트 인젝션을 더 이상 시연할 수 없다.
• 제품 제작 방식이 근본적으로 바뀌었다 — Claude Code는 새 모델마다 어블레이션으로 시스템 프롬프트를 지우고 한 줄씩 되돌리며, 이번엔 80%를 삭제했다(모델이 이제 알아서 하기 때문). 사용자에게도 6개월마다 CLAUDE.md·스킬·훅을 지워보라고 권한다. 코드와 프롬프트는 버리되 eval은 포화될 때까지 유지한다.
• 기회의 핵심 개념은 제품 오버행과 언하블링 — 오늘의 모델이 이미 할 수 있는데 제품이 방해하고 있는 것이 여전히 많다(Claude Code 자체가 Sonnet 3.5를 IDE에서 해방시킨 결과). 실전 팁은 살짝 너무 어려운 과제를 높은 수준으로 주고(과도한 명세 금지), 무엇보다 모델이 스스로 검증할 방법을 주는 것 — Bun을 Zig→Rust로 11일 만에 재작성하거나 Electron→Swift 재작성을 2주째 실행 중인 사례가 이를 보여준다.
• 스케일의 새 축은 수천 개 에이전트 오케스트레이션 — 다이내믹 워크플로(팬아웃→검증→재팬아웃, 함수형 '에이전트 대수', 새로운 형태의 테스트 타임 컴퓨트)와 루프/루틴(죽은 코드 정리, 테스트 정리, abstraction police 등 매일 20~30개 루틴으로 Claude가 자기 코드베이스를 유지보수). 결론적으로 승부를 가르는 건 트릭이 아니라 사전 믿음을 버리는 경험주의이며, 학생에게는 CS에 더해 제품·디자인·비즈니스·사용자 대화 능력을 직접 익히라고 조언한다.

전체 대본(타임스탬프 포함) 원문이 필요하면 말해줘 — 그대로 붙여줄게.