앱 외주개발 장애 대응: 영향·복구·공지·결정권을 나누는 5가지 기준

앱 외주개발 장애 대응: 영향·복구·공지·결정권을 나누는 5가지 기준

직접 답변: 앱 외주개발 중 문제가 생겼을 때는 알림 신호, 실제 사용자 영향, 복구 작업, 대외·내부 공지, 변경 승인권을 한 가지 “장애 처리 완료” 상태로 묶지 않는 편이 안전합니다. 각 상태의 담당자와 확인 근거를 짧은 기록으로 나눠 두면, 외주사와 발주사가 동시에 추측으로 움직이는 일을 줄일 수 있습니다.

외주개발 운영 전환에서는 오류 알림 하나가 곧바로 심각도나 원인을 뜻한다고 보기 쉽습니다. 그러나 Google SRE의 장애 관리 안내는 대응을 조정·소통·통제의 문제로 설명하고, 역할과 작업·소통 채널을 분명히 두는 방식을 제시합니다. 이 글은 특정 장애 등급이나 복구 시간을 약속하는 계약 문서가 아니라, 초기 앱 팀이 확인 가능한 사실과 결정권을 분리해 적는 운영 틀입니다.

먼저 ‘관찰 신호’와 ‘사용자 영향’을 구분합니다

모니터링 알림, 고객 문의, 스토어 리뷰, 외주사의 보고는 모두 조사 시작점이 될 수 있습니다. 다만 하나의 신호만으로 어느 기능이 얼마나 실패했는지, 어떤 사용자가 영향을 받았는지, 같은 원인인지까지 확정할 수는 없습니다. 관찰 시각과 출처, 아직 확인하지 못한 범위를 함께 적습니다.

영향을 적을 때는 “로그인이 안 된다” 같은 증상과, 실제로 확인한 화면·기기·버전·조건을 나눕니다. 결제·가입·예약처럼 핵심 흐름인지, 대체 경로가 있는지, 데이터 손상이나 보안 문제가 의심되는지도 별도 질문으로 둡니다. 숫자가 보이지 않으면 영향 인원이나 손실을 추정해 공지하지 않습니다.

기준 1: 등급은 라벨이 아니라 행동 순서를 정하는 기준입니다

장애 등급은 누가 먼저 확인하고, 어떤 채널을 열며, 어떤 변경을 잠시 멈출지를 맞추기 위한 약속입니다. Google Cloud의 운영 가이드는 서로 다른 심각도의 사건을 어떻게 분류하고 대응하느냐가 운영에 영향을 준다고 설명합니다. 따라서 등급표에는 이름보다 발동 기준과 첫 행동을 적는 편이 실무적입니다.

예를 들어 팀 내부의 초안 기준은 핵심 사용자 흐름의 확인된 실패, 데이터·보안 우려, 우회 가능 여부, 영향을 확인한 시간으로 구성할 수 있습니다. 이는 일반적인 기록 예시일 뿐이며, 특정 앱의 계약상 SLA나 고객 영향도를 대신 판정하지 않습니다. 확인 전에는 “고등급 확정”보다 “조사 중, 다음 확인 시각”이 더 정확한 상태일 수 있습니다.

기준 2: 기술 복구와 대응 지휘를 분리합니다

Google SRE는 Incident Commander, Communications Lead, Operations Lead처럼 서로 다른 역할을 소개합니다. 이 구조를 작은 팀에 그대로 복제할 필요는 없지만, “누가 시스템을 바꾸는가”와 “누가 전체 상황·우선순위를 정하는가”를 한 사람의 채팅 메시지에 묶지 않는 원칙은 적용할 수 있습니다.

외주사 개발자는 코드·인프라를 조사하고 완화안을 제시할 수 있습니다. 발주사 또는 서비스 책임자는 사용자가 겪는 영향, 사업상 우선순위, 공지 문구, 배포·되돌리기 승인 범위를 확인할 수 있습니다. 역할을 겸할 수는 있어도, 역할 이름과 현재 담당자를 사건 기록에 남겨야 교대나 추가 투입 때 정보가 사라지지 않습니다.

외주개발 장애 대응의 역할·기록·승인 흐름을 함께 점검하기

기준 3: 공지는 확인된 사실과 다음 갱신 시각으로 씁니다

소통 담당자는 원인이나 해결 시점을 대신 확정하는 사람이 아닙니다. 현재 확인한 증상, 영향을 확인 중인 범위, 사용자가 취할 수 있는 안전한 대체 행동, 다음 업데이트 예정 시각을 구분합니다. 원인이 불명확할 때는 “완전히 복구됐다”보다 검증 중인 상태를 정확히 남깁니다.

