600억 토큰을 쓰면서 Claude Code와 Codex 세션을 최적화한 방법들

728x90

올 한 해 600억 가까이 되는 토큰을 사용하면서, (많이 사용한 편은 아닌 것 같지만 ㅋㅋ) 내 사용 경험과 여러 레퍼런스들을 참고하여 작업 세션을 최적화 한 방법에 대해 조금 남겨놓으려고 한다. 핵심은 예나 지금이나 세션 단위의 PRD를 정확히 물려주고, 발산하는 영역들을 휴먼 루프를 최대한 덜 태우면서 어떻게 검증할지를 항상 고민했던 것 같다.

가장 좋은 모델을 오래 붙잡는 것보다, 작업을 나누고 필요한 컨텍스트만 남기고 마지막에 다시 검증하는 편이 더 빨랐다.

처음에는 가장 좋은 모델에게 최대한 많은 맥락을 주면 가장 좋은 결과가 나올 거라고 생각했다. 실제로도 초반에는 꽤 잘 통했다. 프로젝트 전체를 읽히고, 내가 알고 있는 제약을 길게 적고, 한 세션에서 구현부터 테스트와 리뷰까지 계속 이어갔다.

그런데 오래 사용할수록 이상한 장면이 반복됐다. 세션은 이미 앞선 실패와 긴 명령 출력으로 무거워졌고, 새 작업과 관계없는 판단까지 계속 따라왔다. 간단한 구현에도 가장 비싼 모델과 높은 추론 강도를 사용했다. 테스트가 통과했다는 답을 받았지만 실제 화면이나 배포 환경에서는 다른 문제가 남기도 했다.

결국 내가 최적화해야 했던 것은 토큰 하나만이 아니었다. 같은 시간과 사용량으로 얼마나 정확한 결정을 내리고, 실제로 검증된 결과까지 도달하느냐가 더 중요했다.

컨텍스트를 무조건 늘리거나 줄이는 게 아니라, 한 세션이 한 책임을 갖도록 작업 경계를 먼저 나눴다.

1. 최적화의 대상부터 다시 정의했다

예전에는 컨텍스트 사용량이 낮으면 잘 최적화한 것이라고 생각했다. 지금은 네 가지를 같이 본다.

결과가 실제 요구사항을 충족했는가
내가 기다린 시간은 얼마나 되는가
세션과 주간 사용량을 얼마나 소모했는가
마지막 결과를 사람이 검증할 수 있는가

토큰을 적게 썼는데 잘못된 코드를 만들면 다시 고쳐야 한다. 반대로 최고 성능 모델이 한 번에 정답을 내더라도, 기계적인 수정마다 같은 비용과 대기 시간을 쓰면 전체 작업량이 줄어든다. 그래서 모든 단계를 같은 모델과 같은 추론 강도로 처리하지 않게 됐다.

이 글에서 말하는 최적화는 모델을 덜 쓰는 방법이 아니다. 어려운 판단에는 충분히 쓰고, 반복 작업에는 과하게 쓰지 않고, 검증이 필요한 곳에는 다시 집중하는 방식에 가깝다.

2. 새 작업에는 새 컨텍스트를 쓴다

Claude Code를 처음 오래 사용했을 때 가장 먼저 체감한 문제는 긴 세션이었다. 대화뿐 아니라 읽은 파일, 도구 호출, 테스트와 빌드 출력도 다음 요청의 컨텍스트가 된다. 이전 작업에서 유효했던 정보가 다음 작업에서는 잡음이 될 수 있다.

지금도 기준은 단순하다.

완전히 다른 작업을 시작하면 새 세션 또는 /clear
같은 작업의 한 단계가 끝났고 핵심 맥락은 이어가야 하면 /compact
잘못된 접근 이후의 대화를 통째로 끌고 가기보다 분기 전으로 돌아갈 수 있으면 /rewind
별도 탐색이 주 작업의 맥락을 오염시킬 때만 서브에이전트

예전 글에서는 commit 단위로 compact하고 branch 단위로 clear한다고 표현했다. 지금도 꽤 쓸 만한 비유다. 다만 무조건 정해진 주기로 압축하지는 않는다. 현재 작업에 필요한 정보가 무엇인지, 압축 과정에서 잃어버리면 안 되는 결정이 무엇인지 먼저 본다.

컨텍스트가 크다는 사실 자체보다 관련 없는 정보가 섞여 있는 것이 더 문제였다. 새 작업이 시작됐는데 이전 장애 조사 로그와 실패한 테스트 출력이 계속 남아 있다면, 긴 기억이 장점이 아니라 편향이 된다.

3. AGENTS.md와 CLAUDE.md에는 매번 필요한 것만 남긴다

한때는 에이전트가 실수할 때마다 금지 규칙을 한 줄씩 추가했다. 당장은 안전해 보였지만, 어느 순간 모든 세션이 거대한 규칙집을 매번 읽고 시작했다. 서로 비슷한 규칙이 반복되고, 중요한 제약과 문체 선호가 같은 무게로 섞였다.

