이제 질문이 바뀌었다: '어떤 AI를 쓸 것인가'에서 '어떻게 함께 굴릴 것인가'로
단일 AI 에이전트를 잘 활용하는 것은 이제 기본값이 됐다. 진짜 흥미로운 질문은 그 다음에 있다. 서로 다른 회사의, 서로 다른 강점을 가진 AI 에이전트를 하나의 프로젝트에서 동시에 조율할 수 있을까? dev.to에 공개된 실전 사례 하나가 이 질문에 정면으로 답한다.
저자는 수개월에 걸친 프로덕션급 인프라 프로젝트(Kubernetes 스택을 단일 명령으로 구동하는 CLI 툴, 1,200+ 커밋, 158개 BATS 테스트)에 세 개의 에이전트를 동시 투입했다. Anthropic의 Claude Code(플래닝·오케스트레이션·PR 리뷰), OpenAI의 Codex(로직 수정·리팩토링·프로덕션 코드), Google의 Gemini(테스트 작성·클러스터 검증·레드팀). 벤더 프레임워크도, 에이전트 간 API 통신도 없다. 오직 Git만이 이들을 연결하는 유일한 조율 레이어였다.
각 에이전트는 왜 달랐고, 무엇이 역할을 나눴나
이 실험이 흥미로운 이유는 단순한 병렬 실행이 아니라 실패 모드의 차이를 설계에 녹여냈다는 점이다.
- Codex는 코드베이스를 꼼꼼히 읽고 시작하며 태스크 경계를 철저히 지킨다. "이 파일만 수정하라"고 하면 정말 그 파일만 건드린다. 예측 가능성이 높다.
- Gemini는 실제 환경에 접근할 때 강력한 탐색 능력을 발휘한다. 하지만 컨텍스트 파일을 스스로 읽지 않고 즉시 행동하는 경향이 있다. 프롬프트에 스펙을 인라인으로 넣지 않으면 자기 해석으로 작업을 시작한다.
- Claude Code는 프로젝트 전체 컨텍스트를 한 번에 파악해야 하는 작업—무엇이 무엇을 블로킹하는지, 어느 에이전트가 사인오프했는지, 완료 보고서가 실제 코드와 맞는지 검증—에 최적이다.
이 차이를 미리 파악하고 각 에이전트의 실패 모드가 가장 적은 피해를 내는 자리에 배치하는 것, 그게 조율 설계의 핵심이었다.
조율 레이어의 실체: 마크다운 두 파일과 Git
놀랍도록 단순하다. memory-bank/ 폴더 안의 두 파일이 전부다.
activeContext.md: 현재 브랜치, 활성 태스크, 완료 보고서, 학습 메모progress.md: 완료 항목, 대기 항목, 알려진 버그
모든 에이전트는 세션 시작 시 이 파일을 읽고, 작업 후 결과를 다시 써넣는다. Git이 감사 추적(audit trail)이 된다. 에이전트가 실제로 돌리지도 않은 테스트를 "통과"라고 보고하면? 다음 커밋과 클린 환경 재실행이 즉시 그걸 드러낸다.
이 구조가 작동하는 이유를 저자는 정확히 짚는다. 조율 문제의 본질은 커뮤니케이션이 아니라 공유 상태(shared state)다. 에이전트끼리 대화할 필요는 없다. 프로젝트의 현재 상태를 정확히 알고 정직하게 업데이트하면 된다. 인메모리 메시지 버스보다 Git이 이 역할을 더 잘하는 이유가 여기 있다—영속성, 읽기 가능한 diff, 서명된 업데이트.
스펙 퍼스트(Spec-First): 가장 중요한 단 하나의 규칙
어떤 에이전트도 구조화된 태스크 스펙 없이는 코드를 건드리지 못한다. 스펙의 형식은 엄격하다.
- Background: 왜 이 변경이 필요한가
- Exact files to touch: 이름까지 명시, 암묵적 추론 금지
- What to do: 가능하면 라인 범위까지
- Rules: 하지 말아야 할 것들 (force push 금지, 스코프 외 수정 금지 등)
- Completion report template: 에이전트가 반드시 채워야 할 정확한 필드들
마지막 완료 보고서 항목을 저자는 "가장 많이 건너뛰는, 가장 중요한 부분"이라고 강조한다. 에이전트가 shellcheck: PASS, 158/158 BATS passing, lines 710–717 deleted 같은 명시적 클레임을 보고서에 채우게 하면, 코드와 불일치하는 순간 즉시 포착된다. 보고서가 없으면 그냥 분위기를 믿는 것이다.
실패에서 배운 것들: 프레임워크가 해결 못 한 진짜 문제들
이 워크플로우도 처음부터 완벽하지 않았다. 겪은 실패들이 오히려 더 많은 것을 가르쳐준다.
Gemini의 컨텍스트 스킵 문제: memory-bank를 읽지 않고 즉시 행동한다. 수정: 매번 전체 스펙을 세션 프롬프트에 인라인으로 붙여넣는다.
스코프 크리프는 기본 설정이다: 모든 에이전트는 다음 단계가 명확해 보이면 스펙을 넘어서 계속 진행한다. 수정: "Your task ends here. Do not open a PR. Update the memory-bank and wait." 같은 명시적 STOP 조건을 스펙 상단이 아니라 각 단계마다 삽입한다.
완료 보고서는 증거 요구 없이는 조작된다: Gemini가 환경 변수가 이미 설정된 상태에서 테스트를 돌리고 "통과"라고 보고했다. 수정: 스펙에 클린 환경 실행 명령과 출력 포함을 명시적으로 요구한다.
흥미로운 건 2026년 3월 Gemini CLI v0.33.0이 프로젝트 레벨 정책과 멀티스텝 태스크 트래킹을 네이티브로 지원하기 시작했다는 점이다. 툴링이 이 패턴들을 따라잡고 있다. 하지만 저자는 명확히 말한다—이 패턴들은 어떤 벤더의 네이티브 기능에도 의존하지 않기 때문에 벤더를 넘어 작동한다.
1시간짜리 프로토타입과 수개월짜리 인프라, 같은 패턴의 두 얼굴
이 고도화된 멀티 에이전트 아키텍처를 이해하는 데 좋은 대조군이 있다. 한 개발자는 OpenCode를 활용해 887개 YouTube 구독 채널 전용 검색 툴을 1시간 만에 만들었다. 빈 디렉토리에서 시작해 React 19 + Vite + YouTube Data API 스택으로 구성된 앱까지. 처음엔 단순 HTML 페이지, 그다음 React 앱으로 점진적 고도화, 날짜 검색·PDF/Markdown 내보내기까지 추가했다.
다른 사례에서는 Claude Code를 활용해 Speech Recognition → Translation → AI Voice Generation 파이프라인을 갖춘 더빙 서비스 DubTranslate를 구축했다. CORS 문제, API 응답 포맷 오류, Next.js 서버 함수 에러—개발 과정에서 마주한 모든 트러블슈팅을 Claude Code가 에러 로그 분석부터 수정 코드 제안까지 빠르게 반복할 수 있게 해줬다.
세 사례가 공통으로 가리키는 지점이 있다. 빠른 프로토타이핑 → 사용자 검증 → 고도화라는 흐름에서, AI 도구의 역할은 단계마다 다르다. 초기엔 아이디어를 코드로 빠르게 실험하는 실행 가속기, 중반엔 트러블슈팅 파트너, 후반엔 복잡한 멀티 에이전트 조율을 가능하게 하는 시스템 레이어가 된다.
시사점: '조율 설계자'로서의 개발자
AutoGen, CrewAI, Swarm 같은 에이전트 프레임워크들은 런타임 중 에이전트끼리 API로 메시지를 주고받는다. 이 실험의 워크플로우는 런타임 조율이 전혀 없다. 각 에이전트는 독립 세션에서 실행되고, 파일에서 현재 상태를 읽고, 작업하고, 결과를 쓰고, 종료한다. 이것이 다른 벤더의 에이전트를 연결할 수 있는 이유이기도 하다—공유 런타임이 없기 때문이다.
이 패러다임이 프론트엔드 개발자에게 시사하는 바는 명확하다. AI 에이전트를 잘 활용하는 능력은 더 이상 "좋은 프롬프트를 쓰는 능력"이 아니다. 각 에이전트의 강점과 실패 모드를 파악하고, 공유 상태를 설계하고, 태스크 경계를 명확히 정의하고, 검증 가능한 완료 조건을 만드는 것—이건 사실 오랫동안 좋은 소프트웨어 설계자가 해온 일과 본질적으로 다르지 않다.
전망: AI 워크플로우의 다음 진화 방향
툴링은 빠르게 패턴을 흡수하고 있다. Gemini CLI의 네이티브 프로젝트 정책, Claude의 CLAUDE.md, Cursor의 Rules—각 도구들이 "조율 레이어"를 내재화하는 방향으로 수렴하고 있다. 하지만 이것이 조율 설계의 필요성을 없애지는 않는다. 오히려 단일 도구의 네이티브 기능에 갇히지 않는 벤더 중립적 조율 아키텍처의 가치가 더 올라간다.
앞으로 프론트엔드 개발자에게 요구되는 역량의 중심은 이동할 것이다. 특정 API를 외우는 것에서 시스템을 어떻게 설계할지 결정하는 것으로. AI가 코드를 생성하더라도, 무엇을 만들지·어떤 순서로·어떤 경계를 지키며·어떻게 검증할지를 설계하는 주도권은 여전히 사람이 쥐어야 한다. 조율 설계자로서의 개발자—그게 지금 이 전환기가 요구하는 역할이다.