AI 시스템은 왜 운영이 어려운가

이 장에서 배울 것

AI 모델은 노트북에서 좋은 점수를 냈다고 해서 곧바로 서비스가 되지 않습니다. 운영 환경에서는 데이터가 계속 바뀌고, 사용자는 예측하지 못한 입력을 보내며, 서버는 장애를 일으킬 수 있습니다. 모델을 둘러싼 데이터 파이프라인, 배포 절차, 모니터링, 협업 방식이 함께 준비되지 않으면 높은 정확도의 모델도 쉽게 무너집니다.

이 장에서는 AI 시스템 운영이 어려운 이유를 MLOps 관점에서 봅니다. MLOps는 머신러닝 시스템을 안정적으로 개발, 배포, 운영하기 위한 방법입니다. 핵심은 모델 하나가 아니라 모델이 계속 동작하게 만드는 전체 흐름입니다.

왜 이 주제가 중요한가

많은 팀이 처음에는 모델 성능에 집중합니다. 정확도, F1 점수, 손실값 같은 지표를 올리는 데 많은 시간을 씁니다. 물론 모델 성능은 중요합니다. 하지만 실제 장애는 모델 알고리즘 자체보다 주변에서 더 자주 발생합니다.

예를 들어 학습할 때 사용한 데이터 형식과 운영 서버에 들어오는 데이터 형식이 다를 수 있습니다. 학습 당시에는 항상 값이 있던 컬럼이 운영에서는 비어 있을 수 있습니다. 배포 과정에서 잘못된 모델 파일을 올릴 수도 있습니다. 성능 저하가 발생했는데 모니터링이 없어 며칠 동안 아무도 모를 수도 있습니다.

AI 시스템은 일반 소프트웨어보다 변화하는 요소가 많습니다. 일반 소프트웨어는 코드가 바뀌면 동작이 바뀌는 경우가 많습니다. 반면 AI 시스템은 코드가 그대로여도 데이터가 바뀌면 결과가 바뀝니다. 이 차이를 이해하는 것이 MLOps의 출발점입니다.

핵심 개념 설명

모델 코드는 전체 시스템의 일부다

실제 AI 서비스에는 모델 코드 외에 많은 구성요소가 필요합니다. 데이터를 수집하는 작업, 데이터 품질을 검사하는 규칙, 학습 설정, 모델 저장소, 배포 스크립트, API 서버, 모니터링 대시보드, 장애 대응 절차가 함께 있어야 합니다.

간단한 추천 시스템을 생각해 봅시다. 추천 모델 파일만 있으면 끝날 것 같지만 실제로는 그렇지 않습니다. 사용자 행동 로그를 모아야 하고, 잘못된 로그를 걸러야 하며, 학습용 데이터셋을 만들어야 합니다. 모델을 학습한 뒤에는 어떤 데이터와 설정으로 학습했는지 기록해야 합니다. 배포 후에는 추천 클릭률이 갑자기 떨어지지 않는지 확인해야 합니다.

따라서 AI 시스템 운영의 핵심 질문은 "모델이 좋은가?"에서 끝나지 않습니다. "이 모델을 같은 조건에서 다시 만들 수 있는가?", "문제가 생겼을 때 원인을 추적할 수 있는가?", "새 모델을 안전하게 배포할 수 있는가?"까지 물어야 합니다.

DevOps의 CI/CD와 MLOps의 CI/CD/CT

DevOps에서 CI는 지속적 통합입니다. 여러 개발자가 작성한 코드를 자주 합치고, 테스트를 자동으로 실행해 문제를 빨리 찾는 방식입니다. CD는 지속적 배포 또는 전달입니다. 검증된 코드를 운영 환경에 안전하게 배포하는 절차를 말합니다.

MLOps도 CI/CD를 사용하지만, 여기에 데이터와 모델 검증이 추가됩니다. 코드 테스트만 통과했다고 충분하지 않기 때문입니다. 학습 데이터가 갑자기 바뀌었는지, 결측치가 늘었는지, 특정 클래스가 사라졌는지 확인해야 합니다. 새 모델이 기존 모델보다 실제 운영 지표에서 나은지도 검증해야 합니다.

또 하나 중요한 개념은 CT입니다. CT는 지속적 학습입니다. 새로운 데이터가 쌓였을 때 모델을 다시 학습하고, 검증하고, 필요하면 배포하는 흐름입니다. 모든 서비스가 자동 재학습을 해야 하는 것은 아닙니다. 하지만 데이터가 빠르게 바뀌는 서비스라면 재학습 주기와 승인 절차를 명확히 해야 합니다.