현재는 정보를 세 층으로 나눈다.

상시 규칙, 레포 규칙, 현재 작업 문서를 나눠 필요한 시점에 필요한 정보만 읽게 한다.

상시 규칙: 모든 작업에 필요한 짧고 안정적인 원칙
레포 규칙: 저장소 구조, 명령, 배포와 검증 계약
작업 문서: 현재 PLAN, skill, 증거와 판단

핵심은 자주 쓰는 정보를 모두 한 파일에 모으는 것이 아니라, 필요한 시점에 정확한 문서를 읽게 만드는 것이다. 코딩 스타일 한 줄 때문에 배포 절차 전체를 매 요청마다 넣을 필요는 없다. 반대로 데이터 마이그레이션처럼 실패 비용이 큰 작업에서는 짧은 프롬프트보다 명시적인 게이트와 검증 절차가 더 중요하다.

지시문도 코드와 비슷했다. 중복을 줄이고 책임을 나누고, 바뀌는 정보와 안정적인 정보를 분리해야 오래 유지할 수 있었다.

언제 규칙을 상시 파일에서 빼는가?

모든 작업에서 읽을 이유가 없거나, 특정 도구·배포·업무 단계에서만 필요한 절차라면 별도 문서나 skill로 옮긴다. 반대로 권한 경계나 파괴적 작업 금지처럼 매번 적용되는 규칙은 상시 파일에 남긴다.

4. 모델보다 먼저 작업 단계를 나눈다

Claude Code와 Codex를 번갈아 사용하면서 가장 크게 바뀐 부분은 모델 선택보다 phase를 먼저 구분한다는 점이다.

일상 구현은 균형형 설정에서 처리하고, 애매한 결정과 고위험 최종 게이트에 추론 예산을 집중한다.

지금 사용하는 GPT-5.6 계열에서는 복잡한 판단에는 sol, 일상적인 구현에는 terra, 기계적인 대량 작업에는 luna를 후보로 둔다. 하지만 이름 자체가 핵심은 아니다. 같은 모델이라도 추론 강도를 낮추는 것만으로 사용량과 지연이 크게 달라질 수 있다.

clarify   → sol / high
implement → terra / medium
review    → terra / medium 또는 sol / high

구현이 복잡한 멀티 파일 변경이거나 데이터·권한·배포 계약을 건드리면 implement도 강한 모델을 쓴다. 반대로 파일명 변경, 반복적인 테스트 보강, 명확한 UI 카피 수정에 최고 추론 강도를 사용하지 않는다.

중요한 점은 중간에 즉흥적으로 바꾸기보다 phase가 끝났을 때 다음 세션의 설정을 결정하는 것이다. 한 세션이 하나의 책임을 가지면 모델 선택의 이유도 분명해지고, 결과를 비교하기도 쉬워진다.

5. 출력이 많은 일은 본문 컨텍스트에서 격리한다

테스트, 빌드, 로그 검색은 필요하지만 출력이 많다. 성공 로그 수천 줄을 메인 세션에 그대로 남기면 이후 모든 판단에 그 무게가 따라온다.

테스트는 필요한 범위부터 실행한다.
가능하면 quiet 옵션이나 요약 출력을 사용한다.
실패했을 때만 필요한 앞뒤 로그를 넓힌다.
서로 독립적인 조사만 별도 컨텍스트로 보낸다.
서브에이전트의 최종 결과에는 결론과 근거 위치를 요구한다.

대량 출력을 없애는 것이 아니라, 필요할 때 실행하고 다음 판단에 필요한 증거만 메인 컨텍스트로 되돌린다.

여기서 병렬화는 무조건 빠르게 만드는 버튼이 아니었다. 같은 파일을 여러 에이전트가 만지거나, 앞선 결정이 다음 작업의 입력인 경우에는 오히려 합치는 비용이 커졌다. 독립적으로 끝낼 수 있고 결과 형태가 명확할 때만 병렬화가 이득이었다.

6. 조사, 구현, 검증, 리뷰를 섞지 않는다

AI가 코드를 빨리 만드는 것과 그 코드가 실제로 동작하는 것은 다른 문제다. 이 차이는 사용할수록 더 크게 느꼈다.

조사는 원인을 찾는 단계다. 구현은 변경을 만드는 단계다. 검증은 테스트와 빌드, 실제 화면, 런타임 증거로 요구사항을 확인하는 단계다. 리뷰는 구현자가 놓친 결함을 다시 찾는 단계다.

리뷰에서 가정이 깨지면 구현을 덧대기 전에 조사로 돌아간다. 완료는 답변의 자신감이 아니라 검증 증거로 결정한다.

