Claude한테 짜게 시키고 Codex한테 까게 시키기 — 두 AI 에이전트를 한 레포에서 분담시키는 실무 패턴
혹시 이런 경험 있으신가요? Claude한테 코드를 짜달라고 했더니 뭔가 그럴듯해 보이는데, 막상 돌려보면 엣지 케이스가 줄줄 샙니다. 반대로 GPT한테 리뷰를 맡겼더니 "이 부분은 개선이 필요합니다"라는 말만 반복하고 실제로 어떻게 고쳐야 하는지는 모호합니다. 지금 실리콘밸리 개발자 커뮤니티에서 조용히 퍼지고 있는 해결책이 있습니다. Claude는 쓰게 하고, Codex는 까게 하는 것입니다.
왜 두 에이전트가 필요한가 — 단일 AI의 한계
AI 코딩 도구를 쓰다 보면 묘한 패턴을 발견하게 됩니다. 같은 모델한테 코드를 짜달라고 한 뒤 "이 코드 문제없어?"라고 물으면, 십중팔구 "좋아 보입니다, 다만 몇 가지 개선 사항이 있다면…" 하는 식의 미온적인 답이 돌아옵니다. 자기가 쓴 글을 자기가 교정하는 상황입니다. 심리학에서 말하는 확증 편향과 같습니다. 자기 결과물에 대해서는 무의식적으로 관대해집니다.
이 문제를 해결하기 위해 일부 개발자들이 채택하기 시작한 방식이 바로 역할 분리(Role Separation)입니다. 생성과 검증을 서로 다른 모델에 맡기는 것입니다. 이 흐름을 무시하면 6개월 뒤, 여러분의 AI 워크플로우는 여전히 같은 모델에게 "이거 맞아?"를 묻고 있을 겁니다.
실제로 이 전략을 적용한 사례를 보겠습니다
GeekNews(Hacker News 한국판)에 올라온 사례입니다. 한 개발자가 단일 레포에서 Claude와 OpenAI Codex(또는 ChatGPT)를 역할 분담시켜 운영하는 패턴을 공유했습니다. 핵심은 간단합니다.
Claude의 역할 — 구현자(Builder): Claude는 요구사항을 받아 실제 코드를 작성합니다. Claude의 강점은 긴 컨텍스트 윈도우와 지시사항을 충실히 따르는 능력입니다. "이 함수를 만들어줘"라고 하면 빠르게, 그리고 꽤 완성도 있게 구현해냅니다. 복잡한 비즈니스 로직이나 보일러플레이트 코드 작성에 특히 강합니다.
Codex(ChatGPT)의 역할 — 비평가(Critic): Claude가 작성한 코드를 Codex에 넘겨 "이 코드의 문제점을 찾아줘"라고 시킵니다. 중요한 포인트는 같은 모델이 아닌 다른 모델이기 때문에 확증 편향 없이 날카롭게 문제를 짚어냅니다. "이 부분은 null 처리가 안 됐네", "이 루프는 O(n²)인데 개선 가능합니다" 같은 구체적인 지적이 나옵니다.
결과적으로 이 개발자는 코드 품질 이슈를 사람이 직접 리뷰하기 전에 상당수 걸러낼 수 있었다고 합니다.
한 레포에서 두 에이전트를 분담시키는 구체적인 단계
이 패턴을 실제로 적용하려면 어떻게 해야 할까요? 다음은 지금 바로 따라해볼 수 있는 구체적인 단계입니다.
1단계 — 역할 프롬프트를 파일로 저장하기
레포 루트에 .claude/와 .codex/ 디렉토리를 만들고 각각의 역할 프롬프트를 저장합니다. Claude용 프롬프트에는 "당신은 시니어 개발자입니다. 요구사항을 명확히 구현하되, 기존 코드 스타일을 유지하세요"라고 씁니다. Codex용 프롬프트에는 "당신은 코드 리뷰어입니다. 버그, 보안 취약점, 성능 문제, 가독성 문제를 구체적으로 지적하세요. 칭찬보다 문제점 위주로 리포트하세요"라고 씁니다.
2단계 — PR 단위로 역할을 분리하기
개발 흐름을 이렇게 정형화합니다. Claude로 기능 브랜치에 코드를 작성 → 해당 diff를 Codex에 붙여넣고 리뷰 요청 → Codex가 지적한 항목을 Claude에게 수정 지시 → 사람이 최종 확인 후 머지. 이 사이클을 반복하면 사람의 리뷰 부담이 현저히 줄어듭니다.
3단계 — 자동화 스크립트로 연결하기
여기서 한 발 더 나아가면, git hook이나 CI 파이프라인에 이 과정을 자동화할 수 있습니다. PR이 열리면 자동으로 Codex API를 호출해 리뷰 코멘트를 달아주는 GitHub Action을 만드는 것입니다. 실제로 오픈소스 커뮤니티에는 이런 용도의 Action들이 이미 존재합니다. openai/codex-review-action 같은 키워드로 검색하면 참고할 수 있습니다.
4단계 — 역할을 더 세분화하기
익숙해지면 역할을 더 나눌 수 있습니다. Claude는 구현, Codex는 보안 리뷰, 그리고 또 다른 모델(예: Gemini)은 테스트 케이스 작성 담당으로 삼는 방식입니다. 각 모델의 강점을 살려 파이프라인을 구성하면 됩니다.
이 패턴이 왜 지금 주목받는가
단순히 "두 AI를 쓰면 더 좋다"는 이야기가 아닙니다. 이 패턴의 등장은 AI 에이전트 시대의 실무 성숙도를 보여주는 신호입니다.
초기 바이브코딩(Vibe Coding) 시대에는 "AI한테 시키면 되는 거 아니야?"라는 막연한 낙관론이 있었습니다. 하지만 실제로 프로덕션 코드를 AI로 작성해본 개발자들은 알고 있습니다. AI가 생성한 코드는 그럴듯하지만 구멍이 있습니다. 특히 혼자 개발하는 1인 개발자나 소규모 팀일수록 리뷰 리소스가 부족해서 이 구멍이 프로덕션까지 그대로 올라가는 경우가 많습니다.
이중 에이전트 패턴은 이 문제에 대한 현실적인 해답입니다. 추가 비용도 크지 않습니다. Claude API와 OpenAI API를 함께 쓴다고 해도 하루 수십 건의 코드 리뷰라면 월 몇 달러 수준입니다. 사람 개발자 한 명이 리뷰에 쓰는 시간과 비교하면 압도적으로 효율적입니다.
전망 — 멀티 에이전트 워크플로우가 표준이 된다
지난주 실리콘밸리에서 조용히 확산되고 있는 이 변화는 앞으로 더 가속화될 것입니다. 이미 Cursor, Windsurf 같은 AI IDE들은 내부적으로 여러 모델을 조합하는 방식을 실험 중입니다. GitHub Copilot도 단일 모델에서 멀티 모델 오케스트레이션으로 진화하고 있습니다.
6개월 뒤에는 "AI 하나로 다 하려고 했던 시절"이 마치 "스택 오버플로우 없이 개발하던 시절"처럼 느껴질 수 있습니다. 지금 이 패턴을 익혀두는 게 현명한 이유입니다.
오늘부터 작은 것부터 시작해보세요. 다음에 AI로 코드를 짤 때, 그 결과물을 다른 AI에게 "이 코드 뭐가 문제야?"라고 물어보세요. 생각보다 날카로운 답이 돌아올 겁니다.
⚠️ 이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
댓글