프로덕션 RAG: 진짜 고객이 질문하기 시작하면 무엇이 무너지는가

동작하는 RAG(Retrieval-Augmented Generation) 데모는 반나절이면 만들 수 있습니다. 문서 몇 개를 임베딩하고, 벡터 스토어에 넣고, 코사인 유사도로 상위 5개 청크를 가져와 프롬프트에 붙이면 됩니다. 질문에 답합니다. 화면 녹화로 보면 마법 같습니다.

그다음 실제 고객 앞에 내놓는 순간, 간극이 벌어집니다.

누군가 여러분이 지원하는 세 번째 언어로 질문합니다. 누군가 자사 웹사이트에 서로 모순되는 두 버전으로 존재하는 정책을 묻습니다. 누군가 콘텐츠가 정말로 다루지 않는 것을 묻는데도 시스템은 답합니다. 유창하게, 확신에 차서, 틀리게. 재크롤링이 도는 중에 스무 명이 동시에 질문합니다. 타이핑이 아니라 스캔으로 만들어진 PDF 한 건이 검색 노이즈가 되어 주변 답변을 조용히 오염시킵니다.

이런 일은 데모에서 전혀 드러나지 않습니다. 데모는 깨끗한 문서, 하나의 언어, 한 명의 사용자, 그리고 만든 사람이 이미 답을 아는 질문만 쓰기 때문입니다. RAG에서 비용이 드는 모든 것은 이 두 상황 사이의 거리에 살고 있습니다.

이 가이드는 바로 그 거리에 관한 글입니다. RAG가 무엇인지는 이미 안다고 전제합니다. 아직이라면 RAG 챗봇이란 무엇이며 어떻게 작동하는가를 먼저 읽고 돌아오세요. 이제부터는 그 위층, 즉 검색 시스템이 실제 사용자와의 접촉에서 살아남을지를 결정하는 엔지니어링입니다.

컨텍스트 윈도가 커질 때마다 누군가는 RAG의 종말을 선언합니다. 그런 일은 일어나지 않았고, 이유는 일시적이 아니라 구조적입니다.

사용 가능한 컨텍스트는 광고된 컨텍스트보다 작습니다. 20만 토큰을 받는 모델이 그 20만 전체에 대해 똑같이 잘 추론하지는 않습니다. 이 효과는 잘 문서화돼 있습니다. 2023년 Liu 등의 "Lost in the Middle" 논문은 긴 입력의 중간에 묻힌 정보에서 정확도가 떨어짐을 보였고, 이후 등장한 모든 롱컨텍스트 모델 세대가 같은 취지의 단서를 달고 출시됐습니다. 품질은 하드 리밋보다 먼저 무너집니다. 게다가 중견기업의 실제 지식 자산은 200페이지가 아니라 수만 페이지입니다.

파인튜닝은 행동을 바꾸지 지식을 바꾸지 않습니다. 이 분야에서 가장 비싼 오해입니다. 파인튜닝은 형식, 어조, 추론 패턴을 가르치는 데는 훌륭합니다. 그러나 사실을 가르치는 방법으로는 약하고 신뢰하기 어려우며, 사실이 바뀌면 급격히 낡습니다. 가격, 정책, 재고의 사실은 매주 바뀝니다.

비용이 반대 방향으로 확장됩니다. 전체 코퍼스를 매 요청에 밀어 넣는다는 건 질문할 때마다 전체 코퍼스 값을 치른다는 뜻입니다. 검색은 관련 있는 수천 토큰만 지불합니다. 실제 메시지 볼륨에서 이 차이가 곧 마진 전부입니다.

감사 가능성은 기능이 아니라 요건입니다. 금융, 의료, 법률에서는 출처를 추적할 수 없는 답변은 쓸 수 없습니다. 검색은 그 흔적을 공짜로 만들어 냅니다. 어느 문서에서 어떤 구절이 왔는지를 시스템이 이미 알고 있기 때문입니다.

그러니 흥미로운 질문은 더 이상 "검색을 할 것인가"가 아닙니다. "왜 이렇게 많은 검색 시스템이 검색을 못하는가"입니다.

나쁜 답변의 가장 흔한 원인은 모델도, 임베딩도, 벡터 데이터베이스도 아닙니다. 코퍼스입니다.

