장기간 실행되는 자율 코딩 에이전트, 어디까지 왔을까?

개발자가 코드를 짜지 않아도, 수백·수천 개의 파일이 몇 주에 걸쳐 자동으로 작성되고 리팩터링된다면 어떤 느낌일까요?

오늘 이야기할 주제는 바로 “장기간 실행되는 자율 코딩 에이전트”입니다. 단순히 한 두 파일 고쳐주는 AI가 아니라, 웹 브라우저를 처음부터 만들고, 대규모 리팩터링을 수행하고, 성능 최적화까지 장기 프로젝트를 수행하는 에이전트들입니다.

이 글에서는 왜 단일 에이전트로는 한계가 있는지, 여러 에이전트를 어떻게 조율해야 장기간 프로젝트가 가능해지는지, 실제로 어떤 실험들이 진행됐는지, 그리고 우리가 실무에서 무엇을 배울 수 있는지까지 정리해 보겠습니다.

단일 코딩 에이전트의 한계와 멀티 에이전트의 필요성

현재의 코딩 에이전트(코파일럿, Claude Code, Cursor 등)는 “한 번에 한 작업”에는 굉장히 능숙합니다. 함수 하나를 리팩터링하거나, 테스트 코드를 생성하거나, 버그 하나를 잡는 식의 단일 태스크에는 꽤 잘 작동하죠.

하지만 문제는 “진짜 프로젝트”입니다.

예를 들어, 다음 같은 작업을 떠올려보세요.

프론트엔드 프레임워크 전체를 다른 스택으로 마이그레이션
수십만 줄짜리 레거시 서비스에 도메인 단위 모듈화 도입
브라우저, LSP, 에뮬레이터, 스프레드시트 같은 복잡한 애플리케이션을 처음부터 구현

이런 작업을 단일 에이전트에게 맡기면 어떻게 될까요?

처음에는 의욕적으로 이것저것 시도하지만, 규모가 커질수록 다음과 같은 문제가 터집니다.

전체 구조를 다 파악하지 못해 같은 부분을 여러 번 수정
한 번에 담을 수 있는 컨텍스트 한계로 인해 앞에서 했던 결정을 뒤에서 까먹음
시간이 갈수록 “쉬운 일만” 하게 되고, 어려운 핵심 기능은 미루거나 회피

결국 “혼자 뛰는 천재 개발자” 모델로는, 수주·수개월이 걸리는 대형 프로젝트를 끝까지 밀어붙이기 어렵다는 것이 드러납니다¹.

그래서 등장한 발상이 바로 멀티 에이전트 시스템, 그것도 장기간 동안 끊기지 않고 돌아가는 자율 코딩 에이전트 군단입니다.

에이전트끼리 자율적으로 조율해본 실험: 왜 망가졌나

처음 시도는 꽤 직관적입니다.

“에이전트 여러 개를 띄워두고, 알아서 역할을 나눠서 일을 하게 하면 되지 않을까?”

이를 위해 실험팀은 에이전트들이 공유하는 “상태 파일”을 하나 두고, 각 에이전트가 거기서 현재 진행 중인 작업을 확인한 뒤, 자신이 할 일을 골라서 “이건 내가 할게”라고 표시하는 방식으로 설계했습니다¹.

두 에이전트가 같은 일을 집지 않게 하려고 락(lock) 메커니즘도 도입했습니다.

현실은 꽤 가혹했습니다.

첫째, 락이 병목이 됐습니다.
수십 개 에이전트를 돌리는데, 락을 잡느라 대기하는 시간이 길어지면서 실제 처리량은 “2~3개 에이전트 정도의 속도”로 떨어지는 현상이 발생했습니다¹.

둘째, 시스템이 생각보다 깨지기 쉬웠습니다.

에이전트가 락을 잡은 상태에서 실패해 락을 풀지 못하는 경우
이미 가진 락을 또 잡으려다 꼬이는 경우
락 없이 파일을 업데이트해 상태가 깨지는 경우

셋째, 계층이 없는 “평면 구조”에서는 에이전트가 점점 소심해지는 문제가 드러났습니다.

