제가 처음 gpt codex 사용법을 찾아봤을 때 막힌 지점은 “어디서 켜나?”가 아니라 “실제 프로젝트에서 어디까지 맡겨도 되나?”였습니다. 결론부터 말하면, Codex는 새 프로젝트를 통째로 맡기는 도구라기보다 작은 수정 단위로 코드 읽기 → 패치 제안 → 테스트 실행을 반복할 때 가장 빨리 감이 옵니다.
작은 저장소 하나를 골라 브랜치를 만들고, 에러 로그와 파일 범위를 Codex에 넘겨 첫 패치 루프를 돌려보세요.
저는 요즘 Warp 터미널에서 Claude Code와 Codex를 번갈아 쓰며 블로그 자동화 파이프라인과 작은 백엔드 유틸을 고칩니다. 이 글은 설명서 요약이 아니라, 실제로 터미널에서 버그 하나를 잡을 때 어떤 순서로 쓰면 덜 헤매는지에 맞췄습니다.
처음이라면 큰 앱 말고, 테스트가 있는 작은 저장소에서 시작하세요.
아래 루프를 그대로 따라 하면 Codex가 잘하는 일과 위험한 일을 20분 안에 구분할 수 있습니다.
제가 쓴 셋업: IDE보다 터미널 루프가 편했습니다
제 기본 환경은 macOS, Warp 터미널, Git 저장소, Node.js 또는 Python 프로젝트입니다. Codex CLI를 쓸 때는 공식 문서 기준으로 설치하고, API 키나 로그인 방식은 최신 안내를 따르는 편이 안전합니다. 도구 이름과 명령은 버전에 따라 바뀔 수 있어요.
작업 전에는 항상 브랜치를 새로 땁니다. AI 에이전트가 한 번에 여러 파일을 고치는 순간, 원래 의도와 다른 변경이 섞일 수 있기 때문입니다.
git checkout -b fix/codex-small-bug
git status
1단계: “전체를 고쳐줘” 대신 범위를 잘라서 맡기기
제가 처음에 실패한 프롬프트는 이거였습니다. “이 프로젝트 문제점 찾아서 고쳐줘.” 결과는 그럴듯했지만, 수정 범위가 넓고 검증이 어려웠습니다.
그 다음부터는 이렇게 바꿨습니다.
이 저장소에서 src/rss/generateFeed.ts만 읽고,
날짜가 없는 글에서 build가 실패하는 원인을 찾아줘.
수정은 최소 변경으로 제안하고, 테스트 명령도 같이 알려줘.
핵심은 파일, 증상, 제한 조건, 검증 명령을 같이 주는 겁니다. Codex는 맥락이 좁을수록 실수도 줄고 응답도 빨라집니다.
2단계: 패치를 바로 믿지 말고 diff부터 보기
AI 코딩 에이전트의 답은 “완성 코드”가 아니라 “검토할 패치”로 봐야 합니다. 저는 제안이 마음에 들어도 바로 커밋하지 않고, 먼저 diff를 봅니다.
git diff
npm test
npm run build
여기서 테스트가 없으면 최소한 재현 명령이라도 만들어야 합니다. 예를 들어 RSS 생성기가 문제라면 샘플 markdown 하나를 넣고 build가 통과하는지 확인합니다.
구체적인 예: 날짜 없는 글 때문에 빌드가 깨진 상황
가상의 예시지만, 제가 자동화 파이프라인에서 실제로 자주 만나는 형태와 비슷합니다. WordPress로 넘기기 전 markdown 메타데이터를 읽는데, 일부 글에 date가 빠져 Invalid time value가 나는 상황입니다.
이때 저는 Codex에 전체 파이프라인 설명을 길게 넣지 않았습니다. 에러 문구, 관련 파일, 원하는 정책만 줬습니다.
에러: RangeError: Invalid time value
관련 파일: src/rss/generateFeed.ts
정책: date가 없으면 오늘 날짜가 아니라 draft로 제외
수정 후 npm test로 확인
이 방식이 좋았던 이유는 간단합니다. “오늘 날짜로 채워 넣기” 같은 임의 판단을 막고, 제가 원하는 제품 정책을 코드에 반영하게 만들 수 있었습니다.
Codex, Claude Code, Cursor를 언제 나눠 쓰나
저는 도구를 하나로 통일하지 않습니다. Claude Code는 긴 맥락을 잡고 리팩터링 방향을 볼 때 편했고, Cursor는 파일을 보며 편집할 때 장점이 있습니다. Codex는 터미널에서 짧은 작업을 빠르게 반복할 때 손에 맞았습니다.
| 상황 | 제가 고르는 도구 | 이유 |
|---|---|---|
| 작은 버그 수정, 테스트 루프 | Codex CLI | 터미널에서 질문하고 diff 확인하기 좋음 |
| 여러 파일 흐름 파악 | Claude Code | 긴 맥락 설명과 설계 토론에 강점 |
| UI나 파일 단위 편집 | Cursor | 에디터 안에서 바로 보고 고치기 편함 |
| 아이디어 검토, 문서 초안 | ChatGPT | 코드 밖 설명과 선택지 정리에 유용 |
이런 분에게 추천합니다
추천 대상
gpt codex 사용법을 찾는 분 중에서 이미 Git을 쓰고, 테스트나 빌드 명령이 있는 프로젝트를 가진 분에게 특히 잘 맞습니다. 주니어 개발자라면 “코드를 대신 짜주는 도구”보다 “선배에게 작은 패치를 리뷰받는 느낌”으로 쓰는 편이 안전합니다.
반대로 요구사항이 아직 흐릿한 새 서비스 기획, 보안 규칙이 많은 운영 DB 작업, 결제 로직 변경은 처음 연습 대상으로 추천하지 않습니다. 이건 Codex 문제가 아니라, 사람이 해도 검증 비용이 큰 작업입니다.
초반에 가장 많이 하는 실수
가장 흔한 실수는 프롬프트를 친절하게 길게 쓰는 것보다, 검증 기준을 안 주는 것입니다. “잘 고쳐줘”라고 하면 AI는 그럴듯한 방향을 고릅니다. “이 테스트가 통과해야 한다”라고 하면 작업이 훨씬 좁아집니다.
또 하나는 변경 파일을 확인하지 않는 겁니다. Codex가 설정 파일이나 lock 파일을 건드렸다면 이유를 물어보세요. 설명이 납득되지 않으면 되돌리는 게 낫습니다.
FAQ: 처음 쓰면서 자주 막히는 부분
무료로 쓸 수 있나요?
요금과 제공 방식은 OpenAI 정책에 따라 바뀝니다. 무료 여부를 단정하기보다 공식 가격표와 계정 화면을 확인하는 게 정확합니다.
한국어로 말해도 되나요?
가능합니다. 다만 파일명, 에러 메시지, 명령어는 원문 그대로 넣는 편이 좋습니다. 저는 설명은 한국어, 코드 조건은 짧은 영어 또는 원문 로그로 섞어 씁니다.
기존 코드가 망가지면 어떻게 하나요?
브랜치를 따고 시작하면 대부분 되돌릴 수 있습니다. 최소한 git diff, git restore, git checkout 흐름은 익혀두세요.
지금 바로 해볼 액션 체크리스트
- 테스트나 빌드 명령이 있는 작은 저장소를 하나 고릅니다.
- 새 브랜치를 만들고, 에러 문구와 관련 파일 1~2개만 Codex에 줍니다.
- 수정 제안을 받은 뒤
git diff로 변경 범위를 먼저 확인합니다. - 테스트가 통과하면 커밋하고, 실패하면 에러 로그를 다시 붙여 한 번만 더 반복합니다.
처음부터 완벽한 에이전트 워크플로를 만들 필요는 없습니다. 오늘은 작은 버그 하나를 안전하게 고쳐보는 정도면 충분합니다. 그다음 Claude Code나 Cursor와 비교해보면, 내 작업 스타일에 맞는 조합이 보입니다.
오늘도, 코딩할 용기.
관련 링크
- AI 에이전트 하네스 엔지니어링 입문 결정적 오케스트레이션 직접 짜기: 에이전트를 ‘믿는’ 대신 묶어두는 법
- ai 코딩 구독 요금 비교: Claude Code·Cursor·Copilot, 빌드용으로 돈값 하는 조합
- AI 코딩 에이전트 용어가 안 들릴 때 왕초보가 챙긴 최소 개념: Cursor와 Claude Code로 읽는 법
- 관련 태그 더 보기
- 카테고리 더 보기
- 검색 결과 더 보기
- 참고 링크
