Back to Blogs

AI Insight

암묵지가 자산이 되는 순간: 컨텍스트 그래프로 완성하는 기업 AX

#컨텍스트그래프#ContextGraph#기업AX#EnterpriseAX#decisiontrace#판단기록#암묵지#KnowledgeGraph#ProcessMining#AIAgent
Jiyoon Ok
Jiyoon Okjiyoonok@yonsei.ac.kr
Jun 30, 2026•8 min read
암묵지가 자산이 되는 순간: 컨텍스트 그래프로 완성하는 기업 AX

"그건 그냥 AI한테 시키면 되잖아요." 사내에 AI를 들인 회사라면 요즘 흔히 나오는 말입니다. 실제로 문서를 찾고, 회의록을 정리하고, 긴 보고서를 몇 줄로 줄이는 일은 눈에 띄게 빨라졌죠. 그런데 "이 계약을 이 조건에 받아들여도 되나" 같은 판단 앞에 서면, 결국 사람이 처음부터 다시 따져봐야 합니다. 도구는 늘었는데, 일이 돌아가는 방식은 좀처럼 바뀌지 않습니다.

한 회사만의 이야기가 아닙니다. MIT Project NANDA의 보고서 State of AI in Business 2025를 보면, 생성형 AI를 도입한 기업의 약 95%가 손익에 측정 가능한 영향을 얻지 못했습니다. 눈여겨볼 건 그 이유입니다. 모델이 부족해서가 아니라, 도구가 그 조직이 실제로 일하는 방식을 따라가지 못한 탓이었습니다. 보고서는 이걸 'learning gap'이라 부릅니다.

왜 이런 일이 벌어질까요?

실제 업무 판단에 필요한 맥락이 문서 밖에 흩어져 있기 때문입니다.

AI는 문서를 찾는 데는 능숙합니다. 그런데 회사에서 실제로 부딪히는 질문은 그렇게 간단하지 않습니다. 가령 "지난 분기 매출, 얼마나 늘었죠?" 숫자 하나면 끝날 것 같지만 그렇지 않습니다. 당장 매출을 어느 시점에 잡느냐부터 회사마다 다르거든요. 물건이 나간 때인지, 세금계산서를 끊은 때인지, 돈이 들어온 때인지. 게다가 "우리는 이 중 무엇을 매출로 보느냐" 하는 기준 자체가 어느 문서에도 적혀 있지 않습니다. 대개 담당자의 머릿속과 팀의 관행에 남아 있을 뿐이죠.

결국 사내 AI 활용이 막히는 지점은 문서 검색이 아닙니다. 판단에 필요한 맥락이 애초에 어디에도 정리돼 있지 않다는 점입니다.

그렇다면 문서 검색과 요약을 넘어, AI가 실제 업무의 판단과 실행까지 돕게 하려면 무엇이 필요할까요? 이 글에서는 먼저 문서 검색만으로는 무엇이 부족한지 짚어보고, 컨텍스트 그래프와 그 핵심인 판단 기록(decision trace)이 무엇인지 살펴봅니다. 이어서 컨텍스트 그래프를 기업 AI에 적용하면 일하는 방식이 어떻게 달라지는지, 그리고 이 접근에는 어떤 한계가 있는지까지 알아보겠습니다.

문서를 잘 찾아주는데도, 일하는 방식은 왜 그대로일까?

답이 문서에 적힌 질문은 일부일 뿐, 업무의 핵심은 문서가 아니라 사람의 암묵지와 일의 프로세스에 있기 때문입니다.

RAG는 어디까지 잘 통할까요?

먼저 기업 AX의 첫 단계는 대부분 흩어진 사내 문서를 쉽게 찾고 활용하게 만드는 것이었습니다. 흔히 쓰는 방식이 RAG(Retrieval-Augmented Generation)인데, 질문에 관련된 사내 문서를 먼저 검색한 뒤, 그 내용을 LLM에 넘겨 답변의 근거로 삼는 구조입니다. "규정상 접대비 한도는 얼마인가요?", "이 약관 조항에는 뭐라고 적혀 있나요?"처럼 답이 문서에 그대로 적혀 있는 질문에는 잘 통합니다.

