데이터없이 시작하는 순간, 당신의 조직은 AX에 실패한다

Claude Code로 끝날 일이 아니다

AX 팀을 만들겠다고 결정한 회사에서 가장 자주 듣는 두 마디가 있다.

"Claude Code로 우리가 하는 업무 자동화하면 되지."

둘 다 합리적으로 들린다. 그래서 위험하다. AX의 가장 큰 함정은 AI를 도입하는 일을 너무 가볍게 본다는 점이다. 그리고 그 가벼움의 가장 깊은 뿌리는 데이터와 온톨로지를 간과하는 데 있다. 좋은 모델을 깔면 자동으로 일이 풀린다고 생각하는 순간, 그 팀은 1년 안에 "데모는 잘 되는데 실제 운영에서는 못 쓰겠다"는 결론에 도달한다.

AI 성능은 모델의 함수가 아니다

GPT-5가 나오든 Claude 5가 나오든, AX의 운영 성능은 한 줄로 정리된다.

AI 운영 성능 = 데이터 품질 × 온톨로지 정합성 × 모델 성능

대부분의 회사가 마지막 항(모델)만 본다. 그러나 앞의 두 항이 0에 가까우면 곱은 0이다. 모델을 최신으로 갈아도 0은 0이다.

D2C 환경에서 이 두 항이 0이 되는 일은 흔하다.

• 카페24의 "환불"과 쿠팡의 "취소"가 같은 상태로 묶여 매출이 이중 차감된다

• 번들 옵션이 자식 상품들로 분해되면서 수량이 두 배로 계산된다

• 같은 상품이 채널별로 다른 SKU 코드를 가져 매출 합산이 안 된다

• "주문일"이 결제 완료일인지 발송일인지가 시스템마다 다르다

• "신규 고객"의 정의가 마케팅 팀과 데이터 팀이 다르다

이 위에 AI를 얹으면 결과는 그럴듯한 거짓말이다. 자연어로 "지난 분기 베스트셀러 알려줘"를 물어보면 답은 나온다. 그 답이 맞는지 검증할 방법이 없다는 것이 문제다. AI는 빠르게, 그리고 자신감 있게 틀린다.

온톨로지란 무엇인가

거창한 단어로 보일 수 있지만, 결국 다음 질문에 답할 수 있는가의 문제다.

• "고객"은 한 사람당 하나인가, 채널별로 다른가?

• "상품"의 단위는 무엇인가 — 옵션, 모상품, SKU?

• "주문"은 결제 시점인가, 발송 시점인가?

• "환불"과 "교환"과 "취소"의 상태 전이는 어떻게 정의되는가?

• "재구매"는 같은 상품인가, 같은 카테고리인가, 같은 고객 ID 기준인가?

이 정의가 팀마다, 시스템마다, 채널마다 다르면 — 그리고 대부분의 D2C 회사가 그렇다 — 어떤 자동화도 "결과를 신뢰할 수 없는 자동화"가 된다.

온톨로지 정비는 IT 작업이 아니라 비즈니스 합의 작업이다. 영업·운영·CS·마케팅이 같은 단어를 같은 의미로 쓰기로 합의하는 일. 가장 어렵고, 가장 가치 있고, 가장 자주 건너뛰는 일이다. 컨설팅 회사가 와서 풀어줄 수도 없다. 회사 안에서 합의해야 한다.

"Claude Code로 자동화하면 되지"의 함정

이 생각의 본질은 AI를 개인 생산성 도구로 본다는 것이다. 엑셀 잘 쓰는 사람이 회사에 한두 명 있으면 굴러가던 시대의 사고방식 그대로다.

문제는 세 가지다.

첫째, 사일로화된 자동화는 누적되지 않는다. 운영 담당자 A가 Claude Code로 만든 CS 자동화와 마케팅 담당자 B가 만든 카피 자동화는 다른 데이터 정의 위에 서 있다. 두 자동화가 만나는 순간 — 예를 들어 CS 인사이트로 마케팅 캠페인을 만들려는 순간 — 다시 사람이 손으로 매핑해야 한다. 자동화는 늘었는데 일은 그대로다.

