AI를 위한 내비게이션, '데이터 맥락 지도'를 만드는 법

데이터 거버넌스로 땅을 고르고, 지식그래프로 길을 잇고, 온톨로지로 교통 규칙을 세우는 3단계 구축법과, 현장에서 마주치는 네 가지 난관을 살펴봅니다.

서울에서 부산까지 차를 몰고 내려간다고 생각해 보겠습니다. 도로는 이미 다 깔려 있습니다. 고속도로도, 국도도, 시내 골목길도 잘 만들어져 있습니다. 그런데 지도나 내비게이션이 없다면 어떨까요? 아무리 길이 훌륭하더라도 어디서 어디로 이어지는지 모르면 한 발짝도 제대로 나아갈 수 없습니다. 결국 우리가 부산에 도착하게 도와주는 것은 잘 포장된 도로 그 자체만이 아니라, 그 도로들이 어떻게 연결되는지를 알려 주는 지도입니다.

기업의 데이터도 사정이 비슷합니다. 데이터는 넘칩니다. 수십 년간 여러 시스템에 쌓아 온 테이블과 파일, 문서가 이미 회사 곳곳에 도로처럼 깔려 있습니다. 문제는 AI가 이 데이터를 쓰려 할 때 "어디에 무엇이 있고, 그것이 무엇과 연결되는지"를 모른다는 데 있습니다. 바로 이 지도 역할을 하는 것이 '데이터 맥락 지도'입니다. 이번 글에서는 데이터 맥락 지도가 무엇이고, 어떤 순서로 만들어야 하며, 그 과정에서 어디가 막히는지를 함께 살펴보겠습니다.

데이터는 도로, AI는 운전자

먼저 상황을 정확히 짚어 보겠습니다. 대부분의 기업은 데이터가 부족하지 않습니다. 오히려 넘쳐서 문제입니다. 고객 정보는 CRM에, 거래 내역은 판매 시스템에, 정산 자료는 회계 시스템에 흩어져 있습니다. 도로는 충분히 깔려 있는 셈입니다.

사람은 이 흩어진 도로를 경험과 눈치로 이어 붙입니다. "이 고객 코드는 저쪽 시스템의 회원 번호랑 같은 거야", "이 금액은 세금 빼기 전 값이니 조심해야지"처럼, 명시되지 않은 지식으로 빈틈을 메웁니다. 여러 해 그 일을 해 온 담당자의 머릿속에는 회사 전체의 지도가 어렴풋이 들어 있습니다. 하지만 AI는 다릅니다. AI는 "명시된 길"만 갑니다. 표지판이 없는 갈림길에서도 알아서 우회해 주지 않습니다.

또한 "데이터 웨어하우스든 레이크든 데이터를 다 모아 한곳에 넣으면 AI가 알아서 찾아 쓴다"고 생각하는 경우가 많습니다. 과연 그럴까요? 창고에 물건을 잔뜩 쌓는 것과, 그 물건들이 어디에 있고 어떻게 이어지는지를 그린 지도를 만드는 것은 전혀 다른 일입니다. 데이터를 한 곳에 모으는 것은 도로를 한 구획에 몰아 놓은 것에 가깝습니다. 도로가 모였다고 지도가 저절로 그려지지는 않습니다.

'검색'과 '길찾기'는 다릅니다

여기서 개념을 둘로 나눠 보겠습니다. 하나는 검색, 즉 "그 데이터가 어디 있는가"입니다. 다른 하나는 맥락, 즉 "그 데이터가 무엇과 어떻게 연결되는가"입니다. 이 둘은 비슷해 보이지만 완전히 다른 능력입니다.

키워드 검색이나 자연어를 SQL로 바꿔 주는 텍스트-투-SQL(Text-to-SQL) 기술은 대체로 앞쪽, 검색 문제를 해결합니다. "매출 테이블 어디 있어?"에는 잘 답합니다. 하지만 "이 지점의 이번 분기 매출이 왜 떨어졌고, 어떤 상품군과 어떤 프로모션이 관련됐는지"를 물으면 막힙니다. 그건 검색이 아니라 길찾기이기 때문입니다. 여러 데이터 사이의 관계를 따라가며 맥락을 조립해야 답할 수 있는 질문입니다.