막히는 건 그다음부터입니다. 앞서 본 매출처럼 "무엇을 기준으로 삼느냐"를 먼저 정해야 하는 질문도 까다롭지만, 한층 더 어려운 쪽이 있습니다. "이 비용은 왜 예외로 처리됐나" 같은 질문이죠. 이런 건 문서 한 장으로 끝나지 않습니다. 그게 어떤 상황에서 누구 승인으로 적용됐고, 과거 비슷한 건은 어떻게 끝났는지까지 봐야 비로소 답이 나옵니다.

이 차이를 질문 유형으로 나눠 보면 경계가 또렷해집니다.

  • 조회형 질문: 문서 검색으로 충분합니다. "규정상 접대비 한도는?", "이 약관 조항에는 뭐라고 적혀 있나?"처럼 답이 문서에 그대로 적혀 있는 경우입니다.
  • 종합형 질문: 문서만으로는 부족합니다. "지난 분기 매출 성장률은?"처럼 숫자를 묻는 질문이라도, 어떤 기준으로 계산할지 먼저 정해야 하기 때문입니다.
  • 판단형 질문: 문서만으로는 부족합니다. "이 비용은 왜 예외 처리됐나?", "비슷한 청구인데 왜 하나만 부지급됐나?"처럼 상황과 선례, 승인 과정까지 함께 봐야 하는 경우입니다.

조회형은 문서 검색으로 충분합니다. 정작 문제는 종합형과 판단형이죠. 그런데 이 질문들은 왜, 문서를 아무리 잘 찾아와도 풀리지 않는 걸까요?

정작 필요한 건 문서 밖에 있습니다

현업에서의 판단 문제는 문서로 옮겨 적기 어려운 두 가지가 깊이 얽혀 있기 때문입니다.

하나는 사람에게 쌓인 지식입니다. 특정 부서 비용은 관행상 어떤 계정으로 처리한다든지, 어떤 고객 민원은 무조건 먼저 이관한다든지, 어떤 임원 보고에는 숫자보다 배경 설명을 먼저 깔아야 한다든지. 이렇게 경험과 관행 속에 쌓여 매뉴얼로 잘 떨어지지 않는 지식을 암묵지(tacit knowledge)라고 부릅니다. 자전거 타는 법을 글로 옮기기 어려운 것처럼, 베테랑 담당자의 감각도 문서로 깔끔하게 정리되지 않죠.

다른 하나는 일이 처리되는 과정입니다. ERP, 전자결재, 콜센터, 메신저는 최종 상태는 잘 남깁니다. 하지만 거기에 이르기까지 누가 무엇을 보고 어떤 순서로 움직였는지는 거의 남기지 않죠.

그래서 기업 AI의 다음 과제는 "문서를 더 넣기"가 아닙니다. 사람 안에 있는 판단 기준과, 시스템에 남지 않는 처리 과정까지 AI가 쓸 수 있게 만드는 것이죠.

그렇다면 이렇게 흩어진 업무 맥락을, AI가 참고할 수 있는 형태로 어떻게 연결할 수 있을까요?

컨텍스트 그래프란 무엇인가?

그 답으로 주목받는 것이 컨텍스트 그래프(context graph)입니다. 흩어져 있던 업무 맥락을 AI가 따라 읽을 수 있는 하나의 지도로 엮은 것이죠. 문서·사람·고객·정책 같은 업무 대상과, 실제 업무에서 일어난 행동·판단·결과를 연결해 '우리 조직이 어떻게 판단하고 일해왔는지'까지 담아냅니다.

그럼 기존 지식베이스와는 무엇이 다를까요? 지식베이스가 "무엇이 어디에 있는가"를 보여준다면, 컨텍스트 그래프는 "누가 무엇을 보고, 어떤 순서로 진행하였고, 어떤 결과에 이르렀는가"까지 보여줍니다. 고객·문서·정책 같은 대상뿐 아니라, 생성·검토·승인·반려·이관·해결 같은 '행위'도 그래프의 한 점(노드)이 됩니다. 여기에 '이 승인은 저 정책을 따랐다' 같은 관계가 선으로 이어지면, 누가 무엇을 거쳐 어떤 결정에 이르렀는지가 드러납니다.

