들어가며

AI가 보험사에 전화를 걸어 어떤 치료가 보장되는지 확인했습니다. 같은 보험 상품과 같은 치료 조건으로 열 번을 확인했고 답도 모두 같았습니다. 그런데 열한 번째 환자가 오자 AI는 다시 보험사에 전화를 겁니다. 앞서 확인한 내용은 통화 기록으로 남았지만 다음 판단에 쓸 수 있는 지식으로 남지 않았기 때문입니다.

미국의 헬스케어 AI 기업 Infinitus의 CTO가 든 예입니다. 이 회사는 실제로 AI 에이전트로 보험 확인 전화를 자동화하고 있었습니다. 하지만 통화를 대신하는 것과 통화에서 배운 내용을 기억하는 것은 다른 문제였습니다. Infinitus는 보험사, 보험 상품, 치료, 지역, 나이 조건과 과거 확인 결과를 그래프로 연결했습니다. 최신의 검증된 답이 있으면 전화를 생략하고 몇 초 만에 답합니다. 답이 없거나 오래됐다면 그때만 전화를 걸고 새로 확인한 내용을 다시 그래프에 넣습니다.

이 구조를 Infinitus는 Knowledge Layer라고 부릅니다. 요즘 기업 AI 업계에서 말하는 Context Graph, 우리말로 컨텍스트 그래프와 매우 닮았습니다.

앞선 글 AX는 암묵지를 자산화할 수 있어야 성공합니다 에서 컨텍스트 그래프를 짧게 소개했습니다. 문서와 사람의 기억에 흩어진 업무 맥락을 AI가 따라갈 수 있는 지도로 만든다는 내용이었습니다. 이번 글에서는 한 걸음 더 들어가 보겠습니다.

먼저 결론부터 말씀드리면 컨텍스트 그래프는 새로운 그래프 데이터베이스 상품을 뜻하지 않습니다. 조직의 사람과 업무 대상, 정책을 실제 행동과 판단, 승인, 예외, 결과에 연결해 다음 사람과 AI 에이전트가 다시 사용할 수 있게 만든 조직의 운영 기억에 가깝습니다.

이 글을 끝까지 읽으면 세 가지를 구분할 수 있습니다. 컨텍스트 그래프가 RAG나 지식 그래프와 무엇이 다른지, 실제 기업은 어느 업무에 이 구조를 쓰고 있는지, 우리 조직에서는 어떤 업무부터 검토해야 하는지입니다. 이미 CRM과 ERP, 메신저에 데이터가 많은데 왜 또 다른 그래프가 필요한지도 함께 살펴보겠습니다.

결과는 남는데 판단 과정은 사라집니다

CRM에 할인율 20%라고 적혀 있다고 해보겠습니다. 숫자는 분명합니다. 그런데 회사의 기본 할인 한도는 10%였습니다. 해당 고객에게 최근 큰 장애가 세 번 있었고 해지를 언급한 문의도 들어왔습니다. 지난 분기에는 비슷한 고객에게 같은 이유로 예외를 적용한 적이 있었습니다. 영업 담당자가 이 자료를 모아 재무 책임자에게 보여줬고 재무 책임자는 서비스 장애에 대한 보상으로 20%를 승인했습니다.

CRM에 남은 것은 20%라는 결과뿐입니다. 어떤 정책을 적용했는지, 무슨 근거를 봤는지, 누가 예외를 승인했는지, 이후 고객이 실제로 계약을 갱신했는지는 메일과 메신저, 티켓과 사람의 기억에 흩어집니다.

다음 갱신 업무를 맡은 직원이나 AI 에이전트는 두 가지 실수를 할 수 있습니다. 20%를 정상 할인율로 오해해 다른 고객에게도 적용하거나, 정당한 예외였다는 사실을 몰라 똑같은 조사를 처음부터 다시 하는 것입니다.

Foundation Capital이 2025년 말 Context Graph를 소개하며 주목한 것도 이 빈자리였습니다. 기존 업무 시스템은 고객, 주문, 계약, 직원의 현재 상태를 잘 저장합니다. 반면 여러 시스템의 정보를 모아 규칙을 적용하고 예외를 승인한 과정은 제대로 남지 않습니다. 투자사의 표현을 빌리면 기존 시스템은 무엇이 일어났는가의 기록에는 강하지만 왜 이 일이 허용됐는가의 기록에는 약합니다.

