<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: 해봄</title>
    <description>The latest articles on DEV Community by 해봄 (@haebom).</description>
    <link>https://dev.to/haebom</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4103627%2F3cd9572d-3450-468e-8df9-071825d0da42.png</url>
      <title>DEV Community: 해봄</title>
      <link>https://dev.to/haebom</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/haebom"/>
    <language>en</language>
    <item>
      <title>LLM으로 서비스 만들 때 토큰 비용이 실제로 새는 곳 (5가지)</title>
      <dc:creator>해봄</dc:creator>
      <pubDate>Tue, 01 Sep 2026 04:53:36 +0000</pubDate>
      <link>https://dev.to/haebom/llmeuro-seobiseu-mandeul-ddae-tokeun-biyongi-siljero-saeneun-gos-5gaji-1md1</link>
      <guid>https://dev.to/haebom/llmeuro-seobiseu-mandeul-ddae-tokeun-biyongi-siljero-saeneun-gos-5gaji-1md1</guid>
      <description>&lt;p&gt;LLM을 쓰는 서비스를 만들면 비용 이야기가 반드시 나옵니다. 그런데 처음 논의되는 건 대개 "어느 모델을 쓸 것인가"입니다. 실제로 청구서를 뜯어 보면 모델 선택보다 &lt;strong&gt;구조에서 새는 양&lt;/strong&gt;이 더 큰 경우가 많습니다.&lt;/p&gt;

&lt;h2&gt;
  
  
  1. 같은 요청을 두 번 부르는 것
&lt;/h2&gt;

&lt;p&gt;가장 흔하고 가장 조용한 낭비입니다. 사용자가 버튼을 두 번 누르거나, 결과가 안 나온다고 새로고침하거나, 네트워크가 끊겨서 재시도하는 상황입니다. 서버 입장에서는 정상 요청이라 로그에도 이상하게 보이지 않습니다.&lt;/p&gt;

&lt;p&gt;막는 방법은 간단합니다. 요청 내용을 해시해서 키로 삼고, 같은 키가 이미 처리됐으면 저장된 결과를 돌려주는 것입니다.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;키: 도구 이름 + 정규화한 입력값의 해시&lt;/li&gt;
&lt;li&gt;저장 시점: 결과를 쓸 때 같은 트랜잭션으로&lt;/li&gt;
&lt;li&gt;유효 기간: 한 시간 정도면 충분&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;이 사이트도 같은 방식으로 처리합니다. 결과 저장과 멱등 키 기록을 한 트랜잭션으로 묶어서, 둘 중 하나만 남는 상태가 생기지 않게 했습니다. 구현은 몇십 줄인데 막아 주는 비용은 그보다 훨씬 큽니다.&lt;/p&gt;

&lt;h2&gt;
  
  
  2. 매 요청마다 프롬프트 앞쪽이 조금씩 달라지는 것
&lt;/h2&gt;

&lt;p&gt;프롬프트 캐싱은 &lt;strong&gt;앞에서부터 정확히 일치하는 구간&lt;/strong&gt;만 재사용됩니다. 그래서 시스템 프롬프트 안에 현재 시각이나 요청 ID를 넣으면 그 뒤 전체가 캐시에서 빠집니다. 한 글자만 달라져도 그렇습니다.&lt;/p&gt;

&lt;p&gt;자주 걸리는 것들이 정해져 있습니다.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;시스템 프롬프트에 넣은 오늘 날짜&lt;/li&gt;
&lt;li&gt;매번 순서가 달라지는 JSON 직렬화&lt;/li&gt;
&lt;li&gt;조건에 따라 도구 목록을 다르게 구성하는 코드&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;고치는 방향도 단순합니다. &lt;strong&gt;고정된 것을 앞에, 매번 바뀌는 것을 뒤에&lt;/strong&gt; 둡니다. 캐시가 실제로 먹고 있는지는 응답의 캐시 읽기 토큰 수를 보면 바로 알 수 있습니다. 반복 호출인데 계속 0이면 어딘가에서 앞쪽이 흔들리고 있는 것입니다.&lt;/p&gt;

&lt;h2&gt;
  
  
  3. 출력 길이를 제한하지 않는 것
&lt;/h2&gt;

