결론부터 말하면, AI가 회사 데이터를 이해하지 못하는 이유는 AI가 “이해력이 부족해서”가 아닙니다. 애초에 이해할 수 있는 형태로 데이터가 준비되어 있지 않기 때문입니다. 이 글에서는 그 구조적인 이유를 짚어봅니다.
사람은 “안다”고 착각하지만, 사실은 물어봐서 아는 것이다
어느 회사든 신입사원이 들어오면 몇 주는 헤맵니다. TB_CUSTOMER 테이블의 STAT_CD 컬럼에서 3이 무엇을 뜻하는지, 왜 어떤 주문은 ORDER 테이블이 아니라 ORDER_LEGACY 테이블에 들어가 있는지, 이런 것들은 문서에 안 쓰여 있는 경우가 대부분입니다. 옆자리 선임에게 “이거 왜 이래요?”라고 물어봐야 알 수 있습니다.
이 지식을 흔히 “암묵지(tacit knowledge)”라고 부릅니다. 회사가 오래될수록, 시스템이 여러 번 교체될수록 암묵지는 쌓입니다. 문제는 이 암묵지가 데이터베이스 어디에도 기록되어 있지 않다는 겁니다. 사람은 “물어봐서” 압니다. AI는 물어볼 사람이 없습니다. 스키마와 값만 보고 판단해야 합니다.
AI가 보는 것은 “의미”가 아니라 “패턴”이다
LLM에 회사 DB 스키마를 통째로 넘겨주면 그럴듯한 답을 내놓습니다. 컬럼 이름, 데이터 타입, 샘플 값을 보고 “아마 이런 뜻이겠구나”를 매우 잘 추론하기 때문입니다. 이 추론 능력 자체는 실제로 인상적입니다. 문제는 “아마 이런 뜻일 것”과 “실제로 이런 뜻”이 회사 데이터에서는 자주 어긋난다는 점입니다.
예를 들어 IS_ACTIVE라는 컬럼이 있다고 해봅시다. 일반적인 상식으로는 “활성 상태 여부”입니다. 그런데 특정 회사에서는 이 컬럼이 “활성 상태”가 아니라 “재계약 대상 여부”를 의미하도록 변형되어 쓰이고 있을 수 있습니다. 처음 설계할 때는 그 의미였는데, 몇 년에 걸쳐 용도가 바뀌었고, 이름만 그대로 남은 것입니다. 사람은 이런 배경을 구두로 전달받아 압니다. AI는 컬럼 이름만으로 상식적인 추론을 하고, 그 추론은 이 경우 틀립니다.
관계는 값보다 더 숨어 있다
값의 의미도 문제지만, 더 큰 맹점은 테이블 간의 관계입니다. “이 주문이 어느 고객의 것인지”, “이 고객이 어느 영업 담당자에게 배정되어 있는지” 같은 관계는 외래키로 명시되어 있으면 그나마 낫습니다. 실무에서는 이 관계가 애플리케이션 코드 안의 조인 로직에만 존재하거나, 심지어 담당자의 머릿속에만 존재하는 경우도 드물지 않습니다.
AI에게 “이번 달 이탈 위험이 높은 고객을 담당자별로 정리해줘”라고 물으면, AI는 고객, 이탈 위험, 담당자라는 세 개념을 어딘가에서 연결해야 합니다. 이 연결 경로가 명시적으로 정의되어 있지 않으면, AI는 그럴듯해 보이는 조인을 스스로 추측해서 만들어냅니다. 우연히 맞을 수도 있지만, 반복해서 정확하기는 어렵습니다.
그래서 필요한 것은 “더 똑똑한 AI”가 아니라 “먼저 정리된 지도”
여기까지 보면 결론은 자연스럽게 나옵니다. 문제가 “추론 능력의 한계”가 아니라 “정의되지 않은 의미와 관계”에 있다면, 해법도 모델을 바꾸는 게 아니라 데이터에 의미를 입히는 작업이어야 합니다. 컬럼과 테이블에 업무 용어를 붙이고, 테이블 간의 관계를 사람이 이해하는 형태로 미리 정의해두는 작업입니다.
이 작업을 온톨로지라고 부릅니다. “온톨로지”라는 단어가 거창하게 들릴 수 있지만, 실무적으로는 “회사의 현실을 소프트웨어와 AI가 이해할 수 있는 형태로 옮겨놓은 지도”에 가깝습니다. TB_CUSTOMER는 “고객”이라는 오브젝트가 되고, STAT_CD = 3은 “휴면 고객”이라는 사람이 읽을 수 있는 상태가 되고, “고객이 주문한다”는 관계는 코드 어딘가에 숨어 있는 조인이 아니라 미리 정의된 링크가 됩니다.
이 지도가 있으면 무엇이 달라지는가
지도가 갖춰지면 AI는 스키마를 보고 매번 추측하는 대신, 이미 정의된 개념과 관계를 그대로 따라갑니다. 같은 질문에 같은 경로로 답하기 때문에 일관성이 올라가고, 새로운 직원이나 새로운 AI 에이전트가 투입되어도 학습해야 할 암묵지가 크게 줄어듭니다. 그리고 이 지도 위에 “행동(승인, 실행 등)”까지 정의해두면, AI의 답이 단순한 텍스트로 끝나지 않고 실제 업무 처리로 이어질 여지가 생깁니다.
물론 이 지도를 그리는 작업 자체가 공짜는 아닙니다. 누가 설계하고, 업무가 바뀔 때마다 어떻게 갱신할지에 대한 거버넌스가 함께 필요합니다. 하지만 회사 데이터를 AI가 지속적으로, 정확하게 다뤄야 하는 상황이라면 이 초기 투자를 건너뛰기는 어렵습니다.
더 읽어보기
이 구조적인 이유를 실제 챗봇 프로젝트 실패 사례에 대입해 보고 싶다면 기업 AI가 챗봇에서 멈추는 이유를 이어서 읽어보시길 권합니다. 온톨로지가 실제로 어떤 구성요소로 이루어지는지 궁금하다면 온톨로지 핵심 구성요소 — 오브젝트·링크·액션·Functions로 낱어보기에서 오브젝트, 링크, 액션 단위로 자세히 다룹니다.