Anthropic 연구원 한 명이 Claude AI 에이전트 16개를 동시에 풀어놓았습니다. 목표는 C 컴파일러를 처음부터 만드는 것. 결과부터 말하면, 2주 만에 10만 줄짜리 Rust 기반 컴파일러가 나왔고, 이 컴파일러로 리눅스 커널까지 빌드하는 데 성공했습니다. 사람이 코드를 한 줄도 쓰지 않은 채로.
이 프로젝트가 단순한 기술 데모를 넘어서 주목받는 이유는 분명합니다. AI가 ‘코드 몇 줄 짜주는 도구’에서 ‘소프트웨어를 통째로 설계하고 구현하는 팀’으로 진화하고 있다는 증거이기 때문입니다.
16개 AI가 동시에 코딩한다는 것
이 프로젝트를 이끈 사람은 Anthropic 연구원 Nicholas Carlini입니다. 그가 선택한 방법은 ‘에이전트 팀(agent teams)’이라는 접근법입니다. 핵심은 간단합니다. 여러 Claude 인스턴스를 공유 코드베이스 위에서 병렬로 작업시키되, 사람이 직접 개입하지 않는 것입니다.
구체적으로 보면 이렇습니다. 16개의 Claude Opus 4.6 에이전트가 각각 독립된 Docker 컨테이너 안에서 실행됩니다. 각 에이전트는 공유 Git 저장소에 접근할 수 있고, 자기 로컬 복사본에서 작업한 뒤 upstream에 푸시합니다. 병합 충돌이 생기면? Carlini에 따르면 “Claude는 충분히 똑똑해서 병합 충돌을 직접 해결할 수 있다.” 사람의 도움 없이 머지 분쟁을 해결한다는 뜻입니다. 컴퓨터공학 학부 강의에서 가장 골치 아픈 주제 중 하나가 머지 충돌인데, AI가 이것을 자율로 처리한다는 건 의미가 큽니다.
여기서 특이한 점이 있습니다. 보통 멀티 에이전트 시스템이라고 하면 중앙에서 작업을 분배하는 ‘오케스트레이터’가 있습니다. 한 명의 지휘자가 16명의 연주자에게 악보를 나눠주는 식입니다. 하지만 이 프로젝트에는 그런 지휘자가 없었습니다. 각 에이전트가 스스로 ‘다음으로 가장 명백한 문제’를 찾아서 작업을 시작했습니다. 중복을 막기 위해 current_tasks/ 디렉토리에 텍스트 파일을 만들어 “이 작업은 내가 하고 있다”고 선언하는 락(lock) 방식을 썼습니다. 분산 시스템의 가장 단순한 동기화 메커니즘을 그대로 가져온 셈입니다. 이 단순함이 오히려 작동했다는 사실이 흥미롭습니다.
이 구조가 의미하는 건, AI 에이전트가 단순히 지시를 받아 실행하는 수준을 넘어 자율적으로 판단하고 협업할 수 있다는 것입니다. 더 깊이 들어가면, 이 방식은 인간 개발팀의 작동 방식과 묘하게 닮았습니다. 시니어 개발자가 모든 작업을 분배하지 않아도, 잘 짜인 팀에서는 각자가 다음에 무엇을 할지 알아서 찾아냅니다. 16개의 Claude도 같은 방식으로 움직였다는 점이, 이 프로젝트의 가장 흥미로운 발견입니다. Cursor가 에이전트 8개를 동시에 돌리며 시장을 흔들고 있는 흐름도 같은 원리를 제품 수준으로 가져온 사례입니다.
2주, 2만 달러, 10만 줄 — 숫자가 말해주는 것
프로젝트의 규모를 숫자로 정리하면 이렇습니다.
- 기간: 약 2주
- 비용: 2만 달러 미만 (API 사용료)
- 세션 수: 약 2,000번의 Claude Code 세션
- 토큰 사용량: 입력 20억 토큰, 출력 1억 4,000만 토큰
- 결과물: 100,000줄의 Rust 코드, 외부 의존성 없음 (표준 라이브러리만 사용)
2만 달러라는 비용이 싸다고 느껴지십니까, 비싸다고 느껴지십니까? Carlini 본인은 “혼자 구축하는 것보다 훨씬 저렴하다”고 평가했습니다. 실제로 C 컴파일러를 처음부터 만드는 건 컴퓨터공학에서 가장 난이도 높은 프로젝트 중 하나입니다. 인간 개발팀이라면 수개월에서 수년이 걸릴 작업입니다. 시니어 개발자 한 명의 1년 인건비가 보통 2억 원을 넘는다는 점을 생각하면, 2만 달러(약 2,800만 원)는 그 인건비의 14% 수준입니다. 그것도 한 명이 1년 일한 결과가 아니라, 16명분의 작업을 2주 만에 끝낸 결과입니다.
결과물의 성능도 인상적입니다. GCC torture test suite에서 99% 통과율을 기록했고, PostgreSQL, SQLite, Redis, FFmpeg, QEMU 같은 대형 오픈소스 프로젝트를 컴파일할 수 있습니다. 그리고 개발자들의 ‘궁극적 리트머스 테스트’라고 불리는 Doom도 컴파일해서 실행하는 데 성공했습니다. Doom은 1993년 공개된 이래로 토스터부터 임신 테스트기까지 온갖 기기에 이식된 것으로 유명합니다. 새 컴파일러가 등장할 때마다 “Doom이 돌아간다”는 한 줄이 합격증 역할을 합니다.
가장 인상적인 건 리눅스 커널입니다. x86, ARM, RISC-V 세 가지 아키텍처에서 Linux 6.9를 빌드하고 부팅까지 성공했습니다. AI가 만든 컴파일러로 운영체제를 돌린다는 건, 단순한 ‘토이 프로젝트’가 아니라는 뜻입니다. 운영체제 커널은 컴파일러가 만들어낸 기계어가 단 한 줄이라도 잘못되면 부팅 단계에서 그대로 멈춥니다. 세 가지 아키텍처에서 모두 성공했다는 건 코드 생성의 정확성이 일정 수준 이상이라는 객관적 증거입니다.
결국 사람이 필요했다 — 한계가 보여주는 현실
하지만 이 프로젝트를 ‘AI가 인간 개발자를 대체했다’는 이야기로 읽으면 곤란합니다. 자세히 들여다보면 인간의 개입이 없진 않았습니다.
Carlini가 한 핵심적인 일은 테스트 인프라를 설계한 것입니다. AI 에이전트들이 같은 버그에 동시에 걸려 서로의 수정 사항을 덮어쓰는 문제가 발생했을 때, 그가 해결한 방식이 있습니다. GCC를 ‘컴파일러 오라클’로 사용해서, 커널의 대부분은 GCC로 컴파일하고 나머지 일부만 Claude 컴파일러로 컴파일하는 무작위 혼합 방식을 도입한 것입니다. 이렇게 하면 각 에이전트가 서로 다른 파일의 버그를 병렬로 디버깅할 수 있습니다. 이 한 가지 인사이트가 없었다면 16개 에이전트가 같은 자리에서 영원히 빙빙 돌았을 가능성이 큽니다.
전 Microsoft 임원 Steve Sinofsky는 이 프로젝트와 GCC의 37년 개발 기간을 단순 비교하는 것을 비판했습니다. “언어의 진화, 플랫폼의 다양화, 최적화 기술의 발전을 무시한 비교”라는 것입니다. 타당한 지적입니다. GCC가 37년 동안 한 일은 단순히 C를 컴파일하는 것이 아니라, 수십 개의 언어와 수백 개의 아키텍처를 지원하면서 점점 정교해진 최적화 알고리즘을 누적한 것입니다. Claude의 컴파일러는 그중 가장 단순한 단면 하나를 짧은 시간에 재현한 것뿐입니다.
실제 기술적 한계도 분명합니다.
- 16비트 x86 코드 생성 불가: 실모드 부팅에 필요한 코드를 만들지 못해 GCC에 위임
- 어셈블러와 링커 미완성: 컴파일의 마지막 단계가 불안정해서 데모 영상에서도 GCC 도구를 사용
- 최적화 성능 부족: 최적화를 켜도 GCC의 최적화 비활성 상태보다 비효율적
- 새 기능 추가 시 기존 기능 손상 빈번: 현재 모델의 자율 개발 능력의 천장을 보여줌
Carlini 본인도 “Opus 4.6은 능력 한계에 도달했다”고 인정했습니다. 새로운 기능을 추가하거나 버그를 수정하면 이전에 작동하던 기능이 깨지는 현상이 반복됐다는 것입니다. 회귀(regression) 버그입니다. 사람 개발자라면 새 기능을 만들 때 기존 테스트 스위트를 돌려서 무엇이 깨졌는지 확인하는데, AI 에이전트는 이 자기 점검을 충분히 하지 못했습니다. 최근 OpenAI가 코딩 AI 속도를 극한까지 끌어올렸다는 뉴스도 있었지만, 속도와 ‘완성도’는 다른 문제라는 사실을 이 프로젝트가 증명한 셈입니다.
흥미로운 건 이 한계가 두 달 뒤 다시 갱신됐다는 사실입니다. Anthropic은 4월 7일 Mythos Preview를 발표하면서 OpenBSD의 27년 묵은 버그를 자율로 찾아냈다고 밝혔는데, 이는 Opus 4.6의 ‘능력 한계’가 한 세대 안에 깨졌다는 뜻입니다. AI 코딩 능력의 변화 속도가 인간 개발 조직의 적응 속도를 추월하고 있다는 신호입니다.
개발자의 역할이 바뀌고 있다
이 프로젝트에서 가장 의미심장한 코멘트는 한 관찰자의 것이었습니다. “10배 개발자의 핵심 기술은 복잡한 버그를 직접 해결하는 게 아니라, 16개 모델 인스턴스가 병렬로 해결하도록 하는 자동화 테스트 리그와 피드백 루프를 설계하는 것이다.”
생각해보면 Carlini가 이 프로젝트에서 한 일의 본질이 그것입니다. 그는 코드를 쓰지 않았습니다. 대신 AI들이 효율적으로 일할 수 있는 환경을 설계했습니다. 테스트 파이프라인을 만들고, 작업 분배 메커니즘을 고안하고, 디버깅이 가능한 구조를 설계했습니다. 그는 코더가 아니라 코더의 코더, 즉 메타 코더로 일했습니다.
이건 소프트웨어 개발자의 역할이 ‘코드를 쓰는 사람’에서 ‘AI 워크플로우를 설계하는 사람’으로 전환되고 있다는 신호입니다. 누가 코드를 쓰느냐보다 누가 AI를 잘 부리느냐가 경쟁력이 되고 있습니다. 이 변화는 시니어 개발자에게는 권력 강화이고, 주니어 개발자에게는 새로운 학습 곡선의 시작입니다. “어떤 언어를 잘하는가”가 아니라 “어떤 AI 워크플로우를 설계할 수 있는가”가 새로운 평가 기준이 됩니다.
동시에 Carlini는 우려도 표했습니다. “자율적 개발은 실질적 위험을 동반한다.” 개발자가 개인적으로 검증하지 않은 소프트웨어가 배포될 수 있다는 것입니다. 테스트를 통과했다고 해서 완전한 것이 아니라는 점, 침투 테스트 경험에서 그는 이 문제를 뼈저리게 알고 있었습니다. AI가 만든 컴파일러의 99% 통과율은 인상적이지만, 통과하지 못한 1%가 어디인지를 사람이 알지 못한다는 사실이 더 무거운 문제입니다.
한국 개발 조직이 받아갈 한 가지
한국 IT 조직이 받아갈 메시지는 하나로 압축됩니다. “코드를 누가 쓰는가”가 아니라 “AI를 누가 어떻게 운영하는가”가 새로운 경쟁력이 된다는 사실입니다. 그동안 한국 개발 조직의 인력 평가는 “이 사람이 직접 코딩을 얼마나 빠르고 정확하게 하는가”에 맞춰져 있었습니다. Carlini의 프로젝트는 그 기준이 시대에 뒤떨어지고 있음을 보여줍니다. 이제는 “이 사람이 16개의 AI 에이전트를 어떻게 조직해서 결과를 내는가”가 더 중요한 질문이 됩니다. 시니어 개발자의 실력은 손가락이 아니라 시스템 설계 능력으로 판가름 납니다.
이 변화에 대비해 한국 기업이 당장 할 수 있는 일이 두 가지 있습니다. 하나는 사내 코드 저장소에서 에이전트가 안전하게 작업할 수 있는 격리 환경을 미리 구축하는 것입니다. Carlini가 16개 컨테이너를 분리해 운영한 이유가 그것입니다. 한 에이전트의 실수가 다른 에이전트의 작업과 프로덕션 코드에 영향을 미치지 않도록 격리해야 합니다. 다른 하나는 자동화된 회귀 테스트 인프라입니다. AI가 새 기능을 추가할 때마다 기존 기능이 깨지지 않는지 즉시 확인할 수 있는 테스트 스위트가 없으면, 사람이 할 일은 결국 디버깅이 됩니다. 이 두 가지가 갖춰져야 16개 에이전트를 부리는 시대로 넘어갈 수 있습니다.
정리하면
16개 Claude AI 에이전트가 만든 C 컴파일러는 인상적인 성과이면서 동시에 냉정한 현실 점검입니다. AI가 10만 줄의 코드를 쓸 수 있다는 건 증명됐습니다. 하지만 그 코드가 인간 전문가 수준의 품질인지, GCC를 대체할 수 있는지는 완전히 다른 질문입니다.
Carlini는 이 프로젝트를 통해 ‘에이전트 팀이 복잡한 프로젝트를 자율적으로 구현할 가능성’을 보여줬지만, 동시에 현재 모델의 천장도 드러냈습니다. 지금 시점에서 이 프로젝트가 던지는 메시지는 하나입니다. AI가 개발자를 대체하는 게 아니라, 개발자가 AI를 얼마나 잘 설계하고 관리하느냐가 핵심이 됐다는 것입니다.
컴파일러 소스 코드는 GitHub에 공개되어 있습니다. 직접 확인하고 싶다면 Anthropic 공식 엔지니어링 블로그에서 전체 과정을 읽어볼 수 있습니다.