책에 포함된 노트AX 전환의 기술: AI 중심 조직은 어떻게 만들어지는가

사내 지식과 RAG

2026-05-17Views 43약 9분생성형 AI 활용

Summary

사내 지식 AI는 문서 검색에서 시작된다

많은 기업이 생성형 AI를 도입한 뒤 같은 문제를 만난다. 일반적인 질문에는 답을 잘하지만, 우리 회사의 규정, 제품 정책, 고객 대응 기준, 내부 절차에는 제대로 답하지 못한다. 이유는 단순하다. LLM은 회사 내부 문서를 기본적으로 알지 못한다. 모델이 학습한 공개 지식과 기업이 매일 쓰는 최신 업무 지식 사이에는 간격이 있다.

이 간격을 줄이는 대표적인 방식이 RAG다. RAG는 Retrieval-Augmented Generation, 즉 검색 증강 생성의 약자다. 쉽게 말하면 AI가 답변을 만들기 전에 사내 문서나 업무 매뉴얼을 먼저 검색하고, 그 검색 결과를 근거로 답변하게 만드는 구조다. AWS는 RAG를 LLM이 자체 학습 데이터에만 의존하지 않고 신뢰할 수 있는 외부 지식 원천을 참고해 답변 품질을 높이는 방식으로 설명한다.¹

중요한 점은 RAG가 LLM을 매번 재학습시키는 방식이 아니라는 것이다. 회사의 인사 규정이 바뀌거나 영업 제안서 양식이 업데이트될 때마다 모델을 새로 훈련시키는 것은 비용과 시간이 많이 든다. RAG는 모델 밖에 있는 최신 문서 저장소를 연결한다. SharePoint, Notion, Google Drive, Confluence, 사내 위키, PDF 매뉴얼, 고객지원 지식베이스, 제품 문서 같은 자료를 검색 대상으로 삼고, 필요한 내용만 답변 생성에 넣는다.

따라서 RAG의 목적은 "AI가 더 많이 말하게 하는 것"이 아니다. AI가 근거 있는 답변을 하게 만드는 것이다. 좋은 사내 지식 AI는 그럴듯한 문장을 만드는 도구가 아니라 "어떤 문서의 어떤 내용에 근거했는지"를 함께 보여주는 업무 시스템이어야 한다.

사내 지식과 RAG AI 생성 이미지

RAG의 기본 흐름

사내 RAG는 겉으로 보면 챗봇처럼 보인다. 직원이 "육아휴직 신청 절차를 알려줘"라고 묻고, AI가 답한다. 그러나 내부에서는 여러 단계가 움직인다.

첫째, 문서 연결과 수집이다. 사내 문서가 있는 저장소를 연결한다. SharePoint, OneDrive, Google Drive, Notion, Confluence, 사내 파일 서버, 데이터베이스 등이 대상이 된다. 이 단계에서는 "무엇을 가져올 것인가"만큼 "무엇을 가져오지 않을 것인가"도 중요하다. 오래된 문서, 개인 메모, 승인되지 않은 초안이 섞이면 답변 품질이 떨어진다.

둘째, 파싱이다. 파싱은 문서를 AI가 읽을 수 있는 형태로 해석하는 과정이다. PDF, HTML, 워드 문서, 표, 목록, 이미지가 포함된 문서는 단순 텍스트 파일처럼 다룰 수 없다. 표의 행과 열, 제목과 본문, 번호 목록, 정책 문서의 조항 구조가 깨지면 검색 결과도 망가진다.

셋째, 정제다. 중복 문구, 페이지 머리말과 꼬리말, 광고 문구, 깨진 문자, 불필요한 서식 정보를 제거한다. 문서가 지저분하면 AI도 지저분한 근거를 읽는다. 이 단계에서 문서 제목, 작성 부서, 최신 수정일, 문서 유형, 보안 등급 같은 메타데이터도 함께 붙인다.

넷째, 구조 보존형 분할이다. 긴 문서를 작은 단위로 나누는 일을 청킹이라고 한다. 문제는 아무 지점에서나 자르면 안 된다는 점이다. "휴가 신청 기준"이라는 제목과 그 아래 내용이 분리되면 AI는 문맥을 잃는다. 표의 일부만 잘리거나 예외 조항이 다음 청크로 떨어져 나가도 위험하다. 운영 환경의 RAG에서는 문서 구조를 고려해 제목, 표, 목록, 조항, 섹션 단위를 최대한 보존해야 한다.²

다섯째, 임베딩과 색인이다. 임베딩은 문장이나 문서 조각의 의미를 숫자 벡터로 바꾸는 과정이다. 이렇게 바꿔 두면 사용자가 정확한 단어를 쓰지 않아도 의미가 비슷한 문서를 찾을 수 있다. 색인은 이 벡터와 메타데이터를 빠르게 검색할 수 있도록 저장하는 구조다.

