잘 만든 AI 모델도 6개월이면 낡는다. 처음 배포했을 때는 정확도가 훌륭했는데, 몇 달 뒤부터 예측이 슬슬 엇나가기 시작하는 경험 — AI를 서비스에 붙여본 팀이라면 거의 다 안다. 이게 버그가 아니다. 세상이 바뀌는 속도를 모델이 못 따라가는 거다.
AI 모델은 한번 학습시키고 배포하면 끝나는 게 아니다. 그 뒤가 더 중요하다. 어떻게 해야 모델이 계속 쓸 만한 상태를 유지할까? 답은 결국 ‘지속 학습’과 ‘피드백 루프’ 두 가지로 모인다.
모델이 낡는 이유: 드리프트 두 가지
AI 모델이 지속적으로 학습해야 하는 이유는 크게 두 가지 현상 때문이다.
- 데이터 드리프트 (Data Drift): 모델은 특정 시점의 데이터로 학습된다. 근데 현실은 계속 바뀐다. 계절이 바뀌고, 유행이 꺾이고, 사용자 행동이 달라진다. 상품 추천 모델을 예로 들면, 여름에 학습한 모델이 겨울에 같은 추천을 하면 맞을 리가 없다. 학습 데이터와 실제 서비스 데이터의 분포가 벌어지는 게 데이터 드리프트다.
- 개념 드리프트 (Concept Drift): 이건 좀 더 골치 아프다. 데이터 분포만이 아니라 예측 대상 자체의 의미가 바뀌는 경우다. 스팸 메일 탐지 모델을 보자. 스팸 발송자들은 매일 새 패턴을 만들어낸다. 작년 스팸 기준으로 학습된 모델은 올해 스팸을 잡기 어렵다. 정답 자체가 이동하는 셈이다.
이 두 가지 드리프트에 대응 못 하면 모델은 서서히 무용지물이 된다. 경쟁사보다 빠르게 드리프트를 잡아내는 팀이, 그만큼 시장 변화에 선제적으로 반응할 수 있다.
피드백 루프가 뭔데?
AI 피드백 루프는 단순하게 말하면 ‘모델의 예측 결과를 실제 결과와 비교하고, 그 차이로 모델을 업데이트하는 순환 과정’이다. 사람이 실수하고 다음번엔 다르게 행동하는 것과 같은 원리다.
이 루프에서 ‘인간 개입(Human-in-the-loop, HITL)’이 꽤 결정적인 역할을 한다. AI가 스스로 판단하기 애매한 케이스들 — 모델 신뢰도가 낮은 예측이나 파급력이 큰 결정은 사람이 직접 검토해야 피드백 데이터의 질이 올라간다.
피드백 루프 만들려면 뭐가 필요한가
견고한 피드백 루프에는 네 가지 구성 요소가 들어간다.
- 데이터 수집·라벨링 자동화 파이프라인: 최신 서비스 데이터를 자동으로 끌어오고, 라벨링도 가능한 한 자동화해야 한다. 이게 수동이면 루프 속도가 확 떨어진다. 준지도 학습이나 크라우드소싱을 섞으면 라벨링 비용을 줄이면서 속도를 높이는 게 현실적이다.
- 모델 모니터링 시스템: 정확도, 정밀도, 재현율 같은 성능 지표와 입력 데이터의 분포 변화를 실시간으로 봐야 한다. 특정 임계값을 넘으면 자동 알림이 뜨는 구조가 필요하다. 사람이 매일 대시보드를 들여다보는 구조는 지속이 안 된다.
- 재학습·배포 파이프라인: 이상 징후가 잡히거나 정기 업데이트 주기가 오면, 새 데이터로 재학습하고 배포까지 자동으로 이어져야 한다. 여기서 CI/CD/CT (Continuous Integration/Continuous Delivery/Continuous Training) 개념이 들어온다. 개발자들한테 익숙한 CI/CD에 Continuous Training을 더한 개념이다.
- HITL 전략: 어떤 상황에서 사람이 개입할지 명확히 정해야 한다. 모델 예측 신뢰도가 일정 수준 이하일 때, 특정 오류 유형이 반복될 때, 결과의 파급력이 클 때 — 이런 케이스를 미리 정의해두지 않으면 HITL은 형식으로 끝난다.
실전에서 쓰는 지속 학습 전략
구성 요소를 갖추는 것과 실제로 잘 굴리는 건 다른 얘기다. 각 항목별로 보자.
- 데이터 드리프트 감지:
- 통계적 방법: 학습 데이터와 서비스 데이터의 평균, 표준편차, 분포를 비교한다. Kullback-Leibler Divergence(KL 발산)나 Jensen-Shannon Divergence(JS 발산) 같은 지표를 쓴다. 숫자가 튀면 드리프트 신호다.
- 머신러닝 기반 감지: 학습 데이터와 서비스 데이터를 구분하는 이진 분류 모델을 따로 만들어서, 이 모델이 잘 구분할수록 드리프트가 심한 것으로 본다. 좀 돌아가는 방법이지만 실전에서 꽤 쓴다.
- 온라인 학습 vs. 오프라인 재학습:
- 온라인 학습: 실시간으로 들어오는 데이터를 바로 학습해 파라미터를 업데이트한다. 변화에 빠르게 반응하는 대신 학습 안정성 문제가 생길 여지가 있고 검증이 어렵다. 사기 탐지나 추천 시스템처럼 빠른 반응이 생명인 곳에 적합하다.
- 오프라인 재학습: 일정 기간 데이터를 모아 배치(batch)로 다시 학습시킨다. 안정적이고 검증하기 쉬운 게 장점. 대신 변화에 대한 반응이 느리다. 대부분의 예측 모델에 이 방식을 쓴다. 두 방식을 조합하는 하이브리드 접근도 있다.
- RLHF의 역할: LLM 쪽에서 성공적으로 자리 잡은 RLHF (Reinforcement Learning from Human Feedback)는 인간의 선호도·평가를 보상 신호로 삼아 모델을 미세 조정하는 방법이다. 단순히 정답을 맞히는 것을 넘어, 사람이 선호하는 방식으로 작동하게 모델을 ‘정렬(alignment)’시키는 데 효과적이다.
- 버전 관리·모델 거버넌스: 재학습된 모델도 새 버전이다. 버전별 성능, 사용 데이터, 학습 파라미터를 기록해야 한다. 문제가 터졌을 때 이전 버전으로 롤백하는 체계도 필수다. 이걸 안 해두면 나중에 어느 버전이 문제였는지부터 찾느라 시간을 날린다.
MLOps 없이는 지속 학습도 없다
지속 학습 시스템을 제대로 돌리려면 MLOps (Machine Learning Operations) 도입이 사실상 필수다. ML 모델의 개발→배포→운영→재학습 전 과정을 자동화하고 표준화하는 방법론이다. 없으면 팀원이 손으로 하나씩 챙기게 되고, 그러면 어디선가 구멍이 난다.
- MLOps의 핵심: 개발부터 배포, 모니터링, 재학습까지 복잡한 워크플로우를 효율적으로 관리해 팀 생산성을 높이고 모델 안정성을 확보한다. 문제가 생겼을 때 어디서 터진 건지 추적하기도 훨씬 쉬워진다.
- 쓸 만한 MLOps 도구들: Kubeflow, MLflow, AWS Sagemaker, GCP Vertex AI가 대표적이다. 데이터 파이프라인, 모델 레지스트리, 실험 추적, 배포, 모니터링을 한 곳에서 다룰 수 있게 해준다. 오픈소스 진입장벽이 낮은 쪽은 MLflow, 클라우드 의존도를 높이고 싶다면 Sagemaker나 Vertex AI가 무난하다.
- 인프라: Docker로 컨테이너화하고, Kubernetes로 오케스트레이션하는 조합이 지금은 사실상 표준이다. 확장성과 유연성을 둘 다 챙기려면 이 구조가 현실적이다.
지속 학습 시스템 셀프 점검 5가지
시스템을 구축하기 전, 또는 구축 중에 아래 항목을 체크해봐야 한다.
- 초기 모델 설계 단계부터 피드백 루프를 고려했나? 나중에 붙이려 하면 구조가 안 맞는 경우가 많다. 처음부터 어떤 피드백을 어떻게 반영할지 설계에 넣어야 한다.
- 데이터 파이프라인이 자동화되어 있고 안정적인가? 양질의 데이터가 꾸준히 들어오지 않으면 피드백 루프는 빈 껍데기다.
- 모니터링 지표가 비즈니스 목표와 연결되어 있나? 정확도 숫자만 보는 게 아니라, 실제 매출이나 전환율 같은 지표와 연동해야 이 모델이 진짜 문제가 있다는 걸 설득력 있게 보여줄 수 있다.
- HITL 프로세스가 현실적으로 운영 가능한가? 전문가 시간을 너무 많이 갈아 넣는 구조면 지속이 안 된다. 신뢰도 낮은 케이스, 오류 반복 케이스처럼 범위를 좁혀서 효율을 높여야 한다.
- 작게 시작하고 있나? 한 번에 전체 시스템을 바꾸려다 망하는 케이스가 많다. 작은 실험으로 검증하고 점진적으로 확장하는 방식이 실패 확률을 줄인다.
AI 모델은 배포가 끝이 아니다. 오히려 배포 이후가 더 긴 싸움이다. 드리프트는 피할 수 없고, 피드백 루프 없이는 모델이 서서히 가치를 잃는다. 지속 학습을 제대로 세팅해두는 팀이, 그렇지 않은 팀보다 1년 후 훨씬 다른 위치에 서 있게 된다.
출처: Wired
