어제 Spotify가 자체 고속 검색 메커니즘인 Parallel Fusion Router를 소개하는 발표를 봤음. 이 역시 학습 기반 검색으로, 교사 LLM이 훨씬 작은 라우터 LLM에 검색 방법을 가르치고 LLM을 평가자로 쓰는 보상 함수를 활용함.
내 경험상 Apple이나 Spotify 등의 이런 방법은 수억 개 이상의 항목에서 상위 5개의 관련성을 극도로 높여야 하는 초대규모 환경에 주로 적합함. 수백만 개 이하에서는 BM25 색인을 만들고 LLM에 검색 도구로 제공해 후보를 넓게 찾는 방식이 학습 기반 방법보다 매번 나았음. 다만 논문으로 발표하기에는 후자가 RecSys나 ICML에 더 잘 맞음.
[1] https://research.atspotify.com/2025/9/you-say-search-i-say-r....
지난 RAG 프로젝트에서 정확히 이 방법을 썼는데, 작은 데이터셋에서는 아주 잘 작동함.
오래전부터 같은 얘기를 해왔음. 최첨단 LLM이 검색어를 생성하면 어휘 기반 검색도 의미 기반 검색과 거의 같아짐.
검색 순위 산정이 아무리 좋아도, 검색 기반 접근은 결국 도메인 이해도가 훨씬 낮은 휴리스틱 시스템의 결과에 LLM을 편향시키는 듯함. 속도와 품질 사이의 절충이겠지만, 내 경험상 LLM이 그런 편향 없이 직접 탐색하게 하면 최종 결과물의 품질이 대체로 훨씬 좋아짐.
자주 간과되는 부분임. RAG가 LLM의 지능을 옛날 Google 검색 결과 수준으로 떨어뜨릴 수 있음.
코드베이스에 적용할 만능 RAG를 만드는 데 많은 시간을 썼지만, 임베딩 모델이나 BERT가 grep을 능가할 만큼 잘 작동하는지는 여전히 확신이 없음. 대부분의 모델은 AI가 던지는 질문의 핵심을 제대로 파악하기에는 너무 작고, AI가 아주 기초적인 것만 검색하도록 제한하면 결국 grep과 정규식으로 돌아온 셈임.
검색에 걸리적거리는 테스트 파일, 문서, 의미상 겹치는 부속 파일 등을 제거하지 않으면 검색 결과가 테스트로 채워지기 쉬움. 기업용 문서 저장소라면 괜찮겠지만, 코드베이스에 한 번 적용하면 끝나는 범용 해법으로는 대체로 부족함.
아주 큰 임베딩 모델을 쓰려면 대부분의 업무용 컴퓨터에서 제대로 돌리기 어려워 클라우드가 필요함. 그럴 바에는 임베딩 모델을 빼고 언어 모델을 하위 에이전트로 써서 미리 탐색하게 하는 편이 나음.
Apple은 시장이 어떻게 발전하는지 기다렸다가 더 나은 제품으로 진입해 결국 지배하는 흥미로운 역사가 있음. iPod과 iPhone이 그런 예인데, ChatGPT가 장악하려는 개인 AI 비서 시장에서도 이를 재현할 기반을 쌓고 있을 수 있음.
iPhone에서 일정 부분 로컬 추론을 수행해 소비자가 원하는 AI 서비스 대부분을 제공하려고 조용히 준비하는 장기적 접근이 흥미로움. 로컬 추론으로 서비스 가격을 크게 낮추고, 거대한 생태계와 개인정보 보호를 내세우면 개인 AI 비서 구독 시장에서 강력하게 경쟁할 수 있음.
Apple은 이미 성능이 떨어지는 Siri로 이 시장에 일찍 진입한 것 아닌가?
수년간 iPhone과 MacBook Pro를 써왔지만 새 기기를 설정할 때마다 가장 먼저 Siri 관련 제안을 모두 거절하고 추가 설정도 꺼버림. 내가 아는 한 Siri는 없는 것보다 못하고, 쓰지 않은 걸 후회한 적도 없음.
다만 최첨단 모델 시장에 직접 진입하지 않고 어떻게 해낼지는 궁금함. 새 foundation models CLI를 내려받아 Mac에서 추론을 돌려봤는데, 성능은 별로였지만 직접 돌아가는 모습은 흥미로웠음. 어떤 모델을 쓰느냐고 물으니 gpt 4o mini라고 답함. 기기 내에서 작동하는 완전히 비공개인 AI 비서는 지금 Apple과 제휴한 최첨단 모델 제공업체들을 실질적으로 위협할 만큼 큰 시장이 될 수도 있다고 봄.
그건 Apple의 역량이었을까, Steve Jobs의 역량이었을까? 그가 없는 Apple은 그런 일을 해내지 못했으니 Steve Jobs가 해낸 일처럼 보임.
RAG에 대한 열광에서 벗어나는 중인데, 동료가 던진 “그냥 grep을 쓰면 안 되나?”라는 질문이 계속 머릿속에 남아 있음.
grep은 임베딩처럼 의미 기반으로 검색하지는 않음. 다만 LLM이 개념을 여러 개의 문자열 검색으로 확장하면 비슷한 효과를 낼 수 있음.
grep이 가장 빠른 작업도 많지만, 실제 서비스용 RAG에서는 혼합형 벡터 검색처럼 의미나 서로 다른 언어, 오타를 처리하며 검색할 수 없음. 분산 서버에 저장된 테라바이트 규모의 문서를 1,000ms 이내에 검색하려 할 때도 확장성에 한계가 있음.
정보 검색 자체가 하나의 연구 분야임. 잘 구조화된 일반 텍스트 데이터셋에서는 기본 필터링만으로 의미 기반 검색이나 어휘 기반 검색만큼 좋은 결과를 낼 수도 있음. 무엇이 필요한지는 측정해 봐야 알 수 있음.
AI가 grep을 잘못 쓰다가 내 변경 사항을 날린 적이 너무 많음. Git과 AI 훅 기반 차단 장치, 그리고 RAG가 있어서 다행임.