직원이 생성형 AI에 사내 출장비 규정을 물었는데, 회사 기준과 다른 답변이 돌아왔다고 가정해 보자. 모델이 일반적인 출장 제도를 알고 있어도 우리 회사의 개정 규정까지 아는 것은 아니다. 이때 관련 내부 문서를 찾아 질문과 함께 모델에 전달하는 방식이 RAG다.
RAG는 답변 전에 근거를 찾아 제공하는 방식
RAG는 Retrieval-Augmented Generation의 약자로, 검색 증강 생성이라고 부른다. 질문에 맞는 자료를 검색하고, 검색 결과를 참고 문맥으로 제공해 언어모델이 답변하도록 구성한다. AWS의 설명처럼 내부 지식을 활용하기 위해 매번 모델을 재학습하는 과정이 필수인 것은 아니다.
예를 들어 출장비 규정의 관련 조항을 찾아 모델에 전달하면, 모델은 그 내용을 바탕으로 지급 기준을 설명할 수 있다. 다만 문서를 전달했다고 답변의 정확성이 보장되지는 않는다. 엉뚱한 조항을 찾거나 예외 조건을 놓치면 그럴듯한 오답이 나올 수 있다. 참고: AWS — What is RAG?.
기본 구조는 문서 준비와 질문 처리로 분리
먼저 문서를 검색할 수 있는 상태로 준비한다. PDF나 업무 지침에서 텍스트를 추출하고, 긴 문서를 의미 있는 작은 단위로 나눈다. 이 조각을 청크(chunk)라고 하며, 문서명·조항·시행일·원문 위치 같은 정보도 함께 관리한다.
문서를 나눌 때는 길이만 맞추기보다 의미가 유지되는지 살펴야 한다. ‘지원 대상’과 ‘제외 대상’이 멀리 떨어져 검색되면 조건이 빠질 수 있다. 표는 제목과 열 이름이 사라지지 않도록 추출 결과를 확인하고, 스캔 문서는 문자 인식 오류도 점검한다.
질문이 들어오면 검색 시스템이 관련 조각을 찾고, 애플리케이션이 질문과 선택된 조각을 모델에 전달한다. 모델이 만든 답변에는 확인 가능한 원문 위치를 연결한다. 여기서는 이해를 위해 문서를 미리 색인하는 기본 구성을 설명하며, 원본 저장소를 직접 조회하는 구현도 가능하다. 참고: Microsoft Learn — RAG and Generative AI.
벡터 검색만으로 모든 질문을 해결은 불가
임베딩은 텍스트를 숫자 배열로 표현하는 방법이며, 벡터 검색은 그 표현의 유사성을 이용해 관련 내용을 찾는다. 사용자가 ‘재택근무’를 묻고 문서에는 ‘원격근무’라고 적혀 있어도 관련 문장을 찾는 데 도움을 줄 수 있다. 그러나 유사도가 높다는 것은 해당 내용이 정답이거나 현재 유효하다는 뜻이 아니다.
제품 코드, 규정 번호, 특정 약어처럼 정확한 문자열이 핵심인 질문에는 키워드 검색도 유용하다. 두 방식을 결합하는 하이브리드 검색을 검토할 수 있지만, 실제 질문과 정답 문서로 비교해 선택해야 한다. RAG에 반드시 별도의 벡터 데이터베이스가 필요한 것은 아니며, 검색 방식은 자료와 질문에 맞춰 결정한다.
검색 결과를 많이 넣는다고 답변이 좋아지는 것도 아니다. 관련 없는 문서와 서로 충돌하는 버전이 섞이면 모델이 잘못된 근거를 선택할 수 있다. 관련성, 적용 범위, 문서 상태를 확인해 필요한 근거를 추려 주는 편이 낫다. 참고: Microsoft Learn — RAG and Generative AI.
가상 예시로 보는 사내 규정 질의
가상 예시로, 직원이 ‘숙박비 한도와 사전 승인 조건을 알려줘’라고 질문했다고 하자. 저장소에는 현재 시행 중인 출장 규정과 폐지된 이전 규정이 함께 있다. 시스템은 두 문서의 문장 유사성만 비교하지 말고, 질문 시점과 적용 대상에 맞는 규정을 선택해야 한다.
현재 규정에서 숙박비 한도 조항과 예외 승인 조항을 함께 찾았다면 답변도 두 조건을 묶어 설명한다. 출처에는 규정명과 해당 조항, 시행일을 표시해 직원이 직접 확인할 수 있게 한다. 반대로 예외 승인 조건을 찾지 못했다면 관행을 추측해 채우지 말고 확인하지 못한 부분을 밝혀야 한다.
사용자가 개정 전 출장 건을 묻는다면 당시 적용 규정이 필요할 수 있다. 따라서 가장 최근 문서만 남기는 방식도 항상 맞지는 않는다. 현행·과거·폐지 상태를 구분하고, 질문에 적용할 기준 시점을 확인하는 설계가 필요하다.
문서 권한과 갱신은 검색 단계에서 관리
사내 저장소에 접근할 수 있는 계정으로 문서를 수집했다고 해서 모든 직원에게 그 내용을 보여줘도 되는 것은 아니다. 로그인한 사용자가 열람할 수 있는 문서만 모델의 참고 문맥에 들어가도록 검색과 전달 경로에서 통제해야 한다. 답변 화면에서만 민감한 문장을 가리는 것으로는 부족하다.
Microsoft의 문서 수준 접근 제어 설명에서도 사용자 신원과 문서 권한 정보를 비교해 검색 결과를 제한한다. 색인에 권한 정보를 복사하는 구성은 원본 권한이 바뀐 뒤 동기화되기 전까지 차이가 생길 수 있다. 도입 시에는 권한 변경이 언제 반영되는지와 동기화 실패 시 처리 방식을 확인해야 한다.
운영 관점에서는 본문 수정, 문서 삭제, 접근권한 회수를 별개의 사건으로 관리하는 편이 좋다. 삭제된 문서의 조각이 검색 색인이나 캐시에 남는지, 권한이 바뀐 사용자의 대화 이력에서 과거 답변을 어떻게 처리할지도 정해야 한다. 외부 모델 API를 사용한다면 질문과 문서 조각의 전송 범위, 보관·학습 이용 조건도 계약과 설정으로 확인한다. 참고: Microsoft Learn — Document-Level Access Control.
답변 품질은 검색과 생성을 나누어 점검
RAG 평가에서는 먼저 필요한 문서가 검색됐는지 보고, 다음으로 답변이 그 근거를 충실하게 반영했는지 확인한다. Microsoft의 평가 문서는 검색 관련성, 근거 일치성, 답변 관련성, 완전성을 구분한다. 문서가 맞아도 답변에서 예외 조항이 빠질 수 있으므로 한 가지 점수만으로 판단하기 어렵다.
아래 표는 도입 전 시험에 사용할 수 있는 운영 관점의 점검 예시다. 합격 기준은 업무 위험에 맞춰 정하되, 정상 질문 외에 답이 없는 질문과 권한이 다른 사용자도 포함한다. 자동 평가 결과는 표본 원문 대조와 함께 검토하는 편이 안전하다. 참고: Microsoft Learn — RAG Evaluators.
| 시험 상황 | 확인할 결과 | 실패 시 우선 확인 |
|---|---|---|
| 답이 문서에 있음 | 필요 조항과 예외가 답변에 반영됨 | 추출·청크 분할·검색 순위 |
| 문서에 답이 없음 | 근거 부족을 알리고 추측을 구분함 | 답변 지침·응답 검토 |
| 신구 규정이 함께 있음 | 질문 시점에 맞는 규정을 선택함 | 시행일·문서 상태·필터 |
| 사용자별 권한이 다름 | 미허용 원문·요약·출처가 노출되지 않음 | 권한 필터·캐시 구분 |
| 원문이 수정·삭제됨 | 변경 결과가 정한 기한 안에 반영됨 | 색인·캐시·동기화 실패 |
실무자 관점: 모델 및 문서관리의 순서
운영 관점에서 RAG 도입의 첫 질문은 ‘어떤 모델을 쓸 것인가’보다 ‘어떤 문서를 정답의 기준으로 삼을 것인가’에 가깝다. 같은 내용의 파일이 부서별로 복사돼 있고 승인본과 초안이 구분되지 않으면, 검색 성능을 높여도 무엇을 근거로 답해야 하는지 불분명하다.
처음에는 담당 부서와 승인본이 명확한 한 업무로 범위를 좁히는 편이 현실적이다. 문서 소유자는 내용과 적용 기준을, 시스템 담당자는 검색·권한·갱신 경로를 확인하도록 역할을 정할 수 있다. 시범 운영에서는 답변 속도와 함께 원문 확인에 드는 시간, 오답 수정 절차, 담당자의 유지보수 부담도 살펴야 한다.
규정 안내는 문서 기반 RAG에 잘 맞을 수 있지만, 현재 재고나 개인별 잔여 휴가처럼 계속 바뀌는 값은 권한을 확인한 업무 시스템 조회가 더 적합할 수 있다. 실제 승인·발주 같은 변경 작업은 별도의 권한과 승인 절차가 필요하다. 문서를 설명하는 기능과 업무를 실행하는 기능을 같은 범위로 취급하지 않는 것이 좋다.
도입 범위는 근거를 유지할 수 있는 업무부터 설정
RAG의 가치는 내부 문서를 질문에 맞춰 찾아 주고, 그 근거를 확인하면서 답변을 활용하게 하는 데 있다. 시작 범위는 승인된 문서, 적용 시점, 열람 권한, 갱신 책임을 분명히 정할 수 있는 업무로 잡는 편이 좋다. 근거를 찾지 못했을 때 멈추고 확인을 요청하는 동작까지 검증해야 현업에서 사용할 수 있는 도구가 된다.