여기서 말하는 왜는 사람의 머릿속을 읽는다는 뜻이 아닙니다. 실제로 확인할 수 있는 것은 당시 어떤 자료를 봤고 어느 정책 버전을 적용했으며 어떤 도구를 거쳐 누가 승인했고 실행 결과가 어땠는지입니다. 회의나 승인 과정에서 이유를 명시했다면 그것도 남길 수 있습니다. 기록되지 않은 동기까지 AI가 알아냈다고 주장해서는 안 됩니다.

Glean도 이 점을 분명하게 짚습니다 . 사람의 머릿속 why를 안정적으로 잡아내기는 어렵지만 누가 어떤 자료를 열고 수정하고 승인했는지에 관한 how는 디지털 흔적으로 남습니다. 그 흐름을 오래 관찰하면 어떤 조건에서 업무가 진행되고 멈추며 예외가 생기는지 알 수 있다는 것입니다.

그래서 Context Graph가 뭔데?

이 글에서는 컨텍스트 그래프를 다음과 같이 정의하겠습니다.

컨텍스트 그래프는 조직의 사람·고객·문서·정책 같은 업무 대상과, 그 사이에서 일어난 행동·판단·승인·예외·결과를 시간과 출처, 권한까지 포함해 연결한 동적인 관계 모델입니다.

할인 사례를 간단히 그리면 이렇습니다.

그림 1. Context Graph는 최종 값뿐 아니라 그 값에 이른 판단 경로와 이후 결과를 함께 남깁니다.

고객과 정책만 점으로 찍지 않습니다. 요청, 검토, 승인, 반려, 변경 같은 행위와 결정도 그래프의 한 점이 됩니다. 그래야 여러 근거와 사람, 정책과 결과를 결정 하나에 함께 연결할 수 있습니다.

시간도 중요합니다. 지금 적용 중인 정책과 작년 정책은 다릅니다. 현실에서 정책이 효력을 얻은 날짜와 시스템이 그 변경을 알게 된 날짜도 다를 수 있습니다. 출처가 공식 ERP인지, 사람이 입력한 메모인지, AI가 문서에서 추정한 내용인지도 구분해야 합니다. 같은 문장처럼 보여도 믿고 행동할 수 있는 수준은 서로 다릅니다.

컨텍스트 그래프는 아직 업계 표준으로 굳어진 용어가 아닙니다. 2024년 발표된 Context Graph 논문 은 지식 그래프의 사실에 시간, 장소, 출처와 같은 맥락을 붙이는 데 초점을 둡니다. Foundation Capital은 예외, 승인, 선례를 포함한 의사결정 기록을 가리킵니다. Graphiti 같은 구현은 시간에 따라 바뀌는 에이전트 메모리를, Apollo는 에이전트가 사용할 API와 도구의 연결 지도를 같은 이름으로 부릅니다.

그래서 제품 설명에서 Context Graph를 지원한다는 말만 확인해서는 부족합니다. 무엇을 연결하고 어떤 질문에 답하는 그래프인지를 물어야 합니다.

RAG와 지식 그래프가 있는데 왜 또 필요할까

RAG는 질문과 관련 있는 문서 조각을 찾아 모델에게 건네는 데 능합니다. 사규에서 출장비 한도를 찾거나 제품 설명서에서 오류 코드를 찾는 일에 잘 맞습니다. 하지만 다음 질문은 관련 문서 한 장만 찾아서는 답하기 어렵습니다.

이 고객에게 20% 할인을 승인해도 되는가?

가격 정책, 고객 등급, 최근 장애, 과거 예외, 승인 권한과 계약 결과가 서로 다른 시스템에 있기 때문입니다. RAG를 유능한 사서에 비유한다면 컨텍스트 그래프는 사건 기록에 가깝습니다. 사서는 관련 자료를 찾아줍니다. 사건 기록은 어떤 자료가 이 건에 적용됐고 누가 무엇을 결정했으며 결과가 어땠는지 연결해서 보여줍니다.

지식 그래프와의 경계는 조금 더 미묘합니다.

그림 2. 셋은 경쟁 제품이 아닙니다. Context Graph는 RAG와 지식 그래프를 활용하면서 판단의 시간·출처·권한까지 잇습니다.

