메타 설명
ChatGPT와 Codex 사용량을 줄이면서 결과 품질은 유지하는 방법을 정리했습니다. GPT-5.6 모델 선택, 추론 강도, 컨텍스트 관리, Codex 프롬프트와 바이브 코딩 워크플로까지 실전 중심으로 설명합니다.

저는 ChatGPT Plus 사용자입니다. 하지만 저에게 필요한 왠만한 앱은 부족함 없이 개발하고 있습니다. 이번 포스팅에서는 제가 어떤식으로 토큰을 관리하면서 개발을 하고 있는지 설명드리고자 합니다.

어제 Codex에서 프로그램 4개를 동시에 개발하면서 GPT-5.6 Ultra를 사용했습니다. 여러 프로그램의 코드를 동시에 분석하고 기능을 추가하거나 수정하는 작업을 진행했는데, 결과는 꽤 충격적이었습니다.

딱 1시간 만에 일주일치 사용 한도를 거의 다 소모했습니다.

물론 GPT-5.6 Ultra는 강력했습니다. 여러 프로그램을 동시에 분석하고 복잡한 작업을 처리하는 능력, 결과물의 수준, 작업 속도 모두 만족스러웠습니다.

하지만 동시에 이런 생각이 들었습니다.

모든 개발 작업에 항상 가장 높은 성능의 모델을 사용하는 것이 정말 효율적일까?

특히 바이브 코딩을 하다 보면 AI 사용량은 생각보다 빠르게 늘어납니다.

처음에는 기능 하나만 추가하려고 했는데, 수정 과정에서 다른 문제가 발견됩니다. 그 문제를 고친 뒤 다시 검증을 요청하고, 디자인을 조금 더 다듬고, 테스트 중 발견된 오류를 또 수정합니다. 이런 과정이 몇 번만 반복되어도 처음 예상했던 것보다 훨씬 많은 ChatGPT와 Codex 사용량을 소비하게 됩니다.

그렇다고 무조건 가벼운 모델만 사용하는 것도 답은 아니었습니다.

간단한 문구 수정이나 CSS 조정, 명확한 단일 버그 수정에서는 가벼운 모델도 꽤 좋은 결과를 보여줍니다. 하지만 요구사항이 복잡해지면 이야기가 달라집니다. 예를 들어 10개의 수정사항을 요청했는데 그중 몇 가지가 누락되어 다시 작업을 요청해야 하는 경우가 생깁니다.

한 번의 요청에 들어가는 사용량은 적었지만, 누락된 기능을 다시 구현하고 검증하는 과정이 반복되면 결국 시간과 사용량을 모두 더 많이 쓰게 됩니다.

그래서 중요한 것은 단순히 “가장 적게 쓰는 모델을 고르는 것”이 아니었습니다.

작업의 난이도에 맞는 모델을 선택하고, 필요한 만큼만 추론하게 하며, 불필요한 컨텍스트와 재작업을 줄이는 것.

이것이 ChatGPT와 Codex의 사용량을 줄이면서도 결과물의 품질을 유지하는 가장 현실적인 방법입니다.

현재 저는 작업 성격에 따라 모델과 추론 수준을 나누어 사용하고 있습니다.

기획, 아키텍처 설계, 복잡한 오류 분석처럼 처음의 판단이 중요한 작업에는 높은 성능의 모델을 사용하고, 이미 방향이 정해진 단순 수정이나 반복 작업에는 상대적으로 가벼운 모델을 사용하는 방식입니다.

이 글에서는 OpenAI가 공개한 GPT-5.6 및 Codex 관련 자료와 실제 바이브 코딩 경험을 바탕으로 ChatGPT와 Codex의 사용량을 효과적으로 줄이는 방법을 정리해보겠습니다.

단순히 “프롬프트를 짧게 쓰세요” 같은 이야기가 아닙니다.

모델 선택 → 추론 수준 → 프롬프트 작성 → 컨텍스트 관리 → Codex 작업 범위 → 검증 방법 → 개발 워크플로

이 흐름에 따라 실제 개발 과정에서 바로 적용할 수 있는 방법들을 하나씩 살펴보겠습니다.

1. ChatGPT 토큰 절약의 핵심은 ‘가장 싼 모델’이 아닙니다

ChatGPT나 Codex의 사용량을 줄이려고 할 때 가장 먼저 떠오르는 방법은 간단합니다.

더 가벼운 모델을 사용하는 것입니다.

실제로 GPT-5.6 계열도 작업 성격과 필요한 성능에 따라 여러 모델로 나뉘어 있습니다. OpenAI는 GPT-5.6 계열을 대략 다음과 같이 설명합니다.

OpenAI는 GPT-5.6을 소개하면서 Luna를 빠르고 경제적인 모델, Terra를 균형형 모델, Sol을 복잡한 작업을 위한 플래그십 모델로 설명하고 있습니다.

실제로 사용해 보면 모델별 사용량 차이가 크게 느껴집니다.

제가 개발 작업 중 GPT-5.6 Luna를 반나절 가까이 사용했을 때는 ChatGPT Plus의 주간 사용량 표시가 약 2~3% 정도만 줄어든 경우도 있었습니다. 반면 Ultra를 사용해 복잡한 작업을 진행했을 때는 하나의 작업만으로도 사용량이 눈에 띄게 줄어드는 경우가 있었습니다.

다만 이 부분은 제가 실제로 사용하면서 확인한 개인적인 체감 사례입니다. ChatGPT Plus에서 표시되는 사용 한도는 API에서 계산하는 토큰 사용량과 완전히 같은 개념은 아니기 때문에, 정확한 토큰 소비량이라기보다는 모델별 사용량 차이를 체감한 사례로 보는 것이 좋습니다.

어쨌든 사용량만 놓고 보면 가벼운 모델은 매우 매력적입니다.

