MSP에 맡겼는데 애플리케이션 장애는 누가 해결할까

문제와 판단 기준

클라우드 운영 대행 계약을 검토하고 있다고 가정해 보겠습니다. 제안서에는 ‘모니터링·장애 대응 포함’이라고 적혀 있습니다. 그런데 주문이 멈췄을 때 서버를 확인하는 일, 잘못된 코드를 수정하는 일, 누락된 주문을 바로잡는 일까지 모두 포함된다는 뜻일까?

애플리케이션 장애를 해결할 담당자는 ‘MSP’라는 이름으로 정해지지 않습니다. 어떤 진단과 수정 작업을 맡겼는지, 누가 변경을 승인하고 실행할 수 있는지를 확인해야 합니다. 인프라 운영만 위탁했다면 코드 수정 담당은 별도로 필요합니다. 애플리케이션 유지보수까지 위탁할 수도 있지만 그때도 데이터 복원 범위나 서비스 재개처럼 사업 판단이 필요한 결정의 승인자는 정해 두어야 합니다.

계약 전에는 두 질문에 답할 수 있어야 합니다. “장애를 끝까지 조율할 사람은 누구인가?”와 “각 시스템을 실제로 고칠 사람은 누구인가?” 연락 창구를 하나로 만드는 것과 모든 수정 작업을 한 업체에 맡기는 것은 다른 선택입니다.

이 글에서 ‘책임’은 업무의 결정·승인·수행 역할을 뜻합니다. 특정 장애의 법적 귀책이나 손해배상 책임을 판정하는 기준은 아닙니다.

CSP의 책임 공유 모델만으로 운영 대행 범위가 정해지지는 않는다

클라우드 서비스 제공자(CSP), 운영 대행사(MSP), 애플리케이션 개발·유지보수 팀을 먼저 구분합니다. 여기에 업무 중단과 재개를 결정할 서비스 소유자, 데이터의 올바른 상태와 복원 범위를 승인할 데이터 소유자, 결제·인증 같은 외부 SaaS 사업자가 참여합니다. 작은 조직에서는 한 사람이 여러 역할을 맡을 수 있습니다.

AWS의 책임 공유 모델은 EC2의 기반 인프라와 고객의 게스트 운영체제·애플리케이션 등 보안 책임을 구분합니다. Google Cloud도 서비스 유형에 따라 책임 경계가 달라진다고 설명합니다. 이 자료들은 보안 책임을 이해하는 출발점입니다. 개별 MSP가 야간에 어떤 코드를 수정할지까지 정해 주는 업무 명세서는 아닙니다.

지원 상품도 별도로 봐야 합니다. AWS Support FAQ는 지원 범위와 함께 사용자 정의 코드 개발·소프트웨어 디버깅이 포함되지 않는다고 명시합니다. 이를 ‘어떤 지원도 받을 수 없다’로 읽을 필요는 없지만 기술 지원 구독을 애플리케이션 유지보수 계약으로 간주해서는 안 됩니다.

가용성 약속은 또 다른 문서입니다. AWS Compute SLA와 Google Compute Engine SLA는 해당 서비스의 가용성 정의, 적용 조건, 크레딧 청구 조건과 제외 사유를 규정합니다. 그 수치를 그대로 고객 웹사이트 전체의 가용성이나 MSP의 복구 시간으로 옮길 수는 없습니다. 공급자의 서비스 약속, 공급자의 기술 지원, MSP의 실제 운영 업무를 각각 확인해야 합니다.

‘24시간 대응’이라는 한 칸을 일곱 칸으로 나누자

아래는 제안 범위를 비교하기 위한 설계 기준입니다. 한 항목의 제공 여부를 다음 항목의 보장으로 읽지 않도록 나눈 것입니다.

자동 티켓 생성은 사람의 접수 증거가 아닙니다. 서버가 다시 응답하는 것도 주문 누락이 해결됐다는 증거는 아닙니다. 반대로 진단을 모두 끝낸 뒤에야 완화를 시작해야 하는 것도 아닙니다. Google SRE의 사고 대응 설명도 조직적인 역할 분담과 함께 피해 완화를 중시합니다.