앞선 암묵지 글에서는 설명을 단순화하느라 기존의 triple 기반 지식 그래프가 시간과 출처 같은 맥락을 표현하는 데 한계가 있다고 썼습니다. 더 정확히 말하면 기존 지식 그래프 기술도 시간과 출처를 표현할 수 있습니다. RDF의 Named Graph, W3C의 PROV-O, Temporal Knowledge Graph처럼 오래전부터 관련 방법이 있었습니다. 컨텍스트 그래프의 차이는 없던 표현법을 새로 발명했다는 데 있지 않습니다.

무엇을 반드시 기록하는지, 언제 기록하는지, 그리고 다음 업무에 어떻게 되돌려 주는지가 다릅니다. 컨텍스트 그래프는 시간과 출처를 부가 정보로 두지 않고 핵심 조건으로 취급합니다. 업무가 끝난 뒤 문서를 모으는 데서 멈추지 않고 결정이 이뤄지는 순간의 근거와 실행 결과를 잡습니다. 다음 에이전트는 그중 필요한 관계만 조회하고, 새로 수행한 일의 결과를 다시 남깁니다.

이전 글 프롬프트만 잘 쓰면 끝인 줄 알았다 에서 설명한 Graph Engineering과도 다릅니다. 그 글의 Graph는 앞으로 어떤 작업을 어느 순서로 실행할지 나타내는 업무 흐름입니다. Context Graph는 그 작업이 참고할 조직의 현실과 과거 기록입니다.

업무 Graph: 다음에는 누가 무엇을 실행할까?
Context Graph: 그 실행은 어떤 사실과 과거 판단을 참고할까?

둘은 서로 연결됩니다. 업무 Graph를 따라 에이전트가 일하면 새로운 결정 기록이 생기고 그 기록이 Context Graph를 갱신합니다. Context Graph에서 찾은 근거는 다시 업무 Graph의 다음 판단에 들어갑니다.

현장에서는 어떻게 쓰고 있을까

용어가 유행한 지 오래되지 않아 Context Graph라는 이름으로 수년간 축적된 독립 연구는 아직 많지 않습니다. 대신 같은 구조를 Knowledge Layer, Teamwork Graph, Enterprise Graph, Ontology라는 이름으로 운영한 사례는 이미 있습니다. 이름보다 실제로 어떤 업무가 달라졌는지를 보겠습니다.

Zuora: 지원팀이 엔지니어의 답을 기다리지 않게 됐습니다

구독·결제 관리 기업 Zuora에서는 고객 장애가 발생하면 지원팀이 조사하고 엔지니어링팀에 넘긴 뒤 답을 기다려야 했습니다. 코드 저장소와 티켓, 관측 데이터, 고객 상황과 과거 장애 기록이 나뉘어 있었기 때문입니다.

Zuora는 PlayerZero로 이 정보를 연결해 생산 환경의 컨텍스트 그래프를 만들었습니다. 지원 담당자는 고객 코드를 넣고 동작 흐름과 오류 지점을 확인합니다. 직접 해결할 수 없는 문제도 관련 코드 경로와 근거를 붙여 엔지니어링팀에 전달합니다. 엔지니어는 여러 저장소에 걸친 변경 영향을 출시 전에 확인합니다.

PlayerZero가 공개한 Zuora 사례 에 따르면 L3 에스컬레이션은 90% 줄었고 매달 60건이 넘는 복잡한 조사를 엔지니어링팀 없이 처리하게 됐습니다. 코드 검토와 오류 지점을 찾는 시간은 약 2시간에서 15분으로 줄었습니다. Zuora의 CEO는 아예 컨텍스트 그래프를 중심으로 업무를 설계한다고 설명합니다.

이 사례에서 눈여겨볼 것은 검색 속도만이 아닙니다. 고객 문제를 가장 잘 아는 지원팀과 코드를 가장 잘 아는 엔지니어링팀의 역할이 바뀌었습니다. 공통된 맥락이 생기자 지원팀이 해결할 수 있는 범위가 넓어졌고 엔지니어는 모든 문의의 통역자가 되지 않아도 됐습니다.

Infinitus: 한 번의 실행이 다음 실행을 줄였습니다

앞서 소개한 Infinitus는 보험 확인 업무를 조회 → 필요할 때만 통화 → 결과를 다시 기록하는 구조로 바꿨습니다.

Neo4j가 공개한 Infinitus 사례 에 따르면 복잡한 보험 규칙의 그래프 조회는 1초 안에 끝납니다. 사람이 처리할 때 평균 45일, AI가 전화를 대신해도 12일 걸리던 확인 업무가 이미 검증된 답을 재사용할 때는 몇 초로 줄었습니다. 전체 물량 중 두 자릿수 비율의 요청이 전화 없는 즉시 확인으로 전환됐다고 합니다.

