Claude Code 만든 보리스 체르니가 "시스템 프롬프트 80%를 지웠다"고 밝힌 이유

개요

  • 주제: Y Combinator Startup School 2026 대담 — Boris Cherny(Claude Code 개발자, Anthropic)와 Diana Hu의 대화에서 드러난 AI 코딩 에이전트 시대의 개발 패러다임 전환
  • 핵심 관점: 모델 성능이 비약적으로 좋아진 지금, 개발자를 막던 병목은 모델이 아니라 우리가 씌워둔 과도한 프롬프트와 스캐폴딩이다
  • 핵심 키워드: Opus 5 · 제품 오버행(Product Overhang) · 속박(Hobbling) 해제 · 동적 워크플로우 · 테스트 타임 컴퓨트 · 엘리시테이션(Elicitation)

핵심 메시지 3가지

① 시스템 프롬프트의 80%는 '교정용'이었고, 교정할 대상이 사라졌다

과거 모델들은 마땅히 해야 할 행동을 일일이 지시로 교정해야 했기 때문에 복잡한 시스템 프롬프트가 필요했다. Opus 5는 그 지시 없이도 스스로 올바른 행동을 수행하므로, Boris는 출시와 함께 프롬프트의 80%를 삭제했다.

② '더 자세히 시키라'가 아니라 '더 어렵게 시켜라'

단계별 지시(step-by-step)를 줄여도 모델은 이미 충분히 잘한다. 남은 잠재력을 끌어내는 열쇠는 고차원 목표 + 가드레일 + 종료 기준을 제시하고 자율적으로 놓아주는 것이다.

③ 에이전트 스케일링의 새 법칙 — 추론 단계에서 수천 개 에이전트를 돌려라

학습 데이터·모델 크기 중심의 과거 스케일링 법칙을 넘어, 동적 워크플로우와 루틴을 통해 테스트 타임 컴퓨트를 수천 개 에이전트 단위로 확장하는 것이 현재의 전선이다.

1. Opus 5의 기술적 도약 — 자율 실행과 3중 보안 방어

Opus 5의 가장 큰 변화는 두 축입니다.

축 과거 모델 Opus 5
자율성 복잡한 스캐폴딩·슬래시 명령어로 태스크 완결성을 보장해야 함 별도 지시 없이도 스스로 완결성을 인지, 수일~수개월 중단 없이 장기 실행
보안 모델 정렬(Alignment)에 의존, 프롬프트 인젝션에 취약 메커니즘 해석 기반 3중 방어 체계로 인젝션 시도 자체를 차단

보안 쪽이 특히 주목할 만합니다. 단순 정렬을 넘어 Crystal의 메커니즘 해석(Mechanistic Interpretability) 연구를 기반으로 프롬프트 인젝션 분류기와 Auto Mode 분류기를 결합한 방어 구조를 세웠습니다. 모델 내부의 특정 뉴런이 인젝션 시도 시 활성화되는 현상을 감지해 차단하는 방식이라, 에이전트가 인터넷에서 악성 지시를 "읽더라도" 사용자의 컴퓨터를 삭제하는 등의 행위로 이어지지 않습니다. 이 보안 경계 덕분에 Auto Mode로 장시간 무인 실행을 맡길 수 있는 토대가 마련된 셈입니다.

발표자 신원 확인 자막 — Boris Cherny, Head of Claude Code, Anthropic

2. 프롬프트 80% 삭제와 'Simple Mode' — 아블레이션의 철학

Boris가 밝힌 삭제의 논리는 단순합니다.

"과거 모델들은 마땅히 알아야 할 행동을 교정하기 위해 복잡한 프롬프트가 필요했다. Opus 5는 그 지시 없이도 스스로 올바르게 행동한다."

그는 CLAUDE_CODE_SIMPLE=1 환경 변수로 모든 시스템 프롬프트와 도구 프롬프트를 제거한 'Simple Mode'로 직접 실행해 볼 것을 권장했습니다. 놀랍게도 이 상태에서 모델이 오히려 더 지능적으로 작동하는 경우가 많았다고 합니다. 다만 실제 제품에서는 UX와 제품 동작을 위해 일부 프롬프트는 유지해야 한다는 단서도 달았습니다.