앞서 문서 검색이 막혔던 질문을 다시 떠올려 보죠. "이 비용은 왜 예외로 처리됐나?" 컨텍스트 그래프에서는 그 비용이 어떤 정책 아래, 누구의 승인으로, 과거 어떤 선례를 따라 처리됐는지가 하나로 이어져 있습니다. 그 연결을 따라가면, 문서 한 장에는 없던 답이 비로소 보이죠. 정리하면, RAG가 답이 적힌 문서를 찾아주는 도구라면, 컨텍스트 그래프는 그 문서엔 없는 기준과 선례, 처리 경로까지 이어주는 지도입니다.

그래서 이 지도는 단순히 답을 찾는 도구에 그치지 않습니다. "이 상황에선 다음에 무엇을 해야 하는가"까지 짚어 주는, 일종의 업무 플레이북에 가깝습니다.

한편, 지식을 그래프로 구조화해 활용하려는 시도는 연구에서도 이어져 왔습니다. Microsoft Research가 2024년 공개한 GraphRAG는 문서를 그래프로 엮어 여러 문서를 가로지르는 질문에 답하는 방식을 제안했습니다. 컨텍스트 그래프는 여기서 한 발 더 나아가 정책·예외·승인·결과까지 함께 연결하고, AI가 실제 업무를 실행할 때 참고하도록 만드는 접근입니다.

컨텍스트 그래프는 어떻게 작동하나요?

쉽게 말해, 흩어진 시스템 기록을 하나의 업무 경로로 이어 붙이는 일입니다.

  • ERP·CRM·전자결재·콜센터·문서함·메신저 등에서 데이터와 이벤트를 모읍니다.
  • 시스템마다 다르게 쓰이는 고객·부서·프로젝트·ID를 같은 대상으로 통합합니다.
  • 조회·수정·승인·반려·상태 변경 같은 이벤트를 공통 형식으로 정규화합니다.
  • 흩어진 이벤트를 하나의 고객·업무·프로젝트 경로로 잇습니다.

두 번째와 세 번째가 특히 어렵습니다. 전자결재의 '전결'과 콜센터의 '수퍼바이저 승인'은 이름은 달라도 같은 '승인'입니다. 이렇게 서로 다른 표현을 같은 의미로 맞춰야 흩어진 이벤트가 한 경로로 이어집니다.

경로가 쌓이면, AI 에이전트는 지금 마주한 상황과 비슷한 과거 경로를 찾아 '다음에 무엇을 해야 할지' 판단하는 근거로 삼습니다. 그리고 그 실행 결과와 사람의 피드백이 다시 새 기록으로 더해집니다. 쓰면 쓸수록 조직의 판단 지도가 촘촘해지는 셈이죠.

다만 이 경로는 저절로 만들어지지 않습니다. 최종 문서와 상태만 모아서는 실제 업무 흐름을 복원하기 어렵습니다. 조회·댓글·담당자 변경·승인·반려·보류 같은 '변화의 순간'이 남아 있어야 비로소 처리 경로가 보입니다.

문제는 기존 시스템이 바로 이 '변화의 순간'을 잘 남기지 않는다는 점입니다.

결과만 남는 시스템에서 사라지는 것: 판단 기록

CRM이나 ERP 같은 기록 시스템은 결과를 꼼꼼히 남깁니다. ERP에는 매출액이, 전자결재에는 승인 여부가, 보험 시스템에는 지급/부지급 결과가 남죠. 하지만 거기에 이르기까지의 '왜'는 충분히 남지 않습니다.

이 빠진 ‘왜’를 채우는 것이 판단 기록(decision trace)입니다. 어떤 정보를 참고했는지, 어떤 정책을 적용했는지, 누가 승인했는지, 어떤 예외가 있었는지, 그래서 결과가 어땠는지를 함께 묶어 남기는 거죠.

그리고 이렇게 쌓인 판단 기록이 바로 앞서 본 컨텍스트 그래프를 채우는 핵심 재료입니다. 흩어진 판단 기록을 사람·고객·정책 같은 대상과 엮으면, 그것이 곧 하나의 판단 지도, 즉 컨텍스트 그래프가 됩니다.

이렇게 판단이 기록으로 남으면 무엇이 달라질까요?

