“비용은 보이는데 원인이 보이지 않는 상태에서는 어디부터 줄여야 할지 결정할 수 없었습니다.”

이제는 많이들 서비스에 LLM 붙이는 일이 많을 텐데, 최근에 비용 이슈에 대한 소식들을 자주 접하게 돼. 29CM 팀에서도 AWS Bedrock을 쓰다가 눈덩이처럼 불어나는 요금을 보고 깜짝 놀랐다네? 그런데 진짜 무서운 건 비용은 엄청난데 대체 어떤 API가 돈을 잡아먹는지 그 원인이 안 보였다는 거야. 완전 막막한 상황인 거지.

그래서 가장 먼저 한 일은 API별 토큰 사용량을 추적하는 메트릭 대시보드부터 만들었데. 가시성을 확보하고 나니 뙇! 범인이 보였는데, 변동되는 상품 데이터는 2K 토큰밖에 안 되는데, 무려 15K나 되는 똑같은 시스템 프롬프트를 매 호출마다 처음부터 다시 보내고 있었다는 거야! 이걸 해결하려고 AI에게 비용 시뮬레이션을 맡겨서 ‘프롬프트 캐싱’이라는 최적의 답을 찾아냈다고 해. 그리고 AI가 그럴듯하게 숫자를 지어내는 할루시네이션을 막기 위해 사칙연산 같은 최종 계산은 무조건 결정론적인 코드에 맡겼다는 점에 주목할 필요가 있어.

물론 단순히 캐시 기능만 켠다고 문제가 다 해결 되는 건 아니라고 생각해. 캐싱이 제대로 작동하게 만드는 팁도 유용하게 설명되어 있고, 무심코 타임스탬프나 유저 ID 같은 동적 변수를 시스템 프롬프트에 넣었다가는 매초 해시가 달라져서 캐시가 깨져버리는 흔한 안티패턴도 짚어주고 있어서 실무에 참고하기 좋을 거 같아.

요즘처럼 AI 도입은 필수인데 눈먼 인프라 비용 때문에 머리 아픈 개발 환경에서, 가시성 확보부터 프롬프트 구조 분리까지 다룬 내용이라, 비용 최적화를 고민하는 이들에게 도움이 될 거라고 봐.

LLM 비용 64% 절감, 캐시 히트율 98% 달성기

■ IT 스냅샷: 이달의 화두는?‍

