왜 AI Analytics Tools가 잘못된 문제를 해결하고 있는가

Source: Dev.to

TLDR: AI 분석 산업은 더 나은 쿼리 엔진—LLM을 사용해 자연어를 SQL로 변환하는 것—구축에 집착하고 있습니다. 하지만 이는 실제 과제의 20 %에 불과합니다. 나머지 80 %는? 사람들의 머리 속, 문서화되지 않은 회의, 그리고 조직 전반에 흩어져 있는 위키에 존재하는 방대한 비즈니스 컨텍스트를 포착하고 유지하는 일입니다. 이 매력적이지 않은 문서화 문제를 해결하지 못한다면, AI 기반 분석은 생산 환경에서 고군분투하는 인상적인 데모에 머물게 될 것입니다.

모든 “데이터와 채팅” 데모는 똑같이 보입니다. 누군가가 세련된 인터페이스에 “지난 달 지역별 매출을 보여줘”라고 입력합니다. LLM이 SQL 쿼리를 생성합니다. 결과가 나타납니다. 모두가 고개를 끄덕이며 승인합니다.

그런 다음 여러분의 회사에 이를 배포하려고 시도합니다.

갑자기 간단해야 할 질문들이 불가능해집니다. “프리미엄 고객의 매출은 얼마인가요?”는 명확해 보이지만, 세 개의 팀이 “프리미엄”을 서로 다르게 정의하고, “매출”은 재무팀과 운영팀이 다르게 해석한다는 것을 깨닫게 됩니다.

데모가 성공한 이유는 데모에 깔끔하고 단순한 데이터가 있었기 때문입니다. 여러분의 현실은 더 복잡합니다.

모두가 만들고 있는 것

AI 분석 제품을 하나 열어보면 대체로 같은 아키텍처가 내부에 있습니다.

• 데이터베이스에 연결해 스키마(테이블, 컬럼, 데이터 타입, 외래키)를 가져옵니다.
• 질문을 할 때 관련 메타데이터를 찾기 위해 검색‑증강 생성(RAG)을 사용합니다.
• LLM이 그 컨텍스트를 받아 SQL을 생성합니다.
• 쿼리를 실행하고, 결과를 포맷하고, 필요하면 인사이트를 생성합니다.

잘 설계된 데이터베이스에 대한 간단한 질문이라면 이것으로 충분합니다. “지난 주 총 주문 수” 혹은 “지출 기준 상위 10 고객”—문제 없습니다.

이것이 모든 사람이 완벽히 다듬으려는 분석의 20 %입니다.

아무도 이야기하지 않는 80 %

실제 작업은 데이터베이스 스키마를 벗어나 비즈니스 의미가 얽힌 복잡한 세계로 들어갈 때 시작됩니다.

레이어 1: 어디에도 존재하지 않는 비즈니스 정의

데이터베이스에 customers 테이블이 200만 행이나 있습니다. 좋습니다. 그런데 “프리미엄 고객”은 누구일까요?

• 연간 1만 달러 이상을 소비하는 고객?
• 로열티 프로그램의 VIP 등급?
• 전담 계정 관리자를 가진 고객?

팀마다 답이 다릅니다.

“고용량 매장”은 무엇을 의미할까요? 매출 상위 10 %? 거래 건수 상위? 면적 기준? 답은 어딘가에 있습니다—아마 18개월 전 전략 자료에, 혹은 5년째 근무 중인 누군가의 머릿속에.

“피크 시간대”는 객관적으로 들리지만, 소매는 오전 10시‑오후 2시와 오후 5시‑8시를, 물류는 오전 7시‑11시와 오후 3시‑7시를 의미합니다.

이러한 내용은 데이터베이스에 존재하지 않습니다. LLM이 활용하기 전에 구조화된 형태로 문서화돼야 하는 비즈니스 지식입니다.

레이어 2: 메트릭과 그 숨은 복잡성

다섯 사람에게 “매출”이 무엇인지 물어보면 다섯 가지 다른 답을 얻을 수 있습니다.

• 매출에 미결 주문이 포함되나요?
• 반품은 어떻게 처리하나요?
• 할인 전인가, 후인가?
• 배송비를 포함하나요?
• 세금은 어떻게 처리하나요?
• 주문이 발생한 시점, 배송 시점, 결제 완료 시점 중 언제를 기준으로 하나요?

각 질문에 대한 답은 조직 어딘가에 존재합니다—종종 여러 곳에 여러 버전이 존재하고, 때로는 서로 모순됩니다.

분석팀은 “월간 반복 매출(MRR)”을 한 방식으로 계산하고, 재무팀은 이사회용으로 다른 방식을 씁니다. 영업 대시보드는 시험판을 제외한 세 번째 숫자를 보여줍니다.

