농심의 Amazon SageMaker를 활용한 원자재 가격예측과 MLOps 여정

농심은 1965년 창립 이후 50여 년 동안 한국의 식문화를 이끌어온 식품 전문 제조기업입니다. 농심은 글로벌 식문화 창조기업으로의 도약을 위해 비전 2025를 수립하고 이에 맞는 중장기 목표와 사업별 성장전략, 역량 확보전략을 새롭게 정립하고 있습니다.

농심은 식품 제조에 필요한 원자재를 ‘비축구매 방식’으로 구매하고 있습니다. 비축구매는 미래 원자재 가격의 오름/내림을 예측하여 n개월 뒤에 받을 원자재를 현재 시점에서 선 발주하는 방식입니다. 이에 따라 비축구매 방식을 적용할 때는, 원자재의 정확한 가격을 예측하는 것보다 추세를 잘 예측하는 것이 더 중요합니다.

지금까지 농심은 미래핵심기술 축적의 일환으로 세계적으로 공신력 있는 A 회사의 원자재 가격 데이터를 구입하는데, 구매 담당자는 여러 원자재 데이터를 품목별/일자별로 일일이 클릭해 내려받습니다. 이후 담당자는 개인의 노하우를 활용하여 앞으로의 구매전략을 세웁니다.

서비스 개발 목표

이번 서비스 개발의 목표는 실무 담당자가 데이터를 내려받는 과정에 들어가는 불필요한 인력, 시간 자원을 최소화하고 데이터 기반의 의사결정 및 체계적 구매전략 수립을 위해 AWS SageMaker를 활용한 MLOps 아키텍처를 구성했습니다. 이를 통해 농심 내부 효율적인 프로세스를 확립하고 머신러닝(AI/ML)을 활용한 시계열 예측 기술을 적용하여 일관성 있는 구매전략을 기대합니다.

업무의 효율성 및 빠른 의사 결정 속도를 위해 기존 비즈니스 담당자가 수작업으로 이루어지던 데이터 수집부터 AI/ML 모델을 학습하고 배포하는 단계까지 자동화하는 MLOps 아키텍처 구축의 필요성, SageMaker를 통해서 향후 농심의 타 AI 서비스에도 적용할 수 있는 AI 서비스 아키텍처 템플릿을 구축하는 필요성 역시 대두되었습니다. 따라서 데이터, AI 모델, 아키텍처 3가지 측면에서 요구사항을 세분화하였습니다.

1. 데이터: 구매담당자가 원자재 가격을 예측하는 데에 사용해온 데이터 수집

내부 데이터: 농심 SAP ERP 팜유 구매 실적 데이터
외부 데이터: 원산지의 기후 데이터 (ex 일조량, 강수량 등), 연관 원자재(ex 소맥, 대두유 등), 세계 경기 지수(ex 상해 지수, 나스닥 지수 등)

2. AI 모델: AutoGluon

AWS lab에서 개발한 AutoML 라이브러리인 AutoGluon을 포함한 다양한 모델 사용

3. 아키텍처: Amazon SageMaker

데이터 수집부터 AI 모델 배포까지 AI 라이프사이클을 자동화하고 AI 모델을 관리하기 위한 MLOps 아키텍처 구축
AI 모델 배포 전, 비즈니스 담당자가 다양한 모델을 테스트한 결과를 확인한 후 선택할 수 있는 파이프라인

원자재 가격 예측 자동화 시스템의 세부 사항

농심에서는 On-premise를 AWS로 마이그레이션하는 차세대 프로젝트를 1년 이상 진행하고 있습니다. 이에 따라 AWS 환경이 사내 개발자 및 데이터 사이언티스트에게 친숙합니다. 그러나, 그들이 진행하는 AI/ML 프로젝트의 경우 다양한 인프라에 각기 다른 아키텍처로 구축되어 있습니다.

Amazon Sagemaker는 AWS 리소스와 연계가 쉽고 데이터 분석부터 기계 학습(ML) 모델을 빠르게 훈련, 배포하고 모니터링까지 가능한 완전 관리형 서비스입니다.

단일화된 플랫폼을 구축함으로써 얻을 수 있는 효과는, 데이터 사이언티스트에게는 친숙한 Jupyter notebook 환경인 Studio notebook과 데이터 변환 서비스인 Data Wrangler를 제공하여 데이터 정제, 분석을 손쉽게 할 수 있습니다. 또한, AI/ML 엔지니어에게는 Sagemaker Training을 활용하여 여러 AI 모델을 훈련시키고, Sagemaker experiments, Model Registry로 고도화를 위해 수행되는 여러 개의 머신러닝 모델들을 실험 및 성능 모니터링하여 최적의 모델을 선택할 수 있습니다. AI 모델 제작 이후에도 모델 서빙 및 모니터링에 필요한 사후 관리 서비스를 제공한다는 점과 AWS 리소스를 활용한 아키텍처 관리가 용이하다는 강력한 장점에 Amazon Sagemaker 가 사용되었습니다.

