클로드 코드 코덱스 연결과 협업: 역할 나누는 기준

AI가 프로젝트의 파일을 읽고 고치고 명령을 실행하는 도구를 코딩 에이전트라고 부릅니다. Claude Code(클로드 코드)와 Codex(코덱스)는 서로 다른 회사가 만든 코딩 에이전트입니다. 둘 중 누가 더 좋은지를 고르는 비교는 많지만 이미 두 도구를 쓸 수 있다면 질문이 달라집니다.

요즘은 직원에게 AI를 지원하는 회사가 점점 많아지고 있습니다. 채팅용으로 가벼운 모델을 지원하는 회사부터, 실무용으로 Claude Code(클로드 코드)나 Codex(코덱스)처럼 한 단계 더 들어간 도구까지 지원하는 회사, 여러 도구를 다양하게 열어 주는 회사도 있습니다. 저희 회사는 가벼운 사용 용도로 ChatGPT(챗지피티)를 팀용 Business 플랜으로 구독하다가 실무용으로 Claude Code를 확장한 경우인데, Claude Code를 적극적으로 쓰다 보니 ChatGPT는 채팅으로만 쓰고 그마저도 잘 안 쓰게 됐습니다. 이미 비용을 내고 있는 구독이 이렇게 잠들어 있다면, 두 도구를 같이 쓸 방법이 궁금해질 차례입니다.

이 글은 이미 두 구독을 가진 분의 활용 폭을 넓히는 글입니다. 하나만 쓰고 있는데 다른 모델을 가볍게 구독해서 협업을 시험해 보고 싶은 분에게도 맞습니다. Claude Code와 OpenAI(오픈AI)의 Codex를 같은 작업에 어떻게 나눠 넣을지 설명합니다. 역할을 가르는 기준부터 실제로 시도 중인 구성, 함께 쓸 때 생기는 한도와 컨텍스트, 파일 충돌 문제까지 내려가 보겠습니다.

같이 쓰기의 뜻: 연결이 아니라 협업 구조

두 개를 같이 쓴다는 말은 Claude Code 안에 Codex를 연결하거나 두 에이전트가 자동으로 한 대화를 나눈다는 뜻이 아닙니다. 한 작업을 나누고 서로 다른 세션에 맡겨서 협업 구조를 만든다는 뜻입니다. 한쪽이 결과물을 만들면 다른 쪽이 빠진 조건을 검토하고, 서로 겹치지 않는 파일을 맡아 동시에 진행하기도 합니다. 사람 둘이 일을 나누는 방식 그대로입니다.

처음에는 두 화면을 켜고 같은 부탁을 복사해 넣는 모습을 떠올리기 쉽습니다. 그러면 답변은 두 개 생기지만 일은 나뉘지 않습니다. 사용자가 두 결과를 처음부터 다시 비교해야 하니 오히려 확인할 양만 늘어납니다.

같이 쓸 때 필요한 것은 연결 기능보다 작업 경계입니다. 무엇을 완성해야 하는지, 어느 파일을 건드려도 되는지, 누가 마지막 검사를 맡는지를 먼저 정합니다. 에이전트 이름은 그다음에 넣으면 됩니다.

그럼 누가 계획하고 누가 검토를 맡을까요. 정해진 것은 없습니다. 저는 Claude Code가 계획을 세우고 Codex가 검토한 다음, 역할을 바꿔 한 번 더 돌리는 식으로 작업물을 다듬는 경우가 많습니다. 그렇게 하면 Claude가 놓친 것을 Codex가 잡아내고, Codex가 틀린 것을 Claude가 정정합니다. Claude가 일하는 동안 Codex에 다른 일을 시켜 병렬로 처리할 수도 있고요. 정답이 있는 배치가 아니니 편한 대로 조합을 바꿔 가며 실험해 보시면 됩니다.

이미 두 구독이 있는 경우가 많습니다

