시니어 엔지니어들이 토큰 제한에 걸리지 않고 AI를 사용하는 방법 - AI 토큰 사용량을 60~90% 절감하기
요약
AI 보조 개발 시 발생하는 토큰 낭비를 줄이고 효율성을 극대화하는 전략을 소개합니다. 불필요한 터미널 로그를 필터링하는 RTK와 파일 컨텍스트를 압축하는 Lean-CTX를 통해 토큰 사용량을 60~90% 절감할 수 있습니다.
핵심 포인트
- 불필요한 컨텍스트 제공이 토큰 낭비의 주원인
- RTK를 활용해 터미널 로그의 노이즈 제거
- Lean-CTX로 소스 코드 파일의 컨텍스트 압축
- 효율적인 컨텍스트 관리가 비용 절감과 추론 속도 향상으로 직결
지난달 저는 한 개발자가 일주일도 채 되지 않아 Claude 사용 제한을 다 써버리는 것을 목격했습니다.
그들은 거대한 애플리케이션을 생성하고 있었던 것도 아니었습니다.
복잡한 AI 시스템을 구축하고 있었던 것도 아니었습니다.
그들은 그저 AI에게 동일한 저장소(Repository)를 반복해서 스캔하고, 동일한 파일을 읽고, 동일한 아키텍처를 계속해서 설명해 달라고 요청하고 있었을 뿐입니다.
익숙한 상황인가요?
AI 보조 개발(AI-assisted development)이 주류가 되면서, 많은 팀이 새로운 엔지니어링 과제를 발견하고 있습니다:
토큰 효율성 (Token efficiency).
숙련된 엔지니어들이 클라우드 비용을 최적화하는 법을 배웠듯이, 시니어 엔지니어들은 이제 AI 컨텍스트 (Context)를 최적화하는 법을 배우고 있습니다.
며칠마다 토큰이 바닥나는 개발자와 한 달 내내 여유롭게 작업하는 개발자의 차이는 종종 AI 모델의 차이가 아닙니다.
그것은 바로 컨텍스트를 어떻게 관리하느냐의 차이입니다.
여기 제가 지속적으로 효과가 있다고 확인한 툴킷과 워크플로우가 있습니다.
바이브 코딩 (Vibe Coding)의 숨겨진 비용
다음과 같이 질문한다고 가정해 봅시다:
PaymentService.ts의 버그를 수정해줘
여러분의 AI 어시스턴트는 다음과 같이 진행합니다:
- 전체 저장소(Repository) 스캔
- 인프라 코드 읽기
- 프론트엔드 폴더 탐색
- 문서(Documentation) 탐색
- 이전 대화 내용 로드
- 관련 없는 의존성(Dependencies) 조사
당신은 파일 하나에 대해 물었습니다.
하지만 모델은 수백 개의 파일로부터 컨텍스트를 소비했습니다.
그곳에서 여러분의 토큰이 사라집니다.
목표는 지능을 낮추는 것이 아닙니다.
목표는 불필요한 컨텍스트를 줄이는 것입니다.
1. RTK: 쓸모없는 명령 출력에 비용을 지불하는 것을 멈추기
가장 큰 숨겨진 토큰 낭비 요소 중 하나는 터미널 출력입니다.
많은 AI 코딩 에이전트들이 자동으로 다음과 같은 것들을 소비합니다:
- npm install 로그
- 빌드 결과물 (Build outputs)
- 테스트 결과 (Test results)
- 배포 로그 (Deployment logs)
- 의존성 해결 메시지 (Dependency resolution messages)
이 정보의 대부분은 무관합니다.
RTK와 같은 도구들이 이 문제를 해결합니다.
RTK가 하는 일
RTK는 개발 환경과 LLM 사이에서 프록시 레이어 (Proxy layer) 역할을 합니다.
모든 것을 전달하는 대신:
npm install
RTK는 다음과 같은 것들을 필터링합니다:
- 중복된 메시지
- 반복되는 경고
- 진행 표시기 (Progress indicators)
- 노이즈 (Noise)
이것들이 모델에 도달하기 전에 말입니다.
이점
보고된 절감 수치는 다음과 같습니다:
- 일반적인 개발 워크플로우에서 토큰 소비량 60–90% 절감
- 더 빠른 에이전트 추론 (Agent reasoning)
- 더 깔끔한 컨텍스트 윈도우 (Context windows)
원리는 간단합니다:
사람이 읽지 않을 내용이라면, 모델도 읽을 필요가 없습니다.
2. Lean-CTX: 모델에 도달하기 전 컨텍스트 압축하기
대부분의 개발자는 프롬프트 (Prompt)를 최적화합니다.
하지만 파일을 최적화하는 사람은 거의 없습니다.
대규모 소스 파일에는 종종 다음과 같은 내용이 포함되어 있습니다:
- 생성된 코드 (Generated code)
- 주석 (Comments)
- 반복적인 구조 (Repetitive structures)
- 보일러플레이트 (Boilerplate)
Lean-CTX는 파일 내용이 모델로 전송되기 전에 동적으로 압축하고 최적화합니다.
이것이 중요한 이유
다음과 같이 보내는 대신:
4,000줄짜리 파일
이렇게 보낼 수 있습니다:
관련 함수 (Relevant functions)
의존성 (Dependencies)
심볼 (Symbols)
...
AI는 훨씬 적은 토큰을 소비하면서도 필요한 정보를 전달받게 됩니다.
이를 다음과 같이 생각하십시오:
AI 컨텍스트를 위한 gzip.
3. AI Codex 및 리포지토리 인덱서 (Repository Indexers)
AI 코딩에서 가장 비용이 많이 드는 활동 중 하나는 다음과 같습니다:
"내 코드베이스를 탐색해줘."
모델은 다음을 이해하려고 시도하며 수십 개의 파일을 읽기 시작합니다:
- 라우트 (Routes)
- API
- 스키마 (Schemas)
- 서비스 (Services)
- 컴포넌트 (Components)
이 탐색 단계는 수만 개의 토큰을 쉽게 소모할 수 있습니다.
리포지토리 인덱싱 (Repository indexing) 도구들이 이 문제를 해결합니다.
생성되는 결과물
모든 것을 스캔하는 대신, 다음을 생성합니다:
ROUTES.md
DATABASE_SCHEMA.md
COMPONENTS.md
...
이제 AI는 500개의 소스 파일 대신 5개의 작은 파일만으로 시스템을 이해할 수 있습니다.
전형적인 절감 효과
많은 팀이 초기 코드베이스 탐색 과정에서 다음과 같은 비용을 피했다고 보고합니다:
- 30k–50k 토큰
이는 여러분이 수행할 수 있는 가장 높은 ROI (투자 대비 효율) 개선 사항 중 하나입니다.
원시인 규칙 (The Caveman Rule): 내가 가장 좋아하는 토큰 해킹
말도 안 되게 들릴 것입니다.
하지만 효과가 있습니다.
코드가 필요할 때, 에세이가 필요한 것은 아닙니다.
다음과 같은 내용은 필요 없습니다:
물론입니다! 여기 자세한 설명이 있습니다...
여러분에게 필요한 것은 다음과 같습니다:
여기에 버그 있음.
이것을 수정할 것.
테스트 실행.
...
원시인 규칙은 AI에게 다음과 같이 지시합니다:
- 대화형 미사여구 (Conversational filler) 건너뛰기
- 긴 요약 피하기
- 최소한의 단어로 소통하기
예시:
대신에:
I've identified several possible root causes...
결과물:
Null value here.
Add guard clause.
Problem solved.
기술적 정확도는 유지됩니다.
장황함은 사라집니다.
많은 개발자들이 출력 토큰 (output tokens)이 75%에 육박할 정도로 감소했다고 보고합니다.
프로젝트 브레인 (Project Brain) 생성하기
제가 목격한 가장 큰 실수 중 하나는 다음과 같습니다:
개발자들이 자신의 프로젝트를 반복해서 설명하는 것입니다.
모든 새로운 세션(session)은 다음과 같이 시작됩니다:
우리는 다음을 사용합니다:
- Node.js
- PostgreSQL
...
또다시.
또다시.
또다시.
대신에 다음과 같이 만드세요:
CLAUDE.md
AGENTS.md
PROJECT_CONTEXT.md
...
다음 내용을 저장하세요:
- 아키텍처 (architecture)
- 컨벤션 (conventions)
- 코딩 표준 (coding standards)
- 배포 패턴 (deployment patterns)
- 저장소 구조 (repository structure)
이제 모든 세션은 공유된 이해를 바탕으로 시작됩니다.
AI는 학습하는 데 시간을 덜 소비합니다.
당신은 가르치는 데 토큰을 덜 소비합니다.
파편화된 코드 접근 방식 (The Fragmented Code Approach)
또 다른 비용이 많이 드는 습관은 다음과 같습니다:
파일 전체를 다시 작성해줘.
그러면 AI는 다음과 같이 응답합니다:
2,000줄
당신은 그 모든 것에 대해 비용을 지불합니다.
대신 다음과 같이 요청하세요:
120~150번 라인만 수정해줘.
패치(patch)만 반환해줘.
요약은 생략해.
이점:
- 더 적은 출력 토큰 (output tokens)
- 더 작은 미래 컨텍스트 (future context)
- 더 쉬운 리뷰
- 더 낮은 비용
최고의 AI 엔지니어들은 점점 더 전체 재작성(rewrites)이 아닌 패치(patches) 단위로 생각합니다.
대부분의 개발자가 무시하는 IDE 기본 기능
많은 현대적인 AI IDE들은 이미 토큰 최적화 기능을 제공하고 있습니다.
하지만 대부분의 사람들은 이를 전혀 사용하지 않습니다.
비용 상한선 (Cost Caps)
다음 항목을 설정하세요:
- 최대 도구 호출 (maximum tool calls)
- 세션 예산 (session budgets)
- 사용 제한 (usage limits)
토큰을 클라우드 비용(cloud spend)처럼 취급하세요.
실제로 그러하기 때문입니다.
컴팩트 세션 (Compact Sessions)
Claude 및 기타 도구들은 컨텍스트 압축 (context compaction)을 지원합니다.
예시:
/compact
이 기능은 다음을 제거합니다:
- 중복된 대화 기록 (redundant conversation history)
- 더 이상 유효하지 않은 결정 (obsolete decisions)
- 해결된 이슈 (resolved issues)
동시에 중요한 컨텍스트는 보존합니다.
이렇게 생각하세요:
대화를 위한 가비지 컬렉션 (garbage collection for conversations).
새로운 세션, 새로운 문제
가장 쉽게 얻을 수 있는 성과 중 하나는 다음과 같습니다:
새롭게 시작하기.
다음과 같은 경우에:
- 기능 구현이 완료되었을 때
- 버그가 해결되었을 때
- 도메인(domain)을 전환할 때
새로운 세션을 만드세요.
오래된 대화는 짐이 됩니다.
모델은 계속해서 다시 읽게 됩니다:
- 실수 (mistakes)
- 포기한 접근 방식 (abandoned approaches)
- 무관한 문맥 (irrelevant context)
신선한 문맥 (Fresh context)은 종종 더 나은 결과를 만들어냅니다.
나의 개인적인 문맥 엔지니어링 (Context Engineering) 체크리스트
AI에게 무엇인가를 묻기 전에:
저장소 (Repository)
제외할 항목:
node_modules/
dist/
coverage/
...
문맥 (Context)
유지할 항목:
CLAUDE.md
AGENTS.md
ARCHITECTURE.md
...
도구 (Tooling)
사용할 도구:
- RTK
- Lean-CTX
- AI Codex
- 저장소 인덱서 (Repository Indexers)
- 시맨틱 검색 (Semantic Search)
- 코드 그래프 (Code Graphs)
프롬프팅 (Prompting)
다음 대신에:
모든 것을 설명해줘. (Explain everything.)
이것을 선호하세요:
패치만 적용해줘. (Patch only.)
요약은 하지 마. (No summary.)
세션 (Sessions)
- 정기적으로 압축하기 (Compact regularly)
- 자주 새로 시작하기 (Start fresh often)
- 문맥을 작게 유지하기 (Keep contexts small)
마치며
수년 동안 우리는 다음을 최적화해 왔습니다:
- 클라우드 비용 (cloud costs)
- 컴퓨팅 비용 (compute costs)
- 스토리지 비용 (storage costs)
- 네트워크 비용 (network costs)
이제 우리는 다음을 최적화해야 합니다:
- 문맥 비용 (context costs)
차세대 고성능 AI 엔지니어는 가장 큰 문맥 창 (context windows)을 가진 사람들이 아닐 것입니다.
그들은 어떤 문맥을 보내야 할지 정확히 아는 사람들이 될 것입니다.
프롬프트 엔지니어링 (Prompt engineering)이 우리가 AI와 대화하는 것을 도왔다면,
문맥 엔지니어링 (Context engineering)은 우리가 AI를 확장(scale)하는 것을 돕습니다.
그리고 바이브 코딩 (vibe coding)의 시대에, 문맥은 새로운 컴퓨팅 자원 (compute)입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기