한 고객사의 지식 베이스에서는 문서의 절반가량이 나머지 절반의 사실상 중복이었습니다. 같은 정책이 마케팅 사이트, 헬프센터, 보관된 PDF에 사소한 서식 차이만 두고 재게시돼 있었던 겁니다. 검색은 성실하게 다섯 청크를 돌려줬지만 그것은 같은 문단의 복사본 다섯 개였습니다. 모델은 다섯 개의 관점 대신 좁은 근거 한 조각만 보았고, top-k 예산은 중복에 쓰였습니다. 이걸 고치는 일은 화려할 것 없는 수작업 데이터 파이프라인 작업이었습니다. 그런데도 그달에 했던 어떤 검색 튜닝보다 답변 품질을 더 끌어올렸습니다.

반복해서 등장하는 범인들:

• 스캔 PDF와 OCR 손상. 사람 눈에는 멀쩡히 읽히는 텍스트가 구조적으로는 갈가리 찢겨 있을 수 있습니다. 단 순서가 뒤섞이고 표가 단어 수프로 뭉개집니다. 찢긴 텍스트의 임베딩은 예측 불가능하게 검색됩니다.
• 상용구와 동의 배너. 사이트를 순진하게 크롤링하면 모든 페이지가 같은 쿠키 고지, 같은 내비게이션, 같은 푸터를 달고 옵니다. 그러면 모든 청크가 크고 동일한 접두사를 공유하게 되고, 아무 관련 없는 페이지들 사이의 의미적 유사도가 올라갑니다. 그래서 저희 크롤러는 무엇이든 색인하기 전에 동의 배너와 페이지 틀을 제거합니다.
• 로그인 장벽과 빈약한 페이지. 로그인 페이지에도 텍스트는 있으니 순진한 파이프라인은 그것도 삼킵니다. 아무것도 더하지 않고 모든 것을 희석합니다.
• 아무도 눈치채지 못한 모순. 두 페이지가 서로 다른 반품 기한을 적어 둡니다. 검색은 둘 다 찾습니다. 모델은 하나를 고릅니다. 무엇을 고르든 누군가는 틀린 안내를 받습니다.

실무 규칙: 품질 게이트는 색인 이전에, 코드베이스의 정확히 한 곳에 두고, 콘텐츠를 추가할 수 있는 모든 경로가 그곳을 지나게 하십시오. 수집 규칙이 세 곳에 흩어지면 반드시 어긋나고, 온보딩 경로와 재크롤링 경로의 품질 차이는 아무도 재현하지 못하는 미스터리가 됩니다. 실전편은 깔끔한 지식 베이스 구축 가이드를 보세요.

단일 밀집 벡터 검색은 검색의 초안일 뿐입니다. 프로덕션의 검색은 네다섯 단계의 파이프라인이고, 각 단계는 다른 단계가 닿지 못하는 실패 유형을 해결합니다.

쿼리 확장. 실제 사용자 쿼리는 짧고, 오탈자가 있으며, 내부 약어로 가득합니다. 임베딩 전에 동의어와 풀어 쓴 약어로 쿼리를 확장하면 재현율이 측정 가능한 수준으로 좋아집니다. 실제 채팅 트래픽을 지배하는 두세 단어짜리 질문에서 특히 그렇습니다.

하이브리드 검색: 밀집 + 희소. 밀집 임베딩은 의미를 포착하지만 정확한 토큰을 놓칩니다. 상품 코드, 오류 코드, 모델 번호, 사람 이름 같은 것들이죠. 키워드 검색(저희는 Postgres tsvector 위의 BM25)은 바로 그런 것을 정확히 맞히고 대신 바꿔 말한 질문을 놓칩니다. 둘 다 돌리고 Reciprocal Rank Fusion으로 결과를 융합하는 것은 최적화가 아니라 프로덕션의 기본값입니다.

마땅한 것보다 훨씬 중요한 세부 하나: 키워드 검색은 언어에 의존합니다. Postgres는 텍스트가 영어라고 알려줘야만 "prices"를 "price"로 어간 처리합니다. 터키어, 독일어, 스페인어, 프랑스어, 이탈리아어, 포르투갈어는 각각 자기 설정이 필요하고, 내장 스테머가 없는 언어(일본어, 한국어, 중국어)에는 우연이 아니라 의도된 대체 전략이 필요합니다. 모든 쿼리를 영어로 어간 처리하는 다국어 RAG는 나머지 모든 언어에서 조용히 재현율을 잃습니다. 두 개 이상의 시장을 담당한다면 이 절과 함께 다국어 챗봇 가이드도 읽어 보세요.

