🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Cloudflare의 AI Search는 에이전트가 필요한 정보를 적시에 모델에 제공하도록 하이브리드 검색, 내장 저장소·인덱스, 런타임 인스턴스 생성, 메타데이터 기반 랭킹 조정, 다중 인스턴스 검색을 제공하는 검색 기반 구성요소다.

📌 핵심 요약

• 글은 모든 에이전트가 검색을 필요로 한다는 문제의식에서 출발한다. 코딩 에이전트는 여러 저장소의 수많은 파일을 검색하고, 지원 에이전트는 고객 티켓과 내부 문서를 검색하지만, 본질적인 과제는 모델이 적절한 시점에 올바른 정보를 받게 하는 것이다.
• 기존에 직접 검색 시스템을 만들려면 벡터 인덱스, 문서 파싱·청킹·색인 파이프라인, 데이터 변경에 따른 인덱스 갱신 체계가 필요하다. 키워드 검색까지 필요하면 별도 인덱스와 결과 융합 로직도 만들어야 하며, 에이전트별 검색 컨텍스트가 다르면 이 구성을 반복해야 한다.
• AI Search는 이러한 검색 기능을 플러그앤플레이 방식으로 제공한다. 사용자는 Worker, Agents SDK, Wrangler CLI에서 인스턴스를 만들고 데이터를 넣은 뒤 검색할 수 있으며, 새 인스턴스는 자체 저장소와 벡터 인덱스를 갖고 API 업로드 파일을 자동 색인한다.
• 지원 에이전트 예시는 공유 제품 문서와 고객별 과거 해결 이력을 함께 검색하는 구조를 보여준다. 제품 문서는 공통 지식 기반으로 두고, 고객별 인스턴스에는 해결된 문제 요약을 저장해 이후 상담에서 반복된 실패를 피하고 재발 이슈를 인식하게 한다.
• AI Search의 핵심 개선은 벡터 검색과 BM25 키워드 검색을 병렬 실행하고 결과를 융합하는 하이브리드 검색이다. 벡터 검색은 의도를 잘 포착하지만 특정 오류 문자열을 놓칠 수 있고, BM25는 정확한 용어 매칭에 강하지만 의미적으로 유사한 문서를 놓칠 수 있어 둘을 함께 쓰는 구성이 강조된다.

🧩 주요 포인트

1. 글은 모든 에이전트가 검색을 필요로 한다는 문제의식에서 출발한다. 코딩 에이전트는 여러 저장소의 수많은 파일을 검색하고, 지원 에이전트는 고객 티켓과 내부 문서를 검색하지만, 본질적인 과제는 모델이 적절한 시점에 올바른 정보를 받게 하는 것이다.
2. 기존에 직접 검색 시스템을 만들려면 벡터 인덱스, 문서 파싱·청킹·색인 파이프라인, 데이터 변경에 따른 인덱스 갱신 체계가 필요하다. 키워드 검색까지 필요하면 별도 인덱스와 결과 융합 로직도 만들어야 하며, 에이전트별 검색 컨텍스트가 다르면 이 구성을 반복해야 한다.
3. AI Search는 이러한 검색 기능을 플러그앤플레이 방식으로 제공한다. 사용자는 Worker, Agents SDK, Wrangler CLI에서 인스턴스를 만들고 데이터를 넣은 뒤 검색할 수 있으며, 새 인스턴스는 자체 저장소와 벡터 인덱스를 갖고 API 업로드 파일을 자동 색인한다.
4. 지원 에이전트 예시는 공유 제품 문서와 고객별 과거 해결 이력을 함께 검색하는 구조를 보여준다. 제품 문서는 공통 지식 기반으로 두고, 고객별 인스턴스에는 해결된 문제 요약을 저장해 이후 상담에서 반복된 실패를 피하고 재발 이슈를 인식하게 한다.
5. AI Search의 핵심 개선은 벡터 검색과 BM25 키워드 검색을 병렬 실행하고 결과를 융합하는 하이브리드 검색이다. 벡터 검색은 의도를 잘 포착하지만 특정 오류 문자열을 놓칠 수 있고, BM25는 정확한 용어 매칭에 강하지만 의미적으로 유사한 문서를 놓칠 수 있어 둘을 함께 쓰는 구성이 강조된다.

🧠 상세 정리

1. 에이전트에게 검색이 필요한 이유

글은 에이전트의 활용 사례가 달라도 검색이라는 기반 문제가 공통으로 존재한다고 설명한다. 코딩 에이전트는 여러 저장소에 흩어진 수많은 파일을 찾아야 하고, 지원 에이전트는 고객 티켓과 내부 문서에서 관련 정보를 찾아야 한다. 중요한 것은 단순히 많은 문서를 검색하는 것이 아니라, 모델이 답변하거나 행동해야 하는 바로 그 시점에 필요한 정보를 제공하는 것이다. 이 관점에서 검색은 부가 기능이 아니라 에이전트가 실제 업무 맥락을 이해하기 위한 핵심 원시 기능으로 제시된다.

