LLM 호출 비용 감소를 위한 TTL Cache 적용

왜 이 기능이 필요했나

동숲 프로젝트에서 사용자가 같은 질문을 반복하거나, 유사한 정보 조회 요청이 짧은 시간 안에 반복되는 상황이 있었습니다.

LLM 호출은 매번 비용과 응답 시간이 발생하기 때문에, 동일한 요청에 대해 매번 새로 LLM을 호출하는 구조는 비효율적이라고 판단했습니다.

기존 구조의 문제

기존에는 사용자의 요청이 들어오면 항상 다음 흐름으로 처리했습니다.

1. 사용자 질문 수신
2. 필요한 컨텍스트 검색
3. 프롬프트 구성
4. LLM 호출
5. 응답 반환

이 구조는 단순하지만, 같은 질문이 반복되어도 매번 LLM을 호출한다는 문제가 있었습니다.

예를 들어 다음과 같은 질문은 짧은 시간 안에 반복될 가능성이 높았습니다.

• 오늘 학식 뭐야?
• 학교 공지 알려줘
• 강의실 위치 알려줘

TTL Cache를 선택한 이유

캐시를 무기한 저장하면 오래된 정보가 사용자에게 전달될 수 있습니다.
특히 공지, 식단, 일정처럼 시간이 지나면 바뀔 수 있는 정보는 캐시 만료 기준이 필요했습니다.

그래서 일정 시간이 지나면 자동으로 캐시가 만료되는 TTL Cache 방식을 선택했습니다.

TTL Cache를 사용하면 다음 장점이 있었습니다.

• 같은 요청에 대한 LLM 중복 호출 감소
• 응답 속도 개선
• 오래된 응답이 계속 재사용되는 문제 완화
• 구현 복잡도 대비 효과가 큼

적용 방식

캐시 키는 사용자의 질문을 기준으로 만들었습니다.
동일한 질문이 들어오면 먼저 캐시를 확인하고, 캐시에 응답이 남아 있으면 LLM을 호출하지 않고 저장된 응답을 반환하도록 했습니다.

흐름은 다음과 같이 바뀌었습니다.

1. 사용자 질문 수신
2. 캐시 키 생성
3. 캐시에 응답이 있는지 확인
4. 캐시가 있으면 캐시 응답 반환
5. 캐시가 없으면 기존처럼 검색 및 LLM 호출
6. LLM 응답을 TTL과 함께 저장
7. 사용자에게 응답 반환

TTL 시간을 어떻게 정했나

TTL은 너무 짧으면 캐시 효과가 떨어지고, 너무 길면 오래된 정보가 반환될 수 있습니다.

처음부터 완벽한 TTL 값을 정하기보다는, 운영하면서 호출 빈도와 응답 정확도를 보고 조정할 수 있도록 설계했습니다.

현재 적용한 TTL 값은 2시간 입니다.

적용하면서 고려한 점

TTL Cache를 적용할 때 단순히 비용만 줄이는 것보다 중요한 것은 “잘못된 정보를 빠르게 주지 않는 것”이었습니다.

그래서 다음 기준을 함께 고려했습니다.

• 실시간성이 중요한 질문은 캐시하지 않기
• 사용자별로 결과가 달라질 수 있는 질문은 공통 캐시에서 제외하기
• 캐시된 응답인지 로그로 확인할 수 있게 하기
• 캐시 만료 후에는 다시 최신 컨텍스트로 응답 생성하기

결과와 기대 효과

TTL Cache 적용을 통해 반복 질문에 대한 LLM 호출을 줄일 수 있었습니다.
특히 동일하거나 자주 반복되는 학교 정보 질문에서 비용과 응답 시간을 줄이는 효과를 기대할 수 있었습니다.

또한 캐시 적용 전후를 비교할 수 있는 구조를 만들면서, 단순히 기능을 붙이는 것이 아니라 운영 비용을 고려한 AI 기능 설계의 중요성을 느꼈습니다.

배운 점

LLM 기능은 “잘 답하는 것”만큼이나 “언제 호출하지 않을지”를 설계하는 것도 중요했습니다.

무조건 LLM을 호출하는 방식은 구현은 단순하지만, 실제 서비스에서는 비용과 속도 문제가 누적될 수 있습니다. TTL Cache를 적용하면서 AI 기능도 백엔드 시스템의 일부로 보고, 비용·응답성·정확성 사이의 균형을 고민해야 한다는 점을 배웠습니다.