그동안 한 번 쓰고 흩어지던 예외나, 한 사람의 경험 속에만 있던 노하우가 검색 가능한 '선례'로 남습니다. “지난번 비슷한 건은 왜 예외 승인됐는지”, “그때 어떤 부서가 확인했는지”, “결과적으로 문제가 없었는지”를 다음 업무에서 다시 참고할 수 있게 됩니다. AI는 이 기록을 바탕으로 다음 행동과 필요한 승인 단계를 제안할 수 있습니다.

사실, 완전히 새로운 발상은 아닙니다

흩어진 로그에서 업무가 실제로 어떻게 흘러갔는지를 복원하는 프로세스 마이닝(process mining)은 25년 이상 연구되어 온 검증된 분야입니다. 이 분야를 연 빌 반 데르 알스트(Wil van der Aalst)는 저서 〈Process Mining〉에서, ERP·CRM·헬프데스크 같은 시스템의 이벤트 로그만 있으면 '문서에 적힌 절차'가 아니라 '실제로 일어난 절차'를 그려낼 수 있음을 보여줬습니다. 그러니 흩어진 기록에서 처리 흐름을 복원한다는 컨텍스트 그래프의 토대는 이미 입증된 셈이죠. 컨텍스트 그래프는 여기서 한 걸음 더 나아가, 그 흐름을 사후 분석에만 쓰지 않고 AI가 지금의 판단에 바로 활용하도록 만듭니다.

그럼 이 구조가 실제 업무에 들어가면, 일하는 모습은 구체적으로 어떻게 바뀔까요?

실제 업무에서는 무엇이 달라질까?

AI가 단순한 검색 도구를 넘어, 판단을 돕는 에이전트에 가까워집니다. 매출 분석, 보험금 심사, 고객 민원 세 가지로 살펴보겠습니다.

매출 분석: 숫자는 나오는데, 기준이 없다

맨 앞에서 봤던 질문으로 돌아가 보죠. 데이터 분석 담당자가 사내 AI에게 묻습니다. "지난 분기 매출 성장률 알려줘." 많은 회사가 기대하는 것도 이런 ‘우리 회사 데이터에 답해주는 AI 분석가’입니다. 물으면 필요한 데이터를 찾아 답해주는 거죠.

그런데 막상 시켜 보면 답이 깔끔하게 나오지 않습니다. 어떤 고객은 CRM A에, 어떤 고객은 CRM B에 흩어져 있고, 외부 결제 시스템의 고객 ID는 내부 ID와 다릅니다. 결정적으로, 매출을 어떤 기준으로 잡을지가 어디에도 정해져 있지 않죠. 취소된 주문은 빼야 할까요? 다음 분기에 세금계산서가 끊긴 건은요? 기준이 빠진 채로는, AI가 내놓는 숫자가 그럴듯해 보여도 믿기 어렵습니다.

컨텍스트 그래프는 이 빈자리를 채웁니다. '어떤 상황엔 어떤 데이터를 봐야 하는지', '어떤 ID가 같은 고객인지', '취소 주문은 매출에서 어떻게 빼는지' 같은 문서 밖의 규칙을 AI가 참고하게 해주는 거죠. 그래야 "매출 성장률 알려줘"라는 한 줄 질문에 비로소 제대로 답할 수 있습니다.

보험금 지급 심사: 약관은 찾았는데, 판단이 안 선다

이번엔 보험금 심사역 앞에 한 건이 놓였다고 해보죠. AI에게 관련 약관을 물으면 조항은 정확히 찾아 줍니다. 문제는 그다음입니다. 진단서 표현은 애매하고, 지급 대상인지 아닌지는 약관만으로 딱 떨어지지 않거든요.

이럴 때 심사역이 실제로 떠올리는 건 약관이 아니라 선례입니다. "예전에 비슷한 건, 우리가 어떻게 처리했더라?" 앞서 본 '판단 기록'이 필요한 지점이죠. 컨텍스트 그래프가 깔려 있으면 AI는 조항을 찾는 데서 멈추지 않고, "3년 전 비슷한 청구는 일부 지급으로, 본부 승인을 거쳐 마무리됐다"는 선례까지 함께 꺼내 줍니다. 최종 결정은 여전히 심사역의 몫이지만, 혼자였다면 한참 뒤져야 했을 선례와 예외가 곁에 놓이는 셈입니다.

고객 민원과 서비스 보상: '처리 중'은 아무것도 알려주지 않는다