정리하면 일반 소프트웨어 운영은 주로 코드 변경을 관리합니다. AI 시스템 운영은 코드, 데이터, 모델, 설정, 지표의 변경을 함께 관리합니다.

운영 장애로 이어지는 대표 문제

첫째, 학습-서빙 편향입니다. 학습할 때 사용한 데이터 처리 방식과 서빙할 때 사용하는 처리 방식이 다르면 모델 입력이 달라집니다. 예를 들어 학습에서는 나이를 10대, 20대처럼 구간화했는데 운영 API에서는 원래 숫자 그대로 넣는다면 모델은 예상과 다른 입력을 받습니다.

둘째, 데이터 드리프트입니다. 드리프트는 시간이 지나면서 데이터의 성질이 바뀌는 현상입니다. 쇼핑몰의 고객 행동은 계절, 이벤트, 경기 상황에 따라 달라질 수 있습니다. 모델은 과거 데이터를 기준으로 학습했기 때문에 현재 데이터가 크게 바뀌면 성능이 떨어질 수 있습니다.

셋째, 실험-운영 간극입니다. 데이터 과학자가 실험 환경에서 만든 코드는 빠른 검증에는 좋지만 운영에는 부족할 수 있습니다. 파일 경로가 개인 노트북에 고정되어 있거나, 랜덤 시드가 설정되지 않았거나, 데이터 버전이 기록되지 않은 경우가 있습니다. 이런 상태로 배포하면 같은 결과를 다시 만들기 어렵습니다.

넷째, 숨은 기술 부채입니다. 기술 부채는 당장은 빠르게 만들었지만 나중에 유지보수를 어렵게 만드는 선택을 말합니다. AI 시스템에서는 수동으로 만든 데이터 파일, 문서화되지 않은 전처리 규칙, 담당자만 아는 배포 절차가 기술 부채가 됩니다. 처음에는 작은 불편이지만, 모델과 데이터가 늘어나면 장애의 원인이 됩니다.

쉬운 비유 또는 사례

AI 시스템은 식당 운영과 비슷합니다. 모델은 요리법입니다. 좋은 요리법이 있어도 재료가 상했거나, 조리 도구가 다르거나, 주방 직원마다 순서가 다르면 같은 맛을 내기 어렵습니다.

학습 데이터는 재료입니다. 전처리 코드는 손질 방법입니다. 학습 설정은 조리 온도와 시간입니다. 모델 레지스트리는 완성된 요리법을 보관하는 책장입니다. 서빙 인프라는 손님에게 음식을 내보내는 홀 운영입니다. 모니터링은 손님 반응과 위생 상태를 확인하는 일입니다.

어느 추천 서비스 팀이 새 모델을 만들었다고 가정해 봅시다. 실험에서는 클릭률 예측 성능이 좋아졌습니다. 하지만 배포 후 실제 클릭률은 떨어졌습니다. 원인을 확인해 보니 운영 서버의 전처리 코드가 실험 코드보다 오래된 버전이었습니다. 또 일부 사용자 로그가 수집되지 않았지만 알림이 없었습니다. 이 문제는 모델 수식의 문제가 아니라 운영 체계의 문제입니다.

역할과 책임 경계

AI 시스템은 여러 역할이 함께 만듭니다. 책임이 흐리면 장애가 발생했을 때 서로 원인을 미루게 됩니다. 그래서 역할 경계를 정리해야 합니다.

데이터 과학자는 문제 정의, 피처 탐색, 모델 실험, 평가 지표 설계를 주로 담당합니다. 피처는 모델이 입력으로 사용하는 값입니다. 예를 들어 최근 7일 구매 횟수, 평균 체류 시간 같은 값입니다.

데이터 엔지니어는 데이터를 안정적으로 수집하고 저장하며, 학습과 분석에 쓸 수 있는 형태로 가공합니다. 데이터 품질 검사와 파이프라인 안정성도 중요한 책임입니다.

ML 엔지니어는 실험 코드를 운영 가능한 학습·배포 파이프라인으로 바꿉니다. 모델 패키징, 모델 레지스트리 연동, 서빙 최적화, 자동화된 검증을 담당합니다.

DevOps 엔지니어는 인프라, CI/CD, 배포 환경, 권한, 관측성 도구를 관리합니다. 관측성은 시스템 내부 상태를 로그, 지표, 추적 정보로 파악할 수 있는 능력입니다.

운영자는 서비스 상태를 감시하고 장애 대응 절차를 실행합니다. 운영자는 모델의 세부 알고리즘을 모두 알 필요는 없지만, 어떤 지표가 위험 신호인지와 장애 시 누구에게 연결해야 하는지는 알아야 합니다.

