클로드 코드가 멈춘 새벽, 코덱스를 불렀다

멀티 에이전트, 꼭 써야 할까? 

처음 여러 AI 코딩 에이전트를 써 본 건 단지 호기심에서였다. 그런데 도구를 이것저것 조합해 쓰기 시작하면서부터는 확실히 편해졌다. 기획자여서 코드를 이해하지 못해 허둥대던 상황이 차츰 줄어들었고, 결과물의 완성도도 점차 높아졌다. 지금은 클로드 코드에 코덱스를 MCP로 연결해서 하나의 워크플로로 묶어 사용하는 중이다. 

두 개를 함께 쓰게 된 직접적인 계기는 클로드가 같은 자리에서 자꾸 멈추는 상황이 반복됐기 때문이다. 어떤 날은 무한 루프에 빠진 화면을 한참 쳐다보다가 노트북을 켜놓은 채로 잠들어 버린 적도 있다. 그러다 문득, 같은 개발 환경에서 같은 프롬프트를 코덱스에 한번 입력해 보면 어떨까? 하는 생각이 들었다.

결과는 의외였다. 클로드 코드에서 “API 키를 읽을 수 없다”고 막혀 있던 호출이 코덱스에서는 깔끔하게 처리됐고, 결과물도 더 빠르게 나왔다. 물론 최종 결과물의 깊이와 디테일은 여전히 클로드 코드가 더 잘 잡혔다. 그래서 서로 다른 강점을 가진 두 개의 에이전트를 같이 쓰는 멀티 에이전트 워크플로가 자연스럽게 만들어졌다. 

이번 글에서는 클로드 코드와 코덱스를 통합해 셋업하면서 발견한 두 도구의 강점과 약점, 그리고 멀티 에이전트를 효율적으로 다루기 위한 프롬프트를 공유하고자 한다.

코덱스로 짜고, 클로드 코드로 매듭짓기

멀티 에이전트를 쓰는 방식은 통제권을 어디에 두고, 에이전트끼리 어떻게 연결하느냐에 따라 달라진다. 크게 보면 MCP로 직접 묶는 방식, IDE 플랫폼을 이용하는 방식, 오픈소스 에이전트 프레임워크를 쓰는 방식 등이 있다. 이번 브랜드 추천 서비스를 구현할 땐 클로드 코드를 메인 개발로, 코덱스를 서브 검수자로 두고 MCP로 연결해 사용했다.

펄스는 고객이 수동으로 추천받는 대신, 취향이 맞는 크루와 함께 직접 브랜드들을 연결하고 큐레이션 하여 브랜드 맵을 만들어가는 플레이그라운드 형식의 발견형 커머스다. 우선 MVP로 사용자에게 3개를 추천하는 기능부터 만들어 봤다. 

1) 클로드 코드에 코덱스 MCP 연결하기

클로드 코드에 코덱스 MCP를 연결하는 순간에는 단순히 기능을 확장해서 AI 보조도구를 쓴다는 개념으로 생각했다. 실제로 사용해 보니 개발팀 전체를 상주시키는 것 같은 느낌을 받았고 만족스러웠다. 다만, 에이전트 간 복잡한 다자간 토론이나 정교한 순서 제어를 프롬프트만으로 해결해야 해서 코드가 꼬이는 상황이 발생했다.

연결하는 방법은 클로드 코드 CLI(터미널형)와 클로드 앱의 Code 모드(GUI형)가 다른데, 둘 다 설치해서 상황에 따라 골라 썼다. 설치 자체는 클로드가 안내하는 대로 따라 하면 되고, 연결 후에는 아래와 같이 명령어로 호출한다. 

프롬프트: codex에게 Brand link_claude 이 프로젝트 구조한 번 분석시키고 결과 가져와 줘. 즉 컴포넌트 리팩토링은 codex에 위임하고, 너는 결과를 검토해서 UX 관점에서 개선점만 정리해 줘

코덱스 MCP 연결 후 프롬프트로 호출 <출처: 작가>