여러 부서를 거치며 몇 주째 이어진 민원을 누군가 넘겨받았다고 해보죠. 시스템을 열면 '현재 상태: 처리 중'이라고만 떠 있습니다. 정작 알아야 할 건 그게 아니죠. 지금까지 어떤 순서로 처리됐고, 어디서 막혔고, 무엇이 남았는가입니다.

콜센터 시스템은 보통 상담 결과와 현재 상태만 남깁니다. 결과만 남기는 시스템이 놓치는, 바로 그 '경로'죠. 컨텍스트 그래프는 부서마다 흩어진 처리 단계를 하나로 이어 붙여, 이 민원이 어디서 지연됐고 다음에 무엇이 필요한지를 보여줍니다. '지금 상태'가 아니라 '여기까지 온 길'을 읽게 되는 거죠.

세 사례 모두, AI가 검색을 넘어 판단까지 거들게 만든 건 더 똑똑한 모델이 아니었습니다. 기준이든 선례든 처리 경로든, 문서 밖에 흩어져 있던 맥락을 얼마나 연결해 뒀느냐였습니다.

그렇다면 우리 회사는 이걸 어디서부터 시작하면 좋을까요?

기업 AX는 어디서부터 시작해야 할까?

"어떤 챗봇을 만들까"보다, "사람의 경험에 기대 반복해서 판단하는 업무가 무엇인가"를 먼저 물어야 합니다.

사람이 많이 관여하고, 예외가 잦고, "이건 케이스 바이 케이스죠"라는 말이 자주 나오는 업무가 좋은 출발점입니다. 비용 정산, 보험금 심사, 장기 민원, 구매 승인, 임원 보고 같은 일이 그렇죠. 이런 업무일수록 문서 검색보다 판단 기록과 선례 연결의 가치가 더 또렷하게 드러납니다.

출발점은 같아도, 역할마다 먼저 볼 것은 조금씩 다릅니다.

  • 경영진이라면, "어떤 솔루션을 살까"보다 "어떤 반복 판단을 회사의 자산으로 남길까"를 먼저 정해야 합니다.
  • 데이터·IT 담당자라면, 최종 데이터보다 그 앞단을 봐야 합니다. 승인·반려·보류 같은 '변화의 순간'이 로그로 남고 있는지가 첫 점검 대상입니다.
  • 현업 담당자라면, 매번 비슷한 고민을 처음부터 다시 하는 업무 하나를 먼저 떠올려 보세요. 그 업무에 선례와 예외가 가장 많이 쌓여 있을 테니까요.

그래서 컨텍스트 그래프는 어떻게 구축하나요?

업무를 골랐다면, 그다음은 크게 세 단계입니다.

  • 먼저, 에이전트를 업무 시스템에 연결합니다. MCP 연동 같은 방식으로 ERP·전자결재·콜센터·문서함·메신저·회의록에 접근 권한을 주는 거죠. 핵심은 최종 데이터뿐만 아니라 승인 요청·반려·댓글·상담 이력·보류 사유 같은 프로세스의 흔적까지 참조할 수 있게 하는 데 있습니다. 결과만 남는 시스템이 놓치던 바로 그 부분이니까요.
  • 그다음, 그 흔적을 관측 가능한 형태로 남깁니다. 어떤 문서가 조회됐는지, 어떤 승인 단계에서 멈췄는지, 어떤 댓글 뒤에 상태가 바뀌었는지 같은 '변화의 순간'을 정규화해 기록하는 단계입니다. 앞서 본 판단 기록이 실제로 쌓이는 지점이죠. (이때 고객명·부서명·시스템마다 ID가 제각각인 문제도 함께 정리해야 합니다.)
  • 마지막으로, 사람이 에이전트에게 준 지시와 피드백을 자산으로 거둬들입니다. 담당자가 "이 건은 바로 반려하지 말고 과거 사례랑 비교해줘", "이 비용은 재무팀 확인 먼저 받아"라고 일러준 세션을 흘러가는 채팅 로그로 버리지 않는 거죠. 조건·행동·적용 범위를 갖춘 후보 지식으로 뽑아내 쌓으면, 그래프는 쓸수록 촘촘해집니다.

결국 같은 'AI 도입'이라도 설계의 깊이가 결과를 가릅니다. 단순 Q&A로 설계하면 RAG 챗봇에 머물고, 판단 기록과 컨텍스트 그래프까지 설계하면 업무 자동화에 가까워집니다.

