Cloudflare AI Search 사용법: 내 데이터에 검색 붙이기

Cloudflare AI Search는 내가 가진 문서 더미에 "AI가 읽고 답하는 검색"을 붙일 때 쓰는 서비스입니다. 이 글에서는 사내 매뉴얼이나 블로그 원고 같은 자기 데이터를 어떻게 올리고, 어떤 순서로 검색이 동작하며, 결과가 엉뚱할 때 어디를 먼저 의심해야 하는지를 정리합니다.

처음 이걸 붙여보는 분들이 가장 많이 오해하는 지점이 하나 있습니다. "문서를 넣으면 AI가 알아서 다 이해한다"고 생각하는 것입니다.

실제로는 문서를 자르는 방식, 검색해 온 조각의 개수, 질문 문장 자체가 결과를 크게 흔듭니다. 설정 화면을 클릭하는 순서보다 안에서 무슨 일이 벌어지는지를 아는 게 훨씬 중요합니다.

목차

1. AI 검색은 결국 "찾아서 읽히는" 구조입니다
2. Cloudflare AI Search가 대신 처리해주는 단계
3. 시작 전 확인해야 할 준비물
4. 데이터 연결에서 검색까지의 실제 순서
5. 결과가 엉뚱할 때 의심할 순서

AI 검색은 결국 "찾아서 읽히는" 구조입니다

AI에 내 데이터를 붙인다는 건 모델을 다시 훈련시키는 게 아니라, 질문할 때마다 관련 문서를 찾아 프롬프트에 끼워 넣는 것입니다. 이 방식을 RAG(Retrieval-Augmented Generation, 검색 증강 생성)라고 부릅니다.

비유하면 이렇습니다. 시험 보는 학생에게 교과서를 외우게 하는 대신, 문제를 볼 때마다 관련 페이지를 펼쳐 책상에 놓아주는 것입니다.

그래서 답변 품질은 "모델이 똑똑한가"보다 "펼쳐준 페이지가 맞는 페이지인가"에 더 크게 좌우됩니다.

질문 입력
   ↓
질문을 숫자 벡터로 변환
   ↓
문서 조각 중 가까운 것 검색
   ↓
찾은 조각 + 질문을 함께 모델에 전달
   ↓
근거 기반 답변 출력

여기서 "벡터"는 문장의 의미를 숫자 목록으로 바꿔놓은 것입니다. 의미가 비슷한 문장끼리 숫자상 거리가 가까워지기 때문에, 단어가 정확히 일치하지 않아도 찾아냅니다.

예를 들어 사내 문서에 "연차 소진 기준"이라고 적혀 있어도, 직원이 "휴가 남은 거 언제까지 써야 해요?"라고 물으면 같은 문서를 끌어올 수 있습니다. 키워드 검색이 못 하던 일이죠.

Cloudflare AI Search가 대신 처리해주는 단계

Cloudflare AI Search의 핵심 가치는 위 흐름에서 손이 많이 가는 중간 단계를 묶어서 관리해준다는 점입니다. 직접 만들면 최소 다섯 개 부품을 따로 붙여야 합니다.

단계	직접 구축할 때	관리형 서비스를 쓸 때
문서 수집	저장소에서 파일 읽는 코드 작성	데이터 소스 연결 설정
문서 쪼개기	청크 크기·겹침 직접 조정	설정값으로 조정
벡터 변환	임베딩 모델 선택·호출 관리	제공 모델 선택
벡터 저장	벡터 데이터베이스 별도 운영	내장 인덱스 사용
질의 응답	검색 + 프롬프트 조립 코드	검색·응답 엔드포인트 호출

"청크(chunk)"는 긴 문서를 검색 단위로 자른 조각입니다. 100페이지 PDF를 통째로 넣으면 필요한 한 문단만 뽑아낼 수 없으니, 몇백 자 단위로 잘라 각각 벡터로 만듭니다.

"엔드포인트"는 프로그램이 요청을 보내는 주소입니다. 웹사이트 URL과 비슷하지만, 사람이 아니라 코드가 방문한다고 생각하면 됩니다.

💡 관리형이라고 해서 설정이 필요 없지는 않습니다. 청크 크기, 가져올 조각 개수 같은 값은 여전히 내 데이터 성격에 맞게 손봐야 합니다.

시작 전 확인해야 할 준비물

일부 환경에서는 실패는 서비스 설정이 아니라 데이터가 준비되지 않은 상태로 시작하는 것입니다. 아래 항목을 먼저 점검하는 편이 시간을 아낍니다.

• ☐Cloudflare 계정과 대시보드 접근 권한
• ☐검색 대상 문서를 한 곳에 모아둔 저장소
• ☐문서 형식 확인 (텍스트·마크다운·PDF 등 지원 형식은 공식 문서에서 확인)
• ☐스캔한 이미지 PDF가 섞여 있지 않은지 확인
• ☐외부에 나가면 안 되는 개인정보·기밀 문서 분리
• ☐요금 체계와 무료 사용 범위를 공식 가격 페이지에서 직접 확인

세 번째와 네 번째가 특히 중요합니다. 스캔본 PDF는 사람 눈에는 글자로 보이지만 컴퓨터에는 사진입니다. 텍스트 추출이 안 되면 검색 대상에서 조용히 빠집니다.