이것이 적용된 개발 워크플로우는 다음과 같습니다.

① 새 모델 출시
↓
② 기존 코드·프롬프트 대거 삭제(아블레이션)
↓
③ 모델이 실제로 실패하는 지점만 관찰
↓
④ 실패 지점에 최소한의 지시문만 다시 추가

여기서 핵심 개념 두 개가 등장합니다.

  • 제품 오버행(Product Overhang): 모델은 이미 현재 시점에도 다양한 능력을 갖추고 있으나, 제품이 그 잠재력 일부를 아직 담아내지 못하고 있는 상태
  • 속박(Hobbling) / 언호블링(Unhobbling): 과도한 프롬프트·스캐폴딩가 모델의 능력을 가리고 있으므로, 불필요한 제약을 제거해 잠재력을 끌어내는 과정

평가(Evals) 세트 역시 상향 평준화된 모델 성능 앞에서는 빠르게 포화되어, 폐기·재구축되는 주기가 짧아지고 있습니다. "견고한 시스템 설계"보다 "실험적 삭제"가 앞서는 패러다임 전환입니다.

무대 위 1:1 대담 현장 — 진행자와 Boris Cherny가 원형 테이블을 사이에 두고 대화하는 구도

3. 대규모 에이전트 오케스트레이션 — 동적 워크플로우와 루틴

Claude Code는 코딩 도구를 넘어 에이전트 오케스트레이션 플랫폼으로 진화하고 있습니다. Boris가 제시한 두 가지 접근법은 다음과 같습니다.

① 동적 워크플로우(Dynamic Workflows)

Bun 런타임을 샌드박스로 사용해 가상 머신 내에서 다수의 에이전트를 생성·제어합니다. 사용자가 "use a workflow"라고 말하면 Claude가 트리거합니다.

1차 에이전트 실행 → 2차 검증·요약 → 3차 재확산

이 단계적 오케스트레이션은 함수형 프로그래밍의 대수적 구조를 차용해 에이전트를 순차·병렬로 실행하며 토큰 효율을 극대화합니다. Boris는 이를 테스트 타임 컴퓨트(Test-time compute)의 새로운 확장으로 정의합니다 — 학습 데이터·모델 크기가 아니라 추론 단계에서 수천 개 에이전트를 가동해 난제를 푸는 방식입니다.

② 루프(Loops)와 루틴(Routines)

구분 실행 위치 특징 적합한 작업
루프 로컬 크론 작업 방식 개발자 머신에서 도는 반복 작업
루틴 클라우드 노트북을 닫아도 지속 컨텍스트를 공유하지 않는 반복 유지보수

실제 사례로 Anthropic은 Slack 채널을 통해 Claude가 자체 코드베이스(CLI·iOS·Android·Desktop 앱)를 유지보수하는 루틴을 돌려놓고 있습니다.

  • 죽은 코드 정리
  • 실험 기능의 정식 출시 및 잔여 코드 삭제
  • 테스트 커버리지 보완 / 불필요한 테스트 삭제
  • 중복 추상화를 통합하는 '추상화 경찰(Abstraction Police)'

이 루틴들은 매일 수십~수백 개의 에이전트로 실행되며, 엔지니어는 반복 유지보수에서 해방되어 제품 개발과 사용자 소통에 집중하게 됩니다.

4. 실증 사례로 본 '숨겨진 능력'의 크기

사례 과제 소요 시간 결과
Bun 런타임 Zig → Rust 전체 코드베이스 재작성 약 11일 수백만 줄 마이그레이션 완료, 현재 프로덕션 운영 중
이미지 생성 실험 Opus 5 + OpenCV로 초상화·풍경 그리기 — 학습되지 않은 영역에서도 놀라운 성능 → '엘리시테이션'의 증거
Claude Desktop App Electron → Swift 네이티브 재작성 2주 이상 계속 실행 중 "스크린샷을 찍어 Swift 버전과 픽셀 단위로 비교하며 완료까지 멈추지 마라"는 단일 프롬프트로 자율 진행, 스스로 Slack 채널을 만들어 라이브 블로그 형식 공유

