대부분의 RAG 문제는 검색(Retrieval) 문제다

대부분의 RAG 블로그 포스트들은 마치 제품 브로슈어처럼 읽힙니다. 지난 몇 달 동안 여러 시스템을 구축하고 너무나 많은 운영 사후 분석(post-mortems) 보고서를 읽은 결과, 저는 보통 LLM이 가장 먼저 고장 나는 요소가 아니라는 점을 꽤 확신하게 되었습니다.

특히 EU 중견 기업(mid-market) 배포 환경에서는 더욱 그렇습니다.

제가 반복해서 목격하는 몇 가지 실패 모드(failure modes)는 다음과 같습니다:

1. 검색(Retrieval) 품질이 문서 1만 개에서 4만 개 사이에서 무너짐

500개의 PDF로 진행하는 데모는 놀라워 보입니다.

하지만 첫 번째 실제 파일럿이 시작되고, 누군가 SharePoint에서 3만 개의 문서를 업로드하면 갑자기 상위 3개(top-3) 검색 결과가 반쯤 무작위로 변합니다.

전형적인 예시:
쿼리는 Lieferantenbewertung 2024입니다.

검색 결과로 돌아오는 것들:

• 2019년의 공급업체 평가 양식

3. 환각 (Hallucinations)은 실제 운영상의 문제가 아니다

모든 이해관계자가 묻습니다:
“환각 (Hallucinations) 문제는 어떻게 하나요?”

하지만 거의 아무도 묻지 않습니다:
“만약 소스 자체가 오래된 것이라면 어떡하죠?”

제가 본 바로는, 이것이 더 많은 파일럿 프로젝트를 무산시킵니다.

모델은 완벽하게 근거가 있는 답변을 내놓습니다.
올바른 문서를 인용합니다.
단지 그 문서가 더 이상 유효하지 않을 뿐입니다.

혹은 더 나쁜 상황도 있습니다:
두 개의 유효한 문서가 서로 상충하고, 시스템이 확신을 가지고 그중 하나를 선택하는 경우입니다.

해결책으로 보이는 것들:

• 검색 점수 산정 시 최신성 감쇠 (recency decay) 적용
• 검색된 청크 (chunks) 간의 모순 체크
• 신뢰도 임계값 (confidence thresholds) + 인간의 개입 (human handoff)

많은 “환각 문제”는 사실 가짜 콧수염을 붙이고 있는 검색 (retrieval) 문제일 뿐입니다.

4. 권한 문제는 매우 빠르게 재앙이 된다

이 문제는 기본적으로 모든 내부 배포 스레드에서 나타납니다.

어시스턴트가 사용자가 절대 봐서는 안 될 인사 (HR) 스프레드시트나 급여 내역 추출 파일을 사용하여 실수로 답변을 해버리는 상황입니다.

기술적인 해결책은 간단합니다:
의미론적 검색 (semantic retrieval) 이전에 권한 필터링 (permission filtering)을 수행하는 것입니다.

현실은 이렇습니다:

• SharePoint 권한 설정이 너무 오래됨
• 메타데이터 (metadata) 누락
• 더 이상 문서 소유자가 누구인지 아무도 모름
• 법무팀은 IT 부서에 문의하라고 함
• IT 부서는 부서장에게 문의하라고 함
• 부서장은 2021년에 퇴사함

EU 환경에서는 이것이 훨씬 더 성가신 문제가 됩니다. GDPR 때문에 이것이 단순한 “실수”에서 보고 대상이 될 수 있는 사고 영역으로 변하기 때문입니다.

솔직히 말해서, 고객이 누가 무엇에 접근해야 하는지를 설명할 수 있기 전까지는 저는 더 이상 파일럿 프로젝트를 시작조차 하지 않을 것입니다.

5. 재임베딩 (Re-embedding) 비용은 엄청나게 과소평가되어 있다

모두가 첫 번째 임베딩 (embedding) 실행 비용은 예산에 반영합니다.

하지만 거의 아무도 다음 사항들을 예산에 반영하지 않습니다:

• 일일 델타 업데이트 (daily delta updates)
• 모델 업그레이드 후의 재임베딩 (re-embedding)
• 벡터 저장소 (vector storage)의 성장
• 멀티 벡터 인덱싱 (multi-vector indexing)

임베딩 API는 SharePoint 덤프 파일에 8억 개의 토큰 (tokens)이 포함되어 있다는 사실을 누군가 깨닫기 전까지는 저렴해 보입니다.

현재 기본 설정이 되어가는 추세는 다음과 같습니다:

• 문서 약 1만 개 이후에는 로컬 임베딩 모델 (local embedding models) 사용
• 첫날부터 증분 인덱싱 파이프라인 (incremental indexing pipelines) 구축
• 메타데이터에 임베딩 모델 버전 관리 (versioning)

그렇지 않으면 마이그레이션 (migration)은 매우 빠르게 고통스러운 작업이 됩니다.

EU / 독일 미텔슈탄트 (Mittelstand) 관점

이는 많은 미국 블로그 포스트들이 시사하는 것보다 아키텍처 (architecture)를 더 크게 변화시킵니다.

이제는 온프레미스 (On-premise)가 보통 기본 요구 사항입니다.

GDPR + 제28조 (Art. 28) 계약 조건은 즉시 제공업체의 절반을 탈락시킵니다. 대부분의 법무 부서는 수개월간의 논의 없이 아주 적은 수의 후보 명단만을 수용합니다.

또한:
벡터 데이터베이스 (vector DB)에서의 삭제 권리 (right-to-erasure)는 많은 팀이 예상하는 것보다 더 까다롭습니다. 만약 임베딩 (embeddings)이 고객 문서로부터 파생되었다면, 그것들이 정확히 어디에 있는지 알아야 합니다.

여전히 많은 팀이 프로덕션 RAG 시스템 내부에 얼마나 많은 "지루한 인프라 작업 (boring infrastructure work)"이 포함되어 있는지 과소평가하고 있는 것 같습니다.

솔직히 LLM 부분은 종종 가장 쉬운 구성 요소입니다.

구체적인 벤더 (vendor) 분석과 비용 범위를 포함한 더 긴 버전을 원하신다면, 저희가 여기에 작성해 두었습니다: RAG mit eigenen Daten (독일어). EU 규제 환경에서의 에이전틱 AI (agentic AI)에 대한 더 넓은 관점은 다음과 같습니다: KI-Agenten im Mittelstand 2026.