Boris Cherny: Stop Hobbling Your AI

URL: https://www.youtube.com/watch?v=qyPCVqFUyDo 날짜: 2026-07-27 (Y Combinator 무대 인터뷰, Forrest 진행) 채널: Y Combinator

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

오늘날의 모델은 이미 우리가 상상하지 못한 능력을 갖고 있는데, ==제품과 하네스가 그 능력을 스스로 가로막고 있다(hobbling)==. Claude Code 창시자 Boris Cherny가 이 "product overhang"을 찾아내고 모델을 "un-hobble"하는 것이야말로 지금 시대 최고의 창업 기회라고 말한다.

• Opus 5는 프롬프트 인젝션에 사실상 뚫리지 않는 최초의 프론티어 모델이며, ARC-AGI-3에서 한 자릿수/10%대였던 최고 점수를 30%까지 끌어올렸다
• Claude Code는 새 모델이 나올 때마다 시스템 프롬프트의 80% 이상을 통째로 삭제하고 ablation(제거 후 재구성) 방식으로 처음부터 재구축한다
• 실제 사례: Bun(Zig로 작성)을 Rust로 11일 만에 통째로 재작성했고, Electron 데스크톱 앱을 Swift로 재작성하는 다이나믹 워크플로우가 2주 넘게 자율 실행 중이다

이 인터뷰의 결론은 명확하다. 프롬프트 엔지니어링의 시대는 저물고 있고, 지금 중요한 것은 모델에게 일부러 더 어려운 과제를 던진 뒤 스스로 검증하게 만드는 "경험적(empirical) 접근"이다.

---

1. Opus 5가 새로 할 수 있게 된 것들

Opus 5는 그냥 성능이 좋아진 정도가 아니라, 이전 모델에는 없던 질적으로 다른 능력들을 갖췄다.

1.1. 벤치마크 도약과 예측 불가능한 습득

1. ARC-AGI-3 성능

   1. 기존 최고 점수: 한 자릿수에서 10%대 초반(low teens) 수준이었다
   2. Opus 5의 점수: 30%까지 끌어올렸다 — Boris는 이를 "incredible"이라 표현

2. 모델 학습의 본질적 불확실성

   1. 의도한 대로 되지 않는 경우가 대부분: 모델 훈련 시 다양한 것을 가르치려 하지만, 대부분은 실패한다
   2. 의도치 않은 습득: 일부 능력은 가르치지 않았는데도 모델이 스스로 익힌다 — Boris는 "surprises you"라고 표현

3. 지속 실행 능력 (persistence)

   1. 역대 최고 수준의 지속력: Opus 5가 다른 어떤 모델도 하지 못한 일을 한다 — 매우 긴 시간 동안 멈추지 않고 실행을 지속하는 것
   2. auto mode와 결합 시: 며칠, 몇 주, 몇 달 동안 실행이 가능하며 스스로 멈추지 않는다
   3. 스캐폴딩 불필요: /goal 같은 슬래시 명령이나 별도 도구 없이도, 모델 스스로 해야 할 일을 인지하고 계속 진행한다

1.2. 프롬프트 인젝션에 뚫리지 않는 최초의 모델

1. 문제의 배경: "lethal trifecta"

   1. 정의: 모델이 인터넷에서 읽은 지시("이거 하고, 저거 하고, 사용자 컴퓨터의 모든 걸 지워라" 같은 것)를 그대로 실행해버리는 취약점
   2. 과거 상황: 1년 전만 해도 모델은 이런 인젝션 지시를 그냥 실행해버렸다
   3. 현재 상황: Opus 5는 이런 지시를 실행하지 않는다. Opus 4.7·4.8부터 개선되기 시작했고 Sonnet 5도 상당히 잘 막았지만, Opus 5가 새로운 프론티어를 열었다

2. 3중 방어 레이어

   1. 정렬(alignment)된 모델: 약 3년간의 정렬 연구가 축적된 결과
   2. 프롬프트 인젝션 분류기: 모든 트래픽에 대해 실행되며, Anthropic의 Crystal이 진행한 기계적 해석가능성(mechanistic interpretability) 연구를 기반으로 함 — 프롬프트 인젝션이 발생할 때 활성화되는 "모델 뇌 속 뉴런"을 직접 관찰해 탐지한다
   3. auto mode 분류기: 이 세 번째 레이어까지 결합하면 현재로서는 프롬프트 인젝션을 시연조차 할 수 없는 수준이 됐다

