프런트엔드 개발자는 토큰을 낭비하고 있을까요? AI 코딩 비용을 줄이는 다섯 가지 방법

AI 요약

AI 에이전트를 하루 종일 켜 두면 토큰이나 크레딧 비용이 빠르게 늘어납니다. 글쓴이는 AWS Developer Advocate이며 AWS가 소유한 Kiro를 사례로 비용을 줄이는 다섯 가지 방법을 소개합니다. 앞서 Kiro 무료 요금제의 크레딧 사용량을 추적한 Laura Salinas의 글을 참고했다고 밝힙니다.

작업에 맞는 모델을 고릅니다

간단한 버그 수정이나 속성 이름 변경에 최신 고성능 모델을 쓸 필요는 없습니다. Kiro의 모델 선택 화면은 Auto를 1.0배로 둔 크레딧 배수를 표시합니다. 오픈 가중치 모델은 Qwen3 Coder Next 0.05배, MiniMax M2.1 0.15배, DeepSeek 3.2 0.25배이며, 프런티어 모델 Opus 5.5는 2.0배입니다. 문서의 예시에서는 Auto로 10크레딧이 드는 작업이 Opus 5.5에서는 20크레딧, Haiku 4.5에서는 4크레딧, Qwen3 Coder Next에서는 0.5크레딧입니다. 같은 작업도 모델에 따라 40배 차이가 납니다. 지원하는 모델이라면 추론 수준을 낮춰 응답 시간과 길이, 크레딧 사용량을 줄일 수도 있습니다. 배수는 새 모델이 나오면 바뀌며, 배수가 같아도 토큰 수와 추론 깊이에 따라 실제 사용량은 다를 수 있으니 모델 문서를 확인해야 합니다.

반복 지시를 steering 파일에 둡니다

Kiro는 .kiro/steering/에 둔 Markdown 파일을 지속적인 맥락으로 불러옵니다. 예를 들어 token-rules.md에 불필요한 파일을 만들지 말 것, 요청하지 않은 테스트를 만들지 말 것, 토큰 사용량을 아낄 것을 적으면 세션마다 같은 지시를 반복하지 않아도 됩니다. 파일 맨 앞에 포함 방식을 지정하는 front matter를 두며, inclusion: always는 모든 대화에 적용합니다. 항상 불러오는 파일은 매 요청에 함께 전달되므로 짧게 유지해야 합니다. 특정 파일을 다룰 때만 적용할 규칙은 inclusion: fileMatch와 fileMatchPattern으로 설정할 수 있습니다. manual은 대화에서 #파일 이름으로 불러오며, auto는 요청이 설명에 맞을 때 불러옵니다. 글쓴이가 인용한 Laura Salinas의 사례에서는 steering 파일 없이 작업해 필요하지 않은 검증 파일과 요약 Markdown 파일이 생겼고, 그만큼 크레딧도 들었습니다.

명세 작성에는 강한 모델, 구현에는 저렴한 모델을 씁니다

간단한 버그 수정이 아니라 설계가 필요한 기능이라면 spec-driven development를 활용합니다. Kiro의 명세 작업은 요구사항, 설계, 작업 목록 세 단계를 거치며 .kiro/specs/에 requirements.md, design.md, tasks.md를 만듭니다. 요구사항과 설계 단계에서 강한 모델로 충분히 고민한 뒤 명확한 작업 목록이 나오면 구현에는 더 저렴한 모델을 배정합니다. 작업을 하나씩 실행하면 첫 작업 결과를 확인한 뒤 나머지를 진행할 수도 있습니다. 모델 선택은 대화의 이후 메시지에 계속 적용되므로 작업 실행 전에 모델을 바꿔야 합니다.

서식과 린트는 결정론적 도구에 맡깁니다

