Codex 한도를 아끼려다 개발 프로세스가 생겼다: ChatGPT와 Codex를 나눠 쓰는 방법
Codex 한도를 아끼려다 개발 프로세스가 생겼다
최근 Threads에 제가 ChatGPT와 Codex를 나눠 쓰는 방법을 올렸는데, 생각보다 많은 분이 공감해주셨습니다.
저만 이렇게 사용하는 줄 알았는데 비슷한 고민을 하는 분들이 꽤 많더라고요.
사실 처음부터 거창한 개발 프로세스를 만들려고 했던 건 아닙니다.
시작은 정말 단순했습니다.
Codex 사용량을 조금이라도 아끼고 싶었습니다.
Plus에서는 한도가 항상 아쉬웠다
Codex Plus를 사용할 때는 한도가 생각보다 빠르게 줄었습니다.
프로젝트 전체를 읽고, 코드를 수정하고, 테스트하고, 다시 리뷰하다 보면 체감상 사용량이 금방 쌓였습니다.
그래서 처음에는 이렇게 생각했습니다.
설계나 대화까지 굳이 Codex에서 할 필요가 있을까?
실제 저장소를 봐야 하는 작업만 Codex에 맡기면 되지 않을까?
그때부터 ChatGPT와 Codex의 역할을 나누기 시작했습니다.
처음 목적은 정말 하나였습니다.
양쪽을 최대한 알뜰하게 써보자.
그런데 이 방식을 계속 사용하다 보니, 단순한 절약법이 아니라 하나의 개발 프로세스처럼 자리 잡기 시작했습니다.
현재 사용하고 있는 전체 개발 흐름
제가 현재 사용하는 흐름은 대략 이렇습니다.
1. ChatGPT에서 요구사항과 설계 방향 정리
2. 작업지시문과 프로젝트 현황 문서를 Codex에 전달
3. Codex에서 기존 코드 검토 및 구현
4. 구현이 끝나면 Codex에서 자체 리뷰 진행
5. 자체 리뷰가 통과하면 Commit / Push / PR 생성
6. ChatGPT에서 PR 전체 리뷰
7. 수정사항이 있으면 Codex에 다시 전달
8. Codex 수정 → PR 갱신 → ChatGPT 재리뷰
9. 최종 승인 시 PR에 결과를 남기고 작업 종료글로 적으면 조금 복잡해 보이지만, 실제로 반복하다 보면 흐름은 꽤 단순합니다.
- ChatGPT는 설계와 판단
- Codex는 실제 프로젝트 안에서 실행
- 개발자는 최종 방향과 승인
이렇게 역할을 나눠서 사용하고 있습니다.
ChatGPT에서 하는 일
저는 주로 ChatGPT에서 아래 작업을 진행합니다.
- 요구사항 정리
- 구현 범위 결정
- 여러 설계안 비교
- 작업 순서 나누기
- Codex에 전달할 작업지시문 작성
- PR 전체 리뷰
- 다음 작업 방향 결정
기능을 바로 만들어달라고 요청하기 전에 먼저 이런 내용을 정리합니다.
이번 작업의 목적은 무엇인가?
어디까지 구현해야 하는가?
기존 기능에 어떤 영향을 줄 수 있는가?
테스트 통과 기준은 무엇인가?
이번 작업에서 하지 말아야 할 것은 무엇인가?이 단계에서 방향을 최대한 정리해두면 Codex가 실제 구현을 시작했을 때 불필요하게 넓은 범위를 수정하는 일이 줄어듭니다.
제가 느끼기에는 Codex에게 바로 구현부터 맡기는 것보다, ChatGPT에서 작업 범위를 먼저 정리하고 넘기는 편이 결과도 훨씬 안정적이었습니다.
Codex에서 하는 일
Codex에서는 실제 저장소를 확인해야 하는 작업을 맡깁니다.
- 프로젝트 구조 확인
- 기존 코드 분석
- 기능 구현
- 테스트 실행
- 문서 갱신
- Commit과 Push
- PR 생성
- 구현 코드 자체 리뷰
Codex의 가장 큰 장점은 실제 프로젝트 안에서 관련 파일을 찾고, 수정하고, 테스트까지 이어서 진행할 수 있다는 점입니다.
반대로 설계 단계부터 모든 내용을 Codex에 맡기면 프로젝트를 읽는 과정까지 포함되어 사용량이 더 빠르게 줄 수 있습니다.
그래서 저는 저장소를 직접 봐야 하는 순간부터 Codex를 사용합니다.
프로젝트 현황 문서를 함께 관리한다
Codex를 사용하면서 중요하다고 느낀 것 중 하나가 프로젝트 현황 문서입니다.
대화가 길어지거나 새로운 세션에서 작업을 이어가면 이전 결정사항이 누락될 수 있습니다.
그래서 프로젝트 안에 현재 상황을 정리한 문서를 함께 둡니다.
문서 이름은 프로젝트마다 다를 수 있지만 대략 이런 내용을 관리합니다.
현재 프로젝트 상태
이번 작업의 목표
구현이 완료된 범위
남아 있는 작업
변경하면 안 되는 기존 정책
테스트 및 품질 기준
최근 결정사항예를 들면 작업을 시작할 때 Codex에 이렇게 전달합니다.
프로젝트 현황 문서를 먼저 확인해주세요.
이번 작업은 주문 복구 기능까지만 진행합니다.
기존 주문 생성 정책은 변경하지 않습니다.
구현 후 관련 테스트를 실행하고 결과를 정리해주세요.
Commit과 PR 생성은 자체 리뷰가 통과한 뒤 진행해주세요.처음에는 컨텍스트를 아끼려고 문서를 만들었습니다.
그런데 계속 사용하다 보니 이 문서가 Codex뿐 아니라 저에게도 꽤 유용했습니다.
한동안 프로젝트를 보지 않다가 다시 시작해도 현재 상황을 빠르게 파악할 수 있었고, 작업 범위가 옆으로 퍼지는 것도 막아줬습니다.
결국 AI를 위해 만든 문서가 프로젝트 운영 문서가 된 셈입니다.
구현이 끝나도 바로 PR을 만들지 않는다
Codex가 구현을 완료했다고 바로 PR을 만들지는 않습니다.
먼저 자신이 수정한 코드를 다시 리뷰하도록 합니다.
보통 이런 식으로 요청합니다.
현재 구현 내용을 PR 리뷰어 관점에서 자체 리뷰해주세요.
다음 항목을 중점적으로 확인해주세요.
- 요구사항 누락
- 기존 기능 영향
- 예외 처리
- 테스트 부족
- 불필요하게 넓어진 변경 범위
- 성능 문제
- 보안 문제
- 문서와 실제 구현의 불일치
문제가 있다면 바로 수정하지 말고,
중요도와 근거를 먼저 정리해주세요.같은 Codex가 구현하고 리뷰하는 것이 의미가 있나 싶을 수도 있습니다.
그런데 실제로는 구현할 때와 리뷰할 때 보는 관점이 꽤 다릅니다.
구현할 때는 주로
어떻게 동작하게 만들 것인가?
를 중심으로 봅니다.
반면 리뷰를 요청하면
기존 기능에 영향을 주지는 않는가?
테스트가 빠지지는 않았는가?
불필요한 변경이 포함되지는 않았는가?
같은 부분을 다시 확인합니다.
물론 자체 리뷰를 통과했다고 완전히 믿고 끝내지는 않습니다.
다만 PR을 만들기 전에 한 번 걸러주는 역할은 충분히 합니다.
PR은 다시 ChatGPT에서 리뷰한다
Codex 자체 리뷰가 끝나면 Commit, Push, PR 생성을 요청합니다.
그리고 만들어진 PR은 ChatGPT에서 다시 리뷰합니다.
이 단계에서는 단순히 코드 한 줄씩만 보는 게 아니라 전체 방향을 확인합니다.
요구사항을 제대로 해결했는가?
변경 범위가 과도하지 않은가?
기존 정책을 깨뜨리지는 않았는가?
테스트가 실제 위험을 충분히 검증하는가?
이번 PR을 Merge해도 되는가?수정사항이 나오면 리뷰 내용을 다시 Codex에 전달합니다.
PR 리뷰 결과를 확인해주세요.
각 리뷰 항목이 실제 문제인지 먼저 검토하고,
타당한 항목만 최소 범위로 수정해주세요.
수정 후 테스트를 실행하고
기존 PR에 반영해주세요.Codex가 수정하고 PR을 갱신하면 다시 ChatGPT에서 리뷰합니다.
이 과정을 반복해서 문제가 모두 해결되면 최종 결과를 PR에 남기고 작업을 종료합니다.
처음에는 절약이 목적이었는데 품질 관리가 됐다
처음에는 Codex 한도를 아끼기 위해 역할을 나눴습니다.
그런데 계속 사용하다 보니 오히려 다른 장점이 더 크게 느껴졌습니다.
설계와 구현을 분리하니 작업 범위가 선명해졌고, 구현과 리뷰를 분리하니 놓치는 부분이 줄었습니다.
또 모든 결정을 AI에게 맡기지 않고 각 단계에서 제가 방향을 확인하게 됐습니다.
결국 이렇게 정리할 수 있습니다.
ChatGPT: 생각하고 정리하는 역할
Codex: 프로젝트 안에서 실행하는 역할
개발자: 최종 방향과 승인 책임모든 작업을 하나의 도구에 몰아넣는 것보다 역할을 나눠 사용하는 방식이 저에게는 더 잘 맞았습니다.
Pro 5x로 올리고 나서도 같은 방식을 유지하는 이유
최근에는 Codex 요금제를 Plus에서 Pro 5x로 변경했습니다.
Plus에서는 한도가 아쉬워서 컨텍스트를 최대한 아끼는 방향으로 작업했습니다.
그 습관을 그대로 유지한 채 한도가 늘어나니 이제는 오히려 사용량이 남습니다.
처음에는 한도를 아끼기 위한 방식이었지만 지금은 굳이 바꿀 필요를 느끼지 못하고 있습니다.
역할을 나눠두니 작업 흐름도 깔끔하고, 문제 발생 시 어느 단계에서 잘못됐는지도 찾기 쉽기 때문입니다.
다만 한도가 넉넉해지면서 생긴 부작용도 있습니다.
예전에는 문서 하나를 읽힐 때도
이 문서까지 정말 필요한가?
를 고민했는데, 요즘은 일단 시켜보는 경우가 많아졌습니다ㅎㅎ
한도가 여유로워진 만큼 컨텍스트 관리가 조금 느슨해진 건 사실입니다.
Plus에서 만들어둔 절약 습관 덕분인지 Pro 5x에서는 아직 꽤 여유롭게 사용하고 있습니다.
다음 목표는 반복 작업 자동화
이제 다음으로 해보고 싶은 건 자동화입니다.
매 PR마다 반복하는 작업들이 있습니다.
- 구현 완료 후 자체 리뷰
- 테스트 결과 정리
- PR 생성
- 리뷰 결과 전달
- 수정 후 재검토
- 프로젝트 현황 문서 갱신
- 최종 PR 코멘트 작성
이런 작업들을 조금씩 자동화해보고 싶습니다.
예를 들면 Codex가 구현을 끝내면 자동으로 자체 리뷰를 수행하고, 품질 기준을 통과한 경우에만 PR을 만들게 하는 방식입니다.
PR 리뷰 결과가 등록되면 수정사항을 다시 분류하고, 필요한 변경만 반영하게 만들 수도 있을 것 같습니다.
다만 열심히 자동화를 세팅해놓고 실행했다가 주간 한도가 아이스크림처럼 녹아버릴까 봐 아직은 조금 걱정됩니다…ㅎㅎ
한도가 많아지니 이제는 아끼는 방법이 아니라 어디까지 자동화할 수 있을지를 고민하게 되네요.
마치며
처음에는 Codex 사용량을 아끼려고 ChatGPT와 역할을 나눴습니다.
그런데 계속 사용하다 보니 이 방식이 단순한 절약법이 아니라, 설계와 구현, 리뷰를 분리하는 하나의 개발 프로세스가 됐습니다.
물론 이 방식이 모든 개발자에게 정답은 아닙니다.
ChatGPT에서도 코드를 분석할 수 있고, Codex에서도 설계와 리뷰를 진행할 수 있습니다.
다만 저처럼 사이드 프로젝트를 혼자 진행하면서 AI를 적극적으로 사용한다면, 도구마다 역할을 나눠보는 것도 꽤 괜찮은 방법이라고 생각합니다.
앞으로는 이 반복 과정을 조금씩 자동화해보려고 합니다.
어디까지 자동화할 수 있을지, 실제로 생산성이 얼마나 달라질지, 사용량은 얼마나 줄거나 늘어날지 직접 해보면서 기록해볼 생각입니다.
그리고 첫 번째 목표도 하나 정했습니다.
더도 말고 Codex 구독료부터 벌어보기.
무엇으로 수익화할지는 아직 정하지 못했지만, 이것저것 시도하는 과정도 함께 기록해보겠습니다ㅎㅎ
