기업용 AI에는 지식을 한 번 관리하고 모든 AI가 공유하는 플랫폼이 필요하다

개별 앱 단위로 컨텍스트를 설계하던 방식이 한계에 부딪혔다. 이제 기업용 AI는 지식을 한 번만 관리하고 모든 애플리케이션이 재사용하는 '전사 지식 플랫폼(Enterprise Knowledge Platform)' 아키텍처로 전환하는 추세다. 개별 앱마다 지식을 따로 구축하던 파편화된 방식에서 벗어나, 전사적 차원의 지식 자산을 통합 관리하는 구조다.

이 플랫폼은 구조화된 데이터를 다루는 기업 데이터 플랫폼과 유사하게 작동한다. 문서, 소스 코드, Jira 티켓, 이메일, API 등을 단순한 입력값이 아닌 공유 자산으로 취급하며, 공통 아키텍처를 통해 거버넌스를 수행한다.

전체 프로세스는 Raw, Refined, Integrated, Serving의 4개 계층으로 분리된다. 원본 소스를 보존하는 Raw 계층부터 이기종 소스를 정규화하는 Refined, 분산된 지식을 연결하는 Integrated, 그리고 AI 에이전트가 사용할 수 있게 발행하는 Serving 계층으로 이어진다. 이렇게 계층을 분리하면 각 단계가 독립적으로 진화하면서도 전체적인 지식 기반의 일관성을 유지할 수 있다.

현재 기업용 AI는 개별 애플리케이션 중심의 컨텍스트 구축에 머물러 있다

많은 팀이 여전히 앱마다 데이터 청크를 생성하고 임베딩 및 검색 파이프라인을 구축하는 '컨텍스트 엔지니어링' 방식에 의존한다. AI 모델이 답변에 필요한 특정 정보를 참조하도록 데이터를 구성하는 이 방식은 단일 어시스턴트를 빠르게 구현할 때는 효과적이다. 하지만 앱 숫자가 늘어날수록 지식을 공유 자산이 아닌 앱 전용 컨텍스트로 취급하게 되어, 결국 지식 관리 체계가 붕괴되는 결과로 이어진다.

이 문제를 해결하는 첫 단추가 Raw 계층이다. 여기서는 PDF, Confluence, Jira 티켓, API 응답, 이메일, 이미지 등 기업 시스템의 정보를 원본 형태와 소스 식별자 그대로 캡처한다. 당장 에이전트가 사용할 수 있는 상태로 만드는 것이 목적이 아니다. 향후 추출 로직이나 사용 모델이 변경되었을 때, 하위 지식을 처음부터 다시 처리할 수 있도록 '신뢰할 수 있는 원천 소스'를 확보하는 것이 핵심이다.

개별 애플리케이션 중심의 AI 구축 방식은 지식 불일치와 변경 관리의 한계를 만든다

앱마다 지식 파이프라인을 따로 구축하면 동일한 정보에 대해서도 AI 에이전트마다 서로 다르게 이해하는 불일치 현상이 발생한다. 이는 Jira와 같은 시스템별 스키마와 정의가 다르기 때문이다. 정보가 수정될 때마다 연결된 모든 앱의 파이프라인을 개별 업데이트해야 하며, 여러 팀이 동일한 파이프라인을 반복해서 만드는 리소스 낭비가 필연적으로 발생한다.

Refined 계층(정제 계층)은 이러한 파편화된 소스들을 정규화해 '관리형 지식 객체(managed knowledge objects)'로 변환한다. 각 소스는 정체성을 유지하되 ID, 작성자, 버전, 권한, 리니지(lineage, 데이터 이력) 및 원본 참조 정보를 포함한 일관된 표현으로 바뀐다. 예를 들어 제품 요구 사항 문서는 소스 종류와 상관없이 문서 ID와 제품 ID, 태그가 포함된 구조화된 객체로 변환되어 동일한 관리 체계 아래 놓이게 된다.

결국 AI의 추론 능력은 단순한 데이터 연결(Link)이 아니라 비즈니스 관계(Business Relationship)를 어떻게 모델링했느냐에 따라 결정된다. 이제 AI 아키텍처의 성패는 개별 앱의 성능이 아니라, 전사 지식의 관계 모델링 수준을 얼마나 확보했는지로 판단해야 한다.