여섯째, 검색과 답변 생성이다. 사용자가 질문하면 시스템은 먼저 관련 문서 조각을 찾는다. 그다음 LLM에게 "아래 근거만 사용해서 답하라"고 지시한다. 마지막으로 답변과 함께 출처를 표시한다. Microsoft도 기업용 RAG의 핵심을 조직 고유의 신뢰 가능한 콘텐츠를 검색해 근거 있고 인용 가능한 답변을 만드는 데 둔다.³

검색 품질이 답변 품질을 결정한다

RAG를 만들 때 가장 흔한 실수는 문서를 많이 넣으면 좋아질 것이라고 생각하는 것이다. 실제로는 반대인 경우가 많다. 문서를 무작정 넣으면 중복, 과거 버전, 잘못된 분할, 권한 오류가 함께 들어간다. 그러면 AI는 더 많은 자료 속에서 더 헷갈린다.

RAG 품질은 검색 품질에서 시작된다. 검색이 잘못되면 LLM이 아무리 좋아도 좋은 답변을 만들 수 없다. 엉뚱한 문서를 근거로 받으면 엉뚱한 답을 정리할 뿐이다.

검색 품질을 높이려면 먼저 청크 크기를 조정해야 한다. 너무 작으면 문맥이 사라진다. 너무 크면 질문과 직접 관련 없는 내용이 많이 섞인다. 예를 들어 인사 규정은 조항과 예외 조건을 함께 담을 정도의 크기가 필요하다. 반면 제품 FAQ는 질문 하나와 답변 하나를 비교적 작은 단위로 나누는 편이 좋다.

제목과 본문의 연결도 중요하다. "신청 기한은 7일 전까지"라는 문장만 따로 저장하면 무엇의 신청 기한인지 알 수 없다. "연차휴가 신청 기한"이라는 제목과 함께 저장되어야 한다. 표도 마찬가지다. "A등급 10만 원"이라는 값만 검색되면 의미가 없다. 어떤 수당, 어떤 조건, 어떤 적용 기간의 금액인지 함께 보존되어야 한다.

키워드 검색과 의미 검색을 함께 쓰는 것도 중요하다. 의미 검색은 표현이 달라도 비슷한 내용을 찾는 데 강하다. 그러나 제품 코드, 계약 번호, 법령 조항, 내부 프로젝트명처럼 정확한 단어가 중요한 경우에는 키워드 검색이 필요하다. 그래서 실제 기업 RAG에서는 벡터 검색과 키워드 검색을 결합한 하이브리드 검색, 그리고 검색 후보를 다시 정렬하는 재순위화 방식이 자주 쓰인다.⁴

메타데이터는 검색 품질을 좌우하는 또 하나의 축이다. 문서마다 부서, 업무 영역, 문서 유형, 작성자, 승인자, 버전, 적용 기간, 보안 등급, 원본 URL을 붙여야 한다. 사용자가 "해외 출장비 기준"을 물었을 때, 시스템은 단순히 비슷한 문장을 찾는 것이 아니라 최신 재무 규정, 적용 중인 버전, 사용자가 접근 가능한 문서만 골라야 한다.

좋은 RAG는 답변을 이렇게 만든다.

"현재 해외 출장 일비 기준은 ○○입니다."
"근거는 2026년 3월 개정된 '해외 출장비 운영 기준'입니다."
"다만 임원 출장과 장기 파견은 별도 기준이 적용됩니다."
"관련 문서 링크는 아래와 같습니다."

반대로 나쁜 RAG는 이렇게 답한다.

"일반적으로 해외 출장비는 회사 규정에 따라 지급됩니다."

후자는 틀린 말은 아니지만 업무에 쓸 수 없다. 사내 지식 AI의 가치는 일반론이 아니라 특정 회사의 최신 기준을 정확히 찾아주는 데 있다.

권한 관리는 엔터프라이즈 RAG의 핵심이다

사내 RAG에서 가장 위험한 문제는 AI가 사용자가 볼 수 없는 문서를 답변에 섞는 것이다. 예를 들어 일반 직원이 임원 보상 정책, 인수합병 문서, 특정 직원의 인사 평가, 고객 계약 조건을 간접적으로 알게 된다면 심각한 보안 사고가 된다.

따라서 엔터프라이즈 RAG는 사용자의 신원 확인에서 시작해야 한다. 누가 질문했는지 확인하고, 그 사람이 어떤 부서에 속해 있으며, 어떤 문서에 접근할 수 있는지 확인해야 한다. 그런 다음 검색 단계에서 접근 가능한 문서만 후보로 가져와야 한다.

권한 관리는 생성 단계에서도 필요하다. 검색 단계에서 걸러졌더라도 답변 생성 과정에서 민감 정보가 노출될 수 있다. 예를 들어 여러 문서의 일부 정보를 조합하면 원래 문서보다 더 민감한 결론이 만들어질 수 있다. 그래서 AI 답변에도 정책 필터, 민감정보 탐지, 출력 제한, 로그 기록이 필요하다.

