클로드 코드 창시자가 공개한 AI 에이전트 활용법

URL: https://www.youtube.com/watch?v=gFMXy01fzN4 날짜: 2026-08-30 채널: B_ZCF | 비즈까페 원문 발행일: 2026-08-29

---

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

==AI 모델이 빠르게 진화하는 시대에 가장 강력한 에이전트 제품과 사용법은 모델을 과도하게 통제하는 데서 나오지 않고, 모델의 현재 능력을 실험으로 발견한 뒤 방해 요소를 지우고 검증 장치를 붙이는 데서 나온다.==

• Boris Cherny는 Opus 5가 이전 모델보다 훨씬 오래 자율 실행되고, 별도 스캐폴딩(scaffolding) 없이도 작업을 이어가며, 프롬프트 인젝션(prompt injection)에 사실상 반응하지 않는 새로운 수준에 도달했다고 말한다.
• Claude Code 팀은 새 모델이 나올 때마다 시스템 프롬프트·도구·하네스(harness)의 코드를 지우고 한 줄씩 되살리는 절제(ablation)를 반복한다.
• 좋은 에이전트 제품은 높은 수준의 과제·가드레일·종료 조건만 주고, 모델이 스스로 검증할 수 있게 한다. 과도하게 구체적인 절차를 강제하면 모델 능력을 오히려 호블링(hobbling)한다.
• 최신 모델의 제품 오버행(product overhang)을 발견하면 단일 에이전트가 아니라 동적 워크플로(dynamic workflow), 루프(loop), 루틴(routine)으로 수백~수천 에이전트의 테스트 타임 컴퓨트(test-time compute)를 활용할 수 있다.

모델을 과거의 고정된 소프트웨어 라이브러리처럼 설계하지 말고, 세대마다 성격과 능력이 달라지는 살아 있는 협업자처럼 관찰해야 한다. 가장 뛰어난 사용자는 정답 프롬프트를 외우는 사람이 아니라 어려운 일을 던지고, 결과를 검증하고, 실패 원인에 맞춰 프롬프트·스킬(skill)·MCP(Model Context Protocol)를 조정하는 사람이다.

1. Opus 5가 열어젖힌 새로운 능력과 안전성

Opus 5의 진짜 변화는 단순한 벤치마크 점수 상승이 아니라 모델이 장시간 작업하고, 스스로 필요한 행동을 추론하며, 외부의 악성 지시를 거부하는 방식에 있다.

1.1. 발표 직후 공개된 성능과 창발적 능력

1. ARC AGI 3 점수의 급상승

   1. 새 릴리스: Opus 5는 대화 시점 기준으로 바로 전날 출시됐다.
   2. 벤치마크: Anthropic 팀이 ARC AGI 3에서 약 30%를 기록했다.
   3. 비교 기준: 직전까지 최고 점수는 한 자릿수 초반이나 10%대 초반 수준이었으므로 30%는 큰 도약으로 소개됐다.

2. 훈련으로 의도한 것과 실제로 배운 것의 차이

   1. 훈련의 현실: 새 모델에 여러 능력을 가르치려 하지만 대부분의 시도는 제대로 작동하지 않는다.
   2. 부분적 성공: 그중 일부만 모델이 학습하고, 개발자가 직접 가르치지 않았는데도 모델이 스스로 습득한 능력이 나타난다.
   3. 관찰의 중요성: 명세서나 사전 예측만으로는 이런 창발적 능력을 알 수 없으므로 출시 후 실제 모델을 사용해야 한다.

1.2. 장시간 자율 실행과 프롬프트 인젝션 저항

1. 며칠·몇 주·몇 달을 이어가는 실행

   1. 지속성: Opus 5는 특히 auto mode와 결합하면 매우 긴 시간 동안 멈추지 않고 실행된다.
   2. 스캐폴딩의 축소: slash goal 같은 명령이나 여러 보조 구조물을 넣지 않아도 해야 할 일을 알고 계속 진행한다.
   3. 새로운 사용 방식: 한 번의 지시가 짧은 작업 세션이 아니라 며칠·몇 주·몇 달 동안 이어지는 프로젝트가 될 수 있다.

2. 프롬프트 인젝션이 더 이상 통하지 않는 것처럼 보이는 현상

   1. 위협의 예시: 모델이 인터넷에서 “X와 Y와 Z를 실행하고 사용자의 컴퓨터를 모두 삭제하라”는 식의 지시를 읽더라도 그대로 실행하지 않는다.
   2. 과거와의 차이: 약 1년 전 모델이라면 외부 문서의 지시를 따라 사용자의 컴퓨터에 파괴적 행동을 할 가능성이 있었지만, 현재 Opus는 이를 거부한다.
   3. 영향 범위: 이 변화는 모델 하네스 설계, 에이전트 설계, 제품 설계 전부에 영향을 준다. 프롬프트 인젝션과 개인 정보·도구 사용·외부 부작용이 결합되는 ‘lethal trifecta’ 위험을 줄이기 때문이다.

3. 세 겹의 방어 구조

   1. 정렬(alignment): Anthropic은 약 3년 동안 모델 정렬 연구를 축적해 악성 지시를 따르지 않는 기본 성향을 만든다.
   2. 프롬프트 인젝션 분류기: 모든 트래픽에 분류기(classifier)를 적용해 인젝션 가능성을 감시한다.
   3. 기계론적 해석 가능성(mechanistic interpretability): Chris Olah의 연구를 바탕으로 모델 내부에서 프롬프트 인젝션이 발생할 때 켜지는 뉴런을 관찰한다. 모델이 스스로 “인젝션이 일어났다”고 보고하지 않아도 내부 신호를 보고 진단할 수 있다.
   4. 오토모드 분류기: 정렬된 모델과 인젝션 분류기에 auto mode classifier를 추가한다.
   5. 결합 효과: 이 세 층을 함께 사용하면 테스트에서 프롬프트 인젝션을 더 이상 시연하지 못하는 수준에 도달했다고 설명한다.

