기업용 RAG 솔루션 비교 기준 9가지와 PoC 점검표

작성 올거나이즈코리아 마케팅팀 · 최종 갱신 2026년 10월 19일

기업용 RAG 솔루션을 비교할 때는 데모 답변의 매끄러움보다 네 가지를 먼저 봐야 합니다. 우리 회사 문서(HWP, 스캔 PDF, 표가 많은 문서)를 제대로 읽는지, 우리 문서로 만든 평가 세트로 정확도를 재는지, 사용자 권한이 검색 단계에서 반영되는지, 설치 방식과 모델 교체와 운영 비용을 어떻게 감당하는지입니다. 이 글은 이 네 가지를 9개 비교 기준으로 나누고, 기준마다 공급사에 물어볼 질문, PoC에서 확인하는 방법, 평가 지표를 정리했습니다. 올거나이즈가 금융·공공 구축과 ACL 2026 논문, 검색 평가 특허(제10-3031382호)에서 다룬 내용을 바탕으로 썼습니다.

기업용 RAG란 무엇이고, 왜 데모로는 비교하기 어려운가요?

기업용 RAG(검색증강생성, Retrieval-Augmented Generation)는 질문이 들어올 때마다 사내 문서에서 근거를 찾아 그 내용으로 답을 쓰고 출처를 붙이는 생성형 AI 시스템입니다. 문서에서 글자·표·그림을 뽑아 읽을 수 있는 형태로 바꾸는 파서, 질문에 맞는 문서 조각을 찾는 검색기(리트리버), 찾은 근거로 답을 쓰는 생성 모델의 세 부분으로 이루어집니다.

데모로 비교하기 어려운 이유는 데모 문서와 실제 기업 문서의 성격이 다르기 때문입니다. 올거나이즈가 ACL 2026 본회의에 발표한 RARE 연구에서는 위키피디아 환경에서 검색 정확도(PerfRecall@10) 77.9%를 기록한 검색 모델이 금융 문서에서 8.5%, 법률 문서에서 5.0%까지 떨어졌습니다[1]. 위키피디아는 문서마다 다루는 내용이 뚜렷이 다르지만, 기업 문서는 분기마다 구조가 같은 보고서, 비슷한 조항이 반복되는 규정집처럼 서로 닮은 문서가 대부분입니다. 공급사가 준비한 데모 문서에는 이런 조건이 거의 없으므로, 비교는 우리 문서와 우리 조직의 권한·망 구성 조건에서 해야 합니다.

기업용 RAG 솔루션은 어떤 기준으로 비교해야 하나요?

아래 9가지 기준으로 비교하면 데모에서 드러나지 않는 차이를 대부분 확인할 수 있습니다. 1~2번은 문서를 열고 읽는 단계, 3~4번은 정확도, 5~6번은 신뢰와 통제, 7~9번은 설치와 운영에 관한 기준입니다.

문서 형식과 DRM은 무엇을 확인해야 하나요?

문서 형식은 실제 업무 문서의 형식 비율을 먼저 세고, 그 비율대로 PoC 문서를 고르는 방식으로 확인합니다. 최근 몇 달간 등록된 문서 100건 정도를 표본으로 HWP, PDF, 스캔본, DOCX, 엑셀 비율을 세면 충분합니다. 공급사가 PDF와 DOCX 위주로 시연하면 HWP와 스캔 문서 처리 능력은 PoC가 끝날 때까지 드러나지 않습니다.

HWP는 표 안에 표가 들어가거나 셀이 병합된 경우가 많고, 그림으로 붙여 넣은 표도 흔합니다. 병합 셀을 단순히 글자로만 뽑으면 항목명과 값의 짝이 어긋나 표에 있는 숫자를 묻는 질문에 엉뚱한 답이 나옵니다. 확인할 것은 HWP를 어떤 방식으로 읽고 그 처리에 별도 서버나 라이선스 비용이 드는지, 병합 셀이 있는 표를 행과 열 구조대로 읽는지 두 가지입니다. 스캔 문서는 OCR 결과 몇 쪽을 원본과 직접 대조해 보는 것이 가장 빠릅니다.

