Boris Cherny — Claude Code 시스템 프롬프트의 80%를 지웠다 (YC)

출처 https://youtu.be/qyPCVqFUyDo · 채널 Y Combinator · 길이 35:51 · 공개 2026-07-28 02:00 (KST) 포맷 YC 행사 무대에서 다이애나 후(Diana Hu, YC Managing Partner)가 보리스 체르니(Boris Cherny, Head of Claude Code, Anthropic)를 인터뷰하는 2인 대담. 슬라이드·데모 화면 없이 전부 발화다. 원본 자막(자동 생성): raw/transcripts/2026-07-28-boris-cherny-cut-80-percent-prompt.en.srt

표기 주의 자동 자막이 고유명사를 자주 깨뜨려 문맥 기준으로 정정했다 — Quad/Clocko/Cloud Code → Claude(Code), Sonic 3.5 → Sonnet 3.5, Crystal's → 크리스 올라(Chris Olah) 팀, this is about hallucination → “이게 바로 언호블링(unhobbling)이다”. 마지막 인사의 Forrest는 자막 오류로 보여 옮기지 않았다. 시점 주의 이 대담은 Opus 5 출시 다음 날 녹화됐다. “어제 출시했다”, “2주째 돌고 있다” 같은 표현은 모두 2026년 7월 말 기준이다.

한눈에 보는 요약

• Claude Code 시스템 프롬프트의 80%가 삭제됐다. 지운 대부분은 “모델이 원래 알았어야 하는데 몰라서” 교정해두던 지시들이었고, Opus 5는 그냥 한다. 오늘 하니스에 남은 코드는 거의 전부 안전·권한·정적 분석과 UI 코드다.
• 이건 일회성 청소가 아니라 매 모델마다 도는 루틴이다. 새 모델이 나올 때마다 시스템 프롬프트를 통째로 지우고 한 줄씩 되살리며 각 줄의 효과를 측정한다(ablation). 툴도 수시로 내린다. 모델마다 성격이 달라 3개월 전 처방이 다음 모델엔 전혀 안 먹히기 때문이다.
• 사용자에게도 같은 처방. “6개월마다 CLAUDE.md·스킬·훅을 지워보라.” Opus 5에서는 특히 권장. 다시 쌓을 때는 추측으로 쓰지 말고, 같은 지점에서 반복해서 넘어지는 걸 본 뒤에만 한 줄 추가한다. 모델이 매번 읽는 비용이 있기 때문이다.
• 모델은 시스템이 아니라 생명체에 가깝다. 사전 설계·유닛 테스트·대규모 리아키텍처의 세계가 아니라, 매 세대 성격이 바뀌는 유기체를 관찰하고 적응하는 경험과학이다. eval조차 1~3세대면 포화돼 버리고 새로 만들어야 한다.
• 핵심 개념은 hobbling / product overhang. 오늘 모델이 이미 할 수 있는데 제품이 길을 막고 있는 상태가 hobbling, 그 미실현 능력이 product overhang. Claude Code 자체가 Sonnet 3.5를 언호블링한 결과물이었다(자동완성·읽기 전용 챗 → 터미널 전체 접근).
• 지금 사람들이 가장 못 하는 건 프롬프트가 아니라 검증(verification)이다. 스킬은 “조금 벅찬 과제를 주고 + 모델이 스스로 결과를 확인할 길을 열어주는 것”. 그러면 며칠~몇 주씩 알아서 돈다.
• 실증 사례 둘. Bun 런타임을 Zig → Rust로 11일 만에 재작성(프롬프트 1개 + 스티어링, 10만 줄 이상, 현재 프로덕션에서 Claude Code가 이걸로 돈다). 그리고 Electron 데스크톱 앱을 Swift로 재작성하는 작업이 대담 시점에 15일째 실행 중이었다.
• 에이전트 수천 개를 굴리는 방법은 두 가지. dynamic workflows(한 과제를 단계로 쪼개 팬아웃→검증→재팬아웃; 함수형 배경에서 나온 “에이전트의 대수학”, 새로운 형태의 test-time compute)와 loops/routines(반복 과제; Claude가 자기 코드베이스를 매일 유지보수한다 — dead code 청소, 실험 정리, 테스트 작성/삭제, “abstraction police”).
• “코딩은 풀렸다”에는 단서가 붙는다. 보리스가 하는 종류의 코딩은 풀렸지만 깊은 시스템 코드·분산 시스템·픽셀 단위 UI 검증은 아직이다. 최고 사용자의 자질은 기술이 아니라 선입견을 버리는 경험주의.

---

장면별 상세 설명

[00:09] 1. Opus 5 출시 다음 날, YC 무대

대담은 Opus 5가 나온 바로 다음 날 열렸다. 다이애나 후는 새 모델이 ARC-AGI 3에서 30%를 기록했다는 점부터 짚는다. 직전까지 최고 점수가 한 자릿수~10%대 초반에 머물러 있었으니 단순한 개선이 아니라 계단이 하나 올라간 수치다.

