서버리스 Postgres로 유명한 Neon이 흥미로운 벤치마크 결과를 공개했어요. 검색(retrieval) 작업에서 Castform이라는 오픈 모델 기반 구성이 OpenAI의 프론티어 모델인 GPT-5.6 Sol을 앞섰는데, 비용은 100분의 1 수준이었다는 내용이에요. “비싼 모델이 항상 낫다”는 통념에 정면으로 반박하는 결과라서 곱씹어볼 가치가 있거든요.
retrieval이 뭐길래 이렇게 중요할까요
요즘 LLM 서비스 대부분은 RAG라는 구조로 만들어져요. 이게 뭐냐면 Retrieval-Augmented Generation, 우리말로 하면 “검색으로 보강된 생성”인데요. 모델이 모든 걸 외우고 있는 게 아니니까, 질문이 들어오면 먼저 관련 문서를 찾아서(검색) 그걸 모델에게 건네주고 답을 만들게(생성) 하는 방식이에요. 사내 문서 챗봇, 고객센터 봇, 코드 어시스턴트까지 거의 다 이 구조죠.
여기서 핵심은, 검색 품질이 전체 답변 품질의 상한선이라는 거예요. 아무리 똑똑한 모델이라도 엉뚱한 문서를 건네받으면 엉뚱한 답을 하거든요. 그래서 파이프라인은 보통 이렇게 생겼어요. 먼저 문서를 임베딩(문장의 의미를 숫자 벡터로 바꾸는 것)해서 벡터 검색으로 후보를 수십 개 추리고, 그다음 리랭커(reranker)라는 모델이 “이 문서가 이 질문과 진짜 관련이 있나”를 따져서 순위를 다시 매겨요. 이 검색과 리랭킹 단계에 어떤 모델을 쓰느냐가 오늘 이야기의 핵심이에요.
왜 작은 모델이 이길 수 있을까요
“이 문서가 이 질문에 답이 되는가”를 판단하는 건 사실 굉장히 좁은 과제예요. 시를 쓰거나 코드를 짜는 범용 지능이 필요한 게 아니라, 관련성 판단이라는 한 가지 일만 잘하면 되거든요. 이런 과제는 작은 오픈 모델을 해당 작업에 맞게 파인튜닝(특정 작업에 맞춰 추가 학습시키는 것)하면 거대 범용 모델 못지않은, 때로는 더 나은 성능이 나와요. 마라톤 세계 챔피언에게 단거리 심판을 맡기는 것보다, 그 일만 훈련한 심판이 더 잘하는 것과 같은 이치죠.
비용 차이는 구조적이에요. 프론티어 모델을 리랭커로 쓰면 질문 하나를 처리할 때마다 후보 문서 수십 개를 통째로 입력해야 하니 토큰 비용이 폭발해요. 반면 파라미터가 몇 B 수준인 작은 모델은 자체 GPU나 저렴한 인프라에서 돌릴 수 있고, 응답 속도도 훨씬 빠르죠. 검색은 사용자가 기다리는 경로 한가운데에 있는 작업이라 지연시간이 곧 사용자 경험이거든요. 100배라는 숫자가 과장이 아닐 수 있는 이유예요.
업계 흐름에서 보면
이건 Neon만의 주장이 아니라 업계 전반의 흐름이에요. Cohere의 Rerank나 Voyage 같은 검색 특화 상용 모델이 이미 자리를 잡았고, 오픈소스 쪽에서도 BGE 계열이나 Qwen 임베딩처럼 작지만 검색에 강한 모델들이 벤치마크 상위권을 차지한 지 오래거든요. 더 큰 그림으로는 “모델 라이트사이징”이라고 부를 만한 움직임이 있어요. 모든 요청을 제일 비싼 모델에 보내는 대신, 쉬운 작업은 작은 모델이 처리하고 어려운 것만 큰 모델로 올리는 라우팅·캐스케이드 구조가 표준이 되어가는 중이에요. 데이터베이스 회사인 Neon이 이런 발표를 했다는 것 자체도 의미가 있는데요, pgvector를 앞세운 Postgres 진영이 벡터 검색을 넘어 검색 스택 전체를 데이터베이스 가까이로 끌어들이려는 흐름의 연장선이거든요.
한 가지 유의할 점도 있어요. 벤더가 공개하는 벤치마크는 자기에게 유리한 설정일 가능성을 늘 감안해야 해요. 어떤 데이터셋에서 어떤 지표로 측정했는지에 따라 결과는 얼마든지 달라지니까, 우리 데이터로 직접 재보기 전에는 절반만 믿는 게 건강한 자세예요.
우리에게 주는 시사점
RAG를 만들고 계시다면 오늘부터 점검해볼 게 있어요. 혹시 검색이나 리랭킹까지 전부 프론티어 모델 API로 처리하고 계신가요? 그렇다면 그 단계만 오픈 모델이나 검색 특화 모델로 분리해도 비용이 크게 줄어들 여지가 있어요. LLM 비용 때문에 기능을 축소하고 있는 팀이라면 더더욱요. 특히 데이터를 외부 API로 보내기 어려운 금융이나 의료 쪽이라면, 작은 오픈 모델은 셀프호스팅이 가능하다는 점에서 비용 이상의 의미가 있고요. “어떤 모델을 쓰지?”라는 질문을 “이 단계에 정말 이 크기의 모델이 필요한가?”로 바꾸는 습관, 이게 이번 발표의 진짜 교훈이에요.
정리하면, 검색이라는 좁은 과제에서는 잘 조련된 작은 오픈 모델이 프론티어 모델을 가격과 성능 모두에서 이길 수 있다는 실증이에요. 여러분의 파이프라인에서 “가장 비싼데 가장 덜 필요한” 단계는 어디인가요? 실제로 모델을 다운사이징해본 경험이 있다면 결과가 어땠는지도 궁금해요.
🔗 출처: Hacker News