AI 코딩 에이전트는 왜 같이 일할수록 약해질까: 멀티 에이전트보다 중요한 조정 능력

핵심 요약

스탠퍼드 연구가 던진 질문: AI는 팀원이 될 준비가 되었나

기사에서 소개된 스탠퍼드 HAI의 연구는 코딩 에이전트가 단독으로 일할 때와 협업할 때의 성능 차이를 다룬다. 연구진은 여러 프로그래밍 언어와 소프트웨어 엔지니어링 과제를 바탕으로 에이전트들이 서로 메시지를 주고받고, 코드를 작성하고, 명령을 실행하며 협업하도록 설계했다. 중요한 점은 단순한 코딩 능력만 본 것이 아니라, 충돌하는 상황에서 에이전트가 상대와 어떻게 조정하는지를 보았다는 점이다.

결과의 핵심은 “조정 격차”다. 에이전트가 언어를 유창하게 쓰고 코드도 만들 수 있지만, 협업 상황에서 그 언어를 사회적 행동으로 안정적으로 연결하지 못한다. 누군가 충돌을 경고해도 상대가 무시하거나, 어떤 파일의 어느 부분을 왜 바꿔야 하는지 충분히 합의하지 못하거나, 작업 경계를 흐릿하게 만든다. 사람 팀에서라면 신뢰를 깨는 행동이 AI 에이전트 사이에서도 그대로 성능 저하로 나타나는 셈이다.

현장에서 실제로 벌어지는 그림: 두 에이전트가 같은 문제를 서로 다른 방식으로 고칠 때

예를 들어 작은 SaaS 대시보드에 “사용자별 결제 상태를 보여주는 카드”를 추가한다고 해보자. 한 에이전트에게는 API 응답 타입과 백엔드 라우트를 맡기고, 다른 에이전트에게는 프론트엔드 카드 컴포넌트를 맡긴다. 겉으로는 완벽한 병렬 작업처럼 보인다. 백엔드 에이전트는 paymentStatus 필드를 만들고, 프론트엔드 에이전트는 디자인 시스템에 맞춰 카드 UI를 만든다.

문제는 둘이 “상태 값의 계약”을 공유하지 않았을 때 시작된다. 백엔드는 active, past_due, cancelled를 반환하는데 프론트엔드는 paid, overdue, expired를 예상한다. 한쪽은 날짜를 ISO 문자열로 넘기고, 다른 한쪽은 이미 포맷된 한국어 날짜를 기대한다. 각자의 작업만 보면 그럴듯하지만 합치면 빈 카드가 나오거나, 테스트가 서로 다른 mock 데이터를 기준으로 통과한다.

이때 사람 개발자는 보통 회의나 PR 코멘트에서 “상태 enum부터 맞추자”, “API contract를 먼저 고정하자”, “mock 데이터를 하나로 쓰자”고 조정한다. 하지만 에이전트 둘을 동시에 돌리면 이 조정이 자동으로 일어나지 않는다. 에이전트는 상대가 무엇을 암묵적으로 기대하는지 충분히 추론하지 못하고, 자기 작업 영역 안에서만 문제를 해결하려 한다.

더 위험한 사례: 한 에이전트가 리팩터링하고, 다른 에이전트가 기능을 추가할 때

가장 흔한 멀티 에이전트 사고는 리팩터링과 기능 개발이 겹칠 때 나온다. 에이전트 A는 파일 구조를 정리한다. 오래된 훅을 합치고, 타입 이름을 바꾸고, 공통 유틸을 분리한다. 에이전트 B는 같은 시간에 새 기능을 추가한다. B는 기존 파일 경로와 타입 이름을 기준으로 코드를 작성한다. 둘 다 단독으로 보면 합리적인 작업이다.

하지만 마지막에 합치면 충돌은 단순한 Git conflict보다 복잡해진다. 경로가 바뀌었고, 타입 이름이 바뀌었고, B가 추가한 기능은 A가 삭제한 helper에 의존한다. 더 까다로운 점은 둘 다 “왜 그렇게 바꿨는지” 설명은 하지만, 어느 변경이 우선인지 결정하지 못한다는 것이다. 결국 사람은 두 에이전트의 산출물을 합치는 사람이 아니라, 두 명의 주니어 개발자가 동시에 같은 코드베이스를 흔든 뒤 남긴 흔적을 수습하는 사람이 된다.

왜 “프롬프트를 더 잘 쓰면 되지 않나”로 해결되지 않을까

물론 지시문은 중요하다. “서로 충돌하지 마”, “변경 전 파일을 확인해”, “작업 범위를 벗어나지 마” 같은 문장은 도움이 된다. 하지만 협업 실패의 핵심은 단순 지시 부족이 아니다. 에이전트가 협업에서 요구되는 사회적 기술을 실제 행동으로 안정적으로 수행하지 못한다는 점이다.

사람 팀의 협업은 말 이상으로 작동한다. 누군가 “이 파일 내가 만지고 있어요”라고 말하면 다른 사람은 기다리거나, 먼저 interface를 정하거나, 작은 PR로 나눈다. 누군가 “이 변경은 위험해요”라고 말하면 팀은 왜 위험한지 묻고, 우선순위를 조정하고, 롤백 기준을 만든다. 협업은 정보를 전달하는 행위가 아니라 신뢰, 순서, 약속, 책임을 조율하는 행위다.

