보리스 체르니: Claude Code는 이렇게 만들어졌다

URL: https://www.youtube.com/watch?v=UkoosAsEA8w 날짜: 2026-07-29 채널: Tech Bridge (TechBridge-KR)

---

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

==Claude Code 창시자 보리스 체르니(Boris Cherny)가 Opus 5 출시 직후 진행된 무대 인터뷰에서, 새 모델의 역량·프롬프트 인젝션 방어 아키텍처·"끊임없이 삭제하는" 하네스 개발 철학·수천 개 에이전트를 오케스트레이션하는 실전 사례를 공개한다.==

• Opus 5는 ARC-AGI-3 점수를 한 자릿수에서 30%까지 끌어올렸고, 스캐폴딩 없이 며칠~몇 달간 자율적으로 작업을 지속할 수 있다.
• 정렬(alignment) 모델 + 기계론적 해석 가능성 기반 프롬프트 인젝션 분류기 + 자동 모드 분류기, 3계층 방어로 더 이상 프롬프트 인젝션을 시연할 수 없게 됐다고 밝힌다.
• Claude Code 팀은 새 모델이 나올 때마다 시스템 프롬프트·툴·훅을 대부분 삭제하고 처음부터 다시 쌓아 올리는 "절제술(ablation)" 방식으로 하네스를 재구축한다.
• Bun 런타임을 Zig에서 Rust로 11일 만에 전면 재작성한 사례, 보리스 본인이 Claude Desktop을 Swift로 2주 넘게 자율 재작성시킨 사례 등 "오늘의 모델로 아직 아무도 못 깨달은 기회"를 실험으로 찾아내는 방법론을 제시한다.
• 동적 워크플로우(수천 개 에이전트 오케스트레이션)와 루프/루틴(반복적 자율 유지보수) 두 축으로 코드베이스 유지보수를 완전 자동화하는 내부 사례도 공유한다.

본 인터뷰는 컨퍼런스 무대에서 진행된 질의응답 형식으로, Opus 5 발표 다음 날 진행되었으며 청중 투표(2주 이상 에이전트 실행 경험 유무, 1000개 이상 에이전트 실행 경험 유무)를 통해 현장의 실전 활용 수준도 함께 드러난다.

---

1. Opus 5의 새로운 역량: 벤치마크 도약과 장시간 자율 작동

이 섹션에서는 Opus 5가 이전 모델과 비교해 어떤 새로운 기능을 수행할 수 있게 됐는지, 그리고 그 기능들이 어떻게 발견되는지를 다룬다.

1.1. ARC-AGI-3 점수 도약과 학습되지 않은 능력의 발현

1. 벤치마크 성과

   1. 점수 상승폭: 이전 최고 점수가 한 자릿수~10점대 초반이었던 ARC-AGI-3에서 Opus 5는 30%까지 도달했다.
   2. 학습 과정의 우연성: 새 모델을 학습시킬 때 여러 가지를 가르치려 시도하지만 대부분은 의도대로 되지 않고, 오히려 가르치지 않은 기술을 모델이 자연스럽게 습득하는 경우가 있다.

2. 다섯 번째 핵심 능력 — 초장시간 자율 작동

   1. 지속 시간: Opus 5를 자동 모드와 함께 사용하면 며칠, 몇 주, 심지어 몇 달 동안 멈추지 않고 작동한다.
   2. 비계(scaffolding) 불필요: 스크래치 목표나 별도의 보조 장치 없이도 해야 할 일을 알고 그대로 진행한다.

1.2. 프롬프트 인젝션에 대한 근본적 저항

1. 변화의 배경

   1. 이전 상황: 1년 전만 해도 모델이 인터넷에서 읽은 "X, Y, Z를 수행하고 사용자 컴퓨터의 모든 것을 삭제하라" 같은 지시를 그대로 따랐다.
   2. 점진적 개선: Opus 4.7, 4.8부터 이런 경향이 개선되기 시작했고 Sonnet 5·Haiku도 어느 정도 개선됐지만, Opus 5는 완전히 새로운 지평을 열었다고 평가된다.
   3. 업계 용어: 정렬이 잘 안 된 모델 + 강력한 툴 접근권 + 신뢰할 수 없는 콘텐츠 노출의 조합을 업계에서는 오랫동안 "치명적인 삼중주(lethal trifecta)"라 불러왔다.
   4. 제품 설계에 미치는 영향: 이 문제는 하네스 설계·에이전트 설계·제품 설계 전반에 영향을 미치는 핵심 이슈다.