이런 방식으로 클로드 코드가 만든 결과물을 코덱스의 논리적, 구조적 강점으로 보완하는 형태로 작업을 이어갈 수 있다.

2) 멀티 에이전트 5단계 프롬프트 가이드

여러 에이전트를 사용할 때 각각의 강점을 극대화하려면,워크플로마다 적합한 역할을 명확히 분리하는 것이 핵심이다. 한 에이전트의 결과물을 다른 에이전트의 입력 값으로 넘기며 크로스 체크하는 구조를 만들면 효율이 눈에 띄게 올라간다.  

참고로 아키텍처 수립이나 로직 설계 단계에서는 연초만 해도 클로드만 한 게 없다고 생각했었다. 그런데 요즘은 코덱스의 결과물도 좋아졌다. 에이전트의 품질이 하루가 다르게 변하고 있으니, 단계마다 각 에이전트를 번갈아 가며 테스트해 보는 것도 좋을 것 같다. 

• 클로드 코드:  오케스트레이터, 모든 의사 결정 및 총괄 진행
• 코덱스: 검수, 보안, 최적화 작업 담당

아래는 실제 5단계 워크플로에서 사용한 md 파일과 프롬프트인데, 역할을 서로 바꿔서 각 에이전트의 역할은 프로젝트 상황에 맞게 분담하면 된다.

1단계: 아키텍처와 로직 설계 

PRD.md 파일을 참고해서 Codex로 브랜드 추천 서비스에 최적화된 전체 디렉토리 구조와 DB 스키마를 설계해 줘. 설계가 끝나면 그 결과를 JSON 포맷으로 출력하고 너는 프론트엔드 컴포넌트 개발을 바로 시작할 수 있도록 준비해 줘.

2단계: 개발 UI와 기능 구현  

Desing.md, UX.md 파일을 참고해서, 사용자가 브랜드를 직접 연결하며 놀 수 있는 플레이그라운드 형태의 발견형 커머스의 메인 피드 브랜드 맵 UI 컴포넌트를 사용성을 고려해서 React로 구현해 줘.

3단계: 1차 검증 코드 리뷰와 리팩토링 

Codex를이용해서 방금 개발한 코드를 정적 분석 및 성능 프로파일 모드로 검증해 줘. Big-O 관점에서의 불필요한 반복문이나 메모리 누수, 의존성 배열 누락, 에러 바운더리 부재를 점검하고 수정한 최적화 코드와 변경 사유를 프롬프트 형태로 정리해서 MD 파일에 저장해 줘.

4단계. 사용성 개선 및 인터랙션 고도화 

방금 만든 MD 파일을 참고해서 사용성을 개선해 줘. 데이터 로직은 절대 건들지 말고, 스켈레톤 로더와 호버 애니메이션 등 마이크로 인터랙션만 추가해 줘.

5단계: 최종 검증 및 배포 준비 

최종으로 Codex로 깐깐한 QA 및 DevSecOps 엔지니어 관점에서 무결성 검수를 수행해 줘. 전체 코드 베이스 기반으로 트리쉐이킹 검사, 크로스 브라우징 및 레이아웃 시프트 위험 요소 탐지, Vercel 배포용 환경 변수 검토 및 하드 코딩된 시크릿 키 검출을 진행하고, 검증을 통과하면 Ready for Vercel 메시지를 출력한 뒤 배포 스크립트를 준비해 줘.

이처럼 마지막에 준비 완료 트리커 메시지를 정해두면, 에이전트가 검증 완료 여부를 명확히 신호로 던져준다. 전체 워크플로에서 이런 작은 부분이 작업 효율을 높인다. 

어떤 작업을 어떻게 분업하면 좋을까?

솔직히 요즘은 에이전트의 품질이 워낙 빠르게 좋아지고 있어서, 작업을 무 자르듯 정확하게 나누는 게 의미가 없다고 느낀다. 다만 현시점에서 체감하는 차이는 분명히 존재한다. 예를 들어, MBTI별로 브랜드를 추천하는 기능을 만들었을 때, 클로드 코드가 페르소나별 톤을 설계를 잡아주면 코덱스에 그 톤을 받아 각 컴포넌트별로 카피라이팅을 빠르게 찍어내는 식의 방법이 자연스러웠다. 

