쓰레기 데이터를 퍼다 나르는 AI? 구글 검색 그라운딩의 '저품질 출처' 차단용 도메인 필터링 노하우

2026-09-15 · 읽는 시간 약 9분

#개발자 도구

생성형 AI가 최신 정보를 기반으로 답변하도록 만드는 가장 대중적인 방법은 검색 증강 생성(RAG, Retrieval-Augmented Generation)입니다. 그중에서도 구글의 방대한 인덱스를 활용하는 ‘구글 검색 그라운딩(Search Grounding with Google Search)’은 실시간 트렌드 정보를 반영하는 데 있어 독보적인 성능을 자랑합니다.

하지만 실제 서비스를 운영해 본 개발자나 서비스 기획자라면 곧바로 심각한 문제에 직면하게 됩니다. 바로 “구글 검색 결과에 섞여 들어오는 쓰레기 데이터” 때문입니다. 광고판으로 도배된 티스토리 블로그, 기계가 자동 생성한 스크랩 사이트, 신뢰할 수 없는 커뮤니티의 악성 루머까지 AI의 콘텍스트(Context)로 유입되면서, AI가 마치 사실인 양 그럴듯한 거짓말(Hallucination)을 하는 현상이 발생합니다.

결국 고품질의 AI 서비스를 만들고 유지하기 위해서는 ‘검색 그라운딩 출처 필터링’ 기술이 필수적입니다. 검색 결과를 무작정 AI에게 주입하는 것이 아니라, 신뢰할 수 있는 도메인만 골라내거나 명백한 스팸 도메인을 사전에 솎아내는 정교한 필터링 노하우를 살펴보겠습니다.

왜 구글 검색 결과가 LLM을 망치는가? ’검색 오염’과 그라운딩의 한계

구글 검색 그라운딩은 LLM이 답변의 근거가 되는 참조 데이터(Grounding Sources)를 구글 검색 엔진에서 실시간으로 긁어오도록 지원하는 기능입니다.

여기서 발생하는 딜레마는 ’사람이 검색할 때 좋은 페이지’와 ’LLM이 읽었을 때 좋은 페이지’가 완전히 다르다는 점입니다. 구글 검색 상위에 노출되는 많은 테크 블로그나 정보성 사이트들은 고도의 SEO(검색엔진 최적화) 작업을 거친 경우가 많습니다. 이 중 상당수는 본문 내용은 부실하면서 키워드만 교묘하게 반복하거나, 타 사이트의 글을 기계적으로 짜깁기한 ’저품질 스팸 사이트’입니다.

인간은 이러한 페이지에 접속하자마자 어설픈 문장과 무수한 광고를 보고 “아, 낚였구나” 하며 바로 이탈하지만, AI는 다릅니다. AI는 전달받은 HTML 텍스트나 크롤링된 데이터 속에서 노이즈와 팩트를 명확히 구분하지 못하고, 그 저품질 텍스트마저 답변 생성의 ’진실한 근거’로 채택해 버립니다. 이것이 바로 검색 그라운딩 도입 시 반드시 별도의 출처 필터링 레이어를 설계해야 하는 이유입니다.

검색 그라운딩 출처 필터링의 두 가지 핵심 축: 화이트리스트 vs 블랙리스트

검색 그라운딩 출처 필터링을 구현할 때 가장 먼저 결정해야 하는 것은 **‘어떤 필터링 전략을 취할 것인가’**입니다. 서비스의 목적에 따라 화이트리스트(허용 목록) 방식과 블랙리스트(차단 목록) 방식을 적절히 선택하거나 혼합해야 합니다.

구분	화이트리스트(Whitelist) 방식	블랙리스트(Blacklist) 방식
개념	정부 기관, 주요 언론사, 신뢰할 수 있는 학술 사이트 등 허용된 도메인만 검색 근거로 사용	스팸 블로그, 악성 커뮤니티, 광고성 사이트 등 특정 도메인을 제외한 모든 검색 결과 허용
장점	- 환각 현상(Hallucination) 극도로 억제 - 답변의 높은 공신력 및 브랜드 안전성 확보	- 정보의 커버리지(Coverage) 극대화 - 실시간 핫토픽이나 트렌디한 정보 수집에 유리
단점	- 답변할 수 있는 정보의 범위가 좁아짐 - 화이트리스트 외의 도메인에만 있는 최신 정보 누락	- 끊임없이 생성되는 신종 스팸 도메인을 매번 차단하기 어려움
추천 시나리오	금융, 의료, 법률, 기업 내부 규정 안내 등 정확성이 생명인 도메인	트렌드 분석, 엔터테인먼트, 일반 상식 등 범용적인 Q&A 서비스