모든 에이전트가 동등한 권한을 가진 상황에서, 각 에이전트는 괜히 대규모 리팩터링이나 어려운 기능 구현에 덤볐다가 다른 에이전트와 충돌하거나 실패하는 걸 피하려고 합니다.

그래서 “위험한 큰 작업”은 아무도 안 맡고, 다들 작고 안전한 수정만 반복하는 패턴으로 빠져버립니다¹.

결론적으로, “서로 눈치 보면서 자율 협업”은 겉으로 보기엔 지능적인 분산 시스템 같았지만, 실제로는:

락 때문에 느리고
실패 케이스에 취약하며
어려운 일을 기피하는 집단으로 변해버리는

예상 밖의 결과를 낳았습니다.

계획자와 작업자: 역할 분리로 얻은 브레이크스루

이 실패 이후, 연구팀은 인간 조직 구조에서 힌트를 얻었습니다.

“모든 사람이 모든 일을 다 하는 팀”은 거의 없죠. 대부분은:

큰 그림을 보고 일을 쪼개는 사람(리드, PM, 아키텍트)
쪼개진 일을 집중해서 끝내는 사람(개발자, 구현 담당)

이런 구조를 갖습니다.

이를 그대로 에이전트 세계에 가져온 것이 Planner(계획자) – Worker(작업자) 구조입니다¹.

계획자 에이전트는 다음 역할을 담당합니다.

코드베이스 전체를 돌아다니며 “해야 할 일 리스트”를 생성
특정 영역(예: 렌더링, 네트워킹 등)에 대해 서브 플래너를 만들어 계획을 더 잘게 쪼갬
난이도 높은 문제도 “작업 단위로 쪼개는 것”에 집중

작업자 에이전트는 아주 단순합니다.

계획자가 만들어준 작업을 하나 집어온다
그 작업을 끝내는 데만 집중한다
완료되면 코드 변경을 푸시하고, 다음 작업을 받는다

여기에 Judge(판정자) 역할을 둬서, 각 사이클이 끝날 때마다:

지금 전략을 계속 밀어야 할지
더 이상 진전이 없으니 리셋해야 할지

를 판단하도록 했습니다¹.

이 구조로 바꾸자, 앞에서 겪었던 문제들이 상당 부분 정리됩니다.

누가 어려운 일을 책임져야 하는지가 명확해짐 (계획자)
작업자는 “큰 그림 스트레스” 없이 작은 단위에 집중
락과 상태 공유의 복잡도는 줄이고, 역할을 중심으로 조정을 단순화

즉, 에이전트를 “하나의 팀”처럼 구조화해주자, 비로소 수백 개 에이전트가 한 프로젝트 위에서 동시에 일하는 것이 현실적으로 가능해졌습니다.

수주간 돌린 실험 사례: 브라우저, 마이그레이션, 성능 튜닝까지

이제 “말로는 좋아 보이는데, 실제로는 뭐 했냐?”가 궁금해집니다.

연구팀은 이 구조를 가지고 꽤 야심 찬 프로젝트들을 여러 개 돌려봤습니다.

첫 번째는 웹 브라우저를 처음부터 만드는 실험입니다.

에이전트들은 대략 일주일 동안 쉬지 않고 돌아가며, 1,000개가 넘는 파일에 약 100만 줄 이상의 코드를 작성했습니다¹.

흥미로운 점은:

코드베이스가 이렇게 커졌는데도, 새로 들어온 에이전트가 전체 구조를 이해하고 의미 있는 수정과 확장을 계속할 수 있었다는 것
수백 명의 ‘작업자 에이전트’가 동시에 같은 브랜치에 코드를 푸시하는데도, 충돌과 갈등이 생각보다 적었다는 것

두 번째는 더 실무적인 실험입니다.

기존 코드베이스에서 프론트엔드 프레임워크를 Solid에서 React로 통째로 마이그레이션하는 작업이었습니다. 이 작업은 3주 넘게 진행되었고, 결과적으로 +266K / -193K 수준의 대규모 변경이 포함된 PR이 만들어졌습니다¹.

사람이 주도해도 부담스러운 규모의 리팩터링을, 장기 실행 에이전트들이 상당 부분 자동으로 밀어붙였다는 점이 인상적입니다.

