AI는 왜 매번 다른 지점에서 넘어질까요?

데이터가 '안 보여서', '안 맞아서', '이어지지 않아서' 멈춘 세 프로젝트를 복기하며, 실패 지점마다 무엇을 준비했어야 했는지 한 층씩 짚어 봅니다.

AI 프로젝트가 엎어졌다는 이야기는 이제 새삼스럽지 않습니다. 그런데 실패한 프로젝트들을 하나씩 복기해 보면 흥미로운 사실이 드러납니다. 멈춘 자리가 저마다 다릅니다. 어떤 팀은 데이터를 모으다 지쳐 주저앉았고, 어떤 팀은 다 모아 놓고도 학습 단계에서 무너졌으며, 또 어떤 팀은 정확한 데이터를 갖추고도 모델이 엉뚱한 답만 내놓아 손을 들었습니다. 멈춘 지점은 이렇게 달랐지만, 원인을 거슬러 올라가면 하나의 줄기로 꿰입니다. 바로 데이터를 준비하는 방식입니다.

등산을 하다 보면 암담해지는 순간이 있습니다. 저 능선만 넘으면 정상이겠거니 하고 힘을 다해 올라섰는데, 막상 도착하니 그 뒤로 더 높은 봉우리가 모습을 드러내는 순간입니다. 하나를 넘으면 또 다음 봉우리가 눈에 들어옵니다. AI를 위한 데이터 준비가 꼭 이렇습니다. 한 문제를 풀고 나면 그동안 가려져 있던 다음 문제가 그제야 수면 위로 떠오릅니다. 이번 글에서는 실무에서 자주 마주치는 세 번의 좌절 지점을 순서대로 오르며, 각 봉우리에서 무엇에 걸려 넘어지는지, 그리고 무엇을 준비했어야 하는지를 한 층씩 짚어 보겠습니다.

실패는 '한 곳'에서 나지 않습니다

AI 프로젝트를 앞둔 많은 조직이 데이터 준비를 하나의 과제로 여깁니다. "데이터 품질만 좋으면 되는 것 아니냐"는 생각입니다. 품질 좋은 데이터를 확보하는 일이 중요하지 않다는 뜻은 아닙니다. 하지만 이 시각에는 함정이 있습니다. 데이터 준비를 단일한 관문으로 보는 순간, 그 관문 하나만 통과하면 준비가 끝났다고 착각하게 됩니다.

실제 준비는 여러 층이 겹쳐 쌓인 산에 가깝습니다. 아래층을 넘어야 비로소 위층의 문제가 눈에 보입니다. 데이터를 찾지도 못하는 상태에서는 데이터끼리 아귀가 맞는지 따질 겨를이 없고, 아귀를 맞추기 전에는 데이터 사이의 관계가 끊겼는지 확인할 방법이 없습니다. 그래서 앞선 문제를 해결하기 전까지는 다음 문제가 존재하는지조차 모르는 경우가 대부분입니다.

이 글에서는 세 팀의 이야기를 따라가겠습니다. 편의상 A사, B사, C사로 부르겠습니다. 세 팀 모두 비슷한 의욕과 예산으로 AI 프로젝트를 시작했지만, 서로 다른 봉우리에서 멈춰 섰습니다. 그리고 뒤에서 보시겠지만, 세 팀이 멈춘 지점은 우연히 흩어진 것이 아니라 하나의 산을 서로 다른 높이에서 오르다 멈춘 결과였습니다.

첫 번째 봉우리 — 데이터가 '없어서'가 아니라 '못 찾아서' 멈춘 프로젝트

A사의 데이터 분석팀은 고객 이탈을 예측하는 모델을 만들기로 했습니다. 시작은 순조로웠습니다. 알고리즘도 정했고, 참고할 논문도 충분했습니다. 그런데 정작 학습에 쓸 데이터를 모으는 단계에서 프로젝트가 멈췄습니다.

