이것만은 제발, 안티 패턴 anti pattern

요새 머신러닝 시스템 디자인 패턴 이라는 키워드로 공부를 하고있습니다. 비전공자로 시작한 저는 그간 모든 코딩을 체득하면서 배웠기 때문에(전문용어로 bottom up..), 누군가에게 설명할 때면 난감한 상황이 벌어지곤 합니다(이거 요리조리 따라하면 코드에 참 좋은데, 말로 설명할 방법이 없네…). 그래서 배우신 분들이 잘 정립한 이런 자료들을 맞닥뜨리면 그렇게나 반가울 수가 없습니다. 저만 써먹기엔 아까워서 포스트로 남겨둡니다. 머신러닝을 활용한 서비스를 만들고 싶은 분들에게 유용하길 바랍니다.

머신러닝 시스템 디자인 패턴, 첫번째 주제로 제발 이것만은 하지 말자는 내용의 anti pattern 부터 출발합니다. ⚠️정말 중요하지만 듣고나면 다 아는 내용 주의⚠️

나도 모르는 새 이미 쓰고 있던 머신러닝 시스템 디자인 패턴

이것만은 제발, Anti pattern : Only-me, Training code in serving, All-in-one pattern
씹뜯맛즐 활용편(예정) : Batch, transfer learning, checkpoint pattern
딥러닝이 중요한게 아니야(예정) : Monolithic vs Micro-service architecture

디자인 패턴 1 : Only-me

스스로 AI 공부를 시작한 저와 같은 사람이라면 개인 컴퓨터에서(뜨끔;) 주피터 노트북 등을 활용하여(흠칫) 머신러닝 모델을 개발하는 경우가 많습니다. 하지만 이렇게 개발된 모델을 실제 운영 환경에 배포하기 위해서는 몇 가지를 꼭 고려해야합니다. Only-me 패턴에서는 ML 엔지니어 개인 환경에서 모델 개발이 이루어지므로, 완성된 모델이 개인 환경에 완전히 의존하게 됩니다. 추후 개인 환경에 변화가 생기면 모델을 재현할 수 없게 되는 리스크가 발생합니다.

먼저 개발 환경과 동일한 환경을 실제 시스템에 구축해야 합니다. 즉, 모델 개발 시 사용한 OS 버전, 프로그래밍 언어, 라이브러리 및 버전 등을 운영 환경에서도 동일하게 맞춰야 합니다. 환경이 다르면 모델의 성능이나 동작이 개발 당시와 다를 수 있기 때문입니다. 사소한 라이브러리 버전 변경만으로도 모델 실행이나 성능에 큰 영향을 미칠 수 있습니다.

실제 운영 환경에서 모델이 제대로 동작하기 위해서는 협업은 필수적입니다. ML 엔지니어는 데이터 전/후처리, 모델 개발 등을 담당하고, 다른 엔지니어들이 UI, API, 백엔드 시스템 등을 개발합니다. 이렇게 분리 개발된 부분들을 안전하게 통합하여 배포하기 위해서는 모델 적용 초기 단계부터 코드 리뷰를 실시하고, 시스템 전체의 실행 로직에 대해 서로 이해하는 것이 중요합니다.

결론 : (자원이 허락하는 한) 모두가 공유할 수 있는 시스템을 만듭시다.

디자인 패턴 2 : Training code in serving pattern

머신러닝 모델을 실제 운영 환경에 배포하는 것은 쉬운 일이 아닙니다. 모델 학습과 서빙 단계 사이에는 많은 차이점이 있기 때문입니다. 학습 단계에서는 데이터 변환, 정규화, 하이퍼파라미터 최적화 등의 작업이 이루어지지만, 서비스 개시 이후의 운영 상황에서는 이러한 구현이 적용되지 않습니다(변형보다는 유지의 관점이 필요하겠죠). 또한 학습을 위해 GPU, 대용량 CPU/RAM, 내부 네트워크/스토리지 등의 리소스가 필요하지만 서빙 환경에서는 상대적으로 필요성이 적습니다.

코드 및 라이브러리 의존성이 다를 수 있습니다. 학습 단계에서는 데이터 전처리, 분산 학습, 하이퍼파라미터 튜닝 등을 위한 다양한 라이브러리와 도구를 사용합니다. 하지만 운영 환경에서는 이런 부분이 필요 없으므로 의존성이 달라집니다.
리소스 요구사항이 다릅니다. 모델 학습을 위해서는 GPU, 대용량 CPU/RAM, 고속 네트워크, 대규모 스토리지 등 상당한 컴퓨팅 자원이 필요합니다. 반면 서빙 단계에서는 이런 고성능 리소스가 크게 요구되지 않습니다.
배치 vs 실시간 처리 방식이 다릅니다. 학습 단계에서는 대용량 데이터를 배치로 처리하지만, 서빙에서는 실시간으로 요청된 데이터를 개별적으로 처리해야 합니다.
보안 요구사항이 다릅니다. 학습용 데이터와 코드는 내부에서만 접근 가능해야 하지만, 서빙 API는 외부에 공개되어야 합니다.

