IS_ACTIVE 컬럼 하나가 회사 전체를 헷갈리게 만든 이야기

IS_ACTIVE 컬럼 하나가 회사 전체를 헷갈리게 만든 이야기

IS_ACTIVE가 진짜로 뜻하는 것

고객 테이블에 IS_ACTIVE라는 컬럼이 있다고 해봅시다. 이름만 보면 “지금 활성 고객인가”를 뜻할 것 같습니다. 그런데 실제로 이 회사에서는 이 컬럼이 “다음 분기 재계약 대상으로 분류된 고객인가”를 의미했습니다. 계약이 끝나 활동이 없는 휴면 고객도 재계약 협상 중이면 IS_ACTIVE = 1로 표시돼 있었던 겁니다.

이 회사에 새로 입사한 사람이라면 이 사실을 어떻게 알게 될까요. 문서에는 없습니다. 대부분 옆자리 선임에게 “이 컬럼이 뭐예요?”라고 물어봐서 알게 됩니다. 이게 암묵지(tacit knowledge)입니다. 문서화되지 않고 사람 사이에서만 전달됩니다.

AI에게는 물어볼 선임이 없다

문제는 AI에게는 옆자리 선임이 없다는 겁니다. AI는 컬럼명 IS_ACTIVE와 샘플 값(0, 1)만 보고 “활성 고객 여부”라고 추측합니다. 이 추측은 아주 그럴듯하지만 틀렸습니다.

이 상태에서 “활성 고객 수를 알려줘”라고 물으면, AI는 IS_ACTIVE = 1인 행을 세어서 답합니다. 숫자는 나오지만, 그 숫자가 가리키는 건 활성 고객이 아니라 재계약 대상 고객입니다. 에러 없이 실행되고 그럴듯한 숫자가 나오기 때문에, 담당자는 이 오류를 한동안 눈치채지 못합니다.

AI가 보는 것은 ‘의미’가 아니라 ‘패턴’

이게 반복되는 이유는 LLM의 작동 방식 때문입니다. LLM은 컬럼명과 샘플 값에서 패턴을 추론합니다. IS_ACTIVE라는 이름, 0과 1이라는 값 — 이 패턴은 인터넷에 있는 수많은 데이터베이스에서 “활성 여부”를 의미했을 가능성이 높습니다. LLM은 이 통계적 패턴을 따라갑니다. 하지만 이 회사의 IS_ACTIVE는 그 패턴을 따르지 않는 예외였습니다. AI에게는 이 컬럼의 “의미”가 아니라 “이름의 생김새”만 보이는 겁니다.

관계는 값보다 더 깊이 숨어 있다

컬럼 하나의 의미가 헷갈리는 것보다 더 심각한 문제가 있습니다. 테이블 간의 관계입니다.

“지난달 이탈한 고객 중 담당 영업 사원이 누구인지 알려줘”라는 질문에 답하려면, 고객 테이블과 이탈 이력 테이블, 담당자 배정 테이블을 연결해야 합니다. 그런데 이 연결이 데이터베이스의 외래키로 정의되어 있지 않고, 애플리케이션 코드 안에 하드코딩되어 있거나, “이건 그냥 다들 아는 규칙”으로만 존재하는 경우가 많습니다.

AI는 이 숨겨진 규칙을 볼 수 없습니다. 그래서 컬럼명이 비슷해 보이는 필드를 임의로 골라 조인합니다. 이번에도 에러는 나지 않습니다. 답이 나옵니다. 다만 틀린 답입니다.

필요한 건 ‘더 똑똑한 AI’가 아니라 ‘정리된 지도’

이 문제를 GPT-5, 혹은 그다음 모델로 넘어간다고 해결할 수 있을까요. 아닙니다. 모델이 똑똑해질수록 오히려 더 그럴듯하게 틀린 답을 만들어낼 뿐입니다. 문제는 모델의 추론 능력이 아니라, 애초에 “이 컬럼이 무슨 뜻인지, 이 테이블들이 어떻게 연결되는지”를 알려주는 정보 자체가 어디에도 정리되어 있지 않다는 겁니다.