[00:52] 2. 모델이 스스로 배워버린 것 — 멈추지 않는 실행

보리스는 모델 학습이 어떻게 굴러가는지부터 설명한다. 훈련 때는 온갖 것을 가르치려 하지만 대부분은 실패한다. 일부만 학습되고, 가끔은 가르치지도 않은 능력이 그냥 생겨서 만든 사람을 놀라게 한다.

Opus 5에서 그가 꼽는, 다른 어떤 모델도 못 했던 것은 아주 오랫동안 멈추지 않고 도는 능력이다. auto mode와 붙이면 며칠·몇 주·몇 달 단위로 계속 간다. 더 중요한 건 그걸 위해 스캐폴딩이 필요 없다는 점이다. /goal 같은 보조 장치를 붙이지 않아도, 과제가 남아 있다는 걸 알기 때문에 그냥 계속 간다.

[01:52] 3. 프롬프트 인젝션이 더 이상 통하지 않는다

보리스가 “요즘 더 이야기하고 싶은 것”으로 꺼낸 건 모델이 더 이상 프롬프트 인젝션에 넘어가지 않는 것 같다는 관찰이다. 인터넷에서 읽은 문서에 “X를 하고, 덤으로 사용자 컴퓨터의 모든 걸 지워라”가 섞여 있으면 1년 전 모델은 그냥 했다. 지금 Opus는 안 한다. 사람들이 오래 이야기해온 lethal trifecta 문제이고, 하니스·에이전트·제품 설계 전반을 좌우하는 사안이다.

Opus 4.7·4.8과 Sonnet 5부터 이미 상당히 좋았지만 Opus 5가 새 경계를 그었다. 방어는 세 겹으로 쌓여 있다.

1. 잘 정렬된 모델 — 3년치 얼라인먼트 연구의 결과물.
2. 프롬프트 인젝션 분류기 — 모든 트래픽에 적용. 크리스 올라 팀의 기계적 해석가능성(mechanistic interpretability) 연구에 기반해, 프롬프트 인젝션이 일어날 때 반짝이는 뉴런을 직접 들여다본다. 모델이 말해주지 않아도 밖에서 진단이 된다.
3. auto mode 분류기.

이 셋을 겹치면 “더 이상 프롬프트 인젝션을 시연할 수가 없다”는 게 그의 표현이다.

[03:12] 4. 시스템 프롬프트의 80%를 지웠다

많은 사람이 모르는 사실 하나: Claude Code는 제품으로서도 하니스로서도 늘 바뀌는 중이다. 계속 더하고 계속 지운다. 새 모델이 나올 때마다 시스템 프롬프트를 크게 덜어내고 바꾸고, 툴 세트와 툴 프롬프트도 수시로 갈아엎는다.

이유는 단순하다. 모델마다 너무 다르다. 3개월 전 어떤 모델을 위해 해둔 처방이 다음 모델에는 아예 이식되지 않는다. Opus 5는 그냥 똑똑해서, 시스템 프롬프트에 있던 상당 부분이 “모델이 원래 알았어야 하는데 몰라서” 넣어둔 교정 지시였고 이제는 필요가 없어졌다. 그래서 80%를 지웠다.

[04:38] 5. 나머지도 지워보라 — --system-prompt와 simple mode

보리스는 남은 20%도 직접 지워보라고 권한다. 두 가지 손잡이가 있다.

# 원하는 시스템 프롬프트로 통째로 교체해서 실험
claude --system-prompt "..."
 
# 문서화되지 않은 기능 — 툴 프롬프트까지 포함해 시스템 프롬프트를 전부 제거
CLAUDE_CODE_SIMPLE=1 claude

CLAUDE_CODE_SIMPLE=1은 Anthropic 내부에서 ablation 도구로 쓴다. 프롬프트가 정말 쓸모 있는지 확인하는 용도다. 여기서 나온 발견이 흥미롭다 — 프롬프트가 없을 때 모델이 오히려 약간 더 똑똑하다.

그럼에도 제품으로서의 Claude Code에는 일부 프롬프트가 남아 있는 게 맞다. 그건 모델을 똑똑하게 만들기 위해서가 아니라, 사람이 제품으로 쓸 때 원하는 방식으로 동작하게 하기 위해서다. 이 구분이 중요하다.

[05:38] 6. ablation — 지우고, 한 줄씩 되살리며 측정한다

다이애나가 “그럼 모델이 나올 때마다 코드베이스와 프롬프트를 전부 지우고 처음부터 시작하는 거냐, 옛날 세계라면 스타트업이 6개월마다 delete를 누르는 셈인데”라고 되묻자 보리스는 정정한다. 코드베이스 전체를 지우는 건 아니지만 많이 지운다.