메인: 클로드 코드가 잘하는 것

클로드는 단순히 코딩할 때만 쓰는 도구가 아니다. 최근엔 클로드 디자인도 출시됐다. 이러한 이유로 클로드를 메인으로 쓰고 있기도 하다. 특히 내 의도를 파악하기 위해 질문하고 확인받는 과정이 있어, 상호작용 측면에서 훨씬 만족스럽다.

요즘따라 오류가 자주 발생한다는 느낌이 있지만, 최종 결과물의 디테일 특히 날씨나 시즌성을 반영한 카피라이팅의 깊이, UI/UX 디자인 완성도는 여전히 클로드 코드가 잘 잡는다고 생각한다. 클로드 코드는 깊고 좁은 작업 방식이라고 표현하는 게 정확할 것 같다. 

• PRD, 개발 스펙 정리 및 아키텍처 수립
• 사용자 의도/맥락 파악, 명세 정리
• 카피, 텍스트 작성 (MBTI별 브랜드 추천 같은)
• UX 흐름 검토, 디자인 의사결정 정리

서브: 코덱스에 맡기면 좋은 것

이전에 클로드 코드를 쓸 땐 토큰 비용을 아끼려고, 반복적인 로직 작성이나 맥락 이해가 크게 필요하지 않은 간단한 작업들은 소넷(Sonnet) 모델을 사용했다. 그런데 코덱스를 함께 써보니, 얇고 넓게 처리하는 작업들은 더 빠르고 안정적으로 마무리할 수 있었다. 

• 여러 파일에 동일 수정을 일괄 적용하거나, 대량 반복 작업이 필요할 때
• 빠른 프로토타이핑 / 보일러 플레이트 코드 작성
• 테스트 코드 자동 생성
• 결과물 검수 / 비판적 리뷰

완벽한 PRD가 실패하는 이유:기획자가 잡아야 할 운전대 

처음 바이브 코딩을 시작했을 땐, 기획서 한 줄로 동작하는 프로토타입이 딸깍 만들어지는 것만으로도 한동안 꽤 만족스러웠다. 그래서 앞단에 기획/계획이 좋은 PRD가 나은 결과를 만든다고 굳게 믿었다. 그런데 이처럼 다양한 AI 에이전트를 함께 쓰다 보니, PRD는 출발선의 지도일 뿐, 운전대가 아니라는 사실을 깨달았다.

클로드 코드가 만든 결과물을 코덱스에 리뷰시키고, 코덱스가 정리한 결과를 다시 클로드 코드에게 넘겨 UX/UI를 고도화하는 과정에서는 각 에이전트가 만든 결과물의 미묘한 차이를 구분하는 감각이 필요했다. 사실 하나의 에이전트 안에서도 매번 답변이 다르거나, 컴포넌트 규칙이 어긋나거나, 같은 의도를 다르게 해석한다. 그래서 이러한 작은 균열을 잇는 맥락의 다리는 결국 기획자가 놓아야 했다.

여러 에이전트를 함께 쓰는 워크플로는 분명 강력하다. 그러나 반드시 기획자가 구체적이고 디테일한 문제를 풀 수 있는 능력이 뒷받침되어야 한다.어떤 단계에서 어떤 에이전트에게 어떤 단위의 일을 맡길지, 무한루프와 같은 오류가 생겼을 땐 어떻게 해결할지, 여러 에이전트의 결과물을 어떤 기준으로 통합할지 등이 모두 기획자의 몫이기 때문이다.

따라서 지금 하나의 에이전트만 사용하고 있다면, 다른 에이전트를 추가해 보길 권한다. 무한루프와 같은 오류가 발생했을 때 같은 프롬프트를 입력해 보면, 어떻게 결과 다른지 직접 비교해 보는 것도 좋은 출발점이 될 것이다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.