Opus 16마리가 C컴파일러 만든 비용 2만불

GCC는 37년, Claude는 2주

GCC의 첫 릴리스는 1987년이다. Richard Stallman이 시작한 이 프로젝트는 37년 동안 수천 명의 개발자가 수백만 줄의 코드를 쌓아올려 지금의 모습이 됐다. C 컴파일러를 밑바닥부터 만드는 일은 컴퓨터 과학에서 가장 난도 높은 작업 중 하나다. 전처리기, 렉서, 파서, 의미 분석기, 최적화기, 코드 생성기, 어셈블러, 링커를 모두 만들어야 한다. 30년 경력의 C 개발자 한 명은 이 프로젝트를 보고 "상위 1% 개발자만 가능한 일"이라고 평했다.

2026년 2월, Anthropic의 안전팀(Safeguards) 연구원 Nicholas Carlini가 이 불가능에 도전했다. 전직 침투 테스터 출신으로, 대기업 제품의 취약점을 파헤치던 사람이다. 그가 선택한 도구는 Claude Opus 4.6 에이전트 16개. 방법은 2주간 병렬 가동. 결과는 Rust로 작성된 10만 줄짜리 C컴파일러. 이름은 CCC, Claude's C Compiler다. 비용은 2만 달러. 그리고 이 컴파일러는 리눅스 커널 6.9를 x86, ARM, RISC-V 세 아키텍처에서 컴파일해 부팅까지 성공했다.

GitHub에는 이미 2,400개 이상의 스타가 달렸다. 숫자만 보면 경이적이다. 하지만 이 프로젝트의 진짜 의미는 숫자 너머에 있다. 2만 달러로 만든 컴파일러가 37년짜리 컴파일러와 같은 반열에 놓일 수 있는가. 그 답은 생각보다 복잡하다.

16마리의 Claude가 일하는 방식

Carlini가 설계한 시스템의 핵심은 "감독 없는 병렬 작업"이다. 16개의 Opus 4.6 에이전트는 각각 독립된 Docker 컨테이너에서 실행됐다. 개별 에이전트는 자체 작업 공간(/workspace)을 갖고 있었고, 공유 git 저장소(/upstream)를 통해 코드를 주고받았다.

오케스트레이션 에이전트는 없었다. 중앙 통제 없이 각 Claude가 스스로 다음 작업을 선택했다. 작업 충돌을 방지하기 위해 current_tasks/ 디렉터리에 텍스트 파일을 생성하는 잠금 파일 방식을 사용했다. 머지 충돌이 발생하면 Claude가 자율적으로 해결했다.

Carlini의 설명에 따르면, 구조는 놀라울 정도로 단순했다. "Claude를 단순한 루프에 넣어서 현재 작업이 완벽해질 때까지 작업하게 하고, 끝나면 바로 다음 작업으로 넘어가게 했다." 인간이 개입한 것은 테스트 작성과 작업 방향 설정뿐이었다. 코드는 한 줄도 직접 쓰지 않았다. README의 한 문단을 제외하면 CCC의 코드와 문서 100%가 Claude Opus 4.6이 작성한 것이다.

에이전트들은 코어 컴파일러 개발 외에도 전문화된 역할을 수행했다. 중복 코드 탐지 및 리팩터링, 컴파일러 성능 최적화, 효율적 코드 생성, Rust 설계 비평 및 구조 개선, 문서 유지보수 등이 각 에이전트에 분배됐다. 클린룸 환경도 철저했다. 개발 중 인터넷 접근은 차단됐고, Rust 표준 라이브러리만 사용할 수 있었다.

프로젝트 진행에 따라 병렬화 전략도 진화했다. 초반에는 각 에이전트가 서로 다른 실패 테스트를 담당했다. 통과율이 99%에 도달하자 전략을 바꿔, 각 에이전트가 SQLite, Redis, libjpeg, QuickJS, Lua 등 서로 다른 실제 프로젝트를 컴파일하는 식으로 작업을 분배했다. 리눅스 커널이라는 거대한 단일 작업에서는 GCC를 오라클로 활용했다. 파일 집합을 무작위로 나눠 일부는 GCC로, 나머지는 CCC로 컴파일한 뒤 결과를 비교하는 방식으로 버그를 파일 단위까지 추적했다.