리랭킹. 융합은 그럴듯한 후보 20~30개를 남깁니다. 크로스 인코더 리랭커는 각 후보를 실제 질문에 대해 채점하고, 진짜 정답 구절을 15위에서 상위 3위로 끌어올리는 일을 일상적으로 해냅니다. 시스템이 "거의 맞는 페이지만 계속 인용한다"면 가장 먼저 살펴볼 곳은 빠져 있는 리랭킹 단계입니다.

캐싱은 신중하게. 동일한 질문이 파이프라인 전체를 다시 돌릴 필요는 없습니다. 다만 캐시할 것은 쿼리와 top-k를 키로 한 검색 결과이지 생성된 답변이 아닙니다. 그렇지 않으면 원본 문서를 업데이트한 뒤에도 낡은 답을 내보내게 됩니다.

진지한 RAG 시스템은 생성 전에 검색 결과를 채점하고, 그 점수로 모델에게 이 컨텍스트를 얼마나 믿어도 되는지 지시합니다. 바로 답하기, 단서를 달고 답하기, 또는 답하지 않고 사람에게 넘기기. 이것이 존재하는 것 중 가장 중요한 환각 방어책입니다.

동시에 잘못 설정돼 있을 가능성이 가장 큰 값이기도 합니다. 기본값이 대개 측정된 것이 아니라 지어낸 것이기 때문입니다.

배울 만한 실수를 하나 소개합니다. 저희 것입니다. 저희의 "높은 신뢰도" 임계값은 코사인 유사도 0.82로 설정돼 있었습니다. 적당히 엄격하게 들리는 숫자죠. 그런데 실제 트래픽에 대조해 보니, 실 응답 중 이 값을 넘은 것은 2%도 되지 않았습니다. 밀집 의미 매칭은 가져온 구절이 누가 봐도 정확히 맞는 경우에도 대략 0.80을 넘는 일이 드뭅니다. 즉 모델은 거의 모든 질문에서 "이 컨텍스트는 부분적일 뿐"이라는 지시를 받고 몸을 사렸습니다. 정확한 답변이 불필요한 불확실성에 감싸여 나갔던 겁니다. 검색은 멀쩡했습니다. 망가진 건 자였습니다.

해법은 전부 느슨하게 푸는 것이 아니었습니다. 애매한 구간의 실제 대화 표본을 뽑아 읽었습니다. 0.64~0.68 구간의 답변은 구체적이고 정확했으며, 정확한 요금제 한도와 정확한 정책 규정을 인용하고 있었습니다. 하지만 진짜 공백 — 저희가 지원하지 않는 연동에 대한 질문 — 도 같은 구간에 떨어졌고, 마땅히 조심스럽게 답하고 있었습니다. 그래서 높은 기준선을 실제 매칭이 도달할 수 있는 수준으로 낮추고, 애매한 중간 구간은 "부분적"으로 남기고, 맨 아래의 "지어내지 말 것" 안전장치는 그대로 두었습니다.

옮겨 쓸 수 있는 교훈: 임계값은 직관이 아니라 자신의 분포에 맞춰 보정하라. 조정하려는 구간의 실제 대화를 직접 읽어라 — 집계 점수는 좋은 답변과 점수만 높은 오답을 구분해 주지 않습니다. 그리고 모든 임계값을 환경 변수로 만들어라 — 그래야 잘못된 보정이 배포가 아니라 1분짜리 롤백으로 끝납니다.

청킹은 서식 결정처럼 보입니다. 실제로는 검색 결정이고, "문서에 분명히 있는 내용을 봇이 못 찾는다"는 불만의 상당 부분이 여기서 시작됩니다.

