Codex 토큰을 줄이려다 AI와 일하는 방식을 다시 배웠습니다

GuideNet 프로젝트를 진행하면서 나는 나름대로 Codex를 구조적으로 쓰고 있다고 생각했다.

처음 바이브코딩을 했을 때처럼 “이거 만들어줘”, “알아서 고쳐줘”라고 던지는 방식은 아니었다. 이제는 GPT를 통해 Codex에게 전달할 프롬프트를 먼저 정리했다. 작업 목적, 범위, 하지 말아야 할 일, 검증 기준, 보고 형식까지 꽤 자세히 적었다.

 

나름대로 체계가 생겼다고 생각했다.

 

그런데 막상 Codex로 작업을 계속 진행하다 보니 새로운 문제가 보였다.

토큰이 너무 빨리 소진됐다.

 

처음에는 당연한 비용이라고 생각했다. 정확하게 지시하려면 긴 프롬프트가 필요하고, 긴 프롬프트를 쓰면 토큰을 많이 쓰는 게 어쩔 수 없다고 생각했다.

 

하지만 작업이 반복될수록 이상했다.

매번 거의 같은 내용을 다시 설명하고 있었다.

 

“너는 GuideNet 프로젝트의 Tech Lead 역할이다.”
“작업 전에 문서를 확인해라.”
“범위 밖 작업은 하지 마라.”
“QA 결과를 분리해서 보고해라.”
“승인 전 commit하지 마라.”
“구현 완료와 검증 완료를 혼동하지 마라.”

 

중요한 내용이긴 했다.
하지만 매번 100줄 가까운 프롬프트를 넣는 방식은 점점 비효율적으로 느껴졌다.

 

오늘의 작업은 여기서 시작됐다.

 

“Codex에게 정확하게 지시하면서도, 프롬프트를 줄일 수는 없을까?”

---

첫 번째 시도: 프롬프트를 영어로 써보기

처음 시도한 방법은 단순했다.

프롬프트를 영어로 쓰는 것이었다.

 

AI 도구를 쓰다 보면 이런 이야기를 자주 듣는다.

영어가 한국어보다 토큰을 덜 쓴다.

 

토큰은 쉽게 말하면 AI가 문장을 읽고 처리하는 단위다.
우리가 입력하는 프롬프트도 토큰이고, AI가 출력하는 답변도 토큰이다.

 

비개발자 입장에서 설명하면, 토큰은 AI와 대화할 때 쓰는 작업 연료에 가깝다. 같은 내용을 전달하더라도 더 적은 토큰으로 전달할 수 있다면, 작업 비용을 줄일 수 있다.

 

그래서 먼저 GPT에게 내가 한국어로 생각한 작업 내용을 영어 프롬프트로 정리하게 했다.

 

예를 들면 이런 식이다.

한국어로는 이렇게 생각한다.

“이번 작업은 T-098이고, Proposal Submission 구조를 검토하는 작업이야. PM Scope는 이미 정해졌고, Tech Lead 관점에서 DB 구조, 권한, 서버 액션, 오류 처리 범위를 검토해야 해. 구현은 하지 말고 설계 리뷰만 해줘.”

 

이걸 GPT를 통해 Codex용 영어 프롬프트로 바꾼다.

“Act as the Tech Lead for GuideNet SEA. Review T-098 Proposal Submission Architecture based on the existing PM scope. Do not implement code. Focus on schema, permissions, server action boundaries, error contracts, and migration risks…”

 

이 방식은 분명 도움이 됐다.

한국어로 길게 설명하던 내용을 영어로 정리하면 조금 더 압축되는 느낌이 있었다.

Codex도 영어 프롬프트를 잘 이해했다.

 

하지만 이것만으로는 한계가 있었다.

프롬프트를 영어로 바꿔도, 매번 같은 배경 설명을 반복해야 한다는 문제는 그대로였기 때문이다.

---

진짜 문제는 언어가 아니라 반복이었다

처음에는 토큰 문제가 “한국어냐 영어냐”의 문제라고 생각했다.

