SAP CAR 솔루션 - 리테일 옴니채널 데이터 기반 이해하기#

#CAR은 무엇인가

SAP CAR은 SAP Customer Activity Repository의 약자입니다. 이름 그대로 "고객 활동(Customer Activity)을 모아두는 저장소(Repository)"이며, 리테일 기업의 매장·온라인·모바일 등 여러 채널에서 발생한 판매/재고/수요 데이터를 한곳에 통합해 두는 데이터 기반(Foundation) 입니다.

여기서 중요한 것은 CAR이 업무 모듈이 아니라 "플랫폼 성격의 솔루션" 이라는 점입니다. MM이나 SD처럼 ERP 안의 모듈이 아니라, SAP HANA 위에서 동작하는 별도의 ABAP 기반 서버로 구축되며, ERP(ECC/S4)와 인터페이스로 연결됩니다.

#왜 CAR을 쓰는가

리테일에서 발생하는 데이터의 특성을 보면 이유가 분명해집니다.

• 양이 매우 많다 — 매장 POS 영수증은 건수 기준으로 ERP 전표와 비교가 안 될 만큼 많습니다. 이걸 그대로 ERP에 쌓으면 기간 업무 성능에 영향을 줍니다.
• 원본(영수증 단위)이 필요하다 — ERP로는 보통 집계된 매출/재고 반영분만 넘어갑니다. 하지만 "어떤 고객이 무엇을 함께 샀는지" 같은 분석은 영수증 라인 단위 원본이 있어야 가능합니다.
• 채널이 여러 개다 — 매장, 온라인몰, 앱 등 채널별로 시스템이 다르면 "지금 이 상품이 전사에 얼마나 있고 얼마나 팔리는지"를 한 번에 보기 어렵습니다.
• 예측이 필요하다 — 수요 예측·발주 제안·프로모션 효과 시뮬레이션은 대량 데이터 위에서 돌아가는 연산이라 별도 기반이 유리합니다.

정리하면 CAR은 "ERP는 기간 업무에 집중시키고, 대량 리테일 데이터의 수집·정제·예측은 HANA 기반 별도 계층에서 처리한다" 는 아키텍처 선택입니다.

#기본 구조

CAR의 데이터 흐름을 단순화하면 다음과 같습니다.

동시에 POS DTA는 감사를 통과한 거래를 ERP 쪽으로도 전달해 매출·재고·회계 반영이 이루어지도록 합니다. 즉 CAR은 ERP를 대체하는 것이 아니라 앞단에서 받아 정제한 뒤 양쪽으로 흘려보내는 허브에 가깝습니다.

#핵심 구성 요소

구성 요소	이름	역할
POS DTA	POS Data Transfer and Audit	매장 POS 거래로그(TLOG)를 수신해 검증·감사(Audit) 하고, 오류 건은 워크벤치에서 수정·재처리한 뒤 후속 시스템으로 전달
DDF	Demand Data Foundation	예측·수요 관련 애플리케이션이 공통으로 쓰는 마스터/거래 데이터 기반 계층
UDF	Unified Demand Forecast	DDF 데이터를 바탕으로 수요를 예측하는 엔진. 프로모션 효과 등도 반영
OAA	Omnichannel Article Availability and Sourcing	채널 전체의 재고 가용성 확인과 출고처(Sourcing) 결정
OSA	On-Shelf Availability	판매 패턴을 분석해 진열대 결품(품절)이 의심되는 상품을 탐지
OPP	Omnichannel Promotion Pricing	채널 전반에 일관된 프로모션 가격을 계산
멀티채널 거래 데이터 관리	Multichannel Transaction Data Management	채널별로 들어온 거래 데이터를 한 기준으로 모아 관리

#전체 그림 - 어디서 들어와 어디로 나가는가

앞에서 구성 요소를 하나씩 봤는데, 실제로는 원천 시스템에서 데이터가 들어와 CAR을 거쳐 다시 여러 시스템으로 나가는 흐름으로 이해하는 편이 빠릅니다.

#① 원천 시스템에서 들어온다

어디서	무엇이	어떻게
S/4HANA Retail · ERP Retail	마스터 데이터, 재고, 판매 문서	SLT로 실시간 복제
CRM · 마케팅	고객 데이터	SLT로 실시간 복제
매장 POS	거래로그(TLOG)	POS DTA가 수신

여기서 눈여겨볼 것이 SLT입니다. ERP의 마스터와 거래 데이터를 CAR로 복제해서 쓰는 구조라, CAR은 ERP 데이터를 "가져다 보는" 쪽이지 원천이 아닙니다. 그래서 앞에서 말한 것처럼 마스터의 원천은 어디까지나 ERP입니다.

#② CAR 안에서 처리된다

POS DTA가 받은 거래를 감사하고, DDF가 공통 데이터 기반을 제공하며, 그 위에서 UDF가 수요를 예측합니다. OAA·OSA·OPP가 각각 재고 가용성, 결품 탐지, 프로모션 가격을 담당합니다.

그 위에 HANA 기반 분석 콘텐츠가 얹혀 있어, 쌓인 데이터를 따로 가공하지 않고도 분석에 쓸 수 있도록 되어 있습니다.

#③ 애플리케이션이 CAR을 쓴다

CAR 자체는 기반입니다. 사용자가 실제로 만지는 것은 그 위에 올라가는 애플리케이션입니다.

• 프로모션 관리(PMR) — 별도 글에서 자세히 다룹니다
• 상품기획(Merchandise Planning)
• 구색기획(Assortment Planning)
• 물량배분(Allocation Management)

#④ 다시 밖으로 나간다

CAR이 종착지가 아니라는 점이 중요합니다. 처리·예측 결과는 다시 흘러나갑니다.

• ERP로 — 매출·재고 반영
• 커머스 시스템으로 — 채널 재고·가격
• 수요예측·보충(F&R) 으로 — 예측 결과 기반 발주
• BW로 — 전사 리포팅

#기능을 간단히 정리하면

#개발자 입장에서의 포인트

• 별도 시스템이다 — CAR은 ERP와 다른 시스템 ID를 가진 서버인 경우가 일반적입니다. 접속·인증·전송(Transport) 경로가 ERP와 별개라는 점을 먼저 확인해야 합니다.
• 인터페이스가 핵심이다 — 마스터 데이터는 ERP에서 CAR로 내려오고, 거래 데이터는 POS에서 CAR로 올라옵니다. 문제 대부분은 연계 구간에서 발생합니다.
• 조회는 HANA 뷰/CDS 기반 — 대량 데이터를 다루는 만큼 전통적인 ABAP 내부 테이블 루프보다 DB 레벨 연산이 중심입니다. 관련해서는 AMDP 글도 참고할 만합니다.