2억 토큰과 3,982개의 커밋

숫자를 정리하면 이 프로젝트의 규모가 더 선명해진다.

항목	수치
에이전트 수	16개 (Opus 4.6)
총 세션 수	약 2,000회
소요 기간	약 2주
입력 토큰	20억 개
출력 토큰	1억 4천만 개
API 비용	2만 달러
생성 코드	10만 줄 (Rust 96.2%, C 3.8%)
git 커밋	3,982개
컴파일 성공 프로젝트	150개 이상
GCC torture 테스트 통과율	99%

2주 동안 3,982개의 커밋이 발생했다는 것은, 분당 약 0.2개 꼴로 커밋이 쌓였다는 뜻이다. 인간 개발자 한 명이 하루에 5~10개의 커밋을 만든다고 가정하면, 16개 에이전트는 인간 팀 수십 명에 해당하는 속도로 코드를 생산한 셈이다.

컴파일러 아키텍처도 교과서적인 구조를 충실히 따랐다. 전처리기, 렉서, 파서, 의미 분석, SSA 기반 중간 표현, 15개의 최적화 패스, 코드 생성기, 어셈블러, 링커까지 모든 컴포넌트를 처음부터 구축했다. 타겟 아키텍처는 x86-64, i686, AArch64, RISC-V 64 네 가지다. x86 SIMD 명령어(SSE부터 AVX-512, AES-NI, FMA, SHA, BMI2까지)와 ARM NEON 인트린식까지 내장 C 헤더에 포함시켰다.

성공적으로 컴파일한 프로젝트 목록도 인상적이다. 리눅스 커널 6.9, PostgreSQL(237개 회귀 테스트 전체 통과), FFmpeg(7,331개 FATE 체크섬 테스트 통과), QEMU, Redis, CPython, LuaJIT, GNU coreutils, Busybox, libsodium, libpng, jq, libjpeg-turbo, mbedTLS, musl, 그리고 DOOM까지. 심지어 TCC(Tiny C Compiler)도 컴파일했다. AI가 만든 컴파일러로 다른 컴파일러를 컴파일한 것이다. 단순한 "Hello World" 수준의 장난감이 아니라, 실제 운영 환경에서 사용되는 대규모 프로젝트 150개 이상을 컴파일할 수 있는 수준이다.

GCC -O0보다 12% 빠르고, -O2보다 2.76배 느리다

성능 벤치마크는 CCC의 현재 위치를 가장 정직하게 보여준다. CCC가 생성한 바이너리는 GCC의 최적화를 끈 상태(-O0)보다 12% 빠르다. 하지만 GCC의 표준 최적화(-O2)와 비교하면 2.76배 느리다.

이 격차의 원인은 명확하다. CCC는 GCC보다 3.3배 많은 명령어를 생성한다. 최적화 패스가 15개 존재하지만, -O0부터 -O3까지 모든 최적화 수준에서 동일한 파이프라인을 실행한다. 즉, 최적화 수준 구분이 아직 구현되지 않았다.

흥미로운 점은 CCC가 생성한 코드의 IPC(Instructions Per Cycle)가 4.89로, GCC의 4.13보다 높다는 것이다. CCC의 코드가 더 단순하기 때문에 CPU가 명령어를 더 효율적으로 처리할 수 있지만, 전체 명령어 수가 압도적으로 많아 총 실행 시간에서는 밀린다. 최적화라는 영역에서 37년간 축적된 노하우를 2주 만에 따라잡기란 불가능에 가깝다.

정확도 측면에서는 100%를 달성했다. 모든 테스트 케이스에서 CCC가 생성한 바이너리는 GCC의 출력과 기능적으로 동일한 결과를 내놓았다. 컴파일러에서 정확도가 100%라는 것은 결코 사소한 성과가 아니다. 컴파일러 버그는 다른 소프트웨어 버그보다 치명적이다. 컴파일러가 틀리면 그 위에 쌓인 모든 프로그램이 흔들린다.

