16개의 AI가 동시에 코드를 작성하면 어떤 일이 벌어질까요? Anthropic의 연구원 Nicholas Carlini는 이 질문에 답하기 위해 극단적인 실험을 했습니다. Claude Code 세션 2,000개를 돌리고 2만 달러를 투입해, 리눅스 커널을 컴파일할 수 있는 10만 줄짜리 C 컴파일러를 만든 겁니다. 그것도 단 2주 만에요.
출처: Building a C compiler with a team of parallel Claudes – Anthropic Engineering Blog
에이전트 팀이란 무엇인가
Claude Code의 에이전트 팀은 여러 개의 Claude 인스턴스가 병렬로 작동하며 하나의 프로젝트를 함께 완성하는 방식입니다. 한 세션이 팀 리드 역할을 맡아 작업을 조율하고, 나머지 팀원들은 각자 독립적인 컨텍스트 윈도우에서 작업하죠.
기존의 서브에이전트와 다른 점은 팀원들끼리 직접 대화할 수 있다는 겁니다. 서브에이전트는 메인 에이전트에게만 결과를 보고하지만, 에이전트 팀은 팀원들이 서로 메시지를 주고받으며 토론하고 협력합니다. 마치 실제 개발 팀처럼요.
작동 방식은 이렇습니다:
- 공유 태스크 리스트: 모든 팀원이 볼 수 있는 작업 목록이 있습니다. 팀원은 다른 팀원이 작업 중인 태스크를 피해 비어있는 태스크를 선택합니다
- 파일 잠금: 두 팀원이 동시에 같은 작업을 시작하지 않도록, Git의 동기화 메커니즘을 활용해 태스크를 “잠급니다”
- 독립 작업: 각 팀원은 자신의 컨텍스트에서 독립적으로 작업한 뒤, 완료되면 변경사항을 메인 저장소에 푸시합니다
C 컴파일러 프로젝트에서 Carlini는 각 에이전트를 Docker 컨테이너에 넣고 무한 루프로 실행했습니다. 한 작업이 끝나면 자동으로 다음 작업을 선택하는 방식이죠. 오케스트레이션 에이전트 없이, 각 Claude가 스스로 “다음에 가장 중요한 문제”를 판단하며 움직였습니다.
리눅스 컴파일러를 만드는 과정
처음에는 여러 개의 독립적인 테스트가 실패하면서 병렬화가 자연스러웠습니다. 한 에이전트는 if문 파싱을 고치고, 다른 에이전트는 함수 정의 코드 생성을 작업하는 식이었죠. 하지만 테스트 통과율이 99%에 도달하자 문제가 생겼습니다.
리눅스 커널 컴파일은 수백 개의 독립적인 테스트가 아니라 하나의 거대한 작업입니다. 모든 에이전트가 같은 버그를 발견하고, 같은 버그를 고치고, 서로의 변경사항을 덮어쓰기 시작했습니다. 16개의 에이전트를 돌려도 진전이 없었어요.
해결책은 GCC를 “알려진 정답” 오라클로 사용하는 것이었습니다. 커널의 대부분 파일은 GCC로 컴파일하고, 일부만 Claude의 컴파일러로 컴파일합니다. 커널이 정상 작동하면 Claude 컴파일러가 담당한 파일들에는 문제가 없다는 뜻이죠. 이 방식으로 각 에이전트는 서로 다른 파일의 서로 다른 버그를 병렬로 수정할 수 있었습니다.
병렬화는 전문화도 가능하게 했습니다. 한 에이전트는 중복 코드를 찾아 통합하는 역할을, 다른 에이전트는 컴파일러 성능 최적화를, 또 다른 에이전트는 문서화를 담당했습니다. 한 에이전트에게는 Rust 개발자 관점에서 프로젝트 설계를 비판하고 구조적 개선을 하도록 요청했죠.
자율 AI 팀을 위한 설계 원칙
Carlini가 발견한 가장 중요한 교훈은 “완벽한 테스트 하네스를 만들어라”였습니다. Claude는 주어진 문제를 자율적으로 해결하려 하지만, 문제 검증기가 부정확하면 잘못된 문제를 풀게 됩니다.
프로젝트 후반부에 Claude가 새 기능을 추가할 때마다 기존 기능을 망가뜨리기 시작했습니다. 이를 막기 위해 Carlini는 CI 파이프라인을 구축하고, 새 커밋이 기존 코드를 망가뜨릴 수 없도록 더 엄격한 검증을 적용했어요.
또 다른 핵심은 “Claude의 입장에서 생각하기”였습니다. 각 에이전트는 새로운 컨테이너에 아무 맥락 없이 떨어지기 때문에, 상황 파악에 상당한 시간을 씁니다. 이를 돕기 위해 Carlini는 에이전트들에게 광범위한 README와 진행 상황 파일을 유지하도록 지시했습니다.
LLM의 한계도 고려해야 했습니다. 컨텍스트 윈도우가 쓸데없는 로그로 오염되지 않도록, 테스트 하네스는 몇 줄만 출력하고 중요한 정보는 파일에 기록했습니다. Claude는 시간 감각이 없어서 몇 시간 동안 테스트를 돌릴 수 있기 때문에, --fast 옵션을 기본값으로 설정해 1-10%의 랜덤 샘플만 실행하도록 했죠.
한계와 가능성
결과물은 인상적이지만 완벽하지는 않습니다. 컴파일러는 리눅스 6.9를 x86, ARM, RISC-V에서 부팅할 수 있고, QEMU, FFmpeg, SQLite, Redis를 컴파일하며, GCC torture 테스트 스위트에서 99% 통과율을 기록합니다. Doom도 컴파일하고 실행할 수 있죠.
하지만 실전 리플레이스먼트로는 아직 부족합니다. 16비트 x86 컴파일러가 없어서 리눅스를 real mode에서 부팅할 때는 GCC를 호출해야 하고, 어셈블러와 링커는 아직 버그가 많습니다. 생성하는 코드의 효율성도 떨어집니다. 모든 최적화를 켜도 GCC가 최적화를 끈 것보다 느린 코드를 만들어냅니다.
Carlini는 이런 한계들을 극복하려 했지만 성공하지 못했습니다. “Opus 4.6의 능력이 거의 한계에 도달했다”는 게 그의 평가입니다. 새 기능을 추가하거나 버그를 고칠 때마다 기존 기능이 망가지는 일이 반복됐죠.
그럼에도 Carlini는 이 프로젝트가 우리가 AI와 일하는 방식의 변화를 보여준다고 말합니다. 초기 모델은 IDE에서 탭 자동완성에 쓰였고, 그다음엔 함수 본문을 완성했으며, Claude Code는 페어 프로그래밍을 가능하게 했습니다. 에이전트 팀은 복잡한 프로젝트 전체를 자율적으로 구현할 가능성을 보여줍니다.
하지만 그는 동시에 불안감도 느낀다고 고백합니다. “개발자가 직접 검증하지 않은 소프트웨어를 배포한다는 생각은 진짜 우려스럽습니다.” 펜테스팅 경력이 있는 그는 대기업이 만든 제품에서 취약점을 찾아 악용하는 일을 해왔기에, 이 위험을 누구보다 잘 알고 있습니다.
에이전트 팀은 흥미롭지만 2026년 초에 이런 일이 가능하리라고는 예상하지 못했다고 Carlini는 말합니다. LLM과 그것을 다루는 스캐폴드의 빠른 발전은 엄청난 양의 새로운 코드를 작성할 수 있는 문을 열었습니다. 긍정적 응용이 부정적 결과를 능가할 거라고 기대하지만, 안전하게 항해하려면 새로운 전략이 필요한 새로운 세계에 들어서고 있다는 게 그의 결론입니다.
참고자료:
답글 남기기