개념
대규모 언어 모델(LLM) API의 요금은 대체로 요청 건수가 아니라 주고받은 토큰의 수에 비례해 매겨진다. 보낸 프롬프트를 세는 입력 토큰과 모델이 생성한 답변을 세는 출력 토큰을 나누어 계산하며, 두 단가는 같지 않다. 일반적으로 출력 쪽이 더 비싸게 매겨지는데, 답을 한 토큰씩 순서대로 만들어 내는 연산이 입력을 한꺼번에 읽는 연산보다 부담이 크기 때문이다.
여기서 자주 놓치는 부분이 대화 누적이다. 챗봇에서 대화가 이어질 때 모델이 앞의 내용을 기억하고 있는 것이 아니라, 매 요청마다 지난 대화 전체가 다시 입력으로 들어간다. 그래서 대화가 길어질수록 질문 하나에 붙는 입력 토큰이 계속 불어나고, 짧은 한마디가 예상보다 훨씬 비싸질 수 있다. 컨텍스트 윈도우가 크다는 말은 많이 넣을 수 있다는 뜻이지 넣어도 싸다는 뜻이 아니다.
같은 앞부분을 반복해서 보낼 때 그 부분을 캐시해 두고 할인된 단가로 계산해 주는 프롬프트 캐싱 기능도 널리 제공된다. 실패해 재시도한 요청도 그때까지 처리된 만큼 비용이 발생할 수 있으므로, 타임아웃과 재시도 정책을 느슨하게 두면 눈에 보이지 않는 비용이 쌓인다. 구체적인 단가와 정책은 모델과 제공사, 시점에 따라 계속 바뀌므로 도입 시점에 공식 가격표를 직접 확인해야 한다.
쓰임새
비용을 줄이는 방법은 대체로 몇 갈래로 정리된다. 작업 난이도에 맞는 작은 모델을 함께 쓰는 것, 매번 반복되는 지시문을 캐싱이 걸리도록 앞쪽에 고정하는 것, 대화 이력을 통째로 넘기는 대신 요약해 넘기는 것, 그리고 RAG에서 청킹과 검색 개수를 조절해 넘기는 문서량 자체를 줄이는 것이다.
에이전틱 워크플로를 쓴다면 비용 관리는 한층 중요해진다. 도구 호출과 재시도가 반복되면서 사용자 눈에 보이지 않는 호출이 여러 번 일어나므로, 요청 단위가 아니라 작업 단위로 토큰을 집계해 보아야 실제 원가가 드러난다.
줄이기에 앞서 먼저 재야 한다. 대부분의 API는 응답에 입력·출력 토큰 수를 함께 돌려주므로, 이 값을 기능별로 남겨 두면 어느 기능이 비용의 대부분을 쓰고 있는지 금방 드러난다. 비용은 대체로 고르게 퍼져 있지 않고 특정 기능 한둘에 몰려 있어서, 그곳만 손봐도 총액이 크게 내려가는 경우가 많다. 어림짐작으로 프롬프트를 줄이기 시작하면 정작 비싼 쪽은 그대로 두고 품질만 깎게 된다.
자주 하는 오해
토큰은 단어와 같은 것 아닌가?
토큰은 단어보다 잘게 쪼개진 단위이고, 한국어는 영어보다 같은 내용에 더 많은 토큰이 드는 경향이 있다. 글자 수만 보고 비용을 어림하면 빗나가기 쉽다.
답변이 짧으면 비용도 적게 나오지 않나?
답이 짧아도 함께 보낸 문서와 대화 이력이 길면 입력 토큰에서 비용이 발생한다.
가장 성능 좋은 모델을 쓰는 것이 항상 이득 아닌가?
분류나 형식 변환처럼 단순한 단계까지 최상위 모델에 맡기면 품질 차이는 거의 없이 비용만 몇 배로 늘어난다. 어려운 판단이 필요한 단계와 그렇지 않은 단계를 나눠 서로 다른 모델에 맡기는 구성이 흔히 쓰인다.
직접 계산해 보기: LLM API 요금 계산기에 월 사용량을 넣으면 주요 모델의 월 비용이 원화로 비교된다.