코덱스(Codex)를 오랫동안 사용하며 마침내 핵심을 파악했습니다!
똑같이 Codex를 사용하면서도, 어떤 사람은 하루에 수백만 개의 Token을 소모하고 코드는 버그투성이인 반면,
어떤 사람은 스스로 자료를 검색하고, 코드를 작성하며, 버그를 수정하고, 테스트를 실행시키고, 심지어 여러 Agent에게 동시에 작업을 지시할 수도 있습니다!
처음 Codex를 사용했을 때 저 역시 수많은 시행착오를 겪었습니다.
가장 황당했던 순간은 프로젝트가 절반쯤 진행되었을 때, 문맥(Context)이 갑자기 뒤죽박죽이 되어버린 경우였습니다. 버그 하나를 수정하려다가 이전에 구현했던 기능까지 망가뜨리는 일이 발생했습니다.
겨우 작동하게 만들었다고 해도, 새로운 세션을 시작하면 다시 요구사항을 처음부터 설명해야 했습니다.
나중에야 깨달았습니다. Codex의 가장 큰 비용은 Token 가격 자체가 아니라, 반복적인 시행착오, 중복 개발, 그리고 비효율적인 출력에 있다는 것을요!
이렇게 애쓰다 보니, 마침내 저만의 고정된 작업 흐름(Workflow)을 찾아냈습니다.
실제 적용 가능한 8가지 경험을 공유하니, 특히 6, 7, 8번은 꼭 저장해 두시길 바랍니다!
- Codex에게 '두뇌'를 장착하여 기억 상실증 극복하기
예전에는 하나의 프로젝트에 대해 수십 번의 대화를 나누면, 요구사항, 버그 내용, 폐기된 방안들이 모두 뒤섞여서 점점 더 혼란스러워졌습니다.
이제는 각 단계가 완료될 때마다 프로젝트 루트 디렉터리에 DV_STATE.md 파일을 업데이트하도록 지시합니다.
이 파일에는 프로젝트 목표, 기술 방안, 완료된 작업 목록, 남아있는 문제점(Legacy Issues), 그리고 다음 계획을 저장합니다.
새로운 세션을 시작할 때는 이 내용을 복사하여 붙여넣습니다:
"DV_STATE.md를 읽고 현재 코드를 결합하여 프로젝트 문맥을 복구해 주세요. 이미 완료된 작업과 남아있는 문제를 확인하고, 이전 작업을 반복하지 않도록 주의하며 개발을 계속 진행해 주세요."
매번 수만 자에 달하는 채팅 기록 전체를 다시 입력할 필요가 없습니다. 장기 프로젝트에서 특히 유용합니다.
- AGENTS.md로 규칙을 정하여 코드 무분별한 수정 방지하기
때로는 단순히 버튼 하나만 바꾸고 싶은데, Codex는 마치 전체 프로젝트를 스캔하는 것처럼 작동하곤 합니다.
결국 세 줄의 코드를 고치기 위해 Token은 엄청나게 소모되죠.
이제 저는 AGENTS.md 파일에 기술 스택, 프로젝트 구조, 코딩 규칙, 그리고 수정 금지 파일을 명확히 기재합니다.
그리고 다음과 같이 지시합니다:
"먼저 AGENTS.md를 읽고, 현재 작업과 관련된 파일만 분석해 주세요. 기존 코드를 우선 재사용하고, 관련 없는 디렉터리는 스캔하지 말고, 다른 기능을 임의로 수정하지 말아주세요."
이렇게 하면 불필요한 파일 읽기를 줄일 수 있을 뿐만 아니라, 다른 모듈을 실수로 건드릴 확률도 낮출 수 있습니다.
- GitHub에서 '바퀴(Wheel)'를 찾고, 제로 베이스 개발 서두르지 않기
예전에는 요구사항이 들어오면 바로 Codex에게 코드를 작성하게 했습니다. 나중에 알고 보니, 많은 기능들이 이미 GitHub에 누군가 만들어 놓은 것이었습니다.
이제는 프로젝트 검색부터 하도록 지시한 후, 직접 개발할지 여부를 결정합니다.
프롬프트:
"코드는 먼저 작성하지 말고, 요구사항을 바탕으로 GitHub에서 검색하여 가장 관련성이 높은 오픈 소스 프로젝트 5개를 찾아주세요. 기능, Star 수, 유지보수 상태, 라이선스를 비교하고, 성숙한 솔루션을 우선 재사용할 수 있도록 구현 계획을 제시해 주세요."
크롤러, 관리자 백엔드(Admin Backend), AI Agent, 자동화 도구 등 무엇이든 이 방식으로 먼저 시도할 수 있습니다.
이미 완성된 것을 굳이 몇 시간을 들여 다시 작성할 필요가 없습니다.
- Codex + Context7로 구식 API 문제 해결하기
가장 짜증나는 것은 코드가 아무 문제가 없어 보이는데, 인터페이스(API)를 실행하면 '존재하지 않는다'는 오류가 나는 경우입니다.
오랜 시간 검색한 끝에 알게 된 사실은, Codex가 오래된 버전의 API를 사용하고 있었다는 것이었습니다.
나중에는 Context7을 연동하여 해당 버전의 기술 문서를 우선적으로 검색하도록 했습니다.
GitHub: https://t.co/DQ28lGJw3V
설치 프롬프트:
"https://t.co/DQ28lGJw3V를 읽고, 공식 문서에 따라 Context7을 설치 및 설정한 후, MCP가 정상적으로 작동하는지 검증해 주세요. 코딩 시에는 해당 버전의 공식 문서를 우선 조회해 주세요."
특히 새로운 프레임워크나 SDK를 자주 사용하는 분들에게는 강력히 추천합니다.
- Codex + RTK로 비효율적인 Token 사용량 줄이기
예전에는 테스트를 한 번 실행할 때 터미널에 수백 줄의 로그가 출력되었습니다.
실제로는 두 개의 에러만 있었는데, 관련 없는 정보들을 모두 문맥(Context)에 채워 넣는 식이었죠.
RTK는 바로 이런 문제를 해결하기 위해 설계되었습니다.
GitHub: https://t.co/tt4rtPjP0w
일반적인 Git, 테스트, 빌드 명령어의 출력 내용을 간소화하여 중복된 내용을 줄여줍니다.
바로 복사:
"https://t.co/tt4rtPjP0w를 읽고, 공식 문서에 따라 설치 및 설정을 완료한 후, 적용 여부를 검증하고, 최적화 전후의 Token 소모량을 비교해 주세요."
테스트나 로그 확인이 잦은 프로젝트에는 정말 유용합니다!
- Codex + oh-my-codex로 여러 Agent가 함께 일하게 하기
예전에는 하나의 Agent가 프론트엔드, 백엔드, 데이터베이스, 테스트까지 모두 담당했습니다.
작업을 하다 보니 문맥이 점점 더 복잡해지기만 했습니다.
나중에는 서로 다른 Agent에게 역할을 분담하여 독립적인 작업들이 병렬로 처리되도록 했습니다.
GitHub: https://t.co/NbHlRpWoRD
작업 계획 수립, 다중 Agent 협업, 코드 검토 및 품질 검증 기능을 지원합니다.
설치 프롬프트:
"https://t.co/NbHlRpWoRD를 읽고, 환경 호환성을 확인한 후, 공식 문서에 따라 설치 설정을 완료하고, 다중 Agent 협업과 작업 계획 수립 기능을 검증해 주세요."
복잡한 프로젝트는 작업을 분할할 수 있지만, 간단한 작업까지 억지로 병렬화할 필요는 없습니다.
- Codex + ECC로 완벽한 개발 프로세스 구축하기
이 프로젝트는 정말 연구해보시길 권합니다!
GitHub: https://t.co/O4yv1M9zLd
Agent, Skills, 규칙, 그리고 개발 워크플로우를 제공합니다.
가장 가치 있는 것은 도구의 개수가 아니라, 전체 개발 프로세스를 표준화할 수 있다는 점입니다.
요구사항 분석 → 작업 계획 → 코딩 → 테스트 → 검토 → 검증
예전에는 Codex가 '완료했다'고 말하면 끝이었지만, 결과는 버그투성이였습니다.
이제는 최소한 규칙을 통해 테스트와 검증까지 완료된 후에만 납품하도록 요구할 수 있습니다.
프롬프트:
https://t.co/O4yv1M9zLd를 읽고, Codex의 환경 호환성을 확인하고, Codex에 적합한 설정을 설치하며, 핵심 기능을 검증하고, 활성화된 Agents와 Skills를 명시해야 합니다.
- Codex가 스스로 버그를 찾게 하세요. 더 이상 수동으로 스크린샷을 찍지 마세요.
예전에는 가장 짜증났던 것이었습니다:
Codex가 코드를 작성하면 → 제가 실행하고 → 버그를 발견해서 → 스크린샷을 찍어 보내고 → 그것이 수정하고 → 제가 다시 실행하는 과정이었습니다. 때로는 십여 차례 왕복하며 고생했습니다!
이제 저는 직접 다음의 전달 규칙을 추가합니다:
'작업 완료 후, Git diff를 확인하고, 관련 테스트(test), 타입 체크(type check) 및 빌드 명령을 실행하며, 오류가 발견되면 먼저 근본 원인(root cause)을 분석한 후 수정하고, 마지막으로 실제 수정 내용, 검증 결과 및 잔여 문제점을 보고해야 합니다. 미실행된 테스트는 반드시 명시해야 하며, 검증되지 않은 기능을 완료된 것으로 표시하는 것은 허용하지 않습니다.'
이 제안은 모두가 저장해 두면 정말 많은 반복 작업을 줄일 수 있을 것입니다!