실무 아키텍처: Vertex AI 및 Gemini API 기반 그라운딩 필터링 구현법

먼저 짚어야 할 사실이 있습니다. Gemini의 내장 검색 그라운딩 도구(최신 모델은 google_search, 구버전인 Gemini 1.5 계열은 google_search_retrieval)는 검색 쿼리 생성부터 결과 수집, 본문 추출, 답변 생성까지 하나의 API 호출 안에서 종단간으로 처리됩니다. 개발자가 받는 grounding_metadata는 이미 답변이 만들어진 뒤 “이런 출처를 참고했다”고 알려주는 사후 결과일 뿐이라, 중간에 검색 결과를 가로채 걸러낸 다음 LLM에 다시 주입하는 구조 자체가 내장 도구로는 불가능합니다.

따라서 실무에서는 목적에 따라 아래 두 가지 중 하나를 선택해야 합니다.

방법 1. 내장 그라운딩을 그대로 쓰면서 네이티브하게 제외하기 특정 도메인만 빼고 싶은 정도라면, 구글 Gen AI SDK가 공식 지원하는 exclude_domains 매개변수를 그라운딩 도구 설정에 넣어주는 것으로 충분합니다. 별도 미들웨어 없이 API 호출 단에서 필터링이 적용됩니다.

방법 2. 화이트리스트나 정교한 재순위화가 필요하면 직접 RAG 파이프라인 구축 단순 도메인 제외를 넘어 화이트리스트 운영, 도메인 평판 조회, 컨텍스트 재구성처럼 세밀한 통제가 필요하다면, 내장 그라운딩 도구 대신 Google Custom Search API 등 별도의 검색 API를 직접 호출하고 그 결과를 필터링해 프롬프트에 수동으로 주입하는 자체(DIY) RAG 파이프라인을 구축해야 합니다. 이 경우의 대략적인 아키텍처는 다음과 같습니다.

[사용자 질문] ──> [1. 쿼리 최적화] ──> [2. 별도 검색 API 호출 (Custom Search 등)]
                                               │
                                       (검색 결과 URL 목록 반환)
                                               ▼
[AI 답변 출력] <── [4. LLM 컨텍스트 주입] <── [3. 도메인 필터링 엔진]
                                        - 블랙리스트 정규식 매칭
                                        - 화이트리스트 도메인 추출
                                        - 도메인 평판 데이터베이스 조회

1단계: 검색 결과에서 URL 파싱

검색 API가 반환한 각 결과의 URL로부터 호스트네임(Hostname)과 도메인을 파싱해 냅니다.

2단계: 정적/동적 필터 매칭