하지만 복잡한 개발 작업을 맡겨보면 또 다른 문제가 생깁니다.

예를 들어 수정해야 할 요구사항을 10개 전달했다고 가정해보겠습니다. 첫 번째 작업이 끝난 뒤 확인해보니 몇 가지 기능이 빠져 있습니다.

“3번 기능이 빠졌어.”

다시 수정한 뒤 확인했더니 또 다른 부분이 누락되어 있습니다.

“5번도 구현이 안 됐는데?”

그리고 다시 테스트했더니 이번에는 기존 기능에 문제가 생겼습니다.

“기존 기능이 깨졌어. 다시 확인해줘.”

이렇게 되면 처음에는 사용량을 아끼기 위해 가벼운 모델을 선택했지만, 누락된 기능을 다시 구현하고 오류를 수정하고 재검증하는 과정에서 오히려 더 많은 시간과 사용량을 소비하게 됩니다.

결국 중요한 것은 한 번의 요청에 얼마나 적게 사용했느냐가 아닙니다.

진짜 봐야 할 것은 원하는 결과에 도달하기까지 들어간 전체 비용입니다.

이를 간단하게 표현하면 다음과 같습니다.

전체 비용 = 모델 사용량 + 재작업 + 디버깅 + 검토 + 사람이 확인하는 시간

가벼운 모델로 한 번 작업하는 비용이 매우 적더라도 세 번, 네 번 다시 수정해야 한다면 처음부터 성능이 더 높은 모델을 사용하는 것이 오히려 효율적일 수 있습니다.

반대로 버튼 문구 하나를 수정하거나 CSS 간격을 조금 조정하는 작업에 최고 수준의 모델을 사용하는 것도 낭비입니다.

그래서 모델을 선택할 때는 단순히 “어떤 모델이 가장 적게 사용할까?”만 생각해서는 안 됩니다.

더 중요한 질문은 이것입니다.

“이 작업을 가장 적은 재작업으로 끝낼 수 있는 모델은 무엇인가?”

OpenAI 역시 GPT-5.6을 설명할 때 단순한 토큰 가격보다 performance per dollar, 즉 같은 비용으로 얼마나 높은 품질의 결과와 작업량을 얻을 수 있는지를 중요한 효율성 기준으로 제시하고 있습니다.

결국 ChatGPT와 Codex의 사용량을 줄이기 위해서는 무조건 작은 모델을 선택하는 것이 아니라, 작업 난이도에 맞는 모델을 선택해야 합니다.

그리고 이 원칙이 다음에 설명할 작업별 모델 선택, 즉 Model Routing으로 이어집니다.

2. 그래서 저는 작업마다 모델을 다르게 사용합니다

제가 가장 효과적이라고 느끼는 방식은 Model Routing입니다.

쉽게 말하면, 작업에 따라 모델과 추론 수준을 다르게 선택하는 방식입니다. 무조건 Sol Ultra나 Extra High를 사용하는 것도 아니고, 무조건 가벼운 모델만 사용하는 것도 아닙니다.

대략 다음처럼 나눌 수 있습니다.

ChatGPT에서는 GPT-5.6 Sol에 대해 Instant, Medium, High, Extra High와 같은 추론 수준을 제공합니다. 높은 단계일수록 복잡한 문제에 더 많은 추론을 사용할 수 있습니다.

하지만 여기서 중요한 점이 있습니다.

높은 추론이 항상 좋은 것은 아닙니다.

OpenAI 역시 reasoning effort가 높을수록 모든 작업에서 항상 같은 비율로 성능이 좋아지는 것은 아니며, 작업에 맞게 조절하는 것을 권장하고 있습니다.

즉, 버튼 색깔 하나를 고치는 데 Extra High를 사용할 필요는 없습니다.

반대로 데이터 구조와 권한 시스템을 처음 설계하는 작업을 가장 낮은 추론 수준으로 맡기는 것도 위험합니다.

핵심은 간단합니다.

많이 생각해야 하는 작업에는 충분한 추론을 쓰고, 정답 범위가 좁은 작업에는 추론을 아끼는 것.

이렇게 해야 사용량을 줄이면서도 결과물의 품질을 유지할 수 있습니다.

3. 제가 사용하는 ChatGPT → Codex 개발 루프

제가 현재 가장 많이 사용하는 방식은 다음과 같습니다.

ChatGPT → Codex → ChatGPT → Codex

조금 더 구체적으로 표현하면,

계획 → 구현 → 검토 → 수정 → 반복

입니다.

제가 사용하는 흐름은 대략 다음과 같습니다.

이 구조가 좋은 이유는 역할이 명확하기 때문입니다.

ChatGPT에게 계속 코드를 조금씩 수정하게 하기보다 먼저

“무엇을 만들어야 하는가?”

를 정리합니다.

그다음 Codex에게

“이 요구사항을 실제 저장소에 구현하라.”

라고 맡기는 방식입니다.

ChatGPT는 기획자이자 검수자 역할을 하고, Codex는 실제 구현자 역할을 합니다. 이렇게 역할을 나누면 작업 흐름이 더 명확해지고, 불필요한 반복도 줄어듭니다.

그리고 검수 자체를

특히 복잡한 앱을 개발할 때는 처음부터 Codex에게 “알아서 잘 만들어줘”라고 맡기는 것보다, ChatGPT에서 목표와 성공 기준을 먼저 정리한 뒤 Codex에 전달하는 편이 안정적입니다.

4. 가장 비싼 모델은 ‘처음’에 쓰는 것이 오히려 저렴할 수 있습니다.

조금 역설적이지만, 저는 프로젝트 초반에 좋은 모델을 사용하는 편이 오히려 사용량을 절약할 수 있다고 생각합니다.

예를 들어 업무용 앱을 만든다고 해보겠습니다.

초기 설계 단계에서 결정해야 하는 것은 생각보다 많습니다.

