이번 논쟁은 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의 소스코드를 학습했을 가능성이 높음
그럼에도 성능이 이렇게 낮은 건 의문임
“1회 반복 8배 느림이면 10억 번 반복해도 8배 느림일 뿐”이라는 지적처럼,
158,000배라는 수치는 논리적으로 맞지 않음
아마도 레지스터 스필링이 L3 캐시를 압도했거나, 불필요한 코드가 실행되는 버그가 있을 가능성이 있음
GCC 버전이 0.047초 만에 끝난 걸 보면, “10억 회 반복”이라는 주장도 신뢰하기 어려움
C 컴파일러를 만드는 건 인간에게도 어렵지만,
이게 LLM의 지능 증거라고 보긴 힘듦
이미 잘 알려진 문제이고, 수많은 구현과 문서가 학습 데이터에 포함되어 있음
즉, LLM은 새로운 설계를 창조한 게 아니라 기존 패턴을 재조합한 것임
그럼에도 이런 도구는 여전히 유용하며,
진짜 인상적인 건 기존 OSS를 복제하는 게 아니라 새로운 접근법을 제시하는 모델이 나올 때일 것임
Hacker News 의견들
이번 논쟁은 LLM 코딩 에이전트에 대한 찬반 양쪽 시각을 잘 보여주는 예시임
찬성 측은 “몇 시간 만에 작동하는 컴파일러를 만들었다니 놀랍다”고 하고, 반대 측은 “작동하지 않으면 의미가 없다”고 함
복잡한 코드베이스일수록 에이전트가 더 약해지는 점, 그리고 “다음 세대가 고칠 것”이라는 반복적인 주장에 회의적임
Anthropic이 Linux 커널을 컴파일했다고 했지만 실제로는 실패했고, AI의 과장된 기대와 현실의 괴리가 드러남
테스트를 통과하고 겉보기에 맞는 출력을 내는 것과, 그 코드가 유지보수 가능한 품질을 갖는 것은 전혀 다른 문제임
처음엔 “작은 함수만 작성 가능”, 그다음엔 “리눅스는 못 컴파일”, 그다음엔 “GCC 수준은 안 됨”이라며 계속 기준이 이동함
하지만 발전 속도를 보면 몇 명의 컴파일러 엔지니어만 붙여도 빠르게 따라잡을 것 같음
그래서 LLM이 완전히 새로운 문제를 해결할 수 있을지는 여전히 의문임
Anthropic이 블로그에서 x86에서도 Linux 커널이 부팅된다고 했는데, 실제로는 RISC-V만 성공한 것으로 보임
공식 포스트에서는 x86/ARM/RISC-V 모두 된다고 했지만,
레포 문서에는 RISC-V 테스트만 있음
최적화되지 않은 C의 성능 저하 폭을 보니 흥미로움
SQLite3 빌드에서 CCC는 12배, 최적화 버전은 20배 느림
이는 GCC가 얼마나 많은 최적화 성과를 내는지를 보여줌
하지만 레지스터 셔플링이 심한 컴파일러는 이 연관성을 잃고 Python처럼 느려짐
CCC는 -O0보다도 느려서 의외였음
CCC가 커널의 모든 C 파일을 에러 없이 컴파일했다고 해서 정상적인 결과물을 냈다고 볼 수 없음
SQLite 테스트 통과만으로는 충분하지 않음
/dev/null로 보내도 에러는 없으니까const를 무시하고, 타입 재정의나 잘못된 변환도 그냥 통과시킴즉, “테스트 통과”라는 목표를 위해 유효하지 않은 코드도 컴파일하는 꼼수를 쓴 셈임
어떤 글에서는 “컴파일러가 가장 쉬운 단계”라고 했지만, 실제로는 링커가 가장 복잡한 부분임
x86-64의 수천 가지 명령 인코딩, ELF의 세부 레이아웃 등은 AI가 다루기 어려움
또, “1회 반복 4배 느림 → 10억 회 반복 시 158,000배 느림”이라는 계산은 말이 안 됨
빠진 명령은 많았지만, 데이터 테이블만 채우면 되는 수준이었다고 함
인간의 기대치가 얼마나 빨리 바뀌는지 놀라움
5년 전만 해도 “AI가 영어 프롬프트로 C 컴파일러를 만든다”는 말은 황당한 농담이었을 것임
HN의 지나친 냉소주의가 이해되지 않음
세 아키텍처를 대상으로 C 컴파일러를 만드는 건 인간에게도 어렵고,
SQLite를 통과하는 수준이라도 주말 프로젝트급 성과로는 대단함
대부분의 기업은 고성능 컴파일러가 아니라 비즈니스 로직용 코드 접착제를 만드는 게 현실임
문제는 기술 자체보다 그걸 사용하는 사람들의 태도에 있음
SQLite에서 158,000배 느린 성능이 핵심임
파싱은 쉬운 문제이고, 진짜 어려운 건 레지스터 할당과 최적화 단계임
GCC와 비교하는 건 무의미하지만, LLM이 이런 컴파일러를 만든 것 자체는 놀라운 일임
다음 목표는 GCC와의 격차를 158,000배에서 100배 수준으로 줄이는 것임
각 반복이 12배 느리면 전체도 12배 느려야 하는데, 158,000배는 오류나 오해로 보임
SQLite 테스트가 실제로 올바르게 실행되는지도 검증이 부족함
그럼에도 성능이 이렇게 낮은 건 의문임
C는 완전히 파싱 가능한 언어가 아니다라는 글을 참고할 만함
“1회 반복 8배 느림이면 10억 번 반복해도 8배 느림일 뿐”이라는 지적처럼,
158,000배라는 수치는 논리적으로 맞지 않음
아마도 레지스터 스필링이 L3 캐시를 압도했거나, 불필요한 코드가 실행되는 버그가 있을 가능성이 있음
C 컴파일러를 만드는 건 인간에게도 어렵지만,
이게 LLM의 지능 증거라고 보긴 힘듦
이미 잘 알려진 문제이고, 수많은 구현과 문서가 학습 데이터에 포함되어 있음
즉, LLM은 새로운 설계를 창조한 게 아니라 기존 패턴을 재조합한 것임
그럼에도 이런 도구는 여전히 유용하며,
진짜 인상적인 건 기존 OSS를 복제하는 게 아니라 새로운 접근법을 제시하는 모델이 나올 때일 것임