Codex란 무엇인가? ChatGPT와 차이부터 첫 코딩 작업까지

요약: Codex는 코드와 개발 도구를 다루는 작업에 적합한 OpenAI의 도구입니다. 처음에는 작은 기능 하나를 맡기고, 변경된 파일과 실행 결과를 확인하는 방식으로 시작해 보세요.

1. Codex와 ChatGPT는 어떤 관계일까?

OpenAI 공식 안내는 질문과 대화를 위한 Chat, 결과물을 만드는 ChatGPT Work, 개발자 도구와 기술 세부 사항을 다루는 Codex를 구분합니다. 따라서 “ChatGPT는 설명만 하고 Codex만 행동한다”는 설명은 현재 제품을 지나치게 단순화합니다. 두 도구가 사용하는 기능은 겹칠 수 있으며, 내가 어떤 화면에서 어떤 파일과 도구를 연결했는지가 중요합니다.

예를 들어 정규식의 의미가 궁금하면 짧은 대화로 충분합니다. 내 프로젝트에서 이메일 검증 오류를 고치려면 소스 파일, 오류를 재현하는 입력, 정상 동작의 기준이 필요합니다. 후자의 작업에서는 코드를 읽고 수정 내용을 비교하는 개발 작업 환경이 유용합니다. 제품 이름을 고르는 것보다 작업의 끝을 설명하는 것이 먼저입니다.

2. 코드 답변과 코드 작업을 구별하기

코드 답변은 복사해서 사용할 수 있는 예제나 설명입니다. 코드 작업은 내 저장소의 실제 파일을 대상으로 이루어지는 변경입니다. Codex CLI 문서는 터미널에서 파일을 살펴보고, 수정하고, 명령을 실행하는 흐름을 안내합니다. 다만 실제 실행 범위는 연결된 환경과 권한에 따라 달라집니다.

이 차이를 모르면 “고쳤다”는 문장을 보고도 내 파일이 바뀌지 않은 이유를 이해하기 어렵습니다. 설명만 원할 때는 파일을 수정하지 말라고 적고, 수정을 원할 때는 프로젝트 경로와 원하는 결과를 알려 주세요. 코드 블록이 나왔다는 사실만으로 파일 저장이나 테스트 실행이 이루어졌다고 판단하지 않는 습관이 필요합니다.

3. 첫 작업은 작은 문제 하나로 시작하기

다음은 가상의 할 일 앱을 위한 요청 예시입니다. 실제 프로젝트에서는 경로와 동작을 바꾸어 사용하세요. 프롬프트를 길게 꾸미기보다 화면에서 관찰할 수 있는 결과를 넣는 것이 핵심입니다.

할 일 앱에서 빈 문자열을 저장하면 빈 항목이 생깁니다.
공백만 입력한 경우에도 새 항목을 만들지 않도록 수정해 주세요.
관련 파일은 src/tasks 폴더에 있습니다.
기존 저장 형식과 정상 항목 추가 동작은 유지해 주세요.
프로젝트에 있는 관련 테스트를 실행하고,
수정 파일, 실행 명령, 결과, 확인하지 못한 부분을 알려 주세요.

이 요청에는 문제, 관련 위치, 보존할 동작, 확인 기준이 함께 들어 있습니다. “앱을 전체적으로 개선해 줘”보다 수정 범위를 판단하기 쉽습니다. 처음에는 로그인 체계를 전부 바꾸는 작업보다 입력 오류 하나, 안내 문구 하나처럼 결과를 직접 비교할 수 있는 문제가 적합합니다.

4. 결과를 읽을 때 확인할 세 가지

첫째, 변경 파일이 요청한 문제와 연결되는지 봅니다. 둘째, 실행한 명령과 출력이 실제 검증을 보여 주는지 확인합니다. 셋째, 남아 있는 제한을 읽습니다. 테스트를 실행할 수 없어 방법만 제안한 경우와, 명령을 실행해 통과한 경우는 구분해야 합니다.

빈 입력을 막는 예시라면 빈 문자열, 공백, 정상 문장을 각각 넣어 보는 확인이 필요합니다. 화면에 오류 문구가 뜨더라도 데이터가 이미 저장되는 문제는 남아 있을 수 있습니다. 따라서 표시와 저장을 함께 확인하는 기준을 요청하세요. 기능 수정이 잘 되었는지는 답변의 자신감보다 변경 전후의 동작과 실행 증거로 판단하는 편이 좋습니다.

5. 처음 사용할 때 자주 생기는 실패와 해결

• 엉뚱한 파일을 고쳤다면: 현재 프로젝트와 관련 경로를 다시 지정하고, 잘못된 변경을 확인한 뒤 원하는 범위를 명시합니다.
• 설명만 받았다면: 실제 파일 수정을 원하는지, 패치 제안만 원하는지 분명히 적습니다.
• 테스트 결과가 없다면: 실행 여부와 실패 또는 미실행 이유를 나누어 보고하도록 요청합니다.
• 수정이 너무 커졌다면: 이번 작업의 완료 기준을 하나로 줄이고 부수적인 개선은 별도 작업으로 남깁니다.

