LLM 비용 폭탄 막는 법…아키텍처 최적화 5대 전략
기업은 지난 10년간 클라우드 청구서를 해독하기 위해 핀옵스 부서 전체를 구축하는 데 힘을 쏟았다. 유휴 컴퓨팅 인스턴스를 종료하는 방법을 막 터득하자마자, 생성형 AI가 훨씬 불투명하고 빠르게 변하는 새로운 지출 계층을 도입했다.
AI 청구 충격이 느리게 이동하는 허리케인처럼 산업 전반에 퍼지고 있다. 대규모 언어 모델(LLM) 비용 급등 외에도, 더 근본적인 아키텍처 문제는 비용 귀속(attribution)이다. 돈이 정확히 어디로 가고, 비즈니스에 정확히 어떤 가치를 전달하느냐는 질문이다.
API 호출이 자동화된 에이전트와 프롬프트 템플릿의 여러 겹으로 감싸이면, 애플리케이션은 토큰을 생성하기 위해 자본을 소모하는 블랙박스가 된다. 피처 엔진이 대규모 언어 모델로 하여금 인사말을 출력하거나 저가치 데이터를 처리하게 하는 데만 월 수천 달러를 태우고 있다면, 그것은 혁신이 아니라 덮개 없는 맨홀, 즉 심각한 부채다. 아키텍처 성숙도란 토큰을 여타 희소 자원과 동일하게 다루는 것을 의미한다.
다행히 AI 지출을 통제하기 위해 활용할 수 있는 몇 가지 유효한 레버가 있다. 다음은 AI 비용 문제를 길들이기 위한 다섯 가지 핵심 도구다.
모델 라우팅
압정만으로 충분할 때 굳이 못총까지 꺼낼 필요는 없다.
클로드 오퍼스 같은 최강급 모델은 지금까지 구축된 소프트웨어 시스템 가운데 가장 정교한 축에 속한다. 극도로 복잡하고 미묘한 사용례를 처리할 수 있는 반면, 컴퓨팅, 즉 비용 소비 측면에서는 가히 폭식성 야수에 가깝다. 대다수 상황에서 과도한 성능이다.
프로토타이핑 단계에서 API와 요구사항을 구체화할 때, 우리는 자연스럽게 가장 강력한 모델을 먼저 택한다. 일단 작동시키는 데 집중하다 보니 모델 한계와 씨름하고 싶지 않기 때문이다. 그러나 프로덕션 환경에서는 사용 가능한 최소 성능 모델이 무엇인지 정확히 파악하는 것이 절대적으로 필수적이다.
경우에 따라서는 모델 선택을 조정하고 수동으로 적합한 모델을 찾아내는 방식으로 해결할 수도 있다. 그러나 대규모 엔터프라이즈 아키텍처에서는 조건부 라우팅 레이어로 전환할 수 있다. 루트LLM(RouteLLM)이나 시맨틱 라우터(Semantic Router) 같은 프레임워크는 단순 분류, 기본 텍스트 파싱, 사용자 의도 탐지 같은 작업을 GPT-4o 미니나 클로드 3 하이쿠 같은 빠르고 저렴한 유틸리티 모델로 동적으로 라우팅할 수 있다.
라우팅과 지출 할당에 고급 AI 게이트웨이를 활용하는 방법도 있다. 인프라 레벨에서 콩(Kong), 클라우드플레어 AI 게이트웨이(Cloudflare AI Gateway), 포트키(Portkey) 같은 전용 AI API 게이트웨이에 이 로직을 감싸면 궁극적인 제어권을 확보할 수 있다. 성숙한 게이트웨이는 기본 대규모 언어 모델이 속도 제한이나 지연 급등에 부딪혔을 때 더 저렴한 모델이나 오픈소스 모델로 자동 폴백하는 ‘캐스케이드 라우팅(cascade routing)’을 구현할 수 있게 해준다. 더 중요한 점은, AI API 게이트웨이가 원격 측정 데이터를 중앙화해 블랙박스를 걷어내고 테넌트별 또는 마이크로서비스별로 엄격한 토큰 예산을 적용할 수 있게 한다는 것이다. 사실상 인지 작업을 위한 로드 밸런서를 구축하는 셈이다.
물론 AI 게이트웨이는 추가적인 복잡성과 비용을 수반하며, 두 요소 모두 반드시 고려해야 한다. 그러나 핵심은 프로젝트에 맞는 적정 규모의 모델이 존재한다는 것이다. 요청을 ‘충분히 좋은’ 골디락스(Goldilocks) 모델로 라우팅하면 상당한 비용을 절감할 수 있다.
참고로, 모델 라우팅의 또 다른 트렌드는 ‘컴퓨트 리패트리에이션(repatriation of compute)’, 즉 컴퓨팅 자원 회귀다. 클라우드에서 생성형 AI 엔드포인트를 임대하는 대신 로컬 하드웨어에서 모델(주로 오픈소스 모델)을 실행하는 방식이다. 온프레미스 옵션의 모든 트레이드오프와 이점이 그대로 적용된다.
시맨틱 캐싱
일반적인 웹 애플리케이션에서 캐싱은 이미 해결된 문제다. 데이터베이스 앞단에 레디스(Redis)를 두고 정확한 쿼리를 캐시된 페이로드에 매핑하면 그만이다. 그러나 대규모 언어 모델은 인간 언어가 무한히 다양하기 때문에 기존 캐싱 방식을 무력화한다. ‘비밀번호를 어떻게 재설정하나요?’와 ‘로그인 정보를 잊어버렸어요’는 완전히 다른 문자열이지만, 동일한 의도를 전달한다.
지나치게 정밀한 매칭에 의존하면 적중률이 사실상 0에 가까워지고, 모든 표현 변형마다 전체 토큰 비용을 지불하게 된다.
여기서 시맨틱 캐싱이 등장한다. 의미를 대상으로 하는 정규식(regex)과 같은 개념이다. 원시 텍스트 문자열을 해싱하는 대신, 입력 프롬프트를 빠른 임베딩 모델에 통과시키고 이전에 답변된 프롬프트와 유사도 검색을 수행한다. 신뢰도 임계값(예: 0.92)을 설정하고 조건이 충족되면 캐시된 응답을 반환해 대규모 언어 모델과 그 비용을 완전히 우회한다.
아키텍처적 효과는 두 가지다. 첫째, 시맨틱 캐시 적중은 추론 비용을 정확히 0으로 줄인다. 둘째, 응답 지연을 초 단위에서 밀리초 단위로 낮춘다. GPT캐시(GPTCache) 같은 전용 프레임워크를 사용하거나, 보다 간결한 인프라를 선호한다면 기존 포스트그레SQL(PostgreSQL) 데이터베이스 내 pgvector를 활용해 임베딩을 저장하고 매핑할 수 있다.
그러나 동적 라우팅과 마찬가지로, 시맨틱 캐싱도 엄밀한 아키텍처 계산을 요구한다. 생성 비용을 임베딩 및 조회 비용과 교환하는 구조다. 캐시를 확인하려면 여전히 프롬프트를 토큰화하고, text-embedding-3-small 같은 저렴한 모델을 호출하며, 벡터 검색을 실행해야 한다.
시맨틱 평탄화(semantic flattening)라는 실질적 위험도 수반된다. 유사도 임계값 조정은 섬세한 기술이다. 너무 낮게 설정하면 애플리케이션이 미묘한 사용자 질문에 일반적이고 재활용된 답변을 반환하기 시작한다. 개방형 창작 생성형 AI 애플리케이션에서 시맨틱 캐싱은 사실상 무용지물이다. 그러나 검색 증강 생성(RAG) 구현, 고객 지원 봇, 그리고 사용자가 동일한 20가지 질문을 1,000가지 방식으로 묻는 내부 지식 베이스에서는 활용 가능한 가장 효과적인 비용 절감 레버다.
프롬프트 캐싱
시맨틱 캐싱이 특정 의도에 대한 응답을 저장한다면, 프롬프트 캐싱은 질문을 맥락화하는 데 필요한 데이터를 저장한다. 사용자가 프롬프트를 입력하면 생성형 AI 엔드포인트로 전송된다. 그러나 애플리케이션이 RAG 파이프라인, 데이터베이스, 또는 다른 소스에서 프롬프트를 구성하는 데 필요한 방대한 맥락 정보를 반복적으로 수집해 전송하는 대신, 그 정보가 이미 컨텍스트 캐시에 로드돼 있다. 모델은 새로운 질문을 캐시된 데이터에 적용하기만 하면 되며, 지연 시간과 입력 비용을 대폭 절감한다.
프롬프트 캐싱의 핵심 개념은 AI 엔진 자체가 입력 프롬프트에 필요한 관련 맥락 데이터를 보유한다는 것이다. 이런 방식으로 캐시된 토큰은 원시 입력 토큰 대비 50%~90%에 달하는 대폭 할인을 받는다. 그러나 처리 방식의 세부 사항은 공급업체마다 다르다.
오픈AI의 경우 프롬프트 캐싱이 자동으로 적용되지만, 활용하려면 앱이 엔드포인트를 사용하는 방식에 주의를 기울여야 한다. 오픈AI는 1,024토큰 최소 임계값을 적용한다. 더 중요한 것은, 토큰 제로부터 시작하는 정확한 바이트 단위 접두사 매칭을 요구한다는 점이다. 시스템 지시문 최상단에 타임스탬프나 사용자 ID 같은 동적 변수를 삽입하면 캐시가 즉시 무효화되고, 이후 모든 토큰에 대해 전체 비용을 지불하게 된다.
앤트로픽의 클로드와 구글의 제미나이 같은 일부 공급업체는 명시적 캐싱을 사용한다. 생존 시간(TTL)이 정의된 전용 API 엔드포인트를 호출해 정적 문서(맥락 데이터)를 업로드하거나, JSON 페이로드에 엄격한 캐시 제어 중단점을 삽입하는 방식으로 캐시를 아키텍처에 의도적으로 설계해야 한다. 명시적 캐싱은 선불로 ‘쓰기 프리미엄(write premium)’을 지불해야 하는 경우가 많지만, 대용량 RAG 데이터를 몇 분이 아닌 몇 시간 동안 메모리에 유지할 수 있다.
프롬프트 규율과 리랭킹
모델이 막대한 양의 토큰을 소비할 수 있다고 해서 반드시 그래야 하는 것은 아니다.
현재 단일 프롬프트에서 100만~200만 토큰을 처리할 수 있는 모델이 등장하면서, PDF 전체, 코드베이스 전체, 또는 최근 3년치 로그를 페이로드에 그대로 쏟아붓고 대규모 언어 모델이 알아서 처리하게 하는 식의 무차별 대입 방식의 유혹이 생긴다.
이런 접근 방식은 핀옵스 측면에서 치명적인 실수다. 전송하는 모든 단일 토큰에 비용을 지불하는 구조이기 때문이다. 더구나 엔지니어링 관점에서 컨텍스트 윈도우를 가득 채우면, 모델이 콘텐츠 중간 부분의 해상도를 잃어버리는 ‘머디 미들(muddy middle)’ 문제, 일명 ‘컨텍스트 부패(context rot)’에 직면한다. 페이로드가 커질수록 성능과 정확도가 저하된다.
처방은 엄격한 RAG 다이어트다. 단순한 RAG 구현은 벡터 데이터베이스에서 상위 20개 결과를 가져와 무작정 프롬프트에 연결할 수 있다. 아키텍처 성숙도는 비싼 대규모 언어 모델에 토큰이 전달되기 전에 훨씬 가혹한 필터링 프로세스를 요구한다.
바로 여기서 리랭킹이 핵심이 된다. 리랭킹은 컴파일된 프롬프트 컨텍스트를 가져와 대규모 언어 모델에 전달되기 전에 효율적으로 구조화되도록 보장한다. 원시 검색 결과를 기본 모델에 직접 전송하는 대신, 코히어 리랭크(Cohere Rerank)나 오픈소스 BGE 모델 같은 소형 고효율 크로스 인코더를 도입한다. 저렴한 벡터 데이터베이스에서 폭넓게 50개의 후보 매칭을 가져온 뒤, 리랭커에 전달해 사용자의 특정 프롬프트와의 실제 관련성을 채점한다. 리랭커는 군더더기를 가차 없이 제거해, 비싼 프런티어 모델에는 가장 관련성 높은 상위 3~4개 청크만 전달할 수 있게 한다.
요약하면, 방대하고 비싼 대규모 언어 모델 컨텍스트 페이로드를 소형의 저렴한 리랭킹 단계와 교환하는 구조다. 아키텍처 수학적 관점에서 거의 항상 압도적인 승리다. 크로스 인코더가 파이프라인에 100밀리초의 지연을 추가할 수 있지만, 프롬프트 토큰 수를 80% 이상 일상적으로 절감하면서 최종 생성의 정확도를 동시에 높인다. 생성형 AI 지출 플레이북에서 대규모 언어 모델이 읽어야 할 내용을 줄이는 것은 활용 가능한 가장 레버리지 높은 조치라 할 수 있다.
응답 제약
기본적으로 대규모 언어 모델은 정중하고, 대화체이며, 장황하다. 모델에 데이터를 요청하면, ‘물론입니다! 요청하신 JSON을 준비했습니다’로 시작하고 ‘다른 도움이 필요하시면 알려주세요!’로 끝내고 싶어 안달이다.
웹 인터페이스에서는 매력적일 수 있지만, 애플리케이션의 API 아키텍처에서 이런 방식은 핀옵스 선체의 누수다. 생성 토큰(출력)은 거의 보편적으로 프롬프트 토큰(입력)보다 3~5배 높은 가격이 책정된다. 모든 인사말이 가장 비싼 자원을 태우고 있는 셈이다.
대규모 언어 모델 응답을 길들이려면 엄격한 API 레벨 적용이 필요하다. 첫째, max_tokens는 포맷팅 도구가 아니라 무분별한 생성 루프를 방지하는 강력한 차단기로 취급해야 한다. (max_tokens에 의존해 답변을 단축하면 잘리고 파싱 불가한 JSON이 나오는 경우가 다반사다.) 둘째, 정지 시퀀스(stop_words)를 사용해야 한다. 모델이 SQL 쿼리만 출력하면 되는 경우, 마크다운 닫기 태그(“`)나 ‘Explanation:’이라는 단어에 정지 시퀀스를 설정하면 연산 작업이 완료되는 즉시 연결을 끊도록 강제할 수 있다.
현대 API는 구조화된 출력(또는 엄격한 JSON 모드)도 지원하는데, 모델이 정의한 엄격한 스키마를 준수하도록 강제한다. ‘유효한 JSON만 출력하라. 모든 대화 텍스트와 인사말을 생략하라. 그렇지 않으면 시스템이 중단된다’는 무관용 시스템 프롬프트와 결합하면, 대규모 언어 모델이 챗봇이 아닌 전통적인 API 엔드포인트처럼 동작하도록 강제할 수 있다.
여기서 아키텍처적 균형은 입력을 엄격히 제한해 모델의 추론 능력을 저하시키지 않는 데 있다. 대규모 언어 모델은 내부 작업 메모리가 없으며, 토큰 출력을 반복함으로써 ‘사고’한다. 복잡한 논리 문제를 해결하게 하면서 먼저 추론할 공간을 주지 않고 단일 불리언(boolean) 참 또는 거짓만 출력하도록 강제하면 정확도가 급락한다. 핀옵스의 목표는 단어 수를 최소화하는 것이 아니라, 비싼 출력 토큰 하나하나가 체인오브소트(chain-of-thought) 추론 같은 실질적인 연산 작업을 수행하도록 보장하는 것이다.