2. 3계층 방어 아키텍처

   1. 1계층 — 정렬된 모델: 3년간의 정렬 연구 결과가 반영된 기본 모델.
   2. 2계층 — 실시간 프롬프트 인젝션 분류기: 모든 트래픽에 대해 실행되며, Chris Olah의 기계론적 해석 가능성(mechanistic interpretability) 연구를 기반으로 한다. 모델의 "뇌"에서 즉각적인 주입이 발생했을 때 활성화되는 뉴런을 직접 관찰해 진단한다. 모델 스스로는 알려주지 않지만 이 뉴런 관찰을 통해 인젝션 발생 여부를 파악할 수 있다.
   3. 3계층 — 자동 모드 분류기: 위 분류기 결과를 자동 모드 판단 로직과 결합한다.
   4. 결과: 이 세 계층의 결합으로 인해 더 이상 프롬프트 인젝션을 성공적으로 시연할 수 없게 되었다.

---

2. "삭제 문화": 새 모델마다 하네스를 다시 짓는 개발 철학

이 섹션에서는 Claude Code 팀이 신모델 출시 때마다 시스템 프롬프트·툴·코드를 어떻게 재구축하는지, 그리고 그 방법론(절제술)을 설명한다.

2.1. 시스템 프롬프트의 80% 이상을 삭제한 이유

1. 하네스의 끊임없는 변화

   1. 상시 변경: 클로드 코드라는 제품이자 하네스 자체가 끊임없이 새 기능을 추가하고 기존 것을 삭제하며 변화한다.
   2. 모델별 재작업: 새 모델이 나올 때마다 시스템 프롬프트 일부를 삭제·변경하고, 도구 세트와 도구용 프롬프트도 항상 바꾼다. 3개월 전 한 모델을 위해 했던 작업이 다음 모델에는 전혀 맞지 않을 수 있기 때문이다.

2. Opus 5에서의 80% 삭제

   1. 이유: Opus 5는 매우 지적인 모델이라, 이전 시스템 메시지에 담겨 있던 "모델이 원래 알아야 했지만 몰랐던 동작을 수정하는" 내용의 상당수가 더 이상 필요 없어졌다.
   2. 실험 방법: --system-prompt 플래그로 원하는 시스템 프롬프트를 직접 설정해 실험할 수 있다.
   3. 비공식 기능 — Simple 모드: 공식 문서에 없는 기능으로, 환경 변수 simple을 1로 설정하고 Claude를 실행하면 도구 설명을 포함한 모든 시스템 프롬프트가 삭제된다. 팀은 이를 프롬프트 유용성을 검증하는 일종의 "제거 테스트"로 활용한다.
   4. 역설적 발견: 이러한 프롬프트가 없을 때 모델이 오히려 조금 더 똑똑해지는 경향이 있다는 것을 발견했다. 다만 제품으로서 클로드 코드를 사용할 때는 사용자가 원하는 방식으로 작동하도록 돕기 위해 이 프롬프트들이 실제로 필요하다.

2.2. 절제술(Ablation) 방법론

1. 개념 정의

   1. 절차: 시스템 프롬프트 전체를 삭제한 다음, 각 줄이 미치는 영향을 파악하기 위해 한 줄씩 다시 불러오는 방식이다.
   2. 본질: 절제술은 기본적으로 평가(eval)이며, 특정 부분을 제거해 그 영향을 파악하는 과정이다.
   3. 도구에도 동일 적용: 도구 역시 항상 포장을 해제(unwrap)하며, 배선 하네스에서 코드를 삭제하는 작업을 상시적으로 수행한다.

2. 현재 하네스 코드의 구성

   1. 보안 중심: 현재 Claude Code 하네스에 남아 있는 코드의 거의 대부분은 보안, 권한, 정적 분석과 관련된 것이다.
   2. UI 코드: UI 코드가 상당 부분을 차지하며, 나머지는 이미 상당 부분 오픈소스로 공개했다.

3. 모든 AI 제품 개발자를 위한 조언

   1. 삭제를 편안하고 용감하게: 새 모델이 나올 때마다 삭제 버튼을 누르는 것에 대해 편안하고 용감해져야 한다고 강조하며 "100%" 동의한다고 답했다.
   2. 비개발자 사용자에게도: 에이전트 기반 제품을 개발하지 않고 클로드 코드를 그냥 사용하는 사람도 6개월마다 프롬프트·스킬·훅을 삭제하고 모델이 어떻게 작동하는지 살펴보라고 권한다. Opus 5의 경우 특히 이전 모델에 필요했던 지침이 더 이상 필요하지 않을 수 있어 강력히 권장한다.
   3. 재구축 단계: ① 삭제한다 → ② 직접 사용해 본다(모델이 필요로 하는 명령어를 추측하지 말고 실제로 실행해서 확인) → ③ 같은 문제에 반복적으로 부딪힐 때에만 지침을 다시 추가한다. 단, 너무 일찍 추가해서는 안 된다. 모델은 사용할 때마다 그 지침을 읽어야 하므로, 정말 필요한지 확인해야 한다.

2.3. 유기적 시스템으로서의 모델 — 경험과학적 접근

