사내 문서를 AI에게 학습시켜 질문하면 답해 주는 시스템, 이른바 RAG(Retrieval-Augmented Generation)에 대한 문의가 꾸준합니다. 결론부터 말씀드리면 효과가 확실한 조건이 있고, 기대만큼 나오지 않는 조건도 분명히 있습니다.
효과가 확실한 조건
- 문서는 많은데 검색이 안 되는 경우. 수천 페이지 규모의 매뉴얼이 PDF로 흩어져 있고, 파일명 검색밖에 안 되는 상황이 전형적입니다.
- 같은 질문이 반복되는 경우. 신입 사원이 매번 같은 것을 묻고, 담당자가 매번 같은 답을 하고 있다면 자동화 효과가 즉시 나타납니다.
- 답이 문서 안에 실제로 있는 경우. 당연해 보이지만 중요합니다. RAG는 없는 답을 만들어내는 도구가 아닙니다.
기대만큼 나오지 않는 조건
- 답이 여러 문서에 흩어져 있고 종합적 판단이 필요한 경우. "A 조건과 B 조건이 동시에 성립할 때 어떻게 처리하나요" 같은 질문은 검색으로 근거를 모아도 정확한 결론이 나오기 어렵습니다.
- 문서가 최신이 아닌 경우. AI는 문서가 낡았다는 것을 알지 못합니다. 낡은 답을 자신 있게 말합니다. 이것이 오히려 더 위험합니다.
- 암묵지가 핵심인 경우. 문서화되지 않은 판단 기준은 어떤 기술로도 검색되지 않습니다.
실제 구축에서 시간이 드는 곳
많은 분들이 모델 선택을 가장 중요하게 생각하시지만, 저희 경험상 전체 공수의 배분은 대략 이렇습니다.
문서 파싱 (약 40%)
가장 지루하고 가장 중요합니다. 스캔된 PDF는 OCR이 필요하고, 표는 구조가 깨지고, 도면과 이미지에 담긴 정보는 텍스트로 나오지 않습니다. 여기서 손실된 정보는 뒤에서 어떤 기술로도 복구되지 않습니다.
청킹 전략 (약 20%)
문서를 어떤 단위로 자를지의 문제입니다. 너무 잘게 자르면 맥락이 사라지고, 너무 크게 자르면 검색 정확도가 떨어집니다. 조항 단위로 끊는 것이 좋은 문서가 있고, 절 단위가 맞는 문서가 있습니다. 문서 종류별로 다르게 접근해야 합니다.
검색 품질 개선 (약 25%)
의미 기반 검색만으로는 부족한 경우가 많습니다. 특히 제품 코드, 규격 번호처럼 정확히 일치해야 하는 용어는 키워드 검색이 훨씬 강합니다. 실무에서는 두 방식을 결합한 하이브리드 검색에 재순위화(re-ranking)를 더하는 구성이 안정적입니다.
모델 연동과 프롬프트 (약 15%)
의외로 가장 적습니다. 검색이 정확하면 대부분의 모델이 준수한 답을 만들어냅니다. 반대로 검색이 부정확하면 아무리 좋은 모델을 써도 결과가 나아지지 않습니다.
보안이 걸림돌이라면
"우리 문서를 외부에 보낼 수 없다"는 이유로 검토를 멈추는 경우가 많은데, 지금은 선택지가 넓습니다.
- 오픈소스 모델을 사내 서버에 직접 구동 (GPU 1~2장 규모에서도 실용적인 모델이 있습니다)
- 임베딩만 로컬에서 수행하고 생성만 외부 API 사용
- 기업 전용 폐쇄형 API 활용 (학습에 사용되지 않음을 계약으로 보장)
도입 전 확인할 것
단 하나만 확인하신다면 이것입니다. 지금 사람이 그 문서를 뒤져서 답을 찾을 수 있는가. 사람도 못 찾는 답은 AI도 못 찾습니다. 반대로 사람이 30분 걸려 찾을 수 있는 답이라면, RAG는 그것을 30초로 줄여줍니다. 그 차이가 도입 효과의 전부입니다.
