[1편] AI에게 커머스 데이터를 이해시키려면 — 온톨로지가 먼저다

"주문 데이터 넣었는데 AI가 엉뚱한 답을 합니다."

커머스 데이터에 LLM을 붙여본 AX팀이라면 한 번쯤 겪는 문제입니다. 주문 테이블, 광고 리포트, 상품 마스터, CS 로그를 전부 넣었는데 AI가 "3월 ROAS"를 물으면 광고비는 Meta 기준, 매출은 실시간 미확정 기준으로 답합니다. 숫자는 나오지만 비즈니스적으로 틀린 답입니다.

문제는 AI가 아닙니다. 데이터 사이에 관계가 정의되지 않은 것이 문제입니다.

라플라스는 5년간 500개 이상의 D2C 브랜드 데이터를 연결하면서 이 문제를 풀어왔습니다. 이 글에서는 우리가 왜 온톨로지라는 구조를 선택했고, 실제로 어떻게 구현하고 있으며, 그 결과 AI가 어떻게 달라지는지를 공유합니다.

AX팀을 꾸리고 커머스 데이터에 AI를 얹으려는 엔지니어들에게 하나의 참고점이 되기를 바랍니다.

왜 테이블을 합치는 것만으로는 부족한가

커머스 데이터의 가장 큰 특성은 같은 개념이 소스마다 다른 이름과 다른 단위로 존재한다는 점입니다.

예시: "매출"이라는 하나의 단어

하나의 "매출"이 최소 5가지 다른 숫자로 존재합니다.

단순히 테이블을 JOIN한다고 이 문제가 풀리지 않습니다. order_price_amount와 purchase_value를 같은 날짜로 조인하면 실시간 미확정 매출과 픽셀 전환 매출이 섞이고, 여기서 ROAS를 계산하면 현실과 전혀 다른 숫자가 나옵니다.

이 문제를 "데이터 클렌징"이나 "ETL 잘 짜기"로 해결할 수 있다고 생각하기 쉽습니다. 하지만 우리 경험상, 소스가 10개를 넘고 고객사가 100개를 넘는 순간 ETL 로직만으로는 관계를 유지할 수 없습니다. 관계 자체를 별도의 레이어로 관리해야 합니다.

그게 온톨로지입니다.

온톨로지란 무엇인가 — 엔지니어를 위한 정의

학술적 정의를 빌리면 "도메인 내 개념과 그 관계를 명시적으로 정의한 모델"입니다. 하지만 실무에서는 이렇게 이해하는 편이 빠릅니다.

온톨로지 = 테이블 스키마 + 테이블 간 관계 규칙 + 비즈니스 맥락 메타데이터

RDBMS의 FK(Foreign Key)도 관계를 정의하지만, 온톨로지는 거기서 한 걸음 더 나아갑니다.

FK는 "이 ID가 저 테이블에 있다"를 보장합니다. 온톨로지는 "이 숫자가 저 숫자와 어떤 비즈니스 맥락에서 연결되는가"를 정의합니다.

라플라스의 온톨로지 구조: 3개의 관계 레이어

라플라스는 커머스 데이터의 관계를 크게 세 레이어로 나눠 관리합니다.

레이어 1: 광고 ↔ 커머스 관계 (Ad Relation)

가장 까다로운 관계입니다. Meta 광고 계정의 캠페인이 카페24의 어떤 브랜드·채널 매출에 기여했는지를 연결합니다.

Ad Channel (Meta, Google, Naver, Kakao...)
  └─ Ad Account
       └─ Campaign → Adset → Ad → Landing URL
                                        ↕
Commerce Channel (카페24, 스마트스토어, 쿠팡...)
  └─ Brand → Channel → Shop → Product

이 관계가 없으면 광고비 100만 원이 어느 상품의 매출에 기여했는지 알 수 없습니다. 대부분의 커머스 BI 툴이 "광고 데이터"와 "주문 데이터"를 각각 보여주는 이유가 여기에 있습니다. 두 데이터를 연결하는 관계 정의가 없기 때문입니다.

라플라스는 ad_channel_name → brand_name → channel_name → product_id까지의 매핑을 관계 테이블로 명시적으로 관리합니다. 이 관계가 있어야 "이 캠페인이 이 브랜드의 이 채널 매출에 기여했다"는 연결이 가능하고, 비로소 **확정매출 기준의 진짜 ROAS(POAS)**를 계산할 수 있습니다.

레이어 2: 상품 ↔ 원가 관계 (COGS Relation)

커머스에서 두 번째로 어려운 관계입니다. "옵션"과 "기초상품(SKU)"을 연결합니다.

주문 데이터의 옵션
  (brand, channel, product_id, option_id)
       ↕  N:M 관계
기초상품 (SKU)
  (item_brand, item_id, item_name, item_qty)