하지만 작업을 계속해보니 더 근본적인 원인이 보였다.

 

진짜 문제는 언어가 아니었다.
반복되는 지시사항을 매번 프롬프트에 다시 쓰는 것이었다.

 

예를 들어 Codex에게 한 번 작업을 맡길 때마다 이런 내용이 반복됐다.

매번 반복하던 내용	왜 필요했나
프로젝트의 현재 Phase	Codex가 현재 작업 맥락을 알아야 함
Codex의 역할	PM, Tech Lead, FE, BE, QA 중 어떤 관점인지 고정
작업 전 확인 문서	엉뚱한 파일을 기준으로 작업하지 않게 하기 위해
작업 범위	Codex가 임의로 기능을 확장하지 않게 하기 위해
금지사항	승인 없이 구현, commit, migration 적용을 막기 위해
완료 기준	“구현함”과 “검증됨”을 구분하기 위해
보고 형식	변경 파일, 검증 결과, 리스크를 빠짐없이 받기 위해

 

하나하나 보면 모두 필요한 내용이다.

 

문제는 이것들이 매번 거의 똑같이 반복된다는 점이었다.

 

그렇다면 프롬프트를 줄이는 방법은 단순히 말을 짧게 하는 것이 아니었다.

 

반복되는 내용을 다시 쓰지 않아도 되는 구조를 만들어야 했다.

---

두 번째 시도: 반복 지시를 md 문서로 빼기

여기서 방향이 바뀌었다.

매번 프롬프트에 100줄 가까이 쓰던 내용을, 프로젝트 안의 md 문서로 분리하기로 했다.

 

md 파일은 Markdown 문서다.
쉽게 말하면 개발 프로젝트에서 많이 쓰는 텍스트 문서 형식이다. 제목, 표, 목록, 코드 블록 등을 간단하게 정리할 수 있어 문서화에 자주 사용된다.

 

내가 한 일은 간단히 말하면 이렇다.

Codex에게 반복해서 설명하던 작업 규칙을 docs/AI/ 폴더 안에 문서로 만들어두었다.

 

이렇게 하면 앞으로 Codex에게 매번 모든 내용을 설명하지 않아도 된다.

 

기존에는 프롬프트 안에 모든 지시를 넣어야 했다.

너는 GuideNet 프로젝트의 Tech Lead 역할이다.
현재 Phase는 Phase 3다.
작업 전 PROJECT_PROGRESS, NEXT_TASKS, DECISIONS를 확인해라.
범위 밖 구현은 하지 마라.
QA와 구현을 혼동하지 마라.
승인 전 commit하지 마라.
...

 

이제는 이렇게 줄일 수 있다.

Read docs/AI/README.md and the Tech Lead template.
Then perform T-098 only.
Do not implement code.
Report scope, risks, required files, and next handoff.

 

프롬프트가 짧아졌다.

 

하지만 중요한 맥락을 버린 것은 아니다.

맥락을 프롬프트에서 문서로 옮긴 것이다.

---

100줄 프롬프트를 25줄 프롬프트로 줄인다는 것

이번 작업을 통해 체감한 변화는 꽤 컸다.

기존에는 Codex에게 한 번 작업을 지시하려면 100줄 가까운 프롬프트가 필요했다.
역할 설명, 프로젝트 배경, 작업 순서, 금지사항, 보고 방식까지 모두 넣어야 했기 때문이다.

 

그런데 오늘 만든 방식에서는 약 25줄 정도로 줄일 수 있었다.

 

물론 정확한 줄 수가 핵심은 아니다.

중요한 것은 구조가 바뀌었다는 점이다.

기존 방식	변경 후 방식
프롬프트가 모든 배경과 규칙을 포함	문서가 배경과 규칙을 담당
Codex에게 매번 긴 설명 필요	Codex가 문서를 읽고 작업 시작
같은 지시를 반복 입력	공통 지시는 md 파일로 고정
프롬프트가 길어질수록 토큰 증가	프롬프트는 짧게, 기준은 문서로 유지
누락 가능성 높음	문서 기준으로 일관성 확보

 

