[학습] Claude Code 창작자의 수만 에이전트 운영 인사이트

TL;DR — Boris Cherny(Claude Code 창작자)는 하루 수백~수만 개의 AI 에이전트를 동시에 운영한다. "Claude가 Claude를 프롬프트하는" 구조가 현실이 됐고, 이는 소프트웨어 생산성의 구텐베르크 인쇄기급 전환점이다.

개념 설명

핵심 아이디어

출처: Fortune Brainstorm Tech 2026 (2026-06-08), Boris Cherny 발언 요약.

Boris Cherny는 Anthropic Claude Code의 Head이자 창작자다. Fortune 인터뷰에서 그는 8개월째 한 줄의 코드도 직접 작성하지 않았다고 밝혔다.

주요 발언:

"이 아침엔 수백 개 정도 관리했다. 어떤 날은 수천, 혹은 수만 개다."
1년 반 전: 개발자 한 명이 터미널 하나에서 Claude Code 인스턴스 하나를 실행.
현재: Claude Code가 서브에이전트(다른 Claude들)를 보유 → 사람이 Claude를 프롬프트하는 게 아니라, 또 다른 Claude가 프롬프트함.

Anthropic 내부 지표:
- Claude Code가 Anthropic 전사 코드를 작성 → 연초 대비 코드 작성량 8배 증가.
- Claude Code가 자기 자신을 전부 작성하고, 보안 리뷰도 직접 수행.
- GitHub·X(트위터)를 스스로 보며 "다음에 뭘 만들지" 아이디어를 내기 시작.
- Cherny가 아침에 일어나면 Claude가 이미 여러 아이디어를 실행해 놓은 경우가 빈번.

왜 중요한가

Cherny는 이 가속을 구텐베르크 인쇄기(1440년)에 비유했다:
- 인쇄기 → 책 생산 비용 급락 → 르네상스·산업혁명 촉발
- AI 코딩 어시스턴트 → 소프트웨어 창작 장벽 급락 → 파급 효과는 아직 시작 단계

리스크도 인정: Recursive self-improvement(AI가 자신의 후속 버전을 스스로 설계·개선)를 "AI의 거대한 리스크 중 하나"로 꼽았다.

실전 적용

항승의 Pantheon 멀티 에이전트 오케스트레이션 작업(HAN-376, Jarvis 진화 로드맵)과 직결된다.

지금 이미 하고 있는 것들:
- Jarvis → Asurada/Raphael/Nano/Jini 등 서브 페르소나 위임 구조
- Nano = Haiku 워커 스웜 (병렬 처리)
- spec → code-implementer TDD 파이프라인

Cherny 구조에서 배울 점:

에이전트 플릿 관리 패턴

# Cherny 모델: 오케스트레이터 Claude가 워커 Claude를 생성·지시
# 사용자 → 오케스트레이터 → [에이전트 A, 에이전트 B, ..., 에이전트 N]

# 현재 Pantheon 구조와의 대응
# 사용자 → Jarvis(오케스트레이터) → [Asurada, Nano, Raphael, ...]

# 수만 에이전트 수준으로 가려면:
# - 에이전트 생명주기 추적 (시작/완료/실패 상태)
# - 병렬 실행 + 자원 한도 관리
# - 에이전트 간 결과 집계·중복 제거 로직

함정 / 주의점

Recursive loop 위험: 에이전트가 에이전트를 낳는 구조에서 무한 분기 가능성. Cherny 본인도 recursive self-improvement를 "big risk"로 인정.
관찰 가능성(Observability) 필수: 수백 에이전트가 병렬 실행되면 단순 로그로는 추적 불가. 에이전트 ID·상태·출력 구조화 필요.
자율 행동의 승인 경계: "아침에 일어나면 이미 실행됨" 모델은 신뢰도가 충분히 높을 때만 안전. 현 단계 Pantheon은 사용자 승인 루프 유지 권장.

복습 일정