같은 물건인데 카페24에서는 "블랙 L", 스마트스토어에서는 "BK/Large"로 올라옵니다. 하나의 SKU에 여러 옵션이 매핑되고, 하나의 옵션이 여러 SKU의 세트 상품일 수도 있습니다. 여기에 사은품(is_gift)까지 얽힙니다.

이 관계가 없으면:

• 상품별 마진율을 계산할 수 없습니다 (원가를 모르니까)

• 재고 소진율을 정확히 볼 수 없습니다 (같은 SKU가 여러 옵션에 분산되니까)

• "사은품이 재구매에 미치는 영향"을 분석할 수 없습니다 (사은품 여부를 모르니까)

라플라스는 이 관계를 4가지 방식으로 설정합니다: MANUAL(사용자 직접 매핑), SOLUTION(솔루션 자동 매핑), RULE(규칙 기반 매칭), AI(AI 추론 매칭). 우선순위 시스템으로 충돌을 해결합니다.

레이어 3: 측정값 메타데이터 (Dashboard Meta)

이 레이어가 AI 에이전트와 직접 맞닿는 지점입니다.

# dashboard_meta 예시 (실제 구조를 단순화)
- column: net_sales_amount
  type: measure
  data_source: order
  data_source_info: cafe24_order
  label: "순매출"
  info: "확정 매출에서 취소/반품을 제외한 금액. 실시간 매출과 다를 수 있음."
  label_info: "순매출 (확정 기준)"

모든 측정값(measure)과 차원(dimension)에 비즈니스 정의, 소속 데이터소스, 유효한 필터 조합이 메타데이터로 붙어 있습니다. 현재 라플라스에는 이런 메타 정의가 639개 있습니다.

이게 왜 중요한지는 다음 섹션에서 설명합니다.

온톨로지가 AI의 동작을 어떻게 바꾸는가

라플라스의 AI 에이전트는 사용자 질문을 받으면 다음 순서로 동작합니다.

1. 질문 수신: "3월 Meta 광고 ROAS가 어떻게 되나요?"
     ↓
2. 메타데이터 조회: dashboard_meta에서 ROAS 관련 측정값 탐색
   → ad_spend (광고비, Meta Ads 소스)
   → net_sales_amount (순매출, 주문 소스, 확정 기준)
     ↓
3. 관계 확인: Ad Relation에서 Meta 광고 계정 ↔ 브랜드/채널 매핑 조회
     ↓
4. 쿼리 생성: 올바른 소스와 올바른 기준으로 벡터DB 쿼리 조합
     ↓
5. 검증: 쿼리 파라미터가 해당 데이터소스에서 유효한 조합인지 validation
     ↓
6. 응답: "3월 Meta ROAS는 확정매출 기준 287%입니다"

온톨로지가 없다면 3번과 5번이 불가능합니다.

AI는 ad_spend와 order_price_amount를 같은 날짜로 나눠서 ROAS를 계산할 겁니다. 하지만 order_price_amount는 취소 전 금액이고, 해당 광고 계정이 어느 브랜드/채널 매출에 연결되는지도 모릅니다. 숫자는 나오지만 비즈니스적으로 의미 없는 답입니다.

온톨로지가 있으면 AI는:

• "ROAS를 계산하려면 광고비와 매출이 필요하다"를 메타데이터에서 읽고

• "이 광고 계정은 이 브랜드/채널에 연결된다"를 관계 테이블에서 확인하고

• "매출은 확정 기준 순매출을 써야 한다"를 측정값 정의에서 판단합니다

AI가 도메인 전문가처럼 동작하는 것이 아니라, 도메인 전문가가 정의한 관계를 따라가는 것입니다. 이 차이가 핵심입니다.

RAG만으로 안 되는 이유

"메타데이터를 벡터 DB에 넣고 RAG로 검색하면 되지 않나?"라는 질문을 자주 받습니다.

라플라스도 벡터 검색을 씁니다. 639개 측정값의 label과 info를 임베딩해서 임베디드 분석 엔진에 저장하고, 사용자 질문과 유사한 측정값을 찾습니다. 하지만 이것만으로는 부족합니다.

RAG가 풀 수 있는 문제:

• "순매출이라는 지표가 있나?" → 벡터 유사도 검색으로 찾을 수 있음

RAG가 풀 수 없는 문제:

• "이 Meta 캠페인의 순매출은?" → 광고↔커머스 관계 테이블 조회 필요

• "이 상품의 마진율은?" → 옵션↔SKU↔원가 관계 체인 탐색 필요

• "순매출에 사은품 매출이 포함되나?" → 관계의 비즈니스 정의 참조 필요

RAG는 "무엇이 있는지"를 찾는 데 강합니다. 하지만 "그것들이 어떻게 연결되는지"는 관계 구조가 명시적으로 정의되어 있어야 합니다.

우리의 결론은 이렇습니다.

벡터 검색은 관문(gate)이고, 온톨로지는 지도(map)다. AI는 관문을 통과한 뒤 지도를 따라 걸어야 정확한 곳에 도착한다.