Bun 사례가 특히 상징적입니다. 메모리 누수를 탐지하던 중 "이 모델이 전체 코드를 재작성할 수 있겠다"고 판단했고, 테스트 스위트와 동적 워크플로우를 결합해 과거 수년이 걸렸을 작업을 11일 만에 끝냈습니다.

한 가지 오해도 짚어둘 필요가 있습니다. "코딩은 해결되었는가"라는 질문에 Boris의 답은 조건부였습니다. 시스템 코드, 분산 시스템, 픽셀 단위 UI 검증 같은 영역에서는 여전히 한계가 있으나, 전반적 자동화 수준은 명백히 높아졌다는 것입니다.

5. exceptional builder가 되는 법 — 경험적 태도

Boris가 강조한 차세대 개발자 역량의 핵심은 이렇습니다.

  1. 경험적(empirical)으로: 과거 모델의 한계나 CS 이론에 얽매이지 말고, 현재 모델의 성능을 직접 테스트하며 피드백 루프로 적응할 것
  2. 과제를 설계할 것: 프롬프트 엔지니어링 대신 검증 가능한 어려운 과제를 만드는 능력 — 고차원 목표·가드레일·종료 기준을 정의하고 자율에 맡기기
  3. 동료처럼 대우할 것: 모델이 자기 작업을 스스로 검증할 도구(MCP 등)와 컨텍스트를 제공하기
  4. 비기술 역량까지: 학생에게는 CS 이론뿐 아니라 실용적 프로그래밍 경험(TI-83 계산기용 어셈블리 코딩 같은)과 제품 개발·비즈니스 감각·사용자 소통을 함께 함양할 것을 조언

참고로 이 대담은 Opus 5 출시 이튿날 진행됐으며, 도입부에서 진행자가 ARC-AGI 점수가 3%에서 30%로 뛴 것을 언급하는 장면이 나옵니다. 대담 말미에는 참석자 전원에게 Claude Max 20x 구독 코드가 제공됨이 공지되었습니다.

관점 포인트 — 실무자가 오늘 짚을 것

  • 프롬프트 감사(audit)부터 하라: 우리 시스템 프롬프트 중 몇 %가 '옛날 모델의 버그 교정용'인가? 새 모델에서 하나씩 지워보고 실패 지점을 관찰하는 것부터가 시작이다.
  • 지시의 방향을 바꿔라: "이렇게 해"가 아니라 "이 목표에 도달해, 이 선은 넘지 마, 끝났는지 이렇게 확인해."
  • 병렬화 가능한 유지보수를 찾아라: 죽은 코드 정리, 테스트 커버리지, 추상화 통합처럼 컨텍스트 공유가 필요 없는 작업은 루틴으로 빼는 순간 엔지니어 시간이 해방된다.
  • 평가는 소모품이다: eval 세트의 수명이 짧아지고 있다. 큰 평가 체계 하나를 영구 설계하기보다 빠르게 갈아치울 실험 루트를 확보하라.
  • 검증 도구를 먼저 줘라: 모델에게 자율성을 주기 전, 스스로 결과를 확인할 수단(스크린샷 비교, 테스트 스위트, MCP 도구)이 준비되어 있어야 한다.

최종 핵심 정리 — 이 글에서 가져갈 질문들

  1. 우리 제품의 '속박'은 어디에 남아 있는가 — 모델이 이미 할 수 있는데 우리가 아직 지시로 막고 있는 영역은?
  2. 단계별 지시를 얼마나 줄이고, 종료 기준을 얼마나 명확히 했는가?
  3. 반복 유지보수를 루틴으로 옮기면 하루에 몇 개의 에이전트를 돌릴 수 있는가?
  4. 모델이 자기 작업의 완결성을 스스로 검증할 도구를 제공하고 있는가?

한 줄 요약: 모델이 좋아졌을 때 할 일은 지시를 더 추가하는 것이 아니라, 지시를 지워보고 남는 실패만 최소한으로 메우는 것 — 잠재력은 이미 모델 안에 있고, 병목은 우리의 불신이다.