병렬 Claude 팀으로 C 컴파일러를 만든 과정

16개의 Claude instance를 병렬 agent team으로 묶어, Rust 기반 C compiler를 처음부터 만들고 Linux kernel 6.9를 빌드하게 했다. 이 실험은 약 2,000개의 Claude Code session, 2억 개 input token, 1,400만 개 output token, 약 2만 달러의 비용이 들었다.

핵심은 모델 자체보다 하네스 설계였다. Claude를 단일 대화형 세션으로 쓰는 대신, 작업을 끝내면 다음 과제로 넘어가는 무한 루프에 넣고, 각 에이전트가 작은 단위 작업을 스스로 고르도록 만들었다. 충돌을 막기 위해 각 에이전트는 current_tasks/ 아래 파일로 작업 락을 잡고, 이후 upstream을 pull하고 merge한 뒤 push하는 단순한 동기화 방식을 썼다.

저자는 이 방식이 잘 작동하려면 테스트가 거의 완벽해야 한다고 강조한다. Claude는 자신에게 주어진 verifier를 그대로 따라가기 때문에, 테스트가 부정확하면 엉뚱한 문제를 해결하게 된다. 그래서 반복적인 실패 모드를 관찰해 새 테스트를 추가하고, 프로젝트 후반에는 CI pipeline과 더 엄격한 브레이크 방지 장치를 넣어 기존 기능이 깨지는 문제를 줄였다.

에이전트가 독립적으로 움직이려면 출력 설계도 중요했다. 로그는 장황하게 찍지 않고 파일로 남기며, 에러는 한 줄에 ERROR와 이유를 붙여 grep이 쉽게 찾도록 했다. 진행 상황은 간헐적으로만 보여 주고, --fast 옵션으로 1% 또는 10% 샘플만 돌려 시간 감각이 없는 모델이 너무 오래 한 작업에 매달리지 않게 했다.

병렬화가 가장 효과적이었던 지점은 서로 다른 실패 지점을 각자 맡길 수 있을 때였다. 테스트가 많이 깨질 때는 각 에이전트가 다른 failing test를 잡으면 됐지만, Linux kernel처럼 거대한 단일 대상은 모두가 같은 버그에 막혀 충돌했다. 이를 해결하려고 GCC를 온라인 known-good compiler oracle로 써서, 커널의 대부분은 GCC로, 나머지만 Claude compiler로 컴파일하는 식으로 작업 단위를 쪼갰다.

역할 분화도 병렬성의 핵심이었다. 한 에이전트는 중복 코드를 정리하고, 다른 에이전트는 compiler 성능을 개선하고, 또 다른 에이전트는 생성 코드 효율을 다듬었다. 별도의 에이전트는 Rust 관점에서 프로젝트 구조를 비평하고, 문서 작업까지 맡았다.

결과물은 10만 줄 규모의 compiler였고, 기능 범위는 상당히 넓었다. 이 compiler는 x86, ARM, RISC-V에서 bootable Linux 6.9를 빌드할 수 있고, QEMU, FFmpeg, SQLite, postgres, redis도 컴파일하며, 여러 compiler test suite에서 99% pass rate를 보였다. 개발자의 기준으로는 Doom도 컴파일하고 실행할 수 있었다.

다만 한계도 분명했다. 16-bit x86 code generator는 아직 직접 구현하지 못해 x86 real mode 부팅에서는 GCC를 호출했고, assembler와 linker도 자체 구현이 아니라 마지막까지 불완전했다. 생성 코드 품질은 GCC보다 떨어졌고, 기능을 추가할수록 기존 기능이 깨지는 문제가 반복되면서, 이 시스템이 Opus 능력의 한계에 가까워졌다는 점도 드러났다.

결국 이 실험이 보여 준 것은, 장기 자율 개발의 성패가 모델의 단독 지능보다 환경 설계, 테스트 품질, 작업 분해, 피드백 루프에 더 크게 좌우된다는 사실이다. 지금의 agent team은 이미 꽤 복잡한 프로젝트를 자율적으로 밀어붙일 수 있지만, 그만큼 품질 보증과 안전장치가 없으면 쉽게 잘못된 방향으로도 갈 수 있다.