비용이나 지연 시간(Latency)을 망가뜨리지 않고 제품에 LLM을 도입하는 방법

"인상적인 데모"와 "프로덕션 기능" 사이의 간극은 거의 전적으로 비용 및 지연 시간(Latency) 엔지니어링에 관한 것입니다. 모델은 쉬운 부분입니다. 그 간극을 메우는 방법은 다음과 같습니다.

먼저, 실제로 무엇에 대해 비용을 지불하고 있는지 이해하세요

대부분의 LLM API는 토큰 (Tokens) — 대략 단어의 3/4 정도 — 단위로 과금하며, 양방향 모두에 대해 과금합니다: 사용자가 보내는 토큰(입력, Input)과 모델이 생성하는 토큰(출력, Output)입니다. 출력 토큰은 일반적으로 입력 토큰보다 몇 배 더 비싸며, 이는 다음과 같은 명확하지 않은 결과를 초래합니다: 장황한 프롬프트(Prompt)가 장황한 답변보다 더 저렴하다는 것입니다.

이는 최적화의 관점을 재설정합니다. 사람들은 프롬프트를 다듬는 데 집착하면서, 정작 80토큰이면 충분할 답변을 모델이 800토큰 동안 떠들게 내버려 둡니다. 비용을 절감하고 싶다면, 가장 영향력이 큰 조치는 거의 항상 출력을 제한하는 것입니다: JSON 형식을 요구하거나, 단일 문장을 요구하거나, max_tokens 상한선을 설정하고, 모델에게 명시적으로 간결하게 답변하라고 지시하십시오.

지연 시간(Latency)도 동일한 논리를 따릅니다. 생성은 순차적입니다 — 모델은 한 번에 하나의 토큰을 생성합니다 — 따라서 출력 길이는 요청이 얼마나 걸리는지를 결정하는 가장 큰 요인입니다. 50토큰 답변은 모델에 관계없이 거의 항상 빠릅니다. 2,000토큰 답변은 가장 빠른 인프라에서도 느립니다.

레버 1: 필요하지 않을 때는 모델을 호출하지 마세요

가장 저렴하고 빠른 LLM 호출은 호출하지 않는 것입니다. 두 가지 기술이 놀라울 정도로 많은 트래픽을 제거할 수 있습니다.

동일하거나 거의 동일한 요청을 캐싱(Caching)하십시오. 많은 실제 프롬프트는 반복됩니다 — 동일한 FAQ 스타일의 질문, 동일한 문서의 두 번의 요약, 유사한 입력에 대한 동일한 분류 등입니다. 정규화된 프롬프트를 키(Key)로 사용하는 캐시는 반복되는 요청을 밀리초 미만의 조회로 바꿔줍니다. 정확히 일치하는 반복의 경우 단순한 키-값(Key-value) 캐시가 작동합니다. 유사한 요청의 경우, 쿼리를 임베딩(Embedding)하고 이전 쿼리가 벡터 공간(Vector space)에서 충분히 가깝다면 캐싱된 답변을 반환하는 시맨틱 캐시(Semantic cache)를 사용하면 약간의 튜닝 비용을 들여 훨씬 더 많은 트래픽을 흡수할 수 있습니다.

적절한 티어(Tier)로 라우팅하기. 모든 작업에 가장 성능이 뛰어난 모델이 필요한 것은 아닙니다. 고객 지원 티켓을 다섯 가지 카테고리 중 하나로 분류하는 작업은 작고, 저렴하며, 빠른 모델이 수행하기에 적합한 일입니다. 반면, 미묘한 뉘앙스가 담긴 고객 이메일을 초안 작성하는 일은 프리미엄 모델을 사용할 가치가 있습니다. 복잡한 방식 이전에 키워드나 길이 기반의 휴리스틱(Heuristic)을 사용하는 간단한 라우터(Router)만으로도, 쉬운 작업은 저렴한 모델로 보내고 어려운 작업은 비싼 모델로 보냄으로써 품질 저하를 느끼게 하지 않으면서도 비용을 획기적으로 절감할 수 있습니다.

레버 2: 지연 시간(Latency)이 실제보다 더 낮게 느껴지도록 만들기

때로는 진정으로 길고 고품질인 응답이 필요하며, 실제로 몇 초가 걸릴 수도 있습니다. 항상 속도를 더 빠르게 만들 수는 없지만, 사용자에게는 속도가 빠르게 느껴지도록 만들 수 있으며, 이것이 실제로는 사용자에게 더 중요한 경우가 많습니다.

응답을 스트리밍(Stream)하기. 전체 답변이 나올 때까지 기다렸다가 한꺼번에 쏟아내는 대신, 토큰(Token)이 생성되는 대로 스트리밍하세요. 사용자는 몇 백 밀리초(ms) 후에 읽기를 시작하며, 전체 생성 시간은 변하지 않더라도 체감 대기 시간은 급격히 줄어듭니다. 이는 모든 채팅 스타일 기능에서 UX(사용자 경험)에 가장 큰 영향을 미치는 변화이며, 대부분의 SDK는 단 한 줄의 코드 변경으로 이를 지원합니다.

