실사용자 쿼리를 통한 자기 개선 멀티모달 검색 엔진 구축하기 - Curify
전통적인 검색 엔진은 정적 인덱스입니다. 세상이 그들을 채우기를 기다립니다. 에이전틱 워크플로우와 '바이브 코딩' 시대에 검색 시스템 구축은 BM25 또는 벡터 임베딩 최적화에만 국한되지 않아야 합니다. 자율 루프를 구축하여 학습하고 결정하며 자체 공급을 구축하는 것이어야 합니다. Curify에서는 최근 검색 바를 수동 검색 도구에서 자기 개선 멀티모달 엔진으로 변환했습니다. 이 게시물은 실제 사용자 데이터를 기반으로 한 에이전틱 루프를 어떻게 설계했는지에 대한 내부적인 시선입니다.
설정: 동적 공급망
엔진을 이해하려면 재고부터 시작하세요. Curify는 공개 웹을 인덱싱하지 않습니다. 설정은 매우 통제되고 결정적입니다:
콘텐츠 엔진: 수정 가능한 매개변수를 가진 수백 개의 구조화된 시각적 템플릿이 있으며, 고충실도 이미지 생성을 위해 Gemini API에 직접 연결되어 있습니다.
신호: 매일 실제 사용자 쿼리를 캡처하는 라이브 검색 제품입니다.
최적화 목표는 간단합니다: 검색 결과의 *풍부함* (공급 / 회수)과 *정확성*을 극대화하는 것입니다. 그러나 수동으로 가중치를 조정하는 대신, 우리는 라이브 사용자 쿼리를 동적이고 지속적인 평가 세트로 전환합니다. 각 저조한 쿼리는 훈련 신호가 됩니다. 이는 경량 하강의 의미가 아니라 에이전틱 결정의 의미입니다. 파이프라인은 쿼리가 실패한 *이유*를 추론하고 올바른 수정으로 라우팅합니다.
평가 → 추론 → 행동 루프
1단계: 실제 쿼리 캡처 (및 엣지 케이스 시뮬레이션)
Curify에서의 모든 검색은 쿼리와 즉각적인 결과를 캡처합니다: 클릭, 다운로드 또는 두려운 제로 결과 페이지. 이는 우리에게 실제 신호의 흐름을 제공합니다.
우리는 또한 *시뮬레이션된* 사용자 응답을 주입하여 실제 사용자가 도달하기 전에 엣지 케이스를 스트레스 테스트합니다. 이는 LLM 기반 에이전트가 카탈로그의 구석을 탐색하는 방식으로 작동하는 작은 합성 트래픽 생성기입니다. 실제 쿼리는 사용자가 실제로 필요로 하는 것을 드러내고, 시뮬레이션된 쿼리는 우리가 예상하는 패턴에 따라 그들이 *필요할* 것을 드러냅니다. 두 가지 모두 동일한 평가 파이프라인에 공급됩니다.
2단계: 각 저조한 쿼리 평가
낮은 풍부함이나 낮은 정확성을 제공하는 쿼리는 평가 노드를 촉발합니다. 평가자는 실제 참여 신호(클릭, 체류 시간, 다운로드)와 결과를 반환했지만 참여가 모호한 쿼리에 대한 Gemini 판단 관련 점수를 결합합니다.
평가자는 단순히 오류를 기록하지 않습니다. 에이전틱 질문을 던집니다: *이것은 공급 문제인가, 아니면 아키텍처 문제인가?* 이 분기는 루프의 핵심이며 다음에 어떤 두 가지 행동 경로가 실행될지를 결정합니다.
3단계: 결정 분기 — 콘텐츠 생성 (공급 수정)
평가가 사용자의 의도가 유효하다고 판단하면(예: '이중 언어 공룡 플래시 카드') 데이터베이스가 실제로 비어 있다면 시스템은 자율적인 생성자로 작동합니다.
행동: 쿼리 매개변수를 템플릿 엔진으로 라우팅하고, Gemini API를 트리거하며, 누락된 시각 자산을 일괄 생성합니다. 이는 정기 콘텐츠 배포를 지원하는 동일한 템플릿 기반 파이프라인으로, 이제 실패한 검색에 의해 요청됩니다.
다음 사용자(또는 시뮬레이션된 에이전트)가 동일한 검색을 실행할 때, 재고는 스스로 치유됩니다. 검색 엔진은 실제로 누락된 것을 구축했습니다.
4단계: 결정 분기 — 아키텍처 개선 (로직 수정)
콘텐츠가 존재하지만('T-Rex 교육 포스터') 사용자의 쿼리('쥐라기 학습 자료')가 이를 드러내지 못하면 엔진은 아키텍처의 간극을 표시합니다.
행동: 여기서 바이브 코딩이 그 가치를 발휘합니다. 개발자가 수동으로 정규 표현식 규칙을 작성하는 대신, 우리는 실패한 평가 사례를 Claude Code에 제공하고 다음을 요청합니다:
- 쿼리 재작성 규칙 업데이트
- 새로운 별칭 확장 생성
- LLM 의도 라우팅 프롬프트 개선
검색 파이프라인에 대한 아키텍처 수정은 실제 사용자 마찰 지점에 완전히 기반하여 몇 분 내에 배포됩니다. 엔지니어는 차이를 검토하며 루프에 남아 있지만, 에이전트는 가상의 쿼리에 대해 추측하는 대신 실제 사례에 대해 초안을 작성합니다.
이것이 대체하는 것
루프가 대체하는 세 가지 패턴:
수동 콘텐츠 보충: 전통적인 검색 팀은 '낮은 회수 쿼리'의 백로그를 유지하고 콘텐츠 위임을 통해 간극을 수정합니다. 지연은 몇 주가 걸리며, 많은 경우 채워지지 않습니다. 에이전틱 루프는 몇 시간 내에 간극을 메웁니다.
수작업 재작성 규칙: 검색 엔지니어가 키워드별 별칭을 작성하거나 형태소 사전을 유지합니다. 필요하지만 느리며, 새로운 쿼리 패턴이 나타날 때 규칙이 변동합니다. 바이브 코딩된 재작성은 사례 수에 따라 선형적으로 확장되며, 엔지니어 시간에 의존하지 않습니다.
정적 평가 세트: 한 번 작성되고 동결된 관련성 벤치마크. 실제 사용자 쿼리는 매주 변화합니다. 정적 평가 세트는 지난 분기의 현실을 측정하고 있습니다. 라이브 쿼리를 평가 세트로 취급함으로써 시스템은 사용자가 실제로 *이번 주* 검색하는 것을 최적화합니다.
Tools & Resources
Learn about the best tools available...
스택이 함께 연결되는 방법
에이전트 레이어로 연결된 네 가지 구성 요소:
검색 프론트엔드는 쿼리 + 참여 신호를 캡처하고 거의 실시간으로 평가자에게 전송합니다.
템플릿 엔진은 Curify의 Nano Banana 라이브러리입니다. 누락된 콘텐츠를 생성하기 위해 공급 측 분기가 호출하는 수백 개의 매개변수화된 시각적 템플릿입니다. 수동 콘텐츠 배포를 지원하는 동일한 엔진이며, 루프는 또 다른 호출자가 됩니다.
Gemini API는 이미지 생성(공급 측)과 관련성 점수(평가 측)를 모두 처리합니다. 단일 모델 패밀리, 두 가지 역할.
Claude Code는 아키텍처 측 업데이트를 처리합니다 — 재작성 규칙, 별칭 확장, 의도 라우팅 프롬프트. 에이전트는 실패한 사례에 대한 맥락과 기존 파이프라인 상태를 얻고, 차이를 반환하며, 엔지니어가 검토하고 배포합니다.
통합 비용은 예상보다 낮았습니다. 템플릿 엔진과 검색 프론트엔드는 이미 독립적인 시스템이었기 때문입니다. 에이전틱 루프는 우리가 이미 가지고 있는 도구 위에 있는 조정 레이어입니다 — 재작성하지 않고 — 그래서 우리는 며칠 내에 첫 번째 버전을 배포할 수 있었습니다.
오케스트레이션으로서의 검색
검색은 더 이상 단순히 검색과 순위 매기기가 아닙니다. 이는 오케스트레이션 문제입니다. 실제 사용자 쿼리를 단순한 메트릭이 아니라 에이전틱 의사 결정자의 활성 트리거로 취급함으로써, 우리는 스스로의 엔트로피와 적극적으로 싸우는 시스템을 구축했습니다.
Curify에서 검색 엔진은 더 이상 콘텐츠를 찾는 것만이 아닙니다. 콘텐츠가 누락되면 생성합니다. 로직에 결함이 있으면 수정합니다. 공급 측과 아키텍처 측 모두 동일한 신호에서 개선됩니다 — 어제 작동하지 않았던 쿼리입니다.
이것이 다음 세대 검색 시스템의 모델입니다: 더 큰 인덱스가 아니라 더 긴밀한 루프입니다.
Take the next step
Putting what you read into practice.
