개발 완료 뒤 유지보수 계약과 인수인계에서 합의해야 할 서비스 기준

개발 완료일에 소스와 매뉴얼만 넘기면 유지보수가 시작되는 것이 아닙니다. 운영자가 장애를 발견하고, 누구에게 어떤 시간 안에 알리며, 어떤 결과를 복구로 인정할지 합의되어 있어야 다음 날부터 업무가 이어집니다. 유지보수 계약과 인수인계 문서에는 기능 목록보다 서비스 기준, 증거 위치, 실패 시 복구 경로를 먼저 적어야 합니다.

이 글에서 말하는 계약은 법률 문구의 해석이 아니라 운영 기준을 맞추는 실무 문서입니다. Google SRE는 서비스 수준을 측정하는 SLI, 목표인 SLO, 목표 미달 시 결과를 포함하는 SLA를 구분하며, 측정 방법이 합의되어야 분쟁을 줄일 수 있다고 설명합니다.SLI·SLO·SLA 구분과 측정 원칙을 기준으로 삼되, 실제 숫자는 서비스의 사용자 영향과 복구 비용에 맞춰 정합니다.

먼저 서비스의 정상 상태를 한 문장으로 고정합니다

“서비스가 운영된다”는 표현만으로는 계약 기준이 되지 않습니다. 사용자가 어떤 업무를 성공적으로 마치면 정상인지, 그 결과를 어느 화면·로그·보고서에서 확인하는지 한 문장으로 적습니다. 예를 들어 “영업일 09시부터 18시까지 고객이 문의를 등록하면 접수 번호를 받고 담당자 큐에 1분 안에 표시된다”처럼 대상, 시간대, 성공 결과, 관찰 위치를 함께 적어야 합니다.

이 문장은 계약의 범위를 좁히는 경계이기도 합니다. 정기 점검 시간, 외부 결제사나 문자 발송사의 장애, 고객이 제공하지 않은 필수 정보처럼 서비스 제공자가 통제할 수 없는 조건은 별도 예외로 표시합니다. 예외를 숨기면 나중에 모든 실패가 같은 책임으로 묶이고, 반대로 예외를 너무 넓히면 기준이 사라집니다.

계약서에는 측정 가능한 지표와 측정 창을 적습니다

지표 이름만 쓰면 서로 다른 대시보드를 보고도 충족했다고 말할 수 있습니다. 지표의 분모와 분자, 측정 위치, 집계 주기, 제외 조건, 보고서 책임자를 한 줄씩 정의합니다. 평균 응답 시간만 보면 일부 사용자의 긴 지연이 감춰질 수 있으므로, 사용자 영향이 큰 서비스는 성공률과 오류율, 백분위 지연처럼 서로 다른 관점을 함께 검토하는 편이 낫습니다.

• 가용성: 정상 요청 중 성공으로 인정할 요청의 정의와 측정 위치

• 응답성: 첫 바이트 또는 업무 완료까지의 시간과 백분위 기준

• 정확성: 성공 응답뿐 아니라 저장·전달된 결과가 맞는지 확인하는 방법

• 보고: 측정 주기, 보고서 위치, 검토 회의 참석자와 보관 기간

SLO를 정할 때는 달성률만 높게 잡지 말고 실제로 행동을 바꿀 수 있는 수준인지 확인합니다. 목표가 지나치게 엄격하면 운영자가 매번 긴급 작업으로 숫자만 지키게 되고, 지나치게 느슨하면 사용자가 겪는 문제를 놓칩니다. 계약에는 지표가 목표에 미달했을 때 어떤 알림, 원인 분석, 개선 회의를 시작하는지도 연결해 둡니다.

대응 기준은 심각도와 시각을 분리해 합의합니다

“장애 발생 즉시 대응”은 누구도 같은 뜻으로 읽지 않습니다. 사용자 영향과 업무 중단 범위로 심각도를 정하고, 각 등급에 첫 응답 시간, 우회책 제시 시간, 복구 목표 시간, 정기 업데이트 주기를 배정합니다. 첫 응답은 문제를 해결했다는 뜻이 아니라 접수 사실과 담당자, 다음 업데이트 시각을 알리는 행위로 정의하면 운영자가 지킬 수 있는 약속이 됩니다.