DRM은 기술보다 절차에서 막히는 경우가 많습니다. 복호화를 어느 서버에서 하는지, 복호화된 원문이 어디에 얼마 동안 남는지, 보안 부서 승인이 필요한지를 PoC 시작 전에 정해 두어야 일정이 밀리지 않습니다. 문서를 넣기 전에 통과해야 하는 형식·접근권·파싱 품질 세 관문은 데이터 파이프라인 현장 리포트에 실제 사례로 정리해 두었습니다.

정확도는 어떤 지표로 비교해야 하나요?

정확도는 우리 문서로 만든 평가 세트 하나를 모든 후보에 똑같이 적용하고, 검색과 생성을 나눠 재야 비교할 수 있습니다. 최종 답의 정답률 하나만 보면 검색이 틀렸는지 생성이 틀렸는지 알 수 없어 PoC 이후 개선 계획을 세울 수 없습니다.

평가 세트의 규모는 업무 분야마다 질문 60개 정도가 실무에서 다루기 좋습니다. 올거나이즈가 2024년 공개한 한국어 RAG 리더보드는 금융·공공·의료·법률·커머스 분야마다 200~300쪽 문서와 질문 60개를 쓰고, 채점 도구 5개 중 3개 이상이 맞다고 판정한 답만 정답으로 인정했습니다[3]. 질문에는 단순 사실 확인뿐 아니라 표의 숫자를 읽어야 하는 질문, 여러 문서를 함께 봐야 하는 질문, 비슷한 문서 사이에서 맞는 문서를 골라야 하는 질문을 섞습니다.

비슷한 문서가 많은 기업 문서에서는 검색을 어떻게 평가하나요?

비슷한 문서가 많은 환경에서는 같은 사실이 들어 있는 문서를 모두 정답으로 인정하도록 평가 세트를 만들어야 검색 성능을 공정하게 잴 수 있습니다. 일반 벤치마크는 질문마다 정답 문서를 하나만 정해 두기 때문에, 1분기 보고서와 2분기 보고서에 똑같이 들어 있는 문장을 검색기가 2분기 보고서에서 찾아오면 오답으로 처리합니다. 이런 평가에서는 맞는 근거를 찾은 검색기도 낮은 점수를 받고, 공급사 간 비교도 틀어집니다.

올거나이즈의 RARE(Redundancy-Aware Retrieval Evaluation)는 이 문제를 세 단계로 다룹니다[1].

1. 사실 단위 분해: 문서를 더 나눌 수 없는 최소 단위의 사실로 쪼개고, 같은 사실이 어느 문서들에 중복으로 들어 있는지 추적합니다.
2. 중복 인지 정답 처리: 같은 사실이 여러 문서에 있으면 그중 어느 문서를 가져와도 정답으로 인정합니다.
3. 평가 데이터 품질 안정화(CRRF): LLM이 만든 평가 질문을 품질 기준별로 따로 평가한 뒤 순위를 합산해 고릅니다. 논문에서는 이 방식으로 평가 데이터 품질 점수(NDCG@3)를 0.419에서 0.463으로 높였습니다.

이 방법은 금융·법률·특허 세 분야의 평가 세트(RedQA)로 검증해 ACL 2026 본회의 논문으로 발표했고, 국내에서는 "고유사·중복 말뭉치를 위한 중복 인지 검색평가 데이터셋 구축 방법 및 시스템"으로 특허(제10-3031382호, 2026년 10월 7일 등록)를 받았습니다[4].