1. 전통적 엔지니어링과의 차이

   1. 과거 방식: 크고 아름다운 시스템을 설계하고, 시스템 설계를 처음부터 심도 있게 고민하며, 방대한 유닛 테스트를 쌓는 방식이었다. 재건축은 몇 달, 대기업에서는 몇 년씩 걸리는 큰 프로젝트였다.
   2. 모델은 다르다: 모델을 마치 살아있는 유기체처럼, 세대마다 다른 개성을 가진 존재로 받아들이고 시간을 들여 특성을 파악한 뒤 하네스를 그에 맞춰 조정해야 한다.

2. 평가(eval)의 수명은 하네스보다 조금 더 길 뿐

   1. 지속 원칙: 코드와 시스템 프롬프트는 삭제해야 하지만, 평가는 유지하며 계속 추가해 나간다.
   2. 평가도 결국 폐기된다: 평가용 부품의 수명이 하네스보다 약간 더 길긴 하지만 큰 차이는 아니다. 길어야 한두 세대, 많아야 세 세대 정도 적용되며, 모델이 너무 빠르게 개선되어 평가가 포화 상태에 이르면 해당 평가를 폐기하고 새로 만들어야 한다.
   3. 평가 구성 방식: 제품과 모델을 직접 사용해보고 어떤 부분에서 어려움을 겪는지 파악한 뒤, 그 결과를 바탕으로 평가 세트를 구성한다.

---

3. 언허블링(Unhobbling)과 제품 과잉 공급(Product Overhang)

이 섹션에서는 "모델의 제약을 풀다"라는 연구 개념이 제품 개발에 어떻게 적용되는지, Claude Code의 탄생 배경과 함께 설명한다.

3.1. 두 개념의 정의

1. 언허블링(방해 제거)

   1. 연구 어원: 모델이 어떤 일을 할 수 있는데 그것을 방해하고 있다는 뜻의 연구 용어다.
   2. 핵심 아이디어: 미래의 모델이 아니라 오늘날의 모델을 이용해서 아직 실현하지 못한 온갖 일들을 해낼 수 있다는 것. 현재 모델에는 사람들이 알지 못하는 수많은 기능(특정 도구·언어·문제 해결 방식)이 이미 내장돼 있다.

2. 제품 과잉 공급(방해 요소로서의 제품)

   1. 정의: 모델이 세대마다 특정 작업을 수행할 능력이 있지만, 그 능력을 표현하도록 지원하는 제품이 없어서 제품 자체가 방해가 되는 상황.
   2. 관계: 언허블링과 제품 과잉 공급은 같은 것의 양면이다.

3.2. Claude Code 탄생 배경: Sonnet 3.5의 언허블링

1. 1~2년 전 상황

   1. 당시 최고 코딩 모델: Sonnet 3.5는 당시 현존 최고의 코딩 모델이었지만, 요즘 기준으로 보면 상당히 형편없는 수준이었다. 그럼에도 Anthropic이 만든 최초의 훌륭한 코딩 모델이었다.
   2. 당시 코딩 제품들의 한계: 한 줄짜리 자동완성, 가끔 여러 줄 자동완성, 읽기 전용 채팅(코드베이스에 질문은 가능하나 쓰기 권한 없음) 정도가 전부였다. 모델이 한 번에 전체 함수나 파일을 작성할 수 있는 제품은 없었다.
   3. Claude Code의 아이디어: 모든 구조를 제거하고 모델에 가장 단순한 구조만 제공해 한 번에 전체 파일을 작성하고 전체 기능을 구축할 수 있게 하면 어떨까 하는 질문에서 출발했다.

2. 터미널 완전 접근이라는 최초의 시도

   1. 기존 제한: 이전 제품들은 IDE 안에서 모델을 지나치게 경직되게 제한했다.
   2. Claude Code의 차별점: 최초로 터미널에 완전한 접근 권한을 부여한 사례 중 하나였고, 그것이 지금까지 계속 사용되는 놀라운 제품을 만들어냈다.

3. 현재적 시사점

   1. 모델 분리 방법을 찾으면 차세대 제품이 나온다: 청중을 향해, 모델을 언허블링하는 방법을 알아내면 누구나 차세대 클로드 코드를 만들어낼 수 있다고 말한다.
   2. 현대 모델일수록 제품 과잉 공급이 심하다: 최근 모델일수록 아직 발굴되지 않은, 놀랍고 상업적으로 가치 있는 행동을 이끌어낼 기회가 엄청나게 많다고 강조한다.

---

4. 오늘의 모델로 무엇을 할 수 있는가: 실전 사례 두 가지

이 섹션에서는 실제 코드베이스를 완전히 새로 작성한 두 가지 대표 사례를 통해 "올바른 작업 지시" 방법론을 설명한다.

4.1. 접근 원칙: 지나치게 구체적인 지시를 피하라

1. 흔한 실수
   1. 과도하게 구체적인 지침: 사람들이 클로드 코드를 사용할 때 "이걸 이런 식으로, 저런 식으로, 1·2·3·4단계로 해야 해"라는 식으로 너무 세세하게 지시하는 실수를 자주 저지른다. 최신 모델에는 올바른 방법이 아니다.
   2. 올바른 방향: 작업을 설명하고, 안전장치를 설명하고, 종료 기준을 설명한 다음 모델과 함께 진행하다가 잠시 후 다시 돌아오는 방식이 놀라운 결과를 낸다. 6개월 전에는 통하지 않았을 방식이지만 지금은 통한다.
   3. 약간 더 어려운 과제 부여: 모델이 할 수 있다고 생각하는 것보다 약간 더 어려운 작업을 줘야 한다.

