# 병렬 Claude 팀을 활용한 C 컴파일러 구축 > Clean Markdown view of GeekNews topic #26446. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26446](https://news.hada.io/topic?id=26446) - GeekNews Markdown: [https://news.hada.io/topic/26446.md](https://news.hada.io/topic/26446.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-06T09:55:47+09:00 - Updated: 2026-02-06T09:55:47+09:00 - Original source: [anthropic.com](https://www.anthropic.com/engineering/building-c-compiler) - Points: 8 - Comments: 2 ## Summary **16개의 Claude 에이전트가 병렬로 협력해 Rust 기반 C 컴파일러를 완성했습니다.** 자동 루프 하네스를 통해 인간 개입 없이 10만 줄 규모의 코드를 생성하고, Linux 6.9 커널을 직접 빌드할 수 있을 만큼의 기능을 확보했습니다. 이 실험은 자율형 LLM 팀이 복잡한 시스템 소프트웨어를 구축할 수 있음을 보여주는 동시에, **품질 검증과 안전성 관리**가 향후 완전 자율 개발의 핵심 과제로 떠오르고 있음을 드러냅니다. ## Topic Body - **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**는 완전 자율 개발의 가능성을 보여줌 - 빠른 기술 발전 속도에 놀라움과 동시에 **새로운 윤리·안전 프레임워크 필요성** 강조 - 긍정적 활용이 부정적 위험을 상쇄할 것으로 기대되나, **새로운 개발 패러다임에 대한 대비 필요** ## Comments ### Comment 50717 - Author: mammal - Created: 2026-02-06T11:13:46+09:00 - Points: 1 C로 만든 컴파일러가 아닌 Rust 표준라이브러리로만 만든 프로젝트라 gcc/clang C 코드가 학습데이터에 있다는 비판은 좀 골대 옮기기 아닌가 싶네요. 어쨌든 대단합니다. ### Comment 50707 - Author: neo - Created: 2026-02-06T09:55:47+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46903616) - 나는 Google에서 거의 10년 동안 **Clang으로 Linux 커널 빌드** 작업을 했음. 이번 프로젝트([clangbuiltlinux.github.io](https://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](https://andonlabs.com/evals/vending-bench-2) 같은 벤치마크를 보면, AI 제품 매니저가 사용자 인터뷰, 실험, 로드맵 제안까지 자동으로 수행할 날이 머지않음 - 멋진 프로젝트지만, “클린룸” 언급은 빼는 게 나았음. **저작권 있는 코드로 훈련된 모델**이니까 그 반대에 가까움 - 하지만 인간도 기존 코드베이스를 학습하고, 그 지식을 바탕으로 **클린룸 구현**을 하기도 함 - 인간이 회사에서 배운 지식을 다른 곳에서 재활용하는 것처럼, LLM도 학습된 데이터를 **변형적 방식으로 재구성**하는 것임. 직접 복사만 아니라면 문제는 다름없음 - [GitHub 이슈](https://github.com/anthropics/claudes-c-compiler/issues/1)에 따르면, 문제는 include 경로 누락 때문임. 컴파일러 자체는 정상임 - 단순히 **glibc-devel** 같은 패키지가 빠진 듯함 - 글이 너무 길고 근거가 부족했음. 핵심을 놓친 느낌임 - AI는 미래임 - 정말 놀라운 결과임 - 나는 **모든 프롬프트와 에이전트 구조**를 공개했으면 함. 학습용으로 훌륭할 텐데, 2만 달러를 직접 써서 재현하기엔 부담스러움 - 요즘은 결과물만 보고 **과정은 궁금해하지 않는 분위기**가 아쉬움 - 이건 Cursor 블로그의 작동 버전 같음. 실제로 **Linux 커널을 빌드했다는 증거**가 훨씬 설득력 있음 - 원래 만우절용으로 가벼운 언어를 만들려 했는데, 이제 이런 수준의 결과가 나오니 놀라움. 그래도 계속 시도해볼 생각임 - 이건 “**피라미드는 지을 수 있지만 성당은 못 짓는**” 식의 접근임 ([관련 글](https://news.ycombinator.com/item?id=46898223)). 엄청난 컴퓨팅 자원을 투입해 기능을 억지로 구현한 셈이고, 2만 달러가 불탔다고 표현할 만함. **지수적 컴퓨팅으로 선형적 결과**를 얻는 건 의미 있지만, 장기적으로는 비효율적인 방향 같음 - 2만 달러면 API 기준이고, 구독 기준으로는 **Max 플랜 5~6개 수준**일 듯함 - 그래도 그건 **FAANG 엔지니어 2주치 인건비**에 불과함. 인간이 2주 만에 컴파일러를 만들 순 없으니, 시연용으로는 충분히 가치 있음