자동화 시스템은 인계받는 날 끝나는 것이 아니라 그날부터 시작됩니다. 입력 데이터는 변하고, 거래처는 서식을 바꾸고, AI 모델은 업데이트되고, 연동된 외부 서비스는 정책을 바꿉니다. 완성도 높은 시스템도 이 변화에 대응하지 않으면 서서히, 때로는 조용히 성능이 내려갑니다. 이 글은 구축 업체에게 시스템을 인계받은 회사가 유지보수를 어떻게 체계화해야 하는지, 인계 시점부터 순서대로 정리했습니다.
인계 시점 · 받을 것을 다 받았는지 확인하라
유지보수의 절반은 인계 품질에서 결정됩니다. 확인할 목록은 다음과 같습니다. 소스코드 전체와 배포 방법, 운영 매뉴얼, LLM을 쓰는 시스템이라면 프롬프트 문서, 계정과 API 키의 소유권, 그리고 장애 시 어디를 먼저 봐야 하는지 적은 대응 가이드입니다. 특히 계정 소유권은 놓치기 쉽습니다. API 키·서버·도메인이 업체 명의로 남아 있으면, 업체와 관계가 끝나는 순간 시스템 전체가 인질이 됩니다. 저희가 소스코드·사용설명서까지 인계 범위에 포함해 전달하는 것도 이 때문입니다. 인계 문서의 품질을 시험하는 방법은 간단합니다. 개발에 참여하지 않은 사람이 문서만 보고 시스템을 재시작할 수 있으면 합격입니다.
운영 체계 · 1차 대응은 내부, 수리는 계약으로
인계 후 가장 먼저 정할 것은 '누가 무엇까지 하는가'입니다. 현실적인 분담은 이렇습니다. 내부 담당자 한 명을 지정해 일상 확인과 1차 대응(재시작, 알림 확인, 오류 건 수동 처리)을 맡기고, 코드 수정이 필요한 문제는 구축 업체나 외부 개발자와의 유지보수 채널로 넘깁니다. 내부 담당자는 개발자일 필요가 없습니다. 시스템이 무엇을 하는 물건인지 알고, 이상할 때 이상하다고 판단할 수 있는 실무자면 됩니다. 중요한 것은 이 역할을 공식화하는 것입니다. '아무나 보다가 이상하면 말한다'는 체계는 아무도 안 보는 체계와 같습니다.
- 매일 · 처리 건수와 오류 알림 확인. 평소와 다른 숫자(급감, 0건, 오류 급증)가 이상 신호다
- 매주 · '확인 필요'로 넘어온 건들의 유형 검토. 같은 유형이 반복되면 규칙 보완 대상이다
- 매월 · 자동 처리율·정확도 지표를 도입 시점 수치와 비교. API 비용·서버비도 함께 점검한다
- 분기 · 처리 범위 재검토. 업무가 바뀌었는데 시스템이 옛 업무를 자동화하고 있지 않은지 확인한다
성능 저하의 신호를 아는 법
자동화 시스템의 고장은 멈추는 것만이 아닙니다. 더 흔한 것은 서서히 나빠지는 것입니다. 거래처 한 곳이 서식을 바꾸면 그 거래처 건만 계속 '확인 필요'로 빠지고, 문의 유형이 달라지면 자동 응답률이 조금씩 내려갑니다. 이 저하를 잡으려면 기준선이 필요합니다. 도입 시점의 지표, 예를 들어 자동 처리율이나 응답 정확도를 기록해 두고 매월 비교하는 것입니다. 기준선 대비 하락이 이어지면 원인은 대개 셋 중 하나입니다. 입력 데이터의 변화, 연동 시스템의 변경, 모델 업데이트. 원인별로 대응 주체가 다르므로, 지표 하락을 발견한 시점에 '무엇이 바뀌었는가'부터 좁혀 들어가야 합니다. 특히 LLM 기반 시스템이라면 모델 업데이트가 고유 변수입니다. 같은 프롬프트라도 모델이 바뀌면 출력이 달라질 수 있습니다. 대비책은 구축 단계에서 만들어 둔 평가셋입니다. 모델이나 프롬프트를 바꿀 때마다 평가셋을 돌려 품질이 유지되는지 확인하고, 통과했을 때만 운영에 반영합니다. 인계받을 때 평가셋과 실행 방법이 포함되어 있는지 확인해야 하는 이유입니다.
유지보수 계약, 어떤 형태가 맞나
| 형태 | 적합한 경우 | 주의할 점 |
|---|---|---|
| 건별 요청 | 변경이 드물고 시스템이 단순한 경우 | 긴급 장애 시 대응 속도를 보장받기 어렵다 |
| 월 정액 유지보수 | 업무 핵심 시스템, 정기 개선이 필요한 경우 | 범위(시간·항목)를 계약서에 명시해야 한다 |
| 내부 이관 | 내부에 개발 인력이 생긴 경우 | 인계 문서·평가셋 없이는 이관이 안 된다 |
형태 선택의 기준은 시스템이 멈췄을 때의 손실 크기입니다. 하루 멈추면 업무가 마비되는 시스템이라면 대응 시간이 보장되는 정액 계약이 맞고, 며칠 수동으로 버틸 수 있는 시스템이라면 건별 요청으로 충분할 수 있습니다. 어느 형태든 '누가, 몇 시간 안에, 무엇까지 대응하는가'가 문서로 남아 있어야 계약이라 부를 수 있습니다.
체크리스트 · 인계 직후 일주일 안에 할 일
- 소스코드·문서·프롬프트·평가셋·계정 소유권 인수 확인
- 내부 1차 대응 담당자 지정과 장애 연락 체계 합의
- 도입 시점 지표(자동 처리율·정확도·처리 건수)를 기준선으로 기록
- 장애 알림이 실제로 오는지 테스트 (일부러 실패 상황을 만들어 확인)
- 유지보수 계약의 범위·대응 시간 문서화
자동화의 성과는 구축이 아니라 운영 기간에 쌓입니다. 건당 15분 걸리던 일이 자동화됐다는 성과도, 시스템이 2년째 안정적으로 돌아갈 때 비로소 완성되는 이야기입니다. Plan AI는 구축 후 소스코드와 문서 전체를 인계하고, 인계 이후의 운영 체계까지 위 기준으로 함께 설계합니다. 이미 운영 중인 자동화 시스템의 유지보수가 고민이라면, 현재 상태를 남겨주세요. 1영업일 내 검토 회신드립니다.