다만 기술적 한계도 분명히 존재한다. 16비트 x86 코드 생성기가 미완성이라 해당 단계에서는 GCC를 호출한다. CCC가 생성하는 16비트 코드는 리눅스의 32KB 제한을 훌쩍 넘는 60KB 이상이 나온다. _Complex 산술의 에지 케이스, _Atomic 한정자가 파싱만 되고 타입 시스템에서 추적되지 않는 문제, GNU 확장의 부분적 지원 등도 아직 해결되지 않았다. 리눅스 전용이라 macOS와 Windows에서는 동작하지 않는다.

Clang 만든 Chris Lattner의 냉정한 평가

이 프로젝트에 대해 가장 무게감 있는 평가를 내린 사람은 Chris Lattner다. LLVM을 만들고, Clang을 만들고, Swift 언어를 설계한 인물이다. Apple, Google, Tesla를 거친 그가 CCC에 대한 상세한 기술 리뷰를 공개했다.

Lattner는 CCC를 **"실질적 진전이자 업계의 이정표"**라고 인정하면서도, 동시에 **"진정한 혁명은 아니다"**라고 선을 그었다. 그의 평가는 구체적이었다. CCC는 **"우수한 학부 팀이 프로젝트 초기에 만들 법한 교과서적 구현"**이라는 것이다. SSA IR은 LLVM에서 영감을 받은 GetElementPtr과 기본 블록 "종결자" 개념을 사용하고 있었다.

기술적 비판도 날카로웠다. 코드 생성기가 "장난감 수준"이고 옵티마이저가 IR 대신 어셈블리 텍스트를 다시 파싱한다는 점, 파서의 에러 복구 능력이 떨어진다는 점, 시스템 헤더를 파싱하지 않고 테스트에 필요한 내용을 하드코딩했다는 점 등을 지적했다. 특히 마지막 지적은 CCC의 범용성을 제한하는 "가장 큰 문제"로 꼽았다.

하지만 Lattner의 리뷰에서 가장 핵심적인 대목은 AI 능력 자체에 대한 통찰이었다. "알려진 추상화를 구현하는 것과 새로운 추상화를 발명하는 것은 다르다. 이 구현에서 새로운 것은 아무것도 보이지 않는다." LLM은 "수십 년간 축적된 컴파일러 공학의 합의를 재현하는 극도로 강력한 분포 추종자"라는 것이 그의 결론이다.

다시 말해, Claude가 한 일은 컴파일러 교과서에 나오는 내용을 대규모로, 빠르게, 정확하게 재현한 것이다. 누구도 생각하지 못한 새로운 최적화 기법이나 혁신적인 아키텍처를 고안한 것이 아니다. 이 구분은 결정적으로 중요하다. 구현 능력과 설계 능력은 다른 차원의 문제이기 때문이다.

Lattner는 이를 바탕으로 세 가지 전망을 제시했다. 첫째, 수작업 재작성이 AI 네이티브 작업이 되어 대규모 엔지니어링 카테고리가 자동화된다. 둘째, 구현 비용이 0에 수렴하면서 아키텍처 설계 능력의 가치가 극대화된다. 셋째, 엔지니어의 역할이 명세, 검증, 설계 쪽으로 상향 이동한다. 코드를 쓰는 일이 아니라, 어떤 코드가 존재해야 하는지를 결정하는 일이 핵심이 된다는 것이다.

"빵을 훔쳐서 섞은 것을 빵을 만들었다고 하지 않는다"

온라인 반응은 극명하게 갈렸다. GitHub에서 가장 많은 공감을 받은 댓글 중 하나는 이랬다. "슈퍼마켓에서 모든 빵을 조금씩 훔쳐서 섞은 것을 '처음부터 빵을 만들었다'고 하지 않는다. 그건 도둑질이라 부른다." 훈련 데이터에 모든 오픈소스 컴파일러가 포함되어 있을 가능성을 지적한 것이다.

이 비판의 핵심은 정당하다. GCC, Clang, TCC, 그리고 수많은 교육용 컴파일러의 소스코드가 공개되어 있다. Claude의 훈련 데이터에 이 코드들이 포함되어 있지 않다고 보기 어렵다. CCC가 "처음부터" 만든 것인지, 아니면 기존 컴파일러 구현을 재조합한 것인지는 여전히 열린 질문이다.