커머스 도메인에서 온톨로지가 특히 어려운 이유

온톨로지 자체는 새로운 개념이 아닙니다. 의료(SNOMED), 생명과학(Gene Ontology) 분야에서는 오래전부터 쓰여왔습니다. 그런데 커머스에서는 왜 이렇게 늦었을까요?

첫째, 표준이 없습니다. 의료에는 ICD-10이라는 국제 표준 분류 체계가 있지만, 커머스에는 "주문"이라는 개념의 표준 스키마조차 없습니다. 카페24의 주문 구조, 쿠팡의 주문 구조, 스마트스토어의 주문 구조가 전부 다릅니다. 필드명도, 상태값도, 확정 기준도 다릅니다.

둘째, 관계가 고객사마다 다릅니다. "이 광고 계정은 이 브랜드에 연결된다"는 규칙이 고객사 A와 고객사 B에서 완전히 다릅니다. A사는 브랜드 하나에 광고 계정 3개, B사는 광고 계정 하나에 브랜드 5개. 관계 구조 자체가 고객사별로 설정되어야 합니다.

셋째, 관계가 시간에 따라 변합니다. 3월에는 A 광고 계정이 X 브랜드에 연결되었는데, 4월에 조직 개편으로 Y 브랜드로 바뀝니다. 옵션↔SKU 매핑도 신상품 출시, 세트 구성 변경으로 계속 바뀝니다.

이 세 가지 이유 때문에 "한번 잘 만들어두면 끝"인 정적 온톨로지가 아니라, 고객사별로 설정되고 시간에 따라 갱신되는 동적 온톨로지가 필요합니다. 이것이 라플라스가 4년간 쌓아온 것의 실체입니다.

AX팀이 커머스 데이터에 AI를 얹을 때 고려할 점

이 글을 읽는 분이 커머스 기업의 AX팀 엔지니어라면, 다음 체크리스트가 참고가 될 수 있습니다.

1. "데이터가 있다"와 "관계가 있다"를 구분하십시오

주문 테이블 100만 행, 광고 리포트 50만 행이 있어도, 그 사이에 광고 계정 → 브랜드 → 채널 → 상품의 매핑이 없으면 AI는 의미 있는 교차 분석을 할 수 없습니다. 데이터 수집 프로젝트와 관계 정의 프로젝트는 별도로 계획하십시오.

2. 측정값에 비즈니스 정의를 메타데이터로 붙이십시오

sales_amount라는 컬럼에 "이것은 확정매출인가 실시간매출인가, 취소/반품이 포함인가 제외인가, 세금 포함인가 제외인가"가 명시되지 않으면, AI든 사람이든 잘못된 숫자를 쓰게 됩니다. 컬럼명만으로는 부족합니다. label, info, valid_filters 수준의 메타데이터가 필요합니다.

3. N:M 관계를 두려워하지 마십시오

옵션↔SKU, 광고↔상품, 고객↔브랜드 관계는 대부분 N:M입니다. 이것을 1:1로 단순화하면 데이터가 깨집니다. 관계 테이블을 별도로 두고, 우선순위와 충돌 해결 규칙을 설계하십시오.

4. 관계의 변경 이력을 추적하십시오

"3월에는 이 매핑이었고, 4월에는 저 매핑이었다"를 알 수 없으면, 과거 데이터를 소급 분석할 때 틀린 관계를 적용하게 됩니다. 관계 테이블에 created_at, updated_at을 반드시 두십시오.

5. AI validation 레이어를 두십시오

AI가 쿼리를 생성한 후, 그 쿼리의 파라미터 조합이 해당 데이터소스에서 유효한지 검증하는 단계를 넣으십시오. "주문 데이터소스에서 impression(노출수) 차원을 조회"하는 식의 의미 없는 쿼리를 사전에 차단할 수 있습니다.

마치며

AI 시대에 데이터 엔지니어링의 핵심 역할이 바뀌고 있습니다. 과거에는 데이터를 모으고 정제하는 것이 가장 중요했다면, 지금은 데이터 사이의 관계를 정의하고 유지하는 것이 더 중요해지고 있습니다.

LLM은 점점 똑똑해지지만, 커머스 도메인의 복잡한 관계 — 광고 계정과 브랜드의 매핑, 옵션과 SKU의 연결, 측정값의 비즈니스 정의 — 를 데이터 없이 추론하는 것은 불가능합니다. 이 관계를 명시적으로 정의한 구조, 즉 온톨로지가 있어야 AI는 비로소 도메인 전문가 수준의 답을 낼 수 있습니다.

라플라스가 4년간 500개 브랜드의 데이터를 연결하면서 쌓은 것의 본질은, 화려한 대시보드나 AI 챗봇이 아니라 그 뒤에서 관계를 정의하고 유지하는 온톨로지 인프라입니다.

AI에게 커머스 데이터를 이해시키려면, 모델을 바꾸기 전에 데이터의 관계부터 정의하십시오.

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