[시스템디자인] 머신러닝 디자인 패턴의 안티패턴(Antipatterns)이란?
📌 목차
- 머신러닝 디자인 패턴의 안티패턴(Antipatterns)이란 무엇인가요?
- 왜 머신러닝 안티패턴이 필요한가요?
- 머신러닝 안티패턴 종류
1. 머신러닝 디자인 패턴의 안티패턴(Antipatterns)이란 무엇인가요?
머신러닝이 실제 운영 환경에서 겪는 어려움들, 즉 비효율적이거나 비생산적인 운영 사례들을 '원인에서 문제 발생까지의 과정'으로 묶어 정리한 것입니다.
이러한 묶음을 '안티패턴(Antipatterns)'이라 부르며, 패턴은 크게 4가지로 구분됩니다.
디자인 패턴은 경험을 바탕으로 정의되었기 때문에 모든 어려운 상황에 대한 해결책이 되지는 않지만,
문제 발생 시 문제 해결의 방향을 잡는 데 매우 유용합니다.
머신러닝이 실제 운영 환경에서 겪는 어려움들?
❗Data quality (데이터 품질)
데이터의 정확성, 완전성, 일관성, 적시성을 포함한 데이터의 전반적인 품질 문제.
❗ Reproducibility (재현성)
동일한 데이터를 사용해 동일한 결과를 다시 얻을 수 있는 능력과 관련된 문제.
❗ Data Drift (데이터 변화)
시간에 따라 데이터의 분포가 변하는 현상으로, 모델 성능에 영향을 미칠 수 있는 문제.
❗ Scale (규모 확장성)
데이터나 시스템의 규모가 커지면서 발생하는 성능 저하나 운영상의 문제.
2. 왜 머신러닝 안티패턴이 필요한가요?
문제가 발생했을 때, 원인을 쉽게 파악하고 빠르게 해결 방안을 찾을 수 있기 때문입니다.
안티패턴은 머신러닝의 문제를,
✨4가지 운영 환경(SERVING, TRAINING, QA, OPERATION)으로 나누어
각 환경에서 발생할 수 있는 문제들을 정의합니다.
각 안티패턴은 다음과 같이 세 부분으로 구분 지어 보면 좋습니다 :
1. 문제나 문제 상황을 설명하는 Case(문제 사례)
2. 해당 문제를 야기한 환경을 설명하고 대안을 제시하는 Situation(환경)
3. 문제와 문제환경을 시각적으로 보여주는 Diagram(도식)
따라서 머신러닝 문제를 해결할 때,
서비스가 속한 운영 환경을 파악한 후 해당 환경에서 발생할 수 있는 문제 사례를 찾아 해결책을 제시할 수 있습니다.
3. 머신러닝 안티패턴 종류 4가지
안티패턴은 4가지 운영 환경(SERVING, TRAINING, QA, OPERATION) 패턴별로 정의됩니다.
각 운영 환경 패턴별 안티패턴들의 'Case(문제상황)'와 'Situation(환경)' 간단히 요약해 보았습니다.
자세한 내용은 출처에서 확인가능합니다.
☑️ SERVING 패턴의 안티패턴
(SERVING 패턴: 운영 환경에서 모델을 서빙하는 패턴)
- Online bigsize pattern (온라인 대규모 패턴)
- Case(문제상황): 대규모 데이터를 실시간으로 처리할 때 발생하는 성능 문제.
- Situation(환경): 실시간 처리가 필요한 웹 서비스나 대규모 배치 시스템에서 모델의 예측 시간이 성능 요구 사항을 충족하지 못할 때 발생합니다. 대규모 복잡한 모델이 사용되면 처리 시간이 길어지기 때문에, 스케일 아웃이나 GPU 사용 등 최적화가 필요합니다
- All-in-one pattern (올인원 패턴)
- Case(문제상황): 모든 기능을 하나의 시스템에 몰아넣는 비효율적인 설계로 인한 문제.
- Situation(환경): 하나의 시스템에 다양한 기능을 몰아넣으면 유지보수가 어려워지고, 시스템 성능이 저하되며 확장성도 제한됩니다. 분리된 서비스로 관리하는 것이 더 효과적일 수 있습니다
☑️ TRAINING 패턴의 안티패턴
(TRAINING 패턴: 모델 학습 파이프라인을 구성하기 위한 패턴)
- Offline-only pattern (오프라인 전용 패턴)
- Case(문제상황): 모델을 오프라인에서만 학습시키고, 실시간 데이터와의 연동을 고려하지 않는 문제.
- Situation(환경): 오프라인에서만 모델을 테스트하면 실시간 데이터를 처리할 때 발생할 수 있는 성능 문제를 놓칠 수 있습니다. 따라서 실시간 환경에서도 모델이 제대로 작동하는지 검증하는 과정이 필요합니다
☑️ QA 패턴의 안티패턴
(QA 패턴: 운영 환경에서 모델 성능을 평가하는 패턴)
- Only-me pattern (나만의 패턴)
- Case(문제상황): 성능 평가나 테스트를 너무 좁은 시각에서만 진행하는 문제.
- Situation(환경): 특정한 조건에서만 성능 테스트를 진행하면 실제 환경에서 발생하는 다양한 상황을 반영하지 못해 실질적인 성능 저하를 경험할 수 있습니다
- Training code in serving pattern (서빙 환경에서 학습 코드 패턴)
- Case(문제상황): 모델 서빙 환경에서 학습 코드를 그대로 사용하는 비효율적인 문제.
- Situation(환경): 서빙과 학습 코드의 요구 사항이 다르므로 서빙 환경에 맞춘 최적화가 필요합니다
- Too many pipes pattern (너무 많은 파이프라인 패턴)
- Case(문제상황): 너무 복잡한 파이프라인 구조로 인해 관리와 유지 보수가 어려운 문제.
- Situation(환경): 지나치게 복잡한 파이프라인은 시스템의 유연성을 떨어뜨리고, 버그 발생 시 원인을 찾기 어렵게 만듭니다
☑️ OPERATION 패턴의 안티패턴
(OPERATION 패턴: 모델 운영을 위한 패턴)
- No logging pattern (로그 없음 패턴)
- Case(문제상황): 시스템 운영 중 발생하는 문제를 추적할 수 있는 로그가 부족한 상황.
- Situation(환경): 운영 중 발생하는 오류나 문제를 분석할 수 있는 로그가 없다면 문제 해결에 어려움을 겪게 됩니다. 적절한 로깅 시스템을 갖추는 것이 필수적입니다
- Nobody knows pattern (아무도 모르는 패턴)
- Case(문제상황): 시스템이나 모델의 상태나 문제를 아는 사람이 없는 상황.
- Situation(환경): 시스템을 운영하는 사람들이 모델의 동작 방식이나 문제 해결 방안을 모르는 경우, 빠른 대응이 불가능해집니다. 이를 방지하기 위해 문서화와 지식 공유가 중요합니다