병렬 Claude 팀을 활용한 C 컴파일러 구축

• 16개의 Claude 에이전트가 병렬로 협력해 Rust 기반 C 컴파일러를 완성, Linux 6.9 커널을 빌드할 수 있는 수준에 도달
• 약 2,000회 세션과 2만 달러 비용으로 10만 줄 규모의 코드를 생성, x86·ARM·RISC-V 아키텍처를 지원
• 에이전트들은 자동 루프 하네스를 통해 인간 개입 없이 지속적으로 작업하며, 테스트·병렬화·역할 분담 구조로 효율을 높임
• 결과물은 GCC 호환성과 높은 테스트 통과율을 보였으나, 16비트 x86 코드 생성·링커·최적화 품질 등은 미완성 상태
• 이 실험은 자율형 LLM 팀의 한계와 가능성을 검증한 사례로, 향후 완전 자율 개발 환경의 안전성과 품질 관리가 핵심 과제로 부상

---

에이전트 팀 기반 C 컴파일러 프로젝트 개요

• 여러 Claude 인스턴스가 병렬로 협력해 하나의 코드베이스를 개발하는 실험
  • 인간의 실시간 개입 없이 자율적으로 코드 작성·테스트·수정을 반복
• 목표는 Rust로 작성된 C 컴파일러를 완성해 Linux 커널을 직접 빌드하는 것
• 총 16개의 에이전트, 약 2,000회 세션, 2억 입력 토큰·1.4억 출력 토큰을 사용
• 결과물은 100,000줄 규모의 컴파일러, Linux 6.9 커널 및 주요 오픈소스 프로젝트(QEMU, FFmpeg, SQLite, Redis 등) 빌드 가능

장기 실행을 위한 Claude 하네스 설계

• 기존 Claude Code는 인간의 입력이 필요했으나, 무한 루프 구조의 자동 실행 하네스로 자율 진행 가능
  • 각 작업 완료 후 즉시 다음 작업을 수행하는 자동 반복 구조
  • 작업 중 Claude가 실수로 pkill -9 bash를 실행해 자신을 종료한 사례도 있음
• 병렬 실행 구조는 Docker 컨테이너와 Git 동기화를 활용
  • 각 에이전트는 /workspace에서 작업 후 /upstream으로 푸시
  • 텍스트 파일 기반 락(lock) 으로 작업 충돌 방지
  • 병합 충돌은 Claude가 직접 해결

병렬 Claude 운영 방식

• 병렬 실행의 장점은 동시 디버깅과 역할 분화
  • 일부 에이전트는 코드 작성, 일부는 문서화·품질 관리·성능 최적화 담당
• 통신이나 중앙 조정자는 존재하지 않으며, 각 에이전트가 자율적으로 다음 과제 선택
• Git 히스토리에는 각 에이전트의 작업 잠금 기록과 진행 문서가 남음

Claude 팀 프로그래밍에서 얻은 교훈

고품질 테스트의 중요성

• Claude는 주어진 테스트를 기준으로 자율 작업하므로, 검증기의 정확도가 핵심
  • 오탐이 있으면 잘못된 방향으로 개발 진행
• 지속적 통합(CI) 파이프라인을 구축해 기존 기능이 깨지지 않도록 강제 검증
• 오픈소스 빌드 스크립트와 컴파일러 테스트 스위트를 활용해 품질 확보

Claude의 관점에서 환경 설계

• 각 에이전트는 컨텍스트 없는 새 컨테이너에서 시작하므로, 진행상황 문서화 필수
  • README와 진행 파일을 지속적으로 갱신하도록 지시
• 맥락 오염 방지: 로그는 최소화하고, 오류는 ERROR 키워드로 식별 가능하게 기록
• 시간 인식 부재를 보완하기 위해 --fast 옵션으로 1~10% 샘플 테스트 수행

병렬화의 한계와 해결

• 독립 테스트가 많을 때는 병렬화가 쉬우나, Linux 커널 빌드는 단일 거대 작업으로 충돌 발생
• 해결책으로 GCC를 기준 컴파일러 오라클로 사용
  • 일부 파일은 GCC로, 나머지는 Claude 컴파일러로 빌드
  • 실패 시 문제 파일을 좁혀가며 병렬 디버깅 가능
  • 이후 델타 디버깅으로 상호 의존 오류 탐지

에이전트 역할 분화

• 중복 코드 제거, 성능 개선, 효율적 코드 생성, Rust 구조 개선, 문서화 등 전문화된 역할 분담
• 병렬성과 전문화를 결합해 대규모 코드베이스 관리 효율 향상