PoC에서는 공급사에 두 가지를 확인하면 됩니다. 평가 세트를 만들 때 같은 내용이 여러 문서에 있는 경우를 어떻게 채점하는지, 그리고 분기 보고서나 개정 규정처럼 서로 닮은 문서 묶음을 평가 대상에 넣었는지입니다. 이 두 가지가 빠진 정확도 숫자는 실제 운영 성능보다 높거나 낮게 나올 수 있습니다.

권한과 출처 표시는 어떻게 검증하나요?

권한은 권한이 서로 다른 계정 2~3개로 같은 질문을 던져, 검색 결과에 볼 수 없는 문서가 섞이는지 확인하는 방식으로 검증합니다. 답을 만든 뒤 화면에서만 가리는 방식은 근거 문서 내용이 답 안에 섞여 나올 수 있어 금융·공공 환경에서는 쓰기 어렵습니다.

실제 구축 현장에서는 검색 범위를 지정하지 않았을 때 다른 사용자의 개인 문서함 문서까지 검색 대상에 들어간 사례가 있었습니다. 권한 필터가 특정 사용자의 ID 값으로 거르지 않고 ID 필드가 있는지만 확인하도록 짜여 있었기 때문입니다[5]. 이런 문제는 정상 계정 하나로 시연할 때는 보이지 않으므로 교차 테스트를 PoC 항목에 반드시 넣어야 합니다.

출처 표시는 답마다 근거 문서 이름, 쪽, 버전이 함께 나오는지 봅니다. 개정 전후 규정을 같이 넣고 최신 규정 기준으로 답하는지, 옛 규정을 근거로 쓸 때 그 사실을 표시하는지도 확인합니다.

설치 방식, 모델 종속, 운영비는 무엇을 물어야 하나요?

설치 방식은 실제로 운영할 망 구성에서 설치와 업데이트가 어떻게 이루어지는지를 절차서로 받아 확인합니다. 폐쇄망에서는 외부 인터넷 없이 모델과 소프트웨어를 반입하고 교체하는 절차가 필요하고, SaaS와 온프레미스가 같은 제품인지 별도 제품인지에 따라 기능 차이와 업데이트 주기가 달라집니다.

모델 종속은 우리가 LLM을 선택하고 교체할 수 있는지, 지식베이스와 설정과 평가 기록을 밖으로 꺼낼 수 있는지 두 가지로 확인합니다. PoC 기간에 모델을 하나 바꿔 같은 평가 세트로 다시 재 보면 교체에 드는 시간과 품질 변화를 함께 볼 수 있습니다.

운영비는 라이선스보다 그 밖의 항목에서 차이가 납니다. 견적 비교표에 HWP 처리, DRM 연동, GPU 서버, 개인정보 마스킹, 운영 인력, 모델 교체 작업을 따로 칸으로 만들어 공급사별로 채워 받으면 숨은 비용이 드러납니다. 운영 중에는 임베딩 모델을 바꾼 뒤 인덱스 설정이 따라 바뀌지 않아 에러 로그 없이 검색 품질만 떨어진 사례도 있었으므로[5], 평가 세트로 검색 품질을 정기적으로 다시 재는 체계가 있는지도 물어야 합니다.

국내 금융·공공 구축 사례에서는 어떤 기준이 요구됐나요?

언론에 보도된 국내 구축 범위를 보면 9가지 기준 중 문서 형식(1번), 출처 표시(6번), 설치 방식(7번), 모델 선택(8번)이 공통으로 요구됐습니다.

공공기관은 HWP와 출처 표시가, 증권사는 온프레미스 설치가 먼저 요구되는 경향이 보도 내용에서도 드러납니다. 우리 조직의 우선순위를 정할 때 같은 업권 사례의 요구 범위를 참고하면 PoC 항목을 줄일 수 있습니다.

PoC는 어떻게 설계하면 비교가 쉬워지나요?

PoC는 공급사에 연락하기 전에 문서, 질문, 채점 방법을 우리가 먼저 정해 두면 비교가 쉬워집니다. 순서는 다음과 같습니다.