1. P1: 핵심 업무가 전면 중단된 경우. 비상 연락망으로 즉시 알리고, 우회 또는 복구 진행을 정해진 간격으로 공유합니다.

2. P2: 일부 사용자나 주요 기능에 영향이 있는 경우. 영향 범위를 확인한 뒤 업무 시간 안에 임시 조치와 원인 분석 일정을 제시합니다.

3. P3: 문의나 경미한 오류처럼 업무가 계속되는 경우. 재현 정보와 처리 예정일을 티켓에 남기고 정기 배포에 포함합니다.

인수인계 산출물은 역할별로 다시 실행할 수 있어야 합니다

인수인계 파일을 많이 주는 것보다 담당자가 같은 결과를 다시 만들 수 있는지가 중요합니다. 운영 매뉴얼에는 정상 작업, 대표 예외, 권한 요청, 로그 검색, 재처리, 배포와 롤백 순서를 넣고 각각의 마지막 성공 상태를 적습니다. 개발 담당자의 기억이나 개인 메신저를 유일한 절차로 남기지 않아야 담당자가 바뀌어도 대응이 이어집니다.

다음 산출물은 계약의 기준과 같은 용어를 사용해야 합니다. 서비스 목록과 의존성 지도는 범위를 보여 주고, 연락망은 업무 시간과 비상 시간의 책임자를 나누며, 런북은 실패 입력과 복구 명령을 단계별로 설명합니다. 대시보드 링크, 알림 규칙, 백업 위치, 접근 권한 승인 기록도 함께 연결하면 인수받은 사람이 문서를 찾아 헤매지 않습니다.

• 서비스 카드: 목적, 정상 상태, 담당자, 의존 서비스, 측정 지표

• 런북: 증상, 확인 순서, 안전한 재시도, 롤백 조건, 완료 확인 방법

• 변경 기록: 배포 일시, 변경 범위, 영향, 검증 결과, 되돌릴 버전

• 권한·비밀정보 기록: 권한 요청 경로와 교체 절차만 남기고 실제 비밀값은 저장하지 않음

복구 목표는 숫자와 리허설 기록으로 검증합니다

복구 기준에는 서비스 중단 시간과 데이터 손실 범위를 따로 적습니다. NIST의 연속성 계획 가이드에서 RTO는 자원을 사용할 수 없는 상태를 허용할 수 있는 최대 시간이고, RPO는 장애 뒤 복구해야 하는 데이터의 기준 시점입니다.RTO·RPO 정의와 계획 표를 업무 중요도별로 나누면 “언젠가 복구” 같은 모호한 약속을 피할 수 있습니다. 예를 들어 문의 데이터는 4시간 이내 복구하고 최근 1시간 이내 접수분까지 보존한다는 식으로 씁니다.

백업 성공 알림만으로 RTO와 RPO를 충족했다고 판단하면 안 됩니다. AWS Well-Architected는 백업을 실제 위치에 복원한 뒤 데이터를 조회하고 무결성을 확인하며, 복원 시작부터 검증 완료까지의 시간을 측정하라고 안내합니다.주기적인 복구 테스트 절차를 월별 또는 변경 이후에 실행하고 결과를 인수인계 기록에 붙입니다.

가상 사례: 문의 자동화 서비스의 계약 부속표 만들기

예시의 입력은 평일 오전에 홈페이지 문의가 등록되었지만 담당자 큐에 나타나지 않고 고객 알림도 발송되지 않은 상황입니다. 정상 상태는 문의 번호 생성, 큐 표시, 알림 발송이며, 영향은 신규 문의 누락 가능성입니다. 먼저 접수 API 로그와 큐 처리량을 확인하고 P1이 아닌 P2로 분류합니다. 고객이 이미 문의를 제출했을 가능성이 있어 원본 데이터 확인 없이 재전송하지 않는다는 결정도 함께 남깁니다.