Opus 4.6 모델의 성능 평가

• Opus 4.5까지는 대형 프로젝트 빌드 불가, Opus 4.6에서 처음으로 실용 수준 도달
• 클린룸 구현으로 인터넷 접근 없이 Rust 표준 라이브러리만 사용
• GCC torture test suite 99% 통과, Doom 실행 가능
• 한계점:
  • 16비트 x86 코드 생성 불가, 부트 단계에서 GCC 호출 필요
  • 어셈블러·링커 미완성, 일부 버그 존재
  • 생성 코드 효율 낮음, GCC 최적화 해제 수준보다 비효율적
  • Rust 코드 품질은 준수하나 전문가 수준 미달

자율 에이전트 팀의 한계와 가능성

• 프로젝트는 LLM 자율 협업의 한계 측정을 위한 벤치마크
• 완전 자율 개발은 품질 보증·보안 위험을 동반
  • 테스트 통과만으로 완성으로 오인할 위험 존재
• 인간 검증 없는 코드 배포에 대한 우려 표명
• 그러나, 자율형 에이전트 팀이 복잡한 프로젝트를 완성할 수 있음을 입증
• 향후 모델 발전과 함께 안전한 자율 개발 전략이 필수 과제로 제시됨

향후 전망

• 언어 모델의 발전은 IDE 자동완성 → 함수 완성 → 페어 프로그래밍 → 자율 프로젝트 수행으로 진화
• Agent teams는 완전 자율 개발의 가능성을 보여줌
• 빠른 기술 발전 속도에 놀라움과 동시에 새로운 윤리·안전 프레임워크 필요성 강조
• 긍정적 활용이 부정적 위험을 상쇄할 것으로 기대되나, 새로운 개발 패러다임에 대한 대비 필요

[mammal]

C로 만든 컴파일러가 아닌 Rust 표준라이브러리로만 만든 프로젝트라 gcc/clang C 코드가 학습데이터에 있다는 비판은 좀 골대 옮기기 아닌가 싶네요. 어쨌든 대단합니다.

[GN⁺]

Hacker News 의견들

• 나는 Google에서 거의 10년 동안 Clang으로 Linux 커널 빌드 작업을 했음. 이번 프로젝트(clangbuiltlinux.github.io)는 LLM이 2,000회 세션과 2만 달러의 API 비용으로 같은 일을 해냈다고 함. 실제로 부팅까지 된다고 하니 놀라움. 다만 생성된 코드의 효율성은 낮고, GCC의 최적화 해제 버전보다도 비효율적이라고 함. 그래도 정말 멋진 프로젝트임

  • 멋지긴 하지만, 어쩌면 다른 사람의 숙제를 베낀 결과일 수도 있음
  • Opus가 16비트 x86 코드 생성기를 구현하지 못해 부팅 단계에서 GCC를 호출하는 편법을 썼다고 함. 진짜로 부팅된 건지 의문임
  • 이건 마치 Ken Thompson의 “Trusting Trust” 시대가 다시 오는 느낌임. AI가 곧 컴파일러 내부에 스스로를 심을 수도 있음
  • 2만 달러가 들었다면, 그 돈으로 시니어 개발자 8명을 단기간 고용할 수도 있었음. 마케팅 비용이 과도하게 들어간 것 같고, 실제 수익 구조는 불분명함

• Cursor 브라우저 프로젝트보다 훨씬 현실적인 접근임. 클린룸 구현이라며 인터넷 접근 없이 Rust 표준 라이브러리만 사용했다고 함. 10만 줄짜리 컴파일러가 Linux 6.9, QEMU, FFmpeg, SQLite, Postgres, Redis까지 빌드 가능하다고 함.
  Opus 4.5가 처음으로 대형 테스트를 통과할 수 있었고, 이번 결과는 그 한계를 거의 다 쓴 듯함.
  여러 제약에도 불구하고 인상적인 실험이라 생각함

  • “클린룸 구현”이라는 표현은 과장된 듯함. 이미 인터넷 전체의 C 컴파일러를 학습한 모델이니까 굳이 그런 말을 붙일 필요는 없음
  • 이런 결과를 현재 수준만 보고 평가하는 건 아쉬움. 최근 몇 달 사이의 발전 속도를 보면 1년 뒤엔 상상 이상일 것임
  • 사실상 클린룸이라기보다, LLM이 학습 중 압축된 지식을 테스트 기반으로 풀어낸 결과에 가까움
  • 어차피 GCC나 Clang 코드로 훈련된 모델일 텐데, 실제 코드 유사성이 얼마나 되는지 궁금함
  • 개인적으로는 대단하긴 하지만, 실제 사용자 입장에서는 덜 흥미로움. 새로운 ISA를 LLVM에 추가하거나, 새 언어용 컴파일러를 만드는 게 더 의미 있을 듯함