2. 직접 검색 시스템을 구축할 때의 복잡성

원문은 검색을 직접 만들 때 필요한 구성요소를 구체적으로 열거한다. 벡터 인덱스가 필요하고, 문서를 파싱하고 청킹해 색인하는 파이프라인도 필요하며, 데이터가 바뀔 때마다 인덱스를 최신 상태로 유지하는 체계도 갖춰야 한다. 여기에 키워드 검색까지 필요하면 별도의 인덱스를 만들고 벡터 결과와 키워드 결과를 합치는 융합 로직을 추가해야 한다. 특히 각 에이전트가 고유한 검색 컨텍스트를 가져야 한다면 같은 구조를 에이전트별로 반복 구축해야 하므로 운영 부담이 커진다.

3. AI Search가 제공하는 기본 가치

AI Search는 이러한 복잡성을 줄이기 위한 플러그앤플레이 검색 구성요소로 소개된다. 사용자는 동적으로 인스턴스를 만들고 데이터를 제공한 뒤 Worker, Agents SDK, Wrangler CLI에서 검색을 실행할 수 있다. 새 인스턴스에는 자체 저장소와 벡터 인덱스가 포함되며, API로 파일을 업로드하면 해당 파일이 색인된다. 원문은 별도의 R2 버킷을 먼저 준비하거나 외부 데이터 소스를 연결하지 않아도 된다는 점을 강조하며, 런타임에 인스턴스를 만들고 삭제할 수 있는 네임스페이스 바인딩도 함께 설명한다.

4. 하이브리드 검색과 내장 저장소·인덱스

AI Search의 주요 출시 내용은 하이브리드 검색과 내장 저장소·인덱스다. 하이브리드 검색은 하나의 질의에서 의미 기반 검색과 키워드 매칭을 동시에 수행하며, 벡터 검색과 BM25가 병렬로 실행된 뒤 결과가 융합된다. 내장 저장소와 인덱스는 새 인스턴스마다 제공되므로 사용자는 파일 업로드와 검색에 집중할 수 있다. 또한 문서에 메타데이터를 붙이고 질의 시점에 그 메타데이터를 사용해 순위를 조정할 수 있으며, 여러 인스턴스를 한 번의 호출로 함께 검색할 수 있다는 기능도 추가된다.

5. 지원 에이전트 예시의 구조

원문은 제품 문서와 고객별 이력을 함께 검색하는 지원 에이전트 사례를 통해 AI Search의 사용 방식을 보여준다. 공유 제품 문서는 모든 에이전트가 참조할 수 있는 공통 지식 기반으로 두고, 고객이 다시 문의할 때는 이전에 무엇을 시도했고 어떻게 해결했는지를 찾을 수 있도록 고객별 이력을 별도 인스턴스에 저장한다. 제품 문서가 컨텍스트 창에 모두 들어가기에는 너무 크고 고객 이력은 해결된 이슈가 쌓일수록 계속 늘어나므로, 관련 부분만 검색해 가져오는 방식이 필요하다. 이 구조는 공통 지식과 개인화된 고객 맥락을 동시에 다루기 위한 예시로 제시된다.

6. 고객별 인스턴스와 해결 이력 저장

고객이 처음 등장하면 지원 네임스페이스 안에 고객별 AI Search 인스턴스를 동적으로 만든다. 각 인스턴스는 자체 저장소와 벡터 인덱스를 가지며 처음에는 비어 있지만, 해결된 이슈의 요약이 저장되면서 시간이 지날수록 검색 가능한 과거 해결 로그가 된다. 에이전트는 문제를 해결한 뒤 무엇이 문제였고, 원인이 무엇이었으며, 어떻게 해결했는지를 요약해 해당 고객 인스턴스에 저장한다. 업로드와 색인 완료를 기다리는 방식이 사용되므로, 저장된 해결 기록은 다음 질의에서 바로 검색 가능한 상태가 된다.

7. Agents SDK에서의 도구 호출 흐름

예시 코드에서 지원 에이전트는 Agents SDK의 AIChatAgent를 확장하고 두 개의 도구를 정의한다. 첫 번째 도구는 제품 문서 인스턴스와 고객별 과거 해결 인스턴스를 함께 검색하는 search_knowledge_base이며, 고객 ID가 있으면 고객 인스턴스를 검색 대상에 추가한다. 두 번째 도구는 문제가 해결된 뒤 요약을 저장하는 save_resolution이다. 모델은 대화 상황에 따라 언제 검색하고 언제 저장할지를 결정하며, 도구 사용 루프는 일정 단계 수로 제한된다. 이 흐름은 검색과 메모리 축적이 에이전트 대화 안에서 자연스럽게 연결되는 방식을 보여준다.

8. 벡터 검색과 BM25가 보완하는 영역

