AI 기능을 납품했는데 왜 3개월 후에 고장 나는가

한줄 요약

AI 기능은 배포 이후에도 살아 움직이기 때문에, 납품 시점에 지표와 모니터링 구조를 함께 설계해야 한다.

AI 기능이 포함된 프로덕트는 납품 후 몇 달이 지나면 클라이언트에게서 이런 연락이 온다. "코드는 그대로인데 챗봇이 이상한 답을 한다." 외주 개발을 의뢰하는 클라이언트도, 그 의뢰를 받는 개발사도 이 현상에 대비하지 못하면 불필요한 분쟁이 생긴다. AI 기능은 일반 소프트웨어와 달리 배포 후에도 성능이 바뀐다. 이 전제를 납품 설계에 반영하지 않으면, 잘 만든 기능도 시간이 지나면서 조용히 무너진다.

기존 납품 방식으로 AI 프로젝트를 판단하면 생기는 문제

일반적인 소프트웨어 외주 개발에서는 기능이 동작하면 납품이 완료된다. 버그가 없고, 스펙대로 움직이고, 테스트를 통과하면 끝이다. 그런데 AI 기능은 이 기준이 그대로 적용되지 않는다.

예를 들어 사내 문서 기반 질의응답 AI를 개발해서 납품했다고 하자. 납품 당일에는 정확도가 높고 응답도 빠르다. 그런데 두 달 후, 모델 제공사가 내부적으로 모델을 업데이트하거나 클라이언트가 문서를 추가하거나 사용자 질문 패턴이 바뀌면서 품질이 서서히 저하된다. 코드는 한 줄도 안 바뀌었지만 사용자 경험은 나빠진 상태다.

클라이언트는 "개발사가 잘못 만든 것 아니냐"고 생각하고, 개발사는 "납품한 코드에는 문제없다"고 한다. 이 갈등은 처음부터 AI 기능의 특성을 계약과 설계에 반영하지 않았기 때문에 생긴다.

납품 전에 지표를 먼저 정의해야 한다

AI 프로젝트에서는 "무엇을 만들 것인가"만큼 "무엇으로 잘 동작하고 있음을 판단할 것인가"가 중요하다. 이 기준을 개발 전에 클라이언트와 합의해두지 않으면, 납품 후 품질 분쟁을 막을 방법이 없다.

AI 기능에서 필요한 지표는 크게 세 가지 영역으로 나뉜다.

첫째는 모델 품질 지표다. AI가 사실과 다른 답을 내놓는 비율(환각률), 출처 문서에 기반한 답변을 생성하는 비율(근거 충실도), 사용자 질문 의도에 맞는 답변 비율(답변 적합도) 등이 여기에 속한다. 이 지표들은 "기능이 동작하는가"가 아니라 "기능이 제대로 동작하는가"를 보여준다.

둘째는 비용 지표다. AI 기능은 쓸수록 토큰 비용이 발생한다. 요청 한 건당 평균 비용, 일·월 누적 비용, 예상 대비 실제 비용 편차를 추적하지 않으면 클라이언트의 월별 API 청구금액이 예산을 초과하는 사태가 발생한다.

셋째는 사용자 행동 지표다. 사용자가 AI 답변을 그대로 수용하는 비율, 같은 질문을 반복하는 비율, 세션 중간에 이탈하는 비율 등이다. 이 숫자들은 "사용자가 AI를 실제로 믿고 쓰는가"를 반영한다. 정확도가 높아도 사용자가 매번 답을 의심하고 재질문한다면 그 기능은 실질적으로 실패한 것이다.

개발사가 설계해야 할 4개 모니터링 레이어

지표를 정의했다면, 그 지표를 지속적으로 추적하는 구조도 함께 만들어야 한다. 하나의 대시보드로 AI 기능을 전부 모니터링하는 건 불가능하다. 각 영역이 독립적으로 문제를 일으키기 때문이다.

