배포한 AI 모델, 현장에서 버전이 꼬이기 전에 — 모델·데이터·프롬프트 3축 버전 관리

현장에서 AI를 한 번 배포하고 나면, 진짜 일은 그때부터 시작됩니다. 모델이 좋아졌다고 업데이트했는데 불량 판정이 늘거나, 예전에는 잘 되던 케이스가 갑자기 틀리기 시작하는 일. 원인을 찾으려 보면 모델 파일은 있는데, 그 모델이 어떤 데이터로 학습됐는지, 어떤 프롬프트·규칙과 함께 돌았는지 아무도 모릅니다. 7년차 현장 엔지니어로서, 현장 AI의 실패는 대부분 모델 성능이 아니라 "버전이 꼬인" 데서 시작된다고 봅니다.

 

모델만 버전 관리하면 반쪽짜리다

보통 버전 관리는 모델 파일 이름에 날짜나 v1.2 같은 숫자를 붙이는 데서 멈춥니다. 하지만 현장에서 돌아가는 AI는 모델 하나가 아닙니다. 학습 데이터셋의 버전, 전처리 규칙, 프롬프트, 그리고 모델 뒤에 붙은 규칙 레이어까지 합쳐져 하나의 "판정"을 만듭니다. 그중 하나만 바뀌어도 결과는 달라집니다. 그래서 저는 모델·데이터·프롬프트(규칙 포함)를 하나의 묶음으로 묶어 같은 버전 번호를 매깁니다. 어느 하나가 바뀌면 묶음 전체의 버전이 올라갑니다. 이렇게 해야 "어제까지 잘 되던 판정이 오늘 왜 달라졌나"라는 질문에 답할 수 있습니다.

 

롤백은 실패한 뒤에 고민하는 게 아니다

두 번째 원칙은 롤백 버튼을 배포 전에 만들어두는 것입니다. 새 버전을 현장에 올릴 때는 이전 버전을 바로 옆에 대기시켜두고, 판정 품질 지표가 기준 아래로 떨어지면 자동으로 이전 버전으로 돌아가게 합니다. 현장에서는 모델을 고치는 시간보다 라인을 세우지 않는 시간이 더 비쌉니다. "새 모델이 틀렸다"는 걸 인정하고 5분 만에 되돌릴 수 있는 구조가, 사실은 가장 빠른 개선입니다. 이전 글에서 다룬 재현성(https://developer-archive.tistory.com/125)과 규칙 레이어(https://developer-archive.tistory.com/140)가 바로 이 롤백의 전제 조건입니다. 재현되지 않는 모델은 되돌릴 수도 없습니다.

 

현장에서 바로 쓰는 버전 관리 3가지 습관

첫째, 배포할 때마다 "모델 버전 + 데이터 버전 + 프롬프트 버전" 세 줄을 배포 기록에 남깁니다. 엑셀 한 줄이면 충분합니다. 둘째, 현장에서 들어온 피드백(틀린 판정 사례)은 반드시 해당 버전 번호와 함께 기록합니다. 버전 없는 피드백은 나중에 어느 모델의 문제인지 알 수 없습니다. 셋째, 한 번에 하나씩만 바꿉니다. 모델과 프롬프트를 동시에 바꾸면 좋아진 이유도, 나빠진 이유도 알 수 없습니다.

 

그래서 뭘 하면 되나 — 오늘 당장, 현장에서 돌고 있는 AI의 "지금 버전"을 세 줄로 적어보세요. 모델 파일명, 학습 데이터 날짜, 프롬프트·규칙 버전. 이 세 줄이 안 적힌다면, 그 AI는 이미 버전이 꼬이기 시작한 상태입니다.