LLM이나 RAG 시스템을 도입할 때 가장 먼저 하는 논의는 대개 모델 선택, 비용, 응답 품질이다. 데이터 출처를 어떻게 검증할지는 나중에 다루거나, 운영 단계에서 문제가 생기면 그때 보완하자는 식으로 미뤄지는 경우가 많다. 그런데 이 순서가 문제다.
모델이 학습하거나 검색해서 가져오는 정보의 신뢰성은, 시스템이 배포된 이후에는 사후 교정이 극도로 어렵다. 특히 RAG 파이프라인에서는 검색 문서의 품질이 곧 답변의 품질이기 때문에, 오염된 소스가 파이프라인 안에 있다면 모델이 아무리 잘 만들어져 있어도 틀린 정보를 자신 있게 출력한다.
이 글은 LLM·RAG 시스템을 도입하거나 내부 구축을 검토 중인 제품 관리자와 기술 의사결정자를 대상으로, 출처 신뢰성 설계를 요구사항 단계에서 어떻게 다뤄야 하는지 실행 순서와 계층별 설계 기준을 설명한다.
왜 출처 신뢰성이 요구사항의 문제인가
2024년 OpenAI가 공개한 보고서에 따르면, 러시아·중국·이란과 연계된 네트워크가 생성형 AI를 이용해 자동화된 계정과 유사 학술 아티클을 대규모로 유포했다. 이 콘텐츠는 웹에 반복적으로 노출되어 언어 모델의 학습 데이터 안으로 스며들 수 있다. 언어 모델은 통계적 빈도를 사실성의 신호로 해석하는 구조이기 때문에, 특정 정보가 많이 등장할수록 더 확실한 것처럼 응답에 반영된다.
이를 데이터 포이즈닝(data poisoning)이라 부른다. 학습 데이터나 검색 인덱스에 의도적으로 오염된 정보를 주입해 모델의 출력 방향을 바꾸는 공격이다. 단순한 오탈자나 날짜 오류가 아니라, 특정 해석이나 프레임이 정상적인 맥락처럼 보이게 설계된다는 점에서 탐지가 어렵다.
더 현실적인 위협은 악의적 공격이 아닌 경우에도 발생한다는 것이다. 품질 검증 없이 크롤링한 웹 데이터, 도메인 전문성이 없는 필자가 작성한 문서, SEO 목적으로 생성된 콘텐츠가 RAG 인덱스에 포함되면, 적대적 의도 없이도 오염된 합의가 형성된다. 이 문제는 시스템이 운영에 들어간 다음에는 어디에서 잘못된 정보가 유입됐는지 추적하기가 대단히 복잡해진다.
어느 계층에서 무엇을 설계해야 하는가
출처 신뢰성 설계는 단일 모듈이 아니라 파이프라인의 세 계층에 걸쳐 동시에 이루어져야 한다.
첫 번째 계층: 데이터 수집 단계의 소스 화이트리스트
RAG 시스템에서 검색 대상이 되는 문서 코퍼스를 구성할 때, 허용 소스를 사전에 정의하는 화이트리스트 방식이 기본 방어선이다. 모든 웹 콘텐츠를 동등하게 처리하지 않고, 도메인별로 신뢰 등급을 부여한다. 예를 들어 내부 정책 문서, 공식 규제 기관 자료, 검증된 학술 저널은 높은 신뢰 등급을 받고, 출처가 불분명한 블로그나 소셜 미디어 게시물은 낮은 등급 또는 제외 대상으로 처리한다.
이 단계에서 요구사항에 명시해야 할 항목은 다음과 같다.
- 허용 소스 목록과 등급 기준을 누가 정하고, 얼마나 자주 갱신하는가
- 새로운 소스가 추가될 때 승인 프로세스가 있는가, 아니면 자동으로 인덱싱되는가
- 소스의 도메인 권한(예: 공식 기관 여부, 발행 이력 검증 가능 여부)을 어떤 방식으로 확인하는가
두 번째 계층: 문서 수준의 메타데이터 검증
소스 등급만으로는 충분하지 않다. 신뢰할 수 있는 소스에서 가져온 문서라도 발행 시점, 최종 수정일, 저자 정보가 없거나 일관성이 없으면 해당 문서의 신뢰도는 별도로 낮춰 처리해야 한다.
구체적으로 설계해야 할 메커니즘은 다음과 같다.
- 발행일과 최종 수정일이 없는 문서를 검색 결과에서 낮은 우선순위로 배치하거나 제외하는 규칙
- 동일한 주제에 대해 같은 표현이 여러 소스에서 반복될 때 이를 독립적 근거가 아니라 복제 가능성으로 처리하는 중복 탐지 로직
- 문서의 내용이 급격히 변경됐을 때 알림을 발생시키는 버전 감시 체계
세 번째 계층: 응답 생성 단계의 출처 추적 가능성
모델이 응답을 생성할 때 어떤 문서를 참조했는지 추적할 수 있어야 한다. 이를 기술적으로는 출처 귀속(attribution)이라고 하며, 단순히 "참고 문서 목록을 보여준다"는 의미가 아니다. 응답의 특정 주장이 어느 문서의 어느 구간에서 왔는지를 파이프라인이 기록하고, 이를 사후에 감사할 수 있어야 한다는 뜻이다.
이 기능이 없으면 모델이 잘못된 정보를 출력했을 때 원인을 진단할 수 없다. 문서를 교체해도 같은 오류가 반복되는지, 아니면 문제가 해결됐는지 확인할 방법이 없다.
파인튜닝이 포함된 경우, 학습 데이터 감사가 선행되어야 한다
RAG가 아닌 파인튜닝(fine-tuning) 방식으로 도메인 특화 모델을 만드는 경우, 위의 세 계층에 더해 학습 데이터셋 자체의 감사 절차가 요구사항에 포함되어야 한다.
파인튜닝에 사용된 데이터는 모델의 가중치에 직접 반영된다. RAG처럼 검색 인덱스를 교체하면 되는 것이 아니라, 모델을 다시 학습시켜야 수정이 가능하다. 이는 훨씬 큰 비용과 시간을 요구하기 때문에, 학습 전에 데이터의 출처 분포와 품질을 검토하는 절차가 필수적이다.
감사 시 확인해야 할 기준은 다음 세 가지다.
첫째, 특정 관점이나 프레임이 과대 대표되어 있지는 않은가. 동일한 사건이나 개념에 대해 한 방향의 해석만 반복된다면, 모델은 그 해석을 기준선으로 학습한다.
둘째, 합성 콘텐츠(AI가 생성한 텍스트)가 어느 비율로 포함되어 있는가. 합성 콘텐츠 자체가 문제는 아니지만, 비율이 높고 품질 검증이 없으면 오류가 증폭된다.
셋째, 데이터의 시점 분포가 도메인 특성과 맞는가. 빠르게 변하는 도메인에서 수년 전 데이터가 과대 대표되면, 현재와 다른 정보를 기준으로 응답하게 된다.
운영 단계에서의 지속적 모니터링 구조
시스템이 배포된 이후에도 출처 신뢰성은 정적인 상태가 아니다. 검색 인덱스에 포함된 외부 소스는 시간이 지남에 따라 내용이 바뀌거나 소유자가 바뀌거나 저품질 콘텐츠로 채워질 수 있다.
운영 단계에서 필요한 구조는 크게 두 가지다.
하나는 소스 재검증 주기다. 인덱스에 포함된 외부 소스를 주기적으로 재평가하고, 신뢰 등급 기준에 미달하게 된 소스를 자동 또는 수동으로 제외하는 프로세스가 있어야 한다.
다른 하나는 이상 응답 탐지다. 모델의 응답이 내부 정책이나 도메인 기준과 어긋나는 방향으로 변화할 때 이를 조기에 감지하는 로그 분석 체계가 필요하다. 이 탐지는 모든 응답을 사람이 검토하는 방식으로는 운영할 수 없기 때문에, 응답의 출처 귀속 로그를 기반으로 통계적으로 이상한 패턴을 식별하는 자동화 모니터링이 현실적인 방법이다.
요구사항 문서에 빠지지 않아야 할 항목들
기획 단계에서 작성하는 시스템 요구사항 문서에 아래 항목이 없다면, 출처 신뢰성 설계는 구현 단계에서 우선순위 밖으로 밀릴 가능성이 높다.
- 허용 소스 기준과 승인 프로세스의 책임자 지정
- 문서 메타데이터 검증 규칙과 미달 시 처리 방식
- 응답 생성 시 출처 귀속 로그 저장 범위와 보존 기간
- 학습 데이터 또는 인덱스 데이터의 감사 주기와 담당 역할
- 소스 신뢰도 등급 변경 시 기존 인덱스 처리 절차
이 항목들은 보안 요구사항 섹션이 아니라, 데이터 파이프라인 설계 요구사항 안에 포함시켜야 한다. 보안 섹션에 배치하면 구현 우선순위가 실제 파이프라인 구조 결정보다 나중으로 밀리는 경우가 많다.
