Royfactory

TL;DRKubernetes는 클라우드 네이티브 환경에서 인프라 관리에 최적화된 도구로 널리 사용됩니다. 하지만 실시간 AI 모델 서빙에서는 종종 성능 이슈와 높은 지연 시간이 발생해 문제가 됩니다. 이 글에서는 Kubernetes에서 실시간 AI 서빙이 어려운 이유와 이를 해결하기 위한 주요 전략을 살펴봅니다.목차Kubernetes와 실시간 AI 서빙: 기본 이해Kubernetes가 실시간 AI 서빙에서 실패하는 이유실시간 AI 서빙의 주요 문제와 해결 방법Kubernetes 대안 및 비교FAQ결론 및 실무 팁Kubernetes와 실시간 AI 서빙: 기본 이해Kubernetes(쿠버네티스)는 컨테이너화된 애플리케이션의 배포, 관리, 확장 및 운영을 자동화하는 오픈 소스 플랫폼입니다. 특히 클라우드 환경..

TL;DRAI 프로젝트의 복잡성을 줄이고 생산성을 극대화하려면 전통적인 "AI 팀" 구성 대신 "소프트웨어 공장" 모델을 도입해야 합니다. 이 글에서는 소프트웨어 공장의 개념, 주요 구성 요소, 도입 방법, 그리고 실무적 이점에 대해 다룹니다.소프트웨어 공장이란 무엇인가?소프트웨어 공장은 DevOps, MLOps, 자동화된 워크플로우를 결합하여 AI 모델 개발 및 배포를 체계적으로 운영하는 환경을 의미합니다. 이는 기존의 AI 팀 구성 방식에서 벗어나, 프로세스 중심의 접근 방식을 통해 일관성, 효율성, 그리고 확장성을 제공합니다.포함 범위:- AI 및 소프트웨어 개발을 위한 자동화된 파이프라인- 팀 간의 협업을 촉진하는 구조- 반복 가능한 개발 및 배포 프로세스제외 범위:- 단순히 인력을 확장하는 방식..

TL;DR간헐수요 예측은 "0이 많은 판매 시계열"을 다루는 별도 트랙이며, 일반 MAPE 싸움으로는 답이 안 나옵니다. Croston 계열(Croston/SBA/TSB)을 최소 베이스라인으로 고정하세요.Croston은 수요 크기와 도착 간격을 분리해 평활하는 고전 접근이지만 편향 이슈가 알려져 있고, SBA는 이를 완화하는 변형으로 널리 인용됩니다."0이 많은 이유"가 진짜 무수요인지 품절/노출 부족으로 검열된 판매인지부터 분리해야 모델이 망가지지 않습니다(데이터 계약/게이트가 먼저).더 강한 확률 모델이 필요하면 제로-인플레이션 카운트 시계열(예: ZIP 기반 상태공간) 같은 접근이 연구·실무에서 쓰입니다.본문TOC주제 정규화사전 요구사항: “0의 의미”를 데이터로 고정설계 절차: 간헐 SKU 분류 ..

TL;DRAI Sales Forecasting는 "모델 학습"이 끝이 아니라 운영 루프(모니터링→원인분석→재학습/롤백)가 설계의 80%입니다.운영에서 반드시 나눠 모니터링해야 할 것은 3개: 데이터 품질(입력), 드리프트(분포), 성능(라벨 도착 후).배포는 "한 번에 교체"가 아니라 모델 레지스트리 기반 버저닝 + 챔피언/챌린저 + 카나리가 기본입니다.본문TOC사전 요구사항(로그·스키마·지연 라벨)운영 아키텍처: 배치 예측 파이프라인의 표준 형태단계별 절차: “모니터링 3종”을 먼저 만든다검증 방법: 어디를 보면 고장인지 바로 알 수 있나릴리즈 전략: 레지스트리·카나리·롤백트러블슈팅 3종(가장 흔한 사고)실무 체크리스트(배포 전 / 운영 중)FAQ(6개)1) 사전 요구사항(로그·스키마·지연 라벨)AI ..

TL;DRAI Sales Forecasting의 “정답”은 MAPE가 아니라, 목표 서비스레벨/비용을 만족하는 발주 의사결정이다.발주점(ROP)·안전재고는 “리드타임 동안의 수요 분포”를 만들고, 원하는 서비스레벨에 해당하는 분위수(quantile)를 쓰면 된다.단, 일자별 P95를 더해서 리드타임 P95를 만들면 안 된다(분위수는 합산 불가). 샘플 경로(시뮬레이션)로 합산해 분포를 만든다.단발성(프로모션/시즌) 발주는 Newsvendor(크리티컬 프랙타일)로 “부족비용 vs 과잉비용”을 분위수로 바꿀 수 있다.예측 구간(PI)이 과신되면 서비스레벨이 무너진다. 컨포멀(conformal)로 구간 커버리지를 보정하는 게 안전하다.본문TOC이번 차시 목표와 사전 준비서비스레벨: CSL vs Fill Rat..