이 사례는 컨텍스트 그래프의 선순환을 잘 보여줍니다.

AI가 보험사에 전화
→ 조건과 예외를 확인
→ 검증된 내용을 그래프에 기록
→ 다음 요청에서 과거 확인 내용을 조회
→ 충분하면 전화 생략, 부족하면 다시 확인

에이전트가 일을 거듭하면 기록이 쌓이고 다음 업무의 비용도 줄어듭니다. 실행이 조직의 기억으로 바뀐 셈입니다.

Mercedes-Benz: 결함 보고서에 차량 전체의 맥락을 붙였습니다

자동차 한 차종을 시험하면 수천 건의 결함이 생길 수 있습니다. 여러 차종을 동시에 시험하면 같은 결함이 중복으로 접수되고 보고서에 로그나 추적 정보가 빠지는 일도 잦아집니다. 결함 하나가 어느 요구사항과 부품, 차량 모델에 연결되는지 찾는 데도 시간이 듭니다.

Mercedes-Benz는 Jira, Confluence, 서비스 관리 시스템과 자동차 개발 시스템의 정보를 Atlassian의 Teamwork Graph에 연결하고 Rovo Agent로 결함 접수와 분류를 보조했습니다. 에이전트는 결함 내용을 분석하고 중복을 찾으며 필요한 로그가 첨부됐는지 확인합니다. 다른 시스템의 유사한 이상 징후도 조회한 뒤 엔지니어에게 다음 조사 지점을 알려줍니다.

Atlassian의 Mercedes-Benz 고객 사례 는 이 에이전트가 결함 보고서의 품질을 90% 높이고 중복 결함 탐지 속도를 85% 높였다고 밝힙니다. 이 기반을 사용하는 기술·업무 인력은 5만 명이 넘습니다.

여기서 Teamwork Graph는 범용 문서 검색기가 아닙니다. 결함 → 요구사항 → 테스트 → 부품 → 차량 모델 → 논의와 결정을 따라갈 수 있는 자동차 개발의 관계 지도를 만듭니다. 범용 AI를 현업에 적용하려면 결국 조직과 산업에서만 쓰는 대상을 연결해야 한다는 점을 보여줍니다.

Pinterest: 과거 SQL에서 분석가의 판단 방식을 꺼냈습니다

Pinterest의 사례는 컨텍스트 그래프를 직접 만들려는 조직에 특히 참고할 만합니다. Pinterest에는 한때 약 40만 개의 테이블이 있었습니다. 정리한 뒤에도 분석용 테이블이 10만 개가 넘었고 분석 사용자는 2,500명이 넘었습니다.

분석가가 국가별 자연 유입 콘텐츠의 참여율을 묻는다고 해보겠습니다. 비슷한 이름의 테이블을 찾는 것만으로는 부족합니다. Pinterest에서 참여율을 어떻게 정의하는지, 어느 테이블이 운영용인지, 어떤 키로 연결하고 어떤 필터를 적용해야 하는지는 숙련된 분석가가 작성한 과거 SQL에 들어 있었습니다.

Pinterest는 테이블의 등급과 담당자, 최신성, 용어 정의를 정리하고 과거 SQL에서 두 종류의 맥락을 추출했습니다. 하나는 그 SQL이 어떤 업무 질문에 답하려고 했는지에 관한 분석 의도입니다. 다른 하나는 실제로 사용한 테이블, 연결 키, 필터와 계산 방식입니다. 새 질문이 들어오면 의미가 비슷한 과거 질문을 찾고 운영 등급과 최신성이 높은 자료를 우선합니다.

Pinterest Engineering이 공개한 글 에 따르면 Analytics Agent는 출시 두 달 만에 분석가의 40%가 사용했고 사내에서 두 번째로 많이 쓰인 에이전트보다 사용량이 10배 많았습니다. 수시간 걸리던 테이블 탐색과 SQL 작성을 수분으로 줄였습니다.

이 성과는 에이전트 하나를 설치했다고 바로 나온 게 아닙니다. Pinterest는 먼저 테이블을 40만 개에서 약 10만 개로 정리하고 중요한 테이블의 담당자와 품질 기준을 세웠습니다. AI가 생성한 설명도 중요 테이블에서는 사람이 검토했습니다. 회사의 데이터가 무엇을 뜻하는지 정리하는 오래된 숙제를 건너뛴 채 컨텍스트 그래프만 살 수는 없습니다.