이 변화는 단순한 토큰 절약이 아니었다.

 

프롬프트가 줄면서 작업 방식도 더 안정적으로 바뀌었다.

---

오늘 만든 docs / AI / 문서 세트

오늘 만든 문서들은 Codex가 작업할 때 반복해서 참고해야 할 기준을 담고 있다.

문서	역할
docs/AI/README.md	AI 작업 문서의 입구
workflow.md	작업이 어떤 순서로 진행되는지
architecture_rules.md	기술 구조를 함부로 바꾸지 않기 위한 규칙
coding_principles.md	코드를 고칠 때 지켜야 할 기본 원칙
definition_of_done.md	“완료”라고 말하기 위한 기준
release_checklist.md	공개 또는 배포 전 확인할 항목
role templates	PM, Tech Lead, Backend, Frontend, QA 역할별 기본 지시문

 

겉으로 보면 문서 정리 작업이다.

 

하지만 실제 의미는 더 컸다.

 

이전에는 AI 협업 방식이 대화 안에 있었다.

내가 매번 설명하고, GPT가 정리하고, Codex가 그때그때 이해해야 했다.

 

이제는 그 기준을 프로젝트 안에 넣어두기 시작했다.

 

즉, 대화에 떠다니던 작업 규칙을 프로젝트 자산으로 만든 것이다.

---

workflow.md: AI가 일하는 순서를 정했다

가장 중요한 문서 중 하나는 workflow.md였다.

 

이 문서는 작업 순서를 정리한다.

 

예전에는 Codex에게 바로 “이 기능 만들어줘”라고 할 수 있었다.

하지만 그렇게 하면 Codex가 너무 많은 것을 한 번에 해버릴 수 있다.

 

그래서 GuideNet에서는 작업 흐름을 이렇게 정리했다.

1. PM이 무엇을 만들지 범위를 정한다.
2. Tech Lead가 기술적으로 가능한지 검토한다.
3. Backend 또는 Frontend가 구현한다.
4. QA가 검증한다.
5. PM이 최종 수용 여부를 판단한다.
6. 검증과 승인이 끝난 뒤 Git에 반영한다.

여기서 PM, Tech Lead, Backend, Frontend, QA는 실제 사람이 아니라 AI에게 부여하는 역할일 수도 있다.

 

중요한 것은 AI가 한 번에 모든 역할을 하지 않게 하는 것이다.

기획한 AI가 바로 구현하고, 구현한 AI가 스스로 QA하고, QA가 스스로 완료 선언까지 하면 위험하다.

 

그래서 순서를 나눴다.

---

definition_of_done.md: 완료의 기준을 적었다

또 중요한 문서는 definition_of_done.md다.

Definition of Done은 말 그대로 완료의 기준이다.

 

개발을 잘 모르는 사람이라면 “코드가 만들어졌으면 완료 아닌가?”라고 생각할 수 있다.
나도 처음에는 비슷하게 생각했다.

 

하지만 프로젝트를 진행하면서 알게 됐다.

구현은 완료의 일부일 뿐이다.

 

정말 완료라고 말하려면 더 많은 것을 확인해야 한다.

확인해야 할 것	의미
정해진 범위 안에서 작업했는가	불필요한 확장을 막기 위해
기존 기능을 깨뜨리지 않았는가	새 기능이 다른 기능을 망치지 않게 하기 위해
권한이 제대로 막히는가	보면 안 되는 데이터를 막기 위해
QA가 통과했는가	실제 흐름을 검증하기 위해
문서가 업데이트됐는가	다음 작업자가 맥락을 잃지 않게 하기 위해
PM이 수용했는가	제품 기준으로 받아들일 수 있는지 판단하기 위해

 

이 문서를 만들어두면 Codex가 “구현 완료”라고 말해도 바로 “프로젝트 완료”로 착각하지 않을 수 있다.

 

사실 이 문서는 Codex를 위한 문서이기도 하지만, 나 자신을 위한 안전장치이기도 하다.