두 도구를 같이 쓰자는 생각은 새 기능이 필요해서가 아니라 아까워서 시작됐습니다. 도입에서 말한 그 잠든 구독, 채팅에만 쓰던 ChatGPT를 Claude Code가 일하는 동안 일에 불러들이지 못하고 있었기 때문입니다.

방치에는 이유가 있었습니다. 예전 Codex는 손이 잘 가지 않았습니다. 그런데 새 모델 Sol(GPT-5.6 세대의 상위 모델)이 나온 뒤로 사정이 달라졌습니다. Codex가 좋아졌다는 평이 커뮤니티에 쌓이기 시작했고, 마침 여러 AI 세션을 한 화면에서 지휘하는 Orca(오르카) 같은 도구도 나오기 시작했습니다. 낭비하느니 같이 쓰자는 생각이 그때 들었고, 둘의 강점을 살린 구성을 시도하게 됐습니다.

이 상황에서 중요한 전제는 이미 두 구독이 있다는 것입니다. 하나만 쓰고 있다면 두 번째 도구 때문에 바로 결제할 필요는 없습니다. 반대로 회사나 팀이 두 서비스를 이미 제공한다면 가격 비교에서 멈추지 말고 실제 업무 한 건에 보조 역할부터 줘 볼 수 있습니다.

요금과 한도 수치는 여기서 다시 적지 않습니다. 자주 바뀌고 플랜과 조직 설정에 따라 이용 범위가 달라지기 때문입니다. 현재 Codex 범위는 코덱스 요금제 정리, Claude 쪽은 클로드 요금제 비교에서 확인할 수 있습니다. 결제나 조직 배포 전에는 각 공식 요금 페이지도 다시 봐야 합니다.

무엇을 기준으로 나누나

두 에이전트의 역할을 제품 평판만으로 정하면 모델이나 버전이 바뀔 때마다 운영 방식도 흔들립니다. 더 오래 가는 기준은 결과물, 파일, 맥락입니다. 이 셋을 정하면 어느 도구가 먼저 일을 맡아도 다음 단계가 이어집니다.

만드는 역할과 검토하는 역할

가장 쉽게 시작하는 방법은 한쪽이 만들고 다른 쪽이 검토하게 하는 것입니다. 실행하는 에이전트에는 목표와 수정 범위, 완료 조건을 줍니다. 검토하는 에이전트에는 실행 쪽의 요약만 넘기지 말고 원래 발주서와 바뀐 파일을 함께 줍니다.

검토가 독립적이어야 하는 이유가 있습니다. 작성한 쪽이 “요구를 모두 반영했다”고 요약하면 검토하는 쪽도 그 틀 안에서 보기 쉽습니다. 실제로 겪었습니다. 검토를 맡긴 쪽에 실행 쪽의 요약만 넘겼더니 잘했다는 확인만 하고 끝났고, 원래 발주서를 함께 넘기고 나서야 빠진 조건을 잡기 시작했습니다. 원래 요구와 결과를 직접 대조하게 해야 누락을 찾을 수 있습니다.

이 구조에서는 두 도구가 같은 일을 중복하지 않습니다. 한쪽의 결과가 다른 쪽의 입력이 됩니다. 검토에서 문제가 없으면 끝나고 빠진 조건이 있으면 실행 쪽으로 한 번만 돌아갑니다.

파일은 겹치지 않게 나누기

두 작업을 동시에 진행하려면 담당 파일이 겹치지 않아야 합니다. 한쪽은 본문을 쓰고 다른 쪽은 같은 본문을 다듬게 하면 나중에 저장한 내용이 앞의 수정을 덮거나 병합할 때 충돌합니다. 같은 파일을 맡길 수밖에 없다면 동시에 돌리지 않고 작성과 검토를 순서대로 진행합니다.

파일이 여러 개라면 경로로 나누는 편이 명확합니다. 예를 들어 한쪽은 콘텐츠 폴더를 맡고 다른 쪽은 테스트 결과만 읽게 할 수 있습니다. 기능 이름으로 “A 작업”과 “B 작업”이라고 나누면 두 작업이 같은 설정 파일을 고칠 수 있습니다. 파일 경로를 적어 두면 경계가 눈에 보입니다.

