ChatGPT에게 오류 원인을 묻는 것은 몇 분이면 충분하지만, 동일한 수정을 직접 보유하고 있는 리포지토리에 적용하려 하면 타입이 맞지 않거나 기존 테스트가 실패하는 경험은 많은 개발자가 했을 것입니다. 문제는 '답변의 질' 자체가 아니라, 작업에 필요한 문맥 전체가 프로젝트 내부에 존재한다는 경우가 많기 때문입니다. ChatGPT와 Codex는 접근 방식만 다를 뿐, 어느 것이 우월하다고 말할 수 없습니다. 본고에서는 결과물을 어디에 배치할지를 기준으로 선택하는 방법을 정리합니다.
두 모델의 능력에는 중복되는 부분이 있지만, 설계상의 무게 중심이 다릅니다. 먼저 구체적인 작업 유형별로 대응할 곳을 맞춰보겠습니다.
| 작업의 성격 | ChatGPT 적합 | Codex 적합 |
|---|
| 문제를 정리하고 싶을 때 | 개념 설명, 방침 비교, 자료 요약 | 리포지토리 내 호출 체인 추적, 구현 위치 특정 |
| ... | | |
| 요컨대, 재료가 대화 창이나 몇 개의 파일로 완결된다면 ChatGPT가 적절하고, 프로젝트 전체에 걸쳐 퍼져 있다면 Codex가 적합합니다. OpenAI의 ChatGPT 가이드는 Q&A와 자료 처리를 모두 다루기 때문에 '대화 전용'은 아닙니다. OpenAI의 Codex 문서는 Codex를 개발 환경 내에서 프로젝트 작업을 처리하는 도구로 위치시키고 있습니다. 실제로 무엇을 할 수 있는지는 제공되는 진입점, 권한, 컨텍스트에 따라 달라집니다. | | |
먼저 상황을 정리하고 싶을 때는 ChatGPT에게 시나리오를 직접 작성해 줍니다.
"이 API 로그에서 추론 가능한 실패 요인을 근거의 강한 순서대로 나열해 주세요. 이어서 추가로 수집해야 할 정보를 알려주세요."
파일을 전달하여 요약, 비교, 분석, 초안 작성을 시킬 수도 있습니다. 사용하고 싶은 결과물을 얻고 싶다면, 입력 자료, 처리 규칙, 출력 형식, 수용 기준을 한 번의 메시지로 지정해 두면 재작업이 줄어듭니다. 결과를 받았다면 반드시 파일을 열어서 수치, 인용, 형식을 직접 대조해야 합니다. ChatGPT가 특정 파일, 웹페이지, 외부 도구에 접근할 수 있는지 여부는 현재 사용하고 있는 진입점, 계정의 권한, 실제로 허용한 범위에 의존합니다.
코드에 대해서도 논의할 수 있고, 함수의 샘플을 작성할 수도 있습니다. 하지만 '사용해 보기에 좋은 스니펫'과 '자신의 프로젝트에 병합되어 테스트가 통과하는 코드'는 별개입니다. 전자는 대화 내에서 끝나지만, 후자에는 실제 프로젝트 문맥과 실행 결과가 필요합니다.
Codex는 목적이 명확하고 개발 환경 내에서의 실행이 필요한 작업에 적합합니다. 예를 들어 다음과 같은 지시를 할 수 있습니다.
"로그인 API는 사용자 이름이 비어있을 때 500을 반환합니다. 먼저 재현 경로를 특정하고, 현행 응답 형식을 유지한 채 수정하며 관련 테스트를 추가하여 실행해 주세요. 마지막으로 변경 파일과 미검증 부분을 나열해 주세요."
이러한 작성 방식은 동작, 범위, 제약, 수용 기준을 한 번에 전달합니다. Codex는 승인된 프로젝트 환경에서 파일을 읽고, 코드를 편집하며, 기존 도구를 실행하여 차분(diff)과 테스트 결과를 반환합니다. OpenAI는 데스크톱 앱, CLI, IDE 통합의 형태로 Codex를 제공하고 있으며, 실제로 할 수 있는 것은 계정과 환경에 따라 다릅니다.
코드를 작성하지 않는 상황에서도 Codex는 사용될 수 있습니다. 문서나 설정이 리포지토리에 있고 변경 사항이 빌드 체크를 통과해야 하는 경우라면, diff와 커맨드 실행만으로도 가치가 있습니다. 다만, 차분이 나왔다고 해서 반드시 옳은 것은 아닙니다.
'테스트 성공', '테스트 미실행', '인간 검토 미실시'는 각각 별개의 상태로 기록한 후 병합 여부를 판단해야 합니다.
'로그인 API가 사용자 이름이 비어있을 때 500을 반환하는' 경우를 예로 들면, 저는 다음과 같이 분담시킵니다.
먼저 ChatGPT를 사용하여 기대 동작을 정리합니다. 본래 반환해야 할 상태 코드, 기존 응답 형식, 놓치기 쉬운 경계 조건을 작성합니다. 이미 자료가 손에 있다면 이 단계는 건너뛰어도 괜찮습니다. -
다음으로 Codex에게 경계를 명시한 지시를 전달합니다. 빈 사용자 이름이 500을 유발하는 경로를 특정해 주세요. 현행 응답 형식을 유지하고, 관련 검증(validation)과 테스트만 변경해 주세요. 먼저 문제를 재현하는 테스트를 추가하고, 관련 테스트를 실행해 주세요. 마지막으로 변경 파일, 실행한 커맨드, 미검증 부분을 나열해 주세요.
마지막으로 직접 diff를 확인합니다. 새로운 테스트가 원래 문제를 정말로 포착하고 있는지, 다른 로그인 분기(branch)에 의도치 않은 변경이 없는지 확인해야 합니다. 테스트가 실행되지 않았다면 '미실행'으로 남기고, '수정 완료'로 검수를 대체하지 않도록 주의합니다. OpenAI의 프롬프트 가이드 역시 목적, 맥락, 명시적 요구사항의 중요성을 강조하고 있습니다.
ChatGPT는 자료나 질문과 대화하는 진입점(入口)이고, Codex는 작업(タスク) 및 프로젝트에 접근하는 진입점이며, API는 프로그램이 요청을 보내고 응답을 받는 채널입니다. API 호출이 성공했다고 해서 Codex가 리포지토리의 수정을 완료했다는 의미도 아니며, ChatGPT가 공유하지 않은 로컬 파일을 읽었다는 의미도 아닙니다.
2026년 10월 29일, https://api.crazyrouter.com/v1/chat/completions에 대해 gpt-4o-mini를 지정하여 중국어 요약 요청을 비스트리밍(non-streaming) 방식으로 보냈습니다. 응답은 HTTP 200이었고, 응답 모델은 gpt-4o-mini-2024-07-18, finish_reason은 stop이었으며, 입력은 53 tokens, 출력은 15 tokens이었습니다. 다만 작업(タスク)은 '한자 20자 이내'였으나 실제 출력은 22자였습니다. 이 기록이 보여주는 것은 단 한 번의 API 호출이 성공했다는 사실과 문자 수 제약을 충족하지 못했다는 것뿐입니다. ChatGPT와 Codex를 비교하는 시험이 아니므로, 두 제품의 동작 방식도 추정할 수 없습니다. Crazyrouter의 Chat Completion 문서에 요청 필드와 응답 형식이 있습니다.
아직 Codex를 사용해 본 적이 없다면, OpenAI의 Codex 페이지에서 환경에 맞는 진입점을 선택하고 작고 명확한 프로젝트 과제로 시험해보는 것이 좋습니다. 실제로 Codex CLI를 서드파티 API와 연결할 필요가 생기면, Crazyrouter의 Codex CLI 연동 가이드를 참조하십시오. 서드파티 API 설정은 OpenAI 프로덕트 계정의 권한이나 사용량과는 별개의 문제입니다.
ChatGPT에 자료 분석을 맡길 때의 형식입니다.
목적: 3건의 견적을 비교하고, 조달 판단을 제안한다.
입력: 업로드된 3건의 견적 PDF.
규칙: 통화와 세금 기준을 맞춘다. 누락 항목은 추측하지 않고, 별도로 목록화한다.
...
Codex에 프로젝트 작업을 맡길 때의 형식입니다.
목적: 로그인 API가 사용자 이름이 비어있을 때 500을 반환하는 문제를 수정한다.
범위: 엔드포인트, 유효성 검사(validation), 관련 테스트.
제약: 현행 응답 형식을 유지한다. 무관한 모듈에는 건드리지 않는다.
...
두 템플릿에 공통되는 핵심 기둥은 목적, 소재(자료), 제약, 수용 기준의 네 가지입니다. Codex 작업에서는 프로젝트 경로, 재현 절차, 관련 파일도 가능한 한 구체화해야 합니다. 그렇지 않으면 처음 몇 단계가 맥락 찾기에 소모됩니다.
막막하다면 처음에 두 문장을 작성하는 것이 지름길입니다. 결과물은 어디에 둘 것인지, 어떻게 검수할 것인지 말입니다. 글자 중심이라면 ChatGPT부터, 프로젝트 중심이라면 Codex부터 시작하세요. 양쪽에 걸쳐 있는 작업은 이름의 격(scope)으로 나누기보다는 단계별 인계로 분담하는 것이 결국 더 빠릅니다.**