아키텍처 구성 항목들:

데이터 수집: 농심 SAP에서 원자재 구매 실적 데이터와 예측 변수로 사용될 외부 데이터를 수집하여 DataLake 역할을 하는 S3에 적재되는 로직이 구현되는 곳입니다.
데이터 추출: 적재된 DataLake에서 Use-Case에 맞는 Stage data를 추출하여 적재하는 로직이 구현되는 곳입니다.
데이터 정제: 추출된 Stage data를 불러와서 머신러닝(AI/ML) 입력값에 맞게 정제된 golden data로 변환하여 적재하는 로직이 구현되는 곳입니다.
모델링: 정제된 golden data를 불러와서 머신러닝(AI/ML) 학습 이후 모델 파일과 모델 결과를 적재하는 로직이 구현되는 곳입니다.
모델 검증: 모델 배포가 진행되기 전에 1차적으로 모델 검증을 거치는 단계입니다. 가령, 사용자가 설정한 모델 성능 최소 요구조건을 넘겼을 때에만 AI 모델 저장소인 Model Registry에 저장됩니다.
모델 배포: 최종 검증을 진행하여 AI 모델이 배포되는 로직이 구현되는 곳입니다. 검증을 통과한 모델의 예측 결과는 시각화 되어 구매 담당자가 직접 확인하고 비즈니스 목표가 달성됐을 때 Approve 버튼을 누르면 서비스가 배포됩니다.

데이터 수집

A. 내부 데이터

수집 근거

농심의 SAP ERP 시스템에는 지난 10년간의 원자재 구매 실적 데이터가 적재되어있습니다. 이를 수집한다면, AI 예측 시스템 효용성 평가를 위한 백테스팅시 기존 팜유 구매 방식과 대조하여 AI 알고리즘이 어느 정도의 성능을 낼 수 있는지 정량적인 지표로 확인할 수 있습니다.

수집 방법

농심 SAP 시스템을 포함한 대부분의 시스템은 Direct Connect로 AWS 클라우드와 직접 연결된 환경을 가지고 있습니다. 또한 SAP로부터 S3로 데이터를 추출하기 위해 외부 서비스와 AWS와의 Connector를 지원하는 Amazon AppFlow를 사용하였습니다. AppFlow를 통해 SAP 데이터를 가지고 오기 위해서는 몇 가지 설정이 필요합니다. 먼저 SAP에는 Gateway 사용설정을 하고 OData 2.0, 4.0을 활성화해줘야 하며, 사용자가 원하는 데이터를 SAP OData API로 설정해줘야 합니다. 이후 Amazon AppFlow에는 SAP와의 연결을 위한 몇 가지 정보를 입력해준 뒤 도착지를 S3로 설정하게 되면, SAP의 데이터를 AWS S3 저장소로 가지고 올 수 있습니다. 이를 통해 SAP에 존재하는 원자재 구매 실적 데이터를 쉽게 가져올 수 있었습니다.

B. 외부 데이터 – 기후 데이터

농심에서는 따로 원자재 가격 예측을 위한 데이터를 스토리지나, 데이터베이스에 정기적으로 수집 및 적재하지 않고 있습니다. 그러므로, 원자재 가격 AI 예측 모델을 개발하기 위해 A사 원자재 데이터를 포함한 외부 데이터 수집이 필요하였습니다.

수집 근거

Abubakar, Ahmed & Ishak, Mohd & Uddin, Mohd & Abd Samad, Mohd & Sulaiman, Mukhtar & Danhassan, Samir. (2021). Effects of Some Weather Parameters on Oil Palm Production in the Peninsular Malaysia.

2022년 10월 한국 무역협회에서 발표한 팜유 산업 현황 보고서에 의하면, 전 세계에서 42개국이 팜유를 생산하고 있으나, 인도네시아와 말레이시아가 전 세계 팜유 생산의 85% 담당하고 있습니다. 이 중 농심은 말레이시아의 팜유를 사용하고 있습니다. 이에 따라서 말레이시아 국가의 작황 및 기후 데이터는 매우 중요합니다. 한 논문에 따르면 최근 몇 년간 팜유의 원천인 Palm Tree의 경작지(Planted Area)가 늘었음에도 불구하고 생산량(Yield tonne)에는 큰 변화가 없었으며, 이에 대한 원인을 분석한 논문에서는 엘리뇨(El-Nino)로 인한 기후변화가 말레이시아의 기온 증가와 강수량 감소를 야기하였고 이에 따라 팜유 생산량 감소라는 결과를 낳았다는 결과를 볼 수 있었습니다. 이에 따라 말레이시아에서 팜유를 생산하는 주요 13개 도시의 기후 데이터를 수집하기로 하였습니다.