GT Golf: 대기업만 할 수 있는 일은 아닙니다

골프용품 유통사 GT Golf는 약 15명의 고객 지원·주문 담당자가 이메일로 들어온 주문을 NetSuite에 옮기고 있었습니다. 주문은 PDF나 Excel뿐 아니라 일반 메일과 손글씨 사진으로도 들어왔습니다. 고객과 상품을 맞추고 어느 창고에서 출고할지 판단하는 방법은 담당자들의 경험에 남아 있었습니다.

Gralio는 2주 동안 실제 화면 업무를 관찰해 도구 전환, 예외 처리와 판단 지점을 정리했습니다. 그 결과 가장 많은 시간을 쓰던 이메일 주문 입력을 먼저 골랐습니다. 에이전트는 주문을 읽고 고객과 상품을 찾으며 과거 주문 이력을 보고 창고를 선택한 뒤 NetSuite에 주문 초안을 만듭니다. 사람은 입력 대신 검토와 승인을 맡습니다.

GT Golf 사례 에 따르면 한 건에 10분 이상 걸리던 초안 작성은 30초 안으로 줄었고, 에이전트에 전달된 이메일 주문의 82%를 자동화했습니다.

규모보다 시작 방식이 중요합니다. GT Golf는 전사 데이터를 모두 통합하지 않았습니다. 실제 업무를 관찰하고 가장 큰 병목 하나를 찾은 뒤 그 업무에 필요한 판단 기준부터 모았습니다.

General Mills: 5천만 번의 작은 판단을 한곳에서 봤습니다

Context Graph라는 이름이 유행하기 전에도 비슷한 구조로 성과를 낸 곳이 있습니다. General Mills의 북미 공급망은 4,000개 공급사와 200곳이 넘는 공장, 연간 약 120만 건의 고객 주문을 다룹니다. 운영 인력이 한 해 내리는 크고 작은 판단은 약 5천만 건에 이릅니다.

General Mills는 2019년부터 200개의 기준·운영 데이터 테이블을 Palantir Ontology로 연결했습니다. 그 위에서 Project ELF라는 시스템이 공장의 생산 여력과 제약, 물류망 비용과 주문 상황을 함께 보고 대응 방법을 추천합니다. 여기서는 그래프라는 이름보다 주문, 공장, 공급사와 제약 조건이 같은 운영 모델 안에 있다는 사실을 눈여겨봐야 합니다. 추천 결과도 실제 업무로 이어집니다.

Palantir가 공개한 General Mills 사례 에 따르면 현업은 추천의 70% 이상을 받아들였고 일부 물류망에 적용한 단계에서 하루 평균 4만 달러, 연간 약 1,400만 달러를 절감했습니다. AI가 수천 건의 주문에서 먼저 살펴볼 선택지를 좁히고 사람이 최종 판단한 사례입니다.

사례의 숫자는 어디까지 믿어야 할까

위 사례 대부분은 독립된 학술 연구가 아니라 솔루션 공급사가 고객과 함께 작성한 자료입니다. 업무에 실제로 사용했고 담당자와 수치가 공개됐다는 점은 의미가 있습니다. 다만 제품을 사용하지 않은 비교 집단이나 장기 유지 비용까지는 확인하기 어렵습니다.

수치를 볼 때는 범위를 섞지 않아야 합니다. Mercedes-Benz의 결함 보고서 품질 90% 개선은 특정 Rovo Agent의 결과이고, 같은 사례에 등장하는 소프트웨어 개발 속도 향상은 더 넓은 클라우드 전환의 결과입니다. 이를 모두 컨텍스트 그래프 하나의 효과라고 말하면 과장입니다.

그럼에도 사례를 나란히 놓으면 공통점은 선명합니다.

• 전사 그래프보다 비용이 큰 업무 하나에서 시작했습니다.
• 여러 부서나 시스템 사이의 인수인계가 병목이었습니다.
• 사람은 사라지지 않고 승인과 예외 판단을 맡았습니다.
• 조회에서 끝난 사례보다 실행 결과를 다시 기록한 사례에서 가치가 누적됐습니다.
• 모델 선택보다 데이터의 의미, 권한과 업무 흐름을 정리하는 데 더 많은 시간이 들었습니다.

그림 3. 이름과 산업은 달라도 여러 시스템의 맥락을 연결해 인수인계와 반복 판단을 줄였다는 공통점이 있습니다. 수치는 각 기업·공급사의 공개 사례 기준입니다.