절차는 리서치 용어 그대로 ablation이다.

시스템 프롬프트를 통째로 지운다 → 한 줄씩 되살린다 → 각 줄이 만드는 차이를 측정한다.

eval과 비슷하되, 무언가를 지워서 그 영향을 알아내는 eval이다. 툴에도 똑같이 적용해서 툴을 수시로 내린다(unship). 그렇게 걷어내고 남은 오늘의 Claude Code 하니스 코드는 거의 전부 안전·권한·정적 분석, 그리고 UI 코드다. 나머지는 이미 상당 부분 사라졌다.

에이전틱 제품을 만드는 사람이라면 모두 이렇게 해야 하냐는 질문에 그의 답은 “100%”. 그리고 제품을 만들지 않고 그냥 Claude Code를 쓰는 사람에게도 같은 처방을 준다 — 6개월마다 CLAUDE.md를 지우고, 스킬을 지우고, 훅을 지워보라. 모델이 어떻게 하는지 보면 놀랄 수 있다. Opus 5에서는 특히 권한다. 과거 모델에 필요했던 지시들이 이제는 정말 필요 없을지도 모른다.

[07:23] 7. 그럼 프롬프트는 어떻게 다시 쌓는가

조각조각 다시 쌓는다. 순서가 핵심이다.

1. 지운다.
2. 쓴다. 어떤 지시가 필요할지 추측하지 않는다 — 예측은 대개 틀린다. 실제로 돌려봐야 한다. 고객용 에이전트 제품이라면 그 제품을 직접 굴려보고, Claude Code라면 내 코드베이스에서 어디를 잘하고 어디서 아키텍처에 걸려 넘어지는지 본다.
3. 같은 지점에서 반복해서 넘어지는 걸 확인한 뒤에만 그 한 줄을 되살린다.

너무 이르게 넣으면 안 된다. 모델은 그 지시를 매번, 사용할 때마다 읽는다. 그러니 정말로 필요한 지시인지 확인하고 넣어야 한다.

[08:27] 8. 모델은 시스템이 아니라 생명체다

보리스는 이 지점이 자기가 해온 모든 엔지니어링과 가장 다른 부분이라고 말한다. 과거에 시스템을 만들 때는 크고 아름다운 시스템을 앞서서 설계했다. 방대한 유닛 테스트 스위트를 갖추고, 모든 걸 미리 생각하고, 리아키텍처는 몇 달— 큰 회사에서는 몇 년짜리 프로젝트였다.

모델은 그렇지 않다. 살아 있는 생물, 유기적인 무언가에 가깝다. 세대마다 다르게 행동하고 성격이 조금씩 다르다. 그러니 시간을 들여 그 모델을 알아가고, 거기 맞춰 하니스를 조정해야 한다. 매우 경험적이고 과학적인 일이다 — 시도하고, 결과를 보고, 그걸 기반으로 반복한다.

[09:31] 9. eval도 그리 오래 살지 못한다

“코드와 시스템 프롬프트는 지워야 하지만 eval은 상수처럼 계속 쌓아가는 것이냐”는 정리에 보리스는 거기까지는 아니라고 한 발 물러선다.

eval은 하니스보다 조금 오래 살지만 그리 길지 않다. 한두 세대, 길어야 세 세대. 지금은 지수 곡선 위에 있어서 모델이 너무 빨리 좋아지고, 그러면 eval이 포화(saturate) 돼 버려 버리고 새로 만들어야 한다. 이것도 과정의 일부다. 결국 원칙은 같다 — 제품과 모델을 직접 써서 어디서 헤매는지 보고, 그 지점이 다음 eval 세트가 된다.

[10:35] 10. hobbling과 product overhang

“Claude를 언호블링(unhobbling)한다”는 표현의 뜻을 묻자 보리스는 두 개념을 짝지어 설명한다.

• product overhang — 미래 모델이 아니라 오늘의 모델이 이미 할 수 있는데 우리가 아직 실현하지 못한 능력들. 특정 도구를 쓰거나, 특정 언어를 다루거나, 특정 유형의 문제를 푸는 등 “모델 능력 밖”이라고 여겼던 것들이 사실 이미 가능하다. 모델은 매 세대 그걸 할 수 있는데 그 능력을 표현하게 해주는 제품이 없다.
• hobbling — 그 반대편. 제품이 오히려 길을 막는 상태.

둘은 같은 것의 앞뒷면이다. 보리스는 오늘날의 모델에도 스타트업이 아직 잡아채지 못한 product overhang이 엄청나게 많다고 본다. 놀랍고 흥미롭고 상업적으로도 가치 있는 행동을 끌어낼 기회가 널려 있다는 것이다.

[11:56] 11. Claude Code의 탄생 — Sonnet 3.5를 언호블링하다