500토큰마다 고정 길이로 자르면 표가 반으로 갈리고, 제목이 그 뒤의 문단과 분리되며, 번호가 매겨진 절차가 두 청크로 쪼개져 어느 쪽도 단독으로는 쓸모없어집니다. 구조를 인식하는 분할 — 먼저 제목과 문단 경계를 존중하고, 목표 크기까지 병합한 뒤, 긴 구간은 문장 경계에서 자르기 — 은 구현에 하루가 걸리고 곧바로 본전을 뽑습니다. 저희 파이프라인은 청크당 약 800토큰, 겹침 200토큰을 목표로 합니다. 산문 위주의 비즈니스 콘텐츠에 합리적인 출발점입니다.

더 미묘한 문제는, 청크가 일단 고립되면 그것을 의미 있게 만들어 주던 맥락을 잃는다는 점입니다. "표준 배송은 영업일 기준 3~5일이 걸립니다"는, 누구의 배송인지, 어느 지역인지, 어떤 제품 라인인지가 청크에 없다면 쓸모없는 검색 대상입니다. 단독으로 검색되면 모델은 그것을 완전히 다른 질문에 갖다 붙일 수 있습니다.

해법은 임베딩 전에 각 청크를 자기 출처로 보강하는 것입니다. 문서 제목, 섹션 제목, 출처를 붙여, 임베딩되는 텍스트가 사람 독자라면 주변 페이지에서 얻었을 맥락을 함께 지니게 하는 것이죠. Anthropic은 이 방식의 한 버전을 "contextual retrieval"이라는 이름으로 널리 알렸고, 검색 실패의 상당한 감소를 보고했습니다. 가치를 얻기 위해 반드시 LLM 처리를 거칠 필요도 없습니다. 문서 자체의 메타데이터로 만든 결정론적 접두사가 한계비용 0으로 이득의 상당 부분을 가져옵니다. 저희가 프로덕션에서 돌리는 것도 이 방식입니다.

경험에서 나온 경고 하나: 청킹이나 맥락 부여 전략을 바꾸면 마이그레이션을 떠안게 됩니다. 기존 청크는 모두 옛 방식으로 임베딩돼 있습니다. 문서 단위의 표적 재색인을 계획하십시오. 운영 중인 코퍼스를 무턱대고 전면 재임베딩하는 일은 절대 하지 마세요.

팀이 논쟁하는 건 검색 품질입니다. 하지만 시스템을 실제로 쓰러뜨리는 건 안정성입니다.

수집은 오래 걸리고, 여러 단계로 나뉘며, 일부는 외부에 의존하는 프로세스입니다. 가져오기, 추출, 청킹, 임베딩(레이트 리밋에 걸릴 수 있는 유료 API 호출), 쓰기, 완료 표시. 네트워크 경계를 넘어 몇 분씩 도는 작업은 반드시 중단되며, 그 중단은 드물지 않습니다.

가장 많은 것을 가르쳐 준 장애는 조용했습니다. 한 사용자가 사이트 크롤링을 시작한 뒤 다른 페이지로 이동했습니다. 그 요청을 처리하던 서버리스 함수가 비행 도중 종료됐습니다. 청크와 임베딩은 기록된 뒤였지만, 문서가 처리 완료로 표시되기 직전이었죠. 예외도 없었습니다. 모니터링에 오류도 없었습니다. 남은 것은 완전히 색인됐는데도 영구히 "색인 중"으로 표시되는 문서 하나, 그리고 배지 하나 바꿔 보겠다고 19시간 동안 같은 사이트를 네 번 재크롤링한 뒤 떠나 버린 사용자 한 명이었습니다.

이 부류의 버그가 가르쳐 준, 그대로 훔쳐 갈 만한 세 가지 불변식:

• 사용자에게 보이는 진실이 가장 먼저 기록되도록 쓰기 순서를 정하라. 콘텐츠가 안전하게 저장된 직후에 처리 완료 플래그를 올리고, 통계·캐시 무효화·기타 장부 작업은 그 뒤로 미루되 각각 시간 제한과 최선 노력 방식으로 처리합니다. 실제 작업과 그것을 기록하는 플래그 사이에 선택적 단계를 절대 끼워 넣지 마십시오.
• 모든 잡 핸들러를 멱등으로 만들고, 그다음 넉넉하게 재큐잉하라. 워커가 도중에 죽으면 다음 스윕이 잡 전체를 안전하게 다시 실행할 수 있어야 합니다. "지우고 다시 넣는" 핸들러는 재시도를 공짜로 만듭니다.
• 자가 치유 스윕을 추가하라. 미완료 상태로 멈춰 있는 문서를 찾아 다시 큐에 넣는 주기적 잡은, 영구적이고 사용자에게 보이는 실패를 몇 분의 지연으로 바꿔 놓습니다. RAG 파이프라인에서 투자 대비 효과가 가장 큰 안정성 작업이며, 거의 모두가 한 번 데인 뒤에야 만듭니다.