Hacker News에서 한 사용자는 이 문제를 더 엄밀하게 제기했다. "진짜 능력을 검증하려면 J 같은 훈련 데이터에 거의 포함되지 않는 비주류 언어로 테스트해야 한다." 분포 내(in-distribution) 작업에서의 성공이 분포 외(out-of-distribution) 작업에서의 능력을 보장하지 않는다는 것이다.

비용에 대한 회의론도 있었다. 남아프리카공화국의 한 계약 개발자는 자신의 시급 기준으로 2만 달러면 4주 안에 동등한 컴파일러를 만들 수 있다고 주장했다. 실제 필요한 코드는 10만 줄이 아니라 1만 5천 줄 정도일 것이라는 분석이었다. 또 다른 사용자는 AI 관리에 투입된 Carlini의 시간, 실패한 시도의 비용, API 가격이 현재 적자를 감수한 수준이라는 점을 지적하며 "실제 비용은 2만 달러보다 훨씬 높다"고 반박했다.

반면 옹호론도 만만치 않았다. **"2만 달러로 10만 줄의 작동하는 코드라니, 인간 개발자 팀을 고용하는 비용과 비교하면 엄청나게 저렴하다"**는 의견에 상당한 공감이 몰렸다. 추론 비용이 매년 약 90%씩 하락하고 있다는 데이터를 근거로, 같은 프로젝트를 1년 후에 다시 하면 2천 달러면 충분할 것이라는 전망도 나왔다. Carlini 본인도 이 비용이 **"나 혼자 만드는 비용의 극히 일부이고, 팀을 꾸린다면 비교조차 안 된다"**고 평가했다.

Google의 Clang 팀에서 일하는 컴파일러 전문가 ndesaulniers는 좀 더 신중한 입장이었다. **"프로덕션 컴파일러로서의 정확성은 아직 판단할 수 없다"**는 것이다. 테스트를 통과하는 것과 임의의 코드를 안전하게 컴파일하는 것은 전혀 다른 차원의 문제라는 지적이었다. 실제로 한 Hacker News 사용자는 CCC가 "타입 검사를 제대로 하지 않는다"고 분석했다. 비포인터에 대한 역참조를 허용하고, 잘못된 인자 수로 함수를 호출해도 에러를 내지 않는다는 것이다.

전 Microsoft 임원 Steve Sinofsky는 다른 각도에서 비교의 오류를 지적했다. GCC가 37년이 걸린 것은 "작동하는 데" 37년이 걸린 게 아니라, C 언어 표준의 진화와 새로운 플랫폼의 등장에 맞춰 37년간 적응해온 것이다. 2주 대 37년이라는 비교 자체가 성립하지 않는다는 지적이었다.

Carlini가 "흥분하면서도 불편하다"고 말한 이유

프로젝트를 직접 수행한 Carlini의 반응은 양가적이었다. 그는 이 프로젝트를 **"최근 가장 재밌었던 경험"**이라고 표현하면서도, **"이것이 2026년 초에 가능하리라고는 전혀 예상하지 못했다"**고 덧붙였다.

그가 불편함을 느낀 지점은 기술적 한계가 아니라 사회적 함의였다. **"프로그래머들이 개인적으로 검증하지 않은 소프트웨어를 배포하는 상황이 현실적 우려"**라는 발언은, 안전팀 연구원으로서의 직업적 감각이 반영된 것이다.

Carlini는 프로젝트를 통해 얻은 실전 교훈도 공유했다. 가장 중요한 원칙은 **"극도로 높은 품질의 테스트를 작성하라"**는 것이었다. 테스트 검증기가 완벽에 가까워야 Claude가 올바른 문제를 풀 수 있다. 테스트가 부정확하면 Claude는 잘못된 방향으로 끝없이 최적화한다.

실무적인 팁도 흥미로웠다. 표준 출력을 최소화하고 상세 로그는 검색 가능한 파일에 저장할 것. 에러 태그를 같은 줄에 배치해 grep으로 탐지할 수 있게 할 것. 사전 계산된 집계 통계를 제공할 것. 테스트의 1~10%만 결정적으로 샘플링하는 --fast 옵션을 만들어 에이전트별 빠른 피드백을 가능하게 할 것. 회귀를 방지하는 CI를 구축할 것.