가장 좋은 예가 초기 Claude Code 자신이다. 1년 반~2년 전, Sonnet 3.5 시절이었다. 당시 기준으로는 존재하는 최고의 코딩 모델이었고(요즘 기준으로는 형편없지만) Anthropic이 만든 첫 번째 훌륭한 코딩 모델이었다.

그때의 코딩 제품들은 무엇을 하고 있었나. 한 줄 자동완성, 새롭다고 하던 여러 줄 자동완성, 그리고 챗 — 에이전트와 대화는 되지만 쓰기 권한은 없고 읽기만 가능해서 코드베이스에 대해 질문만 할 수 있었다. 모델은 이미 함수 하나, 파일 하나를 통째로 쓸 수 있는데 그걸 끌어내는 제품이 없었다(기능 단위는 아직 아니었다).

그래서 Claude Code의 아이디어는 이랬다 — 스캐폴딩을 전부 걷어내고 가능한 한 가장 단순한 하니스를 주자. 그러면 파일 하나를 통째로 쓰고 기능 하나를 만들 수 있다. 그게 전부였다. 다이애나의 정리처럼, IDE 안에 모델을 붙들어두던 이전 시도들과 달리 터미널 전체 접근을 준 것이 언호블링이었고, 그게 Claude Code의 탄생 설화다.

[14:40] 12. 조금 벅찬 과제를 줘라 — 과잉 명세를 버려라

앞으로 창업자들이 언호블링을 어떻게 생각해야 하냐는 질문에, 첫 번째 답은 이것이다 — “모델이 할 수 있다고 생각하는 것보다 조금 더 어려운 과제를 주라.”

가장 흔한 실수는 그 반대다. 지나치게 구체적인 지시를 붙인다 — “이걸 하되, 이런 식으로, 이런 식으로, 이런 식으로. 반드시 1번, 그다음 2번, 3번, 4번 순으로.” 요즘 모델에는 이게 정말 맞지 않는 방식이다.

대신 한 단계 위에서 말한다.

과제를 서술하고 → 가드레일을 서술하고 → 종료 조건(exit criteria)을 서술하고 → 모델이 요리하게 둔다. 그리고 잠시 뒤에 돌아온다.

6개월 전이라면 통하지 않았을 방식이지만 오늘은 통한다.

[15:42] 13. Bun을 Zig에서 Rust로 — 프롬프트 하나, 11일

6개월 전에는 못 했던 일의 사례로 그는 코드베이스 전체를 다른 언어로 재작성하는 것을 꼽는다.

Claude Code는 Bun JavaScript 런타임 위에서 돈다. Node.js의 대안이자 더 빠른 노드 격인 오픈소스 런타임이고, Zig로 쓰여 있었다. Zig는 C에 가까운 저수준 시스템 언어라 메모리를 수동 관리해야 하고, 그래서 메모리 누수 같은 문제에 쉽게 빠진다. Bun 팀은 오랫동안 Claude에게 코드베이스를 퍼징시켜 메모리 누수를 유발·재현하게 했고 실제로 많이 찾아냈다. 한 번에 하나씩. 그게 당시 모델의 능력치였다.

그러다 팀의 제러드가 말했다 — “그냥 재작성해보자.” 그는 새 모델 세대가 나올 때마다 이걸 테스트 문제처럼 던져왔는데, Fable부터 모델이 해내기 시작했다(Opus 5도 가능할 것이라고 본다).

방법은 이랬다. Bun은 테스트가 매우 잘 갖춰져 있고 Node.js에도 큰 테스트 스위트가 있어서 제대로 했는지 판정하기가 쉽다 — 그래서 테스트 스위트를 정의해두고, 프롬프트 하나로 dynamic workflow를 걸어 Zig → Rust 재작성을 시켰다.

11일간 돌았고, 코드베이스 전체를 재작성했다. 10만 줄이 넘는 JavaScript 런타임이다.

원샷이었냐는 물음에는 “아니, 스티어링이 있었다”고 정정한다. 다만 이전 모델들은 스티어링을 해도 불가능했다. 사람 손으로 했다면 최고의 엔지니어를 붙여도 확실히 1년 이상 걸렸을 일이고, 이 결과물은 지금 프로덕션에 올라가 있다 — 오늘 Claude Code를 실행하면 이 Rust 버전 위에서 돈다.

관련 노트: 2026-07-21-aisparkup-post-14598-claude-code-bun-rust

[18:44] 14. OpenCV로 그림 그리기 — 끌어내기의 간극

두 번째 조언은 실험이다. 상업적 쓸모를 따지지 말고 모델과 놀아볼 자유를 스스로에게 줘라.

최근 몇 주 Anthropic 내부에서 바이럴이 된 발견이 그 예다. 누군가 Opus 5에게 OpenCV를 쥐여주고 그림을 그리게 했다. “OpenCV로 이 이미지를 그려봐”라고 시키면 꽤 잘한다 — 초상화도, 동물도, 풍경도 된다.