기술적으로 무엇을 만들어야 할까

컨텍스트 그래프를 도입한다고 해서 모든 데이터를 한 그래프 데이터베이스로 옮길 필요는 없습니다. 원문은 문서 저장소에, 업무 이벤트는 로그에, 현재 상태는 기존 CRM이나 ERP에 계속 둘 수 있습니다. 그래프는 이 자료의 정체와 관계, 시간과 출처를 연결하고 필요한 순간에 찾아주는 역할을 맡습니다.

전체 흐름은 다음과 같습니다.

그림 4. 핵심은 저장소 하나가 아니라 연결과 되먹임입니다. 실행 결과와 사람의 수정이 다시 그래프에 들어와야 다음 판단이 나아집니다.

일이 일어나는 순간을 잡아야 합니다

결정이 끝난 뒤 데이터 창고에서 최종 값만 가져오면 판단 과정은 이미 사라졌을 수 있습니다. 에이전트나 업무 시스템이 실제 일을 수행할 때 조회한 자료, 적용한 정책, 사람의 승인과 외부 시스템의 처리 결과를 함께 남겨야 합니다.

처음부터 과거의 모든 메일과 메신저를 AI로 분석하려는 접근은 비용도 많이 들고 오류와 개인정보 위험도 큽니다. 지금부터 새로 일어나는 중요한 판단을 정확히 기록하는 편이 현실적입니다. 구조가 잡힌 티켓 변경과 승인 기록부터 시작해 필요한 범위에서 문서와 대화를 연결하면 됩니다.

이름이 다른 같은 대상을 찾아야 합니다

CRM의 ACME, 고객 지원 시스템의 Acme Inc., 결제 시스템의 C-1024가 같은 고객인지 알아야 관계가 이어집니다. 이를 Entity Resolution이라고 합니다. 이메일 주소나 고객 ID처럼 확실한 값은 규칙으로 맞춥니다. 이름과 문맥이 비슷한 경우에는 AI가 후보를 찾고 신뢰도가 낮으면 사람이 확인해야 합니다.

잘못 합쳐진 두 고객의 정보는 검색 실패보다 위험합니다. 전혀 다른 고객의 계약이나 장애 기록을 근거로 행동할 수 있기 때문입니다. 한 번 합친 대상을 다시 나눌 수 있는 이력도 필요합니다.

시간과 출처를 값에 붙여야 합니다

이 고객은 위험 고객이다라는 사실만 저장해서는 부족합니다.

• 현실에서 언제부터 위험했는가
• 시스템은 그 사실을 언제 알았는가
• 어느 티켓이나 데이터에서 왔는가
• 사람이 확인했는가, AI가 추정했는가
• 지금도 유효한가

현실의 유효 시점과 시스템이 기록한 시점을 나누는 방식을 이중 시간 모델이라고 합니다. Graphiti 는 이런 시간 모델을 사용해 새 사실이 이전 사실과 충돌하면 과거 내용을 지우지 않고 유효 기간을 닫습니다. 덕분에 지금 무엇이 사실인가뿐 아니라 당시 에이전트는 무엇을 알고 있었나도 물을 수 있습니다.

출처의 상태도 구분해야 합니다. 공식 API에서 읽은 사실, 사람이 적은 설명, AI가 추정한 관계, 서로 충돌해 확인이 필요한 주장을 모두 같은 무게로 다루면 안 됩니다.

권한은 검색한 뒤가 아니라 검색할 때 적용해야 합니다

메일과 인사 정보, 계약과 고객 데이터를 연결하면 Context Graph는 조직에서 가장 민감한 정보가 모이는 곳이 될 수 있습니다. 원래 문서를 볼 수 없는 사람에게 그래프가 그 관계를 알려줘서도 안 됩니다.

사용자와 에이전트의 신원을 확인하고 원천 시스템의 문서·행·필드 권한을 검색 단계에서 적용해야 합니다. 자료를 모델에 보낸 뒤 답변에서 가리는 방식은 늦습니다. 조회 권한과 수정 권한도 분리해야 합니다. 계약서를 읽을 수 있다고 계약 조건을 바꿀 수 있는 것은 아닙니다.

