Cloudflare AI Search의 D1 지원: 빈 결과·삭제 반영·동기화 비용 점검

데이터베이스와 검색 인덱스 사이의 동기화·잔존 문서를 표현한 생성형 개념 이미지다. 실제 서비스 화면은 아니다.

FAQ를 비공개로 바꿨는데 AI 검색에서는 이전 답변이 계속 나온다면 어디부터 확인해야 할까. Cloudflare가 November 12, 2026 공개한 AI Search의 D1 데이터 소스 베타는 이 질문을 함께 검토하며 도입할 기능이다.

이제 읽기 전용 SQL의 결과 행을 문서로 색인하고, 주기적으로 변경을 반영할 수 있다. D1에 보관한 도움말·제품 설명을 검색에 연결할 때 별도 문서 내보내기 작업을 줄일 수 있다. 다만 원본 변경부터 검색 반영까지의 시간과 실패 처리는 운영자가 확인해야 한다. 공식 출시 공지

1. 검색에 내보낼 컬럼부터 좁힌다

다음은 공개 도움말만 선택하는 예제다. 검색에 필요 없는 내부 메모·연락처가 함께 들어가지 않도록 컬럼을 명시했다.

D1 연동 쿼리는 일반 SQL보다 제약이 많다. SELECT 또는 WITH로 시작하는 단일 읽기 전용 문장이어야 하고, 세미콜론·주석·바인딩 매개변수를 넣을 수 없다. 금지 문자열 검사는 문자열 리터럴에도 적용된다. ORDER BY와 LIMIT도 사용하지 않는다. 고유하고 비어 있지 않은 안정적인 id를 반환해야 한다. 위 예제에서는 article_id를 정수 기본 키로 두는 구성을 가정했다. D1 데이터 소스 문서

프로덕션 쿼리를 만들 때는 다음을 별도로 검토한다.

*SELECT 를 피한다. 나중에 운영용 컬럼이 추가돼도 검색 대상이 자동으로 넓어지지 않게 한다.

조인 후에도 id가 하나씩인지 확인한다. 태그 테이블과 일대다 조인하면 한 문서가 여러 행으로 늘어날 수 있다.

사용자 질문을 SQL에 이어 붙이지 않는다. 이 SQL은 검색 질의가 아니라 색인할 원본을 정하는 설정이다.

대표 한 행보다 전체 결과를 검토한다. 일부 행의 빈 ID·중복·과도하게 긴 본문은 정상 샘플 하나로 찾기 어렵다.

본문 SQL을 합성 데이터가 든 로컬 SQLite에서 실행해 공개 행 선택, 내부 메모 제외, 제목 변경 후 ID 유지, 한 행 비공개 전환, 전체 비공개 전환, 일대다 조인의 중복 ID를 확인했다. 이 검사는 SQL 결과에 대한 것이며 Cloudflare의 실제 동기화 테스트는 아니다.

2. 마지막 공개 행을 숨기는 경우를 꼭 시험한다

가장 주의할 조건은 쿼리 결과가 0행이 되는 경우다. 공식 오류 문서는 이를 d1_no_rows로 처리하며 기존 인덱스를 유지한다고 설명한다. 따라서 모든 행의 published를 0으로 바꿨다는 사실만으로 검색에서 모두 지워졌다고 판단하면 안 된다. 동기화 작업 오류

일부 행이 결과에서 빠지는 정상 동기화에서는 전체 결과를 읽은 뒤 해당 문서를 삭제한다. 그러나 전체 결과가 비었거나 쿼리가 실패하면 기존 항목을 보존한다. D1 동기화 동작

이를 바탕으로 다음 운영 방식을 권한다.

테스트용 공개 문서를 두 개 만든다.

하나만 비공개로 바꾸고 동기화 완료 후 검색·원본 인용에서 사라지는지 확인한다.

마지막 문서도 비공개로 바꾸고 작업 오류와 기존 검색 결과를 함께 확인한다.

긴급 철회가 필요한 데이터는 애플리케이션의 응답 차단 경로를 따로 마련한다. 해당 문서를 모델에 전달하기 전에도 현재 공개 상태를 확인하는 방식을 검토한다.

공식 문서는 전체 콘텐츠 제거 방법으로 인스턴스 삭제를 안내한다. 운영 인스턴스 삭제는 다른 저장 항목과 연결된 호출자에도 영향을 줄 수 있으므로, 데이터 범위·의존 서비스·복구 계획을 검토한 뒤 결정할 일이다. 여기서는 삭제나 설정 변경을 실행하지 않았다.

3. 동기화 요청 성공과 검색 반영을 구분한다

외부 데이터 소스의 기본 동기화 간격은 24시간이며, 15분부터 24시간까지 지정된 간격을 선택할 수 있다. 간격은 작업을 시작하는 주기다. 색인 완료까지 걸리는 시간은 콘텐츠와 처리 상황에 따라 달라진다. 동기화 설정

또한 검색 요청이 31일 동안 없으면 예약 동기화가 자동으로 일시 중지된다. 이때 기존 인덱스의 검색은 가능하다. 오래 쓰지 않던 도움말 검색을 다시 열 때는 최신 문서가 반영됐는지도 확인해야 한다.

API가 동기화 요청을 받아들인 뒤에도 항목 처리나 작업 전체가 실패할 수 있다. 원본의 D1 행을 수정했다면 소스 동기화 작업을 실행해야 한다. 개별 항목 재동기화만으로는 그 행을 다시 읽지 않는다. 색인 오류와 재시도 범위

배포 완료 기준은 다음처럼 잡는 편이 낫다.

설정 저장과 동기화 요청의 성공을 기록한다.

작업 이력과 항목 오류를 확인한다.

실제 검색에서 새 내용이 나오고 철회한 내용은 나오지 않는지 확인한다.

검색 결과를 사용하는 답변 생성·출처 표시까지 확인한다.

4. 변경된 행이 적어도 읽기 비용은 생긴다

D1 데이터 소스는 동기화마다 전체 쿼리 결과를 최소 두 번 읽는다. 변경되지 않은 문서의 재색인은 건너뛰지만, 원본 읽기가 없어지는 것은 아니다. 조회수처럼 자주 바뀌는 값을 반환하면 불필요한 재색인도 늘 수 있다. D1 권장 구성

예를 들어 결과가 항상 10,000행이고 15분마다 하루 96회 동기화한다면, 두 번씩 결과를 훑는 단순 계산만으로 1,920,000회의 결과행 방문이 된다. 이 숫자는 실제 청구 rows_read의 예측치가 아니다. 조건 검색·조인·인덱스에 따라 D1이 스캔하는 행 수는 달라진다.

D1의 rows_read는 반환 행이 아니라 읽은 행을 기준으로 한다. WHERE로 결과를 줄였어도 인덱스 없는 전체 스캔이면 읽기량은 클 수 있다. 운영에서는 D1 Metrics의 Row Metrics나 분석 API로 실제 사용량을 확인한다. D1 과금 지표

처음에는 공개된 소규모 데이터로 연결하고, 필요한 최신성에 맞춰 간격을 정하는 것이 좋다. 도입 전에 확인할 핵심은 내보낼 데이터의 범위, 마지막 행이 사라질 때의 처리, 검색 반영 지연, 실제 읽기량이다.

이 글은 한국 시간 November 13, 2026 확인한 공식 문서를 기준으로 작성했다. 베타 기능의 제약은 바뀔 수 있다. 실제 D1·AI Search 인스턴스 생성, 인증정보 발급, 유료 API 호출은 하지 않았다.