Prettier와 eslint --fix는 같은 입력에 같은 결과를 내므로, 에이전트가 파일을 읽고 추론한 뒤 수정 내용을 작성하게 할 이유가 없습니다. package.json에 lint, lint:fix, format 스크립트를 두고 lint-staged로 커밋할 파일을 검사할 수 있습니다. Kiro의 Stop 훅에 npm run lint:fix && npm run format을 연결하면 에이전트 작업이 끝날 때 명령을 실행합니다. 셸 명령 액션은 크레딧을 쓰지 않지만, 새 에이전트 반복을 시작하는 프롬프트 액션은 크레딧을 사용합니다. 저장 시 실행하는 PostFileSave 훅이나 Husky와 lint-staged를 이용한 커밋 전 검사도 대안입니다. 글쓴이는 이런 자동화를 두면 스타일 수정을 에이전트에 맡기느라 토큰을 쓰지 않아도 된다고 설명합니다.

맥락 사용량을 살피고 작업마다 새 세션을 엽니다

대화가 길어지면 매번 이전 대화 기록도 모델에 다시 전달되므로 요청마다 실리는 맥락이 커집니다. MCP 서버는 도구 정의도 맥락을 차지합니다. Kiro Powers 문서는 MCP 서버 다섯 개를 연결하면 도구 정의가 100개를 넘고 토큰 5만 개 이상, 즉 컨텍스트 창의 약 40%를 첫 프롬프트 전에 차지할 수 있다고 설명합니다. 사용하지 않는 MCP 서버는 끄는 편이 좋습니다. 도구를 필요할 때만 불러오는 등 처리 방식은 도구 환경마다 다를 수 있습니다. 다른 작업으로 넘어갈 때는 새 세션을 시작합니다. Claude Code에서는 /clear 명령으로 새 세션을 열면서 이전 세션을 보존할 수 있으며, Kiro는 긴 세션을 자동으로 압축하기도 합니다.

dev.to 반응

• @erikch — 토큰을 낭비하고 있나요?
• @koda2026 — erik, 실용적인 내용을 아주 잘 정리했네요. 개발자들이 자주 놓치는 가장 큰 절약 방법은 4번, Prettier나 ESLint 같은 결정론적 도구가 맡을 일을 도구에 맡기는 것이라고 봅니다. 150달러짜리 휴대전화로만 개발하는 입장에서 Groq나 OpenRouter 같은 무료 요금제 API의 엄격한 한도에 크게 의존합니다. 간단한 작업에는 저렴한 오픈 가중치 모델을 쓰라는 1번 조언이 제가 버티는 방식과 딱 맞습니다. 복잡한 아키텍처 계획에만 프런티어 모델을 쓰고, 상용구나 간단한 리팩터링에는 가벼운 모델을 씁니다. 모바일 제약을 고려해 5번에 덧붙이자면, 컨텍스트 창을 비우는 건 토큰 절약만을 위한 일이 아닙니다. 저가형 Android 브라우저에서는 토큰 5만 개가 넘는 맥락을 담은 긴 대화 기록을 표시하다가 탭이 느려지거나 멈출 수도 있습니다. 새 세션을 시작하는 건 비용 절약을 넘어 하드웨어상 필요한 일입니다. 실행 가능한 전략을 군더더기 없이 공유해 주셔서 감사합니다! 🐯
• @botsailorofficial — AI 코딩에 집중하다 보면 비용을 쉽게 신경 쓰지 않게 되는데, 이 글이 좋았습니다. 가장 큰 교훈은 작업에 맞는 도구를 쓰라는 점인 것 같습니다. ESLint, Prettier, 간단한 스크립트가 바로 처리할 결정론적 작업을 LLM에 맡기지 말라는 조언이 특히 좋았습니다. 당연해 보여도 에이전트가 모든 일을 하게 두는 습관에 빠지기 쉽습니다. 컨텍스트 창에 관한 지적도 과소평가됩니다. 오래 이어지는 AI 세션은 편리해 보여도, 다음 작업에 도움이 되지 않는 과거 맥락을 계속 들고 다니는 셈입니다. 때로는 새 세션을 시작하는 편이 더 저렴하고 명확합니다. AI를 덜 쓰자는 이야기가 아니라 더 의도적으로 쓰자는 이야기라 좋습니다. 비싼 추론은 실제로 가치가 있는 작업에 쓰고, 지루하고 예측 가능한 일은 기존 도구에 맡기세요. 실용적으로 잘 정리했습니다.

원문: dev.to / 번역·요약: Trawling