LLM API 비용 폭탄 피하기: 토큰 절약·캐싱·모델 선택 실전 전략

LLM 기능을 붙인 MVP는 빠르게 만들 수 있지만, 사용자가 늘거나 긴 문서를 반복해서 보내기 시작하면 API 비용이 예상보다 빨리 커질 수 있습니다. 핵심은 호출 횟수만 줄이는 것이 아니라, 한 번의 요청에 포함되는 정보와 모델의 역할을 설계하는 것입니다.

1. 먼저 과금 단위를 쪼개서 보자

입력 토큰과 출력 토큰

LLM API 비용은 보통 요청에 넣는 입력과 모델이 생성하는 출력의 양에 영향을 받습니다. 입력에는 사용자의 질문뿐 아니라 시스템 지침, 대화 기록, 검색된 문서, 도구 결과까지 포함될 수 있습니다. 특히 대화형 기능은 매 요청마다 이전 기록을 다시 보내는 구조가 되기 쉬워, 사용자는 짧게 질문해도 입력량은 계속 늘어날 수 있습니다.

출력도 길수록 비용과 응답 시간이 함께 커집니다. “자세히 설명해줘” 같은 지시를 기본값으로 두면 필요 이상의 답변이 생성될 수 있으므로, 화면에서 필요한 필드와 최대 길이를 먼저 정하는 편이 좋습니다.

비용이 커지는 세 순간

비용은 대체로 긴 컨텍스트를 매번 재전송할 때, 단순한 작업에도 고성능 모델을 사용할 때, 재시도와 스트리밍 실패를 추적하지 않을 때 커집니다. 조코헌트에 출시된 프로덕트 216개 중 AI 도구가 42%라는 점을 보면, 인디 제품에서도 AI 호출 비용은 초기부터 설계할 가치가 있는 운영 항목입니다.

2. 프롬프트를 줄이되, 정보는 보존하기

고정 지침과 가변 데이터를 분리하기

프롬프트 전체를 짧게 만드는 것보다 먼저 할 일은 반복되는 내용과 매번 바뀌는 내용을 나누는 것입니다. 역할, 출력 형식, 금지사항처럼 고정된 지침은 한곳에서 관리하고, 사용자 질문이나 검색 결과처럼 변하는 데이터만 요청에 넣습니다.

긴 문서를 통째로 전달하기보다 필요한 부분을 먼저 찾는 구조도 유용합니다. 문서 기반 기능을 만든다면 RAG 직접 만들기: 내 문서를 AI가 답변하게 하는 검색증강 구조 입문의 검색-생성 흐름을 참고해, 관련성이 낮은 문단을 컨텍스트에서 제외해 보세요.

출력 형식을 좁히기

자유로운 장문 답변 대신 JSON 필드, 선택지, 짧은 요약처럼 결과의 범위를 정하면 불필요한 출력이 줄어듭니다. 예를 들어 “요약, 위험도, 다음 행동” 세 필드만 반환하도록 계약하면 화면에서 쓰지 않는 설명을 받지 않을 수 있습니다. 프롬프트를 설계할 때는 AI에게 코드를 잘 시키는 프롬프트 작성법: 명세·제약·예시 3요소처럼 명세와 제약을 함께 적는 방식이 도움이 됩니다.

3. 작업별로 모델을 분리하기

고성능 모델이 필요한 작업

복잡한 추론, 긴 문서의 비교, 애매한 요청의 분류처럼 오류 비용이 큰 작업은 상대적으로 강한 모델을 검토할 수 있습니다. 다만 “AI 기능 전체”를 한 모델에 맡기지 말고, 실제 실패 사례를 모아 필요한 품질 기준을 정해야 합니다.

가벼운 모델로 충분한 작업

문장 분류, 형식 변환, 태그 추출, 짧은 요약, 간단한 라우팅은 더 가벼운 모델로도 충분한 경우가 많습니다. 먼저 저비용 모델을 기본값으로 두고, 신뢰도나 규칙 위반이 감지될 때만 보완 호출을 하는 단계적 구조를 시도해 보세요. 모델별 특성과 최신 가격은 바뀔 수 있으므로 도입 전 공식 문서에서 확인해야 합니다.

4. 캐싱과 요청 재사용 설계

동일한 시스템 지침이나 제품 설명을 여러 요청에 반복해서 보낸다면 캐싱을 검토할 수 있습니다. 캐시는 “한 번 저장하면 모든 비용이 사라진다”는 기능이 아니라, 반복되는 입력을 효율적으로 처리하기 위한 선택지입니다. 제공 방식, 적용 조건, 보관 정책은 사용하는 API의 공식 문서를 확인하세요.

캐싱이 어렵다면 애플리케이션 레벨에서 먼저 중복을 줄일 수 있습니다. 같은 사용자 요청의 처리 결과를 짧은 시간 보관하고, 변경되지 않은 문서의 요약을 데이터베이스에 저장하며, 새 질문이 들어올 때 전체 대화를 다시 보내지 않는 식입니다. 단, 사용자별 권한이나 최신성에 영향을 받는 정보는 캐시 키를 분리해야 합니다.

5. 상한선을 코드로 고정하기

예산 가드레일

관리자 화면이나 로그에 요청별 모델, 입력·출력 토큰, 응답 시간, 재시도 횟수를 남기세요. 비용을 정확히 계산하는 방식은 API 제공자의 정책을 기준으로 구현하되, 최소한 “어떤 기능이 많이 호출되는가”는 확인할 수 있어야 합니다.

그다음 사용자·기능·시간 단위의 제한을 둡니다. 출력 최대 길이, 요청 타임아웃, 재시도 횟수, 일일 사용량 상한을 코드와 환경 설정에 분리해 두면 문제가 생겼을 때 빠르게 낮출 수 있습니다. 실패한 요청을 무조건 자동 재시도하면 장애가 비용으로 바뀔 수 있으므로, 재시도 가능한 오류와 즉시 중단할 오류를 나누는 것도 중요합니다.

출시 전 점검 질문

• 이 요청에 꼭 필요한 컨텍스트만 들어갔는가?
• 출력 필드와 최대 길이가 정해져 있는가?
• 모든 작업이 같은 모델을 쓰고 있지는 않은가?
• 반복 입력이나 결과를 재사용할 수 있는가?
• 사용량 상한과 비상 중지 방법이 있는가?

처음부터 완벽한 비용 예측을 하기는 어렵습니다. 대신 작은 트래픽에서도 호출 단위의 기록을 남기고, 실제 사용 패턴에 따라 프롬프트·모델·캐시 정책을 함께 조정하세요. LLM 기능은 모델을 붙이는 순간 끝나는 것이 아니라, 비용이 통제 가능한 운영 시스템이 될 때 비로소 제품의 일부가 됩니다.