한 번의 요청으로 모든 것을 맡길 필요는 없습니다. 먼저 프로젝트 구조를 설명받고, 이해한 부분을 기준으로 작은 수정을 맡기는 단계도 좋은 출발입니다. 본인이 바꾼 파일이나 다른 사람이 작업 중인 부분은 미리 알려 불필요한 덮어쓰기를 줄이세요.

6. 내 상황에 맞는 시작 방법 고르기

처음부터 개발 도구를 전부 설치할 필요는 없습니다. 공부할 코드 한 조각이 있고 파일을 바꿀 생각이 없다면 대화로 설명을 요청하세요. 이미 실행되는 프로젝트가 있고 그 파일을 고치려면 작업 폴더를 연결할 수 있는 환경을 선택합니다. 터미널 사용에 익숙하다면 CLI에서 프로젝트 폴더로 이동해 시작하는 흐름이 자연스럽습니다. 편집기나 데스크톱 앱을 사용한다면 현재 열린 프로젝트와 변경 내용을 읽는 방법부터 익히세요.

원하는 결과	먼저 전달할 자료	끝났다고 판단할 기준
코드 이해	함수와 호출 예시	입력에서 반환값까지 설명 가능
작은 오류 수정	프로젝트, 재현 입력, 정상 기준	문제 입력 해결과 정상 입력 유지
변경 검토	비교할 변경과 요구사항	문제 위치·조건·영향이 제시됨
새 기능 추가	기존 화면, 저장 규칙, 완료 사례	기능과 기존 동작을 함께 검증

“어느 도구가 더 똑똑한가”만 비교하면 내 작업에 필요한 자료를 빠뜨리기 쉽습니다. CLI라도 프로젝트 밖에서 시작하면 엉뚱한 폴더를 조사할 수 있고, 대화라도 파일과 도구가 연결되어 있으면 결과물을 만들 수 있습니다. 요청하려는 작업, 접근 가능한 파일, 검증할 수 있는 도구를 한 묶음으로 생각하세요. 요금이나 모델 이름을 먼저 고정하기보다 현재 계정에서 실제로 사용할 수 있는 환경을 기준으로 시작하면 됩니다.

7. 프로젝트를 처음 열었을 때 하는 탐색 요청

가상의 tasks-demo 프로젝트를 받았다고 가정해 보겠습니다. 먼저 실행 명령이 무엇인지 모르는 상태에서 설치와 전체 수정을 한꺼번에 맡기지 말고, README와 설정 파일을 읽어 구조를 파악합니다. 아래 PowerShell 명령은 폴더 위치와 Git 변경 상태를 살펴보는 예시입니다. 프로젝트 경로는 직접 바꾸어야 하며, Git 저장소가 아니라면 git status 단계는 적용되지 않습니다.

Set-Location "C:\Projects\tasks-demo"
Get-Location
Get-ChildItem
 git status --short

이때 보이는 파일이 예상한 프로젝트와 다르면 먼저 폴더를 바로잡습니다. Git 출력에 이미 수정된 파일이 있다면 그 변경이 내 작업인지 구분해 둡니다. package.json이 있는 JavaScript 프로젝트라면 scripts 항목과 lock 파일을 읽어 실행 도구를 찾고, 다른 언어라면 해당 프로젝트의 설정과 README를 따릅니다. 파일 이름만 보고 임의의 패키지 관리자를 정하는 것보다 현재 프로젝트의 안내를 따르는 편이 오류를 줄입니다.

이 프로젝트의 구조를 먼저 설명해 주세요.
README와 현재 설정에서 실행·검증 명령을 찾아 주세요.
할 일 추가 기능의 입력 화면, 저장 함수, 테스트 위치를 연결해 주세요.
이번 단계에서는 파일 수정이나 의존성 설치를 하지 마세요.
직접 읽은 파일과 아직 확인하지 못한 부분을 구분해 주세요.

좋은 탐색 답변은 “프런트엔드 프로젝트입니다”라는 분류에서 끝나지 않습니다. 입력이 어느 파일에서 들어오고, 어떤 함수가 저장하며, 어디에서 관련 검증을 하는지 알려 주어야 다음 수정 요청에 사용할 수 있습니다. 파일을 찾지 못했다면 확정된 경로를 꾸미는 대신 검색한 위치와 부족한 자료를 설명하도록 요청하세요.

8. 빈 항목 오류를 끝까지 해결하는 작은 사례