세 번째는 실제 제품 성능 개선입니다.

비디오 렌더링 파이프라인을 장기간 에이전트에게 맡겨, Rust 기반의 효율적인 구현으로 갈아타며 렌더링 속도를 25배 향상시킨 사례가 보고됐습니다¹. 이 코드는 실서비스에 실제로 머지되어 곧 프로덕션에 반영될 예정입니다.

이와 별개로, 장기 실험으로 진행 중이거나 진행되었던 프로젝트들도 있습니다¹.

Java LSP: 7,400여 개 커밋, 55만 줄 규모
Windows 7 에뮬레이터: 약 1,4600 커밋, 120만 줄
Excel 유사 스프레드시트 프로젝트: 1.6M LoC 수준

단순 PoC 수준이 아니라, “큰 코드베이스를 에이전트가 장기간 관리하고 발전시킬 수 있는가?”를 진지하게 시험해 본 셈입니다.

장기간 자율 코딩에서 드러난 핵심 인사이트 4가지

이 여러 실험에서 얻어진 교훈은, 단순히 연구 프로젝트에만 머물지 않고 우리 같은 실무 개발자에게도 꽤 많은 시사점을 줍니다.

1. 모델 선택이 생각보다 훨씬 중요하다

장기간 돌아가는 자율 에이전트에게 가장 중요한 능력은 “한 방에 똑똑함”이 아니라:

지시를 오래·정확하게 따르는 능력
한 방향으로 계속 집중하는 끈기
중간에 맥락을 잃지 않는 일관성
구현을 끝까지 밀어붙이는 집요함

입니다.

실험 결과, 장기 작업에서는 특정 모델(GPT-5.2 계열)이, 코딩 특화 모델(GPT-5.1-codex)보다 계획자 역할에 더 잘 맞았다고 보고됩니다¹.

코드 생성만 잘하는 모델보다, “계속 같은 방향으로 밀어붙이는 모델”이 상위 계층(Planner)에는 더 적합했던 셈입니다.

실무적으로는, 앞으로 “하나의 모델로 다 한다”보다, 역할별로 다른 모델을 쓰는 하이브리드 전략이 더 일반적인 패턴이 될 가능성이 큽니다.

2. 복잡한 구조가 꼭 좋은 구조는 아니다

실험 초기에 연구팀은 Integrator(통합자) 같은 역할을 만들어, 코드 품질 검토와 충돌 해결을 전담시키는 구조를 설계했습니다¹.

이론상으로는 굉장히 그럴듯해 보입니다.

각 작업자가 올린 PR을 Integrator가 검토
충돌과 품질 이슈를 중앙에서 관리
품질 게이트 역할 수행

하지만 실제로 돌려보니, 이 Integrator가 전체 파이프라인의 병목이 되었습니다.

오히려 작업자 에이전트들에게 “충돌이 나면 스스로 해결하게” 했더니, 시스템 전체 속도와 유연성이 더 좋아졌습니다¹.

여기서 얻은 중요한 인사이트는:

“모든 좋은 조직 이론이나 분산 시스템 설계 패턴이, 에이전트 시스템에도 그대로 잘 맞는 것은 아니다.”

라는 점입니다.

적당한 구조화는 필요하지만, 구조화가 과해지면 오히려 깨지기 쉬운 시스템이 됩니다. 너무 자유롭게 놔두면 충돌과 중복 작업이 발생하지만, 너무 빡빡하게 제약하면 확장성과 회복력이 떨어지는 것이죠.

3. 에이전트 행동의 80%는 프롬프트에서 결정된다

장기간 자율 코딩 에이전트를 돌릴 때, 생각보다 가장 민감한 요소는 프롬프트 설계입니다¹.

어떤 작업을 우선도로 두게 만들 것인지
충돌이 났을 때 어떻게 행동해야 하는지
어려운 작업을 피하지 않고 끝까지 따라가게 만드는지
이미 있는 코드와 스타일을 어디까지 존중하게 할지

이 모든 것이 프롬프트 내용과 구조, 예시, 제약 조건에 크게 좌우됩니다.