흔히 "데이터가 많고 정확하기만 하면 된다"고 생각합니다. 품질만 좋으면 AI가 잘 쓴다는 것입니다. 하지만 아무리 정확한 데이터라도 다른 데이터와의 연결 정보가 없으면 AI에게는 망망대해에 떠 있는 고립된 섬일 뿐입니다. 정확한 섬이 백 개 있어도 섬들을 잇는 항로가 없으면 어디에도 가지 못합니다. 정확성(품질)과 연결성(맥락)은 서로 다른 축입니다. 하나를 채운다고 다른 하나가 채워지지 않습니다. 데이터 맥락 지도가 필요한 이유가 바로 여기에 있습니다.

사람이 내려놓고 AI가 운전대를 잡을 때

그런데 왜 하필 지금 데이터 맥락 지도에 대한 이야기를 하는 걸까요? 바로 데이터를 소비하는 주체가 달라졌기 때문입니다. 최근 확산되는 에이전틱 AI(agentic AI), 즉 스스로 판단하고 여러 단계의 작업을 실행하는 AI가 데이터의 새로운 운전자로 등장했습니다. 예전에는 사람이 데이터를 꺼내 보고, 이상하면 멈추고, 동료에게 물었습니다. 사람과 사람 사이에는 "그 지표는 원래 이렇게 봐요" 같은 암묵지가 자연스럽게 오갔습니다. 그런데 AI에게는 이 암묵지가 전달되지 않습니다. 말해 주지 않은 것은 없는 것과 같습니다.

오류가 났을 때의 비용 구조도 바뀝니다. 사람은 뭔가 이상하면 운전대를 놓고 되묻습니다. "이 숫자가 맞나요?" 하지만 실행 권한을 위임받은 AI는 틀린 길로 들어서도 멈추지 않고 끝까지 달립니다. 잘못된 데이터로 잘못된 보고서를 만들고, 그 위에서 다음 판단까지 내려 버립니다. 사람이 지도 없이 헤맬 때는 시간만 잃었지만, AI가 지도 없이 달리면 틀린 목적지에 자신 있게 도착합니다. 명시적인 지도가 필요한 이유가 여기에 있습니다.

'데이터 맥락 지도'란 무엇인가

이제 대상을 분명히 정의해 보겠습니다. '데이터 맥락 지도'란, AI가 필요한 데이터를 스스로 찾아 그 의미를 이해하고 활용할 수 있도록 데이터가 무엇이고 서로 어떻게 연결되는지를 기계가 읽을 수 있는 형태로 정리해 둔 것입니다. 사람이 보는 지도가 도로와 지명, 방향을 담듯이, 데이터 맥락 지도는 데이터 자원과 그 의미, 그리고 자원들 사이의 관계를 담습니다.

핵심은 "기계가 읽을 수 있는"이라는 대목입니다. 사람이 문서로 정리한 데이터 설명서는 사람에게는 지도지만 AI에게는 여전히 풍경 사진에 가깝습니다. AI가 실제로 길을 찾으려면, 관계와 규칙이 사람의 말이 아니라 기계가 따라갈 수 있는 구조로 표현돼 있어야 합니다.

이렇게 잘 정돈되고 의미가 연결된 데이터를 'AI Ready Data'라고 부릅니다. AI가 곧바로 활용할 수 있도록 의미와 맥락이 정돈된 데이터라는 뜻입니다. 데이터 맥락 지도는 이 'AI Ready Data'를 구성하는 핵심 요소라고 할 수 있습니다. 데이터를 그저 많이 쌓아 두는 것과, AI가 실제로 딛고 달릴 수 있는 상태로 만드는 것 사이의 거리를 좁혀 주는 것이 바로 이 지도입니다. 그렇다면 이 지도는 무엇으로 이뤄질까요.