업무 행동을 관찰하는 과정도 주의해야 합니다. Glean은 사내 실험 에서 직원이 자발적으로 참여하도록 했고 집계된 업무 흐름에는 원문과 사용자 식별자, 고객 비밀을 넣지 않았다고 설명합니다. 화면 기록을 사용한 GT Golf 사례도 직원이 녹화를 멈추거나 구간을 지울 수 있게 했습니다. 기술적으로 수집할 수 있다는 것과 수집해도 된다는 것은 다른 문제입니다.

모델에는 그래프 전체가 아니라 작은 묶음을 줍니다

큰 Context Graph를 모델의 입력창에 통째로 넣지 않습니다. 지금 처리하는 계약이나 티켓을 출발점으로 관계를 따라갑니다. 시간과 권한을 확인한 뒤 필요한 근거만 작은 Context 묶음으로 만듭니다.

실무에서는 한 가지 검색 방식만 고집하지 않습니다.

• 정확한 상품 번호와 오류 코드는 키워드 검색
• 표현이 다른 유사 사례는 Vector 검색
• 고객과 계약, 정책의 연결은 Graph 탐색
• 최신성과 공식 여부, 신뢰도로 결과 재정렬

이 조합을 Hybrid Retrieval이라고 합니다. 기술 이름보다 에이전트가 답과 함께 근거, 충돌하는 정보와 빠진 정보까지 받을 수 있게 만드는 일이 중요합니다.

결과까지 돌아와야 조직의 기억이 됩니다

과거에 20% 할인을 승인했다는 사실만으로는 좋은 선례인지 알 수 없습니다. 그 고객이 계약을 갱신했는지, 추가 장애가 있었는지, 나중에 승인이 취소됐는지도 연결해야 합니다.

제안, 승인, 실행, 결과를 구분하는 이유가 여기에 있습니다. 에이전트가 처리했습니다라고 말한 것을 성공으로 저장하지 말고 CRM의 변경 기록이나 API 처리 결과를 확인해야 합니다. 실패와 취소, 사람의 수정도 남겨야 다음 에이전트가 성공 사례만 보고 잘못 배우지 않습니다.

그래프가 틀리면 AI는 더 자신 있게 틀립니다

컨텍스트 그래프는 AI의 환각을 없애는 마법이 아닙니다. 잘못 만든 그래프는 오류에 출처와 관계까지 붙여 더 그럴듯하게 만들 수 있습니다.

그림 5. 연결의 수보다 상태와 근거의 성격을 구분하는 일이 중요합니다. AI의 추정이 검증된 사실로 되먹임되지 않게 해야 합니다.

오래된 지도가 됩니다

담당자가 바뀌고 정책이 개정됐는데 그래프가 그대로라면 실제 조직과 다른 지도가 됩니다. 과거의 CMDB가 수동 업데이트에 의존하다 실제 IT 환경과 달라졌던 것과 비슷합니다. 데이터가 언제 갱신됐는지 측정하고 원천 시스템과 계속 대조해야 합니다.

예외가 정책으로 둔갑합니다

지난번의 20% 승인이 이번에도 맞다는 보장은 없습니다. 당시 장애 보상으로 허용한 일회성 예외였을 수 있습니다. 예외의 범위와 만료, 승인자와 이후 결과를 함께 보지 않으면 에이전트는 예외를 회사의 기본 관행으로 확대합니다.

시간 순서를 원인으로 오해합니다

메일을 보낸 뒤 계약이 체결됐다고 그 메일이 계약의 원인이라고 단정할 수는 없습니다. 뒤이어 일어남, 함께 자주 나타남, 담당자가 원인이라고 기록함, 별도 검증으로 원인이 확인됨을 서로 다른 관계로 다뤄야 합니다.

AI가 만든 오류가 선례가 됩니다

AI가 근거 없이 관계를 추정해 확정된 사실로 저장하면 다음 에이전트가 그 정보를 다시 근거로 씁니다. 잘못된 행동이 새 기록을 만들고 기록이 다시 잘못된 행동을 부르는 순환이 생깁니다. 원문에서 직접 읽은 사실과 AI가 추정한 내용을 구분해야 합니다. 영향이 큰 판단은 사람이 확인합니다.

우리 조직에서는 어디서 시작해야 할까

전사 Context Graph 구축을 첫 과제로 잡지 않는 편이 좋습니다. 너무 넓고 성공 기준도 모호합니다. 사례에서 성과가 난 곳은 대개 다음 조건을 가진 업무였습니다.

