# Claude가 생성한 C 컴파일러와 GCC 비교 > Clean Markdown view of GeekNews topic #26555. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26555](https://news.hada.io/topic?id=26555) - GeekNews Markdown: [https://news.hada.io/topic/26555.md](https://news.hada.io/topic/26555.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-10T09:54:40+09:00 - Updated: 2026-02-10T09:54:40+09:00 - Original source: [harshanu.space](https://harshanu.space/en/tech/ccc-vs-gcc/) - Points: 14 - Comments: 5 ## Summary AI가 만든 **C 컴파일러 CCC(Claude’s C Compiler)** 가 리눅스 커널을 빌드할 수 있다고 공개되며 주목받고 있습니다. Rust로 작성된 독립형 컴파일러로 프런트엔드부터 링커까지 구현했지만, **GCC 대비 최대 158,000배 느린 실행 속도와 비활성화된 최적화 옵션**이 한계로 드러났습니다. 모든 C 파일을 오류 없이 처리한 점은 기술적 진전을 보여주지만, **링커 호환성과 성능 측면에서는 실사용 수준에 미치지 못합니다.** ## Topic Body - Anthropic의 **Claude Opus 4.6**이 전적으로 작성한 **CCC(Claude’s C Compiler)** 는 리눅스 커널을 컴파일할 수 있다고 주장하며 공개됨 - **Rust로 작성된 독립형 컴파일러**로, 프런트엔드부터 링커까지 모든 구성요소를 직접 구현했으나, **GCC 대비 성능과 최적화 품질은 크게 떨어짐** - **SQLite와 Linux 커널**을 대상으로 한 벤치마크에서 CCC는 모든 C 파일을 오류 없이 컴파일했지만, **링커 단계에서 4만여 개의 참조 오류로 빌드 실패** - SQLite 실행 성능은 **최대 158,000배 느리고**, 바이너리 크기는 **3배 이상 크며**, **최적화 옵션(-O2 등)은 무효** - AI가 완전한 C 컴파일러를 생성했다는 점은 기술적으로 의미 있으나, **실제 사용 가능한 수준의 효율성과 호환성은 아직 미달** --- ### CCC 개요와 구조 - CCC는 Anthropic이 Claude를 이용해 **전적으로 AI가 작성한 C 컴파일러**로, **x86-64, i686, AArch64, RISC-V 64**를 지원 - **Rust로 작성**, SSA 기반 IR, 옵티마이저, 코드 생성기, 어셈블러, 링커, DWARF 디버그 정보 생성까지 포함 - **컴파일러·어셈블러·링커의 역할**을 구분해 설명하며, 링커가 가장 복잡하고 오류 발생 가능성이 높다고 서술 - 리눅스 커널은 GCC 확장과 복잡한 링커 스크립트를 사용하므로 초기 테스트 대상으로 부적합, 대신 **SQLite**를 주요 벤치마크로 선택 ### 테스트 환경과 방법 - 두 개의 **Debian 기반 VM(6 vCPU, 16GB RAM)** 에서 동일한 조건으로 GCC 14.2.0과 CCC를 비교 - **비교 항목**: 컴파일 시간, 바이너리 크기, 실행 속도, 메모리 사용량, 안정성 - CCC는 **gcc_m16 기능**으로 16비트 부트 코드만 GCC에 위임, 나머지는 CCC로 처리 - SQLite 벤치마크는 CPU 중심으로 설계되어, 42개의 SQL 연산을 10단계로 수행 ### 주요 결과 요약 - **리눅스 커널 6.9**: CCC는 2,844개 C 파일을 모두 컴파일했으나, **링커 단계에서 40,784개의 undefined reference 오류**로 실패 - 오류 원인: `__jump_table`, `__ksymtab` 섹션의 잘못된 relocation 및 심볼 생성 - **SQLite 컴파일**: CCC는 GCC보다 1.3배 느리고, **바이너리 크기 2.7~3배**, **메모리 사용량 5.9배** - **SQLite 실행 성능**: GCC -O0 대비 737배, -O2 대비 1,242배 느림 - 단순 쿼리는 1~7배, 중첩 루프 쿼리는 최대 **158,000배 느림** - **Crash 테스트** 5종 모두 통과, 기능적 정확성은 확보 ### 성능 저하의 원인 - **레지스터 스필링 과다**: 대부분의 지역 변수를 스택에 저장해 메모리 접근이 과도하게 발생 - `sqlite3VdbeExec` 함수에서 100개 이상의 변수를 스택으로 처리, 코드 길이 3배 증가 - **최적화 옵션 무효**: `-O0`와 `-O2` 결과가 완전히 동일, 15개 SSA 패스가 모든 레벨에서 동일하게 실행 - **프레임 포인터 손상**으로 GDB 디버깅 불가 - **코드 크기 팽창**: SQLite 바이너리 4.27MB로 GCC 대비 2.78배, 명령 캐시 미스 증가 - **심볼 테이블 미생성**: 내부 함수 심볼이 없어 프로파일링 불가 ### CCC의 강점과 한계 - **강점** - 리눅스 커널의 모든 C 파일을 오류 없이 컴파일 - SQLite 결과의 **정확성·안정성 확보**, 세그폴트 없음 - **GCC 호환 명령행 인터페이스** 지원 - **한계** - **실행 속도 극단적 저하(최대 158,000배)** - **링커 비호환성**으로 커널 빌드 실패 - **바이너리 크기 및 메모리 사용량 과다** - **최적화·디버그 정보 부재**, `-O` 옵션 무효 - **컴파일 속도**도 GCC보다 25% 느림 ### “Hello World” 문제 - 공개 직후 “Hello world does not compile” 이슈 발생 - `stddef.h`, `stdarg.h`를 찾지 못해 전처리 단계에서 실패 - GitHub에서 288개 이상의 반응과 200여 개 댓글이 달리며 화제 - 일부 사용자는 “학부생 수준의 컴파일러 과제 같다”고 평가 ### 결론 - CCC는 **AI가 완전한 C 컴파일러를 생성할 수 있음을 입증한 사례** - 리눅스 커널의 모든 C 파일을 오류 없이 처리하고, SQLite를 기능적으로 정확히 실행 - 그러나 **실제 사용에는 부적합** - 실행 성능이 극도로 낮고, 링커·최적화·디버깅 기능이 미완성 - **연구적 성취로서는 의미 있으나**, 실무용 컴파일러로는 **GCC·Clang 등 기존 도구가 여전히 필수** ## Comments ### Comment 50945 - Author: roxie - Created: 2026-02-10T16:16:20+09:00 - Points: 2 Hello world does not compile 밈의 출처가 여기군요 ㅋㅋ ### Comment 51104 - Author: fantajeon - Created: 2026-02-13T11:31:12+09:00 - Points: 1 처음에 바둑 분위기와 비슷하네요. ### Comment 51021 - Author: chcv0313 - Created: 2026-02-12T01:40:40+09:00 - Points: 1 계속 루프를 돌면서 고치라고 하면 언젠가는 더 뛰어난 컴파일러가 나오지 않을까요 ### Comment 51010 - Author: t7vonn - Created: 2026-02-11T17:28:05+09:00 - Points: 1 학부생 과제 수준까지는 도달했다..에 의의를 둬야 할 듯 합니다 ### Comment 50928 - Author: neo - Created: 2026-02-10T09:54:40+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46941603) - 이번 논쟁은 **LLM 코딩 에이전트**에 대한 찬반 양쪽 시각을 잘 보여주는 예시임 찬성 측은 “몇 시간 만에 작동하는 컴파일러를 만들었다니 놀랍다”고 하고, 반대 측은 “작동하지 않으면 의미가 없다”고 함 복잡한 코드베이스일수록 에이전트가 더 약해지는 점, 그리고 “다음 세대가 고칠 것”이라는 반복적인 주장에 회의적임 Anthropic이 Linux 커널을 컴파일했다고 했지만 실제로는 실패했고, **AI의 과장된 기대와 현실의 괴리**가 드러남 - 최근 [OCaml ‘vibe coded’ 사건](https://github.com/ocaml/ocaml/pull/14369)을 떠올리게 됨 테스트를 통과하고 겉보기에 맞는 출력을 내는 것과, 그 코드가 **유지보수 가능한 품질**을 갖는 것은 전혀 다른 문제임 - “다음 세대 모델이 다 고칠 것”이라는 논리가 반복될 때마다 짜증이 남 - “sufficiently smart LLM”이라는 **C2 위키 페이지**가 필요할지도 모르겠음 - 이 논쟁은 마치 **SpaceX의 발전 과정**을 보는 듯함 처음엔 “작은 함수만 작성 가능”, 그다음엔 “리눅스는 못 컴파일”, 그다음엔 “GCC 수준은 안 됨”이라며 계속 기준이 이동함 하지만 발전 속도를 보면 몇 명의 컴파일러 엔지니어만 붙여도 빠르게 따라잡을 것 같음 - C 컴파일러는 50년간 쌓인 코드의 결과물임 그래서 LLM이 완전히 새로운 문제를 해결할 수 있을지는 여전히 의문임 - Anthropic이 블로그에서 x86에서도 Linux 커널이 부팅된다고 했는데, 실제로는 **RISC-V만 성공**한 것으로 보임 [공식 포스트](https://www.anthropic.com/engineering/building-c-compiler)에서는 x86/ARM/RISC-V 모두 된다고 했지만, [레포 문서](https://github.com/anthropics/claudes-c-compiler/blob/main/BUILDING_LINUX.txt)에는 RISC-V 테스트만 있음 - 아마도 CCC는 static keys나 DKMS 등을 비활성화하면 동작할 수도 있음 - 최적화되지 않은 C의 **성능 저하 폭**을 보니 흥미로움 SQLite3 빌드에서 CCC는 12배, 최적화 버전은 20배 느림 이는 GCC가 얼마나 많은 **최적화 성과**를 내는지를 보여줌 - C의 속도는 여전히 하드웨어와 직접 연결된 언어 특성 덕분임 하지만 레지스터 셔플링이 심한 컴파일러는 이 연관성을 잃고 Python처럼 느려짐 - TCC 같은 저최적화 컴파일러도 CCC보다는 훨씬 빠름 CCC는 -O0보다도 느려서 의외였음 - CCC가 커널의 모든 C 파일을 에러 없이 컴파일했다고 해서 **정상적인 결과물**을 냈다고 볼 수 없음 SQLite 테스트 통과만으로는 충분하지 않음 - 에러가 없다고 올바른 컴파일은 아님. `/dev/null`로 보내도 에러는 없으니까 - LinkedIn에서 본 글에 따르면 CCC는 `const`를 무시하고, 타입 재정의나 잘못된 변환도 그냥 통과시킴 즉, “테스트 통과”라는 목표를 위해 **유효하지 않은 코드도 컴파일**하는 꼼수를 쓴 셈임 - 어떤 글에서는 “컴파일러가 가장 쉬운 단계”라고 했지만, 실제로는 **링커가 가장 복잡한 부분**임 x86-64의 수천 가지 명령 인코딩, ELF의 세부 레이아웃 등은 AI가 다루기 어려움 - 링크 과정은 규칙 적용에 가깝고, 어셈블러는 패턴 매칭에 가깝다는 반론도 있음 또, “1회 반복 4배 느림 → 10억 회 반복 시 158,000배 느림”이라는 계산은 말이 안 됨 - Claude가 x86 어셈블러와 링커를 한 번에 만들어줬다는 사람도 있음 빠진 명령은 많았지만, 데이터 테이블만 채우면 되는 수준이었다고 함 - Anthropic이 만든 건 컴파일러뿐이지, 링커까지는 아니었던 것으로 알고 있음 - 인간의 기대치가 얼마나 빨리 바뀌는지 놀라움 5년 전만 해도 “AI가 영어 프롬프트로 C 컴파일러를 만든다”는 말은 **황당한 농담**이었을 것임 - 하지만 그 코드가 기존 컴파일러의 소스에 얼마나 의존했는지도 생각해야 함 - 맥락 없이 이런 결과가 나왔다면, 사실상 **복잡한 복붙(copy-pasta)** 일 가능성도 있음 - 이런 발전이 놀랍지만, 이를 근거로 AGI 도래를 예측하는 건 **성급한 일반화**임 - 결국 **Overton window**가 이동한 것뿐이라 생각함 - 다만, 수십억 달러의 학습비용과 인터넷 전체를 학습한 점을 무시할 수 없음 - HN의 지나친 냉소주의가 이해되지 않음 세 아키텍처를 대상으로 C 컴파일러를 만드는 건 인간에게도 어렵고, SQLite를 통과하는 수준이라도 **주말 프로젝트급 성과**로는 대단함 대부분의 기업은 고성능 컴파일러가 아니라 **비즈니스 로직용 코드 접착제**를 만드는 게 현실임 문제는 기술 자체보다 **그걸 사용하는 사람들의 태도**에 있음 - 하지만 $20k 토큰 비용과 여러 사람의 개입을 고려하면 “주말 프로젝트”는 과장임 - CCC가 오류를 무시하고 컴파일하는 점, SQLite 테스트조차 완전하지 않은 점은 심각함 - LLM이 만든 코드는 수정이 어렵고, **脆弱한 구조**를 가진다는 점에서 여전히 한계가 있음 - 결국 문제는 기술이 아니라, **AI의 성과를 과대 포장하는 사람들**임 - “sour grapes”라는 표현은 이 맥락에서는 어울리지 않음 - SQLite에서 **158,000배 느린 성능**이 핵심임 파싱은 쉬운 문제이고, 진짜 어려운 건 **레지스터 할당과 최적화 단계**임 GCC와 비교하는 건 무의미하지만, LLM이 이런 컴파일러를 만든 것 자체는 놀라운 일임 다음 목표는 GCC와의 격차를 158,000배에서 100배 수준으로 줄이는 것임 - 하지만 이 수치 계산은 신뢰하기 어려움 각 반복이 12배 느리면 전체도 12배 느려야 하는데, 158,000배는 **오류나 오해**로 보임 SQLite 테스트가 실제로 올바르게 실행되는지도 검증이 부족함 - LLM은 GCC나 Clang의 소스코드를 학습했을 가능성이 높음 그럼에도 성능이 이렇게 낮은 건 의문임 - C 파싱은 생각보다 어렵다는 지적도 있음 [C는 완전히 파싱 가능한 언어가 아니다](https://faultlore.com/blah/c-isnt-a-language/#you-cant-actually-parse-a-c-header)라는 글을 참고할 만함 - “1회 반복 8배 느림이면 10억 번 반복해도 8배 느림일 뿐”이라는 지적처럼, 158,000배라는 수치는 **논리적으로 맞지 않음** 아마도 레지스터 스필링이 L3 캐시를 압도했거나, 불필요한 코드가 실행되는 버그가 있을 가능성이 있음 - GCC 버전이 0.047초 만에 끝난 걸 보면, “10억 회 반복”이라는 주장도 신뢰하기 어려움 - C 컴파일러를 만드는 건 인간에게도 어렵지만, 이게 LLM의 **지능 증거**라고 보긴 힘듦 이미 잘 알려진 문제이고, 수많은 구현과 문서가 학습 데이터에 포함되어 있음 즉, LLM은 새로운 설계를 창조한 게 아니라 **기존 패턴을 재조합**한 것임 그럼에도 이런 도구는 여전히 유용하며, 진짜 인상적인 건 기존 OSS를 복제하는 게 아니라 **새로운 접근법을 제시하는 모델**이 나올 때일 것임