지도의 세 겹 — 지형·도로·규칙

데이터의 개괄 정보를 보여주는 데이터 카탈로그는 매우 유용한 도구입니다. 하지만 데이터 카탈로그는 주소록입니다. 누가 어디 사는지는 알려 주지만, A에서 B로 어떻게 가는지, 그 길에 어떤 규칙이 있는지는 말해 주지 않습니다. 지도를 보고 목적지까지 가기 위해서는 주소록만으로는 부족합니다.

차량용 내비게이션은 사실 하나의 레이어로 이뤄진 게 아닙니다. 여러 겹의 레이어가 겹쳐 있습니다. 데이터 맥락 지도도 마찬가지로 세 겹으로 이뤄집니다. 이 세 겹이 뒤에서 다룰 3단계 구축의 뼈대입니다.

• 측량된 지형: 도로가 이어질 지형과 지역의 정보가 정확히 측량돼 있어야 그 사이에 무엇이든 그릴 수 있습니다. 데이터로 치면 신뢰할 수 있게 정돈된 데이터, 즉 데이터 거버넌스의 영역입니다.
• 이어진 도로망: 지형 위에 도로가 놓이고 서로 이어져야 이동할 수 있습니다. 데이터로 치면 개체와 개체 사이의 관계, 즉 지식그래프의 영역입니다.
• 교통 규칙과 표지: 도로가 있어도 일방통행, 우선순위, 제한속도 같은 규칙이 있어야 안전하게 달립니다. 데이터로 치면 개념과 관계의 의미·규칙, 즉 온톨로지의 영역입니다.

1단계 — 지형 측량: 데이터 거버넌스

이제 순서대로 만들어 보겠습니다. 가장 먼저 짚을 것은 지형, 즉 데이터 거버넌스입니다.

왜 이것이 첫 단계일까요? 측량이 부실하고 지반이 물러 있으면, 그 위에 아무리 멋진 도로와 표지판을 세워도 무너지기 때문입니다. 데이터의 이름과 정의가 제각각이고 값의 신뢰도가 들쭉날쭉한 상태에서 관계를 잇고 규칙을 세워 봐야, 잘못된 땅 위에 지도를 그리는 꼴이 됩니다. 하부구조가 먼저입니다.

이 단계에서 하는 일은 엔코아가 오랫동안 다뤄 온 데이터 거버넌스의 기본기와 정확히 겹칩니다. 몇 가지만 들어 보겠습니다.

• 메타데이터 관리: 각 데이터가 무엇을 뜻하는지, 누가 관리하는지, 어디서 왔는지를 명시합니다.
• 데이터 표준: 같은 개념을 같은 이름으로 부릅니다. 시스템마다 다르게 부르는 용어를 하나의 표준 용어와 값으로 통일합니다.
• 데이터 품질: 값이 비어 있거나, 형식이 어긋나거나, 서로 모순되는 데이터를 걸러 냅니다.
• 데이터 흐름 관리: 이 데이터가 어느 원천에서 어떤 가공을 거쳐 지금에 이르렀는지를 추적합니다.

이 작업이 끝나면 AI는 비로소 믿고 딛을 수 있는 지면을 얻습니다. 정확성이라는 축을 채우는 단계입니다. 다만 이것만으로는 아직 부족합니다. 땅은 골랐지만, 아직 길은 없기 때문입니다.

2단계 — 도로 연결: 지식그래프

두 번째 단계는 도로망을 놓는 일, 지식그래프입니다.

데이터 거버넌스의 영향 아래에서 아무리 데이터를 잘 정돈해도 전통적인 관계형 데이터베이스(RDB)의 데이터는 테이블이라는 경계 안에 갇혀 있습니다. 테이블과 테이블을 잇는 JOIN은 가능하지만, 관계가 복잡하게 얽히고 여러 단계를 건너뛸수록 JOIN은 무거워지고 느려집니다. "이 고객과 세 다리 건너 연결된 거래처가 어디냐" 같은 질문 앞에서는 특히 그렇습니다.

지식그래프는 데이터를 테이블이 아니라 노드(점)와 엣지(선)로 표현합니다. 실제 세계의 개체를 노드로, 그 사이의 관계를 엣지로 놓는 것입니다. 이렇게 하면 흩어진 시스템에 제각기 존재하던 같은 개체를 하나로 이을 수 있습니다. CRM의 '고객'과 계약 시스템의 '가입자'와 정산 시스템의 '수취인'이 사실 같은 사람이라면, 이들을 하나의 노드로 잇고 각각의 관계를 명시합니다. 부서가 본부에 속하고, 본부가 특정 규정의 적용을 받는다면, 그 소속과 적용 관계도 선으로 그립니다.

이 단계가 끝나면 "어디서 어디로 갈 수 있는가"라는 도로망이 완성됩니다. 데이터 사이를 관계를 따라 이동할 수 있게 되는 것입니다. 앞서 말한 연결성이라는 축을 채우는 단계이기도 합니다. 다만 여기에도 한계가 있습니다. 길은 놓였지만, 그 길을 어떻게 달려야 하는지에 대한 규칙이 아직 없습니다.

3단계 — 규칙 수립: 온톨로지

마지막 단계는 교통 규칙을 세우는 일, 온톨로지(ontology)입니다. 온톨로지란 어떤 영역에 존재하는 개념들의 유형과, 그것들이 맺는 관계, 그리고 그 관계를 지배하는 규칙을 명시적으로 정의한 체계를 말합니다.

도로망만으로는 "이 길이 일방통행인지, 어느 쪽이 우선인지, 이 표지판이 무엇을 뜻하는지"를 알 수 없습니다. 노드와 엣지가 이어져 있어도, 그 관계가 정확히 어떤 의미이고 어떤 규칙을 따르는지는 별도로 정의해야 합니다. 온톨로지는 바로 그 의미와 규칙의 층입니다.

온톨로지의 진짜 힘은 추론에 있습니다. 예를 들어 이렇게 규칙을 세워 둡니다. "A팀은 개발본부에 속한다. 개발본부는 C규정의 적용을 받는다. 소속 관계는 전이된다." 그러면 A팀이 C규정의 적용을 받는다는 사실을 아무도 따로 적어 두지 않아도, AI는 규칙을 따라 스스로 추론해 냅니다. 이것이 단순한 분류체계(taxonomy)와 다른 지점입니다. 분류체계가 개념을 계층으로 정리하는 데 그친다면, 온톨로지는 관계에 규칙을 부여해 새로운 사실을 이끌어 냅니다.

세 층은 '한 장의 지도'로 합쳐집니다

거버넌스, 지식그래프, 온톨로지는 서로 다른 세 개의 프로젝트가 아닙니다. 이 셋은 한 장의 지도를 이루는 지형과 도로와 규칙입니다. 따로 떼어 놓으면 지형만 있는 황무지, 지반 없는 도로, 도로 없는 표지판이 됩니다. 지면이 있어야 도로를 놓고, 도로가 있어야 규칙이 의미를 갖습니다. 이 순서를 건너뛰면 지도는 완성되지 않습니다. 겹쳐야 비로소 지도가 됩니다.

세 층을 한눈에 정리하면 다음과 같습니다.

층	무엇을 하는가	주요 산출물
데이터 거버넌스	데이터를 믿을 수 있게 정돈	메타데이터·표준·품질·리니지
지식그래프	개체와 관계를 연결	노드·엣지로 이은 관계망
온톨로지	개념·관계의 의미와 규칙 정의	개체 유형·관계 규칙·추론

난관 ① 완벽한 지도부터 그리려는 함정

이 3단계가 논리적으로 잘 연결되어 있어도, 막상 만들기 시작하면 반드시 벽에 부딪힙니다. 어떤 벽인지 미리 알아 두면 넘기가 한결 수월합니다.

가장 흔한 실패는 처음부터 완벽한 지도를 그리려는 것입니다. 전사의 모든 데이터를 한 번에 다 매핑하겠다고 덤비다가, 규모에 짓눌려 좌초하는 경우가 빈번합니다.

세계 전체를 1:1 축척으로 그린 지도는 아무 데도 쓸 수 없습니다. 오히려 반대입니다. 내비게이션도 온 국토의 골목까지 완벽히 담고 나서 출시하지 않습니다. 사람들이 가장 많이 다니는 주요 노선부터 촘촘히 채우고 점차 넓혀 갑니다. 데이터 맥락 지도도 마찬가지입니다. 자주 묻는 업무, 가치가 높은 핵심 도메인부터 먼저 지도로 만들고, 거기서 효용을 확인한 뒤 확장하는 편이 훨씬 안전합니다. 용도가 우선순위를 정합니다.

난관 ② 표준·합의의 정치학

두 번째 벽은 기술이 아니라 사람입니다. 앞서 표준화를 이야기했지만, 실제로 표준을 세우려 들면 진짜 난관은 기술이 아니라 합의라는 사실을 깨닫게 됩니다.

같은 대상을 부서마다 다르게 부르는 일은 예외가 아니라 일상입니다. 영업팀의 '주문번호'가 물류팀의 '오더ID'와 같은 것인지, 미묘하게 다른 것인지를 두고 회의가 몇 시간씩 이어집니다. 각 부서는 저마다의 이유로 자기 용어를 지키고 싶어 합니다. 기술적으로 두 값을 잇는 것은 순식간이지만, "무엇을 표준으로 삼을 것인가"에 합의하는 데는 훨씬 오랜 시간이 걸립니다.

여기서는 위에서 표준을 강제하는 톱다운(top-down) 방식과, 현장의 실제 쓰임을 반영하는 바텀업(bottom-up) 방식 사이의 균형이 관건입니다. 톱다운만 밀어붙이면 현장이 따르지 않는 죽은 표준이 되고, 바텀업에만 맡기면 영영 합의에 이르지 못합니다. 그래서 데이터의 주인이 누구인지를 분명히 하는 오너십과, 이견을 조정할 거버넌스 조직이 필요합니다. 지도 제작이 결국 조직의 일인 이유가 여기에 있습니다.

난관 ③ 지도는 낡습니다

세 번째 벽은 시간입니다. 도로는 새로 나기도 하고 폐쇄되기도 합니다. 지도가 이를 따라가지 못하면 어제의 정확한 지도가 오늘은 사람을 엉뚱한 곳으로 안내합니다.

데이터도 끊임없이 변합니다. 새 시스템이 도입되고, 스키마가 바뀌고, 업무 규칙이 개정됩니다. 이렇게 시간이 흐르며 데이터의 구조와 의미가 원래 정의에서 조금씩 어긋나는 현상을 데이터 드리프트(data drift)라고 합니다. 한 번 잘 만든 맥락 지도라도 방치하면 서서히 현실과 어긋나기 시작합니다.

낡은 지도는 차라리 없는 것보다 위험할 수 있습니다. 지도가 없으면 AI가 조심하지만, 틀린 지도가 있으면 AI는 그것을 믿고 자신 있게 잘못된 길로 달립니다. 그래서 데이터 맥락 지도는 일회성 구축 프로젝트가 아니라 상시 갱신 체계로 접근해야 합니다. 데이터 흐름을 자동으로 수집해 변화를 감지하고, 정해진 주기로 지도에 반영하는 운영 체계를 함께 갖춰야 합니다. 만드는 것보다 살아 있게 유지하는 것이 더 어려운 일입니다.

난관 ④ 규칙을 너무 정교하게 — 과설계의 함정

네 번째 벽은 조금 역설적입니다. 온톨로지의 힘에 매료된 나머지, 규칙을 지나치게 정교하게 만들려다 무너지는 경우입니다.