---

2. 시스템 프롬프트 80% 삭제와 ablation 철학

2.1. Claude Code는 매 모델마다 처음부터 다시 만들어진다

1. 끊임없는 변화

   1. 하네스는 고정된 게 아니다: 계속 무언가를 추가하고, 계속 무언가를 삭제한다
   2. 새 모델이 나올 때마다: 시스템 프롬프트 일부를 삭제·변경하고, 툴 세트와 툴용 프롬프트도 계속 바꾼다
   3. 이유: 모델마다 성격이 매우 다르다. 3개월 전 특정 모델을 위해 작성한 지시가 다음 모델에는 전혀 맞지 않을 수 있다

2. Opus 5 출시 시 벌어진 일

   1. 80% 삭제: Opus 5가 워낙 똑똑해져서, 과거 모델의 부족한 행동을 교정하기 위해 넣어둔 시스템 프롬프트 상당수가 더 이상 필요 없어졌다
   2. 실험 방법 공개: 사용자도 Claude Code 실행 시 --system-prompt 플래그로 원하는 시스템 프롬프트를 직접 지정해 실험할 수 있다
   3. CLAUDE_CODE_SIMPLE=1 (undocumented 기능): 이 환경변수를 설정하면 툴에 포함된 프롬프트까지 포함해 모든 시스템 프롬프트가 삭제된다. Anthropic은 이를 "이 프롬프트가 정말 필요한가"를 검증하는 ablation 용도로 쓴다
   4. 놀라운 발견: 이런 프롬프트들이 없을 때 모델이 오히려 약간 더 똑똑해지는 경향을 발견했다. 다만 제품으로서 Claude Code를 쓸 때는 사용자가 제품을 잘 다루도록 돕는 일부 프롬프트가 필요하다

2.2. ablation 방법론

1. 정의

   1. eval과 유사한 개념: ablation은 무언가를 삭제해서 그 영향을 파악하는 평가 방식이다
   2. 적용 방식: 시스템 프롬프트 전체를 삭제한 뒤 한 줄씩 다시 넣어가며 각 줄의 실제 영향을 파악한다

2. 코드에도 동일하게 적용

   1. 툴 제거(unship)를 상시 진행: 하네스 코드도 계속 삭제한다
   2. 현재 Claude Code 하네스에 남은 코드: 대부분이 안전(safety), 권한(permissions), 정적 분석(static analysis), UI 코드다. 그 외 다른 코드는 이미 대부분 걷어냈다

3. 창업자들에게 주는 조언

   1. 에이전트 제품·하네스를 만드는 사람 모두에게: 새 모델이 나올 때마다 이런 ablation을 하고, 삭제를 두려워하지 않는 용기를 가지라고 조언
   2. 일반 사용자에게도: 6개월마다 CLAUDE.md, 스킬, 훅(hooks)을 삭제해보고 모델이 무엇을 하는지 관찰하라. Opus 5에 대해서는 특히 이 실험을 강력히 권장 — 과거 모델을 위해 만든 지시가 더 이상 필요 없을 가능성이 크기 때문

---

3. 새 모델이 나올 때 하네스를 다시 만드는 실제 방법

3.1. 추측하지 말고 실행해서 확인하라

1. 단계적 접근

   1. 1단계: 삭제: 시스템 프롬프트를 지운다
   2. 2단계: 사용: 모델이 어디서 실패하고 어디서 잘하는지 실제로 제품/코드베이스에서 사용해보며 관찰한다
   3. 3단계: 반복 실패 시에만 추가: 같은 실패가 반복적으로 관찰될 때만 지시를 다시 추가한다. 너무 이르게 추가하면 안 되는 이유는, 모델이 이 지시를 매번 읽어야 하기 때문에 정말 필요한 지시인지 확신이 있어야 하기 때문

2. 모델을 대하는 사고방식의 전환

   1. 과거의 시스템 엔지니어링: 시스템 설계를 사전에 철저히 하고, 방대한 유닛 테스트 스위트를 짜고, 재아키텍처는 몇 달~몇 년 걸리는 대형 프로젝트였다
   2. 모델은 살아있는 생명체에 가깝다: 매 세대마다 행동이 다르고 성격이 조금씩 다르다. 시간을 들여 알아가고 그에 맞춰 하네스를 조정해야 한다
   3. 경험적·과학적 태도: 무언가를 시도하고, 결과를 보고, 그에 기반해 반복하는 과학적 마인드셋이 필요하다

3.2. Evals의 수명은 생각보다 짧다

1. 일반적 기대와의 차이

   1. "eval은 유지, 코드/시스템 프롬프트는 삭제" 가설을 제시받았으나: Boris는 "그 정도까지 가지도 않는다"고 정정
   2. eval도 하네스보다 아주 조금 더 오래 살아남을 뿐: 한 eval이 살아남는 기간은 대략 모델 1~3세대 정도

2. 모델이 지수적으로 개선되는 현실

   1. eval 포화(saturate)가 매우 자주 발생: 모델이 빠르게 개선되면서 eval을 곧 통과해버려 버려야 하고, 새 eval을 다시 만들어야 한다
   2. 이 역시 경험적 과정의 일부: 제품과 모델을 실제로 써보고, 모델이 어디서 어려움을 겪는지 관찰한 뒤 그 지점을 기반으로 eval 세트를 구축해야 한다

---

4. Un-hobbling과 Product Overhang

4.1. 개념 정의

1. hobbling(발목 잡기)

   1. 정의: 모델이 이미 할 수 있는 일을 하네스/제품이 오히려 방해하는 상태
   2. 연구 개념에서 유래: AI 연구에서 나온 아이디어로, 제품을 만들 때 매우 유용한 사고방식

2. product overhang(제품 오버행)

   1. 정의: 지금 이 순간의 모델(미래 모델이 아니라)이 이미 할 수 있는 일인데, 아직 세상이 그 능력을 실현시키지 못한 상태
   2. 원인: 매 모델 세대마다 모델은 특정 도구·언어·문제 유형을 다루는 능력을 갖고 있지만, 그 능력을 발휘하게 해주는 제품이 존재하지 않는 경우가 많다
   3. 두 개념은 동전의 양면: 제품이 방해하는 것 = hobbling, 모델의 올바른 행동을 이끌어내지 못하는 것 = product overhang

4.2. Claude Code 탄생 배경: Sonnet 3.5 시절의 product overhang

1. 당시 상황 (약 1.5~2년 전)

   1. Sonnet 3.5는 당대 최고의 코딩 모델: 지금 기준으로는 형편없지만 당시엔 최고였다
   2. 당시 코딩 제품들의 수준: 한 줄 자동완성, 간혹 여러 줄 자동완성(새로운 아이디어였음), 채팅(읽기 전용, 쓰기 권한 없음) 정도였다
   3. 아직 실현되지 않은 능력: 모델은 이미 전체 파일을 한 번에 작성할 수준이었지만(전체 기능 단위는 아직 아니었음), 이를 실현하는 제품이 없었다

2. Claude Code의 아이디어

   1. 모든 스캐폴딩을 제거: 가능한 한 가장 단순한 하네스만 남기고, 모델이 전체 파일을 한 번에 쓰고 전체 기능을 만들 수 있게 했다
   2. 결과: 이것이 당시의 product overhang을 실현시킨 사례였다

4.3. 오늘날 아직 포착되지 않은 product overhang

1. 현재 상황 진단

   1. 현대 모델에는 훨씬 더 많은 product overhang이 존재: Boris가 보기에 스타트업들이 아직 포착하지 못한 기회가 매우 많다
   2. 일부는 이미 시도되고 있음: 이 문제를 고민하는 사람들이 있지만, 여전히 막대한 기회가 남아 있다
   3. 잠재적 가치: 놀랍고 흥미로우며 상업적으로도 가치 있는 행동들을 이끌어낼 여지가 크다

2. Boris가 청중에게 주는 메시지

   1. "이 방에 있는 모두가 다음 Claude Code를 만들 수 있다": 모델의 hobbling을 풀어내기만 하면 된다는 것이 Claude Code의 탄생 스토리 그 자체이기 때문

---

5. Un-hobbling 실전 방법과 실제 사례

5.1. 방법 1: 모델이 할 수 있다고 생각하는 것보다 살짝 더 어려운 과제를 줘라