응답 목표를 읽을 때는 ‘몇 분’ 앞뒤의 조건이 더 중요합니다. Google Cloud 기술 지원 가이드라인은 지원 등급·우선순위별 최초 응답 목표와 지원 시간을 구분합니다. 최초 응답 목표를 문제 해결 기한으로 해석해서는 안 됩니다.

운영 합의에는 감지·신고·통지·접수 중 어느 시점부터 시간을 재는지, 고객 승인이나 외부 업체 답변을 기다리는 시간은 어떻게 보고할지 적어 둡니다. 다른 업체로 이관돼도 사용자가 겪은 전체 중단 시간은 이어서 계산하는 편이 좋습니다. 허용 가능한 중단과 데이터 손실부터 정해야 한다면 RTO·RPO로 복구 수준을 정하는 방법을 먼저 참고할 수 있습니다.

‘DB 장애’가 아니라 수행할 작업으로 책임을 나눈다

다음은 가상의 웹앱 운영 계약을 위한 설계 예시입니다. 실제 업체의 기본 제공 범위나 IXC의 계약 조건이 아닙니다.

웹앱은 VM과 관리형 DB를 사용합니다. MSP는 VM·네트워크 운영과 승인된 배포 절차의 실행을 맡습니다. 개발·유지보수 팀은 코드·쿼리·DB 연결 설정을 담당합니다. 서비스 소유자는 사전에 정한 예산·변경 한도 안의 조치를 위임했다고 가정합니다.

표의 최종 결정·승인은 그 작업을 진행해도 되는지 결정하는 한 주체입니다. 수행은 실제로 조사하거나 변경하는 주체입니다. 협조가 필요하지 않은 칸은 비워 두었습니다. 공급자 내부 작업에 고객의 승인권이 생긴다는 뜻도 아닙니다.

사전 승인 한도를 넘는 증설은 같은 작업으로 취급하지 말고 추가 비용 승인 절차로 넘깁니다. 데이터 손실 가능성이 있는 복원도 단순 서버 재시작과 같은 권한으로 묶지 않습니다.

이렇게 나누면 ‘DB 장애는 누구 책임인가’라는 질문을 더 작게 만들 수 있습니다. 조사할 대상이 DB 엔진 내부인지, 애플리케이션의 연결 관리인지, 쿼리인지, 업무 데이터인지에 따라 필요한 수행자와 승인자가 달라집니다. 직접 설치한 DB라면 엔진 운영 담당도 별도로 지정해야 합니다. 관리형 상품의 공급자 작업 범위는 해당 서비스 정책으로 확인합니다.

CPU가 높다는 이유만으로 원인을 인프라로 확정하지 않는 것도 같은 원칙입니다. 아래 사례에서는 애플리케이션 변경이 연결 문제를 만들었다고 가정합니다. 자원 증설을 실행할 수 있다는 사실과 원인을 수정할 수 있다는 사실을 분리해서 보는 것입니다.

연락 창구는 하나로, 수정 권한은 필요한 곳으로

Google SRE는 사고 지휘자, 소통 담당, 기술 조치 담당의 역할을 구분합니다. 작은 사고에서는 한 사람이 여러 역할을 맡을 수 있지만 지휘와 기술 조치는 구별할 수 있어야 합니다.

이를 여러 업체가 참여하는 운영에 적용한다면, 원인이 아직 불명확한 동안에도 사건 전체를 맡을 지휘자를 정하는 방식이 적합합니다. MSP가 그 역할을 맡을 수도 있고 고객 내부 담당자가 맡을 수도 있습니다. 누구를 선택하든 ‘우리 범위가 아니다’라는 통보만으로 사건 담당자가 사라지지 않게 해야 합니다.

특히 MSP에서 개발팀으로 넘길 때는 수신 담당자의 인수 확인을 남기도록 합의합니다. 장애 증상, 영향, 수행한 조치, 필요한 권한, 다음 안내 시점이 함께 전달돼야 합니다. CSP나 외부 SaaS에 지원을 요청한다면 고객 대신 케이스를 열 수 있는 계정·지원 계약을 확인하고 사건 기록에 외부 티켓 번호와 접수 상태를 연결합니다. 외부 티켓을 만들었다고 내부 사건을 종료하지는 않습니다.

설계 예시 1: 배포 직후 DB 연결이 고갈됐다면

