AI 시스템 유지보수: 출시 후에 무엇이 고장 나는가

AI 시스템을 개발하는 것은 항상 맞춤형 이야기이며, 무언가가 고장 날 수 있는 지점이 많이 있습니다. 그렇기 때문에 개발 후에는—직접 하든 팀에 의뢰하든—진정으로 일정 기간 유지보수가 필요합니다. 우리가 아키텍처에서 가정했던 것과 실제 현실에서 일어나는 것은 완전히 다른 문제입니다. 세심한 모니터링, 버그 수정 및 추가 개발 없이는 빌드가 매우 자주 쓸모없는 짐이 됩니다. 이 단계는 절대 건너뛸 수 없습니다.

그렇다면 첫 몇 달 동안 실제로 무엇이 고장 날까요? 거의 항상 같은 것들입니다.

데이터 드리프트(Data drifts). 시스템은 특정 가격 목록, 일정 및 문서에 따라 작업을 수행하도록 학습했지만—이러한 것들은 자신만의 삶을 계속 살아갑니다. 인보이스 형식이 변경되거나, 공급업체 사이트의 섹션이 이동하여, 당신의 로직 일부가 이제 눈먼 상태로 작동하게 됩니다.

Component repair in a workshop

외부 종속성(External dependencies)이 아무도 모르게 변경됩니다. 모델이 업데이트되어 약간 다르게 답변하기 시작합니다. 플랫폼 API가 버전을 변경하거나 속도 제한을 조정합니다. 당신은 아무것도 하지 않았는데—시스템의 동작은 이미 달라져 있습니다.

사람들이 시스템을 당신이 가정한 방식과 다르게 사용합니다. 테스트는 깔끔하고 정돈된 요청을 가졌지만; 실제 생활에는 오타, 미완성 문구, 계획에 없었던 질문들이 있습니다. 이 모든 것이 테스트가 결코 보지 못했던 바로 그 지점에 도달합니다.

비즈니스가 변경됩니다. 새로운 서비스, 새로운 규칙, 새로운 프로세스입니다. 이전 방식에 맞춰 조립된 로직은 조용히 맞지 않게 되고—문제가 생길 때까지 아무도 알아차리지 못합니다.

이 모든 것이 시스템이 잘못 구축되었다는 것을 의미하지 않습니다. 이것은 맞춤형 개발의 정상적인 속성입니다: 시스템은 현실 안에 살고 있고, 현실은 멈춰 있지 않기 때문입니다. 출시하고 잊어버리는 것은 토스터에만 통하는 방식입니다.

그렇기 때문에 유지보수는 선택적인 보험 정책이 아닙니다. 그것은 시스템 자체의 일부입니다. 실제 데이터에서 어떻게 작동하는지 관찰하고, 사용자가 알아차리기 전에 버그를 잡고, 데이터와 프로세스가 변경됨에 따라 로직을 일치하게 유지하는 것입니다. 이것 없이는 장기간 운영되는 시스템은 시들해집니다. 처음에는 눈에 띄지 않다가 나중에는 명백히 드러나게 됩니다.

System monitoring dashboard

만약 AI 시스템을 출시한다면—자신이 만든 것이든 맞춤 제작한 것이든—유지보수를 나중에 기억할 선택 사항이 아니라 개발 단계의 일부로 처음부터 계획해야 합니다. 저의 지원과 발전은 바로 이 이유 때문에 매월 주기로 진행됩니다. 한 달간의 실제 작업 경험은 출시 전 어떤 인수 테스트보다 더 많은 것을 알려줍니다. 이 단계는 결코 건너뛸 수 없습니다. 이것 없이는 개발 자체가 무거운 짐이 됩니다.