• 반복해서 일어납니다.
• 여러 시스템을 오갑니다.
• 예외가 많아 단순 규칙만으로 처리하기 어렵습니다.
• 숙련자에게 물어보거나 다른 부서로 넘기는 시간이 깁니다.
• 처리 시간, 오류, 에스컬레이션, 비용 같은 결과를 측정할 수 있습니다.
• 처음에는 사람이 승인해도 충분한 가치가 있습니다.

예를 들어 우리 회사의 모든 영업 판단을 이해하는 AI 대신 이렇게 시작할 수 있습니다.

갱신 할인 요청이 들어오면 같은 고객군의 과거 예외, 당시 정책과 결과를 찾아 재무 담당자에게 보여주자.

또는:

고객 장애가 들어오면 같은 구성요소의 과거 장애, 최근 배포와 담당자를 모아 지원팀이 먼저 판단하게 하자.

시작 순서는 단순합니다.

1. 비용이 큰 인수인계나 판단 하나를 고릅니다.
2. 그 판단에 쓰는 시스템과 사람, 근거와 결과를 관찰합니다.
3. 과거 전체를 옮기기보다 지금부터 새 판단을 정확히 기록합니다.
4. 처음에는 읽기 전용으로 근거와 선례를 보여주고 사람이 결정합니다.
5. 실제 업무 지표가 좋아지고 권한과 오류가 통제될 때 다음 업무로 넓힙니다.

그림 6. 전사 그래프를 먼저 만들기보다 값비싼 판단 하나에서 출발해 기록·검증·자동화의 범위를 차례로 넓히는 편이 현실적입니다.

그래프 데이터베이스를 먼저 선정할 필요도 없습니다. 기존 Event Log와 관계형 데이터베이스 위에 필요한 관계만 만들어 가치를 검증할 수 있습니다. 관계 탐색이 많아지고 규모가 커졌을 때 전용 Graph DB나 RDF 기반을 선택해도 늦지 않습니다.

나가며

컨텍스트 그래프라는 이름은 새롭지만 재료는 오래되었습니다. 지식 그래프, 이벤트 기록, 프로세스 분석, 데이터 출처 관리와 접근 제어는 전부터 쓰던 기술입니다. 에이전트가 실제 업무 안으로 들어오면서 이 재료들을 한데 묶어야 할 이유가 생겼습니다.

기존 시스템은 결과를 저장합니다. 컨텍스트 그래프는 결과에 이르는 동안 사용한 근거와 정책, 예외와 승인, 실행과 결과를 연결합니다. 이 기록을 다음 사람과 에이전트가 필요한 만큼만 꺼내 쓸 때 조직은 같은 일을 매번 처음부터 반복하지 않게 됩니다.

모든 암묵지가 저절로 자산이 되지는 않습니다. 어떤 업무를 관찰할지, 무엇을 결정으로 볼지, 사람의 설명과 AI의 추정을 어떻게 구분할지 정해야 합니다. 서로 다른 시스템의 고객과 상품을 맞추고 정책의 시간을 관리하며 원래의 접근 권한도 유지해야 합니다. 에이전트가 행동한다면 승인, 중복 실행 방지, 복구와 평가까지 함께 설계해야 합니다.

그래서 Context Graph 구축은 Graph DB를 설치하는 프로젝트보다 현업의 판단 구조를 다시 설계하는 AX 프로젝트에 가깝습니다. 업무를 모르면 쓸모없는 관계를 잔뜩 만들기 쉽고, 데이터와 에이전트 운영을 모르면 멋진 시범 화면 뒤에서 그래프가 금세 낡습니다.

엡실론델타는 앞선 글에서 다룬 암묵지 자산화를 실제 업무에 적용할 수 있도록 현업의 업무 흐름과 판단 지점을 함께 찾습니다. 가장 작게 검증할 수 있는 업무를 고른 뒤 필요한 데이터와 Context Graph를 설계합니다. 에이전트와 오케스트레이션, 권한과 평가 체계도 실제 운영에 맞게 구성합니다. 도입 뒤 현업의 수정과 실행 결과가 다시 조직의 자산으로 남는 과정까지 돕고 있습니다.

우리 조직의 데이터는 많은데 AI가 여전히 일반적인 답만 하거나 에이전트를 현업에 넣고 싶어도 어디서 시작해야 할지 막막하다면 contact@epsilondelta.ai로 연락해 주세요. Context Graph가 필요한 문제인지, 더 단순한 방법으로 먼저 풀 수 있는 문제인지부터 함께 살펴보겠습니다.