문제는 데이터가 없다는 것이 아니었습니다. 오히려 그 반대였습니다. 고객 데이터는 회원 시스템에, 결제 이력은 정산 시스템에, 상담 기록은 고객센터 솔루션에, 마케팅 반응은 별도 툴에 흩어져 있었습니다. 각 데이터가 어디에 있는지, 담당자가 누구인지, 무슨 의미를 담고 있는지를 한눈에 아는 사람이 조직 안에 없었습니다. 데이터를 한 벌 확보하는 데만 여러 부서를 거쳐 수개월이 걸렸고, 그사이 프로젝트의 동력은 빠져나갔습니다.

이것이 첫 번째 봉우리, 접근성의 문제입니다. 데이터가 여기저기 고립돼 서로 오갈 수 없는 상태를 데이터 사일로(data silo)라고 부릅니다. 부서별로 각자의 곳간에 데이터를 쌓아 두고 서로 무엇을 가졌는지 모르는 상황입니다. 이런 조직에서는 "데이터는 분명히 있는데 정작 쓰지는 못하는" 역설이 벌어집니다. 실무에서 AI 프로젝트가 표류하는 첫 번째 이유로 이 데이터 확보 지연을 꼽는 경우를 자주 봅니다.

그렇다면 이 봉우리는 어떻게 넘을까요? 핵심은 데이터에 지도를 씌우는 일입니다. 구체적으로는 두 가지입니다.

• 데이터 카탈로그: 조직 안에 어떤 데이터가 어디에 있는지 목록으로 정리한 것입니다. 도서관의 서지 목록을 떠올리면 쉽습니다. 책이 아무리 많아도 목록이 없으면 원하는 책을 찾을 수 없습니다.
• 메타데이터(metadata) 관리: 메타데이터란 '데이터에 대한 데이터'입니다. 이 데이터가 무슨 뜻인지, 언제 만들어졌는지, 어디서 왔고 어디로 흘러가는지(리니지, lineage)를 설명하는 정보입니다. 데이터 자체가 상품이라면 메타데이터는 그 상품에 붙은 라벨입니다.

이 두 가지가 갖춰지면 무엇이 좋아질까요? 데이터를 요청할 때마다 부서를 수소문하고 담당자를 찾아 헤매는 시간이 사라집니다. 팀이 "데이터 찾기"에 쏟던 에너지를 "데이터로 일하기"에 쓸 수 있게 됩니다. AI 프로젝트의 출발선이 앞당겨지는 셈입니다. A사가 만약 프로젝트에 앞서 데이터 카탈로그부터 정비했다면, 첫 번째 봉우리에서 주저앉는 일은 없었을 겁니다.

두 번째 봉우리 — 데이터는 모였는데 서로 '말이 안 맞았다'

B사는 A사가 겪은 문제를 이미 넘어선 조직이었습니다. 데이터 카탈로그도 있었고, 필요한 데이터를 어디서 가져올지도 분명했습니다. 여러 시스템의 데이터를 한자리에 모으는 데 큰 어려움이 없었습니다. 그런데 학습을 시작하자 모델이 이상한 것을 배우기 시작했습니다.

원인을 파고들어 보니 데이터를 물리적으로 모으기만 했을 뿐, 그 데이터들이 서로 다른 언어로 쓰여 있었습니다. 가령 '고객'이라는 같은 단어가 시스템마다 다른 것을 가리켰습니다. 회원 시스템에서 '고객'은 가입한 사람 전부였지만, 정산 시스템에서 '고객'은 실제로 결제한 사람만을 뜻했습니다. '주문 완료'라는 상태도 한쪽에서는 결제가 끝난 시점을, 다른 쪽에서는 배송까지 끝난 시점을 의미했습니다. 코드값도 제각각이었습니다. 같은 '완료' 상태를 어디서는 숫자 1로, 어디서는 문자 Y로, 또 어디서는 DONE으로 적었습니다.

이렇게 뜻이 어긋난 데이터를 한데 섞어 학습시키면, 모델은 존재하지 않는 규칙을 학습합니다. 사람으로 치면 같은 단어를 서로 다른 뜻으로 쓰는 세 사람의 말을 한 번에 듣고 정리하려는 것과 같습니다. 정리가 될 리 없습니다.

