AI로 장소 검색 서비스 만드는 중입니다 (기술 2) — 기능마다 다른 모델: 비용·지연·품질을 표로
> 기술 1편에서 "로컬 LLM은 벽에 부딪혔고, 클라우드로 돌아가되 기능별로 다른 모델을 쓰기로 했다"고 했습니다. 이번 글은 그 라우팅의 근거가 된 실제 숫자 — 어떤 모델이 얼마고, 얼마나 빠르고, 어느 품질인지 — 를 표로 정리합니다.
> 요금은 벤더 공개가(Alibaba Model Studio / Gemini API, 2026-07 기준·변동 가능), 지연·품질은 유추카 자체 A/B 실측입니다.
왜 "한 모델로 통일"이 아니라 "기능별"인가
유추카가 LLM을 부르는 지점은 크게 여섯 군데입니다.
- extract — 영상 설명에서 장소 뽑기 (오프라인 배치, 대량)
- concept — 장소에 188개 의도 feature 점수 매기기 (오프라인 배치, 초대량)
- aspect·venue-style·review-summary — 속성/공간/리뷰요약 (오프라인 배치)
- query-parse — 검색어를 지역·업종·의도로 분해 (온라인, 검색마다)
- rerank — 후보를 재정렬·부적합 컷 (온라인, 검색마다·동기 병목)
- match-reason — "왜 이 결과가 맞는지" 한 줄 (온라인·비동기)
이들은 중요도·빈도·무게가 다 다릅니다. 파싱은 틀리면 검색 전체가 무너지지만 짧고, 컨셉 채점은 한 번 실수해도 티가 덜 나지만 6천 곳을 돌려야 합니다. "가장 좋은 모델 하나로 통일"하면 배치에서 파산하고, "가장 싼 모델 하나로 통일"하면 파싱에서 품질이 무너집니다. 그래서 세 축(비용·지연·품질) 을 각각 재고, 기능마다 다른 모델을 붙였습니다.
축 1 — 비용 (100만 토큰당, 입력/출력)
| 모델 | 입력 | 출력 | 메모 |
|---|---|---|---|
| qwen-flash | $0.05 | $0.40 | 최저가 (배치 분류·요약) |
| gemini-2.5-flash-lite | $0.10 | $0.40 | 채택 (리랭크·추출·컨셉·이유) |
| gemini-3.1-flash-lite | $0.25 | $1.50 | 2.5보다 빠르나 비용 ~3배(입력 2.5배·출력 3.75배) |
| gemini-2.5-flash | $0.30 | $2.50 | 출력비 6배·느림 |
| qwen-plus | $0.40 | $1.20 | 컨셉 채점 실험용 |
| text-embedding-v4(임베딩) | — | — | 질의당 ~$0.000002 · 코퍼스 재임베딩 ~$0.3/회 |
숫자를 규모로 옮기면 이렇습니다.
- 검색 1회: 질의 임베딩 ~$0.000002 + 리랭크 소량(입력 몇 천 토큰·출력 ~230토큰) = 1센트도 안 됩니다.
- 일회성 대량 배치가 진짜 비용: 컨셉(149종)을 전체 6,041곳에 채점 =
qwen-plus로 169분·약 $31(1회). 표본 631곳은 약 $0.5·5분. 코퍼스 전체 재임베딩 = ~$0.3(1회).
즉 운영비의 대부분은 "가끔 한 번 도는 배치" 이고, 사용자 트래픽 단가는 사실상 무시할 수준입니다. "AI 서비스는 부를 때마다 돈"이라는 막연한 공포와 달리, 실제로 아픈 건 초기 라벨링 배치 몇 번이었습니다.
축 2 — 지연 (리랭크 1회)
리랭크는 검색 응답을 붙잡는 동기 병목이라 지연이 가장 중요합니다. 엔드포인트 직접 프로빙(순수 LLM)과 앱 레벨(파싱+임베딩+리랭크 포함)을 둘 다 쟀습니다.
| 모델 | 순수 LLM 지연(3회) | 앱 레벨 | 평균 속도(A/B) |
|---|---|---|---|
| gemini-2.5-flash-lite | ~2.0초(2.0/2.2/2.0) | q1 3.2s / q2 3.5s | ~5초 |
| qwen-flash | ~2.5초(2.5/2.8/2.2) | — | ~10초 |
| qwen-plus | — | — | ~15초 |
| gemini-2.5-flash | ~9.8초(7.8/11.8/9.8) | — | ⚠️ thinking 오버헤드 |
| gemini-3.1-flash-lite | — | — | ~3.5초 (단 비용 3배) |
gemini-2.5-flash는 이름만 보면 상위 모델이지만, 답변 전에 '생각(thinking)'하느라 4~6배 느리고 변동도 큽니다. 게다가 어떤 질의에선 검색 이유(matchReason)를 전부 빈 값으로 반환하는 사고가 났습니다 — thinking 모드가 출력을 잠식해버려서, reasoning_effort: none을 강제해야 겨우 정상화됐습니다. 비싸고 느린데 결과물도 불안정 — 탈락.
> 참고: 초기에 "리랭크가 1초로, 8배 빨라졌다!"고 좋아했던 적이 있는데, 알고 보니 폐기된 모델명(gemini-2.0 계열)을 불러 404 → 폴백이 나면서 LLM을 아예 안 탄 착시였습니다. 실제 정직한 개선은 "2배쯤"입니다. (측정할 때 "너무 좋으면 의심하라"는 교훈.)
축 3 — 품질, 그리고 파싱만의 예외
리랭크 품질은 A/B에서 P@8(상위 8건 정밀도) 동등이 결론이었습니다(qwen-flash·flash-lite·flash 엇비슷, 부적합 컷 개수도 비등). 품질이 같다면 가장 싸고 빠른 걸 고르면 됩니다 → gemini-2.5-flash-lite. (Qwen-Flash는 matchReason이 가장 생생·구체적이라 품질 지향 대안으로 남겨뒀습니다.)
딱 한 곳 — 검색어 파싱(query-parse)만은 예외였습니다. 검색어를 지역·업종·의도로 쪼개는 이 단계에서 gemini-2.5-flash-lite는 8개 중 2개를 치명적으로 오분석했습니다:
- "역삼역 10분 이내 파스타" → 문장 전체를 상호명(NAME_SEARCH)으로 오인 → 지역·시간·업종 조건을 통째로 상실
- "스타벅스 강남" → 마찬가지로 통째 상호 검색으로 처리 → 지역(강남) 필터 소실
파싱은 모든 검색의 출발점입니다. 여기서 "파스타 맛집을 찾는 지역·시간 조건"이 사라지면 뒤 단계가 아무리 좋아도 엉뚱한 걸 찾습니다. 그래서 파싱만은 claude-haiku-4-5(상위 모델) 유지. "경량 모델은 빠르고 싸지만 복합 구문 분해에 약하다"가 실측 결론이었습니다. (반대로 규칙 기반 사전 분류기 QueryClassifier가 명백한 쿼리를 먼저 걸러 LLM 호출 자체를 줄이는 최적화도 함께 씁니다.)
최종 라우팅 — 기능 → 모델 → 근거
| 기능 | 모델 | 근거 |
|---|---|---|
| 검색어 파싱 | claude-haiku-4-5 | 신뢰성. lite는 복합 구문 8중 2 치명 실패 |
| 리랭크(재정렬·컷) | gemini-2.5-flash-lite | 동기 병목. ~5초·$0.10/$0.40·품질 동등 |
| 검색 이유(matchReason) | gemini-2.5-flash-lite | 비동기 UX (대안: qwen-flash, 생생함) |
| 컨셉 채점(188-feature) | gemini-2.5-flash-lite | 대량 배치 |
| 속성·공간·리뷰요약 | qwen-flash | 배치·최저가 |
| 임베딩 | text-embedding-v4 (2048d) | 교체 시 전체 재임베딩이라 고정 |
기각된 모델도 기록해 둡니다: gemini-2.5-flash(느림·비쌈·빈 reason), gemini-2.0 계열(404 폐기), gemini-3.1-flash-lite(빠르나 ~3배 비쌈), 로컬 리랭커 전부(cosine 못 이김 — 기술 1편), exaone3.5:7.8b(matchReason 지시 미준수).
갈아타기를 쉽게 만든 것 — 프로토콜 인지형 클라이언트
로컬(Ollama)과 클라우드(Gemini/Qwen)는 말하는 방식(API 프로토콜) 이 다릅니다. Ollama는 네이티브 /api/chat(+ think:false), 클라우드는 OpenAI 호환 /chat/completions(+ Bearer 인증)입니다. 그래서 LLM 클라이언트를 프로토콜을 알아서 구분하는 구조로 만들어, 프롬프트·JSON 파싱은 공유하고 엔드포인트만 바꿔 로컬↔클라우드를 오갈 수 있게 했습니다. 덕분에 "extract만 클라우드로, 나머지는 로컬 폴백" 같은 경로별 전환이 비파괴적이었습니다. 클라우드 경로엔 429·5xx(특히 Gemini 503)에 대한 지수 백오프 재시도(3회·500ms 시작) 를 붙여 일시 오류를 흡수했습니다.
보너스 — extract: 로컬 10시간을 클라우드 15분으로
영상 설명에서 장소를 뽑는 extract가 전환 효과가 가장 극적이었습니다.
로컬 qwen3:14b |
클라우드 gemini-2.5-flash-lite |
|
|---|---|---|
| 영상당 처리 | ~45초 | sub-second |
| GPU | 100% 점유 | 불필요 |
| 736영상 채널 총시간 | ~10시간 | ~15분 (실측 493영상, 초당 0.83건) |
| 품질 | 기준 | "구조화 설명 추출엔 동급 이상" |
| 영상당 비용 | 전기·밤잠 | 1센트 미만 |
반나절 배치가 커피 한 잔이 됐습니다. 게다가 클라우드 API는 로컬 GPU와 달리 동시성이 자유로워, 지금은 직렬인 추출을 병렬화하면 더 줄일 여지가 큽니다(로컬이었으면 GPU가 하나라 불가능).
이 글의 결론
- "모델을 크게"가 아니라 "기능별 적정 모델" — 파싱엔 좋은 모델(haiku), 리랭크·이유엔 싸고 빠른 lite, 대량 배치엔 최저가(qwen-flash).
- 검색 트래픽 단가는 1센트 미만, 비싼 건 일회성 배치뿐. AI 비용 공포의 실체는 "부를 때마다"가 아니라 "초기 라벨링 몇 번"이었습니다.
- 갈아타기를 쉽게 하려면 프로토콜을 추상화해 두는 게 결정적이었습니다.
다음 글(기술 3)부터는 이렇게 고른 모델들로 검색 품질을 어떻게 올렸는지를 기법별로 깊게 봅니다. 먼저 "임베딩이 못 잡는 걸 형태소로 잡은" 하이브리드 검색입니다.