• 처음엔 “와, 대단하다”였지만 곧 생각이 바뀜. C 컴파일러는 명세가 매우 엄격한 소프트웨어라서 LLM이 다루기 쉬운 편임.
  하지만 우리가 하는 대부분의 일은 요구사항이 모호하고, 목표가 계속 바뀌는 환경임. 이런 영역에서도 잘 작동할지가 궁금함

  • “C 컴파일러는 명확하다”는 말에 웃음이 나옴. “unspecified behavior” 가 얼마나 많은데
  • 코드 생성이 테스트에 맞춰지는 건 ML 모델 피팅과 비슷함. 인간은 여전히 테스트를 설계하고 검증해야 함

• 결과가 완벽해야 한다는 기대가 이상하게 느껴짐. 가능한 것 자체가 놀라움. 이런 시도가 다음 Opus나 Sonnet 학습에 반영되어, 언젠가 효율적인 컴파일러를 스스로 만드는 모델이 나올지도 모름

  • 나도 같은 생각임. “개가 춤을 얼마나 잘 추느냐보다, 춤을 춘다는 사실이 놀라운 것”임
  • 요즘 생성형 AI에 대한 반감이 커서, 조금의 결함만 있어도 ‘AI 쓰레기’ 라고 몰아가는 분위기가 아쉬움. 이건 단순한 데모이자 개념 증명인데 말임

• 이 프로젝트는 Linux 커널, QEMU, FFmpeg, Redis, Doom까지 빌드할 수 있다고 함. 정말 놀라움.
  하지만 이런 에이전트 시스템은 테스트 가능한 영역에선 잘 작동하지만, 비즈니스 의사결정처럼 맥락이 필요한 영역에선 한계가 있음

  • 이미 인터넷 전체로 학습된 모델에게 “클린룸 구현”이란 개념이 의미가 있는지 의문임
  • 다음 단계는 AI가 실제 비즈니스 문맥을 이해하고 운영하는 것임. 예를 들어 Vending-Bench 같은 벤치마크를 보면, AI 제품 매니저가 사용자 인터뷰, 실험, 로드맵 제안까지 자동으로 수행할 날이 머지않음

• 멋진 프로젝트지만, “클린룸” 언급은 빼는 게 나았음. 저작권 있는 코드로 훈련된 모델이니까 그 반대에 가까움

  • 하지만 인간도 기존 코드베이스를 학습하고, 그 지식을 바탕으로 클린룸 구현을 하기도 함
  • 인간이 회사에서 배운 지식을 다른 곳에서 재활용하는 것처럼, LLM도 학습된 데이터를 변형적 방식으로 재구성하는 것임. 직접 복사만 아니라면 문제는 다름없음

• GitHub 이슈에 따르면, 문제는 include 경로 누락 때문임. 컴파일러 자체는 정상임

  • 단순히 glibc-devel 같은 패키지가 빠진 듯함
  • 글이 너무 길고 근거가 부족했음. 핵심을 놓친 느낌임
  • AI는 미래임
  • 정말 놀라운 결과임

• 나는 모든 프롬프트와 에이전트 구조를 공개했으면 함. 학습용으로 훌륭할 텐데, 2만 달러를 직접 써서 재현하기엔 부담스러움

  • 요즘은 결과물만 보고 과정은 궁금해하지 않는 분위기가 아쉬움

• 이건 Cursor 블로그의 작동 버전 같음. 실제로 Linux 커널을 빌드했다는 증거가 훨씬 설득력 있음

  • 원래 만우절용으로 가벼운 언어를 만들려 했는데, 이제 이런 수준의 결과가 나오니 놀라움. 그래도 계속 시도해볼 생각임

• 이건 “피라미드는 지을 수 있지만 성당은 못 짓는” 식의 접근임 (관련 글).
  엄청난 컴퓨팅 자원을 투입해 기능을 억지로 구현한 셈이고, 2만 달러가 불탔다고 표현할 만함.
  지수적 컴퓨팅으로 선형적 결과를 얻는 건 의미 있지만, 장기적으로는 비효율적인 방향 같음

  • 2만 달러면 API 기준이고, 구독 기준으로는 Max 플랜 5~6개 수준일 듯함
  • 그래도 그건 FAANG 엔지니어 2주치 인건비에 불과함. 인간이 2주 만에 컴파일러를 만들 순 없으니, 시연용으로는 충분히 가치 있음