세상의 모든 개념과 관계를 빠짐없이 담은 완벽한 세계 모형을 만들겠다는 야심은 이해할 만합니다. 하지만 그렇게 만든 온톨로지는 너무 무거워집니다. 설계에 몇 달이 걸리고, 유지하는 데 또 그만큼이 들며, 정작 그 복잡함 때문에 아무도 손대지 못하는 상태가 됩니다. 정밀함을 좇다가 쓸모를 잃는 것입니다.

규칙이 정밀할수록 무조건 좋은 것은 아닙니다. 내비게이션에 모든 골목의 모든 표지판이 다 들어갈 필요는 없습니다. 실제로 차가 들어갈 수 있는 길목에 있는 표지판만 있으면 됩니다. 온톨로지도 마찬가지로, AI가 실제로 던질 질문에 답할 수 있을 만큼만 정의하는 것이 낫습니다. 물론 온톨로지의 추론 능력은 큰 강점이지만, 그 강점에는 설계와 유지라는 비용이 따르며, 비용이 효용을 넘어서는 순간 지도는 서랍 속에서 잠들게 됩니다. 강점과 부담을 함께 저울에 올려야 합니다.

어디서부터 시작할까요

난관을 넷이나 늘어놓고 보니 지레 겁이 날 수도 있습니다. 하지만 이 벽들은 넘지 못할 벽이 아니라, 미리 알면 피해 갈 수 있는 벽입니다. 실무에서 착수할 때 도움이 될 만한 몇 가지를 정리해 보겠습니다.

• 작은 도메인으로 시작합니다. 전사를 노리지 말고, 가치가 높고 질문이 잦은 한 영역을 골라 파일럿으로 지도를 만들어 봅니다. 성공 경험이 확장의 동력이 됩니다.
• 이미 있는 것부터 재활용합니다. 많은 기업이 그동안 쌓아 온 메타데이터와 표준 문서를 어느 정도 갖고 있습니다. 맨땅에서 시작하지 말고 있는 자산부터 지도의 재료로 끌어옵니다.
• 질문에서 거꾸로 설계합니다. AI가 실제로 무엇을 물어볼지를 먼저 그려 보고, 그 답에 꼭 필요한 연결과 규칙부터 우선 정의합니다. 쓰지도 않을 관계를 미리 다 이어 둘 필요는 없습니다.

한 가지 관찰을 덧붙이자면, 현장에서 지도의 성패를 가르는 것은 처음의 완성도가 아니라 갱신 주기인 경우가 많습니다. 절반쯤 그렸어도 꾸준히 최신으로 유지되는 지도가, 완벽하게 그렸지만 방치된 지도를 언제나 이깁니다. 언제나 완성보다 지속이 어렵습니다.

지도를 쥔 AI가 향하는 곳

이 글의 처음으로 돌아가 보겠습니다. 서울에서 부산까지 도로는 이미 다 깔려 있었습니다. 우리에게 부족했던 것은 도로가 아니라 지도였습니다.

기업의 데이터도 그렇습니다. 데이터는 넘치도록 쌓여 있고, 정작 없는 것은 그 데이터가 무엇이고 어떻게 연결되는지를 알려 주는 지도, 즉 '데이터 맥락 지도'입니다. 땅을 고르는 거버넌스, 길을 잇는 지식그래프, 규칙을 세우는 온톨로지가 한 장의 지도로 겹쳐질 때, AI는 비로소 스스로 길을 찾기 시작합니다.

물론 이 지도가 만능은 아닙니다. 만드는 데 정비 비용이 들고, 표준을 세우는 데 합의의 진통이 따르며, 살아 있게 유지하려면 꾸준한 갱신이 필요하고, 욕심을 부리면 과설계로 무거워집니다. 그래도 목표는 세상 전부를 담은 완벽한 지도가 아닙니다. AI가 실제로 달릴 수 있는 지도, 오늘의 질문에 답하고 내일의 변화를 따라가는 지도입니다.