회사의 문서를 AI에 연결하면 AI가 우리 회사를 알게 될까.
RAG는 이 질문에 가장 널리 사용되는 답이다. 사내 문서를 잘게 나누어 검색할 수 있게 만들고, 질문과 관련된 내용을 찾아 AI의 답변에 넣어준다. AI가 학습하지 않은 회사 자료를 참고할 수 있고, 답변의 근거도 제시할 수 있다.
분명히 유용하다. 그러나 여기서 한 가지를 구분해야 한다.
관련 문서를 찾는 것과 회사가 무엇을 알고 있는지는 같은 일이 아니다.
RAG는 검색의 문제를 크게 개선한다. 하지만 어느 문서가 맞는지, 무엇이 지금도 유효한지, 충돌하는 규칙 중 무엇을 따라야 하는지까지 저절로 판단해주지는 않는다.
문서를 모두 연결해도 답이 하나가 되지 않는 이유
회사에는 같은 주제를 다루는 문서가 여러 개 있다.
지난해의 가격표와 올해의 가격표가 함께 남아 있고, 회의에서 바뀐 정책이 정식 문서에는 아직 반영되지 않았을 수 있다. 영업팀과 운영팀이 같은 고객 상태를 서로 다른 의미로 사용할 수도 있다. 예외적으로 승인된 사례가 나중에는 일반 원칙처럼 복사되어 있을 수도 있다.
RAG는 질문과 비슷한 문장을 잘 찾는다. 그러나 비슷하다는 사실이 곧 옳다는 뜻은 아니다.
예를 들어 AI가 “이 고객에게 할인을 제공할 수 있는가”라는 질문을 받았다고 해보자. 검색 결과에는 다음 자료가 함께 나올 수 있다.
- 현재 가격 정책
- 폐기되지 않은 과거 가격표
- 특정 고객에게만 적용된 예외 승인
- 영업 담당자의 회의 메모
- 제안서에 복사된 오래된 할인 조건
이 자료를 모두 찾았다는 것은 검색의 성공이다. 하지만 무엇을 따라야 하는지는 여전히 판단의 문제다.
회사의 지식에는 권위와 시간이 필요하다
문서에는 내용이 있다. 지식에는 그 내용의 지위가 있어야 한다.
- 누가 이 정의와 정책을 책임지는가
- 언제부터 언제까지 유효한가
- 무엇을 대체하거나 폐기했는가
- 일반 원칙인가, 한 번의 예외인가
- 어떤 조건에서 적용되는가
- 서로 충돌할 때 무엇이 우선하는가
이 정보가 없으면 AI는 최신 문서와 오래된 문서를 비슷한 근거로 취급할 수 있다. 출처가 명확한 정책과 개인 메모의 문장이 검색 점수만으로 나란히 놓인다.
사람은 조직의 맥락을 통해 어느 쪽을 믿어야 하는지 짐작한다. AI가 같은 판단을 하게 하려면 그 맥락을 구조로 만들어야 한다.
원문 기록과 현재 지식은 역할이 다르다
그렇다고 오래된 문서와 회의 기록을 삭제해야 하는 것은 아니다.
원문은 중요한 근거다. 언제 어떤 논의가 있었고, 무엇을 바꾸었으며, 왜 예외를 허용했는지 확인하려면 과거 기록이 필요하다. 법적 보존과 감사, 재검토를 위해서도 남겨야 한다.
다만 원문 기록 전체를 현재의 지식처럼 사용해서는 안 된다.
회사에는 두 개의 층이 필요하다.
- 원문과 증거의 층
회의록, 대화, 계약서, 보고서, 운영 데이터처럼 실제로 발생한 기록을 보존한다.
- 현재 지식의 층
지금 유효한 정의, 정책, 결정, 책임자와 예외를 짧고 명확하게 정리한다.
RAG는 첫 번째 층을 탐색하는 데 강하다. 두 번째 층은 조직이 지속적으로 편집하고 책임져야 한다.
좋은 답변보다 안전한 행동이 더 어려운 문제다
AI가 문서를 요약하는 데 그친다면 잘못된 답을 사용자가 버릴 수 있다. 그러나 Agent가 실제 시스템을 사용하기 시작하면 지식의 모호함은 행동의 위험이 된다.
- 오래된 계좌로 송금 정보를 안내할 수 있다
- 폐기된 가격 정책으로 제안서를 만들 수 있다
- 특정 고객의 예외를 모든 고객에게 적용할 수 있다
- 내부 자료를 외부 문서에 포함할 수 있다
- 승인되지 않은 상태 변경을 실행할 수 있다
이때 필요한 것은 검색 정확도만이 아니다. 행동 전에 확인해야 할 규칙, 필요한 승인, 허용된 도구와 권한이 함께 있어야 한다.
RAG가 “무슨 자료가 관련 있는가”를 돕는다면, 기업용 harness는 “그 자료를 근거로 무엇까지 할 수 있는가”를 통제해야 한다.
Graph RAG와 Ontology가 모든 문제를 자동으로 해결할까
문서 사이의 관계를 그래프로 만들고 회사의 개념을 ontology로 정의하면 RAG의 한계를 상당 부분 보완할 수 있다.
고객과 계약, 프로젝트와 담당자, 정책과 예외의 관계가 명확해지면 AI는 단순한 문장 유사도보다 더 정확한 맥락을 사용할 수 있다. 어떤 문서가 어떤 결정을 대체했는지도 표현할 수 있다.
그러나 그래프나 ontology 자체가 진실을 만들어주지는 않는다.
현업이 사용하지 않는 분류 체계, 갱신되지 않은 관계, 책임자가 없는 정의는 정교한 형태의 오래된 문서가 될 뿐이다. 기술적으로 훌륭한 지식 그래프도 실제 결정과 업무에서 계속 수정되지 않으면 곧 현실과 멀어진다.
그래서 ontology는 완성된 설계도로 도입되기보다 업무에서 자라야 한다. 반복해서 등장하는 개념과 결정이 wiki에 정리되고, 실제 시스템과 원문에 연결되며, 필요한 부분부터 구조화되어야 한다.
회사의 지식은 책임 있는 편집의 결과다
회사 지식을 만드는 일은 문서를 한곳에 모으는 프로젝트가 아니다.
누군가는 중복된 정의를 합쳐야 하고, 오래된 정책을 폐기해야 하며, 예외가 원칙을 바꾸었는지 판단해야 한다. 중요한 결정에는 책임자와 검토 시점이 있어야 한다. AI가 초안을 만들고 충돌을 찾아줄 수 있지만, 무엇이 회사의 공식 지식인지는 조직이 결정해야 한다.
좋은 지식 시스템에는 최소한 다음 순환이 필요하다.
- 업무에서 대화와 결과, 결정이 발생한다.
- 원문은 증거로 보존된다.
- 반복해서 필요한 지식은 짧은 페이지로 증류된다.
- 책임자가 정의와 유효성을 승인한다.
- Agent가 다음 업무에서 그 지식을 사용한다.
- 오류와 새로운 결정이 다시 지식을 수정한다.
이 순환이 없다면 RAG는 문서를 더 빨리 찾게 해줄 뿐, 조직을 더 잘 기억하게 하지는 못한다.
RAG의 성공 기준을 다시 정해야 한다
RAG 프로젝트는 흔히 검색 정확도와 답변 품질로 평가된다. 필요한 지표지만 기업 업무에는 충분하지 않다.
함께 물어야 할 질문이 있다.
- 답변이 현재 유효한 자료를 사용했는가
- 권위 있는 출처와 개인 메모를 구분했는가
- 충돌하는 정보가 있을 때 이를 드러냈는가
- 원문으로 돌아가 판단을 검증할 수 있는가
- 잘못된 지식으로 행동하지 않도록 승인 조건이 있는가
- 오류가 발견됐을 때 공통 지식이 수정되는가
이 질문에 답하지 못하면 검색 데모는 성공했어도 회사의 지식 시스템은 만들어지지 않은 것이다.
검색 가능한 회사에서 학습하는 회사로
RAG는 기업 AI의 중요한 부품이다. 관련 자료를 빠르게 찾고 모델이 회사의 원문을 참고하게 하는 능력은 반드시 필요하다.
그러나 RAG를 회사의 지식 그 자체로 착각하면 문서의 양과 검색 품질에만 투자하게 된다. 회사가 실제로 알아야 하는 것은 어느 문장이 관련 있는가를 넘어, 무엇이 현재 사실이고 누가 책임지며 어떤 행동으로 이어질 수 있는가이다.
문서를 연결하면 검색 가능한 회사가 된다.
원문을 보존하고, 현재 지식을 증류하고, 권위와 관계를 명시하며, 실행과 오류를 다시 반영할 때 비로소 학습하는 회사가 된다.
RAG는 그 여정의 시작이지 완성은 아니다.