---

release_checklist.md: 공개 전에 확인할 목록을 만들었다

release_checklist.md는 공개 또는 배포 전에 확인해야 할 항목을 정리한 문서다.

Release는 쉽게 말하면 만든 기능을 실제 사용 가능한 상태로 내보내는 것이다.

 

블로그 글을 발행하기 전에 제목, 오탈자, 이미지, 링크를 확인하는 것처럼, 서비스도 공개 전에 확인할 것이 있다.

 

예를 들면 이런 것들이다.

 

관리자만 접근해야 할 화면이 잘 막히는가.
일반 사용자가 보지 말아야 할 데이터가 노출되지 않는가.
기능을 고치면서 다른 기능이 깨지지 않았는가.
남은 문제가 있다면 known issue로 기록됐는가.
공개를 막는 치명적인 문제가 남아 있지는 않은가.

 

이런 기준이 없으면 “대충 괜찮아 보인다”는 느낌으로 넘어가기 쉽다.

 

체크리스트는 그 느낌을 막아준다.

---

role templates: 매번 역할 설명을 반복하지 않기 위해

오늘 만든 것 중 실용적으로 가장 기대되는 것은 role template이다.

 

GuideNet에서는 Codex를 하나의 만능 도구로 쓰지 않으려고 한다.

 

PM 역할, Tech Lead 역할, Backend 역할, Frontend 역할, QA 역할을 나눠서 운영한다.

이 역할들을 매번 프롬프트에 길게 쓰면 토큰을 많이 쓴다.

 

그래서 역할별 기본 지시문을 템플릿으로 만들었다.

 

예를 들어 QA 역할이라면 이런 기준이 들어간다.

 

“구현하지 말고 검증만 한다.”
“PASS, FAIL, BLOCKED를 구분한다.”
“근거 없는 PASS를 주지 않는다.”
“발견한 문제는 수정하지 말고 보고한다.”

Tech Lead라면 다르다.

“구현 전 구조를 검토한다.”
“DB, 권한, 서버 로직의 리스크를 확인한다.”
“범위 밖 구현을 하지 않는다.”
“다음 역할에 넘길 작업을 정리한다.”

 

이제는 매번 역할을 설명하지 않아도 된다.

 

해당 역할의 template을 읽게 하면 된다.

---

이번에 배운 가장 중요한 것

오늘의 가장 큰 배움은 이것이다.

프롬프트를 줄인다는 것은 설명을 없애는 것이 아니라, 설명의 위치를 바꾸는 것이다.

 

처음에는 영어로 바꾸는 것부터 시작했다.
그것도 도움이 됐다.

 

하지만 더 큰 변화는 반복 지시를 문서로 옮긴 것이었다.

프롬프트 안에 있던 100줄의 설명 중 상당수는 매번 새로 쓸 필요가 없는 내용이었다.

프로젝트의 작업 방식, 역할 기준, 완료 기준, 릴리즈 체크리스트는 한 번 정리해서 문서로 두면 된다.

 

그다음부터는 Codex에게 이렇게 말하면 된다.

 

“이 문서를 읽고, 이번 작업만 해줘.”

 

이렇게 하면 프롬프트는 줄어든다.

하지만 기준은 사라지지 않는다.

 

오히려 기준이 더 명확해진다.

---

겸손하게 다시 배운 하루였다

솔직히 말하면, 나는 이미 꽤 구조적으로 Codex를 쓰고 있다고 생각했다.

 

GPT로 프롬프트를 정제했고,
역할을 나눴고,
하지 말아야 할 일을 적었고,
작업 결과를 문서화했다.

 

그래서 어느 정도는 잘하고 있다고 생각했다.

 

그런데 오늘 또 하나를 배웠다.

구조적인 프롬프트를 쓰는 것과,
구조적인 작업 환경을 만드는 것은 다르다.

 

나는 그동안 프롬프트를 잘 쓰려고 했다.
하지만 이제는 프롬프트가 모든 것을 떠안지 않게 만들어야 한다는 것을 배웠다.

 