스트리밍되지 않는 작업에 대해 정직한 진행 상황 보여주기. 검색(Retrieve), 추론(Reason), 형식화(Format)와 같이 여러 단계의 작업을 수행하는 경우, 사용자에게 무엇이 일어나고 있는지 알려주세요 ("문서를 검색 중입니다...", "답변을 작성 중입니다..."). 눈에 보이고 정직한 상태 표시(Status)는 작업이 진행 중인지에 대해 아무런 정보도 주지 않는 스피너(Spinner)보다 훨씬 낫습니다.

레버 3: 평균이 아닌 최악의 경우를 제어하기

평균 지연 시간은 위안을 주는 거짓말입니다. LLM 엔드포인트(Endpoint)는 헤비 테일(Heavy tails) 특성을 가집니다. 대부분의 요청은 괜찮지만, 상당 부분의 요청은 3~5배 더 오래 걸리고, 일부는 완전히 타임아웃(Timeout)됩니다. 만약 제품이 이러한 요청들 때문에 차단된다면, 아주 적은 비율의 느린 요청들이 전체 경험을 지배할 수 있습니다.

테일(Tail) 현상에 명시적으로 대비하세요:

• 공격적인 타임아웃(Timeout) 설정: 타임아웃에 도달했을 때 어떤 일이 일어날지 미리 결정하세요. 요청이 계속 대기 상태로 머물게 두는 대신, 캐시된 폴백(Fallback), 더 작은 모델 사용, 또는 정중한 "다시 시도" 메시지 출력 등을 선택해야 합니다.
• 지수 백오프(Backoff)를 적용한 재시도 추가: 일시적인 오류에 대비해 재시도 로직을 추가하되, 횟수를 제한하세요. 과부하가 걸린 제공자(Provider)를 상대로 무한 재시도를 하는 것은 장애 상황을 더 악화시킬 뿐입니다.
• 서킷 브레이커(Circuit Breaker) 도입: 지속적인 장애가 발생할 경우를 대비하세요. 제공자가 명백히 다운된 상태라면, 모든 사용자를 30초 동안 기다리게 만드는 대신 빠르게 실패(Fail fast) 처리하고 폴백(Fallback)으로 전환해야 합니다.

이것들은 AI 전용 패턴이 아닙니다. 모든 외부 의존성(Dependency)에 적용하는 것과 동일한 회복 탄력성 공학(Resilience engineering)입니다. 흔히 하는 실수는 LLM을 마법처럼 취급하는 것입니다. LLM은 그저 타인의 서버로 보내는, 느리고 때때로 불안정한 네트워크 호출(Network call)일 뿐입니다.

레버 4: 실제로 변화를 만드는 지표를 측정하라

추적하지 않는 것은 최적화할 수 없습니다. 첫날부터 요청당 세 가지 수치를 기록하세요: 입력 토큰(Input tokens), 출력 토큰(Output tokens), 그리고 엔드 투 엔드 지연 시간(End-to-end latency). 이를 기능(Feature)별, 모델별로 태깅하세요. 일주일만 지나도 기능별 비용 및 지연 시간 분석 데이터를 얻게 될 것이며, 이는 거의 확실히 여러분을 놀라게 할 것입니다. 보통 예상치 못한 특정 엔드포인트 하나가 청구서의 대부분을 조용히 차지하고 있기 때문입니다.

유용한 파생 지표는 API 호출당 비용이 아니라, **성공적인 사용자 결과당 비용(Cost per successful user outcome)**입니다. 모델을 두 번 호출하더라도 실제로 사용자의 문제를 해결하는 기능이, 한 번만 호출하고 무시당하는 기능보다 모든 중요한 측면에서 더 저렴합니다.

사고방식의 전환

AI 기능을 지속 가능하게 출시하는 팀은 모델을 제품 그 자체로 생각하는 것을 멈추고, 대신 관리 책임이 있는 '비싸고 변동성이 큰 의존성(Dependency)'으로 생각하기 시작합니다. 프롬프트(Prompt)는 데모를 가능하게 하지만, 캐싱(Caching), 라우팅(Routing), 스트리밍(Streaming), 그리고 테일(Tail) 제어는 여러분이 계속 운영할 여력이 있는 실제 기능을 만들어냅니다.

이 중 어느 것도 생소한 것이 아닙니다. 이는 모든 외부 서비스를 프로덕션 환경에 적합하게 만드는 것과 동일한 규율입니다. 다만 그 대상이 단어 수에 따라 비용을 청구하고, 한 번에 토큰 하나씩 생각의 속도로 답변하는 서비스일 뿐입니다.