LLM 비용 줄이는 방법, 토큰 과금에서 많이 틀리는 지점 5가지(사례로 정리)

LLM 비용은 대부분 “계산이 어려워서”가 아니라, 토큰이 생각보다 많이 들어가거나 “다시 써야 할 일을 계속 반복”해서 새요. 결론은 간단해요. 입력·출력 토큰을 줄이고, 불필요한 호출을 없애고, 재사용(캐시/요약/결과 저장)을 붙이면 효과가 바로 나요.

LLM 비용 줄이는 방법: 토큰 과금에서 많이 틀리는 지점(사례로 정리)

아래 5가지는 실제 서비스에서 비용이 갑자기 튀는 패턴과 연결돼요. 각 항목은 “왜 틀리는지 → 어떤 모습인지 → 어떻게 고치는지” 순서로 볼게요.

1) 히스토리를 ‘전부’ 다시 보내는 습관

챗봇을 만들다 보면 “사용자 대화 전체를 매번 넣어야 이해가 좋아진다”라고 생각하기 쉬워요. 그런데 토큰 과금 구조에선 이게 곧 비용 폭탄이 됩니다.

사례로 보면, 고객 상담형 챗봇이 “대화 기록 전체”를 그대로 프롬프트에 붙여서 돌리다가, 이용 시간이 늘수록 비용이 선형(혹은 그 이상)으로 증가했어요. 사용자는 같은 질문을 해도 시스템은 매번 더 긴 입력을 처리하니 토큰이 계속 커지죠.

고치는 방법은 히스토리 전략을 고정하는 겁니다.

• 최근 N턴만 원문 유지

• 나머지는 “상담 요약 5~10줄”처럼 토큰 적게

• 사용자 의도/제약/요구사항만 메타로 재삽입

2) 출력 길이를 “기본값”에 맡기는 경우

LLM을 호출할 때 “자유롭게 길게 써줘” 형태가 섞이면, 생각보다 자주 출력이 길어져요. 토큰 과금은 입력뿐 아니라 생성(output)도 함께 물기 때문에 더 위험합니다.

사례로는, 리포트 생성 기능에서 “상세하게 작성” 요구가 붙어 있었고, 사용자가 자꾸 “더 길게”를 추가하면서 문서가 계속 확장됐어요. 결과적으로 한 번의 요청이 짧게 끝나지 않고, 후속 요청에서도 더 많은 맥락을 만들며 비용이 늘었습니다.

고치는 방법은 출력 목표를 “토큰 친화적으로” 먼저 정하는 거예요.

• 요약/결론/불릿처럼 형식을 고정

• 최대 글자/최대 항목 수 같은 상한을 둠

• “필요 없으면 생략” 규칙을 프롬프트에 명시

3) 프롬프트에 설명을 너무 많이 넣고, 중복도 많게 만드는 경우

프롬프트는 “매번 동일한 지시문”이 반복되기 쉬워요. 그런데 동일 지시문이 길면, 호출 한 번마다 불필요한 토큰을 계속 태우게 됩니다.

사례로 보면, 개발팀이 만든 시스템 프롬프트가 버전업할 때마다 설명이 누적됐고, 사용자 프롬프트에도 같은 제약(톤, 형식, 금지사항)이 중복으로 들어가 있었어요. 모델이 굳이 읽을 필요가 없는 텍스트가 “호출 횟수만큼” 쌓이면서 비용이 올라갔습니다.

고치는 방법은 “지시문을 압축”하고 “중복 제거”예요.

• 시스템/사용자 프롬프트에 같은 제약을 중복 기입하지 않기

• 길게 설명하는 대신 체크리스트처럼 짧게

• 업데이트가 잦으면 템플릿 관리로 누적 방지

4) 툴 호출/에이전트를 ‘자동 반복’하게 설계한 경우

툴을 쓰거나 에이전트처럼 여러 단계를 밟는 구조는 편하지만, 잘못하면 호출 횟수와 중간 생성이 늘어납니다. “한 번에 끝내기”보다 “계속 시도”가 되면 토큰이 계속 소모돼요.

사례로는, 검색/DB 조회 툴을 연결한 에이전트가 실패하면 재시도하면서, 매번 근거를 다시 생성해 프롬프트와 output이 누적됐어요. 사용자는 결과만 원했는데, 시스템은 내부 과정을 계속 말로 만들고 있었던 셈입니다.

고치는 방법은 반복을 “규칙”으로 끊는 겁니다.

• 툴 재시도 횟수 상한

• 실패 시 즉시 대체 답(예: 범위 축소)로 전환

• 중간 상태(채팅 로그)를 다음 단계 프롬프트에 전부 넣지 않기

5) 캐시/재사용 없이 “같은 걸 매번 다시” 계산하는 경우

비용을 줄이는 가장 현실적인 방법은 “다시 안 시키는 것”이에요. 그런데 캐시를 안 두면, 동일 문서 요약이나 동일 질의 응답을 요청할 때마다 새로 토큰을 씁니다.

사례로는, 제품 문서 Q&A에서 같은 FAQ가 반복되어도 매번 RAG 검색→요약→답변을 새로 수행했어요. 사용자 수가 늘자 토큰 비용도 그대로 따라 올라갔죠.

고치는 방법은 “어디를 캐시할지”부터 정하는 겁니다.

• 요약/추출 결과(중간 산출물) 캐시

• 동일 질의(혹은 유사 질의) 응답 캐시

• 문서 임베딩/검색 결과는 가능하면 재사용

바로 써먹는 절감 체크리스트

지금 운영 중인 서비스라면, 아래 순서대로 보면 우선순위가 잡혀요. (시간 대비 효과가 큰 쪽부터)

1. 요청 1건당 토큰(입력/출력)을 로그로 분리해 보기

2. 입력 누적(히스토리) 비중이 큰지, 출력이 길어지는지 먼저 판별

3. 길이 상한을 프롬프트+애플리케이션 레벨에서 동시에 걸기

4. 캐시 후보(문서 요약/FAQ/중간 산출물)부터 정해 실험 적용

자주 묻는 질문