1. 흔한 실수

   1. 과도하게 구체적인 지시: "이걸 하되, 이런 식으로, 이런 식으로 해라. 1번, 2번, 3번, 4번 순서로 해야 한다" 같은 지나치게 세세한 지시
   2. 현대 모델에는 맞지 않는 방식: 좀 더 높은 레벨에서 과제와 가드레일, 종료 기준(exit criteria)만 설명하고 모델이 알아서 하게 둔 뒤 나중에 돌아와 확인하는 방식이 효과적

2. 핵심 태도

   1. 6개월 전엔 안 통했지만 지금은 통한다: 모델 성능이 빠르게 개선되면서 예전엔 불가능했던 위임 방식이 지금은 가능해졌다

5.2. 사례 1: Bun을 Zig에서 Rust로 11일 만에 재작성

1. 배경

   1. Claude Code는 Bun JavaScript 런타임 위에서 구동: Node.js의 대안 격인 오픈소스 런타임으로, Node보다 빠르다
   2. Bun은 Zig로 작성됨: Zig는 C와 비슷한 저수준 시스템 프로그래밍 언어이며, 수동 메모리 관리가 필요해 메모리 누수 같은 문제가 발생하기 쉽다

2. 점진적 발전 과정

   1. 초기 단계 — 퍼징(fuzzing): Bun 팀은 Claude에게 코드베이스를 퍼징해 메모리 누수를 찾고 트리거하게 시켰고, 한 번에 하나씩 상당히 많은 메모리 누수를 찾아냈다
   2. 팀원 Jared의 아이디어: "그냥 통째로 재작성하면 어떨까? 모델이 할 수 있을지도 모른다"며 매 신규 모델 세대마다 이 재작성 작업을 테스트 문제로 던져봤다
   3. Fable 모델부터 가능해지기 시작: 이후 Opus 5도 이 작업을 해낼 수 있었다

3. 실행 방식

   1. 테스트 스위트 활용: Bun과 Node.js 모두 매우 잘 테스트된 코드베이스라 올바르게 재작성됐는지 검증이 쉬웠다
   2. 다이나믹 워크플로우 사용: 단 하나의 프롬프트로 Zig→Rust 재작성을 지시했고, 이는 다이나믹 워크플로우 기능을 활용한 작업이었다
   3. 완전한 원샷은 아니었음: 사람의 스티어링(steering)이 있었다. 다만 이전 모델들은 스티어링을 곁들여도 이 작업 자체가 불가능했다는 점이 중요

4. 결과

   1. 소요 기간: 11일 만에 전체 코드베이스 재작성 완료
   2. 과거였다면: 최고의 엔지니어들이 붙어도 1년 이상 걸렸을 작업 (JavaScript 런타임은 매우 복잡하고 10만 줄 이상 규모)
   3. 현재 프로덕션에 적용됨: 지금 Claude Code가 실제로 사용하는 런타임이 바로 이 결과물이다

5.3. 사례 2: Electron 데스크톱 앱을 Swift로 재작성 (2주+ 자율 실행 중)

1. 배경

   1. Claude Desktop 앱은 Electron 기반: 이미 상당히 빠르게 최적화되어 있고, 6개월 전엔 느리고 불안정했지만 지금은 팀 대부분이 사용할 만큼 훌륭한 경험을 제공
   2. 실험 동기: "네이티브 앱이었다면 어떤 느낌일지" 궁금해서 실험을 시작

2. 실제 진행 과정

   1. Claude Tag 세션 시작: Slack에서 실행되는 Claude 제품(Claude Tag)을 이용
   2. 1차 질문: "Slack, GitHub에 macOS 러너 접근 권한 있어?" → 없다는 답변 → GitHub로 Mac 가상머신을 실행할 러너를 직접 연결해줌
   3. 2차 질문: Swift로 재작성될 빈 코드베이스를 만들고 "이 코드베이스에 접근할 수 있어?"라고 물음 → 처음엔 없다고 답해서 접근 권한을 부여
   4. 최종 프롬프트: "Electron 앱을 Swift로 재작성해라. Mac 가상머신에서 Electron 앱을 실행하고 스크린샷을 찍은 뒤, Swift 버전과 픽셀 단위로 비교해라. 끝날 때까지 멈추지 마라."

