먼저 결론부터: 지식 그래프는 창고 마스터 데이터를 실제로 정리해주는 유일한 AI 접근법입니다. 유행이라서가 아닙니다 — 관계를 고치기 때문입니다. 깨진 마스터 데이터는 거의 언제나 깨진 관계입니다. 엉망인 데이터 더미에 RAG를 들이대면 엉망인 답이 돌아옵니다. 이게 터지는 걸 세 번 봤습니다. 매번 고라이브 전날이었습니다.
지식 그래프가 실제로 뭔지 (쉬운 말로)
프로젝트 이야기. 2023년, 텍사스 댈러스의 3PL 창고 — 80,000 평방피트, WMS 고라이브. 도면은 끝났고, 프로세스는 정리됐고, 연동 테스트도 마쳤다. 그런데 고라이브 체크리스트의 '마스터 데이터 동결' 항목에서 — 동결을 할 수가 없었다.
한 상품이 WMS에서는 SKU-8821, 마켓플레이스에서는 EB-8821-BLK, 재무에서는 ITEM-08821이었다. 세 개의 코드, 세 개의 시스템, 그리고 어느 것이 마스터인지 말할 수 있는 사람이 없었다. 입고 담당자들은 ASN 코드와 WMS 코드를 손으로 대조했고 — 하루 400건 이상 — 오출고가 늘었다. 고라이브는 여섯 주 미뤄졌고, 구현 일수로 10만 달러가 추가로 탔다.
근본 원인은 '나쁜 데이터'가 절대 아니다. 고아 관계다. SKU, 로케이션, 공급사, 고객, 운송사 — 그들 사이의 연결고리는 다섯, 여섯 개 시스템에 흩어져 있고, 그 지도의 주인은 아무도 없다. 정합 스프레드시트에는 열두 가지 버전이 있는데, 그건 없는 것과 같다.
지식 그래프가 바로 그 지도다: 누가 누구고, 누가 누구와 연결되는지를 그래프 데이터베이스에 저장해, AI가 문서를 읽기 전에 관계를 따라가게 한다. 이렇게 생각해 보라 — RAG는 AI를 도서관에 보내 책을 읽힌다. 지식 그래프는 AI에게 먼저 등장인물표를 건넨다. 마스터 데이터가 엉망일 때는 책보다 등장인물표가 더 중요하다.
나는 구현 컨설턴트지 AI 연구자가 아니다. 아래 내용은 전부 고라이브 최전선에서 쓴 것이다 — 모든 단계는 실행 가능하고, 모든 단계에는 산출물이 있다.
구축 체크리스트: 4단계로 만드는 최소 지식 그래프
1단계: 현황 파악. WMS, ERP, 마켓플레이스에서 마스터 데이터를 뽑아 VLOOKUP으로 코드끼리 대조하고, 각 엔티티(SKU, 로케이션, 공급사, 고객, 운송사)가 몇 개 시스템에서 몇 가지 코드 체계를 쓰는지 세어라. 산출물: 행렬 하나 — 행은 엔티티, 열은 시스템, 셀은 코드 체계 규칙. 일~이주를 잡고, 비즈니스 담당자를 내내 방에 붙잡아 두어라. 기술 혼자 지도를 만들면 비즈니스는 그걸 믿지 않는다. 그럼 아무것도 만든 게 아니다.
2단계: 기준 시스템을 선언하라. 엔티티마다 하나의 권위 있는 출처 — SKU는 WMS에, 공급사는 ERP에, 고객은 OMS에. 써서, 인쇄해서, 회의에서 서명을 받아라. 이 함정을 세 번 봤다: 기술은 다 끝났는데 비즈니스는 '마스터'에 합의한 적이 없고, 고라이브 당일에도 각자 자기 코드만 외친다. 서명이 어떤 기술보다 중요하다.
3단계: 최소 지식 그래프를 만들라. 첫날부터 창고 전체를 모델링하지 마라 — 프로젝트는 그렇게 죽는다. 세 가지 관계 유형부터 시작해라: SKU-로케이션(이 기회에 ABC 분류도 해라), SKU-공급사, 주문-SKU-운송사. 노드 수만 개, 엣지 수십만 개 정도는 오픈소스 그래프 DB로 8코어 머신 한 대에서 잘 돌아간다. 버전 1은 돌아가기만 하면 된다. 완전할 필요는 없다.
4단계: 엔티티 해결을 필수로 해서 Q&A 경로에 그래프를 연결하라. 사용자가 '8821 재고 얼마나 있어'라고 물으면 — 시스템이 먼저 그래프를 통해 8821을 세 가지 코드 체계에서 해결한 뒤 재고를 확인한다. 그 한 번의 절삭으로 오답이 뚝 떨어진다. 아무도 쿼리하지 않는 그래프는 내가 본 가장 비싼 벽 장식이다.
5단계(다들 건너뛰는 것): 오너를 지명하라. 그래프는 만들어진 그날부터 썩기 시작한다 — 새 SKU는 관계 없이 들어오고, 로케이션은 업데이트 없이 바뀌고, 세 달 뒤 AI는 자신만만하게 환각을 본다. 처방: 월간 고아 노드 스캔(관계 없는 노드를 전부 목록화)과 분기별 비즈니스 관계 리뷰. 지식 그래프의 수명은 유지보수 프로세스의 수명과 같다.
지식 그래프 vs 전통 MDM vs 직행 RAG
먼저 성공 사례부터. 2025년 초, 중서부의 리테일 DC — 400,000 평방피트, 똑같은 마스터 데이터 난장판. 그들은 빅뱅 MDM 프로그램을 건너뛰고 위 체크리스트대로 최소 그래프를 만들었다. 8주 만에 가동. 입고 코드 대조는 건당 약 3분에서 30초 미만으로 줄었고, 하루 400건이 넘는 입고에서 하루 1~2 FTE를 해방시켰다. 비용: 엔지니어 1명이 4주 + 비즈니스 주 반나절.
| 전통 MDM | 직행 RAG | 지식 그래프 + RAG | |
|---|---|---|---|
| 가치 창출까지 | 3–6개월 | 1–2주 | 4–8주 |
| 초기 비용 | 높음 (라이선스 + 컨설턴트) | 낮음 | 중간 (대부분 인건비) |
| '이 SKU는 시스템마다 뭐라고 불려?' | 정확하지만 느림 | 자주 날조됨 | 정확하고 빠름 |
| 관계 유지 주체 | 무거운 프로세스 | 아무도 없음 | 가벼운 월간 점검 |
| 적합한 곳 | 다중 엔티티 기업 | 데이터가 이미 깨끗한 곳 | AI를 쓰고 싶은, 지저분한 마스터 데이터의 창고 대부분 |
판단하는 세 가지 질문:
- 같은 엔티티에 여러 코드 체계를 쓰고 있는가? 그렇다 — 그래프에 1점.
- AI에게 답하게 하고 싶은 질문의 절반 이상이 엔티티를 가로지르는가('이 공급사 상품이 어느 로케이션에 있나')? 그렇다 — 그래프에 1점.
- 유지를 위해 한 달에 4시간, 0.5인분을 낼 수 있는가? 없다 — 만들지 마라. 돌아가서 먼저 2단계를 확실히 해라.
역설적 한마디: SKU 5,000개 미만, 시스템 한두 개 — 지식 그래프에 손대지 마라. 코드를 통합하면 어떤 AI보다 가치가 크다. 그래프는 사람의 뇌로 감당 못 하는 관계 복잡도를 위한 것이다. 마감 못에 큰 망치를 쓰지 마라.
이게 터지는 네 가지 패턴 (각각 세 번씩 봤다)
- 첫날부터 전부 모델링하기. 200,000 SKU에 전체 주문 이력을 한 그래프에, 세 달 동안 나온 게 없고 프로젝트 취소. 처방: 먼저 최소 그래프를 만들고 비즈니스가 승리의 맛을 보게 하라.
- 기술이 밀실에서 그래프를 만들기. 그래프 엔지니어가 자기 이해대로 관계를 정의하고, 고라이브 전에 비즈니스가 본다: '현장은 그렇게 안 돼.' 처방: 관계 정의는 비즈니스 승인이 필요하고, 승인된 버전은 동결한다.
- 그래프와 Q&A가 만나지 않기. 그래프는 만들었는데 AI는 여전히 문서를 직접 쿼리 — 돈 낭비. 처방: 검색 경로에서 그래프 경유 엔티티 해결을 필수로 하고, 이를 건너뛰는 쿼리는 거부한다.
- 그래프를 MDM 대체재로 취급하기. 그래프가 관리하는 건 관계지 데이터 품질이 아니다 — 코드 자체가 틀리면 그래프는 틀린 걸 더 깔끔하게 정리할 뿐이다. 데이터 품질은 2단계와 일일 거버넌스에서 나온다.
내일 당장 할 수 있는 것: 마스터 데이터가 난장판이면 AI Q&A 제품부터 사지 마라. 이번 주에 각 시스템에서 SKU 코드를 뽑아 정합시켜 보라. 90% 이상 일치 — RAG로 직행. 일치하지 않으면 — 체크리스트를 돌려라: 마스터를 선언하고, 그다음 최소 그래프를 만들어라. 지식 그래프는 은 탄환이 아니다. 단지 '관계'를 몇몇 베테랑의 머리에서 기계가 찾을 수 있는 곳으로 옮길 뿐이다.
Lin Xiao, WMS 구현 컨설턴트 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