마지막 항목도 넘기지 마세요. 서비스 요금과 포함 사용량은 시점에 따라 바뀌므로, 이 글의 숫자를 믿지 말고 Cloudflare 공식 문서와 대시보드에서 확인하는 게 맞습니다.

데이터 연결에서 검색까지의 실제 순서

작업 순서는 크게 네 단계입니다. 대시보드 UI는 바뀔 수 있으니 이름보다 "무엇을 하는 단계인가"를 기억하는 편이 낫습니다.

1단계, 저장소 연결. 검색시킬 문서가 들어 있는 저장 공간을 지정합니다. Cloudflare 환경이라면 자사 오브젝트 스토리지(파일을 통째로 보관하는 창고형 저장소)를 쓰는 구성이 가장 매끄럽습니다.

2단계, 인덱싱. 문서를 조각내고 벡터로 바꿔 저장하는 과정입니다. 이 단계는 문서 양에 따라 시간이 걸립니다. 진행 상태가 "완료"로 바뀌기 전에 질문을 던지면 결과가 비어 있을 수 있습니다.

3단계, 검색 테스트. 대시보드의 테스트 창에서 실제 질문을 넣어봅니다. 여기서 봐야 할 건 답변 문장이 아니라 어떤 문서 조각을 근거로 가져왔는지입니다.

4단계, 내 서비스에 연결. 챗봇이나 사내 도구에서 호출하도록 API로 붙입니다. API는 프로그램끼리 대화하는 창구이고, API 키는 그 창구를 여는 출입증입니다.

1. 저장소 연결
2. 인덱싱 (완료 대기)
3. 테스트 질의 → 근거 확인
4. API 연결
   ↑
문서 추가 시 2번으로 되돌아감

문서를 추가하거나 수정하면 인덱스도 갱신해야 합니다. 이걸 자동으로 돌릴지, 주기적으로 수동 실행할지는 초기에 정해두는 게 좋습니다. 나중에 "왜 새 매뉴얼 내용이 안 나오지?" 하고 헤매는 원인이 일부 환경에서는 여기입니다.

결과가 엉뚱할 때 의심할 순서

답변이 이상할 때 모델을 바꾸는 건 보통 마지막 선택입니다. 아래 순서로 확인하면 원인을 훨씬 빨리 좁힙니다.

증상	먼저 볼 곳	조정 방향
아무것도 못 찾음	인덱싱 상태, 파일 형식	텍스트 추출 가능한 형식으로 변환
관련 없는 문서를 가져옴	검색 결과 상위 조각	가져올 조각 수 조정, 문서 분리
문맥이 잘린 답변	청크 크기	조각을 키우거나 겹침 늘리기
오래된 내용으로 답함	인덱스 갱신 시점	재인덱싱 실행
없는 내용을 지어냄	프롬프트 지시문	근거 없으면 모르겠다고 답하게 명시

마지막 줄이 실무에서 제일 자주 쓰입니다. 모델에게 "제공된 문서에 없으면 없다고 답하라"고 명시하지 않으면, 그럴듯한 문장을 만들어냅니다.

문서 구조도 손볼 여지가 큽니다. 여러 제품 매뉴얼을 한 파일에 몰아넣으면 A 제품 질문에 B 제품 문단이 섞여 올라옵니다. 제품별로 파일을 나누는 것만으로 정확도가 올라가는 경우가 많습니다.

어떤 상황에 쓸 만한가

실무에서 이런 구성이 값을 하는 지점은 문서가 많고, 사람들이 계속 같은 걸 물어보는 상황입니다.

• 사내 규정·매뉴얼이 흩어져 있어 담당자에게 반복 문의가 들어오는 팀
• 제품 문서가 방대해 고객이 원하는 항목을 못 찾는 서비스
• 몇 년치 원고를 쌓아둔 블로그 운영자가 "이거 전에 쓴 적 있나" 확인할 때

반대로 문서가 몇 개뿐이라면 굳이 검색을 붙일 필요가 없습니다. 그 정도 양은 프롬프트에 그냥 붙여 넣는 게 더 빠르고 저렴합니다.

여기부터 손대면 됩니다

딱 하나만 가져간다면, 문서 품질이 검색 품질의 상한선이라는 점입니다. 서비스 설정을 아무리 만져도 원본이 뒤죽박죽이면 답변도 뒤죽박죽입니다.

그래서 첫 실습은 작게 시작하는 걸 권합니다. 문서 열 개 정도만 올려 인덱싱하고, 답이 뻔한 질문 다섯 개를 던져 근거 조각을 눈으로 확인해보세요.

그 다음에 문서를 늘리고, 청크 설정을 조정하고, API로 붙이면 됩니다. 요금과 지원 형식, 사용량 한도 같은 값은 반드시 Cloudflare 공식 문서에서 현재 기준으로 다시 확인하세요. 이 영역은 업데이트가 잦은 편입니다.

함께 보면 좋은 글

• Cloudflare x402 사용법: API를 유료로 파는 새 방식 정리
• Cloudflare Tunnel 끊김, 원인 진단과 재연결 자동화 정리
• Ollama 사용법 — 로컬에서 무료로 LLM 돌리기 입문