RAG 구축, 데모는 성공했는데 운영은 왜 실패할까?

기업 RAG 구축은 문서를 벡터 데이터베이스에 넣고 LLM을 연결하는 작업만을 뜻하지 않습니다. 문서 구조화, 접근권한, 검색과 재정렬, 답변 생성, 평가, 문서 갱신을 하나의 운영 체계로 설계해야 합니다. PoC를 시작하기 전에는 잘 정리된 샘플보다 실제 업무에서 가장 처리하기 어려운 문서로 품질을 확인하는 것이 중요합니다.

이 글은 RAG의 개념보다 구축과 운영 판단에 초점을 맞춥니다. RAG의 뜻과 기본 작동 원리가 궁금하다면 먼저 RAG란? 왜 기업에서는 기대만큼 효과가 나지 않는가를 참고해 주세요.

RAG 구축 전 무엇을 먼저 확인해야 하나

RAG가 필요한 조직은 문서는 많지만 필요한 근거를 찾는 데 시간이 오래 걸리는 조직입니다. 사내 위키, 매뉴얼, 규정집, 계약서와 보고서가 흩어져 있고, 검색 결과만으로는 업무 질문에 답하기 어려워 결국 담당자에게 다시 묻는 일이 반복됩니다.

다음 조건이 여러 개 겹친다면 RAG 도입을 검토할 이유가 충분합니다.

• 내부 문서에만 존재하는 지식을 AI가 활용해야 한다.

• 답변과 함께 근거 문서나 원문 위치를 제시해야 한다.

• 규정과 매뉴얼이 자주 바뀌어 최신 문서 반영이 필요하다.

• 문서별·부서별 접근권한을 검색 결과에도 적용해야 한다.

• 외부 클라우드 전송이 제한되는 보안 환경을 고려해야 한다.

• 기존 키워드 검색으로는 표와 문맥을 함께 찾기 어렵다.

다만 위 조건이 있다고 해서 곧바로 벡터 데이터베이스를 선정할 필요는 없습니다. 먼저 대상 문서의 종류, 품질, 보안 등급, 갱신 빈도와 실제 질문 유형을 확인해야 합니다.

특히 PDF, 스캔본, 표, 다단 문서와 수기 내용이 섞인 환경에서는 텍스트를 추출하는 과정에서 제목과 본문, 항목과 값, 표의 행과 열 관계가 사라질 수 있습니다. 이 구조 손실은 검색과 답변 품질을 떨어뜨리는 원인 중 하나이므로 구축 초기에 별도로 검증해야 합니다.

기업 RAG 아키텍처와 구축 단계

기업용 RAG는 기본 파이프라인과 전체 구간에 적용되는 운영 기준으로 나눠 보는 것이 좋습니다.

보안과 권한은 마지막에 덧붙이는 별도 단계가 아닙니다. 문서를 수집할 때부터 사용자가 검색할 수 있는 문서 범위를 정하고, 검색 결과와 답변에도 같은 권한 정책이 적용되도록 설계해야 합니다.

문서가 개정되거나 삭제됐을 때 임베딩과 인덱스에도 변경이 반영돼야 합니다. 따라서 초기 데모뿐 아니라 문서 갱신, 권한 변경, 장애 대응까지 포함해야 운영형 아키텍처가 됩니다.

PoC가 운영에서 무너지는 이유

PoC는 제한된 문서와 예상 질문을 사용하기 때문에 실제 운영보다 문제가 적게 보일 수 있습니다. 운영 단계에서는 문서 양식과 질문이 다양해지고, 권한·갱신·속도 같은 조건이 함께 작동합니다.

문서 구조가 검색 전에 손실된다

텍스트만 추출하면 복잡한 표의 행과 열, 제목과 본문, 각주와 항목 사이의 관계가 사라질 수 있습니다. 검색기는 손실된 구조를 알 수 없으므로 관련 문장을 찾더라도 값의 의미나 적용 조건을 잘못 연결할 수 있습니다.

복잡한 기업 문서를 다루는 RAG에서는 문서 구조화가 자주 간과되는 품질 변수입니다. 다만 문서 처리만으로 전체 품질이 결정되는 것은 아닙니다. 청킹, 메타데이터, 검색, 재정렬과 생성 단계도 별도로 평가해야 합니다.

실제 질문과 평가 데이터가 부족하다

구축팀이 예상한 질문만으로 테스트하면 표현이 다른 질문, 문서 여러 개를 함께 봐야 하는 질문, 답을 찾을 수 없는 질문을 놓치기 쉽습니다. 현업 사용자의 질문을 모아 평가 세트를 만들고, 정답뿐 아니라 근거 문서와 허용 가능한 답변 조건을 함께 정의해야 합니다.