&lt;p&gt;입력보다 출력이 몇 배 비쌉니다. 그런데 프롬프트에 "자세히 설명해 주세요"라고 써 두면 모델은 성실하게 길게 씁니다. 사용자는 그 절반도 안 읽습니다.&lt;/p&gt;

&lt;p&gt;길이는 토큰 상한으로 자르는 것보다 &lt;strong&gt;형식으로 통제하는 편&lt;/strong&gt;이 낫습니다. 상한으로 자르면 문장 중간에서 끊겨서 재시도가 발생하고, 결국 두 번 부르는 셈이 됩니다. 대신 "표로 정리", "3문장 이내", "항목 5개" 같은 형식 지시를 주면 모델이 알아서 그 안에서 끝냅니다. 읽기도 더 낫습니다.&lt;/p&gt;

&lt;h2&gt;
  
  
  4. 결과 페이지를 매번 다시 만드는 것
&lt;/h2&gt;

&lt;p&gt;이건 토큰이 아니라 인프라 쪽이지만 같은 성격의 낭비입니다. 한 번 만들어진 결과는 바뀌지 않는데, 그 결과 링크를 여러 사람이 열 때마다 서버가 매번 조회하고 렌더한다면 불필요한 일을 반복하는 것입니다.&lt;/p&gt;

&lt;p&gt;결과가 불변이라면 캐시 헤더를 길게 주면 됩니다. 공유 링크가 널리 퍼지는 서비스라면 이 차이가 꽤 큽니다. 링크 하나가 만 번 열려도 실제 서버 처리는 사실상 한 번으로 끝납니다.&lt;/p&gt;

&lt;h2&gt;
  
  
  5. 어려운 작업에만 필요한 설정을 전부에 적용하는 것
&lt;/h2&gt;

&lt;p&gt;요즘 모델들은 사고 깊이를 조절할 수 있습니다. 그런데 이걸 서비스 전체에 한 값으로 고정해 두는 경우가 많습니다. 분류나 짧은 변환처럼 단순한 작업까지 높은 설정으로 돌아가면 품질 차이는 거의 없는데 비용만 올라갑니다.&lt;/p&gt;

&lt;p&gt;경로별로 나누는 게 맞습니다. 판단이 필요한 곳은 높게, 형식 변환에 가까운 곳은 낮게 둡니다. 다만 순서가 중요합니다. &lt;strong&gt;캐싱과 중복 호출 차단 같은 공짜 개선을 먼저 하고&lt;/strong&gt;, 그다음에 품질을 거래하는 조정을 합니다. 반대로 하면 품질만 깎이고 비용은 별로 안 줄어듭니다.&lt;/p&gt;

&lt;h2&gt;
  
  
  정리
&lt;/h2&gt;

&lt;ol&gt;
&lt;li&gt;같은 요청 두 번 부르지 않기 (멱등 키)&lt;/li&gt;
&lt;li&gt;프롬프트 앞쪽 고정해서 캐시 살리기&lt;/li&gt;
&lt;li&gt;출력 길이를 형식으로 통제하기&lt;/li&gt;
&lt;li&gt;불변 결과는 캐시하기&lt;/li&gt;
&lt;li&gt;경로별로 사고 깊이 조정하기&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;1번부터 4번까지는 품질을 전혀 깎지 않습니다. 대부분의 경우 여기까지만 해도 비용 이야기가 한동안 나오지 않습니다. 모델을 낮추는 건 그다음에 고민해도 늦지 않습니다.&lt;/p&gt;




&lt;blockquote&gt;
&lt;p&gt;이 글은 제가 운영하는 &lt;a href="https://haebom.site" rel="noopener noreferrer"&gt;해봄&lt;/a&gt;에 먼저 올린 글입니다. 자소서 첨삭·3줄 요약·말투 바꾸기·면접 질문·회의록 정리 도구를 무료로 열어 두고 있고, 위 글은 그걸 만들면서 비용을 뜯어본 기록입니다. 원문: &lt;a href="https://haebom.site/blog/ai-tool-cost-leak" rel="noopener noreferrer"&gt;https://haebom.site/blog/ai-tool-cost-leak&lt;/a&gt;&lt;/p&gt;
&lt;/blockquote&gt;

</description>
      <category>ai</category>
      <category>llm</category>
      <category>productivity</category>
    </item>
  </channel>
</rss>