이 네 단계를 한 프롬프트에서 모두 시키면 마지막 답변은 대체로 낙관적으로 수렴했다. 자신이 방금 만든 변경을 자신이 바로 리뷰하면 맥락을 잘 아는 대신 같은 가정을 공유한다. 그래서 중요한 변경에서는 새 컨텍스트로 diff와 요구사항만 주고 다시 보게 한다.

테스트가 초록색이어도 완료라고 말하지 않는 것도 같은 이유다. 테스트하지 않은 것은 통과가 아니라 미검증이다. 브라우저를 열지 못했으면 시각 검증은 하지 않은 것이고, 배포하지 않았으면 운영 반영은 되지 않은 것이다.

속도를 위해 AI를 쓰면서도 마지막 책임은 줄어들지 않았다. 오히려 구현의 허들이 낮아진 만큼 무엇을 확인하지 않았는지를 정확히 말하는 일이 더 중요해졌다.

7. 느낌 대신 사용량과 결과를 같이 본다

Claude Code를 많이 쓰기 시작하면서 JSONL 파일이 수 GB까지 쌓였고, 기존 사용량 도구가 느려져 직접 toktrack을 만들었다. 처음에는 비용과 토큰을 보기 위한 도구였지만, 지금은 작업 방식을 비교하는 계기이기도 하다.

단순히 토큰이 적은 세션을 좋은 세션이라고 보지는 않는다. 비슷한 난이도의 작업에서 다음을 같이 본다.

완료까지 걸린 시간
구현과 수정에 사용한 턴 수
다시 열린 결함 수
검증 단계에서 발견한 누락
최종 입력과 출력 사용량

모델과 추론 강도도 대표 작업으로 비교해야 했다. 공식 문서의 추천값은 출발점이고, 실제 레포의 테스트 구조와 요구사항 밀도에 따라 결과가 달랐다. 가장 높은 설정을 기본값으로 두고 참는 것보다, 평소에는 중간값을 쓰고 품질 차이가 측정되는 단계에서만 올리는 편이 지속 가능했다.

8. 지금 사용하는 기본 흐름

현재의 기본 흐름을 짧게 적으면 다음과 같다.

작업 크기와 실패 비용에 맞춰 단계를 합치거나 깊이를 조절하되, 검증 경계만은 흐리지 않는다.

범위 고정: 요구사항, 성공 조건, 비범위를 먼저 적는다.
설정 선택: 다음 phase의 모델과 추론 강도를 고른다.
구현: 계획과 필요한 파일만 전달한다.
출력 축약: 테스트와 빌드는 필요한 범위부터 실행한다.
실제 검증: 확인한 것과 확인하지 못한 것을 나눈다.
독립 리뷰: 위험한 변경은 새 컨텍스트에서 다시 본다.
컨텍스트 종료: 다음 작업에 불필요한 맥락을 넘기지 않는다.

이 흐름이 항상 가장 빠른 것은 아니다. 한 줄 수정에 phase를 세 개 만들면 오히려 낭비다. 반대로 데이터 마이그레이션이나 권한 로직을 한 세션에서 바로 구현하고 스스로 승인하는 것은 빠른 것처럼 보여도 실패 비용이 크다.

결국 작업 크기와 실패 비용에 맞게 깊이를 조절하는 것이 핵심이었다.

실패했던 방식들

하나의 긴 세션에서 관련 없는 작업까지 계속 이어가기
실수할 때마다 AGENTS.md와 CLAUDE.md에 금지 규칙 추가하기
모든 구현을 최고 모델과 최고 추론 강도로 실행하기
독립적이지 않은 작업까지 병렬 에이전트에 맡기기
테스트 성공을 실제 기능과 배포 성공으로 확대 해석하기
에이전트가 만든 요약만 보고 원본 diff와 런타임 증거를 생략하기

완전히 버린 방식도 있고, 특정 상황에서는 여전히 쓰는 방식도 있다. 긴 세션이 항상 나쁜 것도 아니고, 강한 모델이 아까워서 쓰지 말아야 하는 것도 아니다. 문제는 선택의 이유가 없는 기본값이었다.

모델 이름보다 오래 남는 것

처음 Claude Code를 사용할 때는 컨텍스트를 얼마나 많이 넣을 수 있는지가 중요해 보였다. 이후에는 어떻게 줄일지가 중요해졌다. 지금은 무엇을 남기고, 어떤 단계에 어떤 모델을 쓰고, 어디서 다시 검증할지를 더 많이 고민한다.

AI 코딩 도구가 좋아질수록 프롬프트 요령은 금방 낡을 수 있다. 모델 이름과 명령어도 계속 바뀐다. 그래도 작업을 작게 정의하고, 관련 있는 컨텍스트만 전달하고, 결과를 독립적으로 검증하는 원칙은 비교적 오래 남을 것 같다.

정답이라고 생각하지는 않는다. 다만 Claude Code와 Codex를 꽤 많이 사용하면서, 지금까지는 이 방식이 가장 덜 지치고 가장 많은 결과를 실제 완료 상태까지 가져다줬다.

참고 자료