데이터 구조, 사용자 권한, API 구조, 화면 구조, 상태 관리, 검색 방식, 로그, 오류 처리, 테스트 방법까지 정해야 합니다.

이때 구조를 대충 잡으면 나중에 기능 하나를 추가할 때마다 기존 구조를 뜯어고쳐야 합니다. 처음에는 빠르게 만든 것처럼 보이지만, 뒤로 갈수록 수정 비용이 계속 커집니다.

그래서 저는 초기 기획이나 구조 설계 단계에서는 GPT-5.6 Sol High나 Extra High처럼 충분히 추론할 수 있는 설정을 사용하는 편입니다.

대신 계획이 확정된 뒤에는 작업 성격에 따라 추론 수준을 낮춥니다. 이미 방향이 정해진 단순 구현, 문구 수정, 스타일 수정, 명확한 버그 수정까지 모두 최고 성능 모델로 처리할 필요는 없기 때문입니다.

쉽게 말하면 다음 원칙입니다.

생각이 비싼 곳에는 좋은 모델을 쓰고, 손이 많이 가는 반복 작업에는 가벼운 모델을 쓴다.

초반 설계에서 한 번 잘못된 판단을 줄이면 이후의 재작업을 크게 줄일 수 있습니다. 그래서 좋은 모델은 무조건 아끼기보다 실패 비용이 큰 단계에 집중적으로 사용하는 것이 더 효율적입니다.

5. Ultra는 아무 작업에나 켜는 옵션이 아닙니다

GPT-5.6에서 특히 주의해야 할 것이 Ultra입니다.

Ultra를 단순히

“Extra High보다 더 많이 생각하는 모드”

라고 이해하면 조금 부족합니다.

OpenAI 설명에 따르면 Ultra는 하나의 에이전트가 오래 생각하는 방식이라기보다, 여러 하위 에이전트를 활용해 복잡한 작업을 병렬로 처리하는 방식에 가깝습니다.

따라서 Ultra는 이런 작업에 효과적일 수 있습니다.

예를 들어 대규모 프로젝트에서 프론트엔드, 백엔드, 보안, 테스트, 데이터 구조를 동시에 분석해야 하는 경우입니다. 여러 관점에서 병렬로 탐색해야 하는 작업이라면 Ultra의 장점이 살아납니다.

반대로 이런 요청에는 과합니다.

“로그인 버튼을 오른쪽으로 20px 이동해줘.”

이런 작업은 병렬 탐색이 필요한 문제가 아닙니다. 이미 수정 범위가 명확하고, 깊은 추론도 거의 필요하지 않습니다.

그래서 저는 Ultra를 항상 켜두는 최고성능 옵션이 아니라, 구조적으로 병렬 탐색이 필요한 특별한 작업용 옵션으로 생각하는 편이 좋다고 봅니다.

Ultra는 강력합니다. 하지만 강력한 만큼 사용량도 빠르게 소모될 수 있습니다.

따라서 Ultra를 사용할 때는 먼저 이렇게 질문해보는 것이 좋습니다.

“이 작업은 정말 여러 관점에서 동시에 분석해야 하는 복잡한 작업인가?”

답이 아니라면 High나 Extra High, 또는 더 가벼운 모델로도 충분할 수 있습니다.

6. 토큰을 줄이는 가장 쉬운 방법: 목표와 성공 기준을 먼저 적습니다

제가 최근 프롬프트에서 가장 중요하게 보는 부분은 목표와 성공 기준입니다.

AI에게 단순히 이렇게 요청할 수 있습니다.

회원가입 기능 만들어줘.

하지만 이런 요청은 완료 조건이 불분명합니다.

회원가입 화면만 만들면 되는지, 데이터 저장까지 해야 하는지, 관리자 승인 기능이 필요한지, 기존 로그인과 어떻게 연결해야 하는지 알 수 없습니다.

이렇게 바꾸는 것이 좋습니다.

회원가입 기능을 구현한다.
목적은 관리자가 승인한 사용자만 서비스를 사용할 수 있도록 하는 것이다.
성공 기준은 다음과 같다.

1. 사용자가 가입 신청을 할 수 있어야 한다.

2. 관리자가 가입 신청을 승인할 수 있어야 한다.

3. 승인된 사용자만 로그인할 수 있어야 한다.

4. 기존 로그인 기능은 깨지면 안 된다.

5. 관련 테스트를 실행하고 실패 항목이 있으면 결과에 표시한다.

차이는 큽니다.

특히 성공 기준이 명확하면 모델이 불필요한 탐색을 줄이고, 스스로 작업 종료 시점을 판단하기 쉬워집니다.

AI에게 “잘 만들어줘”라고 하면 AI가 스스로 완성 기준을 추측해야 합니다. 반면 “이 조건을 만족하면 완료”라고 알려주면 작업 범위가 훨씬 명확해집니다.

Codex 같은 코딩 에이전트에서는 이 차이가 더 커집니다.

완료 기준이 없으면 저장소를 더 많이 탐색하고, 더 많은 가능성을 검토하고, 필요 이상의 작업까지 건드릴 수 있습니다. 반대로 완료 기준이 명확하면 필요한 파일과 테스트에 집중할 가능성이 높아집니다.

만약 이런 프롬프트를 만드는데 어려움이 있다면 ChatGPT에 이런 부분을 요청(특히 토큰을 아끼면서 작업한다는 목표까지 함께) 하는 것이 좋습니다.

7. “어떻게 할지”보다 “왜 하는지”를 알려주는 것이 중요합니다

AI에게 아주 자세한 절차를 지정하면 결과가 좋아질 것 같지만, 항상 그렇지는 않습니다.

OpenAI 내부 데이터 에이전트 개발팀도 비슷한 경험을 공개했습니다. 처음에는 실행 절차를 매우 구체적으로 지시했지만, 복잡한 상황에서는 정해진 절차가 오히려 모델을 잘못된 방향으로 밀어 넣는 문제가 있었다고 합니다.

