Opus 4.6 agent team으로 C 컴파일러를 만들어 봤다

TL;DR Highlight

16개의 Claude 인스턴스가 Rust로 C 컴파일러를 개발하고 리눅스 커널 컴파일에 성공하여, 자율 에이전트 팀 운영의 가능성과 한계를 동시에 입증했다.

Who Should Read

LLM 에이전트를 활용한 자율 코딩 워크플로우에 관심 있는 개발자, 또는 멀티 에이전트 시스템 설계를 고민하는 엔지니어.

Core Mechanics

16개의 Claude Code 인스턴스를 Docker 컨테이너에 띄워 병렬로 작업시켰다. 각 에이전트는 bare git repo를 공유하고, current_tasks/ 디렉토리에 텍스트 파일을 써서 '락'을 거는 방식으로 작업 충돌을 방지했다. 오케스트레이션 에이전트 없이 각자 '다음으로 가장 명백한 문제'를 알아서 골라 작업했다.
약 2,000번의 Claude Code 세션과 $20,000의 API 비용으로 10만 줄 규모의 Rust 기반 C 컴파일러를 만들었다. 인터넷 접속 없이 Rust 표준 라이브러리만으로 구현했고, x86/ARM/RISC-V 세 아키텍처에서 리눅스 6.9을 부팅 가능하게 빌드한다.
리눅스 커널 외에도 QEMU, FFmpeg, SQLite, PostgreSQL, Redis를 컴파일할 수 있고, GCC torture test suite 포함 대부분의 컴파일러 테스트에서 99% 통과율을 보였다. Doom도 컴파일해서 실행 가능하다.
핵심은 테스트 하네스의 품질이었다. 에이전트가 자율적으로 일하려면 '무엇이 맞는지' 검증하는 테스트가 거의 완벽해야 한다. 테스트가 부실하면 에이전트가 엉뚱한 문제를 푼다. 기존 컴파일러 테스트 스위트를 가져오고, 오픈소스 빌드 검증기를 만들고, 에이전트 실수 패턴을 관찰해서 새 테스트를 계속 추가했다.
리눅스 커널 컴파일 단계에서 모든 에이전트가 같은 버그에 걸려 서로 수정을 덮어쓰는 문제가 생겼다. 해결책으로 GCC를 'oracle'로 활용했는데, 커널 파일 대부분을 GCC로 컴파일하고 일부만 자체 컴파일러로 바꿔가며 문제 파일을 좁혀나가는 방식이다.
한계도 분명하다. 생성 코드 효율이 낮아서, 모든 최적화를 켜도 GCC의 최적화 없는(-O0) 코드보다 느리다. 16비트 x86 코드 생성기는 구현에 실패해서 부팅 초기 단계는 GCC에 위임했고, 자체 어셈블러와 링커도 없다.
이전 모델들과의 차이도 언급했다. Opus 4 이전 모델은 기능하는 컴파일러 자체를 거의 못 만들었고, Opus 4.5가 처음으로 대규모 테스트를 통과하는 컴파일러를 만들 수 있었지만 실제 큰 프로젝트 컴파일은 불가능했다. Opus 4.6에서야 실용적 수준에 도달했다.
에이전트를 무한 루프로 돌리는 단순한 쉘 스크립트 하네스를 사용했다. Claude가 하나의 작업을 끝내면 바로 다음 작업을 시작하는 구조인데, 한 번은 Claude가 실수로 pkill -9 bash를 실행해서 자기 자신을 종료시킨 에피소드도 있었다.

Evidence

