POOOLING FOREST
비싼 LLM 수업료, 챗봇 운영 비용을 절반으로 줄인 아키텍처 이야기 - LLM 챗봇 운영 비용을 절반으로 줄인 풀링포레스트의 아키텍처 개선 사례를 소개합니다. 모델 라우팅, 시맨틱
Case Studies

비싼 LLM 수업료, 챗봇 운영 비용을 절반으로 줄인 아키텍처 이야기

LLM 챗봇 운영 비용을 절반으로 줄인 풀링포레스트의 아키텍처 개선 사례를 소개합니다. 모델 라우팅, 시맨틱 캐싱, 프롬프트 최적화 등 실전 전략을 확인해 보세요.

송찬영

CTO

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

처음 LLM(Large Language Model)을 도입해 AI 챗봇을 만들었을 때가 기억납니다. 마치 마법 지팡이를 손에 쥔 기분이었죠. 질문만 던지면 그럴듯한 답변이 술술 나오고, 복잡한 문맥도 척척 이해하니 "이거면 게임 끝났다"라는 확신이 들었습니다. 하지만 그 확신이 불안감으로 바뀌는 데는 딱 한 달이면 충분했습니다.

청구서를 받아 들고는 눈을 의심했습니다. 트래픽은 예상 범위였는데, API 호출 비용은 예산을 훌쩍 넘겨버렸더군요. "이대로 서비스하면 유저가 늘어날수록 회사는 망하겠구나"라는 섬뜩한 생각이 들었습니다. 그때 깨달았습니다. LLM 기반 AI 챗봇은 단순히 '잘 대답하는 것'이 문제가 아니라, '감당 가능한 비용으로 대답하는 것'이 진짜 기술력이라는 사실을요.

오늘은 풀링포레스트에서 AI 챗봇을 운영하며 겪었던 비용 문제와, 이를 해결하기 위해 아키텍처를 어떻게 뜯어고쳤는지 그 과정을 이야기해 보려 합니다.

모든 질문을 최고급 모델에게 던지지 마세요

초기 아키텍처는 단순했습니다. 사용자의 모든 입력을 프롬프트로 감싸서 가장 성능이 좋은 SOTA(State-of-the-Art) 모델, 예를 들어 GPT-4나 Claude 3 Opus 같은 최상위 모델에 바로 던졌습니다. 정확도는 높았지만, 이는 마치 편의점에 물 사러 가는데 슈퍼카를 타고 가는 격이었습니다.

"안녕하세요"라는 단순한 인사에 답변하기 위해 건당 수십 원이 나가는 고비용 모델을 쓸 필요는 없습니다. 그래서 우리는 '모델 라우팅(Model Routing)' 계층을 도입했습니다.

사용자의 의도를 먼저 가볍게 분류하는 과정이 필요합니다. 우리는 상대적으로 가볍고 저렴한 모델(GPT-3.5 Turbo나 Gemini Flash 등)이나, 아예 로컬에서 돌아가는 소형 모델(sLLM)을 문지기로 세웠습니다. 이 문지기가 "이건 단순 인사네?", "이건 매뉴얼에 있는 내용이네?"라고 판단하면 무거운 모델까지 가지 않고 즉시 답변을 처리하거나 저렴한 모델로 연결합니다. 정말 복잡한 추론이나 창의성이 필요한 10~20%의 질문만 고비용 모델에게 넘기는 식이죠. 이 구조만 바꿔도 토큰 비용이 눈에 띄게 줄어듭니다.

캐싱, 잊혀진 기본기를 다시 꺼내다

웹 개발에서 캐싱(Caching)은 기본 중의 기본입니다. 하지만 LLM 개발에 들어서면 의외로 이 부분을 간과하곤 합니다. AI의 답변은 매번 생성되어야 한다는 고정관념 때문일까요?

로그를 분석해보니 사람들은 의외로 비슷한 질문을 반복해서 물어봅니다. 특히 서비스 사용법이나 정책 같은 정적인 정보는 더욱 그렇습니다. 우리는 '시맨틱 캐싱(Semantic Caching)'을 도입했습니다. 단순히 문장이 똑같을 때만 캐시를 쓰는 게 아니라, 문장의 의미가 유사하면 저장해 둔 답변을 재활용하는 방식입니다.