그래서 원칙을 “Guide the Goal, Not the Path”, 즉 경로보다 목표를 알려주는 방식으로 바꿨다고 설명합니다.

예를 들어 이런 프롬프트가 있습니다.

1. A 파일을 읽어라.

2. B 함수를 확인하라.

3. C 파일을 수정하라.

4. D 테스트를 실행하라.

이 방식이 항상 나쁜 것은 아닙니다. 파일과 원인이 명확할 때는 오히려 좋습니다.

하지만 원인을 아직 모르는 문제라면 다음과 같은 요청이 더 나을 수 있습니다.

로그인 이후 관리자 화면이 느려지는 원인을 찾아 수정해줘.
목표는 기존 기능을 변경하지 않으면서 초기 로딩 시간을 줄이는 것이다.
필요한 파일과 실행 순서는 코드 구조를 확인한 뒤 판단해줘.
수정 후 어떤 근거로 문제가 해결됐다고 판단했는지 테스트 결과를 제시해줘.

이 방식의 핵심은 다음과 같습니다.

무엇을 달성해야 하는지는 명확하게 알려주고, 어떻게 달성할지는 모델이 코드 구조를 보고 판단하게 하는 것.

너무 세세한 절차를 지정하면 모델이 더 좋은 해결 경로를 발견해도 그 길로 가지 못할 수 있습니다. 반대로 목표와 제약을 명확히 주면 모델이 상황에 맞게 더 적절한 방법을 선택할 수 있습니다.

8. “검증해줘”보다 “근거를 보여줘”가 좋습니다

코드 작업에서 특히 추천하는 방식입니다.

처음에는 저도 많이 이렇게 요청했습니다.

전체 코드를 철저하게 검증해줘.

하지만 이 말은 범위가 너무 넓습니다.

AI 입장에서는 전체 저장소를 탐색하고, 여러 파일을 열고, 모든 가능성을 분석하려 할 수 있습니다. Codex 같은 에이전트에서는 이것이 곧 많은 tool call과 많은 컨텍스트로 이어질 수 있습니다.

대신 이렇게 요청하는 편이 좋습니다.

이번 변경사항이 요구사항을 충족하는지 확인해줘.
각 요구사항마다 다음 항목을 정리해줘.

• 구현된 파일/함수

• 코드 근거

• 실행한 테스트

• 테스트 결과

• 확인하지 못한 항목

이 방식의 장점은 AI가 단순히

“정상적으로 구현되었습니다.”

라고 말하는 것을 막아준다는 점입니다.

실제로 개발에서 중요한 것은 “잘 된 것 같다”가 아니라 무엇을 근거로 완료됐다고 판단할 수 있는가입니다.

Codex도 코드 변경 과정에서 터미널 로그, 테스트 결과, 변경 파일처럼 검증 가능한 증거를 남길 수 있습니다. 따라서 개발 프롬프트에서는

검증해줘

보다

완료됐다고 판단한 근거를 제시해줘

가 훨씬 유용합니다.

이렇게 요청하면 검토 범위도 명확해지고, 사람이 확인해야 할 지점도 훨씬 줄어듭니다.

9. 출력 결과부터 요구하면 토큰도 줄어듭니다

AI는 요청하지 않아도 설명을 길게 하는 경우가 많습니다.

특히 코딩 에이전트에서는 긴 설명 자체가 중요한 것이 아닐 때가 많습니다. 중요한 것은 무엇을 바꿨는지, 테스트는 통과했는지, 남은 문제는 무엇인지입니다.

그래서 저는 결과물 형식을 미리 정해두는 편입니다.

예를 들어 이렇게 요청합니다.

수정부터 수행해줘.
작업 완료 후에는 다음만 알려줘.

• 변경한 파일

• 핵심 변경사항

• 실행한 테스트

• 남은 문제
  설명은 간단하게 작성해줘.

이렇게 하면 AI가 작업을 시작하기 전에 긴 계획을 반복해서 출력하는 일을 줄일 수 있습니다.

API에서는 verbosity처럼 출력 길이를 조절하는 기능도 제공됩니다. 이는 추론의 깊이와 최종 답변의 길이가 별개의 문제라는 뜻입니다.

즉,

깊게 생각하되 짧게 대답하게 할 수 있습니다.

이 조합은 상당히 유용합니다.

복잡한 문제는 충분히 추론하게 하되, 최종 보고는 짧게 받는 것. 이것이 사용량을 줄이면서도 작업 품질을 유지하는 좋은 방식입니다.

10. “80%만 완벽하게”의 올바른 사용법

AI 작업을 하다 보면 작은 디테일까지 계속 수정하면서 사용량을 크게 소비할 수 있습니다.

버튼 그림자, 카드 간격, 애니메이션 속도, 문구의 미묘한 차이까지 계속 다듬다 보면 끝이 없습니다.

그래서 저는 때에 따라 완벽주의를 제한하는 조건을 넣습니다.

예를 들어 이렇게 요청합니다.

핵심 기능과 안정성은 반드시 충족하되, 시각적인 디테일이나 낮은 중요도의 개선사항은 80% 수준에서 종료해도 된다.

이 방식은 꽤 유용합니다.

다만 그냥

80% 정도만 만들어줘.

라고 하면 위험합니다.

보안, 데이터 저장, 권한, 결제, 개인정보, 핵심 기능까지 80%가 되어서는 안 되기 때문입니다.

그래서 저는 다음처럼 구분하는 것을 추천합니다.

기능 정확성·데이터·보안 = 100%
디자인 polishing·사소한 리팩터링 = 80%

즉 80% 규칙은 정확성을 포기하는 규칙이 아닙니다.

중요하지 않은 세부 개선에서 작업 종료 기준을 만드는 규칙입니다.