가정: 애플리케이션 배포 뒤 주문 오류가 늘었고, 변경된 연결 관리 코드가 문제를 일으켰습니다. MSP에는 배포 파이프라인 실행 권한이 있지만 임의 코드 수정 권한은 없습니다. 아래 흐름은 실제 사고 기록이 아닙니다.

감지·접수 → 공동 진단 → 롤백 승인 → 실행·검증 → 업무 확인과 후속 수정 인계로 연결합니다.

MSP가 사건을 접수하고 지휘자를 지정합니다. MSP는 자원·네트워크·DB 연결 지표를 확인하고 개발팀은 최근 변경과 애플리케이션 오류를 조사합니다. 처음부터 ‘서버 문제’ 또는 ‘개발 문제’로 단정해 한쪽에만 넘기지 않습니다.

이전 버전으로 되돌리는 것이 적합하다고 판단되면 애플리케이션 기술 책임자가 현재 DB 스키마·설정과의 호환성을 확인하고 롤백을 승인합니다. MSP는 합의된 배포 절차만 실행합니다. 코드 롤백 승인에 DB 전체를 과거 시점으로 덮어쓸 권한까지 포함시키지 않습니다.

승인자가 연락되지 않는 상황도 미리 정해야 합니다. 대체 승인자나 명시된 긴급 위임이 없다면, MSP가 애플리케이션 수정·데이터 변경 권한을 임의로 확대하는 대신 사전에 승인된 완화 조치를 적용하고 에스컬레이션을 이어 가도록 합의합니다.

복구 후 개발팀과 MSP는 핵심 기능을 검증하고 서비스 소유자는 실제 주문 처리와 밀린 작업을 확인합니다. 누락 데이터가 발견되면 데이터 소유자가 정정 범위를 승인합니다. 코드의 근본 수정과 회귀 검증은 개발팀의 후속 작업으로 남깁니다. 사건에는 배포 버전, 승인·실행 시각, 검증 결과, 후속 작업의 수신 담당자를 기록합니다.

설계 예시 2: 외부 결제 API가 응답하지 않는다면

가정: 고객 웹앱에서 결제 요청의 응답이 끊겼습니다. 외부 사업자가 요청을 처리했는지는 아직 모릅니다. 이것도 실제 고객 사례가 아닌 설계 예시입니다.

응답을 못 받았다는 사실과 결제가 실행되지 않았다는 사실을 구분해야 합니다. Stripe의 오류 처리 문서도 네트워크 오류에서는 클라이언트가 서버의 요청 수신 여부를 알 수 없는 상황을 설명합니다. 이는 Stripe의 기술 설명이며 다른 결제사의 조회·재시도 규칙까지 같다는 뜻은 아닙니다.

영향 확인 → 외부 사건 연결 → 영업상 완화 결정 → 거래 결과 확인 → 재처리·업무 재개 승인으로 역할을 나눕니다.

MSP는 자사 측 네트워크와 서버 상태를, 개발팀은 요청 식별자와 애플리케이션 기록을 확인합니다. 외부 서비스 문제를 의심할 근거가 있으면 정해진 담당자가 외부 지원 케이스를 엽니다. 공개 상태 페이지는 참고 자료이지 개별 거래의 성공·실패를 확정하는 자료로 쓰지 않습니다.

신규 주문을 잠시 멈출지, 이미 검증된 다른 결제 경로를 사용할지는 서비스 소유자가 결정합니다. MSP가 외부 플랫폼 내부를 직접 고칠 수 있다는 전제는 두지 않습니다. 외부 사업자에게 복구를 요청하는 일과 고객 웹앱의 피해를 줄이는 일을 병행합니다.

외부 연결이 회복된 뒤에도 모든 요청을 새로 보내지 않습니다. 개발팀이 해당 결제사의 조회·재시도 규칙에 따라 결과를 확인하고 데이터 소유자는 주문과 결제의 불일치를 어떻게 정리할지 승인합니다. 승인된 재처리와 업무 확인을 거쳐 서비스 소유자가 재개를 결정합니다. 종료 기록에는 외부 사건 번호뿐 아니라 결과 미확인 거래와 남은 처리의 담당자도 남깁니다.

제안서에는 작업 목록과 함께 결정 조건을 적는다