기업용 RAG에서 권한은 원본 시스템과 분리되어서는 안 된다. SharePoint에서 볼 수 없는 문서는 RAG에서도 볼 수 없어야 한다. 인사팀 전용 문서는 인사팀 권한이 있는 사용자에게만 검색되어야 한다. Microsoft는 SharePoint와 OneDrive 같은 내부 콘텐츠 검색에서 사용자의 기존 권한에 따라 결과가 제한되는 보안 트리밍을 중요한 기업 기능으로 다룬다.⁵

운영 원칙은 명확하다.

검색 전에 사용자를 인증한다.
원본 문서의 접근 권한을 지식 계층에도 유지한다.
사용자가 볼 수 없는 문서는 검색 결과에 포함하지 않는다.
답변에는 허용된 문서의 내용만 사용한다.
어떤 사용자가 어떤 문서를 근거로 어떤 답변을 받았는지 로그를 남긴다.

이 기준이 없으면 RAG는 생산성 도구가 아니라 정보 유출 통로가 된다.

사내 RAG 구축 체크리스트

사내 RAG를 시작할 때는 챗봇 화면보다 먼저 운영 질문을 정리해야 한다. 다음 항목이 비어 있으면 데모는 가능해도 실제 업무 사용은 어렵다.

1. 문서 범위
어떤 문서를 먼저 연결할 것인가. 전사 문서를 한 번에 넣기보다 반복 질문이 많고 권한 구조가 단순한 영역부터 시작한다. 인사 온보딩, IT 헬프데스크, 고객지원 FAQ, 영업 제안서 템플릿, 제품 매뉴얼이 좋은 출발점이다.

2. 데이터 소스
문서가 어디에 있는지 정리한다. SharePoint, Notion, Google Drive, Confluence, 사내 위키, 파일 서버, CRM 첨부 문서 등 원천별 연결 방식을 정한다.

3. 사용자 그룹과 권한
누가 어떤 문서를 볼 수 있는지 정의한다. 전 직원, 특정 부서, 관리자, 프로젝트 구성원처럼 그룹을 나누고, 원본 시스템의 권한과 RAG 검색 권한이 어긋나지 않게 한다.

4. 문서 구조와 메타데이터
제목, 섹션, 표, 목록, 버전, 작성자, 승인자, 적용 기간, 보안 등급, 원본 링크를 보존한다. 검색은 내용만이 아니라 구조와 맥락을 함께 사용해야 한다.

5. 출처 표시 방식
답변마다 근거 문서명, 문서 버전, 수정일, 링크를 표시한다. 가능하면 답변 문장과 근거 문단을 연결한다. 사용자는 AI의 말이 아니라 근거를 보고 신뢰한다.

6. 평가 데이터셋
자주 묻는 질문, 예외 질문, 답하면 안 되는 질문, 권한이 필요한 질문을 모아 테스트 세트를 만든다. 정확성, 근거성, 유용성, 보안성을 기준으로 정기 평가한다.

7. 운영 담당자와 개선 주기
문서 수집 오류, 검색 실패, 잘못된 답변, 오래된 근거, 사용자 불만을 누가 확인할지 정한다. 월 1회 또는 분기 1회 지식베이스 리뷰를 운영한다.

8. 로그와 감사
누가, 언제, 어떤 질문을 했고, 어떤 문서가 검색되었으며, 어떤 답변이 생성되었는지 기록한다. 이는 감시가 아니라 품질 개선과 보안 사고 대응을 위한 장치다.

목표는 데모 챗봇이 아니라 신뢰할 수 있는 지식 AI다

RAG는 사내 AI의 핵심 기반이다. 그러나 RAG를 단순히 "문서 넣고 질문하는 챗봇"으로 이해하면 실패한다. 실제 업무에 쓰이는 RAG는 문서 구조, 검색 품질, 권한 관리, 최신성, 출처 표시, 평가 체계가 함께 작동해야 한다.

직원이 사내 지식 AI를 반복해서 쓰려면 한 가지 조건이 필요하다. 답변이 빠른 것보다 믿을 수 있어야 한다. 믿을 수 있다는 것은 항상 완벽하다는 뜻이 아니다. 근거를 보여주고, 모르면 모른다고 말하며, 접근 권한을 지키고, 오래된 문서를 근거로 삼지 않는다는 뜻이다.

AX 전환에서 RAG는 중요한 전환점이다. 회사의 문서와 노하우가 개인의 기억, 부서 폴더, 오래된 매뉴얼 속에 머무르지 않고 업무 순간에 호출되는 지식으로 바뀌기 때문이다. 이때 AI는 단순한 답변기가 아니라 조직 지식을 연결하는 인터페이스가 된다.

기업이 RAG를 제대로 구축하면 직원은 정보를 찾는 데 쓰던 시간을 줄이고, 더 빠르게 기준을 확인하며, 더 일관된 판단을 내릴 수 있다. 이것이 사내 지식 AI의 본질이다. 더 많은 문서를 넣는 것이 아니라, 필요한 순간에 신뢰할 수 있는 지식을 꺼내 쓰게 만드는 것이다.