AI 도구 활용법 – 미스트랄 타임스트랄(Timestral)로 판매량 예측해 발주 기준 잡기
쇼핑몰을 운영하면서 다음 달 발주량을 지난달 평균이나 감으로 정해 왔다면, 이번 글이 쓸모 있을 거예요. 미스트랄(Mistral)이 2026년 10월 15일 공개한 타임스트랄(Timestral)은 판매량 예측 같은 시계열 예측(Time-series Forecasting)용 모델이고, 숫자 하나 대신 하위 10%부터 상위 90%까지 판매 범위를 내놓습니다.
직접 만든 가상 쇼핑몰 주문 CSV로 다음 4주를 돌려 봤고, 그 범위를 발주 기준으로 바꾸는 AI 자동화 순서까지 정리했어요. 화면과 숫자는 모두 가상 예시 데이터이고, 실제 쇼핑몰 주문은 쓰지 않았습니다.
미스트랄이 10월 15일 공개한 타임스트랄
미스트랄 블로그의 “Introducing Timestral” 글에 따르면 타임스트랄은 미스트랄의 첫 시계열 기초 모델(Time-series Foundation Model) 묶음이에요. 크기는 5M, 28M, 123M, 209M 네 가지이고, 가장 큰 209M 모델이 GIFT-Eval, TIME, fev-bench 세 공개 벤치마크에서 1위를 했다고 미스트랄이 밝혔습니다.
판매량 예측에 바로 쓸 만한 건 확률 예측(Probabilistic Forecasting)이에요. 시점마다 21개 분위(Quantile)를 내서 불확실성이 얼마나 넓은지 볼 수 있게 했다고 설명합니다. 미리 아는 변수(Known-future Covariates)를 넣는 기능도 있는데, 공식 글은 생산 일정, 계획된 가동 중단, 날씨 예보를 예로 들었고, 다른 문단에서는 휴일 달력도 언급해요.
공식 글은 공급망을 쓰임새 중 하나로 꼽았지만, 자세히 든 예시는 공장 센서와 재무 쪽이에요. 쇼핑몰 판매량 예측은 공식 예시에 없어서, 이 글에서 같은 기능을 주별 판매 수량에 대 봤습니다. 속도는 미스트랄이 8스레드 서버 CPU에서 잰 값으로, 15분 단위 3주치 기록으로 하루 앞을 예측할 때 5M 모델이 10ms, 209M 모델이 140ms 걸렸다고 적었어요.
깃허브 코드와 허깅페이스 가중치, 라이선스부터 확인
실행 코드는 깃허브 mistralai/timestral 저장소에 있습니다. README는 PyTorch, NumPy, safetensors, huggingface_hub만 있으면 되고 CPU나 GPU에서 돈다고 적었어요. 설치는 한 줄이고 Python 3.10 이상, torch 2.4 이상이 필요합니다.
pip install git+https://github.com/mistralai/timestral.git # Python >= 3.10, torch >= 2.4모델 가중치는 허깅페이스 mistralai 계정에 크기별로 올라가 있어요. 처음 실행할 때 한 번 내려받고, README 표 기준으로 5M이 21MB, 209M이 837MB입니다. 모델 카드에는 한 번에 1,024 시점까지 예측하고 그보다 길면 구간을 나눠 이어 예측한다고 나와요.
가중치 라이선스는 코드와 다릅니다
코드는 Apache 2.0이지만 가중치는 수정 MIT 라이선스(Modified MIT)예요. 판매를 포함한 사용을 허용하면서, 2번 조항에 직전 달 회사(또는 고용주)의 전 세계 연결 매출이 일정 규모를 넘으면 이 라이선스상 권리를 쓸 수 없다는 조건을 두었습니다. 원문은 이 조건을 2번에 적어 놓고 다음 문장에서 “This restriction in (b) applies to the Model and any derivatives…”라고 (b)로 부르는데, 원문 표기 그대로 옮겼어요. 금액 기준과 저작자 표시 의무는 LICENSE 원문에서 직접 확인하세요.
판매량 예측이 끝난 뒤의 판단 흐름은 Anthropic의 small-business 플러그인에서 가져왔습니다. 2026년 9월 15일 Claude for Small Business 출시 때 새로 정리된 이 플러그인(1.35.1판)은 README 기준으로 스킬 44개를 담았고, 그중 inventory-planner와 restock이 재고·발주를 맡아요. 판매 기록과 재고 수량을 담은 CSV만 있어도 쓸 수 있고, 7일·28일 판매 속도로 품절 예상일과 발주량을 계산한 뒤 발주서와 거래처 메일 초안까지 만듭니다.
주문 내역 CSV를 주별 판매량으로 바꿔 넣기
가상 쇼핑몰에는 ‘A 텀블러 500ml’와 ‘B 보냉백’ 두 상품을 두고, 2024년 10월 21일부터 2026년 10월 18일까지 104주치 주문을 만들었어요. 주문 한 줄에 주문일, 주문번호, 상품명, 수량이 있는 흔한 형태입니다. 중간중간 기획전을 연 주가 12번 있고, 그 주에는 판매가 늘도록 만들었어요.
판매량 예측에 넣을 재료는 이 주문 내역 하나면 됐습니다. 판매 채널마다 내려받는 CSV의 열 이름은 다르겠지만, 주문일과 상품명, 수량 세 열이 있으면 같은 방식으로 주별 합계를 낼 수 있어요.
판매량 예측에 넣는 부분은 아래 10줄이에요. 주별 판매량을 (상품, 1, 주) 모양으로 세우고, 지난 기획전 주와 앞으로 잡아 둔 11월 2일 주를 1로 표시한 줄을 미리 아는 변수로 함께 넘깁니다. 같은 데이터로 기획전 정보를 넣지 않은 예측도 한 번 더 돌렸어요.
names = list(weekly.columns)
context = weekly.T.values[:, None, :].astype(float) # (상품, 1, 주)
known = np.tile(promo_flag[None, None, :], (len(names), 1, 1)) # (상품, 1, 주+4)
t0 = time.time()
fc = TimestralForecaster.from_pretrained(MODEL)
t1 = time.time()
plain = fc.forecast(context, prediction_length=H)
t2 = time.time()
withp = fc.forecast(context, prediction_length=H, known_covariates=known)코드만 봐서는 모르는 것
- README는 미리 아는 변수의 길이를 과거 길이에 예측 기간을 더한 만큼(T + 예측 길이)으로 받으라고 적었어요. 그래서 기획전 표시 줄이 104주가 아니라 108주입니다.
- 값이 모두 0 또는 1인 줄은 표시용 변수(Indicator)로 처리된다고 README에 나와 있어요. 기획전 주 여부가 이 경우입니다.
- 비어 있는 값은 NaN으로 넣으면 결측으로 처리됩니다. 품절이라 못 판 주가 있다면 판매량 예측에는 0 대신 NaN으로 비워 두는 편이 맞아요. inventory-planner도 품절 기간의 0 판매를 수요 0으로 보지 말라고 적었습니다.
가상 쇼핑몰로 돌려 본 다음 4주 판매량 예측
2026년 10월 19일, Apple M1 Pro 컴퓨터의 CPU로 209M 모델을 돌렸습니다. 가상환경을 만들고 설치하는 데 1분 남짓 걸렸고, 모델을 받은 뒤 상품 2개의 4주 판매량 예측은 한 번에 1초 안쪽으로 끝났어요. 28M 모델로도 돌려 봤는데 기획전 주에 범위가 뛰는 모양은 같았습니다.
차이는 11월 2일 기획전 주에서 크게 났어요. 기획전 정보를 넣지 않으면 그 주 상위 90%가 145.6개로 다른 주와 비슷하게 나왔습니다. 11월 2일이 기획전 주라고 알려 주자 같은 주의 범위가 168.1~231.1개로 올라갔어요.
지난 4주 평균으로 정할 때
- 최근 4주 A 상품 판매가 92, 91, 106, 100개라 평균은 97개 남짓
- 매주 비슷한 수량을 준비하게 된다
- 기획전 주에도 같은 수량이라 모자랄 수 있다
판매 범위로 정할 때
- 주마다 하위 10%·중앙값·상위 90%가 따로 나온다
- 기획전 주는 상위 90%가 231.1개로 따로 잡힌다
- 범위가 넓은 주는 불확실성이 큰 주라는 신호로 본다
B 보냉백도 흐름이 같았어요. 기획전 정보 없이 돌린 판매량 예측에서 11월 2일 주 범위는 18.1~41.9개였고, 기획전 주라고 알려 주자 39.2~90.5개로 올라갔습니다. 기획전 정보를 넣은 예측에서는 두 상품 모두 그 주의 범위 폭이 다른 주보다 넓게 나왔는데, 판매량 예측에서 범위가 넓다는 건 그만큼 결과가 흔들릴 수 있는 주라는 뜻으로 읽으면 됩니다.
보고서에 그래프 숫자가 필요할 때, 그래프 사진을 표로 바꿔 주는 AI판매량 예측의 상위 90% 값을 준비 수량 기준으로
이 글에서는 판매량 예측의 상위 90% 값을 올림한 수를 그 주에 갖춰 둘 수량의 기준으로 정했어요. 0.9 분위는 모델이 판매량이 이 값 아래일 거라고 본 확률이 90%인 지점입니다. 품절이 더 아픈 상품은 0.95 분위로, 재고 부담이 큰 상품은 중앙값 쪽으로 옮겨 잡을 수 있어요.
| 주 시작일 | 예측 범위(하위 10%~상위 90%) | 준비 수량 기준 |
|---|---|---|
| 10월 19일 | 86.3~111.3개 | 112개 |
| 10월 26일 | 82.5~115.0개 | 115개 |
| 11월 2일 (기획전) | 168.1~231.1개 | 232개 |
| 11월 9일 | 81.3~118.5개 | 119개 |
준비 수량 기준이 곧 발주량은 아니에요. 현재 재고와 이미 들어오기로 한 물량을 빼야 하고, 거래처의 최소 주문 단위도 맞춰야 합니다. 여기서부터는 inventory-planner가 정해 둔 규칙을 추려서 체크리스트로 썼어요.
- 입고 예정분을 빼지 않은 발주량은 쓰지 않는다
- 28일 동안 한 개도 안 팔린 상품은 발주 후보에서 빼고, 묶인 재고로 따로 본다
- 판매 기록이 1년이 안 되면 계절 보정을 하지 않고 운영자에게 묻는다
- 발주서와 거래처 메일은 초안까지만 만들고, 보내기 전에 승인을 받는다
inventory-planner 자체는 7일·28일 판매 속도로 계산하고, 기본값은 28일 판매 속도 기준 60일치에 리드타임을 더한 양이에요. 타임스트랄과 이어 주는 기능은 없고, 판매량 예측 범위를 넣고 이 규칙으로 거르는 조합은 이 글에서 묶은 방식입니다.
판매량 예측은 범위까지, 발주 확정은 사람이
이번 AI 자동화에서는 모델이 판매 범위까지만 내고, 발주 확정은 사람이 누르게 나눴어요. restock 스킬도 같은 구조라서, 구매 목록 승인과 발주서 발송 승인을 따로 받게 돼 있습니다. 원문 표현은 “Two gates, two decisions”입니다.
판매량 예측은 모델이, 발주 버튼은 사람이.
범위가 좁고 기획전 같은 변수도 없는 주는 승인이 금방 끝나요. 범위가 넓거나 처음 여는 행사가 낀 주는 사람이 한 번 더 보는 자리입니다. 일을 이렇게 나누는 법은 AI 업무 설계, 일 맡기기 전에 이렇게 쪼개 보세요와 AI에 일 맡길 때, 사람만 누르는 버튼부터 정해 두세요에 더 적어 두었어요.
처음 붙일 때는 상품 전체보다 잘 팔리는 상품 몇 개로 판매량 예측을 먼저 돌려 보는 편이 좋아요. 몇 주 동안 실제 판매량과 예측 범위를 나란히 적어 두고, 범위 밖으로 벗어난 주가 잦으면 기준 분위를 바꾸거나 사람이 다시 보는 주를 늘리면 됩니다.
참고한 공식 문서
- 미스트랄 블로그, Introducing Timestral (2026-10-15)
- 깃허브 mistralai/timestral README·LICENSE
- 허깅페이스 mistralai/Timestral-209M 모델 카드·LICENSE
- Anthropic small-business 플러그인 inventory-planner·restock 스킬
라이선스와 사양은 바뀔 수 있으니 쓰기 전에 원문을 확인하세요. 이 글의 주문·판매 수치는 모두 직접 만든 가상 예시 데이터입니다.
업종과 업무에 맞춘 AX 설계 상담은 무료 AX 상담 신청에서 받습니다.
판매량 예측 자주 묻는 질문
타임스트랄(Timestral)은 무료로 쓸 수 있나요?
코드는 Apache 2.0, 모델 가중치는 수정 MIT 라이선스(Modified MIT)로 공개돼 있고 판매를 포함한 사용을 허용합니다. 다만 라이선스 2번 조항에 직전 달 매출이 일정 규모를 넘는 회사는 권리가 없다는 조건이 있어요. 금액과 문구는 허깅페이스의 LICENSE 원문에서 확인하세요.
GPU가 없는 노트북에서도 판매량 예측을 돌릴 수 있나요?
공식 README는 추론에 GPU가 필요 없다고 적고 있습니다. 2026년 10월 19일 Apple M1 Pro 컴퓨터의 CPU로 209M 모델을 돌렸을 때 상품 2개의 다음 4주 예측이 모델을 불러온 뒤 한 번에 1초 안쪽으로 끝났어요. 가상 예시 데이터 104주 기준입니다.
예측 결과를 그대로 발주량으로 써도 되나요?
이 글에서는 상위 90% 값을 그 주 준비 수량의 기준으로만 썼고, 현재 재고와 입고 예정분을 뺀 뒤 사람이 승인하는 순서로 정했습니다. Anthropic의 inventory-planner 스킬도 입고 예정분을 빼지 않고 발주량을 잡지 말 것, 승인 없이 발주서를 보내지 말 것을 규칙으로 두고 있어요.
글에 나온 규칙 파일과 에이전트는 Claude Code에서 쓰는 방식이고, 공식 안내는 Claude Code 공식 문서에 있습니다.
이 글은 직접 만들고 운영하며 남긴 기록입니다. 적힌 수치는 작성 시점의 운영 계정 기준이며, 같은 결과나 수익을 보장하지 않습니다.