둘째, 데이터 의미가 표준화되지 않으면 같은 질문에 다른 답이 나온다. "지난달 재구매 고객 수"를 A가 만든 자동화는 1,247명으로, B가 만든 자동화는 982명으로 답한다. 둘 다 코드는 멀쩡하다. 다만 "재구매"의 정의가 다르다. 이 상태에서 회의를 하면 의사결정이 불가능해진다. 숫자보다 정의를 두고 다투는 회의가 늘어난다.

셋째, 개인 자동화는 그 사람이 떠나면 끝난다. 코드는 남아도 정의는 머릿속에 있다. 인수인계 문서를 백 페이지 써도, 다음 사람은 그 자동화가 어떤 가정 위에 있는지 모른다. 결국 새로 짠다.

Claude Code는 강력한 도구다. 다만 그 도구가 향하는 데이터의 의미가 합의되지 않은 상태에서 자동화를 늘리는 일은 자산이 아니라 부채를 늘리는 일에 가깝다. "AI 자동화 100건 달성"은 듣기 좋지만, 그 100건의 자동화가 서로 모순된 정의 위에 서 있다면 그건 100개의 지뢰다.

"플랫폼으로 되는 거 AI로 자동화하면 되지"의 함정

이 생각의 본질은 AI를 단순 자동화의 비싼 버전으로 본다는 것이다.

룰 기반 자동화로 풀 수 있는 문제를 굳이 AI로 푸는 것은 ROI가 안 나온다. 정해진 양식의 송장 발송, 정해진 트리거의 알림, 정해진 양식의 리포트 — 이런 일은 워크플로 도구나 단순 스크립트가 더 싸고 안정적이다. AI를 쓸 이유는 룰로 못 짜는 영역에 있을 때다.

그런데 많은 회사가 둘 중 하나를 한다.

1. 룰 기반 자동화로 충분한 일을 AI라고 부르고 도입한다. 비용은 늘고 안정성은 떨어지는데, "AI 도입" 마일스톤은 달성한다. 평가용 자동화다.

2. 반대로, AI가 진짜 가치 있는 영역(비정형 데이터 해석, 맥락 기반 판단, 자연어 인터페이스)은 손도 못 댄다. 데이터가 정리되어 있지 않아 AI에게 시킬 일 자체가 없기 때문이다.

두 함정 모두 결국 같은 곳으로 돌아온다. 온톨로지가 깔리지 않은 상태에서는, AI가 잘하는 일(맥락 기반 판단)을 시킬 데이터 자체가 없다. 그러니 룰 기반 자동화를 비싸게 다시 만드는 것 외에 할 일이 안 보인다. 그렇게 만들어진 "AI 자동화"는 결국 더 비싼 매크로다.

가장 흔한 반론: "일단 시작하면서 정비하면 되지 않나"

여기서 자주 나오는 반론이 있다. "완벽한 데이터 정비가 끝날 때까지 기다리면 영영 시작 못 한다. 일단 만들면서 정비하자."

이 말은 절반은 맞고 절반은 틀렸다.

맞는 부분은, 모든 데이터를 정비한 뒤 시작하는 것은 불가능하다는 점이다. D2C 데이터는 끝없이 변한다. 새 채널, 새 상품 형태, 새 결제 방식이 매달 생긴다.

틀린 부분은, "정비 없이도 자동화를 쌓을 수 있다"는 가정이다. 정의 합의 없는 자동화는 쌓이지 않는다. 한 명이 떠나면 사라지고, 두 자동화가 만나면 충돌한다. 결국 "왜 우리 AI 프로젝트는 작동하지 않는가"라는 회고를 1년 뒤에 하게 된다.

현실적인 답은 이렇다. 핵심 엔티티 몇 개의 정의를 먼저 합의하고 시작한다. 고객·상품·주문·환불, 이 정도만 합의되어도 첫 자동화들이 누적될 토대가 된다. 그 위에서 점진적으로 확장하면 된다. 합의 없이 시작하는 게 빠르지 않다.