수집 방법

연구 결과를 근거로 WorldWeatherOnline API로부터 데이터를 수집하였습니다. 이 서비스는 유엔 특별 기구인 세계기상기구(WMO)와 미국 국립 환경 예측 센터(NCEP)로부터 데이터를 가지고 오며, KLM, Cocacola, Volvo를 고객으로 두고 있는 신뢰성 있는 서비스입니다.

WorldWeatherOnline API로 확보할 수 있는 말레이시아 기후 데이터는 2008년 7월부터 현재 날짜까지, 약 14년 치 데이터를 확보할 수 있으며, 지역별 최고/최저/평균 기온, 습도, 강수량, 일조 시간 등 다양한 데이터를 활용할 수 있었습니다.

위 파이프라인의 실행순서는 아래와 같습니다.

EventBridge: 사용자가 설정한 시간에 기후 데이터 수집용 Lambda 실행.
Lambda: WorldWeatherOnline API를 호출하여 데이터 수집하고 S3 적재

C. 외부 데이터 – 연관 원자재, 세계 경기 지수 데이터

수집 근거

농심의 구매 담당자는 원자재 미래가격 예측을 위해 연관 원자재와 세계 경제 데이터를 활용해오고 있었으며, 해당 데이터들은 세계적으로 공신력 있는 A사의 데이터를 구독하여 정보를 확보하고 있습니다. 기존의 데이터 수집 방법은 Proxy 프로그램 구동 후 품목을 지정하여 수동으로 데이터를 다운받고 확인하였습니다. 이는 여러 품목을 조회하여 다운로드할 수 없다는 점과 매번 검색 및 내보내기 버튼을 누른 후, 다른 프로그램으로 파일을 열어봐야 한다는 점에서 인력과 시간이 소모된다는 단점을 가지고 있었습니다.

이러한 단점을 극복하기 위해 하위와 같은 아키텍처를 구성하였습니다.

수집 방법

외부 데이터 수집 파이프라인의 실행순서는 아래와 같습니다.

1. EventBridge: 사용자가 설정한 시간에 Lambda A 실행.

