하룻밤에 코드베이스가 두 배가 됐다. 근데 그게 전부가 아니었다
23개 AI 에이전트를 밤 11시 45분에 풀어놓고 아침 6시 34분에 결과를 확인했다. Next.js 코드베이스는 2만 8천 줄에서 5만 6천 줄로 불어났고, TypeScript 파일 264개, 커밋 120개, TypeScript 에러 0개. dev.to에 올라온 이 실험 후기는 읽는 순간 손이 떨렸다.
그런데 나는 이 글을 보면서 감탄보다 먼저 질문이 떠올랐다. 저 코드, 실제로 얼마나 믿을 수 있나?
속도 문제는 이미 풀렸다. 이제 진짜 싸움은 '리뷰'다
23개 에이전트 실험의 저자가 직접 꼽은 핵심 교훈은 예상 밖이다. "1개 에이전트일 때 병목은 코드 생성이다. 23개가 되면 병목은 머지 해결과 리뷰로 이동한다." 스펙 작성보다 diff 요약 읽는 시간이 더 길었다는 고백이다.
이게 팀 리드 입장에서 굉장히 중요한 신호다. AI 에이전트 병렬화는 기술적으로 이미 가능하다. 문제는 그 출력을 소화할 인간 쪽의 처리 용량이다. 아무리 에이전트를 늘려도 리뷰어가 한 명이면 파이프라인 전체가 거기서 막힌다.
98.6%라고 믿었던 AI 리뷰 품질, 실제론 69%였다
여기서 두 번째 데이터가 치명적으로 들어온다. dev.to의 또 다른 실험 보고서는 449건의 AI 코드 리뷰를 AI 스스로 평가하게 했더니 98.6% 유효하다고 나왔다고 전한다. 그런데 실제 코드 diff를 직접 읽은 독립적인 40개 AI 인스턴스로 검증하자 숫자는 68.9%로 떨어졌다.
30포인트 갭. 이게 그냥 통계 오차가 아니다. AI가 자기 출력을 평가할 때 코드 자체를 보는 게 아니라 텍스트가 그럴듯하게 들리는지를 판단한다는 구조적 문제다. 저자의 표현을 빌리면 "자기 시험지를 자기가 채점하는데 글씨체가 예쁜지 보는 것"과 같다.
실제로 발견된 4건의 완전 무효 리뷰 중 하나는 7,362줄 diff에 존재하지도 않는 함수 패턴을 자신 있게 설명했고, 다른 하나는 187줄짜리 테스트 파일이 PR에 버젓이 있는데 "테스트 없음"이라고 결론 냈다. AI가 실제 코드를 읽는 게 아니라 훈련 데이터의 패턴을 대입한 것이다.
병렬 에이전트 운영의 설계 원칙: 파일이 아닌 기능으로 격리하라
다시 23개 에이전트 실험으로 돌아오면, 이 실험이 성공한 핵심 이유 중 하나는 격리 단위를 파일이 아닌 기능(feature domain)으로 잡은 것이다. 파일 단위로 에이전트를 나누면 충돌이 필연이지만, 기능 단위로 나누면 각 에이전트가 자연스럽게 서로 다른 영역을 건드린다.
실제로 같은 파일을 건드린 경우는 있었다. app/globals.css에 다크모드·애니메이션·모바일 세 에이전트가 동시에 손을 댔는데, CSS는 클래스를 추가하는 방식이라 충돌이 비교적 깔끔하게 해결됐다. TypeScript 파일에서 동일한 Drizzle ORM 스키마에 두 에이전트가 각각 다른 필드를 추가했을 때는 수동 머지가 필요했고 5분이 걸렸다. 이게 23개 에이전트 전체를 통틀어 두 번 있었다.
또 하나 인상적인 조율 메커니즘은 GitHub 이슈를 에이전트 간 통신 단위로 쓴 것이다. 에이전트는 이슈를 읽고, 작업하고, 닫는다. 280개 커밋 전부에 대응하는 이슈가 댓글과 함께 닫혔다. 무슨 에이전트가 뭘 했는지 추적 가능한 감사 로그가 자동으로 생긴 셈이다.
Claude Code와 Cursor를 함께 쓰는 팀이라면, 역할 분리가 먼저다
도구 선택 이야기도 빼놓을 수 없다. dev.to에서 두 도구를 실제로 병행 사용하는 워크플로우를 공개한 글에 따르면, Cursor는 '내가 직접 운전할 때', Claude Code는 '대신 운전하게 할 때' 쓰는 식으로 나뉜다.
- Cursor: 인라인 탭 완성, 2~3개 파일 수준의 빠른 수정, 에디터 내 즉각적인 질문
- Claude Code: 6개 파일 이상 기능 단위 오케스트레이션, 테스트 실행, 자율 실행 루프, 대형 코드베이스 아키텍처 추론
23개 에이전트 실험처럼 완전 자율 병렬 실행 시나리오라면 Claude Code가 훨씬 적합하다. Cursor는 개발자가 흐름 안에 있을 때 쓰는 도구고, Claude Code는 개발자가 감독자 역할로 물러설 때 쓰는 도구다.
팀 리드가 지금 당장 챙겨야 할 세 가지
이 세 실험을 같이 놓고 보면 AI-First 팀 운영에서 지금 당장 점검해야 할 포인트가 선명해진다.
첫째, AI 리뷰 품질을 AI에게 물어보지 마라. 98.6% vs 69%의 교훈은 단순하다. 검증은 반드시 ground truth, 즉 실제 코드 diff에 접근 가능한 독립 프로세스가 해야 한다. AI 셀프 평가는 품질 지표가 아니라 허영 지표다.
둘째, 병렬 에이전트를 늘리기 전에 리뷰 파이프라인을 먼저 설계하라. 에이전트 수가 늘면 생성 속도가 아니라 리뷰 용량이 병목이 된다. 23개 에이전트 실험 저자는 다음에는 '충돌 해결 전담 에이전트'를 오케스트레이터 슬롯에 따로 배정하겠다고 했다. 리뷰어 한 명이 120개 커밋을 소화하는 구조는 지속 불가능하다.
셋째, 시드 데이터와 가짜 콘텐츠를 프로덕션 게이트에서 반드시 필터링하라. 23개 에이전트 실험에서 testimonials 기능을 구현한 에이전트는 그럴듯한 가짜 사용자 후기로 시드 데이터를 채웠다. 에이전트는 기능을 '보여줄 수 있게' 만들려는 경향이 있다. 실제 데이터처럼 보이는 가짜 데이터가 프로덕션에 올라가는 건 신뢰 문제다.
앞으로의 방향: '에이전트 조율'이 핵심 역량이 된다
이 실험들이 가리키는 방향은 하나다. 병렬 AI 에이전트 운영은 이제 실험실 밖으로 나왔다. 하룻밤에 코드베이스를 두 배로 불릴 수 있다는 건 이미 증명됐다. 남은 문제는 그 출력을 어떻게 신뢰 가능하게 만들 것이냐다.
팀 리드의 역할은 에이전트 설정이 아니라 에이전트 조율 설계다. 어떤 격리 단위로 에이전트를 나눌지, 어떤 조율 메커니즘으로 충돌을 통제할지, 어떤 검증 레이어로 품질을 잡을지. 이 세 가지를 설계할 수 있는 팀과 그렇지 못한 팀 사이의 격차가 2025년 하반기의 AI-First 역량 격차가 될 것이다.
속도는 이미 해결됐다. 이제 싸워야 할 건 품질이다.