ML 시스템 설계 패턴 (ML System Design Patterns)

핵심 요약: 프로덕션 ML 시스템의 설계 패턴. 모니터링과 피드백 루프가 핵심이다. ML 코드는 전체 시스템의 5% 미만이고, 나머지 95%는 데이터 관리, 서빙, 모니터링 인프라이다.

초보자를 위한 핵심 용어

• Feature Store: ML 특성의 중앙 저장소. 여러 모델이 동일한 특성을 재사용할 수 있고, 학습/서빙 간 일관성을 보장한다.
• Data Drift(데이터 드리프트): 시간이 지나면서 입력 데이터의 분포가 변하는 현상. 코로나 이후 구매 패턴 변화가 대표적 예시.
• 피드백 루프(Feedback Loop): 모델의 예측이 미래 학습 데이터에 영향을 미치는 순환 구조. 추천 시스템에서 자주 발생한다.
• A/B Testing: 기존 모델(A)과 새 모델(B)을 동시에 서빙하여 실제 사용자 반응으로 성능을 비교하는 방법.

개요

ML 시스템 설계는 단순한 모델 학습을 넘어, 예측 서빙, A/B 테스팅, 특성 관리, 모니터링, 피드백 루프 등 프로덕션 환경의 전체적인 아키텍처를 설계하는 것이다. Google의 유명한 논문 “Hidden Technical Debt in Machine Learning Systems”에서 강조했듯이, ML 코드는 전체 시스템의 극히 일부이며, 나머지는 데이터 관리, 서빙, 모니터링 인프라이다.

비유: “ML 시스템은 살아있는 유기체”와 같다. 건강검진(모니터링), 영양공급(데이터), 운동(재훈련)이 필요하다. 유기체가 한 번 건강하다고 해서 영원히 건강한 것이 아니듯, ML 시스템도 배포 후 지속적인 관리 없이는 성능이 저하된다. 데이터 드리프트는 노화, 피드백 루프는 자가면역 질환, 모니터링 부재는 건강검진을 받지 않는 것에 비유할 수 있다.

---

탄생 배경

ML 시스템 설계 패턴이 체계화된 것은, 대규모 ML 시스템을 운영한 기업들의 뼈저린 경험이 축적된 결과이다.

Google - “Hidden Technical Debt” 논문 (2015):

Google은 수백 개의 ML 모델을 프로덕션에서 운영하면서, ML 시스템의 기술 부채(Technical Debt)가 전통적인 소프트웨어보다 훨씬 빠르게 축적된다는 것을 발견했다. 2015년 NeurIPS에서 발표한 “Hidden Technical Debt in Machine Learning Systems” 논문은 다음을 지적했다:

• ML 코드는 전체 시스템의 5% 미만. 나머지 95%는 데이터 수집, 검증, 특성 추출, 서빙, 모니터링 인프라
• 전통적 소프트웨어의 기술 부채 유형(코드 복잡성, 종속성 등)에 더해, ML 고유의 부채가 존재: 데이터 종속성, 피드백 루프, 은밀한 특성 침식(Entanglement)
• “ML 시스템을 빠르게 만드는 것은 쉽지만, 유지보수 가능하게 만드는 것은 매우 어렵다”

Netflix - 추천 시스템의 교훈:

Netflix는 추천 시스템을 통해 연간 수십억 달러의 가치를 창출하면서도, 시스템 복잡성 관리에 지속적으로 투자해야 했다. 특히 피드백 루프 문제(추천된 콘텐츠만 소비 데이터가 생성됨)와 A/B 테스트의 장기 효과 측정에서 많은 교훈을 얻었다.

Uber - Michelangelo에서 얻은 교훈:

Uber는 ML 플랫폼 Michelangelo를 개발하면서, Feature Store, 모델 레지스트리, 자동 재학습 등의 패턴을 정립했다. 수백 명의 데이터 과학자가 수천 개의 모델을 운영하는 환경에서, 표준화된 설계 패턴 없이는 시스템이 유지 불가능하다는 것을 증명했다.

이러한 경험들이 축적되면서, ML 시스템 설계는 “모델 학습”과는 별개의 독립적인 엔지니어링 분야로 자리 잡았다.

---

핵심 개념

1. Online vs Batch Prediction

특성	Batch (오프라인)	Online (실시간)	Near-Realtime
처리 방식	주기적 대량 예측, 결과 저장	요청마다 즉시 예측	마이크로배치 (수초~수분)
지연시간	수분~수시간	수십 밀리초~수초	수초~수분
사용 예	추천 시스템, 보고서	사기 탐지, 검색 랭킹	뉴스 개인화
장점	간단, 복잡한 모델 사용 가능	최신 데이터 반영	균형 잡힌 접근
단점	데이터 신선도 낮음	인프라 복잡, 지연 제약	양쪽의 복잡성

선택 기준: 지연시간 요구사항, 데이터 신선도(freshness), 인프라 비용

2. A/B Testing

기존 모델(A)과 새 모델(B)을 동시에 서빙하여 성능을 비교한다.

설계 요소:

• 통계적 유의성: p-value, 신뢰 구간, 최소 표본 크기 계산
• 트래픽 분배: 보통 50:50 또는 90:10 (위험 최소화)
• 기간: 충분한 데이터 수집 + seasonality 고려

A/B 테스트의 최소 표본 크기(Minimum Sample Size)는 다음으로 결정된다:

$n \geq \frac{(z_{\alpha/2} + z_{\beta})^2 \cdot 2\sigma^2}{\delta^2}$

• $z_{\alpha/2}$: 유의 수준에 대응하는 z-값 (예: $\alpha=0.05$이면 $z_{0.025}=1.96$)
• $z_{\beta}$: 검정력(power)에 대응하는 z-값 (예: power=0.8이면 $z_{0.2}=0.84$)
• $\sigma^2$: 메트릭의 분산
• $\delta$: 탐지하고자 하는 최소 효과 크기 (Minimum Detectable Effect)

주의사항:

• Novelty effect: 새 것에 대한 일시적 선호
• Seasonality: 계절/요일 패턴 고려
• Interference: 실험 그룹 간 상호 영향

Multi-Armed Bandit: Explore-exploit trade-off를 활용한 A/B Testing 대안. 더 좋은 모델에 점진적으로 더 많은 트래픽을 할당한다.

3. Shadow Deployment

새 모델의 예측을 실제 서비스에 반영하지 않고, 기록만 하여 기존 모델과 비교한다.

장점	단점
위험 없이 실환경 평가	사용자 반응 정보 부재
실제 트래픽으로 테스트	추가 인프라 비용
배포 전 성능 검증	시간 지연

4. Feature Store

ML 특성의 중앙 저장소로, 특성의 생성, 저장, 서빙을 통합 관리한다.

장점:

• 특성 재사용: 여러 모델이 동일 특성 공유
• Online/Offline 일관성: Training-Serving Skew 방지
• 특성 발견: 팀 간 특성 공유와 검색

도구: Feast, Tecton, Vertex AI Feature Store

5. 프로덕션 모니터링 (Monitoring)

Data Drift (데이터 드리프트)

드리프트 유형	정의	탐지 방법
Covariate Shift	입력 분포 변화	PSI, KS test
Prior Probability Shift	클래스 비율 변화	클래스 분포 추적
Concept Drift	입출력 관계 변화 (가장 위험)	성능 지표 하락

탐지 도구:

• PSI (Population Stability Index): 두 분포 간의 안정성 측정

$\text{PSI} = \sum_{i=1}^{B}\bigl(p_i^{\text{new}} - p_i^{\text{ref}}\bigr) \ln\frac{p_i^{\text{new}}}{p_i^{\text{ref}}}$

• KS Test (Kolmogorov-Smirnov): 두 분포의 최대 차이 검정

$D_{KS} = \sup_x |F_{\text{ref}}(x) - F_{\text{new}}(x)|$

$D_{KS}$가 임계값 $c(\alpha) \cdot \sqrt{\frac{n_1 + n_2}{n_1 \cdot n_2}}$을 초과하면 분포 변화가 유의하다고 판단한다.

• 특성별 분포 비교: 히스토그램, 분위수 추적

대응 전략:

• 자동 재학습 파이프라인
• 적응적(incremental) 학습
• 모델 fallback / 규칙 기반 전환
• 알림 시스템 구축

6. 피드백 루프 (Feedback Loops)

모델 예측이 미래 데이터에 영향을 미치는 현상이다.

예시: 추천 시스템 → 추천된 아이템만 클릭 데이터 생성 → 다음 학습에서 더 추천 → 선순환/악순환

문제: 자기 강화 편향, 다양성 감소, 필터 버블

완화: Exploration 메커니즘, 랜덤 노출 실험, 다양성 제약

---

상세 내용

ML 시스템 아키텍처 전체 그림

Google MLOps 성숙도 모델

레벨	설명	특징
Level 0	수동 ML	스크립트 기반, 수동 배포, 모니터링 없음
Level 1	ML 파이프라인 자동화	지속적 학습, 자동 재학습
Level 2	CI/CD 파이프라인	코드+데이터+모델 전체 자동화, 자동 테스트

용량 계획 (Capacity Planning)

프로덕션 ML 시스템의 리소스 산정에 사용하는 정량적 공식이다.

QPS (Queries Per Second) 추정:

$\text{QPS}_{\text{peak}} = \text{QPS}_{\text{avg}} \times \text{Peak Factor}$

일반적으로 Peak Factor는 2~5배 사이이며, 서비스 특성에 따라 달라진다.

모델 서빙 인스턴스 수:

$N_{\text{instances}} = \left\lceil \frac{\text{QPS}_{\text{peak}}}{\text{QPS}_{\text{per\_instance}}} \right\rceil \times (1 + \text{Redundancy Factor})$

• $\text{QPS}_{\text{per\_instance}}$: 단일 인스턴스의 최대 처리량
• Redundancy Factor: 장애 대비 여유분 (보통 0.2~0.5)

모델 메모리 요구량:

$\text{Memory}_{\text{total}} = N_{\text{params}} \times B_{\text{precision}} + \text{Memory}_{\text{activation}} + \text{Memory}_{\text{KV-cache}}$

• $N_{\text{params}}$: 모델 파라미터 수
• $B_{\text{precision}}$: 파라미터당 바이트 (FP32=4, FP16=2, INT8=1)
• $\text{Memory}_{\text{activation}}$: 추론 시 중간 활성화 메모리
• $\text{Memory}_{\text{KV-cache}}$: Transformer 모델의 경우 KV-cache 메모리 (배치 크기와 시퀀스 길이에 비례)

---

언제 사용하는가

패턴	적합한 상황
Batch Prediction	지연시간 덜 중요, 복잡한 모델, 주기적 업데이트
Online Prediction	실시간 결정 필요, 최신 데이터 반영
A/B Testing	새 모델의 비즈니스 영향 측정
Shadow Deployment	위험 최소화, 대규모 변경 검증
Feature Store	여러 모델이 특성 공유, 대규모 팀
자동 재학습	빈번한 데이터 변화, concept drift

---

실전 사례

피드백 루프가 추천 시스템의 다양성을 죽인 사례

한 대형 음악 스트리밍 플랫폼에서 추천 시스템의 피드백 루프(Feedback Loop)가 콘텐츠 다양성을 극적으로 감소시킨 사례이다.

초기 상태:

• 추천 모델은 사용자의 청취 이력을 기반으로 다음 곡을 추천
• 출시 당시 사용자당 평균 15개 장르의 음악을 소비
• 추천 시스템의 CTR(Click-Through Rate)은 25%

6개월 후:

지표	출시 시	6개월 후	변화
사용자당 평균 소비 장르 수	15개	3개	80% 감소
상위 1% 인기곡 재생 비율	20%	65%	3.25배 증가
신규 아티스트 발견률	12%	0.5%	96% 감소
추천 CTR	25%	42%	68% 증가
사용자 이탈률(30일)	8%	22%	2.75배 증가

무슨 일이 일어났는가:

피드백 루프의 악순환이 발생했다:

1. 추천 모델이 사용자의 최근 청취 기록을 기반으로 비슷한 곡을 추천
2. 사용자는 추천된 곡 중에서만 선택 → 청취 데이터가 더 편향됨
3. 다음 재학습에서 모델은 편향된 데이터를 학습 → 더 좁은 범위의 곡을 추천
4. 이 과정이 반복되면서 사용자의 음악 취향이 점점 좁은 버블(Filter Bubble)에 갇힘

CTR은 올라갔지만(좁은 범위의 “안전한” 추천이므로), 사용자들은 점점 지루함을 느꼈고, 이탈률이 급격히 증가했다. 전체 콘텐츠의 다양성은 95% 이상 감소했다.

해결 방법:

• 추천 결과의 10%를 랜덤 탐색(Exploration)에 할당: Epsilon-Greedy 전략 적용
• 다양성 제약(Diversity Constraint) 추가: 추천 목록 내 최소 5개 장르 포함 필수
• Counterfactual 학습: 추천되지 않았지만 사용자가 자발적으로 선택한 데이터에 가중치 부여
• 장기 만족도 지표 도입: CTR 대신 30일 잔존율(Retention)을 주요 최적화 목표로 변경

수정 후 6개월 간: 사용자당 소비 장르가 3개에서 11개로 회복, 이탈률이 22%에서 10%로 감소, 신규 아티스트 발견률이 8%로 회복되었다.

교훈: 피드백 루프는 단기 지표(CTR)를 개선하면서 장기 가치(사용자 잔존)를 파괴할 수 있다. ML 시스템을 설계할 때는 모델의 예측이 미래 데이터에 미치는 영향을 반드시 고려해야 하며, 단기 최적화 지표와 장기 비즈니스 목표의 정렬이 필수적이다.

---

흔한 오해와 함정

1. 모니터링 없이 배포: 모델 성능은 시간이 지남에 따라 반드시 저하된다. 모니터링 없이 배포하면 성능 저하를 인지하지 못한다.

2. A/B Test의 통계적 유의성 무시: 충분한 데이터 없이 결론을 내리면 잘못된 의사결정을 한다. 최소 표본 크기를 사전 계산하라.

3. Feature Store 없이 대규모 ML: Feature Store 없이 여러 모델을 운영하면 특성 정의 불일치, Training-Serving Skew, 중복 작업이 발생한다.

4. 피드백 루프를 인식하지 못함: 추천 시스템에서 인기 편향이 자기 강화되는 것처럼, 모델의 예측이 미래 데이터에 미치는 영향을 고려해야 한다.

5. 자동 재학습만으로 충분하다: 재학습 시 데이터 품질 검증, 성능 임계값 확인, 편향 검사 등이 함께 자동화되어야 한다.

---

다른 주제와의 연결

• ML 파이프라인 설계: 파이프라인의 프로덕션 확장
• 실험 추적: Model Registry와 배포 관리
• 모델 배포: 서빙 인프라와 압축
• 윤리적 AI: 피드백 루프와 공정성
• 흔한 실수: Training-Serving Skew
• MLOps 기초: CI/CD, 모니터링의 자동화
• 데이터 누수: Feature Store로 누수 방지