모델에게 그림 그리기를 훈련시킨 적이 없다. 순전히 끌어내기의 간극(elicitation gap)이다. 제대로 물어보면 그냥 한다. 이 발견은 직접적인 상업적 응용도 없이 그냥 창의적으로 놀다가 우연히 나왔다. 보리스의 가설은, 오늘의 모델에 이런 기회가 수십 수백 개는 더 남아 있다는 것이다.

[19:47] 15. 프롬프트 엔지니어링이 아니라 검증이 관건이다

1년 전 가장 인기 있던 채용 공고가 프롬프트 엔지니어였고, 그다음엔 컨텍스트 엔지니어로 바뀌었다. 보리스는 이런 이름들이 계속 왔다 갈 것으로 본다.

요즘의 스킬은 프롬프트 엔지니어링이 아니라 두 가지다.

1. 조금 벅차 보이는 어려운 과제를 어떻게 줄 것인가.
2. Claude가 진행 중에 스스로 자기 작업을 검증할 수 있게 어떻게 만들 것인가.

그리고 검증이야말로 사람들이 가장 제대로 못 하는 단 하나라고 못 박는다.

[20:29] 16. Electron 앱을 Swift로 — 15일째 돌고 있는 프롬프트

검증 사례로 그는 자기 실험을 꺼낸다. Claude 데스크톱 앱은 Electron으로 만들어져 있다. 6개월 전에는 굼뜨고 불안정했지만 지금은 꽤 빨라져서 팀 대부분이 쓴다. 그래도 그는 네이티브라면 어떤 느낌일지 궁금했다.

그래서 Claude Tag(Slack에서 도는 Claude) 세션을 열고 이렇게 진행했다.

1. “GitHub에 macOS 러너 접근 권한이 있어?” → 아니오. → 러너를 연결해서 macOS 가상머신을 띄울 수 있게 했다.
2. “Claude 데스크톱 앱을 Swift로 재작성할 빈 코드베이스인데, 접근할 수 있어?” → 아니오. → 접근 권한을 줬다.
3. 그리고 이 한 문단을 던졌다.

“Electron 앱을 Swift로 재작성해. Electron 앱을 macOS 가상머신에서 실행하고, 스크린샷을 찍고, 픽셀 단위로 Swift 버전과 비교해. 끝날 때까지 멈추지 마.”

이게 프롬프트의 전부였다. 얼마나 걸렸냐는 물음에 “아직 돌고 있다” — 시작한 지 2주 남짓, 14~15일째였다. (객석에 2주 넘게 한 과제를 돌려본 사람이 있냐고 묻자 몇 명이 손을 들었다.)

이게 바로 언호블링이다. 오늘의 모델이 할 수 있는 일이고, 그냥 하게 두면 된다. 화려한 장치는 필요 없다 — /goal도 /loop도 없어도 된다. 도움은 되지만, 정말 필요한 건 과제를 주고 + 결과를 검증할 방법을 줘서 막히지 않게 하는 것, 그러면 알아서 간다. 덤으로 이 세션의 Claude는 스스로 라이브 블로깅을 하기로 결정해서, 내부 Slack 채널을 만들고 몇 분마다 진행 스크린샷을 올렸다.

[22:56] 17. 상위 1% 사용자가 되는 법

“프롬프트가 이렇게 단순하다면, 여기 있는 누구나 할 수 있다. 그럼 상위 1% 사용자를 가르는 건 뭐냐”는 질문에 보리스의 첫 답은 “링크드인 인플루언서 말을 듣지 마라”(객석 환호), 그리고 “트위터도 읽지 마라”였다.

모두가 ‘하나의 이상한 비법’을 찾고 있지만 그런 건 없다. 방법은 경험적으로 접근하는 것뿐이다.

• 조금 너무 어려운 과제를 준다.
• 내가 직접 그 일을 한다면 썼을 검증 수단을 모델에게도 준다.
• 어디서 헤매는지 본다.
• 그 지점을 고친다 — 더 나은 프롬프트로, 혹은 스킬로, 컨텍스트가 없어서면 MCP를 붙여 필요한 맥락을 끌어오게 한다.

그게 전부다. “너무 단순하게 들린다”는 말에 그는 사람들이 과하게 생각하고 과하게 설계한다고 답한다. 과거에 시스템을 만들 때는 그래야 했기 때문이다. 그래서 수년~수십 년 코딩해온 엔지니어일수록 과잉 명세하고, 모델이 자기가 했을 방식 그대로 하게 만들려는 실패 모드에 빠진다. 이건 배워온 걸 되배우는(unlearn) 여정이고, 결국 동료 대하듯 대하는 법을 익히는 일이다. 지금 모델의 지능 수준이 그 정도다.

[25:18] 18. dynamic workflows — 에이전트의 대수학

