이번 주는 AI 코딩 도구의 역사에서 꽤 의미 있는 한 주였습니다. Cursor, Claude Code, Codex가 거의 동시에 멀티에이전트 기능을 출시했고, Grok Build는 8개, Windsurf는 5개의 에이전트를 병렬로 돌리는 시대가 열렸습니다. 숫자만 보면 생산성이 폭발적으로 올라갈 것 같습니다. 그런데 저는 이 뉴스를 보면서 기대보다 걱정이 먼저 들었습니다.
에이전트가 하나일 때도 품질 문제는 이미 골치였습니다. dev.to의 개발자 Rohan이 공개한 roast-my-code 프로젝트는 그 민낯을 수치로 보여줍니다. AI 코딩 어시스턴트를 1년간 집중적으로 사용하면서 발견한 패턴들—data2, temp, result_final 같은 플레이스홀더 변수명, 곳곳에 박힌 TODO 주석, 빈 except 블록, handle_it이나 do_stuff처럼 책임이 불분명한 함수명—은 기존 린터가 전혀 잡아내지 못합니다. pylint도, flake8도 이런 'AI 슬롭'에는 무감각합니다. 더 무서운 건 이 패턴들이 코드 리뷰를 통과하는 속도입니다. 에이전트 하나가 만든 슬롭도 관리하기 버거운데, 이제 그 에이전트가 5개, 8개, 9개로 늘어납니다.
멀티에이전트의 진짜 문제는 기술적 한계가 아니라 조율의 공백입니다. dev.to에 소개된 reflectt-node 프로젝트가 이 지점을 정확하게 짚습니다. 현재 대부분의 멀티에이전트 환경에서 인간이 직접 수행해야 하는 역할이 세 가지 있습니다. 첫째, 태스크 오너십—Agent A가 인증 리팩토링을 시작했다는 사실을 Agent B가 모릅니다. 둘째, 프레즌스—어떤 에이전트가 루프에 빠져 있고 어떤 에이전트가 유휴 상태인지 아무도 알려주지 않습니다. 셋째, 커뮤니케이션—에이전트끼리 직접 대화하는 채널이 없습니다. 결국 사람이 메시지 라우터이자 태스크 디스패처이자 충돌 해결사 역할을 모두 맡게 됩니다. 에이전트가 3~4개를 넘어가는 순간 이 구조는 스케일이 되지 않습니다.
조율 문제가 해결된다고 해도, 품질의 또 다른 병목은 훨씬 더 근본적인 곳에 있습니다. Claude Code 프롬프트 전략을 다룬 dev.to 아티클은 이를 Margaret과 Timothy의 대화로 날카롭게 포착합니다. "Fix the performance issue in my data processing pipeline"이라는 프롬프트는 사람에게도 불충분하지만, AI에게는 재앙에 가깝습니다. 4백만 건의 레코드, 3시간짜리 타임아웃, 3주 전 추가된 규제 검증 로직—이 모든 컨텍스트가 빠진 프롬프트는 그럴듯하지만 완전히 틀린 답변을 만들어냅니다. 핵심은 이것입니다. 프롬프트의 품질은 사고의 품질입니다. 에이전트가 많아진다는 것은 이 사고의 빈곤이 더 빠른 속도로 더 많은 곳에 증식된다는 뜻이기도 합니다.
세 가지 소스를 교차해서 읽으면 멀티에이전트 시대의 품질 위기가 하나의 구조로 보입니다. 조율 레이어 부재 → 에이전트 간 충돌과 중복 작업 → 슬롭 패턴 누적 → 검증 도구 부재 → 리뷰 통과. 각 단계는 독립적 문제처럼 보이지만 실은 연결된 파이프라인입니다. 에이전트를 늘리면 속도는 올라가지만, 이 파이프라인의 어느 한 단계가 약하면 품질 하락은 속도에 비례해서 빨라집니다. 오케스트레이터(무엇을 할지 지시하는 레이어)와 코디네이션 서버(공유 상태를 제공하는 인프라)를 구분해야 한다는 reflectt-node 저자의 통찰은, 바로 이 파이프라인의 첫 번째 구멍을 메우는 시도입니다.
프론트엔드 개발자 입장에서 이 흐름이 불편한 이유는 명확합니다. 컴포넌트 단위의 작업이 쪼개져 여러 에이전트에 분산되면, 디자인 시스템 일관성이나 마이크로 인터랙션 디테일은 가장 먼저 희생됩니다. UI 슬롭은 코드 슬롭보다 눈에 바로 보이지 않습니다. 버튼 하나의 포커스 스타일이 누락되거나, 에러 상태 처리가 빠지거나, 접근성 속성이 뭉개지는 건 린터도, AI도 잘 잡아내지 못합니다. roast-my-code처럼 AI 슬롭을 탐지하는 도구가 코드 레벨에서 나왔다면, UI/UX 레벨의 슬롭 탐지 도구는 아직 공백입니다.
결국 에이전트의 수가 늘어날수록 중요해지는 건 더 많은 자동화가 아니라 더 정교한 게이트입니다. 어떤 태스크를 어떤 에이전트에 할당할지 판단하는 컨텍스트 설계, 에이전트 산출물에 대한 계층적 검증 레이어, 그리고 슬롭 패턴을 조기에 잡는 정적 분석 도구—이 세 가지가 멀티에이전트 워크플로우의 품질을 결정할 것입니다. 속도를 얻는 건 이미 해결됐습니다. 이제 남은 질문은 '그 속도로 만든 것이 믿을 만한가'입니다.