별도 브랜치나 worktree(같은 프로젝트를 작업 폴더 여러 개로 펼쳐 두는 Git 기능)를 쓰면 작업 폴더도 나눌 수 있습니다. 다만 그 장치가 파일 소유권을 대신 정해 주지는 않습니다. 서로 다른 작업 폴더에서도 같은 파일을 각자 고치면 합칠 때 다시 만납니다.

맥락을 이어야 할 일과 독립 검토가 필요한 일

한 세션에서 오래 논의한 결정과 예외는 그 세션에 쌓입니다. 그 맥락이 필요한 후속 수정은 같은 에이전트가 이어 가는 편이 짧습니다. 반대로 처음 보는 독자의 눈이나 독립 검토가 필요하면 다른 에이전트의 빈 맥락이 도움이 됩니다.

Claude Code와 Codex의 대화 기록은 자동으로 공유되지 않습니다. 같은 폴더를 열었다고 다른 도구가 앞 대화의 합의까지 아는 것은 아닙니다. 파일에 적힌 규칙은 함께 볼 수 있지만 채팅에서만 정한 이유와 보류 사항은 따로 넘겨야 합니다.

그래서 맥락을 전부 복사하기보다 결정만 남깁니다. 목표, 바꾸지 말아야 할 것, 이미 확인한 사실, 남은 질문, 검사 결과를 짧게 적으면 됩니다. 대화 전문을 넘기면 새 에이전트도 오래된 시행착오부터 다시 읽게 됩니다.

실제로 나눠 본 구성

시작점은 분명했습니다. ChatGPT Business를 채팅에만 쓰던 상태에서 Codex에도 일을 맡겨 보기로 했고 Claude Code와 함께 굴릴 방법을 찾았습니다. Orca를 쓰며 여러 에이전트가 각자 다른 작업을 맡는 화면을 본 경험도 이 시도에 영향을 줬습니다.

제 경우 글쓰기 작업에서 배치가 자리를 잡았습니다. 초안 작성은 Codex에 맡기고, 사실 확인과 검토, 최종 문장을 다듬는 일은 Claude Code가 맡습니다. 만드는 쪽과 다듬는 쪽을 가른 것인데, 반대로 Claude Code가 만든 계획서를 Codex가 검토하게 시키기도 합니다. 도구별 고정 배역이라기보다 그 작업에서 누가 만들고 누가 볼지를 정하는 쪽에 가깝습니다.

여러 세션이 각자 작업 공간을 맡으면 화면은 이렇게 보입니다.

실제 역할표에는 도구 이름만 적는 것으로 부족합니다. 각 역할이 끝났다고 판단할 조건이 있어야 합니다. “초안 작성” 대신 “지정한 파일에 초안을 쓰고 검사 결과를 남김”처럼 결과를 적어야 다음 도구가 어디서 시작할지 알 수 있습니다.

처음 정한 역할이 계속 맞는다고 가정할 수도 없습니다. 어떤 일은 긴 맥락을 지닌 쪽이 예상보다 빨랐고 어떤 검토는 새 세션이 더 잘 볼 수 있습니다. 이 차이는 제품 홍보 문구가 아니라 실제로 나눈 작업에서 확인해야 합니다.

이 구성이 정착하면 두 에이전트가 별개의 일을 하는 것이 아니라 하나의 작업 안에서 앞뒤를 잇습니다. 계획과 실행, 검토를 모두 병렬로 돌리는 것이 목표가 아닙니다. 동시에 해도 되는 일만 나누고 앞 결과가 필요한 일은 순서대로 넘기는 구성입니다.