AX 팀의 첫 번째 일

도구를 사기 전에, 자동화를 시작하기 전에, AX 팀이 먼저 해야 하는 일은 다음이다. 추상적으로 들리는 단계지만 산출물과 진행 방식은 매우 구체적이다.

1. 핵심 엔티티의 표준 정의를 합의한다

가장 자주 다투는 단어 3~5개부터 시작한다. 보통 고객 / 상품 / 주문 / 환불 / 채널이다. 회의실에 영업·운영·CS·데이터·마케팅을 모아두고, 각 팀이 그 단어를 어떻게 정의해서 쓰고 있는지 적게 한다. 정의가 다르다는 사실을 우선 가시화하는 것이 1차 목표다. 같은 회사 안에서 "재구매 고객"의 정의가 네 가지 나오는 일이 흔하다.

다음으로 한 명의 오너(보통 데이터 리드나 PM)가 결정권을 가지고 정의를 통일한다. 합의가 안 되는 항목은 표결로 끌지 말고 결정하고 기록한 뒤 영향받는 팀에 어떻게 전환할지 알린다. 합의 자체보다 결정과 일관성이 중요하다.

산출물은 단순하다. 한 페이지짜리 데이터 사전이면 충분하다.

완벽하지 않아도 된다. 명시되고 공유되었는가가 핵심이다.

흔한 실패: 정의 합의를 IT 작업으로 위임한다. 그러면 비즈니스 맥락이 빠진 정의가 만들어지고, 현장 팀이 따르지 않는다. 결국 또 다른 정의가 등장한다.

2. 상태 전이의 명세를 작성한다

엔티티 정의가 끝나면 그 엔티티가 어떤 상태들을 거치는지 그린다. 주문이라면 결제대기 → 결제완료 → 출고대기 → 배송중 → 배송완료 → (환불요청) → (환불완료) 같은 흐름이다. 환불은 어디서 발생할 수 있는지, 교환은 어떤 상태로 추적되는지 모두 명시한다.

이 작업이 중요한 이유: 채널마다 같은 상태값이 다른 의미를 가진다. 카페24의 "주문취소"와 쿠팡의 "주문취소"는 시점도, 환불 처리 방식도 다르다. 우리 표준 상태로 어떻게 매핑하는지 정해두지 않으면 매출 합산은 무조건 어긋난다.

산출물은 상태 다이어그램 한 장 + 매핑 표.

흔한 실패: "유사한 상태니까 같이 묶자"는 결정을 빠르게 한다. 부분환불처럼 처리 방식이 미묘하게 다른 케이스를 묶어버리면, 나중에 모든 자동화가 그 묶음 위에서 잘못된 결과를 낸다.

3. 채널 간 매핑 정책을 문서화한다

상태뿐 아니라 데이터의 다른 차원도 매핑이 필요하다. 주로 다음 세 가지.

• SKU 코드 매핑: 같은 상품이 채널별로 다른 코드를 갖는다. 수동 매핑인지, 자동 매칭 후 검수인지 정한다. 신규 상품 등록 시 매핑 갱신 책임자도 같이 정한다.

• 카테고리 매핑: 카페24 카테고리 체계와 쿠팡 카테고리 체계는 다르다. 우리 내부 카테고리 트리로 어떻게 정규화할 것인가.

• 옵션·번들 처리: 옵션 분리 등록과 단일 상품 등록을 어떻게 동일시할 것인가. 번들의 GMV는 모상품에 귀속할 것인가, 자식 상품에 귀속할 것인가.

산출물은 매핑 룰 문서 + 매핑 데이터(시트 또는 DB 테이블)다. 매핑 데이터는 살아 움직이는 데이터이므로 누가 어떻게 업데이트하는지 프로세스까지 정해둔다. "신규 상품이 등록되면 24시간 안에 매핑 테이블 갱신" 같은 식으로.

흔한 실패: 매핑을 일회성 작업으로 본다. 한 번 매핑하고 나면 SKU나 카테고리가 변경되어도 갱신이 안 되어, 6개월 뒤에는 매핑 테이블이 무용지물이 된다.