앞의 할 일 앱에서 완료 기준을 더 구체화해 보겠습니다. 빈 입력을 막는다는 말에는 화면에 메시지만 보여 주는 방법과 저장 함수에서 데이터를 거부하는 방법이 모두 들어갈 수 있습니다. 화면에서 입력을 제한해도 다른 호출 경로가 저장 함수를 사용하면 빈 값이 들어갈 수 있으므로, 실제 데이터가 만들어지는 경로까지 조사하도록 요청합니다. 어느 계층에 검증을 둘지는 기존 프로젝트 구조에 맞춰 결정해야 합니다.

입력 사례	가정한 요구사항
빈 문자열	저장되지 않고 사용자에게 이유 안내
공백 세 칸	빈 값과 같은 정책 적용
일반 문장	기존 방식으로 한 항목 저장
앞뒤 공백이 있는 문장	공백 보존 또는 제거 정책을 별도로 결정
기존 저장 데이터	이번 수정으로 임의 삭제하지 않음

마지막 두 조건이 특히 중요합니다. 공백만 입력한 값을 차단한다고 해서 모든 정상 문장의 앞뒤 공백을 자동으로 제거해야 하는 것은 아닙니다. 예전 데이터의 빈 항목을 정리하는 일도 새 입력 검증과 별개입니다. “새 항목 생성만 막고 기존 데이터를 바꾸지 않는다”처럼 이번 수정의 목적을 한정하면 불필요한 데이터 변환을 줄일 수 있습니다.

빈 입력 방지 수정에서 저장 호출 경로까지 확인해 주세요.
빈 문자열·공백만 있는 값·정상 문장을 각각 구분해 검증해 주세요.
앞뒤 공백이 있는 정상 문장의 저장 정책은 현재 동작을 유지하세요.
기존 저장 데이터를 정리하거나 저장 형식을 바꾸지 마세요.
화면 메시지와 실제 저장 차단이 각각 어디에서 처리되는지 설명해 주세요.

9. 답변을 받아들일지 결정하는 방법

최종 답변의 “완료” 표현보다 근거를 먼저 읽으세요. 변경 파일 목록에 입력 화면만 있고 저장 경로 설명이 없다면, 저장 함수가 다른 경로에서도 호출되는지 후속으로 물어볼 수 있습니다. 테스트 통과라는 문장이 있어도 어떤 명령이 어느 폴더에서 실행되었는지 빠져 있다면 확인한 범위가 불분명합니다. 화면을 직접 열지 못한 경우에는 코드 검증과 사용자 화면 확인을 구분해 달라고 요청합니다.

완료 보고를 다음 순서로 정리해 주세요.
1. 요청 조건별로 변경한 파일과 동작
2. 실제 실행한 명령, 작업 폴더, 통과·실패 결과
3. 빈 입력과 정상 입력을 확인한 근거
4. 직접 실행하지 못한 확인과 그 이유
5. 제가 화면에서 따라 할 수 있는 짧은 확인 절차

예를 들어 “단위 테스트는 통과했고 브라우저 실행은 하지 못했다”는 보고를 받았다면, 다음 단계는 화면에서 빈 값과 정상 값을 입력해 저장 결과를 살펴보는 것입니다. “도구가 없어 테스트를 실행하지 못했다”면 필요한 실행 환경을 갖춘 뒤 같은 명령을 다시 수행해야 합니다. 미실행을 실패로 취급하거나, 코드가 그럴듯하다는 이유로 성공으로 취급하면 다음 판단을 잘못하게 됩니다.

첫 작업을 마친 뒤에는 범위를 조금씩 넓히세요. 빈 입력 수정이 검증되었다면 다음에는 중복 항목 안내나 검색 조건처럼 다른 한 가지 기능을 맡길 수 있습니다. 작업마다 문제 입력, 보존할 동작, 변경 차이, 검증 근거를 남기면 나중에 오류가 생겼을 때 어느 변화부터 조사해야 할지 찾기 쉬워집니다. 이것이 첫 Codex 작업에서 얻어야 할 실질적인 사용 습관입니다.

10. 자주 묻는 질문

코딩을 몰라도 사용할 수 있나요? 자연어로 요청할 수 있지만 결과를 판단할 기준은 필요합니다. 어떤 입력에서 어떤 결과가 나와야 하는지를 적고, 이해되지 않는 변경은 설명을 요청하세요.

Codex가 만든 코드를 바로 배포해도 되나요? 수정된 동작과 프로젝트의 검증 절차를 확인한 뒤 결정하세요. 로컬에서 동작하는 것과 실제 서비스 환경에서 동작하는 것은 다른 확인입니다.

어떤 모델이 가장 좋나요? 이 글은 모델 순위나 요금 비교를 다루지 않습니다. 사용 가능한 모델과 제한은 계정과 시점에 따라 달라지므로 현재 공식 안내와 자신의 화면을 확인하는 것이 정확합니다.

공식 출처 및 확인일: OpenAI 공식 문서: Use ChatGPT · OpenAI 공식 문서: Codex CLI. 2026년 10월 3일 확인. 예시의 경로와 명령은 자신의 프로젝트에 맞게 조정하세요.