병렬 LLM 에이전트로 리눅스 커널 컴파일러 자율 개발 실험

핵심 요약

여러 개의 Claude 인스턴스를 병렬·지속적으로 돌려, 인간 개입을 최소화한 채 리눅스 커널을 컴파일할 수 있는 C 컴파일러를 만든 실험이다.

핵심은 "똑똑한 에이전트" 자체보다, 이들이 자율적으로 일하면서도 탈선하지 않게 만드는 테스트·환경·작업 구조 설계에 있다.

이 실험은 대규모 자율 코드 생성을 현실로 만들면서도, 동시에 품질·안전 측면에서 새로운 위험과 과제를 드러낸다.

실험의 목표와 전체 구도

이 프로젝트의 목표는 "현재 세대 LLM이 자율적으로 어디까지 소프트웨어를 만들 수 있는지"를 능력 한계까지 시험해 보는 것이다.

연구자는 하나의 거대한 목표를 주었다. 러스트로 작성된, GCC와 호환되는 C 컴파일러를 완전히 새로 만들고, 이를 이용해 리눅스 커널과 주요 오픈소스 프로젝트를 컴파일하는 것이다.

중요한 점은, 이 과정을 인간이 세밀하게 코딩 지시를 내리는 방식이 아니라, 긴 시간 동안 거의 손을 떼고 에이전트들이 스스로 계획을 세우고 코드베이스를 발전시키는 방식으로 진행했다는 점이다.

이를 위해 단일 에이전트가 아니라 16개의 Claude 인스턴스를 동시에 돌리고, 모두가 하나의 리포지토리에 기여하는 "에이전트 팀" 구조를 사용해 병렬 개발과 역할 분리를 시도했다.

무한 루프에서 동작하는 장시간 에이전트

일반적인 LLM 코딩 도구는 사람이 옆에 앉아 질문을 던지고, 답변을 보고, 다시 수정 요청을 하는 "짧은 상호작용"을 전제로 설계되어 있다.

하지만 리눅스 커널을 컴파일할 수준의 컴파일러를 만드는 것은 며칠에서 몇 주가 걸리는 장기 작업이므로, 모델이 몇 분 대화하다 멈추는 구조로는 진행이 불가능하다.

연구자는 이를 위해 간단하지만 강력한 전략을 썼다. 쉘 스크립트로 Claude 세션을 무한 루프에 넣어, 한 번 작업이 끝나면 곧바로 새 세션이 시작되고 또 다음 작업을 수행하게 만들었다.

각 세션은 공통된 프롬프트(문제 정의, 작업 방식, 자기 관리 지침 등)를 읽고 시작하며, 스스로 "지금 무엇을 해야 하는지, 다음엔 뭘 해야 하는지, 어떤 상태를 기록해야 하는지"를 판단하도록 설계되었다.

이 방식은 본질적으로 "사람이 끊어주지 않는 한, 모델은 계속 다음 목표를 찾아서 일하도록" 만드는 자동 연속 작업 엔진에 가깝다.

병렬 에이전트 구조와 간단한 동기화 방식

단일 에이전트만으로는 속도와 효율이 크게 떨어지므로, 연구자는 여러 개의 Claude 인스턴스를 동시에 실행하는 병렬 구조를 도입했다.

각 에이전트는 도커 컨테이너 안에서 동일한 git 리포지토리를 공유하지만, 실제 작업은 컨테이너 내부의 로컬 복제본에서 수행하고, 변경이 끝나면 upstream 리포지토리에 pull·merge·push를 하는 식으로 협업한다.

에이전트끼리 같은 이# 병렬 LLM 에이전트로# 병렬 LLM 에이전트로스트 코드 자체는 "쓸 만한 수준"이지만 숙련된 러스트 개발자의 작품과 비교하면 구조적 세련됨이나 일관성이 떨어지고, 생성된 기계어의 실행 효율도 GCC에 비해 크게 뒤처진다.

무엇보다, 새로운 기능이나 버그 수정이 기존 기능을 쉽게 망가뜨리는 불안정성이 남아 있어, 현재 상태의 컴파일러를 실전용으로 쓰기에는 리스크가 크다. 이 프로젝트는 "기술 데모이자 능력 벤치마크"로 보는 편이 정확하다.

에이전트 팀이 여는 미래와 안전에 대한 고민

이 실험은 LLM이 "함수 한두 개를 도와주는 도우미"에서 "수십만 줄 규모 프로젝트를 거의 혼자 수행하는 주체"로 진화할 수 있음을 보여준다.

과거에는 사람이 목표를 정의하고, 모델이 잠깐 생각한 뒤 답을 주고, 다시 사람이 다음 지시를 내리는 패턴이 기본이었다. 이제는 목표와 환경만 잘 설계하면, 에이전트 팀이 며칠 동안 자율적으로 작업하며 큰 시스템을 완성하는 것이 가능해지고 있다.

이는 개발자에게 엄청난 생산성 도약을 제공하지만, 동시에 위험도 커진다. 특히 사람이 직접 살펴보지 않은 코드가 대량으로 생성·배포되기 쉬운 환경이 만들어지면, 보안 취약점이나 미묘한 버그가 대량으로 확산될 수 있다.

연구자는 실제 침투 테스터로서의 경험 때문에, "테스트가 통과했다고 해서 안심할 수 없다"는 점을 강조한다. 자동화된 테스트는 필수지만, 사람의 비판적 검토와 현실 감각을 대체할 수는 없다.

즉, 에이전트 팀은 강력한 도구이지만, 이를 사용해 소프트웨어를 만들고 배포하는 조직은 코드 품질 보증, 보안 검토, 책임 분할 등 새로운 방식의 안전 전략을 고민해야 한다.

인사이트

자율적인 LLM 개발 팀을 잘 쓰려면 "프롬프트 잘 쓰는 법"보다 "환경과 테스트를 설계하는 법"이 훨씬 중요하다는 점이 드러난다. 에이전트가 스스로 읽고 행동을 조정할 수 있는 테스트·로그·문서 구조를 만들면, 사람 개입 없이도 꽤 긴 여정을 스스로 완주할 수 있다.

병렬 에이전트를 제대로 활용하려면, 문제를 자연스럽게 나눌 수 없다면 인공적으로라도 분해해야 한다. GCC를 기준으로 삼아 커널 파일을 분할해 디버깅한 사례처럼, "병렬성이 없는 문제를 병렬적으로 보이게 만드는 설계력"이 관건이다.

실무 관점에서 이 실험이 주는 교훈은, 단기적으로는 "코드베이스를 에이전트 친화적으로 만드는 것(좋은 테스트, 명확한 로그, 잘 정리된 문서)"이 가장 즉각적인 생산성 향상을 줄 것이라는 점이다. 장기적으로는, 이렇게 생성된 대량의 자동 코드에 대해 어떤 검증·감사·보안 체계를 둘지 미리 고민하는 조직이 경쟁력과 안전을 동시에 확보할 가능성이 크다.

출처 및 참고 : Building a C compiler with a team of parallel Claudes \ Anthropic