동시 부하에 대비해 지루한 인프라도 갖추십시오. 발사 후 잊어버리는 프로미스 대신 진짜 큐, 임베딩 호출이 커넥션을 붙잡고 있다는 점을 감안한 커넥션 풀 한도, 그리고 한 고객의 900페이지 크롤링이 다른 모두의 실시간 채팅을 굶기지 못하게 하는 테넌트 격리입니다.

RAG 품질은 눈대중으로 판단할 수 없습니다. 모든 팀이 할 수 있다고 믿고, 모든 팀이 틀립니다. 나쁜 RAG의 실패 양상은 유창하고 그럴듯하며 서식까지 깔끔한, 그러나 사실이 아닌 답변이기 때문입니다. 좋은 답변과 똑같이 읽힙니다.

최소한의 평가 체계는 사람들이 두려워하는 것보다 작습니다.

골든 세트. 정답이 알려진 실제 질문 30~100개를, 지어내지 말고 실제 상담 이력에서 뽑으십시오. 검색·청킹·프롬프트·모델 버전을 바꿀 때마다 다시 돌립니다. 이것은 회귀 테스트이고, 시끄럽게 실패해야 합니다.

검색 점수와 답변 점수를 분리하라. 품질이 떨어졌을 때, 정답 구절이 검색되지 않은 것인지 검색됐는데 무시된 것인지를 알아야 합니다. 해결책이 완전히 다르며, 단일한 종단 간 점수로는 둘을 구분할 수 없습니다.

신뢰도 분포를 시간에 따라 관찰하라. 검색 점수 히스토그램의 이동은 조기 경보입니다. 대개 누군가 저품질 콘텐츠를 대량으로 추가했거나, 트래픽이 코퍼스가 다루지 않는 주제로 옮겨간 것입니다.

"모르겠습니다"를 가장 값진 텔레메트리로 취급하라. 낮은 신뢰도 답변과 사람 연결은 모두 이미 라벨이 붙은 콘텐츠 공백입니다. 몇 달에 걸쳐 어시스턴트가 눈에 띄게 좋아지는 팀은 거의 예외 없이, 그 목록을 매주 읽고 빠진 페이지를 쓰는 팀입니다. 챗봇 애널리틱스 가이드에서 지켜볼 만한 지표를 다룹니다.

그리고 문의 감소율은 정직하게 측정하십시오. 대화는 고객이 타이핑을 멈췄다고 해결된 것이 아닙니다. 한 시간 뒤에 이메일을 보내지 않았을 때 해결된 것입니다. 플랫폼이 이 두 사건을 연결하지 못한다면, 여러분은 스스로를 기분 좋게 해 주는 숫자를 최적화하고 있는 셈입니다.

아키텍처가 똑같은 두 RAG 시스템이 같은 산업에서 하나는 성공하고 하나는 실패할 수 있습니다. 차이는 대개 파이프라인 안에 있지 않습니다.

도메인 언어는 진짜 작업입니다. 의료 약어, 금융 상품명, 법률 인용 형식, 상품 코드 관행은 각각 고유한 방식으로 범용 검색을 망가뜨립니다. 금융 고객이 "3년물"을 물을 때는 특정 상품을 뜻하지만, 범용 임베딩은 시간을 떠올립니다. 이건 동의어 사전, 메타데이터 필터, 그리고 사람뿐 아니라 기계도 읽을 것을 전제로 쓴 콘텐츠로 고칩니다. 더 큰 모델로는 고쳐지지 않습니다.