좋은 프롬프트도 중요하다.
하지만 프로젝트가 길어질수록 더 중요한 것은 문서화된 작업 환경이다.

 

AI에게 매번 같은 이야기를 반복하는 것이 아니라,
AI가 읽고 따를 수 있는 기준을 프로젝트 안에 남겨야 한다.

 

오늘은 그걸 배웠다.

아직 완벽하게 안다고 말할 수는 없다.
아마 다음 작업을 하면서 또 고칠 부분이 보일 것이다.
어떤 문서는 너무 길 수도 있고, 어떤 템플릿은 부족할 수도 있다.

 

그래도 괜찮다.

바이브코딩은 나에게 아직도 배우는 과정이다.
하나씩 해보고, 문제를 발견하고, 다시 구조를 고치는 과정이다.

 

오늘은 그중에서도 꽤 중요한 문제를 하나 해결한 날이었다.

---

비개발자 PM에게 이 경험이 의미 있었던 이유

이 경험은 개발자가 아닌 PM에게도 의미가 있었다.

 

처음에는 AI 코딩이라고 하면 코드 자체가 핵심이라고 생각하기 쉽다.

하지만 실제로 해보면 코드보다 더 자주 마주치는 문제는 이런 것이다.

 

“AI에게 어디까지 설명해야 하지?”
“매번 같은 말을 반복하지 않을 방법은 없을까?”
“짧게 지시하면 결과 품질이 떨어지지 않을까?”
“작업 기준을 어떻게 유지하지?”
“새 스레드에서도 같은 방식으로 일하게 하려면 어떻게 해야 하지?”

 

이 질문들은 개발자가 아니어도 충분히 이해할 수 있다.

 

회사에서 일하는 방식과 비슷하다.

 

매번 신입에게 말로 설명하는 대신 온보딩 문서를 만든다.
반복되는 업무는 체크리스트로 만든다.
역할이 헷갈리면 R&R 문서를 만든다.
배포 전에는 확인 목록을 만든다.

 

AI와 일하는 것도 크게 다르지 않았다.

Codex도 매번 새로 온 작업자처럼 문서를 읽고 시작하게 만들면 된다.

 

그렇게 하면 나는 매번 100줄을 설명하지 않아도 된다.
Codex는 매번 기준을 추측하지 않아도 된다.

 

이게 오늘 만든 구조의 가장 큰 의미다.

---

결론: 프롬프트 절약은 결국 일하는 방식의 개선이었다

오늘 작업은 처음에는 토큰 절약에서 시작했다.

프롬프트를 영어로 쓰면 토큰을 줄일 수 있다는 이야기를 듣고, 먼저 영어 프롬프트를 시도했다.

 

그다음 더 근본적인 문제를 발견했다.

토큰을 많이 쓰는 이유는 프롬프트의 언어 때문만이 아니었다.
매번 같은 작업 규칙을 반복해서 설명하고 있었기 때문이었다.

 

그래서 반복되는 지시를 docs/AI/ 문서로 옮겼다.
작업 순서, 구조 변경 원칙, 코드 작성 기준, 완료 기준, 릴리즈 체크리스트, 역할별 템플릿을 만들었다.

 

그 결과 앞으로는 100줄 가까운 프롬프트 대신, 약 25줄 정도의 짧은 프롬프트로도 Codex에게 작업을 맡길 수 있는 구조가 생겼다.

물론 이것이 최종 정답은 아닐 것이다.

 

하지만 오늘 하나는 분명히 배웠다.

프롬프트를 줄이려면 생각을 줄이면 안 된다.
반복되는 생각을 문서로 옮겨야 한다.

 

바이브코딩을 하면서 또 한 걸음 배웠다.

 

AI에게 일을 잘 시키는 방법은 더 멋진 문장을 쓰는 것이 아니라,
AI가 계속 같은 기준으로 일할 수 있는 환경을 만들어주는 것이었다.

 

오늘은 그걸 처음으로 조금 제대로 실천해본 날이었다.