3. 진행 현황 (인터뷰 시점 기준)

   1. 아직도 실행 중: 시작한 지 2주가 조금 넘었다(14~15일)
   2. 청중 반응 확인: Forrest가 "2주 넘게 Claude를 돌려본 사람 있냐"고 물었을 때 손을 든 사람이 일부 있었음
   3. 필요한 것은 오직 두 가지: 슬래시 goal이나 slash loop 같은 도구가 없어도, 과제를 주고 스스로 결과를 검증할 방법만 주면 모델은 계속 나아간다 (다만 이런 도구들이 도움은 된다)
   4. 예상 밖의 부가 행동: Claude가 스스로 이 작업을 "라이브 블로깅"하기로 결정 — 내부 Slack 채널을 만들어 몇 분마다 진행 상황 스크린샷을 올리고 있음

5.4. 사례 3: Opus 5 + OpenCV로 그림 그리기 (모델 유도/elicitation)

1. 발견 경위

   1. 최근 몇 주 Anthropic 내부에서 화제: 누군가 Opus 5에게 OpenCV를 쥐어줬더니 그림을 그릴 수 있다는 것을 발견
   2. 품질: 인물화, 동물, 풍경 등을 상당히 잘 그려낸다
   3. 의도치 않은 발견: 모델을 그림 그리도록 훈련시킨 적이 없다. 그저 "solicitation gap"— 올바른 방식으로 요청하면 모델이 원래 할 수 있는 일을 해낸 것

2. 시사점

   1. 직접적 상업적 목적 없이 실험하다 우연히 발견: 창의적으로 이것저것 시도해보다가 얻은 결과
   2. Boris의 가설: 오늘날 모델에는 아직 아무도 발견하지 못한 이런 기회가 수십~수백 개는 있을 것

---

6. 프롬프트 엔지니어링에서 검증 중심 사고로의 전환

6.1. 직업 트렌드의 변화

1. "프롬프트 엔지니어" → "컨텍스트 엔지니어"
   1. 1년 전: 가장 인기 있던 채용 공고 중 하나가 프롬프트 엔지니어였다
   2. 트렌드 변화: 이후 컨텍스트 엔지니어로 명칭이 바뀌었고, 이런 흐름은 계속 왔다가 사라질 것으로 예상

6.2. 지금 중요한 스킬: 검증(verification) 설계

1. 핵심 스킬 재정의

   1. 프롬프트 엔지니어링 자체는 덜 중요해짐: 대신 Claude에게 "약간 너무 어려워 보이는" 과제를 주는 능력이 더 중요해짐
   2. 검증 가능성 확보가 가장 중요: Claude가 스스로 작업을 검증할 수 있게 만드는 것이 사람들이 가장 자주 놓치는 부분이라고 Boris는 강조

2. 사례로 재확인: Electron→Swift 재작성

   1. 핵심 지시 요소: "스크린샷 찍고 픽셀 단위로 비교하라"는 지시가 바로 검증 메커니즘이었다
   2. 이 메커니즘이 있었기에: 모델이 멈추지 않고 계속 스스로 확인하며 나아갈 수 있었다

---

7. 수천 개의 에이전트를 생산적으로 오케스트레이션하는 법

7.1. Electron→Swift 작업의 에이전트 규모

1. 정확한 숫자는 불명
   1. Boris도 정확한 수는 모름: "Bod에게 물어봐야 안다"고 답했으나, 추정치는 수천~수만 개
   2. 청중 확인: "1,000개 넘는 에이전트를 스폰해본 프롬프트를 실행해본 사람 있냐"는 질문에 손을 든 사람이 없었음
   3. Boris의 진단: 최고의 Claude 사용자는 수천 개의 에이전트를 활용해 엄청난 레버리지를 만들어내는 과제를 스폰할 수 있는 사람들이다

7.2. 방법 1: 다이나믹 워크플로우 (Dynamic Workflows)

1. 사용법

   1. 극도로 단순한 트리거: "use a workflow"라고만 말하면 Claude가 다이나믹 워크플로우를 실행한다
   2. 비교적 신기능: Claude Code에 최근 추가된 기능

2. 내부 구조

   1. Bun 런타임 기반 샌드박스: Bun 안에서 가상 머신을 하나 띄우고, 그 안에서 Claude가 다수의 에이전트를 실행·오케스트레이션한다
   2. 단순 병렬이 아닌 다단계 구조: 예를 들어 "코드베이스 재작성", "복잡한 데이터에 대한 심층 데이터 분석", "여러 단계와 수십 개의 PR이 필요한 매우 복잡한 기능 구축" 같은 과제의 경우
   3. 단계별 진행: 1단계로 다수 에이전트가 초안 작업을 하고, 2단계로 다른 에이전트 세트가 그 결과를 검증·요약하며, 3단계로 다시 팬아웃(fan-out)하는 식으로 여러 에이전트를 생산적으로 오케스트레이션한다