수집된 도메인을 사전에 정의한 규칙에 대입합니다. 단순히 example.com을 통째로 막는 방법 외에도, 특정 하위 경로(예: example.com/spam/*)나 서브도메인을 처리할 수 있는 정규표현식(Regex) 엔진을 거치게 합니다.

3단계: LLM 프롬프트 재구성 (Context Re-ranking)

필터링을 통과한 신뢰할 수 있는 도메인의 본문 텍스트만 직접 크롤링·추출하여 LLM의 프롬프트 콘텍스트에 수동으로 탑재합니다. 필터링 결과 남은 소스가 지나치게 적거나 없을 경우에 대비해 “신뢰할 수 있는 출처를 찾지 못했습니다”라는 예외 처리 답변(Fallback) 프로토콜을 마련해야 합니다.

이 방식을 도입했을 때의 실제 효과—스팸 도메인 제거 비율, 환각 감소 정도, 자체 크롤링 단계 추가로 인한 응답 지연—는 어떤 검색 API와 크롤링 방식을 쓰는지에 따라 크게 달라지므로, 일반화된 수치보다는 자신의 파이프라인에서 도입 전후로 직접 비교 측정해 보는 것이 정확합니다.

저품질 출처 차단을 위한 단계별 구축 체크리스트

효과적인 검색 그라운딩 출처 필터링 시스템을 구축하고 운영하기 위한 실무적인 체크리스트를 제안합니다.

초기 블랙리스트 시드(Seed) 확보
- 무단 불펌 후 광고만 넣은 미러링 사이트, 티스토리/네이버 블로그 중 자동 생성형 포스팅 비율이 높은 도메인 목록을 수집했는가?
서브도메인 및 와일드카드 처리 규칙 수립
- *.blogspot.com이나 *.tistory.com처럼 서비스 제공 도메인 내의 개별 유저 블로그를 선택적으로 차단하거나 허용할 수 있는 정규식 규칙을 마련했는가?
리다이렉션(Redirection) 우회 방지 구현
- 검색 결과에는 정상적인 도메인으로 보이지만, 클릭 시 스팸/광고 사이트로 강제 전환되는 도메인을 탐색하기 위해 Shortener URL 풀이 및 최종 Destination URL 검증 로직을 넣었는가?
폴백(Fallback) 메커니즘 설계
- 필터링 필터가 너무 촘촘하여 검색 결과가 모두 솎아내 졌을 때, 사용자에게 에러를 뱉는 대신 “신뢰할 수 있는 최신 출처가 없어 일반적인 지식을 바탕으로 답변합니다” 등의 안전장치를 설정했는가?

실무에서 마주하는 예외 상황과 해결책 (Q&A)

Q. 위키백과나 나무위키 같은 오픈 사전류 사이트는 차단해야 할까요?

A. 서비스의 ’신뢰성 가이드라인’에 따라 다릅니다. 기업용 보고서 작성용 솔루션이라면 위키류 사이트는 편향성과 가짜 정보 가능성이 높아 블랙리스트에 넣는 것이 안전합니다. 반면, 트렌디한 신조어나 대중문화 정보를 다루는 엔터테인먼트 성격의 챗봇이라면 오히려 위키백과와 나무위키가 훌륭한 출처가 되므로 **허용(Whitelist)**해야 합니다. 즉, 도메인 필터는 단일 고정값이 아니라 서비스의 페르소나와 결합하여 ’유연한 세트’로 관리되어야 합니다.

Q. 매일 새로 생겨나는 스팸 도메인을 수동으로 다 등록할 수는 없지 않나요?

A. 동적 필터링 기법을 도입해야 합니다. 도메인 자체의 평판 정보를 실시간으로 조회하는 외부 API(예: Google Safe Browsing API, Cloudflare Radar 등)를 미들웨어단에 연동하여, 도메인의 생성 일자가 너무 최근이거나 보안 위협 점수가 높은 도메인을 실시간으로 자동 차단하는 방식을 병행하는 것이 좋습니다.

Q. 출처 필터링을 빡빡하게 적용했더니 AI가 “정보를 찾을 수 없습니다”라는 답변만 반복합니다.

A. 검색 쿼리 자체의 품질(Query Formulation)을 점검해 보세요. 사용자의 질문을 검색 엔진에 그대로 던지기보다, LLM을 한 번 거쳐 ’정보성 사이트 위주로 검색할 수 있는 타겟형 키워드’로 변환(Re-writing)하여 검색 요청을 날리면 저품질 검색 결과 자체를 원천적으로 줄일 수 있습니다.

지속 가능한 AI 그라운딩을 위한 제언

구글 검색 그라운딩은 LLM의 시공간적 한계를 극복해 주는 최고의 도구이지만, 날이 갈수록 교묘해지는 웹상의 검색 오염(Search Engine Pollution) 앞에서는 양날의 검이 되기 쉽습니다. 단순히 최신 기술을 연결하는 것에 그치지 않고, 그 기술이 퍼다 나르는 데이터의 수질을 검사하고 정화하는 ‘검색 그라운딩 출처 필터링’ 아키텍처를 꼼꼼하게 갖추는 것만이 비즈니스 환경에서 실제로 쓸 수 있는 수준의 고품질 AI 서비스를 만드는 지름길입니다.

필터링 정책은 한 번 만들고 끝나는 정적 규칙이 아닙니다. 사용자 피드백과 생성 결과 모니터링을 통해 필터링 리스트를 지속해서 고도화해 나가는 운영 체계를 구축하는 것이 궁극적인 AI 서비스의 경쟁력이 될 것입니다.