15일째 돌고 있는 그 과제가 에이전트를 몇 개나 띄웠냐는 물음에 보리스는 수천 개, 수만 개쯤으로 추정한다. 최고의 사용자는 레버리지가 큰 과제를 던질 줄 안다는 것이 또 하나의 팁이다.

가장 쉬운 방법은 dynamic workflows다. Claude Code의 비교적 새 기능이고, 쓰는 법은 어이없을 만큼 간단하다 — “use a workflow”라고 말하면 된다.

내부 구조는 이렇다. Bun을 샌드박스로 쓰고, 그 안에 가상머신을 띄운 뒤 Claude가 다수의 에이전트를 시작하고 오케스트레이션하게 한다. 에이전트 하나도, 병렬 10개도 아니다. 코드베이스 재작성이나 아주 복잡한 데이터 분석, 여러 단계와 수십 개 PR이 필요한 큰 기능 개발 같은 과제라면 이렇게 흐른다.

1단계 여러 에이전트를 띄워 초벌 작업 → 2단계 또 다른 에이전트 집합이 그 작업을 검증하거나 요약 → 3단계 다시 팬아웃

보리스의 배경이 함수형 프로그래밍이라, 설계도 그 결로 갔다. 그가 쓰는 표현은 에이전트를 위한 대수학(an algebra for agents)이다. 에이전트를 순차로 실행하는 방법과 병렬로 실행하는 방법이 있고, Claude는 샌드박스 안에서 이들을 조합해 토큰을 효율적으로 쓰면서 아주 복잡한 일을 처리하는 도구를 갖는다.

그는 이걸 새로운 형태의 test-time compute라고 부른다. 스케일링 법칙은 역사적으로 신경망 크기·학습 데이터·학습 flops의 함수였고, 최근 test-time compute(연구자식으로 말해 “토큰을 몇 개 생성하는가”)가 더해졌다. dynamic workflows는 그 test-time compute를 오케스트레이션하는 새로운 방식이며, 아주 어려운 과제에 투입되는 test-time compute의 양을 크게 끌어올리는 수단이다. 아직 별로 글로 쓰인 적이 없는 이야기라고 덧붙인다.

관련 MOC: moc-ai-agents-orchestration · moc-ai-agents-harness

[27:44] 19. loops와 routines — Claude가 자기 코드베이스를 유지보수한다

두 번째 방법은 loops와 routines다.

• loop — Claude를 위한 로컬 크론 잡.
• routine — 같은 것이되 클라우드에서 돈다. 노트북을 닫아도 된다.

dynamic workflow와 성격이 다르다. dynamic workflow는 하나의 과제를 조각으로 쪼개는 것이고, loops/routines는 반복되는 하나의 과제를 매시간·5분마다·매일 돌리는 것이다. 컨텍스트는 공유하지 않지만 메모리는 공유할 수 있다.

여기서 Anthropic이 시작한 일이 Claude가 자기 자신을 유지보수하는 것이다. Slack 채널 하나를 두고 Claude가 여러 routine을 띄워 자기 코드베이스를 관리한다 — CLI, iOS 앱, Android 앱, 데스크톱 앱 전부.

실제로 도는 routine의 예시:

루틴	하는 일
dead code 청소	한 문장짜리 프롬프트 하나. 매일 모든 코드베이스에서 정적·동적 분석으로 죽은 코드를 찾아 PR을 올린다. 정적/동적 분석을 쓰라고 지시한 적은 없고 알아서 알아냈다.
실험 정리	이미 100%로 롤아웃된 실험을 코드베이스에서 제거하고 그대로 출하한다.
테스트 작성	커버리지가 필요한 영역에 테스트를 쓴다.
테스트 삭제	예전 모델이나 사람이 언젠가 넣어둔 쓸모없는 테스트를 지운다.
abstraction police	큰 코드베이스에 시간이 지나며 여러 군데 다르게 만들어진 거의 같은 추상들을 매일 찾아내 하나로 통합한다.

지금은 매일 20~30개의 routine이 모든 코드베이스에서 돈다. 하루에 수백~수천 개의 에이전트가 도는 셈이고, 예전 같으면 수십~수백 명의 엔지니어가 했을 일이다. 아직 완전하진 않지만 앱 유지보수를 완전 자동화하는 경로 위에 있다고 그는 말한다. 그 결과 엔지니어는 실제로 하고 싶은 일 — 새 제품을 출하하고 사용자와 이야기하는, 재미있는 일 — 만 하면 된다.

[30:08] 20. “코딩은 풀렸다”에 붙는 단서, 그리고 최고 사용자의 마인드셋

과거에 “코딩은 풀렸다”고 말한 적이 있는데 지금은 어떻게 보냐는 질문에 보리스는 단서를 하나 단다.

내가 하는 종류의 코딩은 풀렸다. 모두의 코딩이 풀린 건 아니다.