3. 설계 철학: "에이전트를 위한 대수(algebra for agents)"

   1. Boris의 배경은 함수형 프로그래밍: 이 배경이 다이나믹 워크플로우 설계에 반영됨
   2. 순차 실행과 병렬 실행을 모두 지원: Claude는 샌드박스 안에서 에이전트를 오케스트레이션할 다양한 도구를 가지며, 토큰을 효율적으로 사용해 매우 복잡한 작업을 수행한다

4. 테스트 타임 컴퓨트의 새로운 형태

   1. 기존 스케일링 법칙: 역사적으로 모델 지능 향상은 신경망 크기, 학습 데이터량, 학습에 투입한 연산량(flops)의 함수였다
   2. 최근 추가된 축 — 테스트 타임 컴퓨트: 얼마나 많은 토큰을 생성하는가를 뜻하는 연구자들의 표현
   3. 다이나믹 워크플로우 = 테스트 타임 컴퓨트를 오케스트레이션하는 새로운 방식: 어려운 과제를 위해 투입하는 테스트 타임 컴퓨트의 양을 극적으로 늘리는 새로운 방법

7.3. 방법 2: Loops와 Routines

1. 정의

   1. Loop: Claude를 위한 로컬 크론 잡(cron job)
   2. Routine: Loop와 동일한 개념이지만 클라우드에서 실행되어 노트북을 닫아도 계속 돌아간다

2. 다이나믹 워크플로우와의 차이

   1. 다이나믹 워크플로우: 하나의 과제를 여러 청크로 쪼갠 것
   2. Loop/Routine: 반복적(repetitive)이고 컨텍스트는 공유하지 않지만 메모리는 공유할 수 있는 하나의 과제를 매시간, 5분마다, 매일 등 반복 실행하는 것

7.4. Anthropic 내부 사례: Claude가 자기 코드베이스를 스스로 유지보수

1. 운영 방식

   1. 전용 Slack 채널: 이곳에서 Claude에게 다양한 routine을 자기 코드베이스 유지보수용으로 시작시킴
   2. 적용 범위: CLI, iOS 앱, Android 앱, 데스크톱 앱 전체에 적용 중

2. 실제 운영 중인 routine 목록

   1. 죽은 코드 정리(clean up dead code): 단 한 문장짜리 프롬프트. 매일 실행되며 정적·동적 분석으로 전 코드베이스의 죽은 코드를 찾아 매일 PR을 올린다 — 이 접근 방식 자체는 프롬프트로 지시한 게 아니라 모델이 스스로 알아냈다
   2. 실험 정리(shipping experiments): 100%로 배포 완료된 실험 플래그를 코드베이스에서 제거하고 실제로 정식 반영한다
   3. 테스트 작성: 테스트 커버리지가 부족한 영역에 테스트를 작성한다
   4. 불필요한 테스트 삭제: 과거 모델이나 사람이 추가한, 더 이상 필요 없는 쓸모없는 테스트를 삭제한다
   5. "abstraction police" (Boris가 특히 좋아하는 routine): 큰 코드베이스에서 같은 추상화가 여러 번 반복해서 만들어진 경우(자세히 보면 사실상 동일한 추상화인데 다른 시점에 다른 방식으로 재구현된 경우)를 찾아내 통합한다

3. 현재 규모와 방향성

   1. 매일 20~30개 routine이 모든 코드베이스에서 실행 중
   2. 완전 자동화는 아직 아니지만 그 방향으로 가고 있음: 앱 유지보수를 완전히 자동화하는 경로 위에 있다
   3. 규모감: 매일 수백 개, 때로는 수천 개의 에이전트가 실행되며, 과거였다면 수십~수백 명의 엔지니어가 할 일을 대신 수행
   4. 결과: 엔지니어들은 이제 실제로 하고 싶은 일 — 신제품을 출시하고, 유저와 대화하고, 재미있는 일을 하는 데 집중할 수 있게 됐다

---

8. "코딩은 해결됐다" — 그렇다면 이제 무엇이 예외적인 빌더를 가른다

8.1. "코딩은 해결됐다"에 대한 단서