각 메트릭은 단일 진실 소스가 필요합니다—단순한 영어 정의가 아니라 실제 비즈니스 로직(조건, 제외 항목, 엣지 케이스 등)이 문서화되고 유지돼야 합니다.

레이어 3: 도메인‑특정 비즈니스 규칙

이제 각 비즈니스 유닛이 자체 문제를 해결하기 위해 내리는 결정을 추가합니다.

• 마케팅은 최근 30일 내에 구매한 고객을 제외하고 캠페인을 진행합니다.
• 운영은 5 000달러 초과 주문에 대해 특수 처리를 합니다.
• 고객 서비스는 보증 청구를 일반 지원 티켓과 다르게 처리합니다.
• 재무는 제품 유형에 따라 매출 인식 규칙을 달리합니다.

이 규칙들은 현재 문제를 해결하기 위해 구현됩니다. 결정을 내리는 사람들은 다운스트림 분석을 고려하지 않으며, 미래 AI 시스템을 위해 문서화하지도 않습니다. 그러나 모든 결정은 데이터 의미와 해석에 영향을 미칩니다.

레이어 4: 기술 구현 결정

비즈니스 요구사항이 엔지니어링에 전달되고, 개발자는 자체 선택을 합니다.

• 마이크로서비스를 구축하고 각각이 자체 데이터를 소유합니다.
• 사용 사례에 맞는 데이터 구조를 선택합니다.
• 성능, API 계약, 배포 제약을 위해 최적화합니다.

여기서 떠오르는 질문들:

• 고객 ID는 문자열인가 정수인가?
• 주소는 구조화된 필드로 저장하나요, 아니면 자유 형식 텍스트인가?
• 타임스탬프는 UTC인가 로컬 시간인가?

서비스마다 선택이 다릅니다. 이는 ‘잘못된’ 선택이 아니라 실용적인 엔지니어링 결정입니다. 하지만 데이터는 운영의 부산물로 전락하고, 대부분의 결정은 데이터 시스템이 접근할 수 있는 곳에 문서화되지 않습니다.

레이어 5: 데이터 플랫폼 변환 레이어

마지막으로 데이터 팀이 모든 것을 하나로 모읍니다. 수십 개의 소스에서 데이터를 추출하고, 정제하고, 표준화하고, 변환합니다.

• 여섯 개의 고객 테이블을 조인해 dim_customer를 생성합니다.
• 주문 데이터에 반품, 환불, 조정을 결합해 fact_orders를 만듭니다.
• 복잡한 로직을 사용해 customer_lifetime_value와 같은 파생 메트릭을 계산합니다.

각 테이블, 각 변환, 각 파생 필드는 결정의 결과입니다. 이 ETL 작업에 어떤 비즈니스 로직이 내재돼 있나요? 왜 이렇게 변환했나요? 어떤 가정을 했나요? 어떤 엣지 케이스를 처리했나요?

문서가 없으면 이 지식은 데이터 엔지니어의 머릿속에 있거나 수백 줄의 SQL 코드에 파묻혀 있습니다.

문서 부채 위기

합산해 보면:

• 모든 도메인 용어에 대한 비즈니스 정의
• 모든 메트릭 및 KPI에 대한 정확한 로직
• 모든 비즈니스 유닛의 규칙 및 제외 항목
• 모든 엔지니어링 팀의 기술 결정
• 모든 데이터 파이프라인의 변환 로직

이것이 LLM이 실제 비즈니스 질문에 대해 올바른 쿼리를 생성하는 데 필요한 컨텍스트입니다. 그러나 거의 모든 것이 기계가 이해할 수 있는 형태로 문서화돼 있지 않습니다. 이 문서화 문제가 바로 80 %입니다.

왜 이렇게 어려운가

문서화는 수작업이며—매력적이지 않고, 시간 소모가 크며, 끝이 없습니다. 비즈니스 정의는 변합니다; 오늘의 “프리미엄 고객”은 다음 분기에 재정의될 수 있습니다. 메트릭은 비즈니스 성장에 따라 진화합니다. 규칙은 규제 변화에 따라 업데이트됩니다. 데이터 플랫폼은 테이블과 스키마를 리팩터링합니다.

정적인 문서는 작성되는 순간부터 오래됩니다. 비즈니스와 함께 진화하는 살아있는 시스템이 필요합니다.

하지만 누가 이를 담당해야 할까요? 비즈니스 팀은 비즈니스 문제에 집중하고, 엔지니어링은 기능을 출시하며, 데이터 팀은 파이프라인 유지에 매몰됩니다. 아무도…