권한과 갱신이 검색 결과에 반영되지 않는다

사용자가 열람할 수 없는 문서가 검색되거나 폐기된 규정이 계속 답변에 사용되면 정확도 문제가 보안과 업무 위험으로 이어집니다. 문서별 권한 필터, 버전 관리, 삭제와 재색인 절차를 PoC부터 확인해야 합니다.

실패했을 때의 행동이 정의돼 있지 않다

근거가 없거나 검색 신뢰도가 낮은데도 답을 생성하면 그럴듯한 오류가 발생할 수 있습니다. 답변 보류, 추가 질문, 원문 검색 결과 제공, 담당자 이관처럼 실패 상황에서 취할 행동을 미리 정해야 합니다.

문서의 표·레이아웃 손실이 검색 오류로 이어지는 과정은
아래 게시물에서 더 자세히 확인할 수 있습니다.
복잡한 표와 레이아웃을 검색 가능한 구조로 바꿀 때 확인할 기준을 살펴보세요.

Parser 설계가 RAG 정확도를 결정하는 이유

Parser 설계가 부족하면 RAG는 필요한 문서를 정확히 찾지 못해 답변이 흔들릴 수 있습니다. 이 글에서는 레이아웃 분석, 문서 구조를 살리는 파싱, Chunk 분할과 메타데이터 설계가 검색 품질에 어떤 영향을 주는지 쉽게 정리했습니다. | ABOUT AI

https://www.koreadeep.com/blog/parser-rag-accuracy

비용·기간·범위를 결정하는 요소

RAG 구축 비용은 모델 사용료만으로 결정되지 않습니다. 문서의 양과 복잡도, 보안 환경, 시스템 연계, 평가와 운영 범위가 함께 영향을 줍니다.

문서 수만으로 견적을 비교하면 실제 난이도를 놓칠 수 있습니다. 같은 1만 페이지라도 텍스트 PDF와 병합 셀이 많은 스캔 문서는 처리 범위가 다릅니다. 반대로 문서 종류가 단순하고 권한 체계가 복잡하지 않다면 작은 범위부터 시작할 수 있습니다.

PoC에서는 모든 문서를 한꺼번에 넣기보다 사용 빈도와 업무 위험이 모두 높은 문서군을 먼저 선택하는 편이 좋습니다. 쉬운 샘플만으로 결과를 만들기보다 실제 운영에서 문제가 될 문서와 질문을 포함해야 이후 범위를 현실적으로 산정할 수 있습니다.

PoC와 운영 전 어떤 지표를 검증해야 하나

RAG 품질은 하나의 정확도 숫자로 설명하기 어렵습니다. 문서 처리, 검색, 생성, 보안과 운영 지표를 분리해야 문제 발생 지점을 찾을 수 있습니다.

RAGAS는 RAG 평가 지표를 Context Precision, Context Recall, Faithfulness, Response Relevancy 등으로 구분합니다. 지표마다 필요한 입력과 평가 방식이 다르므로, 하나의 종합 점수만 보기보다 실제 업무 위험에 맞춰 조합해야 합니다. 자세한 정의는 RAGAS 공식 지표 문서와 RAGAS 논문에서 확인할 수 있습니다.

보안 검토 항목

폐쇄망이나 온프레미스 배포는 보안 설계의 한 요소입니다. 배포 방식만으로 모든 보안 요건이 충족되는 것은 아닙니다.

• 원문과 벡터 DB는 어떻게 암호화하는가?

• 부서·직급·사용자별 문서 접근권한을 검색에도 적용하는가?

• 외부 모델 API로 전달되는 데이터 범위를 통제할 수 있는가?

• 개인정보와 민감정보를 언제 마스킹하는가?

• 질문·검색 결과·답변 로그를 얼마나 보관하는가?

• 문서 삭제와 권한 변경이 인덱스에 언제 반영되는가?

• 관리자 작업과 사용자 조회 기록을 감사할 수 있는가?

IBM도 RAG가 기업 데이터와 모델을 분리하는 데 유리할 수 있지만 외부 데이터베이스와 벡터 저장소 자체를 보호해야 한다고 설명합니다. 자세한 내용은 아래 게시물을 확인해보세요. RAG의 설명을 참고할 수 있습니다.

What is retrieval augmented generation (RAG)?

Retrieval augmented generation (RAG) is an architecture for optimizing the performance of an artificial intelligence (AI) model by connecting it with external knowledge bases.

https://www.ibm.com/think/topics/retrieval-augmented-generation

자체 구축과 파트너 도입은 어떻게 선택해야 하나

자체 구축과 파트너 도입 중 어느 한쪽이 항상 유리한 것은 아닙니다. 문서 난이도, 내부 역량, 보안 환경과 운영 책임을 기준으로 비교해야 합니다.