• [#하네스] 하네스 엔지니어링에 대한 세 가지 오해
  “프레임워크를 바꾸면 코드는 다시 써야 합니다. 하지만 잘 설계된 하네스는 프레임워크를 갈아엎어도 대부분 그대로 옮겨집니다. 설계는 재료보다 오래갑니다.”
• [#Java Flight Recorder] 범인은 내부에 있었다: JFR로 잡은 12분짜리 젠킨스 장애 추적기
  “정황 증거가 너무 깔끔했습니다. 그대로 PR을 올렸어도 아무도 의심하지 않았을 정도로 그럴듯했죠.” 로그만 믿고 엉뚱한 PR 올릴 뻔한 아찔한 순간, 확증 편향은 개발자를 어떻게 속이는가…
• [#AI소음] AI 답변 복붙이 우리 팀을 피곤하게 만드는 이유
  “이 서비스에는 Redis가 맞을까요, Memcached가 맞을까요? 라고 물으면 5초 뒤, 소제목과 트레이드오프, 각종 주의사항, 그리고 지나치게 균형만 잡느라 정작 결론을 내리지 못한 결론까지 붙은 번듯한 에세이가 올라왔죠.” 우리가 원한 건 영혼이 없는 장문의 에세이가 아니라, 단호한 결정이었던 건에 관하여.
• [#코드 리뷰 합의] AI 코드 리뷰, 3번 갈아엎고 배운 것
  “리뷰 봇 하나를 붙이는 PR에 커밋이 148개 쌓였습니다. 공들인 시스템이었지만, 도입 20일 만에 걷어내게 됩니다.” 오버엔지니어링과 대규모 롤백의 경험…148개 커밋 삭제할 때 쾌감 vs 허탈감, 당신의 선택은?
• [#판단력] AI 잘 쓰는 신입 옆에서, 마흔의 나는 무엇을 배워야 할까?
  “이제 차이는 AI를 쓰느냐 마느냐가 아니라 AI가 만든 초안을 그대로 받아들이는 사람과, 자신의 경험으로 다시 다듬는 사람 사이에서 벌어집니다.” AI 코드를 무지성 복붙만 하다간 무슨 일이 벌어질지 모르는 시절. 코드를 통제하고 검증하는 ‘설계’ 능력이 핵심!
• [#에이전트] 딸깍의 신화: AI시대 1인 유니콘이라는 신기루
  “유니콘의 83%는 팀이었고 평균 공동창업자는 3명이었으며, 대규모 자본의 83%는 여전히 팀에게 흘러가고, 생성형 AI 파일럿의 95%는 프로세스를 바꾸지 못해 손익에 닿지 못했으며, 최초의 1인 유니콘이라던 사례는 매출과 가치를 혼동한 2인 회사였고 신뢰가 무너지는 지점에서 금이 갔다.”
• [#토큰비용] 클로드, 코덱스 매번 토큰 확인하기 귀찮아서 만든 메뉴바
  “매번 사용량 확인하러 들어가는 게 귀찮아서, 그냥 맥 메뉴바에 붙여버렸습니다.” 5초를 아끼기 위한 5시간의 코딩! 귀찮음을 사이드 프로젝트로 승화시킨 참된 개발자의 본능. 더불어 실시간 모니터링과 맥북 이륙(발열) 사이의 딜레마까지. 무한 새로고침을 막기 위한 최적화의 현실. 그 결과는요.
• [#기술부채] 되도록 최신 버전을 사용하는게 왜 이렇게 어려울까?
  “진짜 고통은 ‘어느 버전 써요?’라는 질문이 반복되는 게 아닙니다. 어느 버전이 ‘지금 써도 되는’ 버전인지 답해줄 권위 있는 출처가 어디에도 없다는 것입니다.” 이거 머지해도 되요? 의존성 지옥의 뼈아픈 핵심을 찌르는 경험.

■ 독자탐구생활‍

• 
  <에이전트 시대의 AI 시스템 설계> by donghoon-song 님
  생성형 AI를 실제 서비스로 운영할 때 생기는 문제를 패턴 단위로 다루는 책에 가깝다. 그래서 처음부터 끝까지 순서대로 읽는 것도 가능하지만, 지금 만들고 있는 AI 기능에서 막히는 지점을 기준으로 필요한 패턴을 찾아 읽는 방식도 잘 맞아 보였다. 내가 AI 실습 문제 생성 기능을 만들면서 겪었던 문제도 결국 같은 방향이었다. 좋은 결과가 나오지 않을 때마다 프롬프트를 고치고 규칙을 추가했지만, 더 근본적으로는 맥락 공급, 금지 규칙, 품질 평가, 검증 루프가 필요했다. 이 책을 읽으면서 그 경험을 RAG, 신뢰성 개선, 가드레일, 성능 저하 테스트 같은 패턴으로 다시 정리할 수 있었다. AI 기능을 빠르게 만드는 단계에서는 프롬프트와 데모가 중요하다. 하지만 오래 버티는 AI 시스템을 만들려면 그 뒤의 설계가 필요하다. 특히 AI로 무언가를 생성하는 제품을 만들고 있고, ‘결과는 나오는데 품질이 안정적이지 않다’는 고민을 해본 사람이라면 이 책에서 연결해볼 지점이 많을 것 같다.
  ​
• 
  <AI 프로덕트는 어떻게 만들어지는가> by dev_writer 님
  개발만 하고 싶었던 적이 있었습니다. 남들이 쉽게 따라 하지 못한 데에서 오는 성취감, 그리고 남들의 불편함을 바로 해결해 줄 수 있다는 데에서 비롯된 마음이었습니다. 그런데 이제는 비개발자 분들도 AI를 이용하면 바로 각자의 불편함을 해소할 수 있는 환경이 마련된 것을 보면서, 과거처럼 개발만 할 수 있던 능력은 경쟁력이 없어졌음을 체감하고 있습니다. 이제 AI 시대의 경쟁력은 무엇이 사람들의 수요가 몰려 있는 문제 영역인지 식별할 수 있는 능력, 그리고 그것을 풀기 위해 적극적으로 참여하는 실행력이라고 생각합니다. 일례로 개발자 관점으로 사이드 프로젝트를 기획해 본다면, 어떤 문제를 풀고 싶다고 생각하기보다는 어떤 기술을 써볼 수 있을까, 어떻게 하면 테스트 커버리지를 높이고 객체지향적, 유지보수가 쉬운 코드를 만들 수 있을까를 깊이 고민했을 것입니다. 물론 현업에서는 해당 고민들이 유의미하게 중요하지만, 혼자 프로젝트를 개발하거나 1인 개발을 하는 입장에서는 당장 출시하고 빠르게 가설 검증하는 것이 훨씬 중요한 것임을 깨달았습니다.
  ​

■ 데브주요뉴스‍

• • [기획/미토스 이후, 취약점 대응] 취약점 쏟아져도, 패치는 느린 이유
• • 가혹한 토큰 경제학 : 임계점에 다다른 AI 기업들의 재정적 출혈
• • AI 토큰, 새 원가가 되다…‘비용’보다 ‘운영능력’ 경쟁
• • 비싼 미국 AI 왜 써?…비용 폭탄에 美·유럽 기업, 中 AI로 갈아탔다
• • 개발이 공짜가 된다는 말, 어디까지 맞을까?
• • [AI 해커톤 후기] 코드와 문서만 읽은 LLM은 어떻게 사람과 같은 팀을 1위로 골랐을까?
• • AI 에이전트, 중국이 접근하는 방법은 다르다?
• • 2026 상반기, 사람들은 무슨 책을 샀을까?

에디터 OTL_ 무더운 여름, 살포시 눈을 감고 이런 상상을 해.
서늘한 공간, 안락한 자세, 뽀송한 책의 질감, 뭔가 커져가는 고양감을