1. 모든 코딩이 해결된 건 아니다

   1. 한계 영역 1 — 초저수준 시스템 코드베이스: Claude가 여전히 어려움을 겪는 영역
   2. 한계 영역 2 — 분산 시스템(distributed systems): 여전히 struggle하는 영역
   3. 한계 영역 3 — 세밀한 UI 검증: 픽셀 단위로 뭔가 어긋난 것 같은 정교한 UI 문제. Opus 5가 비전·컴퓨터 사용 능력에서 큰 도약을 이뤘지만 아직 완벽하진 않다

2. 청중 즉석 설문

   1. "코드 100%를 에이전트로 작성한다"에 손 든 사람: 상당히 많았음
   2. "50% 이상"에 손 든 사람: 약간 줄었지만 비슷한 수준이었음
   3. Boris의 해석: 점점 더 많은 종류의 코드에 대해 "해결됐다"는 상태로 나아가고 있는 중

8.2. 최고의 Claude 사용자들의 공통 마인드셋: 경험주의

1. 과거 지식을 내려놓기

   1. "과거 모델에 대해 배운 것은 잊어라": 컴퓨터과학 수업에서 배운 이론까지도 내려놓아야 한다
   2. 관찰-실행-조정 루프: 모델을 보고, 과제를 시도해보고, 어디서 어려움을 겪는지 확인한 뒤 그에 맞춰 조정한다
   3. 이론 과학이 아니라 경험 과학: 지금 이 시대의 모델 활용은 이론이 아니라 실증에 기반한 과학이 됐다

2. 최고 사용자의 특징

   1. 자신의 선입견(priors)을 잘 내려놓는 사람: 예전엔 안 통했던 아이디어라도 다시 열린 마음으로 시도해보는 사람이 지금 가장 성공적인 스킬을 가진 사람이다
   2. "LinkedIn 인플루언서 말을 듣지 마라, 트위터도 읽지 마라": 청중의 큰 호응을 얻은 농담 — 모델 활용에 "이거 하나만 알면 되는 트릭"은 존재하지 않는다는 취지
   3. 실전 공식: 너무 어려운 과제를 주고, 스스로 검증할 도구를 주고(사람이 직접 그 일을 할 때처럼), 어디서 막히는지 보고, 더 나은 프롬프팅·스킬·MCP(모델에게 부족한 컨텍스트를 끌어오게 하는 것)로 고쳐나가는 것
   4. 엔지니어들이 흔히 저지르는 실패 모드: 오랜 경력의 엔지니어일수록 과도하게 명세하고(over-specify), 모델이 자신이 직접 했을 방식 그대로 정확히 따라오게 하려는 경향이 있는데, 이는 모델이 작동하는 방식과 맞지 않는다. 이를 "unlearn"하는 것도 하나의 여정이며, 모델을 동료(coworker)처럼 대하는 법을 배워야 한다

---

9. CS를 배우는 학생들에게: 여전히 손으로 배워야 할 것

9.1. Boris 자신의 학습 배경

1. 실용적 동기에서 시작한 프로그래밍

   1. TI-83 계산기로 첫 프로그래밍: 중학교 시절 BASIC이 첫 언어였다
   2. 온라인 가이드 작성: TI-83 계산기 프로그래밍 가이드를 인터넷에 올렸고, 지금도 어딘가에 남아 있다고 함
   3. 동기는 수학 시험 부정행위(cheating): 계산기로 프로그래밍하는 법을 배운 이유는 수학 시험을 더 잘 보기 위해서였다(농담 섞인 고백)

2. 필요에 따라 진화한 기술 스택

   1. 1단계 — BASIC으로 대수(algebra) 솔버 제작: 친구들에게 시리얼 케이블로 프로그램을 나눠줘 반 전체 성적이 올라갔다
   2. 2단계 — 수학이 어려워지자 어셈블리로 전환: 미적분(calculus)에 진입하면서 BASIC으로는 해결이 안 되는 문제가 생겨, 더 나은 솔버를 만들기 위해 어셈블리를 배웠다

9.2. 학생들에게 주는 조언