TL;DRAI Sales Forecasting에서 딥러닝은 "피처 기반 ML(GBDT)"로 한계가 보일 때, 멀티호라이즌·복잡한 공변량·불확실성(분포 예측)을 더 일관되게 처리하려고 쓰는 카드입니다.최근엔 TimesFM·Chronos·TimeGPT처럼 사전학습(Pretrained) 기반 파운데이션 모델이 등장해, 데이터가 부족한 도메인에서도 제로샷/소량 적응을 시도할 수 있습니다.실무 설계의 핵심은 "모델 고르기"가 아니라 (1) 공변량을 예측 시점에 공급 가능한지, (2) 롤링 오리진 백테스트, (3) 예측구간 불확실성(PI/Quantile) 캘리브레이션, (4) 비용·지연·서빙 형태를 같이 묶는 것입니다.팩트시트 (초안 전 필수)핵심 정의(1문장): 딥러닝 판매 예측은 다수 시계열을 "글로벌 모델"로..

TL;DRAI Sales Forecasting에서 피처 기반 머신러닝(GBDT)은 “시계열을 회귀 문제로 변환”해 대량 SKU/매장 예측을 안정적으로 확장합니다.핵심은 (1) 라그/롤링/캘린더/외생변수 설계, (2) 누수 방지(point-in-time), (3) 롤링 오리진 백테스트, (4) WAPE 중심 평가, (5) 분위수(quantile)로 불확실성까지 한 번에 엮는 것입니다.이번 편에서는 “실무 파이프라인”을 그대로 따라 만들 수 있게 데이터 스키마, 피처 분류, 학습/검증, 운영 체크리스트를 제공합니다.본문TOC피처 기반 ML 판매 예측의 정의와 범위데이터 스키마: (store, item) 패널을 “롱 포맷”으로 고정피처 설계: 라그/롤링/캘린더/외생변수(Static/Dynamic/Calenda..

TL;DRAI Sales Forecasting에서 백테스트는 "점수 뽑기"가 아니라 운영과 같은 조건으로 성능을 검증하는 절차입니다. FPP3는 진짜 예측 오차는 학습 잔차가 아니라 새 데이터에서의 genuine forecasts로 봐야 한다고 정리합니다.기본은 rolling forecasting origin(rolling-origin) + expanding/rolling window + 재학습(refit) 여부 명시입니다.리테일/판매 예측에서는 MAPE만 고집하지 말고 WAPE(볼륨 가중), MASE(스케일드) 같은 지표를 함께 써야 합니다.베이스라인은 최소 Seasonal Naive + ETS(지수평활 계열) 2개를 두고, 모든 모델은 여기에 "상대 개선"으로 보고하세요.분위수(확률) 예측을 한다면 ..

TL;DRAI Sales Forecasting 프로젝트는 모델보다 데이터 설계(스키마/시간 의미/누수 방지/품질 규칙)에서 승부가 납니다.판매 예측 데이터는 최소한 sales(타깃) + calendar(캘린더/이벤트) + price + promo + inventory/stockout 축으로 나눠 설계하는 게 안전합니다.시계열 피처 조인은 포인트-인-타임(과거 시점 기준) 정합성을 보장해야 누수(leakage)를 막을 수 있습니다.품절(stockout)은 관측 판매를 검열(censored)로 만들고 예측 편향을 유발할 수 있으니, 최소한 stockout_flag는 데이터 계약에 포함하세요.품질 관리는 "문서"가 아니라 검증 가능한 규칙(Expectation Suite)로 자동화하는 게 실무적으로 맞습니다...

TL;DRAI Sales Forecasting(판매 예측)은 “예측값”보다 예측을 어떻게 의사결정(재고·발주·인력)으로 연결하느냐가 성패를 가릅니다.설계는 문제 정의(단위·지평·리드타임) → 데이터 설계(타깃/캘린더/프로모션) → 베이스라인+백테스트 → 모델(통계/ML/DL) → 확률예측 → 배포·모니터링 순으로 가면 됩니다.평가에는 훈련/테스트 분리와 시계열 교차검증(rolling origin)이 필수입니다.확률예측(분위수/구간)을 도입하면 품절/과잉재고 비용처럼 비대칭 비용을 모델링하기 쉬워집니다.관리형 서비스(예: Vertex AI Forecasting, Azure AutoML Forecasting)는 빠르지만 제약이 있으니(예: 방식/추론 제약) 설계 초기에 결정해야 합니다.본문TOC연재(강의) ..