1. 문서를 고릅니다. 실제 업무 문서의 형식 비율대로 고르고, DRM 문서, 표가 많은 문서, 개정 이력이 있는 문서, 분기 보고서처럼 서로 닮은 문서 묶음을 일부러 넣습니다.
2. 질문과 정답을 정합니다. 분야마다 실무 질문 60개 안팎과 정답, 근거 문서를 공급사에 주기 전에 확정합니다. 같은 사실이 들어 있는 문서는 모두 정답 근거로 묶어 둡니다.
3. 채점 방법을 정합니다. 검색 지표와 생성 지표를 나눠 재고, 생성 채점은 도구 여러 개와 사람 확인을 함께 씁니다.
4. 권한 교차 테스트를 합니다. 권한이 다른 계정으로 같은 질문을 던집니다.
5. 운영 조건을 확인합니다. 실제 운영 망에서 설치해 보고, 모델 교체와 문서 추가 뒤 재평가까지 진행합니다.

공급사에 어떤 질문을 보내야 하나요?

아래 10개 질문을 제안요청서나 사전 질의서에 그대로 넣어 쓰면 9가지 기준을 빠짐없이 확인할 수 있습니다.

1. HWP, 스캔 PDF, 병합 셀이 있는 표, 이미지 문서를 어떤 방식으로 처리하며, 이를 위해 별도 서버나 라이선스가 필요합니까? 처리하지 못하는 형식은 무엇입니까?
2. 사내 DRM 문서는 어떤 방식으로 열고, 그 비용은 견적에 들어 있습니까?
3. 우리 문서로 평가 질문·정답 세트를 만들고 검색과 생성 정확도를 나눠 보고합니까?
4. 같은 내용이 여러 문서에 있을 때 평가에서 정답을 어떻게 처리합니까?
5. 사용자 권한은 검색 단계에서 걸러집니까?
6. 답마다 근거 문서와 버전이 표시됩니까?
7. SaaS, 온프레미스, 폐쇄망 중 어디까지 지원하며, 폐쇄망에서 모델과 소프트웨어는 어떻게 교체합니까?
8. 사용하는 LLM을 우리가 선택하고 교체할 수 있으며, 지식베이스·설정·평가 기록을 나중에 내보낼 수 있습니까?
9. 운영 중 검색 품질 저하는 어떻게 감지합니까?
10. 장애가 나면 우리 조직과 공급사의 역할 분담은 어떻게 됩니까?

올거나이즈는 이 기준에 어떻게 대응하나요?

올거나이즈는 금융·공공 고객 구축 경험을 바탕으로 9가지 기준 각각에 대응하는 기능과 운영 방식을 갖추고 있습니다.

• 우리 문서로 재는 정확도: 고객 문서로 평가 질문·정답 세트를 만들어 RAG 정확도를 재는 RARE 평가 기능을 알리에 넣었습니다(2026년 1월 제품 업데이트). 같은 방법론을 ACL 2026 논문으로 발표했고 국내 특허(제10-3031382호)를 받았습니다. RARE 기능 소개, ACL 2026 논문 소개
• HWP, DRM, 파싱: 국내 금융·공공 현장에서 HWP 처리, DRM 복호화, 파싱 설정 문제를 다룬 과정을 공개했습니다. 데이터 파이프라인 현장 리포트
• 권한과 조용한 장애: 권한 필터 오류와 임베딩 교체 장애의 원인과 점검표를 공개했습니다. RAG·에이전트 장애 현장 리포트
• 설치 방식: SaaS와 온프레미스를 하나의 코드베이스로 제공하고 폐쇄망·망분리 환경 배포를 지원합니다. 온프레미스에서는 인프라 운영을 고객 조직이, AI 플랫폼 기술 지원을 올거나이즈가 맡습니다. 알리 웍스 온프레미스
• 출처와 버전: 문서 유형을 자동 분류하고, 질문에 출처와 버전을 함께 붙여 답합니다. Alli Documents 2.0
• 금융·공공 구축: 증권·공공 분야 구축 내용은 증권, 공공 페이지에, 직접 구축과 플랫폼 도입의 판단 기준은 플랫폼 선택 현장 리포트에 정리했습니다.