중요한 것은 역할을 나누되 벽을 만들지 않는 것입니다. 데이터 문제는 모델 성능 문제로 나타나고, 배포 문제는 사용자 경험 문제로 나타납니다. MLOps는 이 연결을 팀 전체가 볼 수 있게 만드는 방식입니다.

직접 해보는 실습

이번 실습의 목표는 현재 팀 또는 개인 프로젝트의 MLOps 성숙도를 간단히 진단하는 것입니다. 아직 실제 프로젝트가 없다면 가상의 이미지 분류 서비스나 추천 서비스를 하나 정해도 됩니다.

아래 항목에 대해 예, 부분적, 아니오로 답해 보세요.

아니오가 많다면 수동 운영 단계에 가깝습니다. 부분적이 많다면 일부 자동화가 있지만 재현성과 관측성이 부족한 상태입니다. 예가 대부분이라면 파이프라인 기반 운영에 가까워지고 있습니다.

추가로 한 문단 회고를 작성해 보세요. "우리 프로젝트에서 모델 정확도보다 먼저 무너질 가능성이 큰 부분은 무엇인가?"라는 질문에 답하면 됩니다.

흔한 실수와 오류 분석

첫 번째 실수는 모델 성능 지표만 보고 배포를 결정하는 것입니다. 오프라인 평가에서 성능이 좋아도 운영 데이터에서 같은 결과가 나오리라는 보장은 없습니다. 배포 전에는 데이터 스키마, 전처리 일치 여부, 응답 시간, 실패 시 롤백 방법을 함께 확인해야 합니다.

두 번째 실수는 실험 기록을 사람의 기억에 맡기는 것입니다. 어떤 데이터로, 어떤 파라미터를 사용해, 어떤 코드 버전에서 학습했는지 남기지 않으면 문제가 생겼을 때 되돌아갈 수 없습니다.

세 번째 실수는 재학습을 무조건 자동화하는 것입니다. 자동화는 중요하지만 검증 없는 자동화는 위험합니다. 데이터가 오염된 상태에서 자동 재학습이 실행되면 나쁜 모델이 빠르게 배포될 수 있습니다.

네 번째 실수는 모니터링을 서버 지표에만 두는 것입니다. CPU, 메모리, 오류율도 중요하지만 AI 시스템은 입력 데이터 분포, 예측값 분포, 실제 정답이 들어온 뒤의 성능 지표까지 봐야 합니다.

요약

AI 시스템 운영이 어려운 이유는 모델만 관리해서는 충분하지 않기 때문입니다. 데이터, 코드, 설정, 모델, 배포 환경, 모니터링이 함께 맞물려야 합니다.

DevOps의 CI/CD는 코드 중심의 자동화에 가깝습니다. MLOps의 CI/CD/CT는 여기에 데이터 검증, 모델 검증, 지속적 학습까지 포함합니다. 운영 장애는 학습-서빙 편향, 데이터 드리프트, 실험-운영 간극, 숨은 기술 부채에서 자주 시작됩니다.

좋은 MLOps는 복잡한 도구를 많이 쓰는 것이 아닙니다. 같은 결과를 다시 만들 수 있고, 문제가 생겼을 때 원인을 추적할 수 있으며, 안전하게 배포하고 되돌릴 수 있는 상태를 만드는 것입니다.

퀴즈

1. AI 시스템에서 코드가 바뀌지 않아도 성능이 떨어질 수 있는 이유는 무엇인가요?

2. DevOps의 CI/CD와 MLOps의 CI/CD/CT는 어떤 점이 다른가요?

3. 학습-서빙 편향이란 무엇인가요?

4. 데이터 드리프트가 발생하면 어떤 운영 문제가 생길 수 있나요?

5. 모델 레지스트리나 실험 추적이 필요한 이유를 한 문장으로 설명해 보세요.

체크리스트

• 모델 코드는 AI 시스템의 일부일 뿐임을 설명할 수 있다.

• 데이터, 모델, 설정, 배포 환경을 함께 관리해야 하는 이유를 이해했다.

• CI, CD, CT의 차이를 말할 수 있다.

• 학습-서빙 편향과 데이터 드리프트의 의미를 설명할 수 있다.

• AI 프로젝트의 주요 역할과 책임을 구분할 수 있다.

• 현재 프로젝트의 MLOps 성숙도를 간단히 진단할 수 있다.

다음 장 연결

다음 장에서는 AI 시스템의 출발점인 데이터를 다룹니다. 운영에서 모델이 무너지는 많은 문제는 데이터 수집과 품질 관리에서 시작됩니다. 어떤 데이터를 모아야 하는지, 잘못된 데이터를 어떻게 찾을지, 데이터 품질 기준을 어떻게 세울지 살펴보겠습니다.