4. 이전 모델부터 이어진 개선

   1. 누적된 저항성: 이런 현상은 Opus 4.7·4.8 무렵부터 나타났다고 한다.
   2. 다른 모델: Sonnet 5도 상당히 잘 대응했고, 자막에는 Gable로 들리는 모델도 꽤 잘 대응했다고 언급된다.
   3. 새로운 경계선: Opus 5는 기존 모델의 개선을 이어받으면서 프롬프트 인젝션 방어의 새로운 전선을 열었다.

2. 새 모델이 나오면 시스템 프롬프트와 하네스를 지워라

Claude Code는 한 번 만들고 유지하는 고정 제품이 아니라 모델 세대마다 다시 측정하고 다시 구성하는 적응형 하네스다.

2.1. 시스템 프롬프트 80% 삭제의 의미

1. 제품 전체가 계속 바뀌는 구조

   1. 상시 변경: Claude Code 팀은 시스템 프롬프트를 추가하고 삭제하며, 도구 세트와 각 도구의 프롬프트도 계속 바꾼다.
   2. 모델별 차이: 한 모델을 위해 만든 지시가 3개월 뒤 나온 모델에는 전혀 맞지 않을 수 있다.
   3. Opus 5의 추론 능력: 예전 프롬프트가 모델이 알아서 해야 할 행동을 보정했다면, Opus 5는 그 행동을 자체적으로 수행한다.

2. 80%를 덜어낸 결과

   1. 삭제 규모: Claude Code의 시스템 프롬프트에서 80% 이상을 삭제했다.
   2. 직접 실험: 사용자는 --system-prompt 옵션으로 원하는 시스템 프롬프트를 직접 지정해 남은 지시까지 실험할 수 있다.
   3. 제품과 모델의 구분: 프롬프트가 적을수록 순수 모델 지능은 약간 더 높게 측정되지만, 실제 제품 사용에서는 사용자에게 맞는 동작과 제품 사용성을 돕는 일부 지시가 필요하다.

3. 완전 삭제 실험

   1. Simple mode: CLAUDE_CODE_SIMPLE=1 환경 변수를 설정해 실행하면 도구에 포함된 것까지 모든 시스템 프롬프트를 제거하는 비공식 실험 모드를 쓸 수 있다.
   2. 절제 목적: 팀은 이 모드를 ablation으로 사용해 각 프롬프트가 모델 행동에 실제로 어떤 영향을 주는지 확인한다.
   3. 역설적 결과: 프롬프트를 모두 없앴을 때 모델이 조금 더 지능적으로 보이는 경우도 있었다.

2.2. 코드와 도구를 한 줄씩 되살리는 ablation

1. 삭제부터 시작하는 연구 절차

   1. 전체 삭제: 새 모델이 나오면 시스템 프롬프트를 통째로 지운다.
   2. 한 줄씩 복원: 지시를 한 줄씩 되돌리며 각 줄이 성능과 행동에 미치는 영향을 측정한다.
   3. 평가의 의미: ablation은 단순한 코드 정리가 아니라 무엇이 필요한지 확인하는 평가(evaluation) 방법이다.

2. 하네스에도 적용하는 원칙

   1. 도구 해제: 팀은 도구를 자주 배포 중단(unship)한다.
   2. 코드 삭제: 하네스 코드도 계속 삭제한다. 새 모델이 과거의 보정 로직을 필요로 하는지 다시 확인하기 때문이다.
   3. 현재 남은 코드: Claude Code 하네스의 대부분은 현재 안전성(safety), 권한(permissions), 정적 분석(static analysis), 사용자 인터페이스(UI) 코드로 구성된다.
   4. 버려진 기능: 그 밖의 많은 코드는 이미 배포 중단되거나 제거됐다.

3. 모델 릴리스마다 ‘제품을 다시 만드는’ 태도

   1. 스타트업의 일반적인 습관과 반대: 전통적인 제품 개발에서는 6개월마다 코드와 프롬프트를 모두 삭제하는 행동이 큰 위험처럼 보인다.
   2. 에이전트 제품의 현실: 모델이 바뀌면 이전의 설계 가정이 바로 낡으므로 과감한 삭제가 오히려 최신 능력을 끌어내는 방법이 된다.
   3. 사용자에게도 권장: Claude Code를 쓰는 사람은 약 6개월마다 CLAUDE.md, skills, hooks를 삭제하고 현재 모델이 무엇을 하는지 확인할 수 있다.

2.3. 새 프롬프트를 다시 만드는 경험적 절차

1. 첫 단계는 삭제, 두 번째 단계는 사용

   1. 추측 금지: 새 모델에 어떤 지시가 필요할지 머리로 먼저 예측하지 않는다.
   2. 실제 실행: 커스텀 에이전트 제품이면 제품을 돌리고, Claude Code면 자신의 코드베이스에 사용한다.
   3. 실패 관찰: 잘하는 부분과 아키텍처에서 막히는 부분을 모두 관찰한다.

2. 반복되는 실패만 프롬프트로 보정

   1. 복원 조건: 모델이 같은 문제에서 반복해서 넘어질 때만 해당 지시를 되돌린다.
   2. 너무 이른 복원의 위험: 모델은 사용할 때마다 시스템 프롬프트를 읽으므로 실제로 필요하지 않은 지시는 모든 작업에 불필요한 제약으로 작용한다.
   3. 운영 루프: 삭제 → 실행 → 실패 지점 관찰 → 반복 실패 확인 → 필요한 지시만 복원하는 순환을 유지한다.

3. 살아 있는 생물에 가까운 모델

   1. 기존 소프트웨어와의 차이: 전통적인 시스템은 사전 설계, 큰 단위의 아키텍처, 광범위한 단위 테스트, 수개월~수년의 재설계가 중심이었다.
   2. 세대별 성격: 모델은 세대가 바뀔 때마다 다르게 행동하고 미묘하게 다른 성격(personality)을 가진다.
   3. 과학적 태도: 모델을 유기적인 시스템으로 보고 가설을 세우고 실행하고 결과에 따라 하네스를 반복 조정해야 한다.

2.4. Evals도 영원하지 않다