판단을 기록한다고, 모든 문제가 풀릴까요?

아닙니다. 솔직하게 짚고 가겠습니다.

  • 낡고 충돌하는 판단은 누가 정리하나요? 과거 판단이 틀렸거나 규정이 바뀌면, 그 선례는 오히려 독이 됩니다. 충돌하는 지식을 누가 승인하고 갱신할지가 숙제로 남고, 이건 한 번 하고 끝나는 게 아니라 계속 손이 가는 일이기도 합니다.
  • 암묵지에는 끝내 기록되지 않는 부분이 있습니다. 사람의 경험과 판단 감각을 데이터로 옮기는 과정에는 반드시 손실이 생깁니다. 노나카 이쿠지로가 1994년 Organization Science에 발표한 조직 지식 창출 이론(Nonaka, 1994)이 짚었듯, 암묵지를 형식지로 바꾸는 일은 깔끔하게 떨어지지 않습니다. 담당자조차 자신이 왜 그렇게 판단했는지 설명하지 못할 때도 있고요.
  • 많이 반복된 경로가 곧 좋은 경로는 아닙니다. 자주 반복됐다는 건 조직이 그렇게 일해왔다는 뜻일 뿐, 그 방식이 더 빠르거나 안전했다는 뜻은 아닙니다. 과거의 비효율이나 특정 담당자의 편향이 '패턴'으로 굳었을 수도 있죠. 그 경로가 어떤 결과로 이어졌는지까지 함께 봐야 하는 이유입니다.
  • 판단 기록은 곧 감시 기록이기도 합니다. "누가 무엇을 승인하고 반려했는지"가 전부 남는다는 건, 자칫 직원 감시로 비칠 수 있습니다. 익명화·접근 권한·목적 제한 설계가 함께 가야 신뢰가 지켜집니다.

그리고 무엇보다, 이 모든 걸 잘 해내도 모든 결정을 AI에게 넘길 수 있는 건 아닙니다. 근거를 아무리 잘 보여줘도, 고객 피해나 법적 책임, 재무 손실이 큰 결정은 결국 사람이 최종적으로 져야 하니까요. 되돌리기 쉽고 위험이 낮은 일은 맡기되, 그 위에서 판단 기준과 승인 체계, 갱신 규칙을 짜고 감독하는 일은 여전히 사람의 몫으로 남습니다. 결국 컨텍스트 그래프는 판단을 더 잘 보이게 만들 뿐, 판단 자체를 대신해주지는 않습니다. 자동화의 끝에서도 마지막 책임은 사람에게 남는 셈이죠.

마무리

처음의 질문으로 돌아가 보죠. AI를 도입하고도 일하는 방식이 그대로였던 건, 모델이 부족해서가 아니었습니다. 그 회사만의 판단 맥락 ‘무엇을 기준으로 삼고, 어떤 예외를 두고, 누구의 승인을 거쳐 일해왔는지’가 어디에도 구조화돼 있지 않았기 때문입니다.

RAG가 문서를 'AI가 읽을 수 있는 자산'으로 바꿨다면, 컨텍스트 그래프는 그 아래에 있던 기업의 암묵지와 업무 흐름을 'AI가 활용할 수 있는 자산'으로바꾸는 일입니다. AI가 진짜 업무를 하려면, 답을 찾는 능력보다 '이 회사에서는 이런 상황에 어떤 기준을 적용하고 어떤 순서로 움직이는지'를 아는 능력이 필요하니까요.

앞으로 기업 AX의 경쟁력은 ‘AI를 도입했는가'가 아니라, '우리 회사의 판단이 매번 새로 시작되지 않고 자산으로 쌓이고 있는가'에서 갈릴 가능성이 큽니다. 같은 모델을 써도, 그 모델에게 건넬 판단 맥락은 회사마다 다를 수밖에 없으니까요.

그리고 이 모든 게 제대로 작동할수록, 오히려 답하기 까다로운 질문이 하나 생깁니다. AI가 내린 판단마저 다시 조직의 선례로 쌓이기 시작한다면, 우리는 무엇을 '공식적인 판단 자산'으로 인정하고, 누가 그것을 검증하고 갱신해야 할까요?

참고문헌