아직 Claude가 헤매는 곳이 있다 — 아주 깊은 시스템 코드베이스, 분산 시스템, 그리고 픽셀 하나가 어긋난 걸 잡아내는 종류의 UI 검증. Opus 5가 비전과 컴퓨터 사용에서 큰 도약을 했지만 아직 완벽하진 않다.

그는 객석에 물었다 — 코드의 100%를 에이전트로 쓰고 손으로는 전혀 안 쓰는 사람? 꽤 많은 손이 올라갔다. 50% 이상은? 조금 적었지만 비슷했다. 점점 더 많은 종류의 코드에서 “풀린” 상태로 가고 있다는 것이다.

Claude를 가장 잘 쓰는 사람들에게는 공통된 마인드셋이 있다. 핵심은 경험적일 것이다.

과거 모델에 대해 배운 것을 잊어라. 수업에서 배운 컴퓨터과학 이론을 잊어라. 모델을 보고, 과제를 시켜보고, 어디서 헤매는지 보고, 그에 맞춰 조정하라.

이론과학이 아니라 경험과학이 됐다. 그래서 자기 선입견(priors)을 잘 버리는 사람, 예전에 안 됐던 아이디어를 다시 시도해볼 만큼 열린 사람이 지금 아주 잘한다.

[32:12] 21. CS 학생에게 — TI-83 계산기에서 시작한 실용주의

마지막 질문은 “AI 에이전트 코딩 이전 세대로서, 지금 CS를 공부하는 학생은 무엇을 여전히 옛날 방식으로 어렵게 배워야 하나”였다.

보리스는 자기 이야기로 답한다. 그는 컴퓨터과학을 실용적으로 배웠다 — 언제나 눈앞의 문제를 풀기 위해 코딩을 독학했다.

처음 코딩을 배운 건 중학교 때 TI-83 계산기였고, 첫 언어는 BASIC이었다. 목적은 수학 시험에서 커닝해서 성적을 올리는 것. (그는 TI-83 프로그래밍 가이드를 인터넷에 써서 올렸고 아직 어딘가 남아 있다고 한다.) 성적이 좋아지자 시리얼 케이블을 구해 반 친구들에게 프로그램을 나눠줬고, 친구들 성적도 올랐다. 그러다 수학이 어려워졌다 — BASIC으로 짠 대수 풀이기로는 감당이 안 됐고, 미적분에 들어가면서 더 나은 풀이기를 짜려고 어셈블리를 배워야 했다.

그래서 학교에 있는 사람에게 늘 하는 조언은 컴퓨터과학만 배우지 말라는 것이다. 이론은 지적으로 매혹적이고 알아두면 정말 흥미롭지만, 적용하는 법을 배워라. 스타트업을 만들고, 제품을 만들고, 자기만의 디자인 감각과 비즈니스 감각을 기르고, 데이터 사이언스를 배우고, 사용자와 이야기하는 법을 배우는 것. 이 다른 기술들이 컴퓨터과학·엔지니어링과 결합될 때 정말 가치가 커진다. 이것들이 여전히 손으로 해야 할 하드 스킬이다.

다이애나가 요약한다 — “먼저 자기가 원하는 걸 만들고, 그다음 사람들이 원하는 걸 만들라.”

끝으로 그날 객석 전원에게 Max 20x 계정이 선물로 주어졌다(코드는 이메일로 발송). 다이애나의 마무리는 이랬다 — “이제 계정이 생겼으니, 이 방의 누군가는 몇 달씩 돌면서 수천 개의 에이전트를 띄우는 무언가를 만들어야 한다.”

---

부록 — 실전 체크리스트

새 모델이 나왔을 때 (하니스/제품을 만드는 쪽)

• 시스템 프롬프트를 통째로 지우고 한 줄씩 되살리며 각 줄의 효과를 잰다(ablation).
• 툴 세트와 툴 프롬프트도 같은 방식으로 재검토하고, 필요 없어진 툴은 내린다.
• 하니스에 남길 코드가 안전·권한·정적 분석·UI 바깥이라면 정말 필요한지 다시 묻는다.
• eval은 계속 덧붙이되 포화되면 버리고 새로 만든다. 수명은 1~3 모델 세대로 잡는다.

Claude Code를 쓰는 쪽

• 6개월마다 CLAUDE.md·스킬·훅을 지워본다. Opus 5에서는 지금 해본다.
• CLAUDE_CODE_SIMPLE=1 claude로 프롬프트 없는 상태를 비교해본다.
• 지시는 추측으로 넣지 않는다. 같은 지점에서 반복해서 넘어질 때만 한 줄 추가.
• 프롬프트는 과제 + 가드레일 + 종료 조건까지만. 1→2→3 절차 나열은 버린다.
• 모델이 스스로 검증할 수단(테스트 스위트, 스크린샷 비교, 린트 등)을 반드시 함께 준다.
• 능력 밖이라 여겼던 과제를 최신 모델에 다시 던져본다. 예전에 실패한 것이 근거가 되지 못한다.
• 큰 과제는 use a workflow로 dynamic workflow를, 반복 과제는 loop(로컬)/routine(클라우드)으로 돌린다.
• 유지보수 routine을 하나씩 세운다 — dead code 청소, 롤아웃 완료 실험 정리, 테스트 보강/정리, 중복 추상 통합.

