이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
Codex로 작은 수정 하나를 부탁했는데, 답보다 파일 목록과 로그가 길게 따라올 때가 있어요. GPT-6 Astra Codex를 쓸 때도 이 현상은 같습니다. 모델의 문맥 창이 크다고 해서 매번 큰 입력을 넣어도 되는 것은 아니에요. 원인을 찾아보면 대개 긴 대화, 겹치는 프로젝트 지시, 한꺼번에 쏟아낸 도구 출력 중 하나입니다.
먼저 구분해 둘 점이 있어요. 여기서 말하는 절약은 API 청구 금액을 계산하는 방법이 아니라, Codex가 한 작업에서 읽고 되짚는 문맥을 필요한 만큼으로 만드는 습관입니다. OpenAI 문서에서 GPT-6 Astra는 low부터 max까지 추론 강도를 지원하고, Codex 쪽은 모델·웹 검색·연동 기능을 설정 파일에서 조정할 수 있다고 안내합니다. GPT-6 Astra 모델 문서와 Codex config.toml 기본 문서를 먼저 펼쳐 두면 버전에 따라 달라진 항목을 확인하기 좋습니다.
GPT-6 Astra Codex에서 먼저 볼 세 가지
첫째는 대화의 길이입니다. 앞선 작업과 상관없는 디버그 대화까지 이어 가면, 다음 요청도 그 맥락 위에서 시작합니다. 일이 끝났다면 새 대화에서 파일과 완료 조건만 다시 주는 편이 더 낫습니다.
둘째는 지시문입니다. Codex는 작업을 시작하기 전에 AGENTS.md를 읽고, 상위 디렉터리의 지시를 현재 위치까지 합칩니다. 가까운 경로의 지시가 뒤에 붙어 우선하므로, 모든 팀 규칙을 한 파일에 반복할 이유가 없습니다. 이 동작과 기본 32KiB 제한은 AGENTS.md 공식 문서에서 확인할 수 있어요.
셋째는 도구 출력입니다. git diff, 테스트 로그, 검색 결과를 통째로 보여 주면 읽을 내용도 늘어납니다. 오류가 궁금하면 전체 로그 대신 오류 줄과 그 주변만 요청하세요. 파일을 찾을 때도 rg처럼 범위를 좁히는 명령이 편합니다.
rg -n "TypeError|ReferenceError" logs/test.log
sed -n '120,170p' src/payment.ts이렇게 받은 결과만으로 판단이 안 될 때에만 범위를 넓히면 됩니다. 처음부터 “관련 파일을 모두 읽고 전체 테스트 로그를 분석해 달라”고 하는 요청은 작은 수정에는 과합니다.
config.toml은 작업 성격별로 얇게 둬요
개인 기본값은 ~/.codex/config.toml에, 저장소에서만 필요한 값은 .codex/config.toml에 둘 수 있습니다. 프로젝트 설정은 신뢰한 프로젝트에서만 읽히고, 명령행 옵션이 프로젝트 설정보다 우선합니다. 그래서 매일 쓰는 기본값까지 저장소마다 복사하기보다, 달라지는 값만 프로젝트 설정으로 두는 편이 관리하기 쉽습니다.
예를 들어 평소에는 웹 자료가 필요 없고, 짧은 코드 작업이 많은 환경이라면 아래처럼 시작해 볼 수 있어요. 값의 지원 여부와 조직 정책은 설치한 Codex 버전의 설정 문서에서 다시 확인하세요.
model = "gpt-6-astra"
model_reasoning_effort = "medium"
web_search = "disabled"
tool_output_token_limit = 4000
[features]
apps = false
multi_agent = falsemodel_reasoning_effort는 매번 최고 강도로 생각하게 두지 않기 위한 기본값입니다. 단순 파일 수정에는 낮추고, 설계나 원인 추적처럼 어려운 일에서만 올려 보세요.web_search = "disabled"는 웹 근거가 필요 없는 내부 작업에만 어울립니다. 최신 라이브러리 문서나 오류 원인을 찾아야 하는 작업에서는 검색을 다시 켜야 해요.tool_output_token_limit는 도구 출력 하나를 대화 기록에 저장할 토큰 예산입니다. 4,000은 예시일 뿐이니, 로그 끝의 오류와 테스트 요약이 잘리지 않는지 확인하며 정하세요.apps = false와multi_agent = false는 그 기능을 쓰지 않는 개인 작업용 예시입니다. 연결 앱이나 병렬 작업이 필요한 날에는 기능을 끄는 대신 필요한 작업에서만 켜는 쪽이 낫습니다.
설정 하나가 토큰을 직접 잘라 주는 것은 아닙니다. 불필요한 검색·연동·병렬 작업이 시작되지 않게 하거나, 일상 작업에 과한 추론 강도를 피하게 해 주는 정도예요. 특히 출력 상한은 너무 낮으면 잘린 로그를 다시 읽느라 호출이 늘 수 있습니다. 기능을 꺼서 다시 요청하거나 중요한 근거를 놓쳐도 대화가 길어집니다.
AGENTS.md에는 반복할 규칙만 남겨요
AGENTS.md는 사람에게 읽기 좋은 프로젝트 소개서와 역할이 조금 다릅니다. Codex가 매 작업에 참고할 규칙이므로, 매번 바뀌는 배경 설명이나 긴 명령 출력까지 넣으면 계속 문맥으로 들어옵니다. 규칙은 짧게, 대상은 정확하게, 끝난 기준은 한 줄로 적어 두면 충분합니다.
# 결제 모듈 작업
- 수정 범위는 src/payments/와 그 테스트로 한정한다.
- 새 의존성은 추가하지 않는다.
- 변경 뒤 pnpm test --filter payments만 실행한다.
- 완료 보고에는 바꾼 파일과 테스트 결과만 적는다.반대로 “코드를 깨끗하게 고치고 필요한 테스트를 충분히 실행한다”처럼 넓은 문장은 해석할 여지가 큽니다. 어떤 파일을 읽을지, 어디까지 시험할지 스스로 넓혀 갈 수 있어요. 전역 규칙은 개인 환경에, 저장소 공통 규칙은 루트에, 특정 서비스 규칙은 그 디렉터리 가까이에 두세요. Codex의 지시 파일 탐색 순서를 이해하면 같은 문장을 여러 곳에 적지 않아도 됩니다.
요청도 한 번에 작게 끊어 보세요
큰 기능을 한 문장에 몰아넣기보다, 먼저 읽을 파일과 계획을 확인하고 다음 요청에서 구현을 맡기는 방식이 결과를 고치기 쉽습니다. 단, 아주 작은 수정까지 계획 단계로 나눌 필요는 없어요. 작업의 크기에 맞추면 됩니다.
- 작은 수정: “
src/auth/session.ts의 만료 시간 계산만 고치고 해당 테스트만 실행해 주세요.” - 조사: “이 오류가 나는 호출 경로를 찾되, 관련 파일 5개 안에서 설명해 주세요.”
- 큰 작업: “먼저 영향 파일과 계획만 제안해 주세요. 구현은 확인 뒤 진행합니다.”
완료 형식도 미리 정해 두면 불필요한 장문 보고가 줄어요. 예를 들어 “변경 파일, 이유, 실행한 테스트만 5줄 안에 정리”라고 하면 됩니다. 다만 실패 원인을 조사할 때까지 출력 길이를 억지로 줄이지는 마세요. 잘린 로그 때문에 같은 명령을 반복하면 절약한 만큼을 다시 쓰게 됩니다.
바꾸기 전후를 한 작업으로 비교해요
설정을 한꺼번에 여러 개 바꾸면 무엇이 도움이 됐는지 알기 어렵습니다. 자주 하는 작업 하나를 골라, 먼저 현재 방식으로 실행해 보고 다음에는 웹 검색 여부·추론 강도·요청 범위 중 하나만 바꿔 보세요. 걸린 시간, 다시 요청한 횟수, 결과를 고치는 데 든 대화 수를 적으면 감이 옵니다.
공식 모델 가이드는 GPT-6 Astra가 지시 파일에 더 민감할 수 있으므로 접근 가능한 AGENTS.md와 스킬을 점검하라고 권합니다. GPT-6 Astra 모델 가이드를 따라 긴 규칙부터 줄여 보기 좋은 이유입니다. 같은 주제를 다룬 Steady Study의 설정 점검 글도 큰 도구 출력과 외부 연결을 함께 살펴보는 출발점으로 참고할 만합니다.
이 블로그의 이전 글인 GPT-6 Astra 사용법, 복잡한 작업을 끝까지 맡기는 방법도 함께 보면, 토큰을 아끼려다 작업 범위를 지나치게 줄이지 않고 완료 조건을 정하는 데 도움이 됩니다. 결국 자주 쓰는 규칙은 짧게 남기고, 이번 일에만 필요한 자료는 그때만 주면 됩니다.