AI 프로덕트가 무너지는 이유는 모델이 아니라 멈추는 규칙이 없어서다
이 글은 AI 기능을 이미 만들어봤고 이제 진짜 사용자에게 내보내야 하는 엔지니어와 프로덕트 리더를 위해 씁니다. 얻어갈 결론은 하나입니다. AI 제품이 프로덕션에서 무너지는 진짜 원인은 대개 모델의 품질이 아니라, 언제 멈춰야 하는지를 아무도 미리 정하지 않았다는 사실입니다.
많은 팀이 모델을 더 좋게 만드는 데는 몇 주씩 씁니다. 그런데 그 모델이 나쁜 답을 내놓았을 때 시스템이 어떻게 반응할지는 배포 전날에야 급하게 정합니다. 순서가 뒤바뀌어 있습니다. 좋은 모델은 사고를 줄여주지만 사고를 없애주지는 않습니다. 사고가 났을 때 무엇을 멈추고 무엇을 계속할지 미리 정해두지 않으면, 아무리 정확한 모델도 프로덕션에서는 불안한 시스템일 뿐입니다.
글의 핵심 개념을 형상화했습니다.
좋은 모델이라는 착각이 서비스를 무너뜨린다
팀이 AI 기능을 개발할 때 가장 먼저 던지는 질문은 보통 이 모델이 얼마나 똑똑한가입니다. 벤치마크 점수를 비교하고, 다른 모델로 바꿔보고, 프롬프트를 다듬습니다. 이 과정 자체는 틀리지 않았습니다. 문제는 이 질문에 아무리 잘 답해도 배포 여부를 결정할 수는 없다는 데 있습니다.
모델이 얼마나 똑똑한지와 이 모델이 우리 서비스에 배포해도 되는지는 서로 다른 질문입니다. 후자에 답하려면 먼저 어떤 입력에 어떤 출력이 나와야 하는지, 어떤 종류의 오답은 허용할 수 있고 어떤 오답은 절대 허용할 수 없는지를 사람이 먼저 정해야 합니다. 이 기준이 없으면 어떤 평가 점수가 나와도 해석할 수 없습니다. 구십 퍼센트라는 숫자는 기준이 있을 때만 의미를 갖습니다.
실전에서 자주 보이는 실패 패턴은 이렇습니다. 팀이 모델 두어 개를 비교해 더 나은 쪽을 고릅니다. 정성적으로 몇 가지 사례를 살펴보고 만족스럽다고 판단합니다. 이 판단이 곧 배포 승인이 됩니다. 하지만 이 과정 어디에도 무엇이 실패이고 실패했을 때 어떻게 하겠다는 결정은 들어 있지 않습니다. 배포 이후 첫 장애가 터지고 나서야 그 기준을 급하게 만들게 됩니다.
평가 설계는 개발 작업이 아니라 의사결정 작업입니다. 데이터셋을 무한히 모으는 일이 중요한 게 아니라, 비즈니스 결과에 실제로 영향을 미치는 입력에 먼저 집중하는 일이 중요합니다. 작은 데이터셋이라도 의사결정에 영향을 주는 입력으로 채워져 있다면, 방대하지만 무작위로 모은 데이터셋보다 훨씬 쓸모가 있습니다.
그래서 첫 질문을 바꿔야 합니다. 이 모델이 얼마나 똑똑한가가 아니라, 이 모델이 어떤 조건에서 우리가 감당할 수 없는 실패를 낼 가능성이 있는가로 질문을 시작해야 합니다. 이 질문에 답할 수 있을 때 비로소 다음 단계인 파이프라인과 배포 전략을 설계할 준비가 된 것입니다.
평가는 보고서가 아니라 멈추는 규칙이다
평가 기준을 정했다고 해서 끝난 게 아닙니다. 그 기준이 사람이 매번 읽고 판단하는 보고서로 남아 있다면, 그 기준은 실제로는 존재하지 않는 것과 크게 다르지 않습니다. 사람은 바쁘고, 지치고, 배포 일정에 쫓깁니다. 기준이 사람의 판단에 맡겨지는 순간 그 기준은 압박이 심한 날에 가장 먼저 무너집니다.
평가 파이프라인은 데이터 수집, 기대 출력 정의, 자동 측정, 릴리스 게이트라는 네 단계로 이어져야 합니다. 앞의 세 단계가 아무리 정교해도 마지막 단계인 릴리스 게이트가 자동화되어 있지 않으면 이전 단계의 노력은 절반만 쓰인 셈입니다. 측정 결과가 기준을 밑돌면 배포 파이프라인 자체가 멈춰야 합니다. 사람이 예외로 통과시키는 경로를 열어두는 순간 게이트는 형식으로 전락합니다.
여기서 흔히 저지르는 실수는 측정 지표를 하나로 단순화하는 것입니다. 문자열이 얼마나 정확히 일치하는지만 보면 형식은 맞지만 의미는 완전히 틀린 답을 걸러내지 못합니다. 태스크 성격에 맞는 지표를 골라야 합니다. 분류 문제라면 오답의 방향까지 살펴야 하고, 생성형 응답이라면 정답과의 문자열 일치보다 의미적 관련성이 더 중요할 때가 많습니다.
릴리스 게이트를 설계할 때는 통과 기준만큼이나 실패했을 때의 동작을 명확히 정의해야 합니다. 게이트를 통과하지 못한 모델은 어디로 갑니까. 이전 버전으로 자동 롤백되나요, 아니면 배포가 그냥 보류되나요. 이 답이 없으면 게이트는 경고만 띄우고 아무것도 막지 못하는 장식이 됩니다.
결국 평가의 목적은 좋은 점수를 받는 데 있지 않습니다. 나쁜 배포를 자동으로 막는 데 있습니다. 평가를 보고서로 취급하는 팀과 평가를 게이트로 취급하는 팀은 겉보기에 비슷한 작업을 하지만, 사고가 났을 때 결과는 완전히 달라집니다.
배포는 스위치가 아니라 되돌릴 수 있는 절차다
평가를 통과했다고 해서 모델을 전체 트래픽에 한 번에 내보내는 것은 위험합니다. 평가 데이터셋이 아무리 잘 설계되어 있어도 실제 사용자의 입력 분포를 완벽히 재현하지는 못합니다. 실제 트래픽에서만 드러나는 문제는 언제나 있습니다.
그래서 배포는 스위치를 켜고 끄는 행위가 아니라, 되돌릴 수 있는 절차로 설계해야 합니다. 카나리 배포는 새 모델을 트래픽의 일부에만 먼저 노출하고 문제가 없는지 확인한 뒤 점진적으로 비율을 늘리는 방식입니다. 블루그린 배포는 새 모델을 별도 환경에 전체 배포해두고 이전 환경은 그대로 살려둔 채 트래픽만 전환하는 방식입니다. 두 방식 모두 핵심은 하나입니다. 문제가 생기면 즉시 이전 상태로 돌아갈 수 있어야 한다는 것입니다.
이 되돌리기가 실제로 작동하려면 모델 버전 관리가 선행되어야 합니다. 모델 파일뿐 아니라 그 모델을 만든 설정 값, 그 모델이 통과한 평가 결과, 배포된 시점까지 함께 기록해야 합니다. 이 기록이 없으면 문제가 생겼을 때 어떤 버전으로 되돌려야 안전한지조차 판단할 수 없습니다.
파이프라인 내부도 전처리, 추론, 후처리 세 단계로 나뉘어 있다는 점을 기억해야 합니다. 실패는 이 셋 중 어디에서든 일어날 수 있고, 각 단계마다 실패했을 때의 동작을 미리 정의해두어야 합니다. 전처리에서 입력이 이상하면 추론까지 보내지 말고 그 자리에서 거부하는 편이 낫습니다. 후처리에서 형식이 어긋나면 사용자에게 원본을 그대로 노출하는 대신 안전한 기본값으로 대체해야 합니다.
배포를 절차로 다루는 팀은 사고가 나도 몇 분 안에 이전 상태로 돌아갑니다. 배포를 스위치로 다루는 팀은 사고가 난 뒤에야 되돌릴 방법을 찾기 시작합니다. 그 차이가 장애의 지속 시간을 결정합니다.
실패를 넷으로 나누면 대응이 보인다
AI 시스템은 전통적인 소프트웨어와 다른 방식으로 실패합니다. 코드가 정해진 연산을 그대로 수행하지 않는 경우가 흔하기 때문입니다. 입력의 변주가 크고 모델의 동작 자체가 확률적이라, 같은 입력을 넣어도 다른 시점에는 다른 결과가 나올 수 있습니다.
실패를 네 가지로 나누면 대응이 훨씬 명확해집니다. 첫째는 런타임 오류입니다. 메모리 부족이나 네트워크 중단처럼 추론 자체가 실패하는 경우로, 전통적인 소프트웨어와 같은 방식으로 다루면 됩니다. 재시도, 폴백, 회로 차단기 패턴이 여기에 해당합니다.
둘째는 출력 형식 오류입니다. 모델이 기대한 형식으로 답을 내놓지 않는 경우입니다. 이럴 때는 입력을 다시 처리하거나 다른 추론 경로로 우회하는 편이 낫습니다. 셋째는 품질 저하입니다. 추론은 성공했지만 결과가 사실과 어긋나거나 입력의 의도를 잘못 짚은 경우로, 가장 다루기 까다롭습니다. 형식은 멀쩡하기 때문에 자동으로 걸러내기가 어렵습니다.
넷째는 지연 시간 증가입니다. 평소보다 추론이 갑자기 느려지는 경우로, 서비스 수준 계약을 위반할 수 있어 꾸준히 지켜봐야 합니다. 이 네 가지를 하나의 오류로 뭉뚱그려 처리하면, 재시도해서 해결될 문제에 롤백을 걸거나 롤백이 필요한 문제를 재시도로 넘기는 잘못된 대응이 나옵니다.
| 실패 유형 | 원인 | 우선 대응 |
|---|---|---|
| 런타임 오류 | 메모리 부족, 네트워크 중단 | 재시도, 폴백, 회로 차단기 |
| 출력 형식 오류 | 파싱 실패, 필수 필드 누락 | 재처리 또는 다른 추론 경로 |
| 품질 저하 | 사실과 어긋난 답, 의도 오판 | 사람 검토 또는 안전 기본값 |
| 지연 시간 증가 | 부하 급증, 자원 경합 | 지속 관측, 임계값 알림 |
이 표가 보여주는 것은 하나입니다. 실패의 원인을 정확히 분류할 수 있을 때만 대응도 정확해진다는 사실입니다. 분류를 건너뛰고 모든 실패를 같은 방식으로 처리하는 시스템은 결국 재시도 폭주나 불필요한 롤백처럼 스스로 만든 장애를 낳습니다.
전부 죽거나 전부 사는 시스템은 없다
AI 시스템은 완전히 동작하거나 완전히 멈추거나 둘 중 하나가 아닙니다. 대부분의 실패는 부분적입니다. 여러 모델을 함께 쓰는 시스템이라면 그중 하나가 죽어도 나머지 모델의 결과로 응답을 이어갈 수 있습니다.
이 부분 실패에 대응하려면 설계 단계에서 핵심 기능과 부가 기능을 나눠야 합니다. 검색 서비스에 AI 요약 기능을 얹었다면, 요약이 실패해도 검색 결과 자체는 그대로 보여줘야 합니다. AI 기능의 실패가 핵심 기능까지 끌고 내려가는 구조는 설계 단계의 실수입니다.
이 구분을 미리 해두지 않으면, 장애 대응 중에 어디까지 포기하고 어디는 반드시 지켜야 하는지를 그 순간에 판단해야 합니다. 압박이 심한 순간의 즉흥적인 판단은 대체로 틀립니다. 무엇을 지키고 무엇을 내려놓을지는 평온할 때 미리 정해두는 것이 맞습니다.
부분 실패를 견디는 설계는 비용도 줄여줍니다. 모든 구성 요소를 똑같은 수준으로 견고하게 만들 필요가 없기 때문입니다. 핵심 기능에는 다중화와 빠른 폴백을 투자하고, 부가 기능은 실패했을 때 그냥 조용히 사라지도록 두는 편이 자원을 더 효율적으로 쓰는 길입니다.
게이트에 눈이 없으면 아무것도 못 막는다
지금까지 다룬 평가 게이트, 배포 절차, 실패 분류는 모두 관측이 뒷받침되지 않으면 무력해집니다. 게이트가 아무리 정교해도 그 게이트가 지금 무엇을 보고 있는지 알 수 없다면, 문제가 생겨도 아무도 알아채지 못합니다.
관측해야 할 신호는 세 갈래로 나뉩니다. 시스템 신호는 자원 사용률과 네트워크 지연처럼 인프라 수준에서 잡히는 지표입니다. 모델 신호는 추론 지연 시간, 추론 성공률, 입출력 크기 분포처럼 모델 자체의 동작을 보여줍니다. 비즈니스 신호는 모델 출력이 실제 비즈니스 결과에 미치는 영향을 보여주는데, 응답 이후 사용자 전환율이나 추천 클릭률 같은 지표가 여기에 속합니다.
세 신호 중 하나만 보면 시야가 좁아집니다. 시스템 신호만 보면 인프라는 멀쩡한데 모델이 조용히 나빠지고 있는 상황을 놓칩니다. 비즈니스 신호만 보면 전환율이 떨어졌다는 사실은 알아도 원인이 모델 때문인지 다른 이유인지 구분할 수 없습니다. 세 신호를 함께 봐야 무엇이 왜 나빠지고 있는지 추적할 수 있습니다.
이 관측이 특히 중요한 이유는 모델 드리프트 때문입니다. 배포 시점에는 멀쩡했던 모델도 데이터 분포나 사용 패턴이 바뀌면서 시간이 지나 성능이 떨어질 수 있습니다. 배포 시점의 성능을 기준선으로 잡고, 이후 데이터가 그 기준선에서 유의미하게 벗어나면 알림이 울리도록 만들어야 합니다.
드리프트 감지는 입력 분포의 변화를 보는 데이터 드리프트와 출력 분포의 변화를 보는 예측 드리프트, 두 수준에서 이루어져야 합니다. 데이터 드리프트가 감지되면 수집 파이프라인이나 사용자 행동이 바뀌었다는 신호이고, 예측 드리프트가 감지되면 모델 자체가 낡았다는 신호입니다. 둘을 구분해야 원인을 좁힐 수 있습니다.
결론: 모델보다 먼저 멈추는 법을 설계하라
평가, 배포, 실패 대응, 관측은 서로 다른 네 가지 작업처럼 보이지만 결국 하나의 질문으로 수렴합니다. 언제 멈출 것인가입니다. 평가는 배포 전에 멈출 기준을 정하는 작업이고, 배포 절차는 배포 후에 멈추고 되돌릴 수 있는 경로를 만드는 작업입니다. 실패 분류는 무엇이 멈춰야 할 신호인지 가려내는 작업이고, 관측은 그 신호를 놓치지 않고 감지하는 작업입니다.
모델을 더 똑똑하게 만드는 작업은 여전히 중요합니다. 다만 그 작업이 배포의 안전성을 대신해주지는 못합니다. 아무리 좋은 모델도 언젠가는 예상치 못한 입력을 만나고, 예상치 못한 방식으로 틀립니다. 그 순간에 시스템이 무엇을 하도록 만들어두었는지가 서비스의 신뢰를 결정합니다.
그래서 AI 제품을 준비하는 팀에 제안하고 싶은 순서는 이렇습니다. 모델을 고르기 전에 먼저 멈출 기준을 정하십시오. 배포 버튼을 누르기 전에 되돌릴 절차를 준비하십시오. 장애가 나기 전에 실패를 분류하는 기준을 만들어두십시오. 그리고 이 모든 것이 작동하는지 지켜볼 눈을 먼저 심어두십시오. 이 순서를 지킨 팀은 사고가 나도 몇 분 만에 회복하고, 이 순서를 건너뛴 팀은 사고가 날 때마다 처음부터 다시 배웁니다.
챕터 삽화