인프라 레이어에서는 API 응답 시간과 오류율을 본다. 여기서 중요한 건 평균값이 아니라 상위 5% 느린 케이스(P95)를 측정하는 것이다. 느린 응답을 경험한 소수의 사용자가 "이 AI 느리다"는 인식을 만들기 때문이다.

비용 레이어에서는 세션 단위, 기능 단위로 비용을 쪼개서 본다. 전체 비용이 갑자기 올랐을 때 "왜 올랐는지"를 추적하려면 이렇게 분해된 구조가 필요하다.

품질 레이어는 가장 다루기 어렵다. 기술적 오류는 로그에 잡히지만, AI가 그럴듯하게 틀린 답을 내놓는 경우는 자동으로 감지되지 않는다. 자동화 평가 도구와 샘플링 기반 사람 검수를 병행해야 한다.

사용자 경험 레이어에서는 명시적 피드백(좋아요/싫어요)과 함께 암묵적 행동 신호를 포착한다. 동일 질문 반복, 세션 이탈 패턴이 여기서 드러난다.

---

이 네 레이어가 독립적으로 움직이기 때문에, 개발사는 납품 전에 각 레이어별 알림 기준과 대응 절차를 클라이언트와 함께 문서화해두는 것이 좋다. 알림만 있고 대응 절차가 없으면 그 알림은 노이즈가 된다.

납품 후 3개월이 지나면 시스템 프롬프트가 부풀어 있다

AI 기능 운영에서 개발사와 클라이언트 모두가 자주 놓치는 문제가 있다. 처음에는 간결하게 작성된 시스템 프롬프트가 시간이 지나면서 예외 처리와 추가 지시를 덧붙이다 보니 수천 단어짜리 문서로 커지는 현상이다.

이렇게 되면 비용이 늘고, 응답이 느려지며, 모델이 너무 많은 지시 사이에서 혼란을 겪어 엉뚱한 답을 내놓기 시작한다. 코드는 그대로인데 품질이 떨어지는 원인 중 하나가 바로 이것이다.

개발사 입장에서는 유지보수 계약에 "시스템 프롬프트 정기 점검"을 포함시키는 것이 현실적이다. AI 기능이 있는 프로젝트에서 유지보수를 단순 버그 수정 범위로만 설정하면, 이런 운영상 문제를 다루기 위한 별도 협의가 계속 필요해진다.

AI 프로젝트 수주 시 클라이언트에게 먼저 물어야 할 것

AI 기능을 포함한 외주 개발 프로젝트를 수주할 때, 개발사가 기획 단계에서 클라이언트에게 확인해야 할 것이 있다.

성공 기준을 구체적인 지표로 표현할 수 있는가. "잘 동작하는 AI 챗봇"이 아니라 "환각률 5% 이하, 평균 응답 시간 2초 이내, 월 비용 00만 원 이내"처럼 수치로 정의되어야 한다. 이 기준이 없으면 납품 후 품질 판단을 둘러싼 갈등을 피하기 어렵다.

AI 기능의 출력 결과물이 비즈니스 프로세스 어디에 연결되는가도 확인해야 한다. AI가 답을 내놓더라도 사용자가 그 답을 기반으로 실제로 행동을 바꾸지 않으면 임팩트는 없다. 개발사는 기능을 납품하는 것이 목적이지만, 클라이언트의 목적은 AI 기능이 실제 비즈니스 결과로 이어지는 것이다. 이 차이를 초기에 정렬해두어야 한다.

납품 후 모니터링과 대응을 누가 담당할 것인가도 계약 전에 확정해야 한다. AI 기능은 배포 후에도 운전대를 잡고 있는 사람이 필요하다. 그 역할을 개발사가 맡을 것인지, 클라이언트 내부 담당자가 맡을 것인지, 아니면 별도 유지보수 계약을 통해 구조화할 것인지를 명확히 해두지 않으면 3개월 후에 아무도 운전대를 잡고 있지 않은 상황이 된다.