기업용 AI가 문서를 잘 찾는다고 해서 업무까지 제대로 처리한다고 볼 수는 없다. 여러 시스템의 데이터와 규정이 얽힌 환경에서는 검색 결과보다 관계를 해석하는 기준부터 필요하다.
‘거의 맞는 답’으로 전표를 고칠 것인가
SAP가 2026년 Sapphire에서 공개한 ‘Autonomous Enterprise’의 핵심은 에이전트 수가 아니었다. 45만2,000개 ABAP 테이블과 8만 개 CDS 뷰, 730만 개 필드의 의미를 연결한 지식 그래프였다. 51개 Joule Assistant와 224개 에이전트는 이 업무 지도 위에서 움직인다.
반면 벡터 검색은 질문과 비슷한 문서를 찾는 데 강하다. 하지만 독일 공장의 BOM(자재명세서) 변경이 원가, 원산지, 관세, 물류, 세무에 미칠 영향까지 추적하기는 어렵다. ERP는 문장의 유사성보다 데이터와 규정이 어떻게 연결되는지에 좌우되며, 문서가 정확해도 관계를 놓치면 업무상 오답으로 이어진다.
실제 기업 데이터베이스를 재현한 Spider 2.0에서도 이 한계가 드러났다. 기존 벤치마크에서 좋은 성적을 낸 모델조차 복잡한 스키마와 긴 SQL 작업 앞에서는 문제의 17.1%만 해결했다. 그렇다고 그래프도 모든 경우에 우월하지는 않아 단순한 사실 검색은 벡터가, 여러 단계를 거치는 추론은 GraphRAG가 더 유리하다. 전표와 주문을 직접 수정하는 에이전트에게는 ‘거의 맞는 답’만으로 충분할까.
그래프에는 사람의 판단이 담긴다
지식 그래프는 필드값뿐 아니라 관계까지 저장했다. 어떤 데이터가 어떤 업무와 연결되고, 그 업무에 어떤 정책이 적용되는지까지 담는다. 테이블은 검색으로 찾을 수 있지만, 변경 사항이 어느 규정에 걸리는지는 업무 경험과 해석이 있어야 알 수 있다. 그래프는 이 판단을 기계가 조회할 수 있는 형태로 바꾼다.
SAP가 지식 그래프로 ERP 마이그레이션 공수를 35% 이상 줄일 수 있다고 본 이유 도 같다. 커스텀 필드가 어느 표준 항목에 대응하는지 찾고 검증하는 시간을 줄일 수 있기 때문이다. 같은 문제의식에서 Palantir도 데이터, 로직, 실행, 보안을 하나의 온톨로지에 묶어 에이전트가 통제된 의미 체계를 거쳐 데이터에 접근하게 한다.
이런 구조에서는 역할도 나뉜다.
- 언어 모델은 사용자의 의도를 파악하고 지식 그래프는 관계를 찾으며 관계형 모델은 표 데이터를 예측한다.
- 그러나 조직의 업무 의미를 정의하고 계속 관리하려면 사람의 판단이 필요하며, 그 판단을 유지하는 데 비용이 따른다.
낡은 지도는 더 위험하다
온톨로지는 단번에 못 쓰게 되기보다 현실과 조금씩 어긋난다. 컬럼이 사라지고 담당자와 정책이 바뀌어도 정적 그래프는 예전 관계를 그대로 답으로 내놓는다. 근거와 경로까지 그럴듯하게 붙은 오답은 단순한 환각보다 알아채기 어렵다. 여러 에이전트가 같은 관계를 쓰면 그 영향이 여러 곳으로 번진다.
그래서 그래프는 메타데이터, 데이터 계보, 정책 변경과 실시간으로 연결된다. Atlan이 말하는 활성 온톨로지 는 스키마와 거버넌스의 변화를 감지해 관계를 갱신하고, 에이전트가 필요할 때 이를 조회하게 한다. 한 번 구축하고 끝내는 방식으로 최신성을 지킬 수 있을까.
여기에 시간과 결정 사유도 함께 기록된다.
‘2025년까지 승인된 공급사’와 ‘현재 승인된 공급사’는 다른 사실이다.
승인, 반려 이유까지 기록해야 다음 에이전트가 같은 예외를 다시 조사하지 않는다. 시간 기반 그래프를 사용하는 Zep이 장기 기억 평가에서 기준 시스템보다 최대 18.5% 높은 정확도 를 보인 것도 이런 맥락이다.
기록이 판단의 근거가 되는 만큼, 에이전트에 쓰기 권한을 줄 때는 더 신중하게 접근한다. 새로 추가한 사실마다 출처, 기록 시점, 유효 기간, 삭제 절차가 붙는다. 권한 역시 답을 만든 뒤 가리는 필터가 아니라 검색 경로 자체를 제한하는 조건이어야 한다. 행 단위 권한과 ACL(접근 제어 목록) 버전을 감사 기록에 남기면 누가 어떤 정보로 판단했는지 추적할 수 있다.
업무 지도는 핵심 명사 30개에서 시작한다
비-SAP 조직도 작은 업무 영역부터 지도를 만든다.
먼저 조직이 쓰는 명사부터 통합한다. 고객과 거래처처럼 같은 대상을 가리키는 표현을 정리하고, 고객, 계약, 품목, 공장, 인보이스 등 핵심 엔티티 30~50개부터 정의한다. 처음부터 전사 전체를 모델링하면 검토 범위와 유지비만 커진다.
이어서 업무의 연쇄도 연결한다. 품목 변경이 어떤 승인, 계산, 신고를 촉발하는지 엣지로 표현해야 단순한 목록이 실제 업무 지도가 된다.
승인과 예외의 이유와 시점도 기록한다. 규정만 알고 조직이 허용한 예외를 모르는 에이전트가 사람과 같은 결론에 이를 수 있을까. 그런 에이전트는 사람과 다른 결론을 반복한다.
권한과 정책도 탐색 조건으로 넣는다. MCP 같은 공통 접근 방식을 쓰면 사내 에이전트와 BI 도구가 같은 지표와 정의를 조회할 수 있다. 그러면 도구마다 매출이나 고객 수를 다르게 계산하는 문제도 줄어든다.
다만 초기 정의는 사람이 맡고 유지 작업은 자동화한다. 메타데이터 에이전트가 설명과 관계 후보를 만들고 도메인 담당자가 승인하는 방식이다. 사람은 항목을 일일이 입력하는 대신 정의와 관계가 맞는지 판단한다. 자동 생성된 정보에도 검토자, 근거, 적용 시점을 남겨야 한다.
중요한 것은 지도의 소유권이다
ERP 에이전트가 벡터 검색을 떠나는 이유는 임베딩 성능이 낮아서가 아니다. 핵심 업무의 정답은 비슷한 문서가 아니라 규정, 권한, 파급 관계를 올바른 순서로 따라갈 때 나온다. 답이 한 문서에 있으면 벡터 검색으로 충분하지만, 여러 시스템을 거쳐야 한다면 그래프가 필요하다.
그래프도 전부일 필요는 없어서, 단순한 사실까지 옮기면 비용만 늘고 복잡한 업무를 벡터 검색에만 맡기면 규정과 권한을 놓친다. 질의가 거쳐야 할 단계와 오답의 비용에 따라 두 방식을 함께 쓴다.
구축 상태는 네 질문으로 가늠한다. 같은 대상을 가리키는 명사가 통합돼 있는지, 업무의 연쇄가 관계로 표현돼 있는지, 결정의 이유와 시점이 남아 있는지, 권한이 검색 전에 적용되는지를 본다.
하나라도 빠지면 에이전트는 자연스러운 문장은 만들 수 있어도 안전하게 실행할 근거는 갖추지 못한다. 성능도 문장 품질보다 경로의 정확성과 재현성으로 평가한다.
결국 이 지도는 벤더가 아니라 조직이 소유한다. SAP는 표준 필드의 의미를 제공하지만, 회사마다 다른 커스텀 테이블과 예외 승인 관행까지 대신 정의하지는 않는다. 모델과 제품은 바뀌어도 검증된 엔티티, 관계, 결정 이력은 다시 쓴다. 전사 AI의 장기 자산은 에이전트 수가 아니라, 조직이 직접 관리하는 업무 지도의 정확도에 있다.
그만큼 같은 관계 하나가 더 많은 결정에 재사용될수록 작은 정의 변경의 영향 범위도 넓어진다. 에이전트 시대의 데이터 거버넌스는 변경의 영향을 통제하는 운영 체계로 움직인다. 정보를 보관하는 기능만으로 충분할까.