온톨로지가 하는 일이 바로 이 정리입니다.

데이터베이스 관점 온톨로지 관점
테이블 CUSTOMER 오브젝트 “고객”
IS_ACTIVE = 1 속성 값 “재계약 대상” (컬럼명이 아니라 실제 의미로 표기)
암묵적으로만 존재하던 조인 명시적인 Link “고객 → 담당 영업사원”

테이블은 오브젝트가 되고, 헷갈리던 값은 실제 의미로 이름이 바뀌고, 구두로만 전해지던 조인 규칙은 눈에 보이는 Link가 됩니다.

지도가 있으면 달라지는 것들

IS_ACTIVE를 둘러싼 이 회사의 이야기가 온톨로지로 정리된 이후를 상상해보면 이렇습니다.

  • 새로 입사한 사람도, 새로 연결된 AI 에이전트도 옆자리에 묻지 않고 정의를 바로 확인할 수 있습니다. “활성 고객 수”와 “재계약 대상 고객 수”를 물었을 때 서로 다른 정확한 답이 나옵니다. 지금까지는 두 질문에 같은(틀린) 답이 나왔을 수도 있습니다. 이탈 고객과 담당자를 연결하는 질문에 AI가 매번 다른 경로로 답하는 대신, 정의된 Link를 그대로 따라갑니다. 여기서 한 걸음 더 나아가면, “재계약 대상인데 3개월간 연락이 없는 고객에게 자동으로 알림을 보낸다” 같은 Action까지 설계할 수 있습니다.

물론 공짜는 아닙니다. 이 지도를 처음 그리는 데는 시간과 사람의 투자가 필요하고, 회사가 커지면서 지도도 계속 갱신해야 합니다. 하지만 이 투자를 하지 않으면, IS_ACTIVE 같은 컬럼이 새로 생길 때마다 똑같은 혼란이 반복됩니다.

정리하면

AI가 회사 데이터를 이해하지 못하는 이유는 AI가 부족해서가 아닙니다. 사람들 사이에서만 구두로 전해지던 의미를, AI가 참조할 수 있는 형태로 아무도 정리해두지 않았기 때문입니다. IS_ACTIVE 하나가 문제가 아니라, 회사마다 이런 컬럼과 관계가 수백, 수천 개씩 숨어 있다는 게 진짜 문제입니다.

자주 묻는 질문

Q. 모든 컬럼과 테이블을 다 온톨로지로 정리해야 하나요? 아닙니다. AI나 사람이 자주 묻는 질문부터 역으로 추적해서, 그 질문에 필요한 테이블과 관계부터 정리하는 게 효율적입니다. IS_ACTIVE처럼 오해 소지가 큰 컬럼을 우선순위로 삼으세요.

Q. 이미 이런 혼란이 굳어진 회사는 어떻게 시작해야 하나요? 최근 3개월간 실제로 틀린 보고서나 잘못된 의사결정이 나온 사례를 모아보세요. 그 사례들의 공통 원인이 되는 컬럼과 테이블부터 정리하면 우선순위가 자연스럽게 정해집니다.

질문이나 지적할 부분이 있으면 문의로 알려주세요.

Questions or corrections? Let us know via Contact.

AI

AI map Ontology

기업 IT·데이터 조직에서 20년 넘게 실무를 해온 사람이 씁니다. 모든 사례는 익명화·일반화합니다. 소개 보기 →

AI

AI map Ontology

Written by someone with 20+ years in enterprise IT and data. All cases are anonymized and generalized. About us →

다음으로 읽어볼 글

개념을 이해했다면, 실제 설계와 활용 방법을 이어서 살펴보세요.

온톨로지 Foundry AIP 기업 AI 전략

Keep reading

Once you understand the concept, continue on to real design and usage patterns.

Ontology Foundry AIP Enterprise AI Strategy