우리 문서로 PoC 평가 세트를 함께 설계해 보려면 도입 상담으로 문의해 주세요.

자주 묻는 질문

Q. RAG와 일반 생성형 AI 챗봇은 무엇이 다른가요?
일반 챗봇은 모델이 학습한 지식으로 답합니다. RAG는 질문할 때마다 회사 문서에서 근거를 찾아 그 내용으로 답하고 출처를 붙입니다. 그래서 최신 사내 규정이나 약관처럼 모델이 학습하지 않은 내용에도 답할 수 있습니다.

Q. 공개 RAG 벤치마크 순위로 솔루션을 골라도 되나요?
참고 자료로는 쓸 수 있지만 그것만으로 고르기는 어렵습니다. RARE 연구에서는 위키피디아 환경에서 77.9%였던 검색 정확도가 금융 문서에서 8.5%까지 떨어졌습니다. 우리 문서로 만든 평가 세트로 다시 재야 합니다.

Q. RAG 평가 세트는 몇 문항으로 만들어야 하나요?
업무 분야마다 60문항 안팎이 실무에서 다루기 좋습니다. 단순 사실 질문만 넣지 말고 표의 숫자를 읽는 질문, 여러 문서를 함께 봐야 하는 질문, 서로 닮은 문서 중 맞는 문서를 골라야 하는 질문을 섞어야 차이가 드러납니다.

Q. HWP 문서가 많으면 무엇을 꼭 확인해야 하나요?
HWP를 어떤 방식으로 읽는지, 병합 셀이 있는 표와 그림이 섞인 HWP를 구조대로 읽는지, HWP 처리에 별도 서버나 라이선스 비용이 드는지 세 가지를 확인하세요.

Q. 폐쇄망 환경에서도 RAG를 쓸 수 있나요?
쓸 수 있습니다. 온프레미스로 설치하면 문서와 LLM을 모두 사내 서버에서 운영합니다. 서버와 GPU 준비, 외부 연결 없이 모델과 소프트웨어를 교체하는 절차를 미리 계획해야 합니다.

출처

1. 올거나이즈, "RARE: Redundancy-Aware Retrieval Evaluation Framework for High-Similarity Corpora", ACL 2026 Main Conference. 올거나이즈 블로그 소개글
2. 위성곤 의원실 공개 "공공분야 AI 활용 현황" 설문(중앙부처·지자체 종사자 14,208명), ZDNet Korea 2025년 10월 13일 보도
3. 올거나이즈, "RAG 리더보드 공개: 금융, 공공, 의료, 법률, 커머스 한국어 RAG 성능 평가"(2024년 5월). 블로그
4. 대한민국 특허 제10-3031382호 "고유사·중복 말뭉치를 위한 중복 인지 검색평가 데이터셋 구축 방법 및 시스템", 특허권자 올거나이즈코리아, 2026년 10월 7일 등록
5. 올거나이즈, 엔터프라이즈 AI 현장 리포트 "다 맞는 것 같은데, 왜 답이 이상하지?"(2026년 4월). 블로그
6. 아시아경제, 2024년 8월 1일 보도(LH 생성형 AI 업무 기준 질의응답 서비스 구축)
7. 이데일리, 2025년 12월 8일 보도(한전KDN 'KDN GPT' 구축)
8. 머니투데이·AI타임스, 2026년 6월 23일 보도(하나증권 '하나Q')
9. 이데일리, 2026년 7월 15일 보도(한국증권금융 생성형 AI 플랫폼 구축)

‍