여기서 중요한 구분이 하나 등장합니다. 물리적으로 모인 것과 논리적으로 통합된 것은 다릅니다. 데이터를 한 창고에 쌓았다고 해서 그 데이터들이 하나의 일관된 체계로 묶인 것은 아닙니다. 창고에 물건을 다 넣었어도 물건마다 규격과 단위가 제각각이면 조립할 수 없는 것과 같습니다. A사가 넘은 봉우리가 "데이터를 찾아 모으는" 것이었다면, B사가 마주한 두 번째 봉우리는 "모은 데이터의 뜻과 규칙을 맞추는" 일, 즉 정합성의 문제였습니다.

이 봉우리를 넘는 열쇠는 데이터 표준과 데이터 모델링입니다.

• 데이터 표준: 조직 전체가 같은 용어를 같은 뜻으로, 같은 코드값으로 쓰도록 규칙을 정하는 일입니다. '고객'의 정의를 하나로 통일하고, '완료' 상태의 코드값을 하나로 맞춥니다.
• 데이터 모델링: 데이터가 서로 어떤 구조로 연결되는지, 무엇이 무엇에 속하는지를 설계도로 그리는 일입니다. 건물을 짓기 전에 도면을 그리듯, 데이터를 쌓기 전에 그 구조를 정의합니다.

데이터를 다 모은다고 해도 준비가 끝나는 것이 아닙니다. B사가 바로 그 함정에 빠졌습니다. 모으는 것은 준비의 절반일 뿐입니다. 나머지 절반은 모은 데이터가 서로 말이 통하게 만드는 일입니다. 표준과 모델링으로 이 절반을 채우면, 비로소 데이터는 '쌓인 더미'에서 '학습 가능한 자산'으로 바뀝니다. 그리고 이 작업의 부수 효과도 큽니다. 한 번 표준을 세워 두면 이후의 모든 프로젝트가 같은 언어 위에서 출발하므로, B사의 실패가 다음 팀에서 되풀이되지 않습니다.

세 번째 봉우리 — 깨끗한 데이터인데 AI가 '이해하지 못했다'

C사는 앞선 두 봉우리를 모두 넘은 조직이었습니다. 데이터가 어디 있는지 훤히 꿰고 있었고, 용어와 코드도 가능한 범위 내에서 전사 표준으로 잘 정돈돼 있었습니다. 데이터 하나하나를 뜯어보면 흠잡을 데가 없었습니다. 그런데도 C사의 AI는 기대만큼 똑똑하지 못했습니다.

C사가 만들려던 것은 단순한 예측을 넘어 "왜 이 고객이 이탈했는가", "이 문제는 무엇과 연결돼 있는가"를 설명해 주는 모델이었습니다. 그런데 AI는 개별 사실은 정확히 알면서도 그 사실들을 잇지 못했습니다. 이 고객이 어떤 상품을 샀고, 그 상품이 어떤 캠페인과 이어져 있으며, 그 캠페인에 반응한 고객들이 어떤 상담을 거쳤는지 — 이런 연결의 사슬을 따라가지 못했습니다.

문제의 정체는 개별 값이 아니라 값과 값 사이의 관계였습니다. 우리가 흔히 쓰는 표 형태의 데이터, 즉 행과 열로 이뤄진 데이터는 각각의 값을 담기에는 훌륭하지만 값들 사이의 관계를 담기에는 서툽니다. 표는 "고객 홍길동의 등급은 VIP"라는 사실은 깔끔하게 적지만, "홍길동이 이탈한 이유는 그가 자주 사던 상품군이 단종됐고, 그 단종이 특정 협력사의 계약 종료와 맞물렸기 때문"이라는 이야기는 담아내지 못합니다. 이 이야기는 여러 데이터가 관계로 엮여야 비로소 드러납니다. C사가 마주한 세 번째 봉우리, 관계와 맥락의 문제입니다.

