Claude의 컴파일러는 흔들렸고, Blitzy는 다시 만들었습니다 — 이것이 2026년 AI 코딩에 시사하는 진짜 의미
AI 코딩은 정말 빠르게 변해왔습니다. 처음에는 개발자를 위한 자동완성 도구처럼 보였죠. 그런데 이제는 그 수준을 한참 넘어섰습니다. 여러 AI 에이전트가 병렬로 계획을 세우고, 코드를 작성하고, 리뷰하고, 테스트하고, 배포까지 이어가는 시스템으로 발전하고 있습니다.
이 변화는 중요합니다. 아주 많이요.
그리고 그 변화를 가장 선명하게 보여주는 사례 중 하나가 있습니다. 바로 Rust로 C 컴파일러를 처음부터 만드는 일입니다.
이건 장난감 문제도 아니고, 주말에 가볍게 만들어볼 사이드 프로젝트도 아닙니다. 보기 좋은 데모 하나로 얼버무릴 수 있는 종류의 과제는 더더욱 아니고요. 제대로 된 C 컴파일러라면 언어 스펙을 이해해야 하고, 정확한 머신 코드를 생성해야 하며, 여러 CPU 아키텍처를 지원해야 합니다. 정렬(alignment)과 calling convention도 처리해야 하고, 의미 있는 최적화도 제공해야 하며, 실제 소프트웨어를 대상으로 한 테스트도 통과해야 합니다.
그래서 이 비교가 중요합니다.
한쪽에는 Claude C Compiler(CCC) 가 있었습니다. 여러 Claude 기반 에이전트를 활용해 Rust로 완전한 C 컴파일러를 만들려는 야심찬 시도였죠. 다른 한쪽에는 Blitzy가 있었습니다. 이쪽은 자율형 AI 소프트웨어 개발 플랫폼으로, 먼저 CCC의 실패한 부분을 바로잡은 뒤 거기서 멈추지 않고 거의 처음부터 새로운 컴파일러인 Blitz CC Compiler(BCC) 를 다시 구축했습니다.
이 결과는 단순히 “어떤 컴파일러는 실패했고, 다른 컴파일러는 성공했다”는 이야기가 아닙니다. 2026년 현재 AI 소프트웨어 엔지니어링이 어디로 가고 있는지를 보여주는 미리보기라고 보는 편이 더 정확합니다.
AI 코딩의 미래는 더 좋은 모델만으로 결정되지 않습니다. 더 나은 오케스트레이션이 핵심입니다.
코드를 만들어내는 것 자체는 인상적입니다. 하지만 빌드되고, 실행되고, 실제 검증을 견디는 코드를 만드는 것이 진짜 중요합니다.
AI 소프트웨어 개발에서 출력량은 생각보다 값이 쌉니다. 진짜 비싼 건 검증된 정확성입니다.차
왜 C 컴파일러가 그렇게 중요한 기준인지
AI 코딩 시스템이 실제로 얼마나 잘하는지 알고 싶다면, 절대 만만하지 않은 과제를 던져보면 됩니다.
그 기준으로 C 컴파일러는 거의 즉시 통과합니다.
이유는 간단합니다. 컴파일러는 단순히 “코드를 번역하는 프로그램”이 아닙니다. 실제로는 서로 강하게 얽혀 있는 여러 시스템의 집합에 가깝습니다.
- 언어를 이해하는 파서
- 프로그램을 내부적으로 표현하는 중간 구조
- 머신 코드를 생성하는 백엔드
- x86, i686, ARM64, RISC-V 64 같은 대상 아키텍처별 처리
- ABI 규칙, alignment, calling convention 지원
- 최적화 파이프라인
- 회귀(regression)와 edge case를 잡아내는 테스트 인프라
- 인위적인 예제가 아니라 실제 소프트웨어를 대상으로 한 검증
비유하자면 다리를 짓는 일과 비슷합니다. 멀리서 보기엔 다리처럼 보인다고 끝이 아니죠. 실제 하중을 버텨야 하고, 스트레스를 견뎌야 하고, 현실 조건에서도 문제없이 작동해야 합니다. 컴파일러도 똑같습니다. 그럴듯해 보인다고 점수를 주지는 않습니다.
바로 그래서 이 비교가 가치가 있습니다. 질문이 단순하지 않기 때문입니다. “AI가 많은 코드를 만들어낼 수 있는가?”를 묻는 게 아닙니다. 훨씬 더 무거운 질문을 던집니다.
AI 에이전트가 실제로 동작하는 복잡한 시스템 소프트웨어를 만들 수 있는가?
Claude C Compiler 실험
Claude C Compiler(CCC) 는 Rust로 완전한 C 컴파일러를 만들기 위한 대규모 AI 에이전트 코딩 프로젝트로 제시됐습니다.
설정부터 상당히 공격적이었습니다. 총 16개의 Claude 기반 에이전트가 협업했고, 목표는 여러 CPU 아키텍처를 지원하는 컴파일러를 만드는 것이었습니다.
- x86
- RISC-V 64
- i686
- ARM64
딱 봐도 스코프가 큽니다. 컴파일러를 바닥부터 만든다는 것 자체가 숙련된 엔지니어에게도 어려운 일입니다. 여기에 여러 아키텍처 타깃까지 붙으면 난도는 더 올라갑니다. 여기에 다시 AI 에이전트를 얹으면 문제는 단순한 코드 생성이 아니라 조정(coordination) 의 영역으로 넘어갑니다.
그 점은 인정해야 합니다. 이 시도 자체의 야심은 분명 의미가 있었습니다.
불과 1년 전만 해도 많은 사람들은 이런 시도를 현실적인 목표라고 보지 않았을 겁니다. AI 에이전트가 이 정도 규모의 시스템에 도전할 수 있었다는 사실만으로도, 에이전트형 코딩이 꽤 멀리 왔다는 걸 보여주니까요. CCC는 가벼운 데모가 아니었습니다. 여러 에이전트가 함께 움직이며 가장 어려운 종류의 소프트웨어 중 하나를 다룰 수 있는지 시험한 실험이었습니다.
그것만으로도 의미는 충분했습니다.
문제는, 커뮤니티가 직접 써보기 시작하면서 드러났습니다.
그리고 그때부터 분위기가 달라졌죠.
CCC는 어디서 무너졌나
서류상으로 보면 CCC는 꽤 그럴듯해 보였습니다. 수백 개의 Commit, 수천 개의 파일, 넓은 아키텍처 타깃, 그리고 컴파일러 리포지토리처럼 보이는 구조까지 갖추고 있었으니까요.
하지만 사람들이 자세히 들여다볼수록 문제가 쏟아졌습니다.
가장 치명적인 문제는 아이러니하게도 가장 쉽게 설명할 수 있는 문제였습니다. 리포지토리 히스토리 어디를 봐도 안정적으로 동작하는 빌드를 만들 수 있는 지점이 없었다는 점입니다. 쉽게 말해 누군가가 프로젝트를 clone해서 빌드해보면, 실제로 쓸 수 있는 컴파일러를 얻지 못했다는 뜻입니다. 심지어 “Hello, World” 같은 가장 기본적인 예제조차 안정적으로 컴파일되지 않았습니다.
이런 실패는 과장된 기대를 단번에 걷어냅니다.
커뮤니티 반응도 강했습니다. 관련 GitHub 이슈에는 대략 500명 수준의 반응이 달렸다고 전해집니다. 이 숫자는 두 가지를 동시에 보여줍니다. 하나는 많은 사람이 이 실험에 관심을 가졌다는 점, 다른 하나는 프로젝트가 내건 약속과 실제 사용성 사이의 간극에 적지 않게 실망했다는 점입니다.
아키텍처와 어셈블러 문제
구체적으로 보고된 구현 문제는 다음과 같았습니다.
- ARM assembler 에 instruction encoding bug 가 있었다
- x86 assembler 에서 조건 처리 로직이 깨져 있었다
- 아키텍처 간 alignment bug 가 존재했다
이건 겉모습만 어색한 수준의 문제가 아닙니다. 컴파일러 백엔드, 즉 의도를 실제 머신 명령으로 바꾸는 마지막 핵심 구간을 정면으로 건드리는 문제입니다.
이해를 돕자면, 길 안내를 아주 그럴듯하게 해주는 GPS 앱을 떠올리면 됩니다. 인터페이스도 멀쩡하고 목적지도 정확해 보입니다. 그런데 마지막 안내가 존재하지 않는 도로로 보내버린다면 어떨까요? 보는 순간까지는 괜찮아 보여도, 정작 가장 중요한 순간에 시스템은 실패합니다.
어셈블러와 아키텍처 관련 버그가 딱 그런 종류입니다. 마지막 1마일을 무효화해버리거든요.
언어 지원의 공백과 최적화 부재
CCC에는 C11 지원의 일부가 빠져 있다는 지적도 있었습니다.
이건 꽤 중요합니다. C 컴파일러의 신뢰도는 결국 언어 표준을 얼마나 제대로 처리하느냐에 달려 있으니까요. 자잘한 edge case 몇 개가 비어 있는 것과, 표준의 의미 있는 덩어리가 통째로 빠져 있는 것은 차원이 다릅니다. 후자는 실제 사용 관점에서 컴파일러를 근본적으로 미완성 상태로 만들어버립니다.
여기에 더해 CCC에는 의미 있는 최적화 파이프라인도 없었다고 평가됐습니다.
이 말은 단순히 “느리다”는 뜻이 아닙니다. 컴파일러의 성숙도를 가르는 중요한 층위가 비어 있었다는 의미에 가깝습니다. 좋은 컴파일러는 입력을 출력으로만 바꾸지 않습니다. 정확성을 유지하면서도 더 나은 머신 코드를 만들어냅니다. 그런데 최적화 단계가 사실상 없다면, 그 프로젝트는 완성된 컴파일러라기보다 구조만 잡아놓은 초안에 더 가깝습니다.
테스트 인프라의 문제
가장 본질적인 약점은 어쩌면 이 부분이었을지도 모릅니다. 탄탄한 테스트 인프라가 없었다는 점입니다.
대형 컴파일러 프로젝트에는 보통 이런 것들이 필요합니다.
- Unit test
- Integration test
- Regression test
- 아키텍처별 검증
- 실제 소프트웨어를 대상으로 한 빌드 및 실행 확인
이런 체계가 없으면 코드 생성은 위험한 환상이 됩니다. 아주 많은 코드를 빠르게 만들 수는 있죠. 하지만 그 코드가 정말 맞는지 확인할 믿을 만한 방법은 없게 됩니다.
CCC 사례는 바로 그 점을 적나라하게 보여줬습니다.
AI 에이전트는 scaffold를 빠르게 만들어내는 데는 꽤 강합니다. 반면, 자신이 만든 결과물의 실패를 지속적으로 감지하고, 원인을 이해하고, 다시 교정하는 루프를 강한 검증 체계 없이 스스로 굴리는 데는 훨씬 약합니다.
숨겨진 비용: 사람 의존도가 높았다는 점
CCC에서 얻을 수 있는 가장 중요한 교훈 중 하나는 문법이나 백엔드, 벤치마크와는 조금 다른 곳에 있습니다. 바로 사람의 노동입니다.
CCC는 완전히 자급자족하는 에이전트 군집처럼 작동하지 않았습니다. 대신 한 명의 선임 연구자에게 크게 의존했습니다. 이 연구자는 2,000회가 넘는 상호작용 턴을 기록한 것으로 전해집니다.
그리고 이 사람은 하나의 좁은 역할만 맡은 게 아니었습니다. 사실상 다음 역할을 동시에 수행한 셈입니다.
- 아키텍트
- 프롬프트 엔지니어
- 문맥 관리자
- 디버거
- 테스트 작성자
- Merge conflict 해결자
- QA 책임자
- 프로젝트 매니저
- 에이전트 조정자
이 차이는 아주 중요합니다.
분명 에이전트들은 많은 코드를 만들어냈습니다. 하지만 그들이 스스로 계획하고, 검증하고, 고치고, 다시 확인하는 안정적인 폐쇄 루프를 대규모로 형성한 것은 아니었습니다. 시스템이 계속 굴러가기 위해서는 숙련된 인간이 어려운 조정 작업을 떠안아야 했습니다.
이 사실이 말해주는 건 명확합니다.
지금 세대의 AI 코딩 시스템은 큰 구조물을 만드는 데는 강하지만, 정확성의 루프를 혼자서 끝까지 닫는 데는 아직 약합니다.
더 쉽게 말하면 이렇습니다. 집의 골조는 세울 수 있습니다. 하지만 배관이 제대로 연결됐는지, 전선이 안전한지, 문이 정말 열리는지는 아직 사람이 확인해줘야 합니다.
그럼에도 CCC가 여전히 중요한 이유
CCC를 그냥 실패 사례 하나로만 보는 건 쉬운 일입니다.
하지만 그렇게 보면 핵심을 놓치게 됩니다.
CCC는 여전히 의미 있는 사실을 보여줬습니다. AI 에이전트가 이제는 얼마 전까지만 해도 비현실적으로 보였을 정도의 대형, 다단계 엔지니어링 작업에 참여할 수 있다는 점입니다. 여러 아키텍처를 대상으로 실제 컴파일러에 가까운 형태를 절반 이상이라도 만들어냈다는 사실만으로도, 에이전트형 코딩이 훨씬 더 본격적인 영역으로 들어섰다고 볼 수 있습니다.
이게 중요한 이유는, AI 소프트웨어 엔지니어링의 발전이 늘 직선형은 아니기 때문입니다. 때로는 “실패한 실험”이 오히려 다음 단계의 가능성을 증명합니다.
CCC는 AI 에이전트가 복잡한 시스템 프로젝트의 형태를 만들어낼 수 있다는 걸 보여줬습니다. 동시에 그 형태만으로는 충분하지 않다는 점도 똑같이 선명하게 보여줬고요.
불편하지만 유용한 구분입니다.
그래서 엔지니어링 리더, 연구자, 개발자 입장에서 CCC는 “부분적인 가능성의 증명”이자 “불완전한 자율성에 대한 경고”로 읽는 편이 가장 적절합니다.
Blitzy는 무엇이 달랐나
Blitzy는 전형적인 AI 코딩 도구와는 꽤 다른 위치를 잡고 있습니다.
그저 또 하나의 LLM 인터페이스로 자신을 설명하지도 않고, 가벼운 “바이브 코딩” 도구처럼 포장하지도 않습니다. 개발자가 하루 종일 터미널 앞에 앉아 에이전트의 액션을 하나씩 승인하거나 거절하는 방식으로 설계된 도구도 아닙니다.
대신 Blitzy는 스스로를 완전 자율형 AI 소프트웨어 개발 플랫폼에 가깝게 설명합니다.
말로만 들으면 조금 추상적으로 느껴질 수 있습니다. 그런데 구조를 뜯어보면 왜 다른지 바로 보입니다.
핵심 아이디어는 이렇습니다. 모델을 불완전한 문맥 상태로 코드베이스에 던져 넣고 즉흥적으로 작업하게 하는 대신, 먼저 전체 시스템에 대한 깊은 이해를 구축합니다. 그 위에서 수천 개의 특화된 AI 에이전트를 조직해 계획, 구현, 테스트, 검증을 병렬로 수행합니다.
철학 자체가 다릅니다.
기존 AI 코딩이 계속 지켜봐야 하는 똑똑한 견습생 같았다면, Blitzy는 코드베이스를 먼저 학습하고, 일을 나누고, 서로 확인하고, 꽤 큰 결과물을 들고 돌아오는 하나의 엔지니어링 조직처럼 움직이려 합니다.
이 방식이 모든 곳에서 항상 이길 거라고 단정할 수는 없습니다. 하지만 확실히 다른 모델인 건 분명합니다.
Blitzy는 실제로 어떻게 동작하나
1) 먼저 전체 코드베이스를 이해합니다
Blitzy는 우선 코드베이스 전체를 매핑하고, 시스템의 동적 지식 그래프(dynamic knowledge graph) 를 만든다고 설명합니다.
여기에는 다음 요소들이 포함됩니다.
- 의존성
- 아키텍처 구조
- 기존 패턴
- 관례
- 코드베이스 전반의 구조적 관계
쉽게 말하면, 코드를 쓰기 전에 시스템 전체를 머릿속에 그리는 큰 지도를 먼저 만든다고 보면 됩니다.
비유를 하나 들어볼게요. 집 리모델링을 맡긴다고 했을 때, 어떤 시공사는 대충 둘러보고 바로 망치를 듭니다. 반면 어떤 시공사는 설계도, 배선, 배관, 기초 구조, 하중이 걸리는 벽까지 한참 들여다본 뒤에야 손을 대죠. 두 번째 방식은 시작은 느릴 수 있습니다. 하지만 집을 망가뜨릴 확률은 훨씬 낮습니다.
Blitzy는 후자를 지향합니다.
이 단계는 “infinite code context” 라고도 설명됩니다. 제공된 내용에 따르면 1억 줄이 넘는 코드베이스도 다룰 수 있다고 합니다. 물론 대가가 있습니다. 이 과정은 즉시 끝나지 않습니다. 깊은 수준의 문맥을 만드는 데 몇 시간에서 며칠이 걸릴 수 있고, 결과물은 수백 페이지짜리 문서가 되기도 합니다.
중요한 건 이 지연이 결함이 아니라는 점입니다. 오히려 그게 이 워크플로의 핵심입니다.
2) 수천 개의 특화 에이전트를 오케스트레이션합니다
시스템을 이해한 다음에는 Blitzy가 대규모의 특화 AI 에이전트 네트워크를 가동합니다.
이 에이전트들은 계획, 구현, 리뷰, 검증을 병렬로 처리합니다. 작업 시간도 짧지 않습니다. 빠르면 5시간, 복잡한 작업은 3~4일까지 이어질 수 있다고 설명됩니다.
제공된 자료에 따르면 이 플랫폼은 한 번의 실행으로 최대 50,000줄의 코드를 생성할 수 있으며, 사용자가 몇 분마다 개입할 필요가 없습니다.
이건 많은 개발자에게 익숙한 AI 코딩 경험과는 상당히 다릅니다. 보통은 IDE를 열고, 모델에 프롬프트를 주고, 결과를 확인하고, 승인하거나 반려하고, 다시 시도하고, 패치를 반복하죠.
Blitzy의 모델은 그보다는 상세한 프로젝트 명세서를 제출한 뒤, 큰 가상 엔지니어링 조직이 그걸 바탕으로 실행하는 방식에 더 가깝습니다.
3) 내부 리뷰 루프가 내장돼 있습니다
여기서 중요한 포인트 하나가 더 있습니다. Blitzy는 자신을 단순한 코드 생성기로 설명하지 않습니다. 코드가 전달되기 전에 여러 QA 에이전트가 서로의 작업을 리뷰하는 구조를 갖고 있다고 합니다.
이건 정말 중요합니다. 검증 없는 생성이야말로 에이전트형 시스템이 가장 자주 무너지는 지점이기 때문입니다.
워크플로는 대략 이렇게 이해하면 됩니다.
- 시스템을 깊이 이해한다
- 병렬로 생성한다
- 내부 리뷰를 수행한다
- 문제를 수정한다
- 다시 검증한다
- 결과를 전달한다
즉, 품질을 나중에 사람이 뒤처리하는 대상으로 두는 것이 아니라, 처음부터 품질 루프를 프로세스에 내장하려는 접근입니다.
4) 개발 생애주기 전체를 포괄합니다
Blitzy는 단순히 코딩만 하는 플랫폼으로 설명되지 않습니다. 범위가 더 넓습니다.
- 요구사항
- 설계
- 코드
- 테스트
- Pull Request
이런 end-to-end 흐름은 중요한 차별점입니다. 가치는 단순히 “더 빨리 코드 쓰기”에 있지 않고, 명세에서 검증까지 이어지는 흐름의 연속성에 있다는 뜻이기도 하니까요.
5) 벤치마크 신뢰도도 강조합니다
Blitzy는 Sweet Bench Pro에서 66.5% 점수를 기록했다고 제시됩니다. 이 평가는 독립적으로 감사된 것으로 설명되며, 해당 프레임에서는 AI 플랫폼, 도구, LLM 기반 개발 시스템 전반을 통틀어 최고 수준, 혹은 최고 점수권으로 소개됩니다.
정확히 어떤 벤치마크냐보다 중요한 건, 이 수치가 의미하는 방향입니다. 개별 모델의 출력 품질보다는 플랫폼 수준의 성능, 즉 문맥 이해, 병렬 실행, 검증 루프를 결합한 전체 시스템 역량에 초점을 맞추고 있다는 점입니다.
Blitzy 워크플로를 단계별로 보면
왜 컴파일러 결과가 এত 극적으로 갈렸는지 이해하려면, 이 접근을 단계별로 보는 편이 좋습니다.
1단계: 전체 코드베이스를 수집하고 해석합니다
목적: 문맥 충돌과 즉흥적인 저품질 생성을 줄이기 위해서입니다.
작동 방식: 전체 코드베이스를 분석해 구조화된 지식 그래프와 대규모 문맥 문서로 변환합니다.
왜 중요한가: 생성되는 코드가 기존 패턴과 아키텍처 규칙을 훨씬 더 잘 따르게 됩니다.
2단계: 상세한 명세를 입력합니다
목적: 실행 전에 모호성을 줄이기 위해서입니다.
작동 방식: 사용자는 목표, 제약 조건, 품질 기준, 플랫폼 기대치를 담은 길고 구체적인 프롬프트를 제공합니다.
왜 중요한가: 장시간 자율 실행에서는 애매한 요구사항 하나가 큰 비용의 실수로 불어날 수 있습니다.
3단계: 수천 개의 에이전트를 병렬로 오케스트레이션합니다
목적: 계획, 구현, 디버깅, 검증을 동시에 확장하기 위해서입니다.
작동 방식: 역할이 다른 에이전트들을 각 워크스트림에 배정합니다.
왜 중요한가: 속도는 단순 출력량이 아니라 조정의 품질에서 나옵니다.
4단계: 여러 QA 에이전트로 교차 검증합니다
목적: 결과물을 전달하기 전에 오류를 잡기 위해서입니다.
작동 방식: 리뷰 에이전트가 빌드 에이전트의 작업을 검사해 내부 수정 루프를 만듭니다.
왜 중요한가: 이 단계가 없으면 대규모 생성은 대규모 실패로 이어질 수 있습니다.
5단계: 산출물을 통합하고 최종 결과로 정리합니다
목적: 생성된 결과를 실제로 사용할 수 있는 형태로 바꾸기 위해서입니다.
작동 방식: 코드, 테스트, 문서, PR을 통합하고, 환경별 최종 조정이 필요할 때만 사람이 개입합니다.
왜 중요한가: 자율성이 높아도 마지막 호환성 확인과 품질 마감은 여전히 중요합니다.
Blitzy는 CCC를 어떻게 고쳤나
Blitzy는 자기 컴파일러를 새로 만들기 전에 먼저 기존 CCC 리포지토리를 받아서 수리 대상으로 다뤘습니다.
이건 꽤 중요한 포인트입니다. 이미 망가진 시스템을 고치는 일은, 새 시스템을 만드는 것과는 다릅니다. 기존 구조, 기존 실수, 기존 아키텍처 제약을 떠안고 시작해야 하니까요.
제공된 내용에 따르면 Blitzy는 다음과 같은 작업을 수행했습니다.
- CCC 리포지토리를 흡수했다
- 기존 아키텍처를 중심으로 지식 그래프를 만들었다
- 치명적인 회귀 문제를 식별하고 수정했다
- 커뮤니티가 지적한 주요 이슈를 해결했다
여기에는 앞서 언급한 핵심 문제가 포함됩니다.
- ARM assembly encoding bug
- x86 조건 처리 문제
- 원래 빌드의 다른 핵심 결함들
무엇이 수정됐나
제공된 자료 기준으로, Blitzy는 13개의 치명적인 P0 regression 을 수정했습니다.
이건 작은 정리 작업이 아닙니다. P0는 최우선 치명도에 해당하는 회귀 이슈입니다. 즉, 핵심 기능을 직접 깨뜨리는 문제라는 뜻이죠.
Blitzy는 여기에 더해 실제 계층형 최적화 파이프라인도 추가했습니다. 예시로는 다음이 언급됩니다.
- Loop unrolling
- Tail-call optimization
그리고 검증 결과가 뒤따랐습니다.
- 753개 중 753개 Unit test 통과
- 모든 Integration test 통과
- 동작하는 컴파일러 빌드 확보
바로 여기서 이야기의 결이 바뀝니다. “겉으로만 컴파일러처럼 보이는 AI 생성 코드”의 이야기가 아니라, 크고 불안정한 scaffold를 실제 검증을 통과하는 시스템으로 끌어올린 사례가 되기 때문입니다.
품질 차이가 분명하게 드러나는 지점입니다.
BCC는 어떻게 처음부터 다시 만들어졌나
망가진 프로젝트를 고치는 것도 성과입니다.
하지만 컴파일러를 처음부터 다시 만드는 건 완전히 다른 종류의 성과입니다.
Blitzy는 CCC를 고친 뒤 거기서 멈추지 않고, Blitz CC Compiler(BCC) 라는 새로운 컴파일러를 만들었다고 설명됩니다.
이 시도가 중요한 이유는 간단합니다. 성공의 근거를 “기존 기반을 고쳐서 그렇다”는 말로 축소할 수 없게 만들기 때문입니다. 처음부터 다시 만든다는 건, 오케스트레이션된 에이전트 시스템이 구조와 구현, 검증 체계까지 스스로 세울 수 있는지 묻는 더 깊은 테스트이기도 합니다.
제공된 자료에 따르면, 이 질문에 대한 답은 “그렇다”였습니다.
놀라운 부분: 사람 프롬프트는 단 두 번
BCC 전체 작업에는 사람의 프롬프트가 단 2회만 사용됐다고 설명됩니다.
- 빌드를 시작하기 위한 초기 프롬프트
- Linux 검증에 맞게 PR을 정리하기 위한 최종 보정 프롬프트
이건 CCC의 2,000회가 넘는 상호작용 턴과 비교하면 굉장히 큰 차이입니다.
물론 이 말이 “사람이 전혀 관여하지 않았다”는 뜻은 아닙니다. 초기 명세의 품질은 여전히 매우 중요합니다. 다만 그 사람은 더 이상 상시로 붙어 있는 인터랙티브 컨트롤러 역할을 하지 않았다는 뜻입니다.
그 책임의 상당 부분을 오케스트레이션 레이어가 흡수한 셈이죠.
BCC가 만들어낸 결과
BCC에 대해 보고된 결과는 다음과 같습니다.
- Rust 코드 229,983줄
- 소스 파일 129개
- 테스트 2,271개
- 실패한 테스트 0개
- 경고 0건
- 포맷 차이 0건
- 외부 Rust dependency 0개
아키텍처 타깃도 CCC와 비슷한 범위를 유지했습니다.
- x86
- i686
- ARM64
- RISC-V 64
이 부분이 중요한 이유는, 작업 범위를 편하게 줄인 결과가 아니라는 점을 보여주기 때문입니다. 비교 가능한 수준의 난도를 그대로 유지하고 있었던 거죠.
BCC는 무엇으로 검증됐나
가장 강한 주장은 코드 줄 수가 아니었습니다. 실사용 검증이었습니다.
제공된 내용에 따르면 BCC는 다음 소프트웨어들을 성공적으로 컴파일했습니다.
- SQLite
- Redis
- Lua
- QuickJS
- zlib
그리고 가장 인상적인 지점은, Linux kernel을 컴파일하고 실제로 부팅까지 성공했다는 점입니다.
이건 대화의 레벨을 바꿉니다.
“AI가 만든 코드베이스다”라고 주장하는 건 누구나 할 수 있습니다. 하지만 Linux kernel 빌드와 부팅처럼 까다로운 현실 검증을 버텨내는 주장은 아무나 할 수 없습니다.
진짜 봐야 할 숫자들
핵심 수치만 한 번에 정리해보겠습니다.
Claude C Compiler (CCC)
- Claude 에이전트 16개
- 수백 개의 Commit
- 수천 개의 파일
- 타깃 아키텍처: x86, RISC-V 64, i686, ARM64
- 2,000회 이상 사람의 상호작용 턴 필요
- 리포지토리 어느 시점에서도 안정적으로 동작하는 빌드를 제공하지 못한 것으로 보고됨
- 핵심 GitHub 이슈에 대략 500건 수준의 반응
CCC의 주요 문제
- ARM assembler의 instruction encoding bug
- x86 assembler의 조건 처리 실패
- 아키텍처 간 alignment bug
- C11 지원 일부 누락
- 의미 있는 최적화 파이프라인 부재
- 약하거나 불충분한 테스트 인프라
Blitzy 플랫폼의 역량
- 1억 줄을 넘는 코드베이스 처리 가능
- 깊은 문맥 형성에 수시간~수일 소요 가능
- 수백 페이지에 달하는 시스템 이해 문서 생성
- 한 번의 실행으로 최대 50,000줄의 코드 생성 가능
- Sweet Bench Pro 66.5% 기록
Blitzy가 수리한 CCC 결과
- P0 regression 13개 수정
- 753 / 753 Unit test 통과
- 모든 Integration test 통과
- Loop unrolling, Tail-call optimization 을 포함한 실제 최적화 파이프라인 추가
Blitz CC Compiler (BCC)
- 사람 프롬프트 2회로 구축
- 3,600개의 자율 에이전트 조정
- 624시간 분량의 병렬 엔지니어링 작업
- 실제 실행 시간으로는 약 4.5일
- Rust 코드 229,983줄
- 소스 파일 129개
- 테스트 2,271개 전부 통과
- 경고 0건
- 포맷 차이 0건
- 외부 Rust dependency 0개
- SQLite, Redis, Lua, QuickJS, zlib 컴파일 성공
- Linux kernel 컴파일 및 부팅 성공
- 다른 AI 생성 컴파일러 시도와 비교했을 때 22개 측정 항목 중 15개 항목 우위로 보고됨
이 비교가 왜 정말 중요한가
이걸 컴파일러 덕후들만 좋아할 이야기라고 넘기고 싶을 수도 있습니다.
그건 오히려 잘못된 해석에 가깝습니다.
진짜 핵심은 컴파일러 자체가 아닙니다. 컴파일러는 스트레스 테스트일 뿐입니다. 더 본질적인 질문은 이 사례가 차세대 소프트웨어 개발 방식에 대해 무엇을 말해주느냐입니다.
가장 단순하게 정리하면 이렇습니다.
- CCC는 AI 에이전트가 거대한 엔지니어링 과제에 도전할 수 있음을 보여줬습니다
- BCC는 그런 도전이 실제로 동작하는 시스템이 되느냐를 결정하는 건 오케스트레이션 품질이라는 점을 시사했습니다
이 차이는 큽니다. 정말 큽니다.
지난 몇 년 동안 AI 코딩에 대한 대화는 대개 베이스 모델 중심이었습니다.
- 어떤 모델이 더 깔끔한 코드를 쓰는가?
- 어떤 모델이 지시를 더 잘 따르는가?
- 어떤 모델이 hallucination이 더 적은가?
물론 여전히 중요한 질문입니다. 하지만 이제는 그것만으로 충분하지 않습니다.
이제 더 중요한 질문은 이런 쪽에 가깝습니다.
- 시스템은 문맥을 어떻게 구축하는가?
- 몇 개의 에이전트를 의미 있게 조정할 수 있는가?
- 스스로를 어떻게 테스트하는가?
- 회귀를 어떻게 감지하는가?
- 어느 정도의 사람 감독이 필요한가?
- 합성 벤치마크가 아니라 실제 소프트웨어로 검증할 수 있는가?
지금 frontier는 바로 여기에 있습니다.
이 사례가 개발자와 엔지니어링 팀에 주는 의미
개발자든, Staff Engineer든, Engineering Manager든, CTO든 이 사례에서 가져갈 수 있는 실무적 교훈이 몇 가지 있습니다.
1) 코드 출력이 많다고 더 좋은 소프트웨어는 아닙니다
2026년에 AI 도구를 평가하는 팀이라면, 이게 아마 가장 중요한 포인트일 겁니다.
코드를 아주 빠르게 많이 생성하는 도구도 충분히 취약한 시스템을 만들 수 있습니다. 오히려 팀이 검토하기도 전에 더 빠르게 취약한 코드를 양산할 수도 있습니다.
AI 워크플로에 강한 테스트, 리뷰 루프, 시스템 수준 검증이 없다면 속도는 장점이 아니라 함정이 될 수 있습니다.
2) 이제는 프롬프트보다 ‘문맥 설계’가 더 중요한 역량이 됩니다
예전에는 개발자들이 주로 프롬프트 자체를 중요하게 생각했습니다. 하지만 점점 더 중요한 건 context design, 즉 문맥 설계에 가까워지고 있습니다.
여기에는 이런 요소들이 포함됩니다.
- 문제를 명확하게 정의하기
- 정확한 아키텍처 제약 전달하기
- 품질 기준 정하기
- 시스템이 코드를 쓰기 전에 코드베이스를 제대로 이해하도록 만들기
즉, AI 코딩의 좋은 결과는 기발한 프롬프트 한 줄보다도, 규율 있는 준비 과정에서 나올 가능성이 점점 커지고 있습니다.
3) 길게 달리는 자율 워크플로가 반복적인 상호작용보다 나을 수 있습니다
인터랙티브 AI 코딩이 사라지는 건 아닙니다. 작은 기능 추가, 단발성 디버깅, 로컬 리팩토링, API scaffold 생성 같은 작업은 여전히 잘 맞습니다.
하지만 더 큰 과제에서는 이 사례가 새로운 가능성을 보여줍니다. 깊은 문맥을 깔아놓고 장시간 자율적으로 실행되는 다중 에이전트 워크플로가, 기존의 “프롬프트 → 확인 → 승인 → 재시도” 루프보다 나을 수 있다는 겁니다.
특히 이런 분야에서 의미가 큽니다.
- 큰 레거시 시스템
- 멀티 서비스 플랫폼
- 인프라 코드
- 시스템 프로그래밍
- 상호 의존성이 깊은 엔터프라이즈 소프트웨어
4) 사람의 역할은 사라지는 게 아니라 바뀌고 있습니다
이 비교가 “이제 소프트웨어 엔지니어는 필요 없다”는 뜻은 아닙니다.
오히려 더 현실적인 해석은 이렇습니다. 사람의 역할이 바뀌고 있습니다.
이제 인간은 생성된 모든 변경 사항을 계속 따라다니며 미세 조정하는 관리자라기보다, 점점 더 다음 역할에 가까워질 수 있습니다.
- 명세 작성자
- 아키텍처 책임자
- 품질 게이트키퍼
- 최종 검증 권한자
여전히 대단히 중요한 역할입니다. 다만 일의 종류가 달라지는 것에 가깝습니다.
핵심 개념을 쉽게 풀어보면
에이전트형 코딩
무엇인가요: 여러 AI 에이전트가 서로 다른 소프트웨어 작업을 나눠 맡고 함께 일하는 방식입니다.
왜 중요한가요: 하나의 모델이 모든 걸 하려는 대신, 역할 분화와 병렬 실행이 가능해집니다.
무엇이 성패를 가르나요: 모델 성능만이 아니라 조정 구조와 검증 체계가 함께 결정합니다.
동적 지식 그래프
무엇인가요: 코드베이스가 어떻게 맞물려 있는지를 구조적으로 표현한 지도입니다. 파일, 모듈, 의존성, 패턴, 관계가 포함됩니다.
왜 중요한가요: 짧은 프롬프트만으로는 얻기 어려운 풍부한 문맥을 AI에 제공합니다.
실무적 가치: 문맥이 좋아질수록 깨진 가정도 줄어드는 경우가 많습니다.
infinite code context
무엇인가요: 아주 큰 코드베이스를 조각조각이 아니라 전체적으로 이해하도록 설계된 체계입니다.
왜 중요한가요: 복잡한 시스템은 보통 한 줄 때문에 망가지지 않습니다. 다른 곳의 숨은 가정과 충돌하면서 무너집니다.
실무적 가치: 초기에 문맥을 더 많이 쌓으면, 뒤쪽의 혼란을 줄일 수 있습니다.
Scaffold
무엇인가요: 겉으로는 시스템처럼 보이지만 아직 production-ready는 아닌 구조적 코드입니다.
왜 중요한가요: AI는 scaffold를 빠르게 만드는 데 강한 경우가 많습니다.
위험한 점: 팀이 scaffold를 완성된 소프트웨어로 착각할 수 있습니다.
최적화 파이프라인
무엇인가요: 컴파일 과정에서 정확성을 유지하면서도 머신 코드 성능을 개선하는 단계들의 연속입니다.
예시: Loop unrolling, tail-call optimization
왜 중요한가요: 의미 있는 최적화가 없는 컴파일러는, 파싱이 가능하더라도 성숙한 컴파일러라고 보기 어렵습니다.
P0 regression
무엇인가요: 핵심 기능을 깨뜨리는 최우선 치명도 회귀 이슈입니다.
왜 중요한가요: 이런 문제는 “나중에 보자”가 아니라 당장 멈추고 고쳐야 하는 종류입니다.
이 사례에서는: Blitzy가 기존 컴파일러 시도에서 13개를 수정했다고 설명됩니다.
한계와 불편한 진실
이 이야기는 분명 인상적입니다. 동시에 과하게 읽기 쉬운 사례이기도 합니다.
그래서 조금은 신중해야 합니다.
AI 자율성은 아직 조건부입니다
더 나은 결과가 나온 경우에도 사람이 완전히 사라진 것은 아닙니다. 시스템은 여전히 높은 품질의 초기 명세와, 최소한 한 번의 Linux 검증용 최종 조정에 의존했습니다.
2,000번 넘는 상호작용에 비하면 아주 작아 보일 수 있습니다. 실제로도 그렇습니다. 하지만 그럼에도 사람의 역할이 완전히 없어졌다고 말할 수는 없습니다.
모든 프로젝트에 이런 수준의 오케스트레이션이 필요한 건 아닙니다
장시간 실행되는 다중 에이전트 플랫폼이 모든 엔지니어링 작업의 정답은 아닙니다.
예를 들어 이런 작업이라면:
- 간단한 유틸리티 함수 작성
- 작은 버그 하나 수정
- API boilerplate 생성
- 작은 내부 도구 만들기
이런 경우에는 가벼운 인터랙티브 보조 도구가 더 빠르고 실용적일 수 있습니다.
무거운 오케스트레이션에는 셋업 비용이 있습니다. 그리고 그 비용은 문제가 충분히 클 때만 정당화됩니다.
컴파일러 수준의 검증은 특수한 환경입니다
컴파일러는 AI 생성 코드가 들어갈 수 있는 환경 중에서도 가장 가혹한 축에 속합니다. 정확성은 타협할 수 없고, 검증 요구 수준도 매우 높기 때문입니다.
그래서 좋은 벤치마크이긴 하지만, 동시에 꽤 특수한 벤치마크이기도 합니다.
여기서 잘하는 시스템이 모든 영역에서 똑같이 강하다고 볼 수는 없습니다. 반대로 여기서 약한 시스템이 제품 개발, 프론트엔드 작업, 내부 툴링에서는 아주 유용할 수도 있습니다.
즉, 교훈은 “한 가지 아키텍처가 모든 곳에서 이긴다”가 아닙니다. 진짜 교훈은 이겁니다.
검증 부담이 큰 영역일수록 AI 코딩 시스템의 진짜 강점과 약점이 훨씬 더 빨리 드러난다.
AI 코딩의 더 큰 변화
사실 대부분의 사람들이 주목해야 할 부분은 여기입니다.
이제 AI 생성 소프트웨어는 더 이상 “누가 가장 똑똑한 챗봇을 갖고 있느냐”의 경쟁만은 아닙니다. 점점 더 모델 주변의 실행 환경(execution environment) 을 누가 더 잘 만들었느냐의 경쟁으로 바뀌고 있습니다.
여기에는 이런 것들이 포함됩니다.
- 장기 메모리와 문맥 유지
- 대규모 코드베이스에 대한 깊은 이해
- 다중 에이전트 역할 분화
- 리뷰와 QA 루프
- 테스트 인프라
- 회귀 처리
- 실사용 검증 파이프라인
- 항상 붙어 있는 감독이 아니라, 필요한 순간에만 들어가는 사람의 개입
이건 굉장히 큰 변화입니다.
초기의 AI 코딩 시대에는 많은 팀이 “5분 써보니 느낌이 좋다”를 기준으로 도구를 평가하곤 했습니다. 하지만 2026년의 더 의미 있는 기준은 이것에 가깝습니다. 이 시스템이 며칠 단위의 자율 엔지니어링 작업을 자기 출력에 무너지지 않고 견딜 수 있는가?
이 비교가 가리키는 방향은 꽤 분명합니다.
이제 모델 자체만큼이나, 어쩌면 그 이상으로 중요한 것은 모델을 감싸는 harness입니다.
왜 이제는 실사용 검증이 새로운 기준이 되는가
여기서 한 가지를 더 분명히 해둘 필요가 있습니다.
이제는 “AI가 엄청 많은 코드를 썼다”는 사실만으로 진지한 엔지니어를 설득하기 어려운 시대에 들어가고 있습니다.
새로운 기준은 이런 질문들에 더 가깝습니다.
- 리포지토리가 깔끔하게 빌드되는가?
- 실제 프로그램을 컴파일할 수 있는가?
- 테스트가 통과하는가?
- Integration check를 버티는가?
- 널리 쓰이는 소프트웨어 스택을 처리할 수 있는가?
- Linux kernel만큼 까다로운 대상을 지원할 수 있는가?
이 기준이 훨씬 건강합니다.
그리고 팀 내부에서도 이 기준을 가져가는 편이 좋습니다. AI가 생성한 코드를 평가할 때는 단지 빨리 만들어졌는지만 보지 말고, 현실과 부딪혔을 때 살아남는지를 봐야 합니다.
진실은 보통 거기서 드러납니다.
마무리하며
Claude C Compiler(CCC) 와 Blitz CC Compiler(BCC) 의 비교는, 단순히 한 컴파일러가 실패하고 다른 컴파일러가 성공했다는 이야기가 아닙니다.
이건 소프트웨어 개발의 미래를 보여주는 하나의 사례 연구에 가깝습니다.
CCC는 AI 에이전트가 대형 엔지니어링 작업에 의미 있게 참여할 수 있다는 점을 보여줬습니다. 동시에 강한 검증, 깊은 문맥 관리, 높은 수준의 사람 감독이 없으면 그런 시도가 scaffold 수준에서 멈출 수 있다는 점도 보여줬습니다.
반면 Blitzy가 제시한 CCC 수리 결과와 독립적인 BCC 구축 결과는 조금 더 큰 가능성을 시사합니다. 깊은 코드베이스 이해, 수천 개 에이전트의 병렬 실행, 내장형 QA 루프, 장시간 자율 실행 창 같은 오케스트레이션 프레임워크가 갖춰지면, AI 시스템이 까다로운 영역에서도 production-quality 소프트웨어에 훨씬 더 가까이 갈 수 있다는 것입니다.
그렇다고 해서 어려운 문제가 다 해결됐다는 뜻은 아닙니다. 다만 무게중심이 분명히 이동했다는 뜻은 됩니다.
다음 세대의 AI 코딩은 단순한 자동완성으로 정의되지 않을 겁니다. 더 많이 이해하고, 더 잘 조정하고, 더 집요하게 검증하고, 사람의 상시 개입을 덜 필요로 하는 시스템으로 정의될 가능성이 큽니다.
그리고 이 비교가 맞다면, 그 변화는 이미 시작됐습니다.
FAQ
1) CCC와 BCC 비교에서 얻을 수 있는 가장 큰 교훈은 무엇인가요?
가장 큰 교훈은 AI 코딩의 성공 여부가 베이스 모델만이 아니라 오케스트레이션에 크게 좌우된다는 점입니다. 큰 코드베이스를 생성하는 것과, 실제로 빌드되고 테스트를 통과하며 현실 환경에서 동작하는 코드베이스를 만드는 것은 전혀 다른 문제입니다.
2) 왜 C 컴파일러가 AI 에이전트의 중요한 벤치마크가 되나요?
컴파일러는 제대로 만들기 매우 어려운 소프트웨어이기 때문입니다. 언어 파싱, 머신 코드 생성, 아키텍처별 동작, 최적화, 광범위한 테스트까지 모두 포함됩니다. 즉, AI가 진지한 시스템 프로그래밍을 감당할 수 있는지를 보기 좋은 강한 스트레스 테스트입니다.
3) CCC는 완전히 실패한 건가요?
그렇게 단정하기는 어렵습니다. CCC는 AI 에이전트가 복잡하고 큰 규모의 소프트웨어 프로젝트에 참여할 수 있다는 점을 보여줬습니다. 다만 한계는 분명했습니다. 강한 사람의 개입 없이, 안정적으로 동작하고 검증된 컴파일러를 지속적으로 만들어내지 못했다는 점이 핵심입니다.
4) Blitzy의 접근은 무엇이 달랐나요?
Blitzy는 깊은 코드베이스 이해, 동적 지식 그래프, 다중 에이전트 병렬 실행, 내부 QA 루프를 핵심으로 삼았습니다. 사람이 계속 옆에서 주고받는 방식 대신, 초기에 문맥을 충분히 쌓아두고 대규모 에이전트 시스템이 장시간 자율적으로 작업하도록 설계된 점이 차별점입니다.
5) 그럼 이제 AI가 소프트웨어 엔지니어를 대체할 수 있다는 뜻인가요?
아니요. 오히려 엔지니어의 역할이 명세, 아키텍처, 검증, 품질 관리 중심으로 이동하고 있다는 해석이 더 맞습니다. 목표를 정의하고, 결과를 검토하고, 실제 환경에서 소프트웨어의 정확성을 보장하는 일은 여전히 사람의 몫입니다.
6) 장시간 자율 실행형 AI 워크플로가 항상 더 좋은가요?
그렇지는 않습니다. 더 작고 단순한 작업에서는 인터랙티브 AI 코딩이 더 빠르고 효율적일 수 있습니다. 장시간 자율 실행형 워크플로는 크고 복잡하며 상호 의존성이 높은 시스템에서, 충분한 문맥과 지속적인 실행이 실제 장점으로 이어질 때 더 잘 맞습니다.
7) 왜 코드 양보다 실사용 검증이 더 중요하다고 하나요?
사용자는 줄 수를 실행하지 않습니다. 소프트웨어를 실행합니다. 코드베이스는 깔끔하게 빌드되고, 테스트를 통과하고, 통합 환경에서도 문제없이 동작하고, 실제 워크로드를 견뎌야 비로소 가치가 생깁니다. SQLite, Redis, Lua, QuickJS, zlib, 심지어 Linux kernel까지 컴파일할 수 있다는 주장이 강하게 들리는 이유가 바로 여기에 있습니다.
8) 이런 사례를 본 뒤 엔지니어링 팀은 무엇을 다르게 해야 할까요?
팀은 AI 도구를 평가할 때 다음 기준을 더 중시할 필요가 있습니다.
- 빌드 신뢰성
- 테스트 통과율
- 회귀 처리 능력
- 코드베이스 이해 수준
- 사람 감독이 얼마나 필요한지
결국 실무에서는 생성 속도보다 검증된 결과를 최적화하는 쪽으로 관점을 옮기는 것이 중요합니다.
'SW > 인공지능' 카테고리의 다른 글
| Gemma 4 완전 정리: Google 오픈소스 LLM이 진짜 중요한 이유 (0) | 2026.05.08 |
|---|---|
| Mythos AI란 무엇인가: 2026년 사이버 보안 판도를 흔든 고위험 AI 모델 완전 정리 (0) | 2026.05.07 |
| MiniMax M2.7 완전 분석: 자기 자신을 개선하는 AI 코딩 모델의 성능과 한계 (0) | 2026.05.05 |
| Claude Mythos란 무엇인가: 사이버 보안을 바꿀 프런티어 AI 모델 완전 해설 (0) | 2026.05.04 |
| Ollama로 로컬 LLM 에이전트 만드는 법: MCP와 Zapier 연동까지 한 번에 정리 (0) | 2026.05.03 |