현재의 많은 코딩 에이전트는 언어로 그럴듯한 협업 메시지를 만들 수 있지만, 그 메시지를 지속적인 약속 관리로 연결하는 능력은 약하다. 그래서 에이전트끼리 “좋습니다, 제가 이 부분을 맡겠습니다”라고 말해도 실제로는 같은 파일을 건드리거나, 이미 합의한 타입을 바꾸거나, 테스트 없이 완료했다고 판단할 수 있다.

실무자가 써먹을 수 있는 멀티 에이전트 운영 패턴

그렇다고 멀티 에이전트를 쓰지 말아야 한다는 뜻은 아니다. 문제는 “동시에 많이 돌리는 것”을 협업이라고 착각하는 데 있다. 안전한 운영은 병렬성이 아니라 경계에서 시작한다.

• 첫째, 공유 계약을 먼저 고정한다. API schema, 타입 이름, 파일 경계, 테스트 기준을 사람이 먼저 정한다. 에이전트에게는 이 계약을 바꾸지 말라고 지시한다.
• 둘째, 역할을 기능 기준이 아니라 산출물 기준으로 나눈다. 한 에이전트는 구현, 다른 에이전트는 리뷰, 또 다른 에이전트는 테스트 보강처럼 산출물이 겹치지 않게 나눈다.
• 셋째, 병렬 작업보다 순차 검증을 우선한다. 에이전트 A의 결과를 lint/build/test로 확인한 뒤 에이전트 B가 그 상태를 기준으로 작업하게 한다.
• 넷째, 충돌 가능성이 높은 리팩터링은 단독 작업으로 둔다. 파일 이동, 타입 재정의, 공통 유틸 분리는 다른 기능 개발과 동시에 시키지 않는다.
• 다섯째, 완료 보고를 믿지 말고 산출물을 읽는다. 에이전트가 “완료”라고 해도 diff, 테스트 결과, 실제 렌더링, 데이터 흐름을 확인해야 한다.

제품 관점의 교훈: 미래의 에이전트 플랫폼은 모델보다 조율 계층이 중요해진다

이 연구가 중요한 이유는 코딩 도구에만 머물지 않는다. 앞으로 기업은 영업, 고객지원, 재무, 인사, 법무, 개발 업무에 여러 AI 에이전트를 붙이려 할 것이다. 그때도 같은 문제가 반복된다. 고객지원 에이전트가 환불 가능하다고 판단했는데, 결제 에이전트는 정책상 불가능하다고 보고, CRM 에이전트는 고객 등급을 다르게 읽는다면 어떻게 할 것인가.

결국 필요한 것은 더 많은 에이전트가 아니라 조율 계층이다. 누가 최종 권한을 갖는지, 어떤 데이터가 기준인지, 예외가 생기면 누구에게 넘기는지, 에이전트가 한 약속을 어떻게 기록하고 검증하는지 정해야 한다. 이 계층이 없으면 에이전트는 많아질수록 똑똑한 조직이 아니라 시끄러운 조직이 된다.

반대로 봐야 할 점: 지금의 실패가 멀티 에이전트의 종말은 아니다

협업 실패 연구를 보고 “AI 에이전트는 팀으로 쓰면 안 된다”고 결론 내리면 너무 단순하다. 지금 드러난 것은 불가능성이 아니라 설계 과제다. 인간도 협업을 잘하려면 티켓, 코드 리뷰, CI, 브랜치 전략, 회의, 문서, 온보딩이 필요하다. AI 에이전트도 마찬가지로 팀워크를 위한 별도의 구조가 필요하다.

다만 중요한 차이가 있다. 사람은 사회적 맥락을 경험으로 배운다. AI 에이전트는 그 맥락을 시스템이 제공해줘야 한다. 따라서 앞으로의 경쟁력은 “가장 똑똑한 단일 모델”만이 아니라, 모델이 서로의 작업을 확인하고, 약속을 지키고, 충돌을 해결하도록 만드는 운영 시스템에서 나올 가능성이 크다.

FAQ

코덱스와 클로드 코드를 같이 쓰면 안 되나?

무조건 안 된다는 뜻은 아니다. 다만 같은 코드 영역을 동시에 고치게 하면 충돌과 조정 비용이 커진다. 하나는 구현, 하나는 리뷰나 테스트처럼 역할을 분리하는 편이 안전하다.

멀티 에이전트가 단일 에이전트보다 항상 나쁜가?

아니다. 작업 경계가 명확하고 산출물이 겹치지 않으며 검증 순서가 분명하면 도움이 될 수 있다. 문제는 경계 없이 병렬로 던지는 방식이다.

실무에서 가장 먼저 정해야 할 것은 무엇인가?

공유 계약이다. API schema, 타입, 파일 소유권, 테스트 기준, 변경 금지 영역을 먼저 정해야 에이전트의 병렬 작업이 실제 생산성으로 이어진다.

결론: AI 에이전트 시대의 실력은 많이 돌리는 능력이 아니라 잘 조율하는 능력이다

AI 코딩 에이전트는 이미 강력하다. 하지만 강력한 도구 여러 개를 동시에 켠다고 팀이 생기지는 않는다. 팀은 약속, 경계, 검증, 책임으로 만들어진다. 앞으로 개발자의 역할은 코드를 직접 쓰는 사람에서 에이전트를 지휘하는 사람으로 바뀔 수 있다. 그러나 그 지휘는 단순한 프롬프트 입력이 아니다. 좋은 작업 단위로 쪼개고, 충돌을 막고, 결과를 검증하고, 에이전트가 지키지 못하는 사회적 약속을 시스템으로 보완하는 운영 능력이다.