벡터 데이터베이스(Vector DB)를 활용해 질문의 의미적 거리를 계산하고, 유사도가 일정 수준 이상이면 LLM을 호출하지 않고 캐시 된 답변을 내보냅니다. 응답 속도는 0.1초 수준으로 빨라지고, API 비용은 '0원'이 됩니다. AI 챗봇의 품질은 유지하면서 운영 효율은 극대화하는 핵심 전략이었습니다.

프롬프트, 줄이는 것이 기술이다

엔지니어들이 흔히 범하는 실수 중 하나가 '혹시 몰라서' 정보를 다 때려 넣는 것입니다. RAG(검색 증강 생성)를 구현할 때, 관련 문서를 통째로 프롬프트에 넣는 경우가 많습니다. LLM 과금은 입력 토큰과 출력 토큰의 합산입니다. 불필요하게 긴 문맥(Context)은 비용을 기하급수적으로 늘립니다.

우리는 검색된 문서를 그대로 넣지 않고, 한 번 요약해서 주입하거나 정말 핵심적인 문단만 추출하는 전처리 과정을 강화했습니다. 또한, 시스템 프롬프트(System Prompt)를 최적화하여 불필요한 미사여구를 빼고, AI가 장황하게 답변하지 않도록 "간결하게 핵심만 답하라"는 지시를 명확히 했습니다. 답변 길이가 줄어들면 출력 토큰 비용도 감소하고, 사용자 입장에서도 가독성이 좋아지니 일석이조입니다.

오픈소스 모델과의 하이브리드 전략

모든 것을 상용 API에 의존하는 것은 장기적으로 위험합니다. 비용 통제권을 외부에 맡기는 꼴이니까요. 풀링포레스트는 특정 도메인 지식이 필요한 태스크의 경우, Llama 3나 Mistral 같은 오픈소스 모델을 파인튜닝(Fine-tuning)하여 자체 호스팅하는 실험을 병행하고 있습니다.

물론 GPU 서버 운영 비용이 들지만, 트래픽이 일정 수준 이상으로 넘어가면 API 종량제보다 자체 호스팅이 훨씬 저렴해지는 분기점(Break-even point)이 옵니다. 특히 민감한 개인정보를 다루거나 보안이 중요한 영역에서는 이 하이브리드 전략이 비용뿐만 아니라 데이터 주권 측면에서도 유리합니다.

결국은 '측정'과 '관찰'입니다

아무리 좋은 아키텍처를 설계해도 상황은 변합니다. 새로운 모델은 매주 쏟아져 나오고, 가격 정책도 수시로 바뀝니다. 그래서 우리는 '비용 관제 시스템'을 구축했습니다. 어떤 유저 그룹이 토큰을 많이 쓰는지, 어떤 유형의 질문이 비용을 유발하는지 실시간으로 모니터링합니다.

비용이 튀는 지점을 발견하면 그 부분만 집중적으로 튜닝합니다. 예를 들어, 특정 기능에서 토큰 소모가 극심하다면 그 기능만 별도의 경량화 모델로 교체하는 식입니다. 막연히 "비싸다"라고 걱정하는 것이 아니라, 데이터를 보고 "어디가 비싼지" 정확히 파악해야 액션을 취할 수 있습니다.

마무리하며

LLM 기반 AI 챗봇을 개발하는 것은 이제 누구나 할 수 있습니다. 하지만 이를 지속 가능한 비즈니스 모델로 운영하는 것은 엔지니어링 리더십의 영역입니다. 기술적인 화려함보다는 비즈니스의 지속 가능성을 먼저 고민해야 합니다.

처음의 그 막막했던 청구서를 이제는 웃으면서 봅니다. 아키텍처를 고민하고 최적화한 만큼 비용이 줄어드는 것이 눈에 보이니까요. 여러분도 AI라는 강력한 도구를 도입함에 있어, 단순히 기능 구현에만 매몰되지 말고 그 뒤단의 효율성과 구조를 깊이 있게 고민해 보셨으면 좋겠습니다. 비용 최적화는 단순히 돈을 아끼는 것이 아니라, 서비스를 더 오래, 더 많은 사람에게 제공하기 위한 생존 전략입니다.

지금 읽으신 내용, 귀사에 적용해보고 싶으신가요?

상황과 목표를 알려주시면 가능한 옵션과 현실적인 도입 경로를 제안해드립니다.