범위 규율이 성능을 이깁니다. 어시스턴트에 대한 신뢰를 가장 빠르게 무너뜨리는 방법은, 실제로 모르는 영역의 질문에 답하게 두는 것입니다. 명시적인 경계 — 이 에이전트는 우리 제품, 정책, 문서에 대해 답하고 나머지는 사람에게 넘긴다 — 는 어떤 검색 개선보다도 민망한 답변을 크게 줄입니다. 실제 어시스턴트들이 일반론의 늪으로 표류하는 걸 목격한 뒤 저희가 적용한 수정이기도 합니다.

정착은 출시 요건입니다. 상담팀에게 알리지 않은 어시스턴트는 결국 상담팀에게 외면당합니다. 콘텐츠 공백을 책임지고, 사람 연결 건을 읽고, 어시스턴트가 무엇을 약속해도 되는지 정하는 사람이 있어야 합니다.

기업의 신뢰에는 체크리스트가 있습니다. 누가 묻는지를 검색이 존중하도록 하는 역할 기반 접근 제어, 어떤 출처가 어떤 답변을 만들었는지 보여 주는 감사 추적, 명확한 데이터 소재지, 보존 정책 제어, 그리고 고객 대화를 공개 모델 학습에 쓰지 않는다는 명확한 선언. 이것들은 보안 검토가 끝난 뒤 붙이는 기능이 아닙니다. 그 검토를 통과하느냐 마느냐의 이유 그 자체입니다. 챗봇 보안·프라이버시 가이드에서 공급업체에게 무엇을 확인해야 하는지 정리했습니다.

직접 만든다면 정직한 범위는 "벡터 DB 하나와 프롬프트 하나"가 아닙니다. 콘텐츠 품질 게이트, 다단계 검색 파이프라인, 보정된 신뢰도 임계값, 멱등 핸들러와 자가 치유 스윕을 갖춘 잡 큐, 평가 하네스, 애널리틱스 루프 — 그리고 이 모두의 지속적인 운영입니다. 검색 품질 자체가 제품이라면 할 만한 일입니다. 검색이 고객 질문에 답하기 위한 수단일 뿐이라면, 작은 팀의 1년을 쓰기에 나쁜 선택입니다.

구매한다면 이 글의 체크리스트가 곧 실사 질문지가 됩니다. 공급업체에 물어보세요. 하이브리드 검색을 쓰나요, 밀집 검색만 쓰나요? 리랭킹 단계가 있나요? "모르겠습니다" 임계값은 어떻게 정해지고, 제가 바꿀 수 있나요? 수집이 중간에 끊기면 문서는 어떻게 되나요? 특정 답변을 어떤 출처가 만들었는지 볼 수 있나요? 제 언어에서 키워드 검색은 어떻게 처리되나요? 지난주에 어시스턴트가 답하지 못한 질문은 무엇인가요? 이 질문들에 답하지 못하는 공급업체는 데모를 만든 것입니다.

Chatloom은 바로 이 층을 책임지기 위해 존재합니다. 이 글 전체에서 설명한 파이프라인 — 맥락 보강을 포함한 구조 인식 청킹, 쿼리 확장, 언어를 인식하는 어간 처리를 갖춘 밀집＋희소 하이브리드 검색, RRF 융합, 크로스 인코더 리랭킹, 진짜 "모르겠습니다"를 가진 보정된 신뢰도, 자가 치유 스윕을 갖춘 멱등 수집 잡, 그리고 어떤 질문이 답을 얻지 못했는지 정확히 보여 주는 대시보드 — 이 플랫폼의 모든 에이전트 뒤에서, 10개 언어로, 여러분 쪽에 ML 팀 없이 돌아갑니다.

오늘 여러분의 콘텐츠로 직접 확인해 보세요. 무료 계정 만들기, 웹사이트 주소를 붙여 넣고, 이 글을 읽는 데 걸린 정도의 시간 안에 전체 루프 — 크롤링, 품질 게이트, 청킹, 임베딩, 하이브리드 검색 — 가 도는 것을 지켜보세요. 고객이 실제로 하는 다섯 가지 질문을 던져 보십시오. 답변이 여러분의 콘텐츠에 근거하고, 모르는 것은 모른다고 인정한다면, 그것이 곧 여러분의 평가 결과입니다. 무료 플랜은 카드가 필요 없습니다.

먼저 자세한 내용을 보고 싶다면 저희 RAG 엔진의 작동 방식을 확인하거나, 실전 편인 내 데이터로 어시스턴트 학습시키기를 읽어 보세요.