여러 AI 에이전트에게 코드를 나눠 맡기면 개발 속도는 빨라진다. 그러나 각자 타당한 판단을 내렸더라도 결과물이 저절로 맞물리지는 않는다.
자연어 지시의 해석 차이
“레시피 관리 앱을 만들어줘”라는 요청에는 수많은 답이 가능하다. 저장 방식, 화면 구성, 로그인 여부가 모두 열려 있기 때문이다. 멀티에이전트 개발은 여러 에이전트가 만든 부품을 그중 하나의 설계에 맞춰 조립하는 일이다.
하지만 자연어에는 늘 해석의 여지가 남는다. 한 에이전트가 콜백(작업 완료 뒤 함수를 호출하는 방식) 방식의 네트워크 모듈을 만들면, 다른 에이전트는 미리 짠 async/await(비동기 작업을 순차 코드처럼 쓰는 구문) 구조를 고쳐야 한다. 작업은 나눌 수 있어도 설계 결정까지 독립되지는 않는다. 조율 기준이 없으면 서로의 선택을 계속 뒤집는 ‘설계 왕복’이 시작된다. 실제로 AI 코딩 에이전트 개발사 Cognition의 Flappy Bird 복제 실험에서도 각 에이전트가 서로 다른 시각 양식과 전제를 택해 결과물을 하나의 게임으로 합치지 못했다.
실행 기록 1,600여 건을 분석한 MAST 연구(멀티에이전트 시스템 실패 분류체계)에서도 명세, 시스템 설계 문제가 41.8%, 에이전트 간 불일치가 36.9%로 나타났다. 두 범주 모두 역할 분담, 맥락 전달, 결과물 충돌 같은 연결부 문제를 포함한다. 모델의 추론 능력만 높여서는 풀 수 있을까.
끝나지 않는 되돌리기
1985년 컴퓨터과학자 Michael J. Fischer, Nancy A. Lynch, Michael S. Paterson은 비동기 분산시스템에서 프로세스 하나만 고장 나도 정해진 시간 안의 합의를 보장할 수 없음을 보였다. 멀티에이전트 코딩도 비슷하다. 메시지를 읽거나 도구 실행을 마치는 시점을 알기 어렵고, 컨텍스트 한도나 무한 루프로 작업이 갑자기 끊기기도 한다. 충돌을 피하려고 결정을 미루면 끝나지 않고 서둘러 합치면 검증하지 못한 문제가 들어간다.
실제로 한 소프트웨어 엔지니어는 두 Claude Code 인스턴스가 서로 다른 내용으로 267번 마이그레이션(데이터베이스 구조 변경 기록)을 만들고 한쪽 결과를 덮어쓴 사례를 소개했다. worktree(한 저장소의 작업 디렉터리를 분리하는 Git 기능)는 파일을 나눴지만 마이그레이션 번호까지 조율하지 못했다. 파일 격리만으로 결정 충돌을 막을 수 있을까.
Git을 Rust로 다시 구현한 Grit에서도 병렬 에이전트가 테스트 장치를 망가뜨려 프로젝트 진행이 한동안 중단됐다. Grit 프로젝트에는 전체 기간 동안 약 450억 토큰과 7,000여 커밋이 쓰였고, 이후 42,001개 중 41,715개 테스트를 통과했다. 대규모 병렬 개발에서 앞선 것은 에이전트 수가 아니라 리뷰, 소유권, 메인테이너 같은 운영 체계였다.
다수결이 오답을 키울 때
프롬프트를 잘못 이해한 에이전트도 그럴듯한 결과를 내놓는다. 분산시스템에서는 이를 ‘비잔틴 실패’에 빗댈 수 있다. 노드가 중단되는 데 그치지 않고 프로토콜과 다른 임의의 결과를 내는 실패를 뜻한다. 전통적인 비잔틴 합의에서는 잘못된 노드 f개를 견디려면 최소 3f+1개의 노드가 필요하다. 구성원의 3분의 1가량이 요청을 다르게 이해한다면 합의를 어떻게 믿을 수 있겠는가.
그런데 문제는 에이전트들의 실수가 서로 닮았다는 데 있다. 350개가 넘는 LLM을 조사한 ICML 2025 연구에서는 두 모델이 모두 틀렸을 때 같은 오답을 고른 비율이 한 데이터셋에서 60%였다. 같은 제공사와 아키텍처를 쓸수록 오류도 더 비슷했다. 역할을 달리 줘도 마찬가지다. 체계적 풀이, 회의적 검토, 간결한 전문가 역할을 나눈 연구에서 GSM8K 추론의 평균 코사인 유사도는 0.888, 유효 랭크는 3.0 중 2.17이었다. 코사인 유사도는 추론 표현의 유사성을, 유효 랭크는 세 역할이 제공한 독립 정보의 수를 나타내며 각각 1과 3에 가까울수록 유사성과 다양성이 높다. 말투는 달라도 판단 근거는 겹쳤다.
그런데 다수결은 판단자들의 오류가 독립적일 때 효과가 있다. 같은 편향을 공유한 에이전트가 많다면 투표는 오답에 확신만 더한다. 컴파일러, 타입 검사, 테스트, 정적 분석처럼 모델과 다른 방식으로 판단하는 검증자가 필요한 이유다.
더 똑똑한 모델보다 단단한 프로토콜
모델이 아무리 똑똑해져도 분산 합의의 한계는 사라지지 않는다. 대신 프로토콜을 갖추면 그 안에서 안정적으로 일할 수 있다. 실패 탐지기가 있으면 응답이 끊긴 프로세스를 계속 기다리지 않아도 된다. 합의에 필요한 최소 실패 탐지 조건 Ω도 1996년에 정립됐다. Ω는 정상 프로세스들이 같은 정상 리더 하나를 신뢰하게 되는 실패 탐지 조건이다. 실무에서는 생존 확인, 타임아웃, 작업 재할당이 여기에 해당한다.
그러나 Git과 worktree만으로는 부족하다. 격리는 충돌을 늦게 보여줄 뿐 결정의 우선순위까지 정해주지 않는다. 어떤 설계를 기준으로 삼을지, 누가 수정할지, 충돌하면 무엇을 폐기하고 어떻게 복구할지를 기록해야 한다. 테스트와 타입 검사는 그럴듯하지만 틀린 결과를 잡아내 재시도 가능한 실패로 바꾼다.
명세 역시 사람이 읽는 문서에 머물러서는 안 된다. 요구사항마다 테스트나 수동 판정 절차를 연결하면 핸드오프마다 이행 여부를 확인하는 계약이 된다. Grit이 공유 계획 파일 대신 티켓 시스템을 택한 것도 소유권과 완료 상태를 분명히 하기 위해서였다.
병목이 에이전트의 지능일까. 에이전트 수를 늘리기보다 생존 확인, 외부 검증, 결정 확정 절차가 먼저다.
자동화가 넓어질수록 사람의 역할은 코드 작성에서 결정의 경계를 관리하는 쪽으로 이동한다. 같은 모델과 도구를 쓰더라도 생산성 차이는 어떤 판단을 공유하고 어떤 판단을 독립시켰는지에 따라 생긴다.