이 기준을 정해두면 AI도 어디까지 다듬고 멈춰야 하는지 판단하기 쉬워집니다. 사람도 불필요한 반복 수정을 줄일 수 있습니다.

11. 긴 채팅 하나를 몇 주 동안 계속 사용하는 것도 좋지 않습니다

토큰 절약에서 생각보다 중요한 부분이 대화 길이입니다.

Codex 구조를 설명하는 OpenAI 자료를 보면, 새로운 메시지를 보낼 때 이전 메시지와 tool call 등이 다시 컨텍스트에 포함될 수 있다고 설명합니다. 대화가 길어질수록 입력 역시 커질 수 있고, 일정 수준에서는 context compaction이 필요해집니다.

따라서 하나의 채팅에서 프로젝트의 모든 일을 계속하는 것이 항상 좋은 것은 아닙니다.

예를 들어 하나의 대화에서 다음 과정을 모두 진행한다고 해보겠습니다.

기획 → 개발 → 디자인 → 버그 수정 → 배포 → 다음 버전 개발

이 흐름을 몇 주 동안 하나의 채팅에서 계속하면, 예전에 필요했던 정보까지 계속 컨텍스트에 남게 됩니다.

물론 대화 맥락이 유지된다는 장점도 있습니다. 하지만 시간이 지나면 오래된 정보, 이미 해결된 문제, 더 이상 필요 없는 결정까지 함께 남게 됩니다. 이것이 오히려 모델의 판단을 흐리게 만들 수 있습니다.

저는 큰 단계가 끝나면 체크포인트를 만든 뒤 새 대화로 넘어가는 방식을 추천합니다.

예를 들어 ChatGPT에게 이렇게 요청하면 됩니다.

다음 대화에서 이 프로젝트를 계속할 수 있도록 현재 상태를 인수인계 문서 형태로 정리해줘.
완료된 기능, 현재 구조, 중요한 결정, 남은 문제, 절대 변경하면 안 되는 조건만 포함해줘.

그 요약본과 최신 코드만 새 대화에 넣으면 됩니다.

이렇게 하면 필요한 맥락은 유지하면서도 불필요한 과거 대화는 줄일 수 있습니다.

12. 이제는 Prompt Engineering보다 Context Engineering이 더 중요합니다

최근 AI 개발에서 많이 등장하는 개념이 Context Engineering입니다.

Andrej Karpathy가 2025년에 이 개념을 널리 알리면서 AI 개발자 사이에서 빠르게 퍼졌습니다.

핵심 아이디어는 단순합니다.

예전에는

“어떤 문장을 써야 AI가 말을 잘 들을까?”

가 중요했다면, 지금은

“AI가 지금 이 문제를 풀기 위해 정말 필요한 정보가 무엇인가?”

가 더 중요해졌다는 것입니다.

Anthropic도 컨텍스트를 유한한 자원으로 설명하면서, 원하는 결과를 얻는 데 필요한 가장 높은 신호의 정보만 제공하는 것이 중요하다고 설명합니다.

이 개념은 Codex에서 특히 중요합니다.

코드 10만 줄을 전부 읽히는 것보다,

현재 오류 로그 + 관련 파일 3개 + 요구사항

을 제공하는 것이 훨씬 효과적일 수 있습니다.

중요한 것은 많은 컨텍스트가 아닙니다.

많은 컨텍스트가 좋은 것이 아니라, 관련 있는 컨텍스트가 좋은 것입니다.

즉 Context Engineering은 단순히 프롬프트를 예쁘게 쓰는 기술이 아닙니다.

AI가 문제를 해결하는 데 필요한 정보만 적절한 시점에 제공하는 기술입니다.

13. Codex의 AGENTS.md도 길다고 좋은 것이 아닙니다

Codex를 많이 사용한다면 AGENTS.md를 만들게 됩니다.

이 파일에는 코딩 규칙, 프로젝트 구조, 테스트 명령어, 주의사항 등을 적어둘 수 있습니다.

문제는 욕심을 내다 보면 AGENTS.md가 점점 커진다는 것입니다. 처음에는 간단한 규칙 몇 줄이었는데, 나중에는 프로젝트의 모든 역사와 예외사항, 기능 설명이 다 들어가게 됩니다.

하지만 긴 AGENTS.md가 항상 좋은 것은 아닙니다.

OpenAI도 실제 Codex 기반 프로젝트를 만들면서 거대한 AGENTS.md 방식이 실패했다고 설명합니다.

이유는 명확합니다.

긴 지침 파일은 실제 작업, 코드, 관련 문서가 들어갈 컨텍스트 공간을 빼앗습니다. 또한 오래된 규칙이 계속 남아 있으면 모델이 현재 상황과 맞지 않는 지침을 따를 수도 있습니다.

그래서 OpenAI 내부에서는 AGENTS.md를 백과사전처럼 쓰기보다 약 100줄 정도의 ‘목차와 지도’ 역할로 사용하는 방식을 택했습니다. 자세한 지식은 별도 docs/ 폴더에 두고, AGENTS.md에서는 필요한 문서를 안내하는 방식입니다.

예를 들면 이런 구조입니다.

AGENTS.md
ARCHITECTURE.md

docs/
 ├─ product-specs/
 ├─ design/
 ├─ security/
 ├─ testing/
 └─ decisions/

AGENTS.md에는 모든 내용을 다 적는 대신 이렇게 안내합니다.

자세한 인증 규칙은 docs/security/auth.md를 참고한다.
테스트 실행 방법은 docs/testing/test-guide.md를 참고한다.
디자인 시스템은 docs/design/system.md를 참고한다.

이 방식의 장점은 명확합니다.

모델이 처음부터 모든 정보를 읽는 것이 아니라, 필요한 순간에 필요한 문서만 찾아 읽을 수 있습니다.

이것도 결국 Context Engineering입니다.