자체 구축을 선택하더라도 모든 계층을 직접 개발할 필요는 없습니다. 내부에서 검색과 LLM 계층을 구성하고, 복잡한 문서의 인식·구조화만 전문 제품과 연계하는 방식도 가능합니다.

한국딥러닝은 어떤 계층을 지원하나

한국딥러닝은 기업 RAG에서 문서 인식과 구조화가 필요한 구간을 지원합니다. VLM 기반 DEEP OCR과 DEEP Parser를 활용해 표와 레이아웃이 포함된 문서를 검색과 LLM이 활용할 수 있는 구조로 변환하는 접근입니다.

벡터 데이터베이스, 검색·재정렬, LLM, 업무 시스템 연계를 포함한 전체 지원 범위는 조직의 환경과 프로젝트 구성에 따라 달라질 수 있습니다. 온프레미스·내부망 구성 역시 대상 제품과 보안 요건을 기준으로 구체적인 가능 범위를 확인해야 합니다.

도입 체크리스트와 자주 묻는 질문

발행 전 또는 제안요청서 작성 전에 다음 항목을 확인해 보세요.

1. 대상 문서의 종류, 양, 갱신 빈도를 파악했다.

2. 표·스캔·수기·다단 문서의 비중을 확인했다.

3. 현업의 실제 질문과 근거 문서를 평가 세트로 만들었다.

4. 문서별·사용자별 접근권한 적용 방식을 정했다.

5. 검색과 생성 품질을 분리해 측정할 지표를 정했다.

6. 답을 찾지 못했을 때 보류·이관하는 방식을 설계했다.

7. 문서 개정·삭제 시 재색인 절차를 정했다.

8. 외부 모델 호출과 데이터 보관 정책을 확인했다.

9. PoC에 실제로 어려운 문서와 질문을 포함했다.

10. 자체 구축과 파트너 도입의 초기비용·운영비용을 함께 비교했다.

RAG 구축은 어디서부터 시작해야 하나요?

벡터 데이터베이스를 선정하기 전에 대상 문서와 질문을 정의해야 합니다. 문서 종류, 접근권한, 갱신 빈도와 답변 근거 요구사항을 정한 뒤 작은 평가 세트를 만들어 문서 처리와 검색 품질을 먼저 확인하는 것이 좋습니다.

RAG 구축 비용은 무엇으로 결정되나요?

문서의 양과 복잡도, 검색 방식, 모델 운영 환경, 보안·권한, 시스템 연계, 평가와 유지보수 범위가 비용을 좌우합니다. 문서 수만으로 비교하기보다 초기 구축비와 지속 운영비를 나눠 확인해야 합니다.

PoC는 어떻게 설계해야 하나요?

사용 빈도가 높으면서 오류 발생 시 업무 영향이 큰 문서와 질문을 표본으로 선택하는 것이 좋습니다. 쉬운 문서만 사용하면 운영 단계의 구조 손실, 검색 누락과 권한 문제를 발견하기 어렵습니다.

폐쇄망에서도 RAG를 구축할 수 있나요?

가능한 구성은 있지만 배포 방식과 제품 범위에 따라 조건이 달라집니다. 온프레미스 여부뿐 아니라 접근권한, 암호화, 로그, 외부 모델 호출과 업데이트 방식을 함께 확인해야 합니다.

RAG와 파인튜닝은 무엇이 다른가요?

RAG는 질의 시점에 외부 지식을 검색해 답변 근거로 사용하고, 파인튜닝은 모델의 행동이나 특정 작업 성능을 조정하기 위해 추가 학습하는 방식입니다. 두 방식은 서로 배타적이지 않으며, 최신 내부 지식과 출처 제시가 중요할 때는 RAG를 우선 검토할 수 있습니다.

한국딥러닝에 상담할 때 무엇을 전달하면 되나요?

사용하는 문서의 종류와 대략적인 양, 표·스캔·수기 문서 비중, 보안 환경, 연계할 시스템과 현재 겪는 검색 오류를 알려주면 검토 범위를 구체화하는 데 도움이 됩니다. 민감한 원문을 바로 첨부하기 어렵다면 문서 유형과 업무 과정부터 설명할 수 있습니다.

RAG를 운영에 안착시키려면 문서, 검색, 권한, 생성과 평가를 함께 설계해야 합니다. 특히 복잡한 기업 문서를 다룬다면 문서 구조가 검색 전에 손실되지 않는지 실제 샘플로 확인해야 합니다.

사용 중인 문서 유형, 보안 환경과 시스템 연계 범위를 기준으로 적용 가능 범위를 상담해 보세요.