에이전트 하나가 10배 생산성이라면, 열 개는 100배다. 이 수식은 직관적이다. 백엔드 에이전트, 프론트엔드 에이전트, 테스트 에이전트, 문서 에이전트가 동시에 달리면 5인 팀이 50인 팀의 산출물을 낸다는 계산이 나온다. 팀 리드로서 이 논리의 유혹을 부정하기 어렵다. 실제로 초반 1~2개월은 그렇게 흘러간다. PR이 쏟아지고, 시스템이 빠르게 형태를 갖춘다.
그런데 3개월째부터 균열이 시작된다. dev.to에 연재된 'Fallacies of GenAI Development' 시리즈의 마지막 편은 이 균열의 정체를 정확히 짚는다. 백엔드 에이전트는 JSON 필드명을 camelCase로 썼고, 프론트엔드 에이전트는 snake_case를 기대했으며, DB 마이그레이션 에이전트는 PascalCase를 골랐다. 각자의 결정은 합리적이었다. 문제는 아무도 서로의 결정을 몰랐다는 것이다. 버그는 'UI가 잘못된 값을 보여준다'는 형태로 나타났고, 원인을 추적하는 데 이틀이 걸렸다.
이 문제에는 이미 이름이 있다. 분산 시스템이다. 분산 시스템 엔지니어들이 40년에 걸쳐 배운 교훈은 단순하다. 노드를 늘려서 시스템을 확장할 수 없다. 프로토콜을 추가해야만 확장된다. 합의 메커니즘, 순서 보장, 충돌 해결 규칙, 인터페이스 계약이 없으면 노드가 늘수록 충돌이 늘어날 뿐이다. AI 에이전트도 정확히 같은 구조다. 각 에이전트는 로컬 컨텍스트 안에서만 결정을 내린다. 전체 그림을 보는 에이전트는 없다. 스펙 없는 에이전트를 늘리는 건 프로토콜 없는 노드를 늘리는 것과 동일하다.
해당 시리즈가 서술하는 실패 타임라인은 팀 리드라면 소름이 돋을 수준으로 구체적이다. 5~6개월째엔 재시도 전략이 충돌한다. 백엔드 에이전트는 지수 백오프를 구현했고, API 게이트웨이 에이전트는 3초 고정 딜레이를 골랐다. 둘 다 유효한 전략이다. 그러나 함께 작동하면 느린 다운스트림 서비스에 thundering herd가 발생한다. 9~10개월째엔 에이전트 편집 전쟁이 시작된다. Google의 Adam Bender가 'Software Engineering at the Tipping Point'에서 명명한 agentic edit war—에이전트 A는 공유 유틸리티를 성능 최적화로 리팩터하고, 에이전트 B는 가독성 개선으로 덮어쓴다. 둘 다 토큰을 소모하고, 결과는 아무것도 남지 않는다. 분산 시스템 용어로는 라이브락(livelock)이다. AI 개발 용어로는 API 청구서다.
여기서 두 번째 소스가 연결된다. RAG 메모리 테스트 자동화 사례를 다룬 dev.to 아티클은 오전 2시에 울린 알람으로 시작한다. 지원 봇이 같은 사용자의 과거 주문을 뒤섞어버렸다. 원인은 같은 session_id를 가진 다른 토픽 대화가 병합된 경계 조건이었다. 그날 오후 40개가 넘는 테스트 케이스를 수동으로 돌렸지만 이 조합은 빠져나갔다. 수동 추적으로는 이 간극을 메울 수 없다는 결론이 나온 순간이었다.
이 팀이 선택한 해법은 의미론적 자동화 평가 파이프라인이다. LangChain의 VectorStoreRetrieverMemory에 ChromaDB를 붙이고, pytest로 테스트 하네스를 구성했다. 핵심 설계 원칙은 세 가지다. 인텐트 템플릿 기반의 자동 테스트 데이터 생성, 임시 디렉터리에서 격리 실행되는 ChromaDB 픽스처, 그리고 문자열 매칭이 아닌 코사인 유사도와 핵심 엔티티 매칭을 결합한 의미론적 평가다. '제안서 어떻게 됐어?'와 '저번에 얘기하던 파란 거' 사이에 공통 단어가 없어도 의미적으로 매칭돼야 한다는 걸 정규식은 처리할 수 없다. 이 파이프라인 전환 이후 임베딩 모델이나 메모리 전략을 바꿀 때마다 시맨틱 드리프트가 즉시 감지됐고, 새벽 2시 알람은 사라졌다.
두 사례를 나란히 놓으면 같은 교훈을 가리킨다. 에이전트는 늘리기 전에 검증 구조를 먼저 설계해야 한다. 다중 에이전트 시스템에서 분산 시스템의 프로토콜에 해당하는 것은 네이밍 컨벤션 스펙, API 계약, 아키텍처 우선순위 규칙, 그리고 머지 게이트의 스펙 강제 검사다. RAG 시스템에서 수동 판단에 해당하는 것은 의미론적 자동 평가로 대체돼야 한다. 둘 다 에이전트가 '작동하는 것처럼 보이는 상태'와 '실제로 올바르게 작동하는 상태'를 구분하는 메커니즘 없이는 스케일이 독이 된다는 점에서 같다.
팀 리드 관점에서 실행 순서를 정리하면 이렇다. 첫째, 에이전트를 추가하기 전에 공유 스펙 레포를 먼저 만든다. 네이밍 컨벤션, 에러 핸들링 전략, 재시도 정책이 문서화되고 모든 에이전트 프롬프트에 주입돼야 한다. 둘째, CI 파이프라인에 스펙 준수 검증 게이트를 심는다. 에이전트가 생성한 코드가 계약을 위반하면 머지가 막혀야 한다. 셋째, RAG나 메모리 레이어처럼 '느낌상 맞다'로 평가하던 영역은 의미론적 자동 테스트로 전환한다. 수동 추적으로 커버할 수 없는 조합 공간은 자동화만이 메운다.
에이전트 수가 늘어날수록 조율 실패의 비용은 선형이 아니라 지수로 증가한다. 이건 분산 시스템이 이미 증명한 사실이다. AI-First 팀이 지금 해야 할 일은 에이전트를 더 구하는 게 아니라, 에이전트들이 서로 모순 없이 작동할 수 있는 구조를 먼저 짜는 것이다. 프로토콜 없는 확장은 생산성이 아니라 기술 부채를 복리로 쌓는 일이다.