필요한 정보를 한꺼번에 밀어 넣는 것이 아니라, 필요한 정보를 찾을 수 있는 지도를 제공하는 것입니다.

14. Codex 프롬프트는 GitHub Issue처럼 작성합니다

OpenAI가 공개한 Codex 사용 가이드에서 상당히 실용적인 팁이 하나 있습니다.

Codex 프롬프트를 GitHub Issue처럼 작성하라는 것입니다.

예를 들어 이렇게 요청할 수 있습니다.

회원관리 이상해. 고쳐줘.

하지만 이 요청은 너무 모호합니다.

무엇이 이상한지, 어디서 문제가 발생하는지, 어떤 상태가 정상인지, 무엇을 건드리면 안 되는지 알 수 없습니다.

대신 다음처럼 작성하는 것이 좋습니다.

목표
관리자 페이지에서 승인 대기 회원이 정상적으로 표시되게 수정한다.

현재 문제
가입 신청은 저장되지만 /admin/approvals 목록에 나타나지 않는다.

관련 영역
- admin approvals
- signup request API
- user status mapping

성공 기준
1. 승인 대기 사용자가 목록에 표시된다.
2. 승인 후 일반 회원 목록으로 이동한다.
3. 기존 로그인 기능은 변경되지 않는다.
4. 관련 테스트를 실행한다.

제약
기존 데이터 구조는 삭제하거나 재생성하지 않는다.

작업 방법
원인은 저장소를 직접 조사해서 판단한다.

완료 후
변경 파일 / 원인 / 수정 내용 / 테스트 근거만 정리한다.

길어 보이지만, 이 프롬프트는 오히려 재작업을 줄입니다.

이유는 간단합니다.

Codex가 추측해야 할 부분이 줄어들기 때문입니다.

목표, 현재 문제, 관련 영역, 성공 기준, 제약 조건이 명확하면 모델은 불필요한 탐색을 줄이고 실제 문제 해결에 집중할 수 있습니다.

특히 중요한 것은 성공 기준입니다.

성공 기준이 있어야 Codex도 작업이 끝났는지 판단할 수 있고, 사람도 결과를 검토하기 쉬워집니다.

15. 작은 수정은 수정 범위를 좁힙니라

Codex에게 이런 요청을 많이 하게 됩니다.

전체 코드를 확인해서 이 문제를 수정해줘.

문제가 어디에 있는지 전혀 모를 때는 이런 요청이 필요할 수 있습니다.

하지만 오류 위치가 어느 정도 좁혀졌다면 굳이 전체 저장소를 다 뒤질 필요는 없습니다.

예를 들어 날짜가 하루씩 밀리는 문제가 캘린더 상세 팝업에서만 발생한다면 이렇게 요청하는 것이 좋습니다.

캘린더 상세 팝업에서 날짜가 하루씩 밀리는 문제만 수정해줘.
관련 날짜 변환 로직과 API 응답 부분을 우선 확인하고, 다른 기능은 리팩터링하지 마.

이 요청은 범위가 훨씬 명확합니다.

특히 수정 작업에서는 scope 제한이 매우 중요합니다.

새로운 기능을 만드는 단계에서는 넓게 탐색할 필요가 있습니다. 하지만 버그 수정 단계에서는 가능한 한 최소 변경을 기본값으로 두는 편이 좋습니다.

이렇게 하면 두 가지 장점이 있습니다.

첫째, Codex가 불필요한 파일을 덜 열게 됩니다.
둘째, 기존 기능을 건드리면서 생기는 회귀 오류를 줄일 수 있습니다.

수정 작업의 기본 원칙은 다음과 같습니다.

문제를 해결하는 데 필요한 만큼만 고친다.

이 원칙이 토큰과 버그를 동시에 줄여줍니다.

16. 에러가 났다면 전체 프로젝트 설명을 다시 하지 말아야 합니다

이미 문제가 좁혀졌다면 다음 요청에서 전체 요구사항을 다시 붙여넣을 필요가 없습니다.

예를 들어 빌드 오류가 발생했다면 필요한 정보는 보통 다음 정도입니다.

현재 상태
직전 수정까지 적용 완료.

문제
npm run build 실패.

오류
[실제 오류 로그]

요청
오류 원인을 확인해서 최소 변경으로 수정한다.
기존 구현 요구사항은 유지한다.
수정 후 build를 다시 실행하고 결과를 제시한다.

이 정도면 충분한 경우가 많습니다.

전체 프로젝트 설명, 처음 만들려고 했던 배경, 이미 해결된 문제까지 다시 붙여넣으면 오히려 컨텍스트가 불필요하게 커집니다.

에러 수정 단계에서 중요한 것은 현재 상태와 실제 오류 로그입니다.

특히 오류 로그는 요약하지 말고 가능한 한 그대로 제공하는 것이 좋습니다. 모델이 원인을 추론할 때 가장 직접적인 단서가 되기 때문입니다.

즉, 에러가 났을 때는 이렇게 생각하면 됩니다.

처음부터 다시 설명하지 말고, 지금 실패한 지점만 정확히 전달한다.

이것이 현재 작업에 필요한 컨텍스트만 제공하는 방식입니다.

17. 도구도 많다고 좋은 것이 아닙니다

AI 에이전트에게 많은 도구를 연결하면 더 똑똑해질 것 같지만, 의외로 반대 상황도 생깁니다.

OpenAI 내부 데이터 에이전트도 초기에는 모든 도구를 제공했다가 문제가 생겼다고 설명합니다. 비슷한 기능을 가진 도구들이 서로 겹치면서 모델이 어떤 도구를 써야 할지 혼란스러워졌기 때문입니다.

결국 도구를 정리하고 제한하자 안정성이 높아졌습니다. OpenAI는 이를 “Less is More”라는 교훈으로 정리했습니다.

Codex에서도 마찬가지입니다.

