16개의 Claude가 병렬로 C 컴파일러를 만들었다 — 에이전트 팀 시대의 소프트웨어 개발 인사이트

개요

Anthropic의 연구원 Nicholas Carlini가 16개의 Claude 에이전트를 병렬로 운영해 Rust 기반 C 컴파일러를 처음부터 자율적으로 구축한 프로젝트가 발표되었습니다. 약 2,000번의 Claude Code 세션, $20,000의 API 비용, 2주의 시간 동안 10만 줄 규모의 컴파일러가 완성되었고, Linux 6.9 커널을 x86, ARM, RISC-V에서 빌드하는 데 성공했습니다. 이 글에서는 해당 프로젝트의 핵심 내용을 요약하고, 소프트웨어 개발의 미래에 대한 인사이트를 정리합 니다.

 

---

프로젝트 배경: 왜 C 컴파일러인가

Nicholas Carlini는 AI 에이전트의 자율 소프트웨어 개발 능력의 한계를 시험하기 위해 의도적으로 어려운 과제를 선택했습니다. C 컴파일러는 다음과 같은 이유로 적합한 벤치마크였습니다.

• 복잡도가 높다: 파서, 의미 분석기, 중간 표현(IR), 코드 생성기, 최적화 패스 등 다양한 모듈이 유기적으로 연결됩니다
• 검증이 명확하다: 기존 테스트 스위트(GCC torture test)와 실제 오픈소스 프로젝트 컴파일로 성공 여부를 객관적으로 판단할 수 있습니다
• 병렬화가 가능하다: 각 모듈을 독립적으로 개발할 수 있어 에이전트 팀 방식에 적합합니다

Carlini는 모델이 세대를 거듭할 때마다 이 컴파일러 프로젝트를 반복 실행하며 능력의 변화를 측정했습니다. Opus 4에서는 겨우 기능적인 수준이었고, Opus 4.5에서 테스트 통과율이 크게 올랐으며, Opus 4.6에서 본격적으로 Linux 커널 컴파일에 도전할 수 있었습니다.

---

에이전트 팀의 작동 원리

장기 실행 하네스

기존 Claude Code는 사용자가 온라인 상태여야 하고, 복잡한 작업 중간에 입력을 기다리며 멈추는 한계가 있었습니다. Carlini는 이를 해결하기 위해 무한 루프 구조의 하네스를 설계했습니다.

작업 완료 → 진행 상황 평가 → 다음 작업 선택 → 실행 → 반복

에이전트에게는 다음과 같은 지시가 주어졌습니다.

• 문제를 작은 단위로 분해할 것
• 진행 상황을 지속적으로 추적할 것
• 완벽해질 때까지 계속 반복할 것

Docker 기반 병렬 실행

각 에이전트는 독립된 Docker 컨테이너에서 실행되었습니다.

• /upstream: 공유 Git 저장소 (모든 에이전트가 참조)
• /workspace: 각 에이전트의 로컬 작업 공간

파일 기반 작업 잠금

에이전트 간 충돌을 방지하기 위해 단순하면서도 효과적인 동기화 메커니즘이 사용되었습니다.

• 에이전트가 current_tasks/ 디렉터리에 텍스트 파일을 작성하여 작업을 "잠금"
• 작업 완료 후 upstream에서 pull → merge → push → 잠금 해제
• 두 에이전트가 같은 작업을 잡으려 하면 Git의 동기화가 자연스럽게 충돌을 해결

---

핵심 엔지니어링 교훈 4가지

1. 테스트의 품질이 모든 것을 결정한다

자율 에이전트에게 테스트는 곧 유일한 검증자입니다. 테스트가 불완전하면 에이전트는 잘못된 방향으로 최적화합니다.

• 컴파일러 테스트 스위트를 먼저 구축하고, 오픈소스 패키지(SQLite, Redis, libjpeg) 컴파일을 추가 검증으로 활용
• 새 기능 구현 시 기존 기능이 깨지는 "회귀 문제"를 해결하기 위해 CI 파이프라인 도입
• GCC torture test의 99%를 통과하는 수준까지 도달

2. Claude의 관점에서 환경을 설계해야 한다

에이전트는 인간과 다른 방식으로 정보를 처리합니다. 환경을 에이전트 친화적으로 설계하는 것이 성능의 핵심이었습니다.

