Databricks Genie와 Amazon Quick 재고 보충 자동화 사례, 수요예측부터 발주까지 무인 파이프라인 구축법
한마디로
수요 급증을 예측하고 공급업체 선택과 발주까지 사람 개입 없이 처리하는 자동화 구조를 Databricks와 Amazon Quick으로 만든 사례예요
한눈에
Databricks는 리테일 수요예측과 재고 관리에 쓰이는 데이터, AI 플랫폼입니다. AWS 머신러닝 블로그가 소개한 이번 사례는 Databricks의 Many Model Forecasting(MMF)과 Chronos-2 모델로 SKU별 수요를 예측하고, Amazon Quick이 공급업체 재고와 대조해 발주까지 자동 처리하는 4단계 파이프라인을 다룹니다. 예측 시스템과 실행 시스템이 따로 놀아서 생기던 지연을 Model Context Protocol(MCP)과 OpenAPI 커넥터로 연결해 풀어낸 구조예요.
AS-IS: 예측과 실행이 따로 노는 문제
리테일 수요예측 실무에서는 플래너가 예측치를 뽑아 공급업체 재고와 대조하고 수만 개 SKU를 하나씩 검토하는 사이에 이미 잘 팔리는 상품은 품절이 나버립니다. 원문은 예측 자체는 파운데이션 모델 덕분에 카탈로그 전체를 한 번에 예측할 수 있게 되면서 어려움이 풀렸지만, 병목은 좋은 예측과 실제 발주 사이의 간격으로 옮겨갔다고 짚습니다. 예측은 거버넌스가 걸린 데이터 플랫폼에 있고 공급업체 재고 현황은 별도 운영 피드에 있는데, 정작 발주하는 사람은 두 시스템 어디에도 로그인 계정이 없는 게 원인이라고 설명해요.
이번 내용: 4단계 자동화 파이프라인
이번에 소개된 구조는 수요 급증을 탐지하고 어느 공급업체가 충당 가능한지 판단해서 사람 개입 없이 발주까지 처리하는 루프입니다. Databricks가 예측(Forecast) 단계를 맡고 나머지 탐지(Detect), 결정(Decide), 실행(Act) 세 단계는 Amazon Quick이 스케줄에 따라 반복 실행합니다. 예측 단계에서는 MMF가 Chronos-2를 서빙해 모든 SKU의 7일 수요를 예측하고, 탐지 단계에서는 Databricks Genie Agent가 향후 7일 평균이 이전 14일 평균의 1.5배 이상이면서 이전 14일 평균이 1 이상인 SKU만 급증으로 판정합니다. 결정 단계에서는 Amazon Quick이 급증 SKU를 Amazon S3 Tables의 실시간 공급업체 재고와 대조해 가장 저렴하게 충당 가능한 공급업체를 고르고, 실행 단계에서는 Amazon Quick Flows가 Supplier Order API로 정상 발주를 넣거나 어떤 공급업체도 충당 못 하면 사람 검토 티켓을 올립니다. Amazon Quick은 MCP로 Genie Agent의 예측에 접근하고, S3 Tables에서 공급업체 피드를 가져오며, OpenAPI 커넥터로 Order API를 호출해서 두 세계를 연결하는 유일한 컴포넌트 역할을 합니다.
실무 적용 포인트
원문에 딸린 저장소에는 재현에 필요한 노트북과 스크립트, 공급업체 피드 로더가 전부 포함돼 있어서 그대로 따라 구축해볼 수 있습니다. 환경 구성 시 확인할 점을 정리하면 다음과 같습니다.
- Amazon Quick 사용자는 Author 또는 Author Pro 권한이 있어야 Flows와 MCP, OpenAPI 커넥터를 만들 수 있어요
- Databricks 계정은 메타스토어에 CREATE CATALOG 권한이 필요합니다
- 리전은 Amazon Quick의 액션 커넥터, 스페이스, Flows를 지원하는 곳으로 골라야 해요
- 공급업체 피드는 63,861행 규모로 결정적(deterministic)으로 생성되며, 일부러 재고가 부족한 공급업체군을 넣어서 사람 검토 경로가 실제로 작동하는지 테스트할 수 있게 설계돼 있습니다
Genie Agent 설정에는 수요 급증 판정 기준을 고정한 예시 쿼리가 포함돼 있어서 급증 판단 결과가 항상 동일하게 나오도록 되어 있고, MCP 연결은 사용자 위임(3-legged) OAuth 방식이라 Genie 쿼리가 인증한 사람 권한으로 실행된다는 점도 실무에서 챙겨야 할 부분입니다.
자주 묻는 질문
Databricks란
Databricks는 데이터 레이크하우스 기반의 데이터 엔지니어링, 분석, 머신러닝 플랫폼입니다. 이번 사례에서는 Many Model Forecasting과 Chronos-2 모델로 수요예측을 수행하고 Genie Agent로 자연어 질의가 가능한 예측 결과를 만드는 역할을 맡았어요.
이번 자동화 사례에서 Amazon Quick의 역할은 무엇인가요
Amazon Quick은 Databricks가 만든 예측치를 MCP로 가져오고, S3 Tables의 공급업체 재고와 대조해 결정을 내린 뒤 OpenAPI 커넥터로 Order API를 호출해 실제 발주까지 실행하는 역할을 맡습니다. Databricks가 지능을 만들면 Amazon Quick이 그 위에서 행동한다는 구조예요.
마테크 자동화 사례로 어떻게 참고할 수 있나요
예측과 실행 시스템이 분리돼 지연이 생기는 문제를 MCP와 OpenAPI 커넥터 연결로 해소한 구조라서, 리테일뿐 아니라 예측과 실행 시스템이 따로 도는 다른 마케팅, 운영 자동화 파이프라인 설계에도 참고할 만합니다. 저장소에 노트북과 스크립트가 공개돼 있어 직접 재현해볼 수 있어요.
CDP 뜻이 이 사례와 관련 있나요
CDP(고객 데이터 플랫폼)는 이번 사례에서 직접 언급되지 않았습니다. 다만 예측 데이터와 운영 데이터를 각각 다른 시스템에 두고 공유 키로 연결하는 방식은 CDP가 여러 데이터 소스를 통합하는 방식과 개념적으로 비슷한 구조입니다.
에디터 노트
예측 모델을 잘 만드는 것과 그 예측을 실제 행동으로 옮기는 것 사이의 간격을 짚은 점이 실무적으로 유용합니다. 다만 이 사례는 AWS 블로그가 자사 생태계(Amazon Quick, S3 Tables, API Gateway)와 Databricks를 결합해 만든 참조 아키텍처라서, 다른 벤더 조합이나 자체 인프라 환경에 그대로 옮기려면 MCP 연결과 권한 설정 부분을 다시 검증해야 합니다.
참고 출처 | 원문 보기
태그
- Databricks
- 데이터브릭스
- Amazon Quick
- 아마존 퀵
- 수요예측 자동화
- 수요예측 자동화
- MCP
- 모델 컨텍스트 프로토콜
이 노트는 자동 검증을 거쳐 발행되었습니다. 오류 제보는 편집팀이 즉시 확인합니다.
관련 마테크
- BigQuery Graph란, Databricks Unity Catalog까지 잇는 AI 에이전트 지식 기반 활용법BigQuery가 그래프 기능을 정식 출시하면서 Databricks 테이블까지 데이터 이동 없이 연결해 AI 에이전트의 근거로 쓸 수 있게 됐어요
- Databricks OpenSharing이란, Qumulo NeuralSearch 연동으로 분산 데이터 통합 거버넌스 구현하는 법여러 곳에 흩어진 데이터를 옮기지 않고도 한 곳에서 찾고 분석할 수 있게 해주는 연동이에요
- Snowflake Observe MCP, CLI란, AI 에이전트가 텔레메트리 직접 조회하는 방법Snowflake의 Observe가 AI 에이전트용 MCP 서버와 CLI를 새로 내놔서 사람 없이도 운영 데이터를 직접 조회하고 대응하게 됐어요
- Databricks Agentic CDP란, 데이터를 캠페인 실행까지 잇는 마테크 전략데이터 인프라는 좋은데 캠페인 실행까지 못 이어지는 마지막 마일 문제를 Databricks의 통합 데이터 기반과 AI 에이전트로 메우는 이야기예요