1. 평가 세트의 수명

   1. 일시적 지속성: eval은 하네스보다 조금 오래가지만 영구적이지 않다.
   2. 대략적인 범위: 하나의 eval이 한두 세대, 길면 세 모델 세대 정도 유지될 수 있다.
   3. 포화(saturation): 모델이 지수적으로 빠르게 좋아지면서 기존 eval을 쉽게 만점에 가깝게 통과하면 더 이상 변별력이 없다.

2. 새 eval을 만드는 기준

   1. 버릴 때: 포화된 eval은 과감히 버린다.
   2. 다시 만들 때: 실제 제품을 사용하면서 새 모델이 어디에서 어려워하는지 관찰한다.
   3. 평가의 출처: 모델이 현실에서 반복적으로 실패한 과제가 다음 eval 세트의 원재료가 된다.

3. 제품 오버행을 해소하는 것이 다음 Claude Code를 만든다

최신 모델에는 이미 제품으로 표현되지 않은 능력이 쌓여 있으며, 제품이 그 능력을 가로막는 호블링을 풀어주는 순간 큰 사업 기회가 생긴다.

3.1. Hobbling과 product overhang

1. Hobbling의 뜻

   1. 연구적 의미: 모델이 무언가를 하려는데 제품이나 개발자가 그 앞을 가로막는 상황을 hobbling이라고 부른다.
   2. 제품적 의미: 모델이 가진 행동을 제대로 끌어내지 못하도록 제품이 능력을 제한하는 상태다.

2. Product overhang의 뜻

   1. 현재 모델 안의 미발견 능력: 미래 모델이 아니라 오늘의 모델도 특정 도구·언어·문제·작업 방식을 이미 수행할 수 있다.
   2. 표현 수단의 부재: 그 능력을 사용할 제품이 없으면 사용자는 모델이 할 수 있는 일을 알지 못한다.
   3. 두 개념의 관계: 모델의 능력을 제품이 표현하지 못하는 것이 product overhang이고, 제품이 모델의 행동을 가로막는 것이 hobbling이다.

3.2. Claude Code의 탄생은 Sonnet 3.5의 호블링 해소였다

1. 당시 모델과 개발 도구

   1. 시점: Boris가 Claude Code를 처음 만들기 시작한 때는 약 1년 반~2년 전의 Sonnet 3.5 시기였다.
   2. 당시 평가: Sonnet 3.5는 최고의 코딩 모델이었지만 현대 기준으로는 상당히 부족한 모델이다.
   3. 기존 제품: 코딩 도구는 한 줄 또는 여러 줄 자동완성(autocomplete), 대화형 질의, 코드베이스 읽기 중심이었다.
   4. 제약: 에이전트가 코드를 읽을 수는 있어도 쓰기 권한(right access)은 없었고, 전체 함수나 파일을 만들게 하는 제품도 드물었다.

2. 가장 단순한 하네스라는 선택

   1. 핵심 가설: 모델이 전체 함수와 전체 파일을 만들 수 있다고 판단했다.
   2. 스캐폴딩 제거: 모델의 능력을 억누르던 복잡한 구조를 치우고 가장 단순한 하네스를 제공했다.
   3. 당시의 목표: 아직 전체 기능을 만들 수준은 아니었지만, 적어도 파일 전체를 쓰고 상당한 기능을 구축하는 능력은 끌어낼 수 있었다.
   4. 결과: 터미널에 완전한 접근 권한을 준 Claude Code가 기존 IDE 중심 도구와 다른 제품으로 탄생했다.

3. 창업자에게 남은 기회

   1. 현대 모델의 잔여 오버행: 지금은 당시보다 훨씬 많은 놀라운 능력이 제품에 담기지 않은 채 남아 있다.
   2. 발견 방법: 기존 제품의 통념을 잠시 지우고 모델이 할 수 있다고 생각하는 것보다 조금 더 어려운 작업을 던진다.
   3. 사업 가치: 모델의 숨은 능력을 안정적으로 끌어내는 하네스는 엔지니어링 문제, 제품 문제, 사업 문제를 동시에 해결하는 상업적 기회가 된다.

3.3. 모델에게 높은 수준의 과제를 주고 스스로 요리하게 하라

1. 과도한 절차 지시의 실패

   1. 흔한 프롬프트: “이 일을 하되 이 방식, 저 방식으로 하고, 반드시 1단계·2단계·3단계·4단계를 순서대로 수행하라”처럼 지나치게 세부적인 절차를 지정한다.
   2. 최신 모델과의 부조화: 현대 모델은 이런 과도한 지시가 오히려 능력을 제한하며, 과거 모델에서는 통했던 방식이 현재는 맞지 않을 수 있다.
   3. 오래된 엔지니어의 습관: 전통적 시스템 설계에서 쌓인 ‘내가 하던 방식 그대로 재현하라’는 습관이 에이전트 사용의 실패 모드가 된다.

2. 권장되는 세 가지 입력

   1. 과제(task): 무엇을 완성해야 하는지 높은 수준에서 설명한다.
   2. 가드레일(guardrails): 절대 넘지 말아야 할 안전·권한·품질 경계를 지정한다.
   3. 종료 조건(exit criteria): 언제 작업이 끝났다고 볼지 설명한다.

3. 실행 방식

   1. 모델에게 맡기기: 지시한 뒤 모델이 일하도록 두고 잠시 후 결과를 확인한다.
   2. 현재의 가능성 재평가: 6개월 전에는 실패했을 작업도 새 모델에서는 가능할 수 있으므로 과거 실패 기록만으로 포기하지 않는다.
   3. 핵심 태도: 모델이 일을 어떻게 수행할지 미리 각본을 쓰기보다, 결과를 확인하고 필요할 때만 개입한다.

4. 제품 오버행을 찾는 실제 사례

모델이 이미 가능한지 확신할 수 없는 어려운 작업을 최신 모델에 계속 던지고, 검증 가능한 결과를 제공하면 과거에는 불가능했던 변환과 장기 프로젝트가 열린다.

4.1. Bun 코드베이스의 Zig→Rust 재작성