그리고 한 가지 결정적인 관찰이 있었다. "Claude는 시간을 인지하지 못한다. 방치하면 진전 없이 몇 시간이고 테스트만 돌리고 있을 수 있다." 이 말은 현재 AI 에이전트의 근본적 한계를 드러낸다. 코드를 쓰는 능력은 갖추었지만, 목표를 향해 효율적으로 시간을 배분하는 메타인지 능력은 아직 부족하다는 뜻이다.

Carlini가 공유한 또 하나의 교훈은 "Claude의 관점에서 설계하라"는 것이었다. 진행 상황을 명시적으로 출력하게 하고, 빠른 실행 모드를 제공해야 한다. 테스트 실행에 진전이 있는지 없는지를 Claude 스스로 판단할 수 없기 때문에, 인간이 그 판단 기준을 미리 설계해 넣어야 한다. 에이전트를 관리하는 것은 주니어 개발자를 관리하는 것과 비슷하면서도 근본적으로 다르다. 주니어는 막히면 물어보지만, Claude는 막혀도 물어보지 않고 같은 시도를 반복한다.

구현 비용이 0에 수렴하는 세계

이 프로젝트의 진짜 의미는 CCC라는 컴파일러 자체에 있지 않다. 10만 줄짜리 컴파일러가 쓸모 있느냐, GCC를 대체할 수 있느냐는 부차적인 질문이다. CCC는 현시점에서 프로덕션에 쓸 물건이 아니다. Carlini 스스로도 "실제 컴파일러의 직접 대체물이 아니다"라고 인정했다.

핵심은 구현 비용의 붕괴다. 2만 달러와 2주면 10만 줄 규모의 복잡한 시스템을 만들 수 있는 시대가 열렸다는 것. Chris Lattner는 이 변화가 소프트웨어 엔지니어의 역할을 근본적으로 바꿀 것이라고 전망했다. "구현 비용이 0에 수렴하면, 희소한 자원은 위로 이동한다. 어떤 시스템이 존재해야 하는지, 소프트웨어가 어떻게 진화해야 하는지를 결정하는 능력이 가장 가치 있어진다."

Carlini의 이전 실험 결과가 이 궤적을 보여준다. Opus 4.0은 기능하는 컴파일러조차 만들지 못했다. Opus 4.5에서 처음으로 대규모 테스트를 통과하는 컴파일러가 나왔지만 실제 프로젝트는 컴파일하지 못했다. Opus 4.6에서 리눅스 커널 컴파일에 성공했다. 모델 한 세대가 바뀔 때마다 가능한 일의 범위가 급격히 넓어지고 있다.

Simon Willison은 이 프로젝트에서 더 깊은 질문을 끌어냈다. "수십 년간 공개된 코드로 훈련된 AI 시스템이 익숙한 구조와 패턴, 심지어 특정 구현까지 재현할 수 있다면, 학습과 복사의 경계는 정확히 어디인가?" 이 질문에 대한 합의는 아직 없다. 그리고 합의가 없다는 것 자체가 이 기술의 현주소를 말해준다.

CCC는 AI가 코드를 "쓸 수 있다"는 것을 증명하지 않았다. 그건 이미 알려진 사실이다. CCC가 증명한 것은 AI가 "복잡한 시스템을 처음부터 끝까지 구축할 수 있다"는 것이다. 그리고 그 비용이 인간 팀의 수십 분의 1이라는 것이다.

Carlini는 이 프로젝트의 함의를 이렇게 정리했다. "에이전트 팀은 복잡한 프로젝트 전체를 자율적으로 구현할 수 있는 가능성을 보여준다. 우리는 새로운 세계에 진입하고 있으며, 안전하게 항해하기 위한 새로운 전략이 필요하다." 안전팀 연구원다운 마무리다. 기술의 잠재력에 감탄하면서도, 그 잠재력이 초래할 위험을 동시에 경계하는 시선. CCC라는 컴파일러보다 이 시선이 더 오래 유효할 것이다.

출처: