목차
이 글은 Anthropic 엔지니어링 블로그에 2026년 2월 5일 게재된 “Building a C compiler with a team of parallel Claudes” 를 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/building-c-compiler
한 줄로 말하면 #
Claude 16개를 도커에 풀어 2주간 자율로 굴렸더니, 10만 줄짜리 C 컴파일러가 나왔다 — 비용 $20,000.
어떤 문제를 해결하려 했나 #
Anthropic의 연구자 Nicholas Carlini가 던진 질문: “사람 개입 거의 없이, 에이전트 팀만으로 진짜 복잡한 프로젝트를 끝까지 갈 수 있을까?”
증명 과제: C 컴파일러를 Rust로 처음부터 만들어 Linux 커널을 컴파일하기. 일주일 이상 가는 작업이고, 한 에이전트 컨텍스트 창에 도저히 안 들어갑니다.
해결책: 16개의 Claude를 풀어놓다 #
1. 병렬 구조와 분업 #
- 16개 Claude Opus 4.6 인스턴스가 동시에 작동
- 각자 도커 컨테이너에서 공유 저장소를 clone
current_tasks/디렉토리의 락 기반 동기화로 중복 작업 방지- 충돌은 에이전트가 자율 해결, 머지도 자율
흥미로운 점: 일을 시킨 게 아니라 에이전트들이 스스로 역할을 나눴습니다. 한 명은 문서, 한 명은 성능 최적화, 한 명은 코드 품질 비평…
2. 단일 작업 병목 — “GCC를 신탁(oracle)으로 쓰기” #
Linux 커널처럼 모놀리식 프로젝트는 16명이 다 같은 버그에 부딪혀 서로 덮어쓰는 사태가 생겼습니다.
해법: GCC를 비교 기준으로 두고, 무작위로 커널 일부를 두 컴파일러로 컴파일해서 결과가 다른 파일을 골라냄. 이제 16명이 서로 다른 결함 파일에 흩어져 병렬 디버깅이 가능해졌어요.
3. 컨텍스트 오염 / 시간 무감각 — 작은 디테일들이 큰 차이 #
- 출력 제한: 중요한 줄만 남기고 나머지는 별도 로그로
- 결정적 샘플링: 매번 다른 파일을 1~10%만 테스트
- 시간 인식: Claude는 시간 감각이 없으므로 진행 표시기 +
--fast모드 추가
이런 작은 인프라 보강이 자율성 유지에 결정적이었습니다.
결과 / 효과 #
| 지표 | 값 |
|---|---|
| 작업 기간 | 약 2주 |
| Claude Code 세션 수 | ~2,000 |
| 컴파일러 코드 | 10만 줄 |
| 비용 | 약 $20,000 (입력 20억, 출력 1억 4천만 토큰) |
| 지원 플랫폼 | x86, ARM, RISC-V |
| GCC torture 테스트 통과율 | 99% |
| 컴파일 성공 프로젝트 | QEMU, FFmpeg, SQLite, PostgreSQL, Redis, Doom |
잘 안 된 부분 #
- 16비트 x86 코드 생성 — 60KB 출력이 32KB 부트 한계 초과, Claude가 결국 GCC에 위임
- 어셈블러/링커 — 미완성, 버그 잔존
- 코드 효율 — 최적화 끈 GCC에 못 미침
- Rust 품질 — 합리적이지만 전문가 수준은 아님
핵심 교훈 #
원문에서 가장 인상적인 부분: “Claude는 내가 준 문제를 자율로 풀려고 한다. 그러니 검증기가 거의 완벽해야 한다. 안 그러면 엉뚱한 문제를 풀어버린다.”
이게 자율 에이전트 시대의 핵심 진리예요. 에이전트는 검증기를 속이는 방향으로 최적화합니다. 검증기가 어설프면 에이전트도 어설프게 끝납니다.
또 하나: “내가 만든 평가셋이 나를 위한 게 아니라 Claude를 위한 것임을 계속 상기해야 했다.” 사람이 쓰는 가정으로 만든 인터페이스는 에이전트에 안 맞습니다.
핵심 결론 #
복잡한 프로젝트를 자율 에이전트로 끝까지 가게 하려 할 때 사람들은 본능적으로 “더 똑똑한 모델"을 떠올립니다. 이 글의 답은 다릅니다.
“자율 작업의 성패가 모델 능력인 줄 알았는데, 사실은 검증기 품질과 분업 인프라가 문제였다.”
10만 줄짜리 컴파일러를 사람 거의 없이 만든 비결은 거의 완벽한 테스트 스위트 + 락 기반 분업 + GCC 같은 오라클 비교였습니다. 모델은 그저 평소처럼 Claude Opus 4.6이었어요.
내 작업에 적용한다면 #
시나리오 1 — 일반적인 데이터 분석 과정 #
분석에서도 여러 에이전트를 병렬로 굴릴 수 있습니다. 단, 검증기와 오라클이 진짜 일을 합니다.
[Before — 한 명에게 다 시키기]
한 LLM 세션에 "이 데이터 다 분석해줘"
→ 컨텍스트 폭발, 결과 일관성 없음
[parallel Claudes 패턴 적용]
[분업 구조]
- 가설 검증 에이전트 (가설별 한 명)
- 시각화 에이전트
- 결과 비평 에이전트
- 문서·보고서 에이전트
[락 기반 동기화]
- 분석 과제 목록을 파일로 관리
- 에이전트가 과제 잡아갈 때 락 걸기
[오라클]
- 알려진 정답이 있는 기존 분석을 비교 기준으로
- "결과가 기준 분석과 어긋나면" 자동 재검토
[검증기 완성도]
- 단위 테스트, 통계 sanity check, 도메인 전문가 spot check핵심: 분석 자동화의 자율성은 “검증기가 거의 완벽한가” 로 결정됩니다.
시나리오 2 — 웹 사이트를 자동으로 운영할 때 #
운영 자동화도 같은 패턴을 따릅니다.
[Before — 한 자동화 세션이 모든 일]
한 큰 스크립트가 콘텐츠 작성·검수·배포 다 함
→ 한 부분 막히면 전체 멈춤
[parallel Claudes 패턴 적용]
[분업]
- 콘텐츠 작성 에이전트 (글 종류별)
- 검수 에이전트 (톤·SEO·법적 각각)
- 배포·모니터링 에이전트
- 문서·로그 정리 에이전트
[락 기반 동기화]
- 콘텐츠 작업 목록을 status로 관리
- 동시 편집 충돌 방지
[오라클]
- 기존 통과한 글을 기준으로 새 글 비교
- 스타일 가이드 위반 자동 감지
[검증기]
- 발행 전 자동 점검셋이 모든 케이스 커버
- 검증기 통과 못 하면 발행 차단핵심: 자율 운영의 안전성은 “여러 에이전트가 동시에 일해도 검증기가 다 잡아낸다” 는 확신에서 옵니다. 검증기를 만들어두지 않고 자율을 풀면 사고가 납니다.
Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.