이 층위를 다루는 기술이 그래프DB(Graph DB)와 온톨로지(ontology)입니다.

• 그래프DB: 데이터를 점(노드)과 선(관계)으로 표현하는 데이터베이스입니다. 고객, 상품, 캠페인, 협력사가 각각 점이라면, 그 사이를 잇는 '구매했다', '반응했다', '공급했다' 같은 선이 관계입니다. 값뿐 아니라 값들이 어떻게 이어지는지를 데이터 자체로 저장합니다.
• 온톨로지: 어떤 개념이 무엇이고 서로 어떤 관계를 맺는지를 정의한 의미의 체계입니다. '상품'과 '상품군'과 '협력사'가 각각 무엇이며 어떻게 연결되는지를 명시해, 데이터에 '의미'를 부여합니다.

관계가 없으면 AI는 흩어진 사실 조각만 봅니다. 관계와 의미가 구조로 연결되면, AI는 비로소 '무엇'을 넘어 '왜'를 다룰 수 있게 됩니다. 개별 사실을 조회하는 도구에서, 맥락을 읽고 추론하는 파트너로 성격이 바뀌는 것입니다. 데이터 사이의 이런 연결망을 잘 갖춰 두는 일은 AI에게 데이터에 대한 지도를 쥐어주는 일입니다. 지도가 있으면 AI는 한 지점에서 다른 지점으로 길을 따라 추론할 수 있습니다. C사에게 부족했던 것이 바로 이 지도였습니다.

세 봉우리의 공통점 — 준비는 '단계'가 아니라 '층위'입니다

여기까지 오면 한 가지 질문이 떠오릅니다. A사, B사, C사는 정말 서로 다른 이유로 실패한 걸까요? 표면만 보면 그렇습니다. 하나는 데이터를 못 찾아서, 하나는 데이터가 안 맞아서, 하나는 데이터가 이어지지 않아서 멈췄습니다. 하지만 조금 물러서서 보면, 세 팀은 같은 산의 서로 다른 높이에서 멈춘 것입니다.

이 지점이 이 글에서 가장 강조하고 싶은 대목입니다. 많은 조직이 데이터 준비를 순차적인 체크리스트로 여깁니다. 접근성 확보에 체크, 품질 정비에 체크, 이렇게 하나씩 지워 나가면 준비가 끝난다는 그림입니다. 하지만 실제 구조는 체크리스트가 아니라 누적된 층위입니다. 아래층을 넘기 전에는 위층의 문제가 존재하는지조차 보이지 않습니다. A사는 접근성 봉우리에 가려 정합성 문제를 볼 기회조차 없었고, B사는 정합성 봉우리에 가려 관계의 문제를 만나지 못했습니다. C사는 두 봉우리를 넘었기에 비로소 세 번째 봉우리를 마주할 수 있었습니다.

그래서 "우리는 데이터 품질을 봤으니 준비가 됐다"는 판단이 위험합니다. 가짜 정상입니다. 품질이라는 능선에 올라선 순간에는 그 뒤에 관계와 맥락이라는 더 높은 봉우리가 있다는 사실이 아직 안 보이기 때문입니다. 넘어 본 사람만 다음 봉우리를 압니다.

제목에서 던진 질문, "AI는 왜 매번 다른 지점에서 넘어질까요"에 대한 답의 뼈대가 여기서 나옵니다. 실패한 프로젝트들이 제각각 다른 지점에서 넘어진 것처럼 보였지만, 실은 같은 산을 오르다 각자 도달한 높이에서 멈춘 것입니다. 그리고 세 봉우리는 흩어진 문제가 아니라 하나의 흐름을 이룹니다. 데이터를 찾아 정돈하고(접근성·정합성), 그 위에 의미를 부여해 연결하는(관계·맥락) 흐름입니다. 정돈이 먼저고 의미가 그다음입니다. 순서를 건너뛸 수 없습니다.

그렇다면 무엇부터 봐야 할까요

