'하나의 AI로 다 해결하겠다'는 발상은 직관적으로 매력적이다. 도구를 하나만 쓰면 컨텍스트 전환이 없고, 파이프라인도 단순하다. 문제는 그 단순함이 실제로 작동하지 않는다는 데 있다. 기획, 실행, 검증은 성격이 다른 작업이고, 동일한 모델에 동일한 토큰을 쏟아붓는다고 품질이 고르게 나오지 않는다.
dev.to에 올라온 실전 사례 하나가 이 문제를 구체적으로 짚는다. 개발자 freema는 Claude Code, Cursor Composer 2, Claude를 각각 계획자-실행자-검토자 역할로 분리해 연결하는 멀티 에이전트 워크플로우를 직접 구축했다. 핵심 판단은 간단하다. Claude Code는 장기 컨텍스트 세션과 서브에이전트 구성 덕분에 계획 품질이 높고, Cursor Composer 2는 파일 편집과 반복적인 기계적 작업에 최적화돼 있다. 그리고 diff 검토는 다시 Claude로 돌린다. 각 단계에서 비싼 프론티어 모델 토큰을 쓸 이유가 없는 작업—코드베이스 전체 rename, placeholder 치환, E2E 브라우저 클릭—은 Composer로 넘기고, Claude 사이클은 판단이 필요한 계획과 검토에만 집중시킨다.
이 구조를 매번 수작업으로 연결하는 건 비효율이다. 그래서 freema는 8개의 /cursor:* 슬래시 커맨드와 자동 위임 서브에이전트를 포함한 Claude Code 플러그인으로 패키징했다. 런타임 의존성 없이 핸드오프 비용을 0으로 낮춘 것이다. 여기서 주목할 포인트는 '더 싼 모델 쓰기'가 목적이 아니라는 점이다. 강점이 다른 에이전트를 작은 팀처럼 운용하는 것—플래너, 이그제큐터, 리뷰어를 명시적으로 나누는 설계 결정 자체가 핵심이다.
그런데 역할 분리는 에이전트 오케스트레이션 레벨에서만 필요한 게 아니다. AI가 생성한 코드 자체의 품질 판단에서도 똑같은 문제가 존재한다. 18년 경력의 iOS 개발자 elangbamjohnson이 공개한 AIAnalyzer는 이 문제를 정면으로 건드린다. SwiftSyntax 기반으로 God Object, 책임 혼재 같은 아키텍처 스멜을 탐지하고, AI 수정 제안을 로컬 LLM과 클라우드 API 중 어디서 받을지 실시간으로 판단하는 하이브리드 구조를 갖는다.
이 도구의 핵심은 신뢰도 기반 폴백이다. 로컬 모델(Ollama 또는 Core ML)로 먼저 시도하고, 출력 품질을 자체 평가한 뒤 신뢰도가 낮을 때만 Gemini 클라우드 API를 호출한다. 클라우드 전용은 품질이 높지만 컴플라이언스 제약 환경에서 쓸 수 없고, 로컬 전용은 프라이버시는 보장하지만 약한 제안을 자신 있게 내놓는 위험이 있다. 흥미로운 건 이 도구를 자기 자신에게 돌렸더니 제 코드베이스에서 God Object를 발견했다는 것이다. AnalyzerApp.swift가 695줄짜리 신의 객체로 자라 있었고, 이를 네 개의 명확한 책임 단위로 쪼개야 했다.
두 사례를 나란히 놓으면 하나의 패턴이 보인다. 역할을 명시적으로 분리하지 않으면 품질 통제 지점도 사라진다. freema의 워크플로우에서 검토 단계를 Claude에 별도로 붙이지 않았다면, Composer가 기계적으로 처리한 diff는 아무도 검증하지 않은 채 커밋됐을 것이다. AIAnalyzer에서 신뢰도 평가 없이 로컬 모델 제안을 그냥 출력했다면, 얕은 제안이 마치 올바른 답인 양 소비됐을 것이다. 두 경우 모두 '동작은 한다'—단지 품질이 보장되지 않을 뿐이다.
팀 레벨로 올려보면 시사점이 더 직접적이다. AI-First 워크플로우를 도입할 때 가장 먼저 무너지는 지점은 검토 단계다. 에이전트가 코드를 빠르게 생성하면 리뷰 속도가 병목처럼 느껴지고, 리뷰를 생략하거나 형식화하려는 압력이 생긴다. 그러나 freema의 구조처럼 리뷰 자체를 파이프라인에 명시적으로 붙이거나, AIAnalyzer처럼 품질 판단을 도구 안에 내재화하지 않으면—속도를 얻는 대신 검증 루프를 통째로 잃는 트레이드오프가 발생한다.
앞으로의 방향도 이 틀에서 크게 벗어나지 않을 것이다. 에이전트 수가 늘수록, 각 에이전트에게 무엇을 맡기고 어떤 출력을 어떻게 검증할지를 명시적으로 설계하는 역량이 팀의 실질적인 경쟁력이 된다. '어떤 모델이 더 좋냐'는 질문보다 '역할 경계를 어디서 그을 것이냐'는 설계 결정이 결과를 가른다. 플래너, 이그제큐터, 리뷰어—이 세 역할을 파이프라인 안에서 명확히 분리하는 팀이, 하나의 강력한 모델에 모든 걸 위임하는 팀보다 더 안정적인 품질을 낼 가능성이 높다.