위 책임표를 계약·운영 합의에 연결할 때는 ‘장애 대응 포함’ 옆에 아래 항목을 붙여 검토합니다. 표준 계약 조항이 아니라 업무 범위를 구체화하기 위한 질문입니다.

여러 대행사의 제안을 비교할 때는 클라우드 운영 대행 업체 선정 가이드를 함께 보되, 위에서 정한 장애별 수행자와 승인자를 각 제안의 업무 범위에 대입해 보겠습니다. 역할을 정한 뒤 실제 대응 절차를 문서화하는 단계에서는 장애 대응 Runbook 설계에서 대응 절차를 확인합니다.

접근 권한은 별도의 인수 조건으로 다루는 편이 좋습니다. ‘관리자 권한 보유’ 한 줄 대신 필요한 계정·자원·행위·기간과 회수 방법을 확인합니다. 예를 들어 AWS Support Authorization은 지원 케이스에 대해 자원·행위·기간을 제한한 허가를 다룹니다. 이와 같은 구체성을 운영 대행 권한 합의에도 적용하자는 제안이지, 해당 기능이 모든 MSP 계약에 포함된다는 뜻은 아닙니다.

공급자를 바꿀 때의 조건도 시작 전에 정해 둡니다. 계정과 도메인의 관리 주체, 소스·설정·운영 문서·모니터링 설정·백업의 인계 대상, 복원에 필요한 키의 안전한 전달 방법, 라이선스나 재판매 계약 때문에 이전이 제한되는 항목을 구분합니다. 인계 형식·기한·비용과 미종결 사건의 담당자도 필요합니다. 새 담당자가 필요한 접근과 복원 수단을 확인한 뒤 기존 권한을 회수하도록 순서를 합의하는 것이 좋습니다.

어떤 운영 방식이 우리 팀에 맞을까

내부에 인프라와 애플리케이션을 모두 다룰 사람이 있고 필요한 시간대의 대응도 가능하다면, 추가 운영 대행 없이 역할과 권한부터 정리하는 선택이 가능합니다. 이 표를 채우기 위해 새 관리 도구를 도입할 필요도 없습니다. 기존 문서와 사건 관리 도구로 담당자·승인·인계를 추적할 수 있으면 됩니다.

개발팀은 있지만 서버 운영 부담을 줄이고 싶다면 인프라 중심 MSP와 애플리케이션 유지보수를 분리할 수 있습니다. 대신 공통 신고 창구, 공동 진단, 개발팀의 호출 가능 시간, 인수 확인을 운영 합의에 포함합니다. 야간 장애를 받아 주는 사람이 있어도 코드를 고칠 사람은 다음 업무일에만 가능할 수 있다는 점을 구매 단계에서 드러내는 것입니다.

반대로 애플리케이션 유지보수 담당 자체가 없다면 인프라 대행 계약만으로 그 빈자리가 채워진다고 가정하지 말아야 합니다. 유지보수 인수, 코드·배포 경로 정비, 애플리케이션 운영을 포함한 위탁 범위 중 무엇이 필요한지 먼저 판단해야 합니다. 중단을 다음 업무일까지 허용할 수 있는 시스템이라면 상시 인력 대응보다 업무 시간 지원이 적합한지도 함께 검토합니다.

어떤 방식을 택하든 고객 측에는 서비스 중단·재개, 데이터 정정·손실 허용 범위, 추가 비용과 우선순위를 결정할 역할이 남습니다. 결정을 위임할 수는 있지만 누가 어떤 한도까지 대신 결정하는지와 부재 시 대체 승인자는 정해져 있어야 합니다.

계약 전에 가장 중요한 업무 하나를 골라 “지금 멈췄다면”을 대입해 보겠습니다. 접수할 사람, 수정할 사람, 승인할 사람, 업무가 돌아왔음을 확인할 사람을 모두 지정할 수 있는가? 어느 작업의 담당자도 정하지 못했다면, 그 빈칸을 해결하는 것이 업체 이름이나 가용성 숫자를 비교하는 일보다 우선입니다.

현재 시스템의 운영 책임과 지원 범위를 외부와 검토해야 한다면, IXC 문의에 대상 시스템과 맡길 업무, 남길 승인 권한을 정리해 전달할 수 있습니다.