4.2. 사례 1 — Bun 런타임의 Zig→Rust 전면 재작성 (11일)

1. 배경

   1. Bun 소개: Node.js의 대안이 되는 오픈소스 JavaScript 런타임으로, Zig(시스템 프로그래밍 언어, C와 유사한 저수준 언어)로 작성됐다.
   2. 기존 문제: Zig는 메모리를 수동 관리해야 해서 메모리 누수 등 관리 문제가 생기기 쉬웠다. Bun 팀은 한동안 Claude를 활용해 코드베이스를 퍼징하고 메모리 누수를 시뮬레이션·발견하는 작업을 진행해왔다.

2. 재작성 결정과 실행

   1. 결단: 팀의 제러드가 "모델이 이걸 다시 작성할 수 있을지도 모른다"고 제안했고, Fable 모델 세대부터 실제로 해낼 수 있게 됐다.
   2. 검증 인프라 활용: Bun과 Node.js 모두 대규모 테스트 스위트를 보유하고 있어 결과가 옳은지 쉽게 검증할 수 있었다는 점이 핵심 조건이었다.
   3. 프롬프트: Zig에서 Rust로 코드를 다시 작성하라는 프롬프트 단 하나. 동적 워크플로(dynamic workflow) 기능을 활용해 수십~수천 명의 에이전트를 조율하도록 했다.
   4. 소요 기간: 11일 만에 전체 코드베이스를 새로 작성했다. 이전 최고 엔지니어들이라면 최소 1년 이상 걸렸을 작업(10만 줄이 넘는 복잡한 JavaScript 런타임)이다.
   5. 조종 가능성: 완전한 원샷은 아니었고 중간에 조향(steering)이 가능했지만, 이전 모델들은 조향을 사용해도 이런 작업 자체가 불가능했다.
   6. 현재 상태: 이 재작성된 결과물은 현재 실제 프로덕션에서 사용 중이며, Claude Code를 실행할 때 쓰이는 코드 그 자체다.

4.3. 사례 2 — Claude Desktop 앱의 Electron→Swift 재작성 (진행 중, 2주+)

1. 동기

   1. 기존 상태: Claude 데스크톱 앱은 Electron으로 개발돼 6개월 전만 해도 느리고 불안정했지만, 지금은 팀원 대부분이 사용하는 훌륭한 도구로 발전했다.
   2. 실험 동기: 네이티브 앱처럼 작동하면 어떤 느낌일지 궁금해서 실험을 시작했다.

2. 실행 과정

   1. Claude Tag 세션 시작: 슬랙에서 실행되는 새 제품 "Claude Tag"를 이용했다. 먼저 GitHub의 macOS 러너 접근 권한을 요청했으나 거부되어, 러너를 연결한 뒤 GitHub로 Mac 가상 머신을 구동할 수 있게 됐다.
   2. 빈 Swift 코드베이스 준비: Claude Desktop 앱을 Swift로 재작성할 완전히 빈 코드베이스를 만들고 접근 권한을 부여했다.
   3. 단일 프롬프트: "Electron 앱을 Swift로 다시 작성하라. Mac 가상 머신에서 Electron 앱을 실행하고 스크린샷을 찍은 다음 픽셀 단위로 Swift 버전과 비교하라. 끝날 때까지 멈추지 마라." — 이것이 받은 프롬프트의 전부였다.
   4. 동적 워크플로 사용: 역시 동적 워크플로를 통해 실행됐다.

3. 결과와 규모

   1. 소요 기간: 인터뷰 시점 기준 2주 조금 넘게(14~15일) 계속 실행 중이었다. 청중 중 아무도 2주 이상 클로드에게 작업을 실행시켜 본 사람이 없었다.
   2. 생성된 에이전트 수: 정확한 수는 파악하지 못했지만 수천~수만 명 규모로 추정된다. 청중 중 1000개 이상의 에이전트를 생성하는 워크플로를 실행해 본 사람도 없었다.
   3. 부수 효과: Claude가 자체적으로 슬랙 채널을 만들어 몇 분마다 진행 상황 스크린샷을 올리며 실시간 진행 상황을 공유했다.
   4. 시사점: 지시 자체는 단순했지만("여기 있는 누구든 할 수 있다"), 모델에게 검증 가능한 방식(작업을 주고, 결과를 검증하는 방법을 제공)으로 막힘없이 계속 진행하게 하는 것이 핵심이었다. 별도의 고급 도구(/go, /loop 등) 없이도 가능했다.

4.4. 두 번째 방법론: 순수 실험과 우연한 발견