2. Lambda A: 특정 EC2를 구동하는 로직 수행. (특정 EC2는 윈도우 인스턴스를 의미

3. EC2 Instance: 윈도우 자동 로그인 후 윈도우 배치 스크립트 실행.

Proxy 프로그램 실행 → Git을 통한 Python 수집 코드 업데이트 → 사용자가 설정한 품목들을 API 호출하여 수집하고, Data lake 역할을 하는 S3에 log와 함께 적재하는 python 코드 실행

4. EventBridge: 수집이 완료되면 Lambda B를 실행

연관 원자재 및 세계 경기 지수 항목 데이터 수집에 평균 15분 소요되므로, 20분 후 EC2를 중지(Stop)하는 로직을 수행하는 Lambda 실행

5. Lambda B: 특정 EC2를 끄는(Stop) 로직 수행

6. Tip

자동 로그인(Autologon): EC2 윈도우 인스턴스는 Lambda로 실행시킨다 하더라도 사용자가 원격 연결을 하지 않는 이상 로그인이 자동으로 되지 않습니다. 이 문제를 마이크로소프트 사이트 내 Mark Russinovich가 개발한 Autologon을 통해서 해결했습니다.
스케줄링: 윈도우 스케줄링을 설정하는 방법은 리눅스의 crontab과 달라 생각보다 복잡했지만 윈도우 Task Scheduler를 이용해서 batch파일을 실행하는 것으로 해결할 수 있었습니다.
코드 관리: Lambda나 Sagemaker 내 Python 코드는 직접 서비스에 접근하여 코드를 수정하거나 테스트가 가능합니다. 그러나, 윈도우 내에 있는 코드를 수정하려면 EC2를 구동하고 원격 접속을 한 다음 원격환경에서 코드를 수정하고 테스트하는 번거로움이 존재하여 관리하기는 쉽지 않습니다. 이 문제를 소스 코드 변경점을 관리해주는 분산형 버전 관리 시스템인 Git과 무료 Git 저장소인 GitHub을 활용하여 윈도우에 원격 접속 하지 않더라도 자동으로 동기화될 수 있게 개발하였습니다.

데이터 추출

AI 모델의 입력값으로 들어가기 전까지는 데이터를 크게 3개의 상태로 나눌 수 있습니다.

Raw data: 정제되어 있지 않은 Data Lake에 수집된 그대로의 상태
Stage data: Raw 데이터 중에서 Use-Case에 필요한 데이터만 추출하여 통합된 상태
Golden data: Stage 데이터에서 중복데이터, 결측치 처리, 업/다운 샘플링 등 데이터가 가공된 상태. 머신러닝 ML 입력값으로 들어가기 전 상태

데이터 추출 단계는 Data Lake의 데이터에서 데이터를 스테이징(Staging)하는 단계입니다.

위 파이프라인의 실행순서는 아래와 같습니다.

EventBridge: 데이터 레이크 역할을 하는 S3 내에 최신일자의 데이터가 업데이트되는 Event발생 시, EventBride로 Staging Lambda 실행
Staging Lambda: DataLake로 부터 Use-case와 연관된 데이터를 추출하여 Use-case 내 staged-data 폴더 적재

데이터 정제

목적에 맞춰 여러 데이터가 합쳐졌을 때, 데이터 정합성을 맞추는 절차는 꼭 필요합니다. 정합성 맞추기 위해 데이터 정제과정을 거치게 되는데 일반적으로 Python, R, Excel 및 다양한 ETL 툴들을 활용할 수 있습니다. 이 프로젝트에서는 Python으로 데이터 정제를 수행했으며, Python으로 개발된 데이터 정제 코드를 사용자가 사용하는 있는 환경이 아닌 외부 Docker Container에서 실행시키고 모니터링할 수 있는 SageMaker Processing을 사용했습니다. 이 특징은 MLOps 아키텍처를 구성하는 데 필수적이라고 볼 수 있습니다.

데이터를 정제한 순서는 아래와 같습니다.

1. 중복 데이터 확인: 중복데이터를 1개 date에 2개의 가격 데이터가 있을 경우라고 정의했으며, 확인 결과 0개였습니다.

2. 업샘플링 처리

전 세계의 시계열 데이터를 수집했을 때, 나라별로 공휴일이 다르고, 같은 나라여도 원자재 품목이 속한 거래소 운영시간이 다릅니다. 이는 불규칙한 시계열 데이터를 야기하였고, 데이터 통합시 일관성이 떨어지는 문제가 존재했습니다. 이를 해결하기 위해서 업샘플링(Upsampling)을 진행하였습니다. 업샘플링은 데이터 불균형이 발생했을 때 다른 데이터와의 일관성을 맞추기 위해서 데이터 수집되지 않은 날에도 수집된 것처럼 빈도를 늘리는 기법입니다. 이를 통해 각기 다른 품목의 시계열 데이터를 일관성 있게 만들 수 있었습니다.

3. 결측치(공백) 데이터 처리

결측치 처리로 총 3가지 방법을 사용했습니다.

3.1 결측 데이터 삭제

- 컬럼 삭제: 환율 데이터의 경우 거래량에 대한 데이터의 90%가 Null값이었습니다. 이는 결측치를 보정한다고 하더라도 데이터의 신뢰성을 보장할 수 없기에 제거하였습니다.
- 특정 Date 이후 데이터 삭제: 가령 팜유의 경우, 1990년부터 Date 칼럼에 데이터가 존재하였지만, 실제 가격 데이터는 1991년부터 존재하였습니다. 이에 따라 1991년 이전 데이터는 삭제하였습니다.

3.2 결측 데이터 보간 (interpolation): 인접한 데이터를 기반으로 누락된 데이터 추정하는 방법입니다.

선형보간법(linear interpolation)을 사용했습니다. 이 방식은, 누락된 데이터가 앞 뒤 데이터에 선형적인 일관성을 갖도록 제한하는 방식입니다. 단, 이방식은 시간에 따라 선형적인 패턴에 따라 동작한다는 사실이 전제가 되어야합니다. 가령 연도에 따른 온도 변화에 대한 추세에서는 쓸 수 있으나, 추세가 없는 강수량같은 경우에는 사용할 수 없습니다.

3.3 결측 데이터 대치: 결측 데이터 즉, 누락된 데이터를 채워 넣는 방법에는 크게 2가지 방법이 있는데 포워드 필(forward fill)은 누락된 값이 나타나기 직전의 값으로 채우는 것이고, 백필(backfill)은 누락된 값이 나타나기 직후의 값으로 채우는 것을 의미합니다. 현 프로젝트에서는 가장 최근 공백이 발생했을 때 미래의 값을 가져올 수 없기 때문에 포워드필(forward fill)로 처리하였습니다.

3.4 데이터 스케일링

<최대최소 스케일링(Min Max Scaler) 적용 수식>

모델학습 전, 데이터 분포가 다양하다면 데이터 일관성 있게 맞춰줘야 합니다.

가령, 원자재 A의 화폐 단위가 원(won)이고 데이터 분포가 1000원~3000원이고, 원자재 B의 화폐단위가 달러(Dollar)이고 데이터 분포가 1달러~6달러로 이뤄져 있다고 가정할 때, 화폐단위에 대한 차이를 모르는 AI 모델은 1000~3000원이 있는 컬럼 데이터가 1~6달러의 컬럼에 비해 가중치를 줄 수 있으며 이는 AI 모델 학습 결과에 영향을 줄 수 있습니다.

이를 해결하기 위해 모든 품목을 달러(Dollar)로 일치시키는 것을 검토하였습니다. 그러나, 새로운 품목 데이터가 수집될 때마다, 그리고 환율이 바뀔 때마다 매일 데이터 업데이트해 줘야 하는 공수가 들어가기에 비효율적이라는 문제점이 있습니다.

이에 따라서, 데이터 스케일링을 적용하였습니다. 스케일링하는 방법은 대표적으로 MinMax, Robust, Standard, Normalizer 4가지 기법이 있습니다. 그중에서 가장 직관적이고, 프로젝트를 실험하는 단계에서는 가장 적합하다고 알려진 최대최소 스케일링(MinMax Scaler)을 사용하였습니다.

최대최소 스케일링(MinMax Scaler)은 위 수식과 같이 각 데이터와 칼럼 내 최솟값 뺀 것을 칼럼 내 최댓값과 최솟값의 차이를 나누는 식으로 계산합니다. 이에 따라서 스케일링 후 모든 데이터 범위는 0~1이 됩니다. 이 방식은 이상치(Outlier)에 대한 정보를 줄이지 않고 데이터 분포도를 유지하며, 기존 데이터에 최소로 관여한다는 특징을 갖고 있습니다.

모델링

프로젝트에서 AI 모델 제작에는 Autogluon을 사용하였습니다. Autogluon은 AI 모델링 작업을 자동화하여 단 몇 줄의 코드만으로 이미지, 텍스트, 시계열 및 표 형식 데이터에 대한 머신 러닝, 딥러닝 모델을 제작할 뿐만 아니라 최적의 하이퍼파라미터 세트로 튜닝까지 해주는 AutoML라이브러리입니다. 이를 통해 사용자는 여러 개의 모델을 하나하나 개발할 필요 없이 AutoGluon 라이브러리를 사용함으로써 아래 코드와 같이 총 8개의 시계열 모델을 제작할 수 있습니다.

# 1) 모델링 필요변수 선언
df_train = pandas.read_csv('path/to/train/data')
target = 'PalmOil'
metric = 'MAPE'
model_dir = 'model'
quality = 'low_quality'
# 2) TimeSeriesDataFrame화
tdf_train = TimeSeriesDataFrame.from_data_frame(df_train, id_column="CODE", timestamp_column="ds")
# 3) Predictor(Estimator) 선언
predictor = TimeSeriesPredictor(path = model_dir,
				 target = target,
				 prediction_length = 30,
				 eval_metric = metric)
# 4) 선언한 Predictor에 train데이터를 학습
predictor.fit(train_data = tdf_train, presets = quality)

Amazon Sagemaker Studio를 이용한 모델 학습 과정은 아래와 같습니다.

SageMaker Training:

데이터 가공이 완료된 데이터(golden-data)를 S3로부터 가지고 와서 학습시키고 이에 대한 결과를 S3에 저장합니다. 코드에 대한 설명은 아래와 같습니다.

1. 모델링 필요 변수 선언

df_train: 데이터 정제가 끝난 golden 데이터를 불러와서 DataFrame 형태로 저장합니다.
target: 예측할 column을 설정합니다.
metric: 성능평가에 사용될 Metric을 설정합니다
model_dir: model 결과 데이터가 저장되는 경로입니다.
quality: Autogluon은 학습 수준 별 4가지의 모델 단계가 존재합니다 (fast_training, medium_quality, high_quality, best_quality 순으로 고성능)
- “fast_training”: 간단한 통계 모델(ETS, ARIMA, Theta, Naive, SeasonalNaive)에 적합합니다. 학습 속도가 빠르지만 데이터 내 더 복잡한 패턴을 파악할 수는 없습니다.
- “medium_quality”: “fast_training”이 사용하는 모델과 더불어 트리 기반 모델과 딥러닝 모델을 학습시킵니다.
- “high_quality”: “medium_quality”가 사용하는 모델과 더불어 2개의 딥러닝 모델(SimpeFeedForward, TemporalFusionTransformerMXNet)을 추가로 학습시킵니다. 더불어서 하이퍼파라미터 최적화를 활성화하기에 medium quality에 비해 더 정확하지만 학습하는데 시간도 더 걸립니다.
- “best_quality”: “high_quality”가 사용하는 모델과 더불어 1개의 고성능 딥러닝 모델(transformer-based TransformerMXNet)을 추가로 학습시킵니다. 이 설정은 high_quality와 마찬가지로 딥러닝 모델에 대한 하이퍼파라미터를 최적화하여 정확도는 더 좋을 순 있지만, high_quality보다 훈련하는데 더 오래 걸립니다.

2. TimeSeriesDataFrame 화

Autogluon Time-series 모델링을 사용하려면, CSV파일이나, pandas의 DataFrame형태는 학습이 안 되며, 학습을 위해선 pandas DataFrame을 Autogluon 전용 TimeSeriesDataFrame으로 변환시켜주는 작업이 필요합니다.

3. Predictor(Estimator) 선언

Autogluon Time-series 모델링에 필요한 Predictor(Estimator) 선언을 해줍니다. 어느 기간(prediction_length) 동안에, 어떤 항목(target)을, 무슨 평가항목(eval_metric)으로 예측을 하여, 이에 대한 결과를 어디에(model_dir) 저장할것인지 정의하는 구간입니다.

4. 선언한 Predictor에 train데이터를 학습

정의한 Predictor에 데이터와 어떤 학습 수준을 설정할 것인지 인자 값으로 선언합니다.

모델 검증

시계열 예측 모델 검증에는 무작위로 샘플링해서 Train set, Validation set, Test set을 나누는 일반적인 머신러닝 모델 검증 방식을 적용하기 어렵습니다. 왜냐하면 무작위로 샘플링을 하게 되면 시간에 따른 상관관계가 깨지며 ‘과거’ 시계열 데이터의 기반으로 ‘미래’를 예측하는 개념에서 벗어나게 되기 때문입니다. 이에 따라서 시계열 모델 검증 방법은 위처럼 2가지로 나뉩니다. TimeSeriesSplit을 사용한 Cross Validation그리고, Blocking Time Series Cross Validation이 있습니다.

현 프로젝트에서는 Blocking Time Series Cross Validation에서 설정할 Training set의 길이가 명확하지 않아 TimeSeriesSplit을 사용했습니다. 이에 따라 비록 다음 1달을 예측하는 것이 여도 해당 모델은 근 5개월간의 검증 구간을 걸쳐서 나온 모델이기 때문에 모델의 신뢰성을 좀 더 높일 수 있었습니다.

위 요구사항을 아키텍처에 적용하기 위해 아래와 같은 파이프라인을 구성하였습니다.

1. SageMaker Processing

1) 모델링 결과 데이터가 저장된 S3로 부터 성능 결과 데이터만 추출

2) 성능이 사용자가 정의한 최소 요구조건을 넘는지 안 넘는지에 따라 Model Registry에 학습된 모델 등록을 결정

2. SageMaker Model Registry: 만약 성능 최소 요구조건을 넘는다면, 모델 등록을 시키고, 그렇지 않다면, 종료합니다.

위 모델 검증 파이프라인에 따라 TimeSeriesSplit을 사용한다면 아래처럼 5개로 나뉜 검증 구간(=fold)으로 나눌 수 있습니다.

모델 배포

위 파이프라인의 실행순서는 아래와 같습니다.

Amazon Quicksight: 모델 검증을 1차적으로 필터링된 결과를 Amazon Quicksight으로 아래와 같은 예시 보여줌으로써 모델에 대한 결과값을 표현할 수 있습니다.

EventBridge: 만약 비즈니스 담당자가 해당 모델을 보고 적절하다 판단되어 Approve를 눌렀다면, Model Registry에 저장된 모델의 Status가 바뀌게 될 것입니다. 이를 Trigger 삼아서 EventBridge가 SageMaker Processing을 동작시킵니다.
SageMaker Processing: Model Registry에서 가장 최신버전이고 Approve 상태인 모델을 찾아서 model Prediction을 수행합니다.
파이프라인 생성

마지막으로 데이터 수집부터 모델 배포까지의 개별 로직이 구현이 완료되면, 원자재 시황 AI 예측 서비스를 자동화하기 위해서는 ML 워크플로우가 필요합니다. ML 워크플로우는 크게 4단계를 거쳐 구성됩니다.

수집된 데이터 전처리
전처리 된 데이터를 토대로 데이터 정제
정제된 데이터를 활용하여 모델 학습
학습된 모델을 토대로 비즈니스 기준에 맞는 검증

MLOps를 구성하기 위해 워크플로우 스케줄링 서비스이자 모니터링 플랫폼인 Apache Airflow와 Sagemaker Pipeline을 고려하였습니다. 두 개 모두 구성이 간단하고 웹 UI 형태가 직관적인 것이 장점입니다. 현 프로젝트에서는 AWS 리소스를 활용해서 데이터 수집부터 모델 검증까지 하므로 상대적으로 연동성이 더 높은 Sagemaker Pipeline을 사용하였습니다.

전처리 코드

split_date = '2022-10-31'
# 1) 데이터 전처리
step_preprocessing = ProcessingStep(
    name = f"{project_prefix}-processing",
    processor = skprocessor_preprocessing,
    inputs = [
        ProcessingInput(source = stage_data_dir,
                        destination = '/opt/ml/processing/input'),
    ],
    outputs = [
        ProcessingOutput(output_name = "stage",
                         source = '/opt/ml/processing/output/stage',
                         destination = preproc_data_dir),
        ProcessingOutput(output_name = "train",
                         source = '/opt/ml/processing/output/train',
                         destination = preproc_data_dir),
        ProcessingOutput(output_name = "test",
                         source = '/opt/ml/processing/output/test',
                         destination = preproc_data_dir),
    ],
    job_arguments=["--split_date", split_date],    
    code = preprocessing_code
)

모델 학습 코드

# 2) 모델 학습
step_train = TrainingStep(
    name = f"{project_prefix}-train-autogluon060",
    estimator = mxnet_estimator,
    inputs = {
        "train" : TrainingInput(
            s3_data = step_preprocessing.properties.ProcessingOutputConfig.Outputs[
                "train"
            ].S3Output.S3Uri,
            content_type = "text/csv"
        ),
        "test" : TrainingInput(
            s3_data = step_preprocessing.properties.ProcessingOutputConfig.Outputs[
                "test"
            ].S3Output.S3Uri,
            content_type = "text/csv"
        ),
    },
)

모델 검증 코드

# 3) 모델 검증 ###
step_model_validaion = ProcessingStep(
    name = f"{project_prefix}-model_validation",
    processor = skprocessor_model_validation,
    job_arguments=["--s3_model_uri", step_train.properties.ModelArtifacts.S3ModelArtifacts],    
    code = model_validation_code
)

모델 예측 코드

# 4) 모델 예측 ##
step_prediction = ProcessingStep(
    name = f"{project_prefix}-prediction",
    processor = script_processor_prediction,
    inputs=[
        ProcessingInput(source = step_preprocessing.properties.ProcessingOutputConfig.Outputs["train"].S3Output.S3Uri,
                        destination = "/opt/ml/processing/input/train"),
        ProcessingInput(source = step_preprocessing.properties.ProcessingOutputConfig.Outputs["test"].S3Output.S3Uri,
                        destination = "/opt/ml/processing/input/test"),
    ],
    outputs=[
        ProcessingOutput(output_name = "prediction_data",
                         source = "/opt/ml/processing/output",
                         destination = prediction_output_path)
        ],
    code = model_prediction_code
)

원자재 가격 자동화 시스템 구축 결과 및 향후 기대

모델링 및 검증 결과

모델링 및 검증 결과: MAPE 10.14%, 표준편차 3%

원자재 시황 예측 프로젝트에 대한 모델은 총 5개월을 토대로 Timeseries Cross Validation을 수행하였으며, MAPE 평균 10.14%, 표준편차 3%의 성능을 가질 수 있었습니다.
과거 1982년 Colin David가 발표한 Industrial and business forecasting method 논문을 볼 때, MAPE 10%는 산업용 예측에 있어 준수한 결과라는 의견이 있습니다. 이에 따라, 원자재 가격 예측 자동화 서비스도 유용하게 쓰일 수 있다고 기대합니다.

향후 기대 효과

1. 의사결정 보조 수단

농심 기존 구매 담당자는 직관과 주관에 의존한 팜유 가격 추세예측을 해왔습니다. 본인이 과거에 수행한 구매 이력을 떠올리며 ‘매년 여름이 되면 팜유 가격이 NN 달러가 되었던 것 같으니, 올해 구매 전략을 세우는데 참고하자’라고 판단하는 식입니다. 이는 일관성 없는 예측을 야기했고, 담당자도 본인의 의사결정에 확신을 가지기 힘들었습니다.

