운영에서 생기는 문제
모델 운영이 어려운 다섯 가지 이유와, 플랫폼이 각각을 어떻게 다루는지
다섯 가지 문제
| # | 문제 | 흔한 증상 | Geo-MLOps 의 대응 |
|---|---|---|---|
| 1 | 재현되지 않는 학습 | "그때 어떤 설정으로 돌렸더라?" 같은 코드로 다시 돌려도 결과가 다르다 | 학습 마법사가 설정 전체를 저장합니다. 모든 실행의 파라미터·지표·산출물은 MLflow 실험에 자동으로 기록됩니다. 같은 설정으로 다시 제출 한 번이면 재현됩니다 |
| 2 | 출처를 모르는 모델 | 운영 중인 모델 파일이 어떤 데이터로 만들어졌는지 모른다 | 모델 버전마다 학습 실행·데이터셋·지표가 연결됩니다. 레지스트리에서 버전을 누르면 거꾸로 따라갈 수 있습니다 |
| 3 | 검증 없는 배포 | 좋아 보이는 모델을 담당자가 바로 현장에 올린다 | 스테이지(Staging → Production)와 승인. Production 으로 올리는 일은 언제나 승인 요청으로 시작하고, 승인자가 승인해야 반영됩니다. 안전이 중요한 모델은 승인이 두 번 필요합니다 |
| 4 | 흩어진 현장 장비 | 장비마다 모델 버전이 다르고, 꺼진 장비를 한참 뒤에 안다 | Edge Fleet 이 장비의 하트비트(장비가 살아 있다고 주기적으로 보내는 신호), 수집 데이터, 추론 결과를 모읍니다. 명령·정책·모델은 중앙에서 보냅니다. 연결이 끊긴 장비는 경보로 알려 줍니다 |
| 5 | 조용히 나빠지는 성능 | 현장 데이터가 바뀌어 정확도가 떨어져도 아무도 모른다 | 드리프트 감시가 입력 데이터의 분포가 얼마나 바뀌었는지 PSI·KS 지표로 재고 경보를 냅니다. 그 화면에서 바로 재학습을 시작할 수 있습니다 |
여러 팀이 함께 쓸 때
플랫폼 하나를 여러 팀(또는 고객사)이 나눠 쓰는 경우가 많습니다. Geo-MLOps 는 팀을 테넌트로 나눕니다.
- 데이터셋·실험·모델·이미지·장비는 테넌트마다 따로 보입니다. 다른 테넌트의 것은 목록에도 나오지 않습니다.
- 학습·서빙 작업은 테넌트별 Kubernetes 네임스페이스(
tenant-<코드>)에서 돌고, GPU 는 테넌트별로 배선(할당)합니다. - 한 사람이 여러 테넌트에 속할 수 있고, 테넌트마다 역할이 다를 수 있습니다.