지금 진행 중이거나 앞둔 AI 프로젝트가 있다면, 무엇부터 점검해야 할까요? 순서를 뒤집어 생각하면 의외로 쉽습니다. 위층에서 나타난 증상으로 아래층의 원인을 역추적하는 방법입니다.

모델이 이상한 답을 내놓는다면, 그 증상만 보고 알고리즘을 탓하기 전에 아래 세 층위를 차례로 짚어 보시길 권합니다.

• 접근 층위: 필요한 데이터를 어디서, 누구를 통해, 얼마 만에 구할 수 있습니까? 이 질문에 즉답이 안 나온다면 첫 번째 봉우리를 아직 넘지 못한 것입니다. 여기서 막혔다면 애초에 모델의 정확도를 논할 단계가 아닙니다.
• 정합 층위: 같은 용어가 시스템마다 같은 뜻입니까? '고객'과 '완료'가 어디서나 하나의 정의로 통합니까? 여기서 어긋난다면 데이터를 아무리 많이 모아도 모델은 헛것을 배웁니다.
• 관계 층위: 값과 값 사이의 맥락이 데이터에 남아 있습니까? 아니면 개별 값만 정확하고 그 사이의 연결은 사라졌습니까? '왜'를 묻는 AI를 원한다면 이 층위를 반드시 확인해야 합니다.

이 세 질문을 위에서 아래로 훑으면, 우리 프로젝트가 지금 몇 번째 봉우리에서 멈춰 있는지가 드러납니다. 진단이 정확하면 처방도 정확해집니다. 접근 층위에서 막힌 팀이 그래프DB부터 도입하는 것은 세 번째 봉우리의 장비를 들고 첫 번째 봉우리 앞에서 헤매는 격입니다. 반대로, 이미 접근성과 정합성을 갖춘 팀이 데이터 확보 방법론을 다시 붙잡고 있다면 정작 넘어야 할 봉우리를 외면하는 셈입니다. 자기 팀이 선 높이를 아는 것만으로도 다음 한 걸음의 방향이 분명해집니다.

넘어진 자리를 아는 팀이 다음 봉우리를 넘습니다

세 팀의 이야기로 돌아가 보겠습니다. A사는 데이터를 찾지 못해, B사는 데이터가 서로 맞지 않아, C사는 데이터가 이어지지 않아 멈췄습니다. 멈춘 지점은 달랐지만 방향이 틀린 것은 아니었습니다. 세 팀 모두 같은 산을 오르고 있었고, 다만 저마다 다른 높이에서 가짜 정상을 진짜 정상으로 착각했을 뿐입니다. AI가 매번 다른 지점에서 넘어지는 이유가 여기 있습니다. 데이터 준비는 하나의 관문이 아니라 접근성 → 정합성 → 관계·맥락으로 이어지는 층층의 산이고, 팀마다 자신이 올라선 높이에서 다음 봉우리를 만나기 때문입니다. 그러니 지금 우리 프로젝트를 붙들고 있다면, 먼저 물어야 할 것은 "모델을 어떻게 고칠까"가 아니라 "우리는 지금 몇 번째 봉우리에서 멈춰 있는가"입니다.

세 층위를 모두 넘은 데이터는 어떤 상태일까요? 필요할 때 곧바로 찾을 수 있고, 어디서 가져와도 뜻이 일관되며, 값들이 관계로 이어져 맥락을 품은 데이터입니다. 이렇게 의미와 맥락이 정돈돼 AI가 별도의 손질 없이 바로 활용할 수 있는 데이터를 AI Ready Data라고 부릅니다. 세 봉우리를 차례로 넘는 여정의 도착점인 셈입니다. 물론 이 산은 한 번 올랐다고 끝나는 산이 아닙니다. 데이터는 계속 쌓이고 바뀌므로, 다지는 일도 반복됩니다. 하지만 자신이 어느 봉우리에서 멈췄는지 아는 팀은 다음 봉우리도 넘습니다. 넘어진 자리를 정확히 아는 것 — 데이터 준비 전략은 거기서 시작합니다.