하지만 이번 원자재 시황 예측 프로젝트는 AutoML 라이브러리를 활용하여 8개의 모델에 대한 결과를 산출하고 비즈니스 담당자가 AWS Quickshight를 통해 모델 결과를 확인하여 어떤 모델을 선택할지 선택하는 검증 절차를 거쳤습니다. 덕분에 데이터를 통한 의사결정에 친숙하지 않은 실무 담당자도 활용할 수 있는 ‘신뢰도 높은 보조수단’을 확보했습니다.

2. 휴먼 에러 감소

기존에는 사람이 직접 데이터를 수집하고 분석하는 작업을 거쳤습니다. 농심 실무 담당자는 글로벌 원자재 정보제공 A 회사의 원자재 가격 데이터를 구입한 뒤, 원자재 데이터를 품목별/일자별로 일일이 클릭해 내려받았습니다. 이 과정에서 담당자는 다른 품목, 혹은 잘못된 기간의 데이터를 선택하여 내려받아 원자재 값을 잘못 인식하는 등 ‘휴먼 에러(human error)’의 여지가 상당했습니다. 하지만 MLOps 아키텍처가 적용된 원자재 시황 예측 프로젝트를 이용한다면, 매일 데이터 수집이 자동으로 수행되어 적재되기 때문에 휴먼에러가 줄어드는 것을 기대할 수 있습니다.

마무리

구매는 종합 예술이라는 말이 있습니다. 특정 원자재를 구매할 때 수량과 시점, 품질을 종합적으로 판단한 뒤, 원하는 시간과 장소에 도달하도록 물류 흐름을 관리해야 하기 때문입니다. 기업이 클수록 구매는 단위가 워낙 커서 조금만 절감해도 월등한 원가절감의 효과를 거둘 수도 있습니다.

구매 절차가 복잡하고 난해하기 때문에, 실무 담당자가 최신 데이터와 AI를 완벽하게 활용하지 못하는 것은 당연할지도 모릅니다. 이번 개발은 이러한 구매 실무자의 원자재 구매 의사결정에 도움이 될 수 있는 서비스를 개발했습니다.

AI 가 구매 의사결정을 전면 대체하기는 어렵습니다. 아직 AI 솔루션이 도출하는 결과값을 내부 의사결정에서 전적으로 신뢰할 만한 ‘공감대’가 부족하기 때문입니다. 그래서 저희는 원자재 구매 프로세스상에 직접 참여하여 원자재 시황 예측 AI 자동화 솔루션이 어떤 역할을 하고 어떻게 활용할 수 있는지 앞으로 더 많은 의사소통을 통해 협업의 기회를 만들어갈 것입니다. 그래야 AI 솔루션이 실제로 잘 작동하며 도출 결과를 신뢰할 수 있기 때문입니다. 비즈니스 프로세스로서의 개선뿐만 아니라 기술적으로도 많은 부분에서 변화와 개선점이 만들고 싶습니다.

우선은 MLOps아키텍처 운영하면서, 입력 데이터에 data drift 혹은 concept drift가 존재하는지, 그리고 모델에 model drift가 존재하는지 확인하면서 안정성 있는 서비스로 만들어 나가는 과정을 기획할 예정입니다. 이에 따라 프로젝트를 진행하면서, 주/달/분기 별 주기를 지정하여 데이터와 모델 모니터링을 진행할 것입니다

현재는 특정 원자재만을 대상으로 예측을 진행하였고, Cross Validation 상 5개월 평균 오차율(MAPE) 10%라는 유의미한 결과를 확인할 수 있었습니다. 향후 추가 결과를 분석하며 다른 원자재도 예측하여 원자재 시황 예측 AI 솔루션 활용도를 높여 나갈 예정입니다.

이 프로젝트는 AWS 에서 고객사를 대상으로 지원하는 Enterprise Boost Program 의 Mini-project 에서 시작되었습니다. 이 프로젝트에 관련된 농심과 AWS 의 많은 분들께 감사의 말씀을 드립니다.

AWS 기술 블로그

농심의 Amazon SageMaker를 활용한 원자재 가격예측과 MLOps 여정

서비스 개발 목표

원자재 가격 예측 자동화 시스템의 세부 사항

데이터 수집

A. 내부 데이터

수집 근거

수집 방법

B. 외부 데이터 – 기후 데이터

수집 근거

수집 방법

C. 외부 데이터 – 연관 원자재, 세계 경기 지수 데이터

수집 근거

수집 방법

데이터 추출

데이터 정제

모델링

SageMaker Training:

모델 검증

모델 배포

원자재 가격 자동화 시스템 구축 결과 및 향후 기대

모델링 및 검증 결과

향후 기대 효과

마무리

주요 링크 모음

팔로우하기