4. 데이터 품질 지표를 측정한다

정의와 매핑이 잡혔다면, 그 위에서 흐르는 데이터가 실제로 약속대로 들어오는지 측정한다. 핵심 지표는 세 가지.

• 정합성(Consistency): 같은 사실을 다른 시스템에서 같은 값으로 기록하는가. 예 — 쿠팡 원본 매출과 우리 시스템 매출의 일별 차이.

• 완전성(Completeness): 누락 없이 수집되는가. 예 — 어제자 주문 데이터가 오늘 오전 9시에 100% 들어와 있는가.

• 신선도(Freshness): 얼마나 최신인가. 예 — 환불 데이터가 채널 발생 시점 대비 몇 시간 지연되어 들어오는가.

산출물은 데이터 품질 대시보드와 이상치 알림 체계. 임계치를 정해두고 슬랙으로 자동 알림. 이 지표가 안 보이면 어떤 AI 결과도 신뢰할 근거가 없다. "오늘 매출이 어제보다 30% 떨어졌다"는 AI 답변이 실제 매출 하락인지, 데이터 수집 누락인지 구별할 방법이 없기 때문이다.

흔한 실패: 품질 지표를 만들고 나서 아무도 보지 않는다. 임계치 초과 알림이 매일 와도 묵살되면, 결국 데이터를 못 믿는 운영이 된다. 한 명의 오너가 매일 5분이라도 보는 체계를 만든다.

5. 그 위에 자동화를 올린다

여기까지 오면 이제 자동화를 시작할 수 있다. 그러나 여기서도 순서가 있다.

• ROI가 명확한 영역부터 시작. CS 1차 분류, 일별 운영 리포트, 이상치 알림 같은 영역. 새로운 능력보다 기존 업무 시간 절감이 측정하기 쉽다.

• 자동화마다 의존하는 정의를 명시. "이 자동화는 '주문 = 결제완료 시점' 정의에 의존한다"는 메타데이터를 남긴다. 정의가 바뀔 때 어떤 자동화가 영향받는지 즉시 알 수 있다.

• 사람과 병행 검증 기간을 둔다. 최소 2주는 AI 결과와 사람 결과를 같이 운영하면서 차이를 분석한다. 차이가 줄어들면 자동화로 전환.

이 단계부터 만들어지는 자동화는 누적된다. 정의가 같으니 두 자동화를 합쳐도 결과가 어긋나지 않는다. 인수인계도 가능하다. 정의 문서를 같이 넘겨주면 된다.

첫 분기 일정 예시

• 1~2주차: 핵심 엔티티 정의 합의 (워크숍 + 결정)

• 3~4주차: 상태 전이 명세 + 채널 매핑 1차안

• 5~8주차: 데이터 품질 지표 구축 + 매핑 데이터 정비

• 912주차: 첫 자동화 23건 운영 + 병행 검증

지루하다. 보고할 거리가 없어 보인다. "이번 분기 우리는 환불 상태 정의를 통일했습니다"는 발표가 잘 안 된다. 그러나 이 12주를 건너뛴 회사는 1년 뒤 같은 곳에 더 비싼 채로 머물러 있다.

마치며

AI 위에 비즈니스를 올리는 게 아니다. 비즈니스를 정의한 위에 AI를 올리는 것이다.

순서를 거꾸로 잡으면 비싸기만 한 자동화, 일관성 없는 결과, 의사결정을 못 하는 미팅이 남는다. AX는 도구의 문제가 아니라 데이터의 문제다. 그리고 데이터는 결국 우리가 비즈니스를 어떻게 정의했는가의 문제다.

그러니 AX 팀을 만들기로 했다면, 첫 분기를 데이터와 온톨로지에 쓰는 게 맞다. 가장 지루한 선택이지만, 가장 빠른 길이다.

---

라플라스는 D2C 커머스 브랜드를 위한 데이터 분석 인프라입니다. 흩어진 주문, 광고, 상품, CS 데이터에 관계를 설정하고, AI가 바로 이해할 수 있는 형태로 제공합니다.