▲

Claude가 생성한 C 컴파일러와 GCC 비교

 (harshanu.space)
3P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • 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 등 기존 도구가 여전히 필수
▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • 이번 논쟁은 LLM 코딩 에이전트에 대한 찬반 양쪽 시각을 잘 보여주는 예시임
    찬성 측은 “몇 시간 만에 작동하는 컴파일러를 만들었다니 놀랍다”고 하고, 반대 측은 “작동하지 않으면 의미가 없다”고 함
    복잡한 코드베이스일수록 에이전트가 더 약해지는 점, 그리고 “다음 세대가 고칠 것”이라는 반복적인 주장에 회의적임
    Anthropic이 Linux 커널을 컴파일했다고 했지만 실제로는 실패했고, AI의 과장된 기대와 현실의 괴리가 드러남

    • 최근 OCaml ‘vibe coded’ 사건을 떠올리게 됨
      테스트를 통과하고 겉보기에 맞는 출력을 내는 것과, 그 코드가 유지보수 가능한 품질을 갖는 것은 전혀 다른 문제임
    • “다음 세대 모델이 다 고칠 것”이라는 논리가 반복될 때마다 짜증이 남
    • “sufficiently smart LLM”이라는 C2 위키 페이지가 필요할지도 모르겠음
    • 이 논쟁은 마치 SpaceX의 발전 과정을 보는 듯함
      처음엔 “작은 함수만 작성 가능”, 그다음엔 “리눅스는 못 컴파일”, 그다음엔 “GCC 수준은 안 됨”이라며 계속 기준이 이동함
      하지만 발전 속도를 보면 몇 명의 컴파일러 엔지니어만 붙여도 빠르게 따라잡을 것 같음
    • C 컴파일러는 50년간 쌓인 코드의 결과물임
      그래서 LLM이 완전히 새로운 문제를 해결할 수 있을지는 여전히 의문임

  • Anthropic이 블로그에서 x86에서도 Linux 커널이 부팅된다고 했는데, 실제로는 RISC-V만 성공한 것으로 보임
    공식 포스트에서는 x86/ARM/RISC-V 모두 된다고 했지만,
    레포 문서에는 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는 완전히 파싱 가능한 언어가 아니다라는 글을 참고할 만함

  • “1회 반복 8배 느림이면 10억 번 반복해도 8배 느림일 뿐”이라는 지적처럼,
    158,000배라는 수치는 논리적으로 맞지 않음
    아마도 레지스터 스필링이 L3 캐시를 압도했거나, 불필요한 코드가 실행되는 버그가 있을 가능성이 있음

    • GCC 버전이 0.047초 만에 끝난 걸 보면, “10억 회 반복”이라는 주장도 신뢰하기 어려움

  • C 컴파일러를 만드는 건 인간에게도 어렵지만,
    이게 LLM의 지능 증거라고 보긴 힘듦
    이미 잘 알려진 문제이고, 수많은 구현과 문서가 학습 데이터에 포함되어 있음
    즉, LLM은 새로운 설계를 창조한 게 아니라 기존 패턴을 재조합한 것임
    그럼에도 이런 도구는 여전히 유용하며,
    진짜 인상적인 건 기존 OSS를 복제하는 게 아니라 새로운 접근법을 제시하는 모델이 나올 때일 것임

답변달기