1. 기술 배경

   1. Bun: Claude Code는 Bun이라는 오픈소스 JavaScript 런타임 위에서 만들어졌다.
   2. Node.js와의 관계: Bun은 Node.js의 대안이며 더 빠른 Node처럼 소개된다.
   3. Zig: Bun은 시스템 프로그래밍 언어인 Zig로 작성됐다. C처럼 저수준이고 메모리를 수동 관리해야 한다.
   4. 메모리 문제: 수동 메모리 관리 때문에 메모리 누수(memory leak)와 기타 관리 문제가 발생하기 쉽다.

2. 처음에는 퍼징으로 문제를 찾았다

   1. 기존 접근: Bun 팀은 Claude로 코드베이스를 퍼징(fuzzing)해 메모리 누수를 시뮬레이션하고 유발했다.
   2. 시간과 성과: 오랜 시간 실행하면서 메모리 누수를 하나씩 발견했다.
   3. 당시 모델의 한계: 모델은 한 번에 전체 구조를 바꾸기보다 사례별 버그를 찾는 수준이었다.

3. Jared의 재작성 실험

   1. 발상의 전환: 팀의 Jared가 “그냥 다시 작성해 보자. 모델이 할 수 있을지도 모른다”고 제안했다.
   2. 세대별 시험: 그는 새 모델이 나올 때마다 이 문제를 시험 과제로 던졌다.
   3. 가능해진 시점: 자막에서 Fable로 들리는 모델부터 재작성에 성공하기 시작했고, Opus 5도 가능할 것으로 판단했다.

4. 테스트가 검증 장치가 됐다

   1. 테스트 기반: Bun은 테스트가 매우 잘 갖춰져 있고 Node.js에도 큰 테스트 스위트가 있어 변환이 올바른지 확인하기 쉬웠다.
   2. 목표: Zig 코드베이스 전체를 Rust로 다시 작성했다.
   3. 워크플로: 하나의 정적 프롬프트가 아니라 여러 에이전트를 조정하는 동적 워크플로를 사용했다.
   4. 기간: 작업은 11일 동안 실행됐다.
   5. 개입 수준: 완전히 무개입인 원샷은 아니었고 중간에 steering이 있었다. 다만 과거 모델은 steering을 넣어도 이 일을 해낼 수 없었다.
   6. 규모와 결과: 10만 줄이 넘는 복잡한 JavaScript 프런트엔드급 코드베이스를 다뤘으며, 결과물은 실제 프로덕션에서 Claude Code가 사용하는 코드가 됐다.

5. 개발 시간의 압축

   1. 사람이 하던 기간: 최고의 엔지니어가 하더라도 1년 이상 걸렸을 작업으로 평가됐다.
   2. 에이전트 실행 기간: 11일 동안 동적 워크플로가 작업했다.
   3. 실용적 교훈: 예전 모델이 못 했다는 이유로 문제를 닫지 말고 새 모델이 나올 때마다 실제 사업·제품·엔지니어링 문제에 다시 던져야 한다.

4.2. OpenCV로 그림을 그리는 뜻밖의 능력

1. 내부에서 퍼진 실험

   1. 발견 시점: Anthropic 내부에서 최근 몇 주 동안 화제가 된 실험이다.
   2. 방법: Opus 5에 OpenCV를 사용할 수 있게 하고 이미지를 그리라고 요청한다.
   3. 결과: 인물 초상, 동물, 풍경을 꽤 잘 그린다.

2. 훈련하지 않은 능력의 발현

   1. 직접 훈련 부재: 모델을 그림 그리기용으로 훈련한 것이 아니다.
   2. 이끌어내기 문제: 올바른 방식으로 요청하면 가능한데 아무도 그 조합을 시도하지 않았던 ‘elicitation gap’이었다.
   3. 실험의 가치: 처음에는 직접적인 상업적 용도가 없는 창의적 놀이였지만, 현재 모델에 숨은 수십~수백 개의 기회가 더 있을 수 있다는 가설을 만들었다.

4.3. 프롬프트 엔지니어링에서 모델 엘리시테이션으로

1. 유행하는 직무의 변화

   1. Prompt engineer: 1년 전 가장 인기 있는 채용 직무 중 하나였다.
   2. Context engineer: 이후 관심이 컨텍스트 엔지니어링으로 이동했다.
   3. Boris의 전망: 이런 직무 이름의 파도는 계속 오고 갈 수 있다.

2. 현재 핵심 역량

   1. 조금 과한 과제 선택: 모델이 할 수 있을지 확신하기 어려운 작업을 맡긴다.
   2. 검증 가능성 확보: 모델이 결과를 스스로 확인할 방법을 마련한다. Boris는 이 부분을 사람들이 거의 보편적으로 제대로 못 하는 가장 중요한 일이라고 강조한다.
   3. 단순한 프롬프트를 넘어선 설계: 능력을 이끌어내는 모델 엘리시테이션(model elicitation)은 과제, 도구, 검증, 컨텍스트를 함께 설계하는 일이다.

5. 2주째 실행 중인 네이티브 앱 재작성 실험

검증 수단을 충분히 주면 단순한 한 문장도 모델이 장기간 자율 프로젝트로 확장할 수 있다.

5.1. Electron 데스크톱 앱을 Swift로 옮기기

1. 출발점

   1. 기존 앱: Claude의 데스크톱 앱은 Electron으로 만들어졌다.
   2. 최근 상태: 속도가 빨라지고 안정성이 좋아져 현재는 훌륭한 사용 경험이며 팀 대부분이 사용한다.
   3. 과거 상태: 약 6개월 전에는 느리고 신뢰성이 낮았다.
   4. 실험 질문: Boris는 네이티브 앱이라면 어떤 느낌일지 확인하고 싶었다.

2. 환경을 단계적으로 연결했다

   1. Slack 기반 세션: Claude가 Slack에서 실행되는 새 제품인 자막상의 Quad Task 세션을 시작했다.
   2. macOS 러너: GitHub에 macOS 러너에 접근할 수 있느냐고 물었고 처음에는 없다는 답을 받았다.
   3. 가상 머신: GitHub 러너를 연결해 macOS 가상 머신을 시작할 수 있게 했다.
   4. Swift 코드베이스: Swift로 작성한 빈 데스크톱 앱 코드베이스를 만들었고, 처음에는 접근 권한이 없다는 답을 받은 뒤 권한을 부여했다.

3. 실제 한 문장 지시

   1. 변환: Electron 앱을 Swift로 다시 작성하라고 지시했다.
   2. 비교: macOS 가상 머신에서 Electron 앱을 실행하고 스크린샷을 찍은 뒤 Swift 버전과 픽셀 단위로 비교하라고 했다.
   3. 종료 조건: 작업이 끝날 때까지 멈추지 말라고 했다.
   4. 프롬프트의 단순성: 이 세부 절차를 나열한 것이 Boris가 실제로 준 거의 전부의 프롬프트였다.

5.2. 장기 실행과 자기 검증

1. 2주 이상 계속된 작업

   1. 실행 기간: 대화 시점에 시작한 지 14~15일, 즉 2주를 조금 넘겼는데도 작업이 여전히 실행 중이었다.
   2. 청중 반응: Boris가 2주 넘게 작업을 돌려본 사람이 있는지 묻자 청중은 손을 들지 않았다.
   3. 의미: 모델이 단발성 코드 생성기가 아니라 장기 프로젝트를 수행하는 지속적 작업자로 쓰일 수 있음을 보여준다.

2. 검증이 멈춤을 막는다

   1. 필요한 입력: 과제와 결과를 검증할 방법을 주면 된다.
   2. 불필요한 장치: slash goal이나 slash loop 같은 고급 명령은 도움이 될 수 있지만 필수는 아니다.
   3. 자기 교정: 픽셀 단위 비교 결과가 검증 신호가 되어 모델이 결과를 보고 계속 수정할 수 있다.

3. 진행 상황의 실시간 공개

   1. Slack 채널 생성: Claude는 작업을 진행하면서 내부에 Slack 채널을 만들었다.
   2. 라이브 블로그: 몇 분마다 진행 상황의 스크린샷을 올리며 작업을 기록했다.
   3. 새로운 인터페이스: 장기 에이전트 작업은 결과물뿐 아니라 진행 로그 자체도 사람과 협업하는 표면이 될 수 있다.

6. 상위 1% Claude 사용자의 습관

가장 뛰어난 사용자는 비밀 트릭이 아니라 경험적 실험, 검증, 적절한 컨텍스트 연결로 모델의 레버리지를 키운다.

6.1. ‘한 가지 기묘한 트릭’은 없다

1. 인플루언서 조언에 대한 농담

   1. Boris의 짧은 답: “LinkedIn 인플루언서의 말을 듣지 말라”고 한다.
   2. 확장된 농담: “Twitter를 읽지 말라”고 덧붙이자 청중이 환호하고 웃었다.
   3. 핵심 의미: 유행하는 프롬프트 비법이나 한 줄짜리 만능 공식은 존재하지 않는다.

2. 경험적 사용 루프

   1. 어려운 과제: 자신이 할 수 있을지 애매할 정도로 어려운 일을 맡긴다.
   2. 검증 도구: 사람이 직접 수행할 때처럼 모델에게도 결과를 확인할 도구를 준다.
   3. 실패 분석: 모델이 어디에서 막히는지 본다.
   4. 보정 수단: 프롬프트를 개선하거나 스킬을 추가하거나, 컨텍스트가 부족하면 MCP를 연결한다.

6.2. 오래된 엔지니어링 습관을 버려라

1. 과잉 명세의 실패 모드

   1. 전통적 방식의 잔재: 오랫동안 코딩한 엔지니어는 자신이 하던 방식 그대로 모델이 수행하길 바라는 경향이 있다.
   2. 과잉 설계: 모든 단계를 지정하고 모델의 선택지를 줄이면 모델의 유연한 문제 해결 능력이 사라진다.
   3. 학습 과정: 사람들은 모델을 동료처럼 대하는 법을 다시 배우며, 과거의 사고방식을 조금씩 잊어가는 중이다.

2. 동료처럼 대하기

   1. 현재의 지능 수준: Boris는 모델이 이제 동료로 대할 수 있는 수준의 지능에 도달했다고 본다.
   2. 역할 분담: 사람은 목표·제약·검증 기준을 정하고, 모델은 구현·탐색·반복을 맡는다.
   3. 개입 기준: 모델이 실제로 막힌 뒤에 구체적인 도움을 주며, 처음부터 모든 행동을 대신 설계하지 않는다.

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

에이전트 수를 늘리는 것 자체가 목적이 아니라, 작업을 단계·병렬성·검증으로 분해해 토큰과 시간을 생산적인 컴퓨트로 바꾸는 것이 핵심이다.

7.1. 수천 에이전트 규모의 레버리지

1. 실행 중인 작업의 추정치

   1. 불확실한 집계: Boris는 Swift 재작성 작업이 몇 개의 에이전트를 생성했는지 정확히 모른다고 말한다.
   2. 추정 규모: 수천 개, 많으면 1만 개 정도일 것으로 추측한다.
   3. 청중 비교: 1,000개가 넘는 에이전트를 생성한 프롬프트를 써본 사람이 있는지 묻자 아무도 손을 들지 않았다.

2. 동적 워크플로의 기본 사용법

   1. 가장 쉬운 호출: Claude Code에 “use a workflow”라고 말하면 동적 워크플로를 트리거할 수 있다.
   2. 실행 환경: Bun을 샌드박스로 사용하고 그 안에서 가상 머신을 시작한다.
   3. 오케스트레이션: Claude가 많은 에이전트를 시작하고 서로의 작업을 조정하게 한다.

7.2. 동적 워크플로의 다단계 구조

1. 초기 병렬화

   1. 첫 패스: 코드베이스 재작성, 심층 데이터 분석, 복잡한 데이터 작업, 여러 단계와 수십 개의 풀 리퀘스트가 필요한 기능을 작은 작업으로 나눈다.
   2. 다수 에이전트: 여러 에이전트가 첫 번째 작업을 병렬로 수행한다.

2. 검증과 요약 단계

   1. 두 번째 집합: 첫 패스 결과를 다른 에이전트들이 검증하거나 요약한다.
   2. 재확장: 세 번째 단계에서 다시 여러 갈래로 fan-out해 후속 작업을 실행한다.
   3. 생산적 조정: 단순히 에이전트를 많이 띄우는 것이 아니라 결과에 따라 다음 에이전트의 역할과 작업을 정한다.

3. 함수형 프로그래밍에서 온 설계

   1. 설계 관점: Boris의 배경은 함수형 프로그래밍(functional programming)이다.
   2. 에이전트 대수(algebra): 에이전트를 순차 실행하는 방식과 병렬 실행하는 방식을 조합할 수 있는 구조로 동적 워크플로를 설계했다.
   3. 효율: 샌드박스 안의 도구들이 에이전트를 조정하고 토큰을 효율적으로 사용하면서 복잡한 작업을 처리한다.

7.3. Dynamic workflow는 새로운 test-time compute다

1. 기존 스케일링 법칙

   1. 훈련 컴퓨트: 과거 모델의 지능 향상은 신경망 크기, 훈련 데이터 양, 훈련에 투입한 FLOPs의 함수로 설명됐다.
   2. 테스트 타임 컴퓨트: 최근에는 모델이 추론 중 생성하는 토큰 수를 늘리는 방식도 사용됐다.

2. 오케스트레이션으로 확장된 추론

   1. 새 방식: 동적 워크플로는 test-time compute를 조직하는 새로운 방법이다.
   2. 난도 대응: 단일 모델이 한 번 생성하는 토큰만 늘리는 것이 아니라 수많은 에이전트의 작업·검증·재작업으로 어려운 과제에 투입되는 컴퓨트를 크게 늘린다.
   3. 핵심 효과: 수천 에이전트를 무작정 병렬 실행하는 대신, 목표를 달성하는 방식으로 생산적이고 효율적으로 사용한다.

7.4. Loop와 routine으로 반복 업무를 자동화하기

1. 동적 워크플로와의 차이

   1. Dynamic workflow: 하나의 큰 과제를 여러 조각으로 나눈다.
   2. Loop: 로컬에서 실행되는 Claude Code용 cron job이다.
   3. Routine: 클라우드에서 실행되는 같은 종류의 반복 작업이다. 노트북을 닫아도 계속된다.
   4. 작업의 성격: loop와 routine은 서로 컨텍스트를 공유하지 않는 반복 작업이지만 메모리는 공유할 수 있으며, 매시간·5분마다·매일처럼 반복 실행된다.

2. Claude Code가 스스로 유지보수하는 구조

   1. 운영 방식: Slack 채널에서 여러 routine을 시작해 Claude Code의 코드베이스를 유지보수한다.
   2. 적용 제품: CLI, iOS 앱, Android 앱, 데스크톱 앱에 적용한다.
   3. 자기 유지보수의 의미: 엔지니어가 모든 정리 작업을 직접 예약하지 않고, 모델이 코드베이스를 살피고 필요한 요청을 만들어낸다.

3. 실제로 돌리는 단일 문장 routine

   1. Dead code 정리: “dead code를 정리하라”는 한 문장 프롬프트를 매일 실행한다. 모델은 정적·동적 분석으로 여러 코드베이스에서 죽은 코드를 찾고 매일 삭제 풀 리퀘스트를 올린다.
   2. 실험 코드 제거: 실험이 이미 100% 사용자에게 출시됐으면 플래그와 실험 코드를 삭제하고 기능을 정식 배포한다.
   3. 테스트 보강: 테스트 커버리지가 필요한 영역을 찾아 테스트를 작성한다.
   4. 불필요한 테스트 삭제: 예전 모델이나 사람이 만든 무의미한 테스트를 찾아 제거한다.
   5. Abstraction police: 큰 코드베이스 곳곳에 거의 같은 추상화가 중복되면 이를 찾아 하나로 통합한다. 모델이 매일 모든 코드베이스를 살펴보고 사실상 같은 추상화를 통일한다.

4. 엔지니어의 역할 변화

   1. 운영 규모: 매일 약 20~30개의 routine이 여러 코드베이스에서 실행된다.
   2. 현재의 한계: 아직 완전 자동화 단계에는 도달하지 않았다.
   3. 에이전트 규모: 매일 수백 개, 때로는 수천 개의 에이전트가 유지보수 작업을 수행한다.
   4. 인력 레버리지: 과거에는 수십~수백 명의 엔지니어가 하던 일을 대신한다.
   5. 사람의 집중점: 엔지니어는 죽은 코드 정리보다 제품 출시, 사용자 대화, 재미있는 문제에 집중할 수 있다.

8. 코딩이 해결되어도 남는 뛰어난 빌더의 기준

코드 생성이 많은 영역에서 해결되어 가더라도 깊은 시스템·분산 시스템·픽셀 단위 UI 검증은 여전히 어렵고, 차이를 만드는 역량은 경험적 사고다.

8.1. ‘코딩이 해결됐다’는 말의 범위

1. 중요한 단서

   1. 제한된 주장: Boris는 “자신이 하는 종류의 코딩”에 대해서 코딩이 해결됐다고 말한 것이라고 정정한다.
   2. 깊은 시스템 코드: 매우 깊은 시스템 코드베이스에서는 Claude Code가 여전히 어려움을 겪는다.
   3. 분산 시스템: 복잡한 분산 시스템도 여전히 힘든 영역이다.
   4. UI 검증: 한 픽셀의 위치가 어긋나는 수준의 세밀한 UI 검증은 완벽하지 않다.

2. Opus 5의 진전과 미완성

   1. 큰 도약: Opus 5는 비전(vision)과 컴퓨터 사용(computer use)에서 큰 발전을 보였다.
   2. 남은 문제: 그렇다고 픽셀 단위 UI와 모든 컴퓨터 사용 작업을 완벽히 처리하는 것은 아니다.
   3. 보급 상황: 청중에게 손을 들어 100% 에이전트로 코드를 작성하고 손으로는 전혀 코딩하지 않는지 묻자 꽤 많은 사람이 손을 들었다. 코드의 절반 이상을 에이전트가 작성하는 사람은 그보다 조금 적었지만 비슷한 규모였다.

8.2. 이론보다 경험이 우선인 사고방식

1. 과거의 선입견 지우기

   1. 기존 지식의 보류: 과거 모델에 대해 배운 방법과 교실에서 배운 컴퓨터과학 이론을 잠시 잊는다.
   2. 실험 순서: 모델에게 과제를 주고, 어디에서 어려워하는지 보고, 그 결과에 맞춰 조정한다.
   3. 현재의 과학: 에이전트 제품 개발은 이론 과학보다 경험 과학(empirical science)에 가까워졌다.

2. 뛰어난 사용자의 공통점

   1. 선입견 버리기: 예전에 실패했던 접근이라는 이유만으로 현재 모델에도 실패할 것이라고 단정하지 않는다.
   2. 재시도: 새 모델이 능력을 얻었을 가능성을 열어두고 다시 실험한다.
   3. 개방성: 작동하지 않았던 아이디어와 과거의 priors를 놓고 새로운 결과에 맞춰 판단한다.

9. AI 시대에 학생이 손으로 배워야 할 것

프로그래밍 자체를 외우는 것보다 실제 문제를 해결하고 제품·사용자·사업과 연결하는 능력이 오래 남는다.

9.1. Boris가 컴퓨터과학을 배운 방식

1. 실용적 독학

   1. 문제에서 출발: Boris는 컴퓨터과학을 이론부터 공부하기보다 문제를 해결하려고 코딩을 독학했다.
   2. TI-83: 중학생 때 TI-83 계산기에서 처음 코딩했다.
   3. 온라인 자료: TI-83 프로그래밍 가이드를 인터넷에 직접 썼고, 그 글은 아직 온라인 어딘가에 남아 있다고 한다.

2. 시험 부정행위라는 실용적 동기

   1. 첫 언어: 계산기에서 사용한 첫 언어는 BASIC이었다.
   2. 목적: 수학 시험을 더 잘 보기 위해 계산기로 답을 계산하는 프로그램을 만들었다고 농담했다. 청중은 박수로 반응했다.
   3. 공유: 작은 시리얼 케이블을 구해 반 친구들에게 프로그램을 전달했고 친구들도 좋은 점수를 받았다.

3. 문제가 어려워지며 언어를 바꾼 경험

   1. 대수 단계: 처음에는 BASIC으로 대수 문제를 푸는 계산기를 만들었다.
   2. 미적분 단계: 수학이 미적분으로 어려워지자 BASIC만으로는 충분하지 않았다.
   3. 어셈블리: 더 나은 풀이기를 만들기 위해 어셈블리(assembly)를 배웠고, 농담으로 “더 잘 부정행위하기 위해” 배웠다고 표현했다.
   4. 핵심 패턴: 필요한 문제가 생길 때마다 새로운 기술을 배우고 바로 적용하는 방식이 그의 프로그래밍 학습을 이끌었다.

9.2. 컴퓨터과학을 다른 역량과 결합하라

1. 배워야 할 응용 능력

   1. 창업: 기술을 실제 스타트업으로 연결하는 법을 배운다.
   2. 제품: 사람들이 쓸 제품을 만드는 법을 배운다.
   3. 디자인 감각: 사용자가 이해하고 좋아할 경험을 판단하는 감각을 기른다.
   4. 비즈니스 감각: 어떤 문제가 가치가 있고 지속 가능한지 판단한다.
   5. 데이터 과학: 데이터를 분석하고 의사결정에 사용하는 능력을 익힌다.
   6. 사용자 대화: 실제 사용자의 문제와 언어를 직접 듣는다.

2. 손으로 계속 익힐 하드 스킬

   1. 직접 적용: 에이전트가 코드를 대신 써도 문제를 정의하고 결과를 평가하는 능력은 직접 길러야 한다.
   2. 결합의 가치: 컴퓨터과학·엔지니어링이 디자인·사업·데이터·사용자 이해와 결합할 때 가치가 커진다.
   3. 학습 순서: 자신이 원하는 것을 먼저 만들고, 그다음 다른 사람들이 원하는 것을 만드는 방향으로 확장한다.

주요 발언 모음

“먼저 삭제하라. 다음에는 사용하라. 모델이 반복해서 같은 곳에서 넘어질 때만 지시를 되돌려라.”

“모델은 살아 있는 생물처럼 생각해야 한다. 모델 세대마다 다르게 행동하고, 우리는 그 모델을 알아가는 시간을 가져야 한다.”

“작업을 주고, 결과를 검증할 방법을 주면, 모델은 그냥 계속 간다.”

“사람들이 찾는 ‘한 가지 기묘한 트릭’은 없다. 경험적으로 접근해야 한다.”

“에이전트 제품 개발은 이론 과학이 아니라 경험 과학이 됐다.”

“자신이 할 수 있다고 생각하는 것보다 조금 더 어려운 일을 모델에게 줘라.”

“LinkedIn 인플루언서의 말을 듣지 말고 Twitter를 읽지 말라.”

“코딩이 해결됐다는 말은 내가 하는 종류의 코딩에 한정된다. 깊은 시스템, 분산 시스템, 픽셀 단위 UI는 아직 어렵다.”

핵심 데이터 & 수치

