사내 데이터는 많은데, AI는 왜 아무것도 인용하지 못할까?

많은 기업이 인사 규정, 노무 지침, 내부 문서 양식, 제품 스펙, 프로젝트 산출물, 임직원 연락처까지 방대한 데이터를 보유하고 있다. 문제는 이 데이터들이 내부망(Intranet) 안에 갇혀 있다는 점이다. 외부 LLM을 그대로 연결할 수도 없고, 그렇다고 모든 데이터를 한꺼번에 학습시키는 방식은 보안·정확성·운영 측면에서 현실적이지 않다. 이 지점에서 RAG(Retrieval-Augmented Generation)는 단순한 AI 기술이 아니라 기업 데이터 자산화의 설계 철학으로 다시 정의될 필요가 있다.

시장의 니즈: ‘학습된 AI’가 아니라 ‘읽을 수 있는 AI’

기업이 원하는 것은 “우리 데이터를 다 외운 AI”가 아니다. 실제 니즈는 "필요한 순간에, 적절한 데이터만, 맥락을 잃지 않고 참조하는 AI"일 것다. 특히 내부망 환경에서는 다음과 같은 요구가 동시에 발생한다.

첫째, 외부로 데이터가 유출되지 않을 것.

둘째, 답변의 근거가 명확히 추적 가능할 것.

셋째, 데이터가 변경되면 AI의 답변도 즉시 달라질 것.

이 세 가지 요구를 동시에 만족시키는 접근이 바로 RAG 중심 설계다.

흔한 오해: “다 모아서 학습시키면 해결된다”

많은 내부 자산화 프로젝트가 여기서 실패한다. 인사 문서, 매뉴얼, PDF, 엑셀, 이메일을 모두 긁어모아 벡터화하고 “이제 AI가 알아서 답하겠지”라고 기대한다. 그러나 결과는 대부분 비슷하다. 답변은 그럴듯하지만 미묘하게 틀리고, 기준 시점이 불분명하며, 누가 책임질 수 없는 문장이 생성된다. 이는 기술의 문제가 아니라 설계 단계에서 인간의 역할을 제거했기 때문이다.

내부망 RAG 설계의 핵심 1: 데이터는 ‘모으는 것’이 아니라 ‘정의하는 것’

RAG 설계의 출발점은 수집이 아니라 분류와 정의다. 내부 데이터는 다음과 같이 재구성되어야 한다.

– 어떤 데이터가 사실(Fact)인가

– 어떤 데이터가 정책(Policy)인가

– 어떤 데이터가 가이드(Guideline)인가

– 어떤 데이터가 시점 의존적인가

이 구분이 없으면 검색 정확도도, 답변 신뢰성도 확보할 수 없다. 즉, 벡터DB 이전에 정보 아키텍처 설계가 선행되어야 한다.

내부망 RAG 설계의 핵심 2: 검색 단위는 문서가 아니라 ‘의미’

기업 문서는 대부분 AI 친화적이지 않다. 한 문서 안에 배경, 예외, 부칙이 뒤섞여 있다. 내부망 RAG에서는 문서를 그대로 쪼개는 것이 아니라, 업무 맥락 단위로 재구성된 청크가 필요하다. 예를 들어 ‘연차 규정’이라는 문서가 아니라 ‘연차 발생 조건’, ‘연차 이월 규칙’, ‘연차 소멸 시점’처럼 질문과 직접 연결되는 단위가 되어야 한다.

내부망 RAG 설계의 핵심 3: 인간의 개입은 줄이는 것이 아니라 바꿔야 한다

이런 프로젝트에서 자주 등장하는 질문이 있다. “데이터 아노테이션(Annotation) 같은 수작업이 필요한가?” 답은 "그렇다, 그러나 우리가 알고 있는 형태의 아노테이션은 아니다"이다. 기업 내부 RAG에서 인간이 해야 할 일은 정답을 태깅하는 것이 아니라, "이 정보는 언제 쓰이는가, 어떤 질문에 인용되어야 하는가, AI가 답변할 수 없는 경계는 어디인가" 를 정의하는 일이다. 이는 데이터 라벨링이 아니라 지식 설계(Knowledge Design)에 가깝다.

기술적 도전 과제: 보안·권한·로그

내부망 RAG는 기술적으로도 외부 서비스와 전혀 다른 요구를 가진다.

– 부서별·직급별 접근 권한에 따라 검색 결과가 달라져야 하고

– 어떤 문서가 언제 인용되었는지 로그가 남아야 하며

– 답변 결과를 감사(Audit) 관점에서 재현할 수 있어야 한다

이 때문에 내부망 RAG는 단순한 API 연동이 아니라 권한 관리, 감사 로그, 데이터 버전 관리가 결합된 구조로 설계되어야 한다.

이롭게(Iropke)의 관점: RAG는 기능이 아니라 ‘조직의 기억 구조’다

이롭게(Iropke)는 이러한 유형의 프로젝트를 “데이터들을 긁어 모아서 AI를 붙이는 기술”로 보지 않는다. 이는 기업이 스스로의 지식을 어떻게 정의하고, 어떤 기준으로 축적하며, 누구에게 어떻게 전달할 것인가에 대한 조직 설계의 문제다. 그래서 접근 방식도 다르다.

– 우리는 데이터를 먼저 넣지 않는다. 질문을 먼저 정의한다.

– 우리는 모델을 먼저 고르지 않는다. 책임 구조를 먼저 설계한다.

– 그리고 마지막에 기술을 배치한다.

결론: AI는 데이터의 구조를 읽는 방식으로 학습한다

기업의 데이터는 이미 충분히 많다. 문제는 AI가 그것을 자산으로 인식할 수 있는 구조가 없다는 점이다. 내부망 환경에서의 RAG는 비용을 줄이기 위한 기술 선택이 아니라, 기업의 지식이 사라지지 않게 만드는 인프라다. AI가 똑똑해지길 기다릴 필요는 없다. 먼저, AI가 읽을 수 있는 형태로 기업의 데이터를 다시 설계해야 할 때다.