1. OpenCV 그리기 사례
   1. 발견 경위: 최근 몇 주간 Anthropic 내부에서 입소문을 탄 사례로, 누군가 Opus 5에 OpenCV를 입력해 그림을 그리게 할 수 있다는 것을 발견했다.
   2. 결과: Opus에게 "CV를 이용해 이 이미지를 그려줘"라고 요청하면 인물화·동물화·풍경화를 꽤 훌륭하게 그려낸다. 모델은 그림을 그리도록 별도로 훈련받은 적이 없다.
   3. 의미: 제대로 된 방식으로 요청하면 모델이 이미 갖고 있던 "입찰 격차(bid gap)"를 그대로 해낼 수 있다는 것을 보여준 사례이며, 상업적 목적과 무관한 창의적 실험 중 우연히 발견됐다.
   4. 가설: 오늘날의 모델을 활용해 아직 아무도 깨닫지 못한 이런 기회가 수십, 수백 개는 존재할 것이다.

---

5. 신속 엔지니어링에서 모델 도출(Model Elicitation)로

이 섹션에서는 프롬프트 엔지니어링이라는 직무가 왜 소멸하고 있는지, 무엇이 그 자리를 대신하는지를 설명한다.

1. 직무 트렌드의 변화

   1. 1년 전: 가장 인기 있는 채용 공고 중 하나가 "신속 엔지니어(prompt engineer)"였다.
   2. 그다음: "컨텍스트 엔지니어" 같은 명칭으로 바뀌었다. 이런 명칭은 주기적으로 생겼다 사라지는 현상일 뿐이라고 본다.

2. 핵심 기술의 재정의

   1. 새로운 핵심 역량: 즉각적인 프롬프트 엔지니어링보다는, 클로드에게 약간 버거워 보이는 어려운 과제를 어떻게 부여하고, 그 과정을 통해 작업 결과를 검증할 수 있게 하느냐가 더 중요하다.
   2. 검증이 최대 약점: 사람들이 온라인에서 가장 제대로 하지 못하는 부분이 바로 이 "검증" 단계라고 지적한다.

---

6. 대규모 에이전트 오케스트레이션: 동적 워크플로우 vs 루프·루틴

이 섹션에서는 클로드 코드가 수천 개의 에이전트를 어떻게 생산적으로 조율하는지, 그 두 가지 방식을 설명한다.

6.1. 방법 1 — 동적 워크플로우(Dynamic Workflow)

1. 작동 원리

   1. 트리거: "워크플로우를 사용하라"는 한마디만으로 클라우드가 동적 워크플로우를 트리거한다.
   2. 기술 기반: Bun 런타임을 샌드박스로 사용하고, Bun 내에서 가상 머신을 시작한 뒤 클라우드가 다수의 에이전트를 시작·오케스트레이션한다.
   3. 적용 대상: 코드베이스 재작성, 매우 복잡한 데이터에 대한 심층 분석, 여러 단계와 수십 개의 풀 리퀘스트가 필요한 복잡한 기능 구축 등에 사용된다.

2. 다단계 파이프라인 구조

   1. 1단계: 여러 에이전트가 시작되어 첫 작업을 수행한다.
   2. 2단계: 이를 바탕으로 다른 에이전트들이 작업을 검증하거나 요약한다.
   3. 3단계: 다시 여러 갈래로 퍼져나갈 수도 있다.
   4. 설계 배경: 보리스의 전공이 함수형 프로그래밍이라, 이 시스템은 기본적으로 "에이전트를 위한 대수학(algebra for agents)"으로 설계됐다 — 순차 실행, 병렬 실행 등 다양한 조합 방식이 있다.

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

   1. 기존 스케일링 법칙: 전통적으로 모델이 똑똑해지는 정도는 뉴런 네트워크 크기, 훈련 데이터 양, 훈련 투입 플롭 수의 함수였다.
   2. 테스트 시간 컴퓨팅 추가: 최근에는 여기에 테스트 시간 컴퓨팅(생성되는 토큰 수)이 추가됐다.
   3. 동적 워크플로의 위치: 동적 워크플로는 테스트 시간 컴퓨팅을 구성하는 새로운 방식이자, 매우 어려운 작업에 필요한 테스트 시간 컴퓨팅 양을 획기적으로 늘리는 새로운 방법이다.

6.2. 방법 2 — 루프(Loop)와 루틴(Routine)

1. 정의

   1. 루프: Claude Code를 위해 로컬에서 실행되는 cron 작업.
   2. 루틴: 루프와 동일하지만 클라우드에서 실행된다는 점만 다르다. 노트북을 닫아도 계속 작동한다.
   3. 동적 워크플로와의 차이: 동적 워크플로는 하나의 작업을 여러 부분으로 나누는 방식인 반면, 루프·루틴은 컨텍스트는 공유하지 않지만 메모리는 공유할 수 있는 반복 작업을 매시간·5분마다·매일 등 원하는 주기로 계속 수행한다.