원문은 기존 AI Search가 벡터 검색만 제공했지만, 벡터 검색만으로는 구체적 용어를 놓칠 수 있다고 설명한다. 예를 들어 사용자가 “ERR_CONNECTION_REFUSED timeout”을 검색할 때 임베딩은 연결 실패라는 넓은 의미를 잡아낼 수 있지만, 실제로 사용자가 찾는 것은 해당 오류 문자열이 포함된 문서일 수 있다. BM25는 질의어가 문서에 얼마나 자주 나타나는지, 전체 말뭉치에서 얼마나 희귀한지, 문서 길이가 어떤지를 고려해 점수를 매기므로 특정 용어가 포함된 문서를 찾는 데 강하다. 반대로 BM25는 같은 문제를 설명하지만 동일한 표현을 쓰지 않은 문서를 놓칠 수 있어, 벡터 검색과 함께 사용할 필요가 있다.

9. 검색 파이프라인의 설정 옵션

AI Search의 검색 파이프라인은 여러 단계로 구성되며 각 단계는 설정할 수 있다. 토크나이저는 색인 시 문서를 매칭 가능한 용어로 나누는 방식을 정하며, porter 옵션은 자연어 문서에서 어간을 맞추는 데 적합하고 trigram 옵션은 코드처럼 부분 문자열 매칭이 중요한 경우에 적합하다. 키워드 매치 모드는 질의 시 BM25 후보 문서를 어떻게 고를지 정하며, AND는 모든 질의어가 포함된 문서를 요구하고 OR은 하나 이상의 항목이 맞는 문서를 포함한다. 결과 융합에는 순위 기반의 reciprocal rank fusion과 더 높은 점수를 취하는 max 방식이 언급되며, 선택적으로 쿼리와 문서를 쌍으로 평가하는 리랭킹도 사용할 수 있다.

10. 메타데이터 기반 부스팅의 의미

원문은 관련성만으로는 충분하지 않은 검색 상황을 설명하며 메타데이터 기반 부스팅을 소개한다. 예를 들어 뉴스 검색에서 지난주 기사와 3년 전 기사가 모두 의미적으로 관련될 수 있지만, 사용자는 보통 더 최근 기사를 원할 가능성이 크다. AI Search는 모든 항목에 기본적으로 있는 timestamp나 사용자가 정의한 커스텀 메타데이터 필드를 기준으로 순위를 밀어올릴 수 있다. 지원 에이전트 예시에서도 검색 옵션에 timestamp를 내림차순으로 부스팅하는 설정이 사용되며, 이는 검색 결과 위에 업무 규칙을 얹어 실제 사용 맥락에 맞는 결과를 제공하려는 접근이다.

🧾 핵심 주장 / 시사점

• 원문이 강조하는 핵심은 에이전트의 품질이 모델 자체만이 아니라 검색 가능한 맥락을 어떻게 구성하고 최신 상태로 유지하느냐에 크게 좌우된다는 점이다.
• AI Search의 인스턴스 단위 설계는 공통 지식과 사용자·고객별 지식을 분리하면서도 한 번의 질의로 함께 검색하게 해, 다중 테넌트나 개인화된 에이전트 구조에 맞는 패턴을 제시한다.
• 하이브리드 검색, 리랭킹, 메타데이터 부스팅은 각각 의미 이해, 정확한 용어 매칭, 업무 우선순위를 보완하므로, 에이전트 검색에서는 단일 검색 방식보다 여러 신호를 결합하는 설계가 중요하다는 메시지가 드러난다.

✅ 액션 아이템

• 지원 에이전트나 코딩 에이전트에 검색 기능을 붙일 때, 공통 제품 문서와 고객별 해결 이력을 같은 인덱스에 섞지 말고 AI Search 인스턴스처럼 컨텍스트 단위로 분리할 수 있는지 점검한다.
• 오류 문자열·제품명처럼 정확한 용어가 중요한 문서와 의미 유사도가 중요한 문서를 구분해, 벡터 검색만 쓰는 대신 BM25와 결과 융합을 함께 실험한다.
• 파일 업로드·청킹·색인 갱신을 직접 운영하는 비용과 AI Search의 내장 저장소·벡터 인덱스·API 업로드 흐름을 비교해 구축 범위를 결정한다.
• 검색 결과의 최신성이나 고객 중요도처럼 관련성 외 업무 규칙이 필요한 경우, timestamp나 커스텀 메타데이터 기반 부스팅을 평가한다.

❓ 열린 질문

• AI Search의 인스턴스 단위 분리는 고객별 이력, 프로젝트별 코드베이스, 제품 문서처럼 서로 다른 검색 맥락을 얼마나 쉽게 운영하게 해줄까?
• 하이브리드 검색에서 벡터 검색, BM25, reciprocal rank fusion, 리랭킹 중 실제 품질에 가장 크게 기여하는 조합은 무엇일까?
• 고객 지원 에이전트가 해결 요약을 계속 저장할 때, 오래되거나 잘못된 해결 기록을 어떻게 만료·수정·감사해야 할까?
• 메타데이터 부스팅을 적용하면 최신성이나 고객 우선순위는 좋아질 수 있지만, 의미적으로 더 정확한 오래된 문서를 밀어내는 부작용은 어떻게 제어할 수 있을까?