Google에서 10년간 Clang으로 리눅스 커널을 빌드하는 작업을 했던 개발자가 댓글을 달았다. 빌드는 되지만 생성 코드의 정확성(correctness)과 성능은 별개 문제라고 지적하면서도, 그래도 인상적인 프로젝트라고 평가했다.
'clean-room 구현'이라는 주장에 대한 반론이 있었다. Opus는 이미 학습 데이터에 Clang, GCC, TCC 등의 소스코드가 포함되어 있으므로, 법적 의미의 clean-room(원본 코드를 본 사람과 새 코드를 작성하는 사람이 분리됨)과는 다르다는 지적이다.
이 실험은 C 컴파일러처럼 스펙이 명확하고 테스트가 잘 정의된 문제에 최적화된 케이스라는 의견이 많았다. 실제 업무에서는 요구사항이 모호하고 엣지 케이스가 즉석에서 발견되는데, 그런 환경에서도 통할지는 미지수라는 것.
단일 에이전트로도 충분하지 않냐는 의견도 있었다. 병렬 에이전트는 불필요한 복잡성(accidental complexity)을 늘릴 뿐이고, 핵심은 에이전트 팀이 아니라 잘 작성된 테스트 스위트라는 주장. 어떤 프론티어 모델이든 좋은 테스트만 있으면 단일 에이전트로도 같은 결과를 낼 수 있다고.
SWE 직업 전망에 대한 경고 댓글도 화제였다. Opus가 '팀원으로 훈련된 것도 아닌데' 쉘 스크립트 하나로 적응시킨 것이고, 이 모드에 특화된 학습이 이루어지면 몇 년 안에 은퇴하지 않는 소프트웨어 엔지니어에게 위협이 될 것이라는 주장.

How to Apply

자율 에이전트 루프를 설계할 때, 에이전트 자체보다 테스트 하네스에 투자하라. 컴파일러처럼 자동 검증 가능한 테스트가 풍부한 도메인일수록 효과가 크다. 기존 테스트 스위트(예: 언어별 공식 테스트, 오픈소스 프로젝트 빌드)를 검증기로 활용하는 것이 핵심이다.
멀티 에이전트 작업 충돌을 방지하려면 git 기반 파일 락 패턴을 쓸 수 있다. current_tasks/ 디렉토리에 작업명.txt를 생성하고, git push 시점에 충돌이 나면 다른 작업을 선택하게 하는 방식이다. 복잡한 오케스트레이션 없이도 동작한다.
에이전트가 새 기능을 추가할 때마다 기존 기능이 깨지는 문제가 발생하면, CI 파이프라인을 붙여서 기존 테스트 통과를 강제하라. 이 실험에서도 프로젝트 후반부에 이 문제가 심각해져서 CI를 도입한 후 안정화됐다.
정답을 알고 있는 기존 시스템(oracle)을 비교 대상으로 활용하는 패턴이 유용하다. 예를 들어 레거시 시스템을 재작성할 때, 기존 시스템의 출력과 새 시스템의 출력을 자동 비교하는 테스트를 만들면 에이전트가 자율적으로 디버깅할 수 있다.

Code Example

snippet

#!/bin/bash
# 에이전트 무한 루프 하네스 (컨테이너 내에서 실행)
while true; do
  COMMIT=$(git rev-parse --short=6 HEAD)
  LOGFILE="agent_logs/agent_${COMMIT}.log"
  claude --dangerously-skip-permissions \
    -p "$(cat AGENT_PROMPT.md)" \
    --model claude-opus-X-Y &> "$LOGFILE"
done

Terminology

SSA IRStatic Single Assignment Intermediate Representation. 컴파일러 내부에서 코드를 최적화하기 쉬운 형태로 변환한 중간 표현. 각 변수가 딱 한 번만 값이 할당되어서 데이터 흐름 분석이 쉬워진다.

GCC torture testGCC에 포함된 극한 테스트 모음. 컴파일러가 처리하기 까다로운 코너 케이스들을 모아놓은 것으로, 이걸 통과하면 컴파일러가 상당히 견고하다는 의미.

oracle정답을 알고 있는 기준 시스템. 여기서는 GCC가 oracle 역할을 해서, 새 컴파일러의 출력이 맞는지 비교 검증하는 데 사용됐다.

agent harness에이전트를 반복 실행하고, 작업 할당·결과 검증·로그 수집 등을 자동화하는 외부 프레임워크. 에이전트 자체가 아니라 에이전트를 '부리는' 인프라.