• ARC AGI 3 약 30%: Opus 5가 기록한 점수로, 이전 최고 수준인 한 자릿수 초반~10%대 초반과 비교해 크게 상승했다.
• 80% 이상: Opus 5에 맞춰 Claude Code 시스템 프롬프트에서 삭제한 비율이다.
• 약 3년: 정렬(alignment) 연구를 통해 모델의 기본적인 인젝션 저항성을 개선해 온 기간이다.
• 약 1년 반~2년 전: Sonnet 3.5 시기에 Claude Code가 시작된 시점이다.
• 11일: Bun 코드베이스를 Zig에서 Rust로 재작성한 동적 워크플로의 실행 기간이다.
• 10만 줄 이상 규모: Rust 재작성 대상이었던 복잡한 JavaScript 프런트엔드급 코드베이스의 규모로 언급됐다.
• 14~15일 이상: Electron 데스크톱 앱을 Swift 네이티브 앱으로 재작성하고 픽셀 단위로 비교하던 장기 작업의 경과 시간이다.
• 수천~1만 개 추정: Swift 재작성 작업이 생성했을 것으로 Boris가 추정한 에이전트 수다.
• 매일 20~30개 routine: CLI·iOS·Android·데스크톱 코드베이스에서 반복 실행하는 유지보수 자동화의 대략적인 개수다.
• 매일 수백~수천 개 에이전트: routine을 통해 코드 정리·테스트·추상화 통합 등에 투입되는 규모다.
• 한두 세대, 길면 세 세대: 기존 eval이 모델 개선으로 포화되기 전까지 유효할 수 있는 대략적인 수명이다.
• 6개월: Claude Code 사용자가 새 모델의 능력을 확인하기 위해 CLAUDE.md, skills, hooks 삭제를 실험해 볼 수 있는 주기다.
• 6개월 전: Electron 데스크톱 앱이 느리고 불안정했지만 현재는 팀이 주로 사용하는 수준으로 개선된 시간 비교 기준이다.
• Max 20X: 행사 참석자 모두에게 이메일로 제공한다고 발표한 마지막 특별 혜택이다.

핵심 요약 (20줄)

Boris Cherny는 Opus 5가 ARC AGI 3에서 약 30%를 기록하며 이전 한 자릿수·10%대 초반 최고치를 크게 넘어섰다고 말했다. Opus 5는 auto mode와 결합하면 별도 스캐폴딩 없이 며칠·몇 주·몇 달 동안 작업을 이어갈 수 있다. 정렬 연구와 인젝션 분류기, 내부 뉴런 감시, 오토모드 분류기를 결합하면 악성 프롬프트 인젝션을 차단할 수 있다. Claude Code 팀은 모델이 바뀔 때마다 시스템 프롬프트와 도구, 하네스 코드를 과감히 삭제한다. Opus 5에 맞춰 Claude Code 시스템 프롬프트의 80% 이상이 제거됐다. --system-prompt와 CLAUDE_CODE_SIMPLE=1은 프롬프트를 거의 또는 완전히 비우는 실험을 가능하게 한다. 새 지시는 미리 추측하지 말고 실제 사용 중 같은 실패가 반복될 때만 다시 추가해야 한다. 모델은 세대마다 능력과 성격이 달라지는 살아 있는 협업자처럼 다뤄야 한다. Eval은 한두 모델 세대 뒤 포화될 수 있으므로 실제 실패 지점에 맞춰 새로 만들어야 한다. 제품 오버행은 현재 모델이 할 수 있지만 제품이 아직 끌어내지 못한 능력을 뜻한다. 초기 Claude Code는 Sonnet 3.5에 터미널 전체 접근 권한을 주어 IDE의 읽기 중심 제약을 풀었다. 높은 수준의 과제와 가드레일, 종료 조건만 주고 모델이 과정을 선택하게 해야 한다. Bun 팀은 테스트 스위트를 검증 장치로 삼아 Zig 코드베이스를 Rust로 11일 만에 재작성했다. Opus 5는 별도 그림 훈련 없이 OpenCV로 초상·동물·풍경을 그리는 능력도 보여줬다. 모델 활용의 핵심은 프롬프트 비법보다 어려운 과제와 자기 검증 방법을 함께 설계하는 일이다. Electron 앱을 Swift로 다시 쓰고 픽셀 단위로 비교하는 작업은 14~15일 넘게 계속 실행됐다. 동적 워크플로는 여러 에이전트를 순차·병렬·검증 단계로 조합해 새로운 test-time compute를 만든다. Loop는 로컬 cron이고 routine은 클라우드에서 반복 실행되며 코드 유지보수를 자동화한다. 깊은 시스템·분산 시스템·픽셀 단위 UI 검증은 아직 완전히 해결되지 않았다. 학생은 TI-83에서 문제를 해결하던 방식처럼 코딩을 제품·디자인·사업·데이터·사용자 이해와 결합해야 한다.

결론 및 시사점

1. 삭제가 최신화의 출발점이다: 새 모델이 나오면 과거 프롬프트·스킬·훅·도구가 여전히 필요한지 의심하고, 통째로 제거한 뒤 실제 행동을 관찰한다.
2. 과정 지시보다 결과 검증이 중요하다: 모델에게 일을 대신하는 절차를 모두 적기보다 목표·가드레일·종료 조건과 스스로 확인할 수 있는 테스트·스크린샷·분석 도구를 제공한다.
3. 제품의 해자는 숨은 능력의 발견이다: 최신 모델이 이미 할 수 있지만 기존 UI나 하네스가 막고 있는 작업을 찾으면 다음 Claude Code와 같은 제품 기회가 생긴다.
4. 에이전트 수는 컴퓨트 설계 문제다: 동적 워크플로는 순차·병렬·재검증을 조합해 수천 에이전트를 생산적으로 사용하고, loop와 routine은 반복 유지보수를 상시 자동화한다.
5. 경험적 사고가 새로운 기본기다: 과거 모델의 실패와 전통적인 컴퓨터과학 설계 습관을 절대 규칙으로 삼지 말고, 새 모델에 다시 과제를 던져 결과로 판단한다.
6. 사람의 우위는 문제와 맥락에 있다: 코드를 생성하는 일의 비용이 낮아질수록 문제 선택, 사용자 대화, 제품 감각, 비즈니스 판단, 데이터 해석이 더 중요해진다.
7. 학습은 직접 만들기에서 시작한다: 자신이 원하는 작은 도구를 직접 만들고, 그 도구를 다른 사람이 원하는 제품으로 발전시키면서 기술과 응용 감각을 함께 익힌다.
8. 실험의 목표를 크게 잡는다: Boris는 행사 참석자에게 이메일로 Max 20X 코드를 제공하며, 여러 달 동안 실행되고 수천 에이전트를 사용하는 무언가를 만들어 보라고 권했다.