이러한 차이로 인해 학습 코드를 그대로 운영 시스템에 적용하기 어렵습니다. 불필요한 의존성과 리소스로 인해 성능 저하, 보안 취약점, 안정성 이슈 등이 발생할 수 있기 때문입니다. 따라서 학습과 서빙 환경을 분리하는 것이 필수적입니다. OS, 언어, 라이브러리 버전 및 전처리/예측/후처리 로직 등 공통적인 부분만 표준화하고, 학습 관련 코드와 리소스는 분리하는 것이 중요합니다. 이를 통해 운영 환경에 불필요한 코드를 포함하지 않고, 안정성과 성능을 보장할 수 있습니다.

공통적인 표준화 부분:

OS, 프로그래밍 언어, 라이브러리 버전 등 기본 실행 환경
데이터 전/후처리, 모델 예측 등 코어 로직

분리할 부분:

학습용 코드 및 라이브러리 (배치처리, 분산학습, 하이퍼파라미터 튜닝 등)
학습 전용 리소스 (GPU, 고성능 CPU/RAM, 내부 스토리지 등)
운영환경에 필요한 부가 기능 (모니터링, 자동 스케일링, 장애대응 등)

이렇게 시스템을 분리하면 운영 환경에 불필요한 부분이 포함되지 않아 안정성과 성능이 보장됩니다. 또한 학습과 서빙 파이프라인을 개별적으로 발전시킬 수 있어 모델 업데이트 및 확장성도 높아집니다.

디자인 패턴 3 : All-in-one pattern

단일 인터페이스에서 여러 개의 예측 모델을 함께 담아 배포하고자 하는 경우가 더러 있습니다. 단일 환경에서 모든 모델을 실행하면 서버 자원을 공유하여 비용을 절감할 수는 있습니다. 하지만 이렇게 함으로써 소프트웨어 개발, 트러블슈팅, 업데이트 등의 운영 측면에서 여러 어려움이 한꺼번에 몰려옵니다. (그리고 오늘도 시동거는 무한나태지옥😈)

모델 개발 시 사용 가능한 라이브러리와 알고리즘 선택에 제한이 생깁니다. 오늘도 새로운 라이브러리와 알고리즘이 쏟아지고 있습니다. 하나의 환경에서 모든 모델을 개발해야 하므로, 특정 모델에 최적화된 라이브러리나 알고리즘을 자유롭게 선택하기 어렵습니다. 마치 그림의 떡이랄까.. 풍요 속 빈곤이랄까.. 사서 고생이랄까…
장애 발생 시 문제 해결이 복잡해집니다. 단일 아키텍처에서 장애가 발생하면 그 원인을 찾기 위해 모든(!?) 로그를 확인해야 합니다. 모델이 예측하는 과정에서 발생한 장애를 시스템 결함과 구분하기 어렵습니다. 전체 로직과 함께 비교하면서 로그를 점검해야 하므로 문제 해결에 상당히 많은 시간이 소요됩니다.
시스템과 모델의 업데이트 주기가 다르기 때문에 불필요한 비용이 발생합니다. 시스템 업데이트가 모델 입장에서는 굳이 필요하지 않을 수 있습니다. 단일 시스템에서는 양쪽을 동시에 갱신해야 하므로 운영 비용이 증가합니다.

따라서 특별한 이유가 없다면 서버당 한 개의 모델을 배포하는 마이크로서비스 아키텍처를 권장합니다. 이렇게 하면 모델 개발, 배포, 모니터링, 업데이트 등 전체 라이프사이클 관리가 용이해지며, 장애 발생 시에도 영향을 받는 부분을 효과적으로 분리할 수 있습니다. 이 부분은 세번째 포스트에서 또 다뤄볼 기회가 있을 것 같습니다.

마무리하며

복합적인 머신러닝 시스템 과 고민해봐야할 디자인 패턴! 내용적으로는 당연히 이렇게 코딩하면 안되겠지 알고는 있지만! 생각보다 빈번하게 점점 안티 패턴으로 나아가고있는 스스로를 돌아봐야할 때가 있죠. 시스템에 대한 구상은 인공지능도 어쩔 수 없는, 오롯이 엔지니어의 영역이라고 생각하기 때문에 많은 공부가 될 것으로 기대하고 있습니다.

다음 포스트에서는 딥러닝에서 기본적으로 활용하기 좋은 형태 패턴인 check point, transfer learning pattern 등에 대해서 알아보겠습니다.

다음 포스트

나도 모르는 새 이미 쓰고 있던 머신러닝 시스템 디자인 패턴 2. 씹뜯맛즐 활용편(예정) : Batch, transfer learning, checkpoint pattern

Reference

머신러닝 시스템 디자인 패턴(ko) – Github blog
머신러닝 디자인 패턴