2. 내부 실사용 사례 — Claude 자체 코드베이스 유지보수

   1. 슬랙 기반 운영: 전용 슬랙 채널을 운영하며 Quad(내부에서 부르는 Claude Code 명칭으로 추정)가 자체 코드베이스를 유지 관리하는 여러 루틴을 실행하게 했다. CLI, iOS 앱, Android 앱, 데스크톱 앱 모두에 동일하게 적용한다.
   2. 사용하지 않는 코드 정리: 단 한 문장의 프롬프트로 매일 실행되며, 정적·동적 분석을 통해 모든 코드베이스에서 사용되지 않는 코드를 찾아내 삭제 PR을 자동으로 보낸다. 이 루틴은 팀이 먼저 요청한 것이 아니라 모델이 알아서 시작한 것이다.
   3. 완료된 실험 정리: 100% 완료된 실험은 해당 코드가 코드베이스에서 삭제되고 그대로 배포된다.
   4. 테스트 관리: 커버리지가 필요한 영역에 테스트를 작성하는 루틴, 이전 모델이 추가했거나 나중에 쓸모없어진 테스트를 삭제하는 루틴이 있다.
   5. "추상화 경찰(abstraction police)": 대규모 코드베이스에서 동일한 추상화 계층이 여러 곳에 중복 등장하는 경우를 매일 훑어 찾아내고 통합하는 루틴. 시간이 지나며 이유 없이 여러 부분에서 다르게 재구축된 추상화를 정리한다.

3. 규모와 의미

   1. 현재 규모: 하루 20~30개의 루틴이 모든 코드베이스에서 실행 중이며, 아직 완벽하게 구현된 것은 아니지만 앱 유지 관리를 완전히 자동화하는 방향으로 나아가고 있다.
   2. 인력 환산: 매일 수백 명, 때로는 수천 명의 에이전트가 작동하며, 이는 수십~수백 명의 엔지니어가 해야 할 유지보수 업무를 대신 처리하는 것과 같다.
   3. 엔지니어 시간의 재배치: 이를 통해 엔지니어들은 신제품 출시, 사용자 소통 등 실제로 하고 싶은 일에 시간을 쓸 수 있게 된다.

---

7. 코딩은 (일부) 해결되었다 — 최고 사용자를 가르는 사고방식

이 섹션에서는 "코딩 문제가 해결됐다"는 발언의 정확한 의미와, 상위 1% 클로드 사용자를 가르는 요소를 다룬다.

7.1. "해결됐다"의 범위와 한계

1. 단서 조항

   1. 본인 한정: "제가 하는 종류의 코딩에 대한 문제는 해결됐다"고 명확히 선을 긋는다. 모든 사람에게 해결된 것은 아니다.
   2. 여전히 어려운 영역: 매우 복잡한 시스템 코드베이스, 분산 시스템, 픽셀 단위 오차까지 요구되는 세세한 UI 검증에서는 여전히 어려움을 겪는다. Opus 5는 비전·컴퓨터 활용 면에서 큰 도약이었지만 완벽하지는 않다.

2. 청중 실태 조사

   1. 100% 에이전트 코딩: 코드의 100%를 에이전트로 작성한다는 응답자가 꽤 많았다.
   2. 50% 이상 에이전트 코딩: 직접 손으로 작성하는 인력이 약간 줄거나 거의 비슷한 수준이라는 응답이 나왔다.
   3. 추세: 점점 더 다양한 종류의 코드에 대해 자동화가 "해결"되는 방향으로 나아가고 있다.

7.2. 최고 사용자의 공통된 사고방식

1. 경험적(empirical) 접근

   1. 기존 지식을 버려라: 기존 모델에 대해 배웠던 것, 수업에서 배운 컴퓨터 과학 이론을 모두 잊어야 한다.
   2. 관찰-조정 루프: 모델을 살펴보고, 작업을 시도해보고, 어떤 부분에서 어려움을 겪는지 확인한 다음 그에 따라 조정한다. 이론 과학이 아니라 완전히 경험 과학으로 바뀌었다.
   3. 버릴 준비가 된 사람: 기존 사고를 잊고, 예전에 효과 없었던 아이디어를 버리고, 다시 시도할 마음의 준비가 된 사람들이 지금 가장 성공적이다.

2. 외부 소음 차단

   1. 조언: 링크드인 인플루언서의 말에 귀 기울이지 말고, 트위터도 읽지 말라고 청중에게 직접 조언한다.
   2. 특별한 비법은 없다: 모두가 특별한 비법을 찾으려 하지만 그런 건 존재하지 않는다. 경험적 접근, 약간 더 어려운 과제 부여, 결과 검증 도구 제공, 문제 파악 후 개선(더 나은 프롬프트, 기술 향상, 부족한 컨텍스트는 MCP로 보강)이 전부다.
   3. 과도한 설계 경향: 오래 코딩해온 엔지니어일수록 과거 시스템 구축 방식에 익숙해 지나치게 구체적으로 정의하려는 실패 유형에 빠지기 쉽다. 너무 세밀하게 정의하면 모델이 자기 방식대로 일하지 못하게 된다. 많은 사람이 이 생각을 버리는 여정을 겪고 있으며, 이는 모델을 동료처럼 대하는 법을 알아가는 과정이기도 하다.