연구팀도 “모델이나 인프라보다, 프롬프트를 어떻게 짜느냐가 시스템 전체의 성격을 결정한다”고 말할 정도로, 다양한 프롬프트 실험을 통해 이상 행동·비효율·표류를 줄였습니다¹.

실무에서 우리가 지금 당장 할 수 있는 액션도 여기서 나옵니다.

프로젝트별 “에이전트 사용 가이드” 문서를 정리(CLAUDE.md, .cursor/rules 등)
코드 스타일, 테스트 정책, 보안 규칙 등을 명확한 자연어 규칙으로 정의
“에이전트가 망가뜨리면 안 되는 것들”을 프롬프트에 명시

이런 것만 해도, 장기간 프로젝트에서의 에이전트 안정성이 꽤 올라갑니다.

4. 완벽하진 않지만, “규모를 키우면 된다”는 희망이 생겼다

물론 현 시스템은 아직 완벽과 거리가 멉니다¹.

플래너가 적절한 타이밍에 깨어나 후속 계획을 세우는 트리거
너무 오래 달리는 에이전트를 적시에 종료시키는 관리
장기간 실행 중 생기는 “표류(drift)”와 “터널 비전”을 주기적으로 리셋하는 메커니즘

이런 부분은 여전히 연구·개선 중입니다.

그럼에도 불구하고, 핵심 질문:

“에이전트를 여러 개 더 붙이면 정말로 더 큰 문제를 풀 수 있는가?”

에 대해서는 꽤 낙관적인 답을 얻었습니다¹.

수백 개의 에이전트를 몇 주씩 돌려도, 실제로 의미 있는 기능과 대규모 리팩터링이 진행되고, 거대한 코드베이스에서도 지속적인 진전이 나온다는 것이 검증되고 있기 때문입니다.

시사점: 지금 우리가 할 수 있는 것들

이 글을 읽고 있는 대부분의 독자분들은, 아직 “수백 개 에이전트를 수주 동안 돌릴 인프라”를 가진 팀은 아닐 가능성이 큽니다.

그래도, 여기서 얻은 교훈을 당장 우리 팀의 개발 워크플로우에 적용할 수 있는 방법은 분명히 있습니다.

역할 분리부터 도입해보기
- 한 에이전트를 “프로젝트 플래너”로 쓰고, 다른 에이전트를 “구현자”로 사용하는 방식
- 예:
  - 플래너: “이 이슈를 해결하기 위한 단계별 계획 수립 + 파일/모듈 단위 작업 쪼개기”
  - 워커: “각 단계별 구현 및 테스트, PR까지 자동화”
프롬프트를 ‘규칙 문서’ 수준으로 관리하기
- 프로젝트별 규칙을 하나의 문서에 정리하고, IDE/에이전트 도구들이 이 문서를 공통으로 참조하도록 구성
- Ruler, Beads 같은 도구를 쓰면 여러 에이전트의 설정을 한 곳에서 관리하는 것도 가능합니다².
장기 작업은 에이전트에게, 최종 판단은 사람에게
- Solid→React 마이그레이션 같은 대형 작업을 에이전트에게 맡기더라도, 최종 머지는 사람이 결정
- 에이전트가 만들어낸 “초안”을 바탕으로, 사람은 리뷰와 최종 아키텍처 판단에 집중
“에이전트 친화적인” 코드베이스 만들기
- 일관된 디렉터리 구조
- 명확한 네이밍 규칙
- 풍부한 테스트와 예제 코드
- 이런 것들이 쌓일수록, 에이전트가 긴 시간 동안 덜 헤매고 더 잘 일할 수 있는 환경이 됩니다.

마지막으로, Cursor 같은 에이전트 중심 IDE는 이런 연구 결과를 빠르게 제품화하고 있습니다¹. 장기간 자율 코딩에 관심이 있다면, 단순 “코드 자동완성” 기능을 넘어 에이전트 기능이 어떻게 설계되고 있는지, 실제 프로젝트에서 어떻게 써볼 수 있을지 탐색해 보는 것을 추천합니다.

참고

¹Scaling long-running autonomous coding