여기서 한 단계 더 가면 사람이 두 화면을 오가며 결과를 옮기는 일까지 도구에 맡길 수 있습니다. 여러 에이전트 세션을 한 화면에 놓고 서로 요청과 회신을 주고받게 하는 것을 오케스트레이션이라고 부르는데, Orca 사용 후기에서 소개한 그 도구가 바로 그 일을 합니다. 이 글에서는 손으로 나누는 기준까지만 다루고, 오케스트레이션으로 흐름 자체를 자동화하는 방법은 다음 글에서 따로 깊게 다루겠습니다.

막히는 곳은 한도와 컨텍스트와 파일 충돌입니다

도구를 하나 더 열면 처리량도 바로 두 배가 될 것 같지만 실제로는 세 군데에서 막힙니다. 사용 한도, 서로 다른 컨텍스트, 같은 파일을 건드리는 충돌입니다. 시작 전에 이 경계를 정하지 않으면 두 번째 에이전트가 시간을 줄이기보다 검토할 일을 늘립니다.

OpenAI 공식 요금 문서는 ChatGPT Work와 Codex가 사용량을 공유한다고 안내합니다. Work는 Business 같은 플랜과 별개의 구독이 아니라, 그 플랜 안에 함께 들어 있는 업무 화면입니다. Claude Code도 플랜과 사용 방식에 따라 한도가 달라집니다. 두 구독이 있다는 사실과 무제한으로 쓸 수 있다는 말은 다릅니다. 정확한 수치와 추가 사용 정책은 공식 페이지에서 그날 다시 확인해야 합니다.

컨텍스트는 자동으로 합쳐지지 않으니 짧은 인수인계 형식을 정해 두는 편이 좋습니다. 다음 정도면 새 세션이 출발할 수 있습니다.

목표:
지금까지 결정한 것:
바꾸지 말아야 할 것:
바뀐 파일:
실행한 검사와 남은 문제:

파일 충돌은 가장 조용하게 손해를 만듭니다. 앞에서 본 것처럼 나중 저장이 앞의 수정을 덮는 경우에는 오류조차 나지 않아, 사라진 사실을 알아채기 어렵습니다. 한 작업에서 최종 편집자는 한쪽만 맡고 다른 쪽은 읽기와 검토만 하게 하는 규칙이 단순하고 안전합니다.

실제로 걸린 것도 파일 충돌이었습니다. 두 세션이 같은 파일을 각자 고치다 한쪽 수정이 조용히 사라진 적이 있고, 그 뒤로 경로 소유권을 먼저 나누는 규칙을 세웠습니다. 오류 메시지가 나는 충돌보다 소리 없이 덮이는 쪽이 더 무섭습니다.

하나만 쓴다면 무엇부터

저라면 이미 결제돼 있고 프로젝트 접근 권한이 열린 도구부터 씁니다. 새 구독을 더하는 것보다 한 도구로 발주서 작성, 파일 수정, 검사, 결과 확인까지 한 바퀴를 완주하는 편이 먼저입니다. 혼자 끝내는 흐름이 없으면 두 도구를 켜도 일을 어디서 나눌지 정할 수 없습니다.

둘 다 이미 있다면 주 도구 하나를 정하고 다른 쪽은 검토자로 붙입니다. 비율을 반반으로 맞출 필요는 없습니다. 현재 프로젝트 맥락이 많이 쌓인 쪽이 실행을 맡고 다른 쪽이 요구 누락과 검사 결과를 보는 구성으로 시작하면 됩니다.

둘을 같이 쓰는 목적은 에이전트 수를 늘리는 데 있지 않습니다. 한쪽이 만든 결과를 다른 쪽이 확인하고 동시에 해도 되는 파일만 나눠 전체 작업을 더 안전하게 끝내는 데 있습니다. 이미 낸 돈으로 시작하되 역할이 생길 때만 두 번째 도구를 여는 것이 제가 택할 기준입니다. 잠들어 있는 구독이 있다면 오늘 하는 작업 하나에서 검토만 먼저 맡겨 보세요. 일을 나누는 감각은 설명이 아니라 첫 분업에서 생깁니다.