MCP, 플러그인, 검색 도구, 수십 개의 스킬을 전부 항상 노출하는 것이 반드시 좋은 것은 아닙니다.

도구가 많아지면 모델이 선택해야 할 것도 많아집니다. 각 도구의 설명, 사용 방법, 출력 결과도 컨텍스트에 포함될 수 있습니다. 결국 문제 해결과 직접 관련 없는 정보가 모델의 판단을 방해할 수 있습니다.

OpenAI의 최신 에이전트 하네스 역시 필요할 때만 도구와 기능을 발견하는 deferred discovery 등을 활용해 context bloat를 줄이고 있습니다.

즉, 도구도 프롬프트와 마찬가지입니다.

많을수록 좋은 것이 아니라, 필요한 도구가 적절히 제공되는 것이 좋습니다.

개발 작업에서도 마찬가지입니다.

지금 필요한 것이 코드 수정이라면 코드 저장소와 테스트 환경이 중요합니다.
지금 필요한 것이 자료 조사라면 검색 도구가 중요합니다.
지금 필요한 것이 디자인 검토라면 화면 캡처나 UI 자료가 중요합니다.

필요한 도구만 연결하는 것이 오히려 더 정확하고 효율적입니다.

18. API를 사용한다면 Prompt Caching도 알아두면 좋습니다

ChatGPT Plus에서 직접 설정하는 기능은 아니지만, OpenAI API로 서비스를 만든다면 Prompt Caching이라는 개념을 알아두면 좋습니다.

쉽게 말하면, 매번 반복되는 프롬프트 앞부분을 재사용해 비용과 응답 시간을 줄이는 기능입니다.

AI 서비스를 만들다 보면 매 요청마다 같은 내용이 반복될 수 있습니다.

- 시스템 지침
- 공통 규칙
- 도구 설명
- 답변 형식
- 예시

이런 내용은 자주 바뀌지 않습니다.
반대로 매번 달라지는 내용은 따로 있습니다.

- 현재 사용자 질문
- 현재 오류 로그
- 현재 데이터
- 이번에 처리할 작업

그래서 API를 사용할 때는 구조를 이렇게 잡는 것이 좋습니다.

앞부분: 변하지 않는 고정 지침
뒷부분: 매번 달라지는 사용자 요청

OpenAI는 앞부분이 동일하게 유지될수록 캐시가 잘 작동할 수 있다고 설명합니다.

즉 핵심은 간단합니다.

반복되는 내용은 앞에 고정하고, 매번 바뀌는 내용은 뒤에 붙인다.

다만 이것은 주로 API 개발자를 위한 최적화입니다.
ChatGPT Plus에서 대화할 때 사용자가 직접 켜고 끄는 기능은 아닙니다.

그래도 원리는 일반적인 ChatGPT·Codex 사용에도 도움이 됩니다.

프로젝트 규칙, 코딩 원칙, 공통 지침은 매번 새로 바꾸지 말고 안정적으로 유지하고,
이번 작업에 필요한 오류 로그나 요청사항만 뒤에 덧붙이면 더 효율적으로 작업할 수 있습니다.

19. 토큰을 아끼기 위해 하면 안 되는 것

토큰 절약을 잘못 이해하면 오히려 품질이 떨어질 수 있습니다.

가장 흔한 실수는 다음과 같습니다.

• 무조건 작은 모델만 사용하기
  → 재작업이 늘어날 수 있습니다.

• 모든 작업을 최저 reasoning으로 실행하기
  → 요구사항 누락이나 잘못된 판단이 생길 수 있습니다.

• 프롬프트를 무조건 한 줄로 줄이기
  → 필요한 정보가 부족해 다시 설명해야 할 수 있습니다.

• AGENTS.md에 모든 내용을 넣기
  → context bloat가 생길 수 있습니다.

• 하나의 채팅을 몇 달 동안 계속 사용하기
  → 불필요한 과거 컨텍스트가 계속 남을 수 있습니다.

• 매번 전체 프로젝트를 검증시키기
  → 불필요한 탐색과 tool call이 늘어날 수 있습니다.

반대로 좋은 절약은 이렇습니다.

필요한 곳에는 충분한 지능을 쓰되, 불필요한 일을 시키지 않는 것.

토큰을 아낀다는 것은 무조건 적게 쓰는 것이 아닙니다.

중요한 작업에는 제대로 쓰고, 단순한 작업에는 과하게 쓰지 않는 것입니다.

20. 제가 추천하는 현실적인 바이브 코딩 방식

제가 현재 가장 추천하는 흐름을 정리하면 다음과 같습니다.

① ChatGPT
목표 / 사용자 / 기능 / 데이터 구조 / 성공 기준 설계
→ Sol High 또는 Extra High

↓

② Codex
초기 구현
→ 복잡도에 따라 충분한 모델과 reasoning 사용
→ 정말 큰 병렬 작업에서만 Ultra 검토

↓

③ 실제 테스트
직접 실행해 문제 확인

↓

④ ChatGPT
완성 코드 또는 diff 검토
→ 문제와 영향 범위 정리

↓

⑤ ChatGPT
Codex용 수정 프롬프트 작성
→ 목표 / 근거 / 성공 기준 / 변경 범위 포함

↓

⑥ Codex
수정
→ 단순 수정은 낮은 reasoning 사용

↓

⑦ 근거 확인
파일 / diff / 테스트 결과 확인

↓

필요할 때만 반복

핵심은 처음부터 끝까지 최고 모델을 사용하는 것이 아닙니다.

작업 난이도가 내려가면 모델의 추론 수준도 같이 내려가는 것입니다.

처음에는 좋은 모델로 방향을 잡고, 구현이 어느 정도 진행된 뒤에는 작업 범위를 좁혀가며 효율적으로 수정합니다.

이 방식은 사용량을 줄이는 데도 도움이 되지만, 개발 품질을 유지하는 데도 도움이 됩니다. 매번 즉흥적으로 요청하는 것이 아니라, 계획과 검토를 분리하기 때문입니다.