결정의 중간 산출물은 아래와 같은 한 장짜리 서비스 기준표입니다. 수치는 가상 사례의 운영 가정이며, 실제 계약에서는 현재 측정값과 사용자 영향으로 다시 합의해야 합니다.

대상: 문의 접수
정상: 접수 번호·큐 표시·고객 알림
P2 첫 응답: 30분 이내 / 우회책: 관리자 수동 배정
복구 목표: 4시간 이내 / 데이터 기준: 최근 1시간 접수분
증거: 요청 ID, 큐 건수 대조표, 알림 발송 결과, 담당자 확인 시각
완료: 테스트 문의 3건이 중복 없이 큐와 알림에 반영됨

예상 결과는 담당자가 30분 안에 접수 사실과 다음 업데이트 시각을 알리고, 수동 배정으로 업무를 우회한 뒤 큐 처리 오류를 복구하는 것입니다. 복구 후에는 요청 ID 목록과 큐 건수, 고객 알림 결과를 서로 대조합니다. 세 건의 테스트 문의가 한 번씩만 처리되고 담당자가 같은 결과를 재현하면 이 사례의 검증 증거가 완성됩니다.

실패 경로와 계약의 한계를 문서에 남깁니다

가장 위험한 실패는 알림은 왔지만 무엇을 재시도해야 하는지 모르는 경우입니다. 자동 재시도가 중복 알림이나 중복 등록을 만들 수 있다면 재시도를 멈추고 원본 상태를 확인하는 수동 절차로 전환합니다. 외부 문자 서비스가 계속 실패하면 고객 알림만 우회하고 내부 접수는 보존하는 식으로 기능을 분리합니다. 운영자는 실패한 대상을 별도 목록에 남기고, 담당자와 다음 확인 시각을 지정해야 합니다.

반대로 서비스 제공자가 통제하지 못하는 외부 장애까지 동일한 복구 시간을 약속하는 것은 좋은 기준이 아닙니다. 외부 의존성의 상태 페이지와 장애 연락처, 우회 가능한 수동 작업, 고객 안내 책임을 별도로 적고, 내부 시스템이 정상이어도 외부 결과가 지연될 수 있다는 경계를 표시합니다. 기준을 지키지 못한 사실을 숨기지 말고 영향, 임시 조치, 재발 방지 작업, 재검토일을 기록합니다.

• 실패 원인이 확인되지 않았으면 성공으로 닫지 않고 관찰 중 상태로 둡니다.

• 복구 명령이 데이터 손실이나 중복을 만들 수 있으면 실행 전 승인자를 지정합니다.

• 동일한 오류가 반복되면 재시도 횟수를 늘리지 말고 원인 분석과 계약 기준 재검토로 에스컬레이션합니다.

완료 조건은 제3자의 재현과 기록으로 판정합니다

유지보수 계약과 인수인계의 검토는 문서 서명이나 회의 종료로 끝내지 않습니다. 인수받는 담당자가 권한을 부여받고, 정상 입력 하나와 대표 실패 하나를 런북대로 실행하며, 알림과 로그를 찾아 대응 시간을 측정해야 합니다. 복구 테스트 결과에는 시작 시각, 완료 시각, 데이터 대조 결과, 미해결 위험, 다음 담당자를 함께 남깁니다.

1. 서비스 범위와 정상 상태가 계약·서비스 카드·런북에서 같은 표현으로 일치하는지 확인합니다.

2. 심각도별 첫 응답, 업데이트, 복구 목표와 측정 창을 실제 알림 기록으로 확인합니다.

3. 인수받는 사람이 정상·실패 입력을 재현하고, 재시도 또는 롤백 뒤 결과를 대조합니다.

4. 미충족 항목은 담당자와 기한을 가진 미완료 목록으로 남기고, 다음 검토일을 지정합니다.

완료 기준은 “제3자가 같은 입력을 재현하고, 정해진 대응·복구 목표 안에서 결과와 잔여 위험을 기록했다”로 두면 관찰할 수 있습니다. 이 기록이 없다면 인수인계는 아직 완료가 아니며, 계약 기준을 다시 합의하거나 추가 리허설을 예약해야 합니다.