AI 검색을 밑바닥부터 구축하기: 아무도 말해주지 않는 것들
요약
실제 서비스 운영 중 발생한 막대한 OpenAI 비용 문제를 해결하기 위해 AI 검색 인프라를 최적화한 경험을 공유합니다. 범용 모델 대신 워크로드에 특화된 저렴한 모델들을 활용하여 비용을 70% 절감하고 검색 품질을 높이는 전략을 다룹니다.
핵심 포인트
- 모든 검색 쿼리에 GPT-4o 같은 고비용 모델을 사용하는 것은 비효율적임
- 트래픽의 70%를 저렴한 모델로 분리하여 비용을 47,000달러에서 14,000달러로 절감
- DeepSeek, Qwen 등 특정 워크로드에 최적화된 모델 활용 권장
- 모델의 성능(Raw capability)보다 워크로드 적합성을 기준으로 모델 선택 필요
6개월 전, 저는 실제 사용자의 8% 정도만이 사용하는 검색 기능을 위해 매달 47,000달러에 달하는 OpenAI 청구서를 바라보고 있었습니다. 그 순간 저는 AI 검색 인프라를 진지하게 고민하기 시작했고, 이 주제에 관한 대부분의 가이드가 CFO(최고재무책임자)에게 LLM (Large Language Model) 비용 항목을 설명해 본 적도 없는 사람들이 작성했다는 사실을 깨달았습니다.
만약 여러분이 2026년에 검색 제품과 유사한 무엇인가를 구축하고 있다면, 이 글은 제가 첫 버전을 출시하기 전에 누군가 건네주었기를 바랐던 내용입니다. 저는 실제 수치, 실제로 중요했던 아키텍처 (Architecture) 결정, 그리고 우리 회사의 런웨이 (Runway) 4분의 1을 낭비하게 만든 실수들에 대해 이야기할 것입니다.
일반적인 LLM 호출이 함정인 이유
여기 아무도 피치 덱 (Pitch deck)에 넣지 않는 불편한 진실이 있습니다. 검색 워크로드 (Workload)를 위해 가공되지 않은 GPT-4o를 실행하는 것은, 고객들이 당연한 기본 사양 (Table stakes)으로 취급할 기능을 출시하는 가장 비싼 방법 중 하나라는 점입니다. 이 모델은 입력 토큰 100만 개당 2.50달러, 출력 토큰 100만 개당 10.00달러의 비용이 듭니다. 의미 있는 규모가 되면, 이러한 계산 방식은 단순한 범용 상호작용 (Commodity interaction)을 위해 결코 작동하지 않습니다.
Global API의 184개 모델 마켓플레이스는 제가 존재조차 몰랐던 대안들을 눈뜨게 해주었습니다. 가격대는 토큰 100만 개당 0.01달러에서 3.50달러 사이이며, 리더보드 (Leaderboard) 스크린샷을 믿는 대신 실제 특정 워크로드를 벤치마크 (Benchmark) 해보면 가장 저렴한 모델과 가장 비싼 모델 사이의 품질 차이는 예상보다 훨씬 좁다는 것을 알 수 있습니다.
우리는 약 3주 만에 검색 트래픽의 70%를 GPT-4o에서 분리했습니다. 나머지 30%는 여전히 모델의 가치를 증명할 수 있는 진정으로 어려운 추론 (Reasoning) 쿼리에 GPT-4o를 사용합니다. 이 단 하나의 결정으로 우리의 LLM 청구서는 47,000달러에서 약 14,000달러로 줄어들었으며, 더 저렴한 모델들이 우리가 던져주는 구조화된 검색 (Structured retrieval) 작업에 정확히 맞춰 튜닝되어 있었기 때문에 품질 점수는 오히려 올라갔습니다.
검색에 실제로 중요한 모델들
수십 개의 제공업체를 대상으로 내부 평가 스위트 (eval suite)를 실행한 결과, 제가 다른 창업자들에게 계속해서 추천하고 있는 모델은 다음의 5가지입니다. 이 모델들은 단순한 성능(raw capability) 순이 아니라, 검색 워크로드 (search workload)에 적합한 기본 설정값이라는 관점에서 정렬되었습니다.
DeepSeek V4 Flash — 입력 $0.27 / 출력 $1.10, 128K 컨텍스트 (context). 검색 쿼리의 대부분을 처리할 때 제가 사용하는 기본 모델입니다. 빠르고 저렴하며, 혼란 없이 구조화된 검색 (structured retrieval) 프롬프트를 처리합니다. 처리량 (throughput)이 매우 뛰어납니다.
DeepSeek V4 Pro — 입력 $0.55 / 출력 $2.20, 200K 컨텍스트 (context). 다중 문서 합성 (multi-document synthesis)을 위해 더 큰 컨텍스트 창 (context window)이 필요할 때 선택하는 상위 모델입니다. 여전히 서구권의 플래그십 (flagship) 모델들보다 훨씬 저렴합니다.
Qwen3-32B — 입력 $0.30 / 출력 $1.20, 32K 컨텍스트 (context). 컨텍스트 여유 공간 (context headroom)이 필요하지 않은 짧은 프롬프트에 대한 확실한 선택지입니다. 가격 경쟁력이 있으며 분류 (classification) 스타일의 작업에 매우 적합합니다.
GLM-4 Plus — 입력 $0.20 / 출력 $0.80, 128K 컨텍스트 (context). 제가 가장 좋아하는 "그냥 작동하면서 비용이 거의 들지 않는 것이 필요할 때" 사용하는 옵션입니다. 저희는 처리량이 많고 리스크가 낮은 쿼리 재작성 (query rewriting) 및 확장 (expansion) 작업에 이 모델을 사용합니다.
GPT-4o — 입력 $2.50 / 출력 $10.00, 128K 컨텍스트 (context). 최상의 추론 (reasoning) 능력이 진정으로 필요한 30%의 쿼리를 위해 남겨두는 프리미엄 티어 (premium tier)입니다. 저희 인프라 예산에서 "비싸지만 그만한 가치가 있는" 항목으로 이해하시면 됩니다.
이 5가지 모델의 내부 평가 스위트 평균 벤치마크 점수는 84.6%입니다. 실제로 저의 손익 계산서 (P&L)를 움직이는 핵심 수치는, 모든 작업을 플래그십 모델로 실행했을 때와 비교하여 확인한 40-65%의 비용 절감입니다.
지연 시간의 함정 (그리고 탈출 방법)
첫 번째 토큰 지연 시간 (first-token latency)은 저를 밤잠 설치게 만든 지표였습니다. 처음 출시했을 때 저희의 p95는 4.1초였으며, 제가 아는 모든 창업자는 "빠른" AI 기능이라고 만들었지만 결국 최악의 데이터베이스 쿼리보다 더 느려졌던 경험을 공유하곤 합니다.
두 달간의 최적화 결과, 현재 평균 지연 시간(latency)은 1.2초, 처리량(throughput)은 초당 320토큰에 도달했습니다. 이러한 개선의 거의 대부분은 세 가지 변화를 통해 이루어졌습니다.
-
모델 선택은 사람들이 생각하는 것보다 훨씬 중요합니다. 우리의 프롬프트 패턴(prompt patterns)에서는 DeepSeek V4 Flash가 GPT-4o보다 실제로 더 빠릅니다. 우리는 가장 유명한 모델을 사용한다는 이유로 지연 시간이라는 세금(latency tax)을 지불하고 있었습니다.
-
스트리밍(Streaming)은 타협할 수 없는 요소입니다. 응답을 스트리밍하기 시작하자, 전체 생성 시간이 동일함에도 불구하고 체감 지연 시간(perceived latency)이 400ms 미만으로 떨어졌습니다. 사용자는 첫 번째 토큰이 300ms 안에 나타난다면 2초의 응답 시간을 견뎌낼 것입니다.
-
프롬프트 구조는 예상보다 처리량(throughput)에 더 큰 영향을 미칩니다. 컨텍스트(context) 뒤에 지침(instructions)을 두는 대신 그 앞에 배치함으로써, 대규모 환경에서 요청당 측정 가능한 시간을 절약할 수 있었습니다. 수백만 건의 요청을 처리할 때는 모든 밀리초(millisecond)가 복리로 쌓입니다.
아키텍처: 벤더 종속(Vendor Lock-In)에 대한 나의 생각
이 부분은 초기 단계의 대부분의 팀이 위험할 정도로 잘못 판단하고 있다고 생각하는 AI 검색 인프라의 영역입니다. 그들은 특정 벤더를 선택하고, 애플리케이션 계층(application layer)에 SDK를 하드코딩하며, 6개월 뒤에 자신들이 벗어날 수 없는 가격 구조에 종속되어 있다는 사실을 깨닫게 됩니다.
현재 제가 검색 파이프라인을 구성하는 방식에는 세 가지 원칙이 있습니다.
SDK 계층이 아닌 HTTP 계층에서의 추상화(Abstraction). 저는 Global API의 엔드포인트를 가리키는 OpenAI 호환 클라이언트(OpenAI-compatible client)를 사용하며, 이는 모델을 교체하는 것이 설정 파일의 한 줄 변경만으로 가능하다는 것을 의미합니다. 이것이 제가 벤더 종속(vendor lock-in)에 대해 적극적으로 대비하는 이유이기도 합니다. 우리가 추가하는 모든 추상화는 단순히 코드를 "깔끔하게" 만드는 것이 아니라, 전환 비용(cost of switching)을 줄임으로써 그 가치를 증명해야 합니다.
어떤 제공업체가 응답했는지 상관하지 않는 라우팅 로직(Routing logic). 우리의 요청 라우터(request router)는 응답이 DeepSeek에서 왔는지 GLM-4에서 왔는지 알지 못하며 신경 쓰지도 않습니다. 오직 모델 문자열과 비용 등급(cost tier)만을 알 뿐입니다. 이는 애플리케이션 코드를 수정하지 않고도 새로운 제공업체를 대상으로 A/B 테스트를 수행할 수 있음을 의미합니다.
제공업체 변경에도 유지되는 텔레메트리 (Telemetry). 우리는 요청당 비용, 지연 시간 (latency), 그리고 품질 점수 (quality scores)를 추적합니다. 30% 더 저렴한 새로운 모델이 출시되면, 저는 설정 플래그 (config flag) 하나만 변경하고도 트래픽의 5%에 이를 배포하여 일주일 안에 결과를 비교할 수 있습니다.
우리 코드베이스에서 클라이언트 설정이 대략 어떻게 구성되어 있는지 보여드리겠습니다. 핵심은 베이스 URL (base URL)입니다. https://global-apis.com/v1을 사용한다는 것은 특정 제공업체가 아닌 통합 게이트웨이 (unified gateway)와 통신하고 있음을 의미합니다.
import openai
import os
from typing import Optional
...
이 4줄짜리 추상화 (abstraction)는 오후 한나절 만에 제공업체를 교체할 수 있느냐, 아니면 향후 2년 동안 레거시 SDK (legacy SDK)에 갇혀 있느냐를 결정짓는 차이입니다. 저는 팀들이 이 단계를 건너뛰었다가 수억 원의 비용을 허비하는 것을 보았습니다.
비용 최적화 플레이북 (프로덕션 준비 완료 버전)
AI 비용에 관한 모든 블로그 포스트는 "결과를 캐싱 (cache) 하라"고 말합니다. 하지만 실제로 무엇을 캐싱해야 하는지, 혹은 캐싱이 제대로 작동하는지 어떻게 측정해야 하는지는 거의 아무도 말해주지 않습니다. 여기 프로덕션 환경에 바로 적용 가능한 버전이 있습니다.
응답 (response) 레벨이 아닌 쿼리 임베딩 (query-embedding) 레벨에서 캐싱하세요. 전체 응답을 캐싱하는 것은 영원히 오래된(stale) 정보를 제공한다는 의미입니다. 쿼리 레벨에서 캐싱하면 기본 코퍼스 (corpus)가 변경되었을 때 이를 감지하고 지능적으로 무효화 (invalidate)할 수 있습니다. 우리는 이 방식을 도입한 지 한 달 만에 40%의 캐시 히트율 (cache hit rate)을 달성했으며, 검색 인프라 비용을 추가로 30% 절감했습니다.
쿼리 복잡도에 따라 라우팅 (Route) 하세요. 단순한 사실 확인 (factual lookups)은 $0.20/$0.80 가격의 GLM-4 Plus로 보냅니다. 다단계 추론 (Multi-hop reasoning)은 $2.50/$10.00 가격의 GPT-4o로 보냅니다. 대부분의 검색 워크로드 (workloads)는 사람들이 생각하는 것보다 훨씬 단순하기 때문에, 이 라우팅 로직만으로도 모두가 약속하지만 실천하지 못하는 50%의 비용 절감을 달성할 수 있습니다.
모든 것을 스트리밍 (Stream) 하세요. 지연 시간 섹션에서 언급했지만, 이는 비용에도 영향을 미칩니다. 사용자는 응답이 길어지면 이탈하며, 생성하지 않은 토큰 (tokens)은 비용을 지불하지 않아도 되기 때문입니다. 스트리밍은 사용자가 더 짧은 답변을 유도하게 만들어 세션당 총비용을 낮춰줍니다.
품질을 매의 눈으로 모니터링하세요. 사용자 만족도 점수, 클릭률 (CTR), 그리고 명시적인 좋아요/싫어요 (thumbs-up/thumbs-down) 신호를 추적하십시오. 저렴한 모델이 품질을 저하시키기 시작하는 즉시, 당신은 이를 즉각적으로 알아야 합니다. 우리는 품질이 기준치(baseline)보다 2% 이상 떨어지면 5분 이내에 자동으로 롤백 (auto-rollback)을 수행합니다.
우아한 성능 저하 (graceful degradation)를 구축하세요. 규모가 커지면 속도 제한 (rate limits)에 부딪히게 됩니다. 올바른 대응책은 폴백 체인 (fallback chain)을 만드는 것입니다. 선호하는 모델을 먼저 시도하고, 실패하면 더 저렴한 모델로 폴백하며, 그 다음에는 비-LLM (non-LLM) 검색 결과로 폴백하십시오. OpenAI가 운이 좋지 않다는 이유로 사용자에게 에러 페이지를 보여주는 일은 절대 없어야 합니다.
빠른 반복 (Fast Iteration) 마인드셋
반복 (iteration)의 속도는 초기 단계의 AI 제품이 가질 수 있는 유일하고 지속 가능한 경쟁 우위입니다. 모든 아키텍처 (architectural) 결정은 단 하나의 질문을 바탕으로 평가되어야 합니다: "다음 모델이 출시되었을 때, 내가 이것을 얼마나 빨리 바꿀 수 있는가?"
우리 인프라의 대부분에 대한 답은 "하루 미만"입니다. 새로운 모델이 Global API에 출시되었나요? 한 시간 이내에 우리의 스테이징 (staging) 환경에 반영되고, 피처 플래그 (feature flag) 뒤에서 작동하며, 당일 업무 종료 전까지 프로덕션 (production) 트래픽의 5%를 처리하고, 수치가 좋다면 일주일 이내에 완전히 배포됩니다. 그 반복 속도가 게임의 전부입니다.
제가 처음 우리 검색 시스템의 아키텍처를 설계했을 때, 공식 OpenAI SDK를 사용할지 아니면 자체 HTTP 클라이언트를 구축할지를 두고 이틀 동안 토론했습니다. 정답은 둘 다 아니었습니다. https://global-apis.com/v1을 가리키는 OpenAI 호환 클라이언트를 사용하는 것이 우리가 직접 HTTP 코드를 작성하지 않고도 벤더 유연성 (vendor flexibility)을 확보할 수 있는 방법이었습니다. 10분도 안 되는 설정 시간 만에, 우리는 그날 오후에 184개의 모든 모델을 테스트할 수 있었습니다.
다음은 우리가 실제로 라우팅 (routing) 결정을 어떻게 처리하는지 보여주는 약간 더 발전된 코드 스니펫입니다. 핵심은 모델 선택이 데이터 기반이며 변경하기 쉽다는 점입니다:
import openai
import os
...
MODEL_TIERS["standard"]라고 적힌 줄은 우리 회사의 월 비용을 3만 달러 절감해 준 줄입니다. 고민해 볼 가치가 있습니다.
실제로 중요한 ROI 계산법
재무 팀이 납득할 수 있는 방식으로 수치를 제시해 보겠습니다. 만약 귀사가 한 달에 5,000만 건의 검색 관련 LLM 호출 (LLM calls)을 수행한다면 다음과 같습니다.
순수 GPT-4o 스택: 당사의 평균 프롬프트 (prompt) 크기 기준, 월 약 $47,000 소요.
혼합 계층 (Mixed-tier) 스택: 동일한 호출 볼륨을 적절한 모델로 라우팅(routing)할 경우, 월 약 $17,000~$19,000 소요. 이는 월 $28,000~$30,000, 연간으로는 $336,000~$360,000의 절감 효과를 의미합니다.
설정 비용: 일주일 미만의 엔지니어링 시간 소요. 이는 절감액에 비하면 오차 범위 수준입니다.
ROI (투자 대비 수익)가 워낙 압도적이기 때문에, 검색 제품의 규모가 너무 작아 절대적인 절감액이 무의미한 경우가 아니라면 이를 실행하지 않을 이유가 없습니다. 검색이 인프라에서 실질적인 워크로드 (workload)가 되는 순간, 이것은 귀사가 할 수 있는 가장 가치 있는 최적화 작업이 됩니다.
만약 제가 오늘 다시 시작한다면 다르게 할 것들
만약 제가 지금 당장 AI 검색을 처음부터 구축한다면, 제가 거쳤던 "여러 제공업체를 직접 시도해 보는" 단계는 건너뛸 것입니다. OpenAI, Anthropic, Google 계정을 직접 개설한 다음, 즉시 Global API와 같은 통합 엔드포인트 (unified endpoint)를 통해 모든 것을 통합하겠습니다. 이는 철학적인 이유가 아니라 운영상의 이유 때문입니다. 하나의 빌링 (billing) 관계, 하나의 관측성 (observability) 스토리, 관리해야 할 하나의 속도 제한 (rate limits) 세트, 그리고 184개의 계약을 체결하지 않고도 184개의 모델을 테스트할 수 있는 능력을 갖추기 위함입니다.
또한, 저희가 했던 것처럼 6주 차가 아닌, 첫날부터 애플리케이션 계층 (application layer)에 비용 추적 기능을 구축할 것입니다. 쿼리당 비용 (per-query cost)을 실시간으로 파악하는 것은 기능 설계에 대한 사고방식을 바꿔 놓습니다. 저희는 지난달에 기능을 하나 추가했는데, 만약 쿼리당 비용에 미치는 영향을 미리 알았더라면 아마 출시하지 않았을 것입니다. 이러한 피드백 루프 (feedback loop)는 첫 배포부터 존재해야 합니다.
마지막으로, 모든 것에 가장 화려한 모델을 사용하고 싶은 유혹을 뿌리칠 것입니다. "작업에 적합한 모델을 사용한다"는 규율이야말로 연구 프로젝트와 프로덕션 준비가 된 시스템 (production-ready system)을 구분 짓는 핵심입니다. CFO는 당신에게 감사할 것이며, 사용자는 그 차이를 느끼지 못할 것입니다.
마치며
규모에 맞게 작동하는 AI 검색을 구축하는 것은 하나의 뛰어난 결정을 내리는 것보다 백 가지의 작은 결정들을 올바르게 내리는 과정에 가깝습니다. 모델 선택 (Model selection), 라우팅 로직 (Routing logic), 캐싱 전략 (Caching strategy), 벤더 추상화 (Vendor abstraction), 스트리밍 (Streaming), 모니터링 (Monitoring) — 이 중 어느 것도 개별적으로는 어렵지 않지만, 이들이 복합적으로 작용하여 동일한 사용자 경험에 대해 월 14,000달러의 청구서가 될 수도, 혹은 47,000달러의 청구서가 될 수도 있습니다.
https://global-apis.com/v1을 사용하는 통합 엔드포인트 패턴 (Unified endpoint pattern)은 운영 측면을 다룰 수 있게 만들어 주는 핵심입니다. 하나의 클라이언트, 184개의 모델, 벤더 종속성 (Vendor lock-in) 없음, 그리고 아침 커피를 다 마시기 전에 새로운 모델 통합을 배포할 수 있는 자유를 제공합니다.
만약 당신이 검색 기능이나 검색 집약적인 (Retrieval-heavy) AI 기능을 구축하고 있으며, 여러 벤더를 통합해야 하는 골칫거리를 피하고 싶다면 Global API를 살펴볼 가치가 있습니다. 이는 제가 패닉 상태에서 검색 인프라를 재작성할 때 존재했더라면 좋았을 추상화 계층 (Abstraction layer)이며, 덕분에 수많은 밤샘 작업을 피할 수 있었을 것입니다.
시간이 날 때 global-apis.com에서 확인해 보세요. 그리고 네, 100개의 무료 크레딧은 실제로 제공됩니다. 이 업계의 대부분
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기