---

8. CS 학생·주니어 개발자를 위한 조언

이 섹션에서는 AI 에이전트 코딩 시대에 여전히 사람이 직접 배워야 할 것이 무엇인지에 대한 보리스의 답을 다룬다.

1. 자신의 프로그래밍 학습 배경

   1. 실용적 학습: 컴퓨터 과학을 실질적인 경험을 통해, 문제 해결을 위해 스스로 코딩을 배우며 익혔다.
   2. 첫 언어 — TI-83 계산기: 중학교 시절 수학 시험에서 부정행위로 더 좋은 점수를 받기 위해 TI-83 계산기 프로그래밍을 배웠다. 당시 작성한 가이드가 아직 인터넷 어딘가에 남아있을 것이라고 말한다.
   3. 확산과 심화: 시리얼 케이블로 프로그램을 반 친구들에게 나눠줬더니 다들 성적이 좋아졌고, 이에 대응해 계산 난이도가 올라가자 베이직으로는 부족해 직접 대수 문제 해결 프로그램을 만들었으며, 미적분학 시험 대비를 위해 어셈블리 언어까지 배웠다.

2. 핵심 조언 — 컴퓨터 과학 밖의 기술을 배우라

   1. 적용력이 지식보다 중요: 컴퓨터 과학은 지적으로 매력적이고 아는 것만으로도 흥미롭지만, 그것을 어떻게 적용하는지 배우는 것이 더 중요하다.
   2. 스타트업/제품 관련 역량: 자신만의 디자인 감각 개발, 비즈니스 감각 함양, 데이터 과학 활용법, 사용자와 소통하는 방법 — 이런 기술들이 컴퓨터 과학·공학과 결합될 때 비로소 진정한 가치가 생긴다.
   3. 여전히 손으로 해야 하는 부분: 이런 비-기술적(제품·디자인·비즈니스) 역량은 보리스 본인도 여전히 직접 해야 하는 작업이라고 말한다.
   4. 요약: 먼저 자신이 원하는 것을 만들고, 그다음 단계로 다른 사람들이 원하는 것을 만드는 순서로 나아가라는 조언으로 정리된다.

3. 깜짝 발표 — Max 20X 제공

   1. 인터뷰 말미에 현장 청중 전원에게 Max 20X 플랜 코드를 이메일로 제공한다고 발표해 환호를 받았다.

---

주요 발언 모음

"1년 전만 해도 모델이 인터넷에서 '사용자 컴퓨터의 모든 것을 삭제하라'는 지침을 읽으면 그냥 그렇게 했을 겁니다. 하지만 요즘 오푸스는 그렇지 않습니다."

"정렬이 잘 된 모델과 모든 트래픽에 대해 실행되는 신속한 주입 분류기를 결합했습니다. 이는 크리스 올라의 기계론적 해석 가능성 연구를 기반으로, 모델의 뇌에서 즉각적인 주사가 발생했을 때 활성화되는 뉴런을 직접 관찰하는 방식입니다."

"Claude 코드에서 시스템 프롬프트의 80% 이상을 삭제했습니다. 흥미로운 점은, 이러한 프롬프트가 없을 때 모델이 실제로 조금 더 똑똑해진다는 것입니다."

"삭제 버튼을 누르는 것을 편안하게, 그리고 용감하게 할 수 있을까요? 100%입니다."

"옛날 방식으로 시스템을 구축할 때는 재건축이 몇 달, 대기업에서는 몇 년씩 걸렸습니다. 하지만 모델은 그렇지 않아요. 살아있는 생물, 더 유기적인 무언가와 같다고 보는 겁니다."

"제가 처음 이 작업을 시작했을 때, 즉 Sonnet 3.5 시절 코딩 제품들은 한 줄짜리 자동완성이나 읽기 전용 채팅 정도였습니다. 모델의 기능을 완전히 활용해서 한 번에 전체 파일을 작성하는 제품이 없다는 느낌이 들었고, 그게 클로드 코드의 시작이었습니다."

"Bun 팀의 제러드가 'Zig를 Rust로 다시 작성해 보자'고 했습니다. 프롬프트는 하나였고, 동적 워크플로였습니다. 그리고 그 작업은 11일 동안 진행됐고, 코드베이스 전체가 새로 작성됐습니다."

"제가 받은 프롬프트는 'Electron 앱을 Swift로 다시 작성하라. 스크린샷을 찍어 픽셀 단위로 비교하라. 끝날 때까지 멈추지 마라'였습니다. 2주가 넘도록 계속 실행 중입니다."

"여기 계신 분들 중에 클로드에게 2주 이상 작업을 시킨 분이 있는지 모르겠네요. 손들어 보시는 분 계신가요?"