• 컨텍스트 창 오염 방지: 테스트 하네스가 불필요한 출력을 제거하고, 중요 정보만 로그 파일에 저장
• 에러 메시지 표준화: ERROR [구체적 이유] 형식으로 통일해 grep 검색이 용이하도록 설계
• 시간 인식 부족 보완: --fast 옵션으로 1~10% 무작위 샘플링을 기본으로 적용해 피드백 루프 속도를 향상

3. 병렬화는 작업 분할이 핵심이다

초기에는 각 에이전트가 실패한 테스트를 하나씩 맡아 처리하는 방식이 잘 작동했습니다. 하지만 Linux 커널 컴파일이라는 단일 거대 목표 앞에서는 모든 에이전트가 같은 버그를 동시에 고치려는 문제가 발생했습니다.

해결책은 GCC를 참조 컴파일러로 활용한 delta debugging이었습니다.

• Linux 커널 소스 파일을 무작위로 분배
• 대부분은 GCC로 컴파일하고, 일부만 Claude 컴파일러로 컴파일
• 차이가 발생하는 파일을 특정하여 각 에이전트에게 서로 다른 버그를 배정

4. 역할 특화가 효율을 높인다

16개 에이전트 모두가 같은 일을 하지 않았습니다. 다양한 역할로 분업화하여 전체 품질을 끌어올렸습니다.

• 핵심 개발 에이전트: 새로운 기능 구현과 버그 수정
• 코드 통합 에이전트: 중복 코드 발견 및 리팩터링
• 성능 최적화 에이전트: 컴파일러 자체의 실행 속도 개선
• 코드 품질 에이전트: Rust 관점에서의 설계 비평
• 문서화 에이전트: 코드베이스 문서 작성 및 유지

---

프로젝트 성과와 한계

달성한 것

• Linux 6.9를 x86, ARM, RISC-V 아키텍처에서 부팅 가능하게 빌드
• QEMU, FFmpeg, SQLite, PostgreSQL, Redis 컴파일 성공
• GCC torture test 99% 통과
• Doom 게임 컴파일 및 실행 성공

여전한 한계

• 16비트 x86 코드 생성 불가: 부팅 과정에서 여전히 GCC에 의존
• 코드 효율성 부족: 생성된 바이너리가 GCC의 최적화 비활성화 상태(-O0)보다도 비효율적
• 회귀 문제: 새 기능 추가 시 기존 기능이 깨지는 근본적 한계를 완전히 해결하지 못함
• Rust 코드 품질: LLVM 창시자 Chris Lattner의 평가에 따르면, "훌륭한 학부팀이 초기 단계에서 구축할 수 있는 정도"

---

비용과 규모

• 기간: 약 2주
• 세션 수: 약 2,000번의 Claude Code 세션
• 토큰 소비: 입력 2억 개 + 출력 1억 4천만 개
• 총 비용: 약 $20,000 (한화 약 2,800만 원)

이 비용은 전문 컴파일러 엔지니어를 고용하는 것에 비해 현저히 낮다는 평가가 있는 반면, 결과물의 품질 차이를 고려하면 단순 비교가 어렵다는 의견도 있습니다.

---

업계 반응과 논쟁

이 프로젝트는 업계에서 뜨거운 논쟁을 일으켰습니다.

긍정적 시각

• AI 에이전트의 자율적 대규모 소프트웨어 개발 가능성을 실증한 최초의 의미 있는 사례
• 개발자의 역할이 "코드 작성"에서 "에이전트 오케스트레이션"으로 전환되는 미래를 구체적으로 보여줌

비판적 시각

• 인간 개입의 실질적 필요성: 테스트 재설계, CI 파이프라인 구축, 에이전트 간 충돌 해결 등 상당한 인간 노력이 투입됨
• 학습 데이터 의존: 에이전트가 훈련 데이터에 포함된 기존 컴파일러 코드를 재생산한 것이 아닌가라는 의문
• 역사적 맥락 부재: Microsoft의 Steve Sinofsky는 GCC가 37년간 축적한 기술적 깊이와 단순 비교할 수 없다고 지적
• 지적재산권 경계: 공개 코드로 훈련된 AI가 유사한 구조를 재현할 때 학습과 모방의 경계가 어디인지에 대한 근본적 질문