외주 계약서나 운영 연락망에는 고객 공지 권한, 내부 의사결정자, 야간 연락 수단, 개인정보가 포함될 수 있는 로그 공유 경로를 별도로 정합니다. 실제 고객의 이름·연락처·계정 정보는 이 공개 글이나 공유 범위가 넓은 사건 요약에 넣지 않습니다. 공지가 게시된 사실도 기술 복구 증거와는 다릅니다.

기준 4: 배포·되돌리기·확인을 세 개의 상태로 남깁니다

수정 커밋이 준비된 것, 테스트 환경에서 확인한 것, 운영에 배포한 것, 되돌리기를 실행한 것은 서로 다른 기록입니다. 되돌리기가 가능한지와 실제로 되돌려졌는지도 분리해 확인합니다. GitHub의 저장소 역할 문서는 필요한 기능과 작업에 맞는 권한을 부여하고, 필요 이상 권한을 주지 않는 원칙을 설명합니다.

그래서 사건 기록에는 변경 제안자, 검토·승인자, 실제 실행자, 실행 시각, 확인한 사용자 흐름을 나눠 둡니다. 외주사에 배포 권한이 있더라도 고객 공지나 사업 우선순위 결정까지 자동으로 위임됐다고 가정하지 않습니다. 반대로 발주사가 승인했다고 해서 기술 검증이 끝났다고 볼 수도 없습니다.

기준 5: 종료 선언과 사후 학습을 구분합니다

Google SRE의 사후검토 가이드는 영향 평가, 원인 분석, 후속 조치 검토 같은 항목을 제시합니다. 작은 MVP에서도 종료 선언 전에는 영향을 받던 핵심 흐름을 어떤 조건에서 다시 확인했는지 남기는 편이 좋습니다. 경고가 줄었어도 트래픽·버전·관찰 기간이 다르면 효과를 단정하기 어렵습니다.

종료 뒤에는 원인을 단정하기 전에 확인된 사실, 아직 남은 불확실성, 후속 소유자와 기한을 나눠 회고합니다. 운영 인수인계 전반의 접근·승인 경계는 앱 외주개발 운영 전환: 배포 승인·환경값·되돌리기를 나누는 5가지 기준에서도 이어서 확인할 수 있습니다. 이 글의 기록 양식은 장애 재발 방지나 특정 복구 결과를 보장하지 않습니다.

외주개발 장애 대응 체크리스트

• 관찰 신호의 시각·출처와 확인하지 못한 범위를 적었는가?

• 사용자 영향, 원인 가설, 복구 작업을 서로 다른 항목으로 남겼는가?

• 현재 대응 지휘·기술 복구·소통 담당자가 누구인지 확인했는가?

• 배포·되돌리기 권한과 실제 승인 기록을 구분했는가?

• 종료 전 핵심 흐름을 어떤 조건에서 재확인했는가?

자주 묻는 질문

알림이 왔으면 바로 장애 등급을 확정해도 되나요?

아닙니다. 알림은 조사할 신호입니다. 사용자 영향 범위, 핵심 기능의 실제 실패, 대체 경로와 확인 시각을 기록한 뒤 팀의 기준으로 대응 우선순위를 결정하세요.

외주사가 복구 작업을 하면 발주사는 공지에 관여하지 않아도 되나요?

그렇지 않습니다. 기술 복구와 이해관계자 공지는 역할이 다릅니다. 누가 사실을 확인하고, 누가 고객·내부 담당자에게 무엇을 언제 알릴지 사전에 분리해 둬야 합니다.

배포를 되돌렸다면 장애가 끝난 것인가요?

되돌리기는 완화 조치일 수 있습니다. 영향을 받던 핵심 흐름이 실제로 복구됐는지, 추가 변경을 누가 승인하는지, 후속 확인이 무엇인지를 별도로 기록해야 합니다.

장애 등급표를 만들면 모든 상황에 같은 조치를 적용해야 하나요?

아닙니다. 등급표는 대화를 시작하는 공통 기준입니다. 서비스의 실제 영향, 안전 문제, 계약상 연락 체계와 당시의 확인 가능한 사실을 함께 검토해야 합니다.

앱 외주개발의 장애 대응 기준과 인수인계 범위를 정리하기

출처

• Google SRE — Incident Management Guide

• Google Cloud Architecture Center — Manage incidents and problems

• GitHub Docs — Repository roles for an organization