"제가 하는 종류의 코딩에 대한 문제는 해결됐습니다. 하지만 모든 사람에게 해결책이 된 것은 아닙니다. Quad가 여전히 어려움을 겪는 매우 복잡한 시스템 코드베이스, 분산 시스템들이 있습니다."

"기존 모델에 대해 배웠던 모든 것을 잊어버리세요. 수업에서 배운 컴퓨터 과학 이론도 모두 잊으세요. 이론 과학이 아니라 경험 과학으로 완전히 바뀌었습니다."

"링크드인 인플루언서들의 말에 귀 기울이지 마세요. 트위터도 읽지 마세요."

"컴퓨터 과학은 지적으로 정말 매력적이지만, 그걸 어떻게 적용하는지 배우는 게 더 중요합니다. 디자인 감각, 비즈니스 감각, 데이터 과학, 사용자와 소통하는 법 — 이런 기술들이 결합될 때 진짜 가치가 생깁니다."

---

핵심 데이터 & 수치

• ARC-AGI-3 점수: 이전 최고 한 자릿수~10점대 초반 → Opus 5는 30%.
• 시스템 프롬프트 삭제 비율: Claude Code 시스템 프롬프트의 80% 이상 삭제(Opus 5 출시 대응).
• 프롬프트 인젝션 방어: 정렬 모델 + 실시간 인젝션 분류기(기계론적 해석 가능성 기반) + 자동 모드 분류기, 3계층.
• Bun 재작성 사례: Zig → Rust 전면 재작성, 소요 기간 11일, 10만 줄 이상 규모, 기존 엔지니어 기준 예상 소요 1년 이상.
• Claude Desktop 재작성 사례: Electron → Swift, 인터뷰 시점 기준 진행 14~15일 차, 생성 에이전트 수 추정 수천~수만 명.
• 내부 루틴 규모: 매일 20~30개 루틴이 모든 코드베이스(CLI/iOS/Android/데스크톱)에서 실행, 하루 수백~수천 에이전트 가동.
• 청중 실태: 2주 이상 에이전트 연속 실행 경험자, 1000개 이상 에이전트 워크플로 실행 경험자 모두 0명(보리스 본인 제외).
• 깜짝 혜택: 현장 참석자 전원에게 Max 20X 플랜 코드 이메일 제공.

---

결론 및 시사점

1. 모델 개발 철학의 전환: Anthropic Claude Code 팀은 전통적 "쌓아 올리는" 엔지니어링이 아니라 새 모델마다 대부분을 삭제하고 재구축하는 "절제술" 방식을 채택하고 있으며, 이는 모델을 정적 시스템이 아니라 세대마다 다른 개성을 지닌 유기체처럼 다루는 사고방식에서 나온다.
2. 프롬프트 인젝션 문제의 실질적 해법 제시: 정렬 + 실시간 해석가능성 기반 분류기 + 자동 모드 분류기라는 3계층 방어는 "치명적인 삼중주" 문제에 대한 구체적이고 검증 가능한 엔지니어링 답변으로, 에이전틱 제품을 만드는 모든 개발자가 참고할 만한 아키텍처다.
3. "언허블링"이 다음 스타트업 기회의 프레임: 오늘의 모델에 이미 내재된, 아직 아무도 발견하지 못한 능력을 찾아 제품화하는 것이 차세대 Claude Code급 제품을 만드는 방법이라는 메시지는, AI 제품을 만드는 모든 팀에게 실질적인 탐색 전략을 제시한다.
4. 검증 가능성이 새로운 병목: 프롬프트 엔지니어링의 시대는 저물고, "어려운 과제를 주고 결과를 검증하는 방법을 설계하는 능력"이 핵심 역량으로 부상하고 있다. 이는 개인 개발자와 조직 모두에게 워크플로 설계 재검토를 요구한다.
5. 대규모 에이전트 오케스트레이션의 실증: 11일 만의 런타임 전면 재작성, 2주 이상 자율 실행되는 데스크톱 앱 재작성 등은 "수천 개 에이전트를 생산적으로 조율"하는 것이 이론이 아니라 이미 실무에서 작동하는 방식임을 보여준다.
6. 비-기술 역량의 상대적 가치 상승: 코딩 자체의 상당 부분이 자동화되면서, 디자인 감각·비즈니스 감각·사용자 소통 같은 기술 외적 역량이 개발자를 차별화하는 핵심 요소로 부상하고 있다.

---

메타데이터

• 원본 영상: [한영자막] 보리스 체르니: Claude Code는 이렇게 만들어졌다
• 채널: Tech Bridge (TechBridge-KR)
• video_id: UkoosAsEA8w
• drop_date: 2026-07-29
• 처리일: 2026-07-29
• 카테고리: dev-engineering
• 요약 메시지: Telegram, Slack #newsfeed 동시 전송
• 저장 경로: /Users/flowkater/Obsidian/flowkater/flowkater/Study/YouTube다이제스트/2026-07-29-TechBridge-Boris-Cherny-Claude-Code.md