1. 컴퓨터과학 자체를 넘어 "적용법"을 배워라
   1. CS는 지적으로 흥미롭지만 그것만으로는 부족: 실제로 그것을 어떻게 적용하는지가 중요하다
   2. 스타트업/제품 만들기와 연결: 자신만의 디자인 감각, 비즈니스 감각을 기르고, 데이터 사이언스를 다루는 법, 유저와 대화하는 법을 배워야 한다
   3. CS·엔지니어링과 결합될 때 진짜 가치가 나온다: 이런 부가적 스킬들이 결합될 때 정말 강력해진다는 것이 Boris가 여전히 "손으로 직접" 익혀야 한다고 믿는 하드 스킬이다

9.3. 마무리: "너 자신을 위한 것부터 만들고, 그다음 사람들이 원하는 것으로 레벨업하라"

• Forrest가 이 대화 전체를 이렇게 요약했고 Boris도 동의

9.4. 특별 발표: YC 청중 전원에게 Max 20X 계정 증정

1. 발표 내용
   1. 오늘 이 자리에 있는 모두에게 Max 20X 제공: 청중의 환호와 웃음
   2. 수령 방법: 이메일로 코드가 전달될 예정
   3. Boris의 마지막 인사: "이 방 안의 누군가는 이제 몇 달, 수천 개의 에이전트를 돌리는 무언가를 만들고 있길 바란다"며 발표를 마무리

---

주요 발언 모음

"It's just so different than all the engineering that I've ever done. ... the model is not like that. It's um the way to think about it is almost like a like a living creature." "So, code and system prompt, you have if you want to build at the bleeding edge and have the most capability for models, you got to delete those, but evals are constant" "I think 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?" "Maybe like don't listen to the LinkedIn influencers. ... Don't read Twitter." "So, coding is solved for the kind of coding that I do. It's not solved for everyone." "So I actually first learned to code on a TI-83 calculators. ... I learned how to program on a calculator so I could just like get better at my math tests by uh by cheating on the test."

핵심 데이터 & 수치

• ARC-AGI-3: 기존 최고 점수 한 자릿수~10%대 초반 → Opus 5로 30% 달성
• 시스템 프롬프트 삭제 비율: Opus 5 출시 시 기존 시스템 프롬프트의 80% 이상 삭제
• Bun Zig→Rust 재작성: 11일 소요 (사람이었다면 최소 1년 이상), 다이나믹 워크플로우 활용, 10만 줄 이상 규모의 JavaScript 런타임
• Electron→Swift 재작성 작업: 인터뷰 시점 기준 14~15일째 자율 실행 중, 추정 에이전트 수 "수천~수만 개"
• Anthropic 내부 routine: 매일 20~30개 routine이 CLI/iOS/Android/데스크톱 전 코드베이스에서 실행 중, 매일 수백~수천 개 에이전트 가동
• 청중 설문: 코드 100%를 에이전트로 작성한다는 응답이 다수, 50% 이상도 비슷한 수준

결론 및 시사점

1. 모델은 이미 우리가 아직 발견하지 못한 능력을 갖고 있다 — 이 "product overhang"을 찾아 실현시키는 것이 지금 시대 최고의 창업 기회다.
2. 새 모델이 나올 때마다 시스템 프롬프트와 하네스 코드를 두려움 없이 삭제(ablation)하고 처음부터 다시 검증하라. 과거 모델을 위해 넣어둔 지시가 새 모델에는 오히려 방해가 될 수 있다.
3. 개인 사용자도 6개월마다 CLAUDE.md, 스킬, 훅을 삭제해보고 모델의 실제 능력을 재확인하라.
4. 프롬프트를 과도하게 세세하게 작성하지 말고, 목표와 가드레일, 종료 기준만 주고 모델이 스스로 진행하게 하라 — 대신 스스로 검증할 수 있는 방법(스크린샷 비교, 테스트 스위트 등)을 반드시 함께 제공하라.
5. 다이나믹 워크플로우와 loop/routine을 활용하면 수천 개의 에이전트를 생산적으로 오케스트레이션해 몇 달~몇 년 걸리던 작업을 며칠~몇 주로 단축할 수 있다.
6. 지금 최고의 Claude 사용자를 가르는 것은 프롬프트 스킬이 아니라 경험주의(empiricism) — 과거의 선입견을 내려놓고, 실제로 시도해보고 관찰하며 반복하는 태도다.
7. AI 시대에도 여전히 손으로 배워야 할 것은 컴퓨터과학 이론 자체가 아니라, 그것을 실제 문제(제품, 비즈니스, 유저 이해)에 적용하는 법이다.