---

핵심 인사이트 정리

인사이트 1: 개발자의 역할이 바뀐다

코드를 직접 작성하는 것보다 에이전트가 효과적으로 작업할 수 있는 환경을 설계하는 능력이 중요해지고 있습니다. 테스트 리그 설계, 피드백 루프 구축, 작업 분할 전략 수립 — 이것이 앞으로의 핵심 역량입니다.

인사이트 2: 테스트는 "명세서"다

자율 에이전트 시대에서 테스트는 단순한 검증 도구가 아니라 에이전트에게 올바른 방향을 알려주는 명세서 역할을 합니다. 테스트가 부정확하면 에이전트는 틀린 방향으로 열심히 달립니다.

인사이트 3: Harness 엔지니어링이 결정적이다

프로젝트 성공의 가장 큰 변수는 모델의 능력이 아니라 하네스의 설계 품질이었습니다. 에러 메시지 형식, 출력 필터링, 피드백 속도 등 에이전트를 둘러싼 환경 전체가 성과를 좌우했습니다.

인사이트 4: 병렬 에이전트에는 "오케스트레이션 설계"가 필수다

여러 에이전트를 단순히 병렬로 실행하는 것만으로는 충분하지 않습니다. 작업 잠금 메커니즘, 역할 분화, 충돌 해결 전략 등 에이전트 간 조율 시스템이 반드시 필요합니다.

인사이트 5: 자율 개발의 품질 보장은 아직 미해결 과제다

테스트를 통과하는 것과 실제로 좋은 코드인 것은 다릅니다. 인간이 직접 검증하지 않는 자율 개발에서 코드 품질과 안전성을 어떻게 담보할 것인지는 여전히 열린 문제입니다.

인사이트 6: AI의 강점은 "알려진 기법의 빠른 조합"이다

Chris Lattner가 지적했듯이 AI 에이전트는 기존에 알려진 기법을 조합하고 측정 가능한 기준에 최적화하는 데 뛰어나지만, 근본적으로 새로운 아키텍처를 설계하거나 프로덕션 수준의 일반화를 달성하는 데는 한계가 있습니다.

---

미래 전망: 에이전트 팀은 어디로 향하는가

Carlini는 소프트웨어 개발의 패러다임 변화를 다음과 같이 정리했습니다.

• 과거: IDE의 탭 완성으로 코드 작성 보조
• 최근: AI가 함수 본체를 자동 작성
• 현재: Claude Code와 페어 프로그래밍
• 미래: 에이전트 팀이 자율적으로 프로젝트를 구현

2026년 현재 이미 VS Code의 멀티 에이전트 지원, OpenAI의 Codex 에이전트 플랫폼 등 다양한 도구가 이 방향으로 진화하고 있습니다. 핵심 질문은 더 이상 "AI가 코드를 쓸 수 있는가"가 아니라, "인간은 AI가 작성한 코드를 어떻게 검증하고 신뢰할 수 있는가"로 옮겨가고 있습니다.

---

마무리

이 프로젝트는 단순한 기술 데모가 아닙니다. 에이전트 오케스트레이션, 하네스 설계, 테스트 주도 자율 개발이라는 새로운 소프트웨어 엔지니어링 패러다임의 실증 사례입니다.

개발자라면 주목해야 할 것은 "AI가 컴파일러를 만들었다"는 결과가 아니라, 그 과정에서 드러난 환경 설계의 중요성, 테스트의 새로운 역할, 병렬 에이전트 조율 전략입니다. 이것이 앞으로 우리가 AI와 함께 소프트웨어를 만드는 방식을 근본적으로 바꿀 패턴들이기 때문입니다.

---

참고 자료

• Building a C compiler with a team of parallel Claudes - Anthropic Engineering Blog
• Sixteen Claude Agents Built a C Compiler without Human Intervention... Almost - InfoQ
• The Claude C Compiler: What It Reveals About the Future of Software - Simon Willison
• Claude Opus 4.6 spends $20K trying to write a C compiler - The Register
• The State of AI Coding Agents (2026) - Dave Patten

이 글은 Claude Code를 활용하여 작성되었습니다.