바이브 코딩에서 가장 위험한 것은 “계속 수정하다 보면 언젠가 좋아지겠지”라는 방식입니다.

반대로 좋은 흐름은 다음과 같습니다.

계획을 세우고, 구현하고, 실제로 테스트하고, 근거를 확인한 뒤 필요한 만큼만 다시 수정하는 것.

이 흐름을 지키면 사용량과 시행착오를 함께 줄일 수 있습니다.

21. 토큰을 줄이는 프롬프트 템플릿

제가 실제로 추천하는 프롬프트 형태는 상당히 단순합니다.

[목표]
무엇을 만들어야 하는지

[이유]
왜 이 작업이 필요한지

[현재 문제]
현재 어떤 문제가 있는지

[성공 기준]
완료됐다고 판단할 조건

[제약]
변경하면 안 되는 것

[범위]
이번 작업에서 다룰 영역

[수행 방식]
구현 방법과 파일 선택은 저장소를 조사해서 판단한다.

[검증]
완료됐다고 판단한 코드 또는 테스트 근거를 제시한다.

[결과 출력]
변경 파일 / 핵심 변경 / 테스트 결과 / 남은 문제만 간단히 보고한다.

이 정도면 대부분의 개발 작업에서 충분합니다.

중요한 것은 형식 자체가 아닙니다.

핵심은 AI가 추측해야 하는 부분을 줄이는 것입니다.

목표가 명확하면 방향을 덜 헤맵니다.
이유가 있으면 판단 기준이 생깁니다.
성공 기준이 있으면 멈출 수 있습니다.
제약이 있으면 불필요한 변경을 줄일 수 있습니다.
검증 기준이 있으면 결과를 확인하기 쉬워집니다.

프롬프트를 잘 쓴다는 것은 멋진 문장을 쓰는 것이 아닙니다.

AI가 일을 끝내기 위해 필요한 조건을 분명히 전달하는 것입니다.

22. 결국 토큰 절약은 ‘프롬프트 줄이기’가 아니다

처음에는 저도 토큰을 아끼려면 프롬프트 자체를 짧게 만들어야 한다고 생각했습니다.

하지만 에이전트와 바이브 코딩을 많이 사용할수록 생각이 바뀌었습니다.

중요한 것은 텍스트의 절대 길이보다 정보 밀도입니다.

Andrej Karpathy가 널리 알린 Context Engineering 역시 같은 방향을 이야기합니다.

AI에게 모든 정보를 한꺼번에 주는 것이 아니라,

다음 행동을 결정하는 데 필요한 정보를 적절한 순간에 제공하는 것

이 핵심입니다.

결국 ChatGPT와 Codex의 사용량을 줄이는 가장 효과적인 방법은 세 가지로 압축됩니다.

첫째, 작업 난이도에 맞게 모델과 추론 수준을 조절합니다.

둘째, AI가 볼 필요가 없는 컨텍스트를 줄입니다.

셋째, 목표와 성공 기준을 명확히 해서 재작업을 줄입니다.

저는 이 세 번째가 가장 중요하다고 생각합니다.

한 번의 답변에서 사용량을 조금 줄이는 것보다, 잘못 만든 기능을 세 번 다시 만드는 일을 없애는 편이 훨씬 큰 절약이기 때문입니다.

AI를 싸게 사용하는 가장 좋은 방법은 가장 작은 모델만 사용하는 것이 아닙니다.

필요한 순간에 필요한 만큼만 제대로 생각하게 만드는 것.

ChatGPT와 Codex를 많이 사용할수록 결국 이 원칙으로 돌아오게 됩니다.

ChatGPT·Codex 토큰 절약 핵심 체크리스트

1. 기획·아키텍처·복잡한 문제에는 좋은 모델을 사용한다.

2. 단순 수정·반복 작업에서는 reasoning을 낮춘다.

3. Ultra는 모든 작업이 아니라 복잡한 병렬 작업에 사용한다.

4. 목표와 성공 기준을 먼저 적는다.

5. 구현 방법보다 왜 필요한지를 알려준다.

6. 절차를 지나치게 고정하지 말고 모델이 방법을 판단하게 한다.

7. “검증해줘”보다 코드·테스트 근거를 요구한다.

8. 결과물과 테스트 결과부터 출력하도록 한다.

9. 큰 단계가 끝나면 컨텍스트를 정리하고 새 작업으로 넘어간다.

10. AGENTS.md는 백과사전이 아니라 프로젝트의 지도처럼 만든다.

11. 수정할 때는 전체 저장소보다 관련 영역의 범위를 좁힌다.

12. 한 번의 토큰 비용보다 ‘정답까지 도달하는 총비용’을 생각한다.

참고한 주요 자료

OpenAI의 GPT-5.6 공식 발표에서는 Sol·Terra·Luna의 역할과 reasoning에 따른 성능·비용 전략을 확인할 수 있습니다.
GPT-5.6 공식 소개

ChatGPT에서 현재 제공되는 GPT-5.6 Sol의 Instant·Medium·High·Extra High 등의 추론 옵션은 OpenAI Help Center에 정리되어 있습니다.
GPT-5.6 in ChatGPT

OpenAI의 실제 Codex 활용법에는 GitHub Issue처럼 프롬프트 작성하기, AGENTS.md 활용, 개발환경 제공 등의 실무적인 권장사항이 담겨 있습니다.
How OpenAI uses Codex

긴 AGENTS.md 대신 짧은 지도와 구조화된 문서를 사용하는 방법은 OpenAI의 Harness Engineering 글에서 자세히 설명합니다.
Harness engineering: leveraging Codex in an agent-first world

Context Engineering에 대해서는 Anthropic의 에이전트 컨텍스트 관리 글도 참고할 만합니다.
Effective context engineering for AI agents