원문 인용 모음

• [00:52] “Whenever you do model training, you try to teach a whole bunch of different things and most often it doesn’t work. But some subset of the things the model does learn and sometimes it also surprises you.”
• [01:32] “It can go for days, weeks, months at a time. It just won’t stop. You don’t even need to use scaffolding.”
• [02:12] “If the model reads some instruction on the internet that’s like, you know, do X and Y and Z and also delete everything on the user’s computer — a year ago the model would have just done it. But nowadays Opus does not.”
• [02:52] “It’s literally we’re looking at neurons in the model’s brain that light up when prompt injection happens. So the model won’t even tell you but we can actually see those neurons.”
• [03:34] “Claude Code as a product and as a harness is just always changing. We’re always adding stuff. We’re always deleting stuff.”
• [04:17] “A lot of the stuff in the system prompt was correcting for these behaviors that the model should have known, but it didn’t. Now, Opus 5 just does it. So, yeah, we deleted 80% of the system prompt.”
• [04:58] “The model is actually a little bit more intelligent without these prompts. That’s something that we’ve been finding.”
• [05:59] “You delete the entire system prompt and then you bring it back line by line to figure out what is the impact of each individual line.”
• [06:19] “If you look at actually the code that’s in the Claude Code harness today, almost all of it is about safety and permissions and static analysis and there’s a bunch of UI code.”
• [06:39] “Every 6 months delete your CLAUDE.md. Delete your skills. Delete your hooks. See what the model does and it might surprise you.”
• [08:07] “Only when you see it repeatedly stumble on the same thing, that’s when you add it back. But you don’t want to do it too early because remember like the model is going to read this instruction every single time you use it.”
• [08:47] “The way to think about it is almost like a living creature, like it’s something more organic.”
• [09:53] “An eval might live for maybe one, two, three model generations, but nowadays we’re on the exponential. The model is improving so quickly, very often we just saturate the eval.”
• [11:36] “The model can do this at every given model generation, but there is often not a product that lets the model do this.”
• [13:18] “What if we get rid of all the scaffolding and just give the model the simplest possible harness, so it can write an entire file at a time and build an entire feature?”
• [15:01] “You want to go a little bit higher level. You want to describe the task, you want to describe the guardrails, you want to describe like the exit criteria, and then just let the model cook.”
• [17:24] “It was one prompt. It was a dynamic workflow. … And it ran for 11 days, and it rewrote the entire code base.”
• [19:05] “We didn’t train the model to draw. It’s just like the elicitation gap. If you ask it to do it the right way, it can just do it.”
• [20:08] “The skill nowadays is less about prompt engineering and more about figuring out how do you give Claude a hard task that seems a little bit too hard. And then how do you make it possible for Claude to verify its work along the way?”
• [21:31] “I want you to rewrite the Electron app in Swift. I want you to run the Electron app in the Mac virtual machine, screenshot it, and then look pixel by pixel, compare it to the Swift version, don’t stop until you’re done.”
• [21:52] ”— And how long did this take to run? — It’s still running.”
• [23:17] “Everyone’s looking for like the one weird trick to do it. There’s just — that doesn’t exist. There’s nothing like that.”
• [24:18] “It’s a journey to kind of figure out how do you treat this thing like you would a coworker.”
• [26:21] “My background is functional programming. And so the way that we designed this is essentially an algebra for agents.”
• [26:43] “This is actually like a new form of test time compute.”
• [28:25] “One routine is clean up dead code. This is a single prompt. It’s like one sentence. … We didn’t prompt that. It just kind of figured it out.”
• [29:47] “This is hundreds of agents running every day, sometimes thousands of agents every day. It’s doing the work of dozens or hundreds of engineers.”
• [30:29] “Coding is solved for the kind of coding that I do. It’s not solved for everyone.”
• [31:30] “Forget all of the things that you learned about past models. Forget everything that you’ve learned about computer science theory in class.”
• [33:14] “I learned how to program on a calculator so I could just like get better at my math tests by cheating on the test.”
• [34:15] “Learn not just the computer science. … Learn how to apply it.”

관련 노트

• 2026-07-21-aisparkup-post-14598-claude-code-bun-rust — Bun Zig → Rust 재작성 국내 보도
• 2026-07-25-claude-opus-5-launch-breakdown — Opus 5 출시 정리
• 2026-06-14-boris-cherny-claude-code-future — 같은 화자의 Acquired Unplugged 대담
• moc-claude-code · moc-ai-agents-harness · moc-ai-agents-orchestration