앱·웹 서비스를 출시하기 전에 운영 준비는 무엇부터 하나요?

출시 준비는 남은 기능을 세는 일이 아닙니다

개발이 끝나면 준비도 끝난 것처럼 보이지만, 공개 이후의 일은 사람과 절차가 있어야 돌아갑니다. 출시 전에 정해야 할 것은 네 가지입니다. 누가 배포하는지, 무엇을 보고 이상을 알아차리는지, 누구에게 연락이 가는지, 그리고 언제 고객에게 알리는지입니다.

이 네 가지가 비어 있으면 첫 장애를 고객 문의로 알게 됩니다. 그때부터는 원인을 찾는 일과 응대하는 일을 같은 사람이 동시에 하게 되고, 둘 다 늦어집니다.

배포는 누가 어떤 순서로 하고, 어떻게 되돌리나요?

배포 절차는 문장 몇 줄이면 충분합니다. 누가 실행하는지, 실행 전에 무엇을 확인하는지, 끝난 뒤 어떤 화면을 열어 보는지, 문제가 생기면 어떤 방법으로 이전 버전으로 돌아가는지를 적습니다. 적어 두는 이유는 담당자가 자리에 없을 때 다른 사람이 같은 순서로 할 수 있어야 하기 때문입니다.

되돌리기는 적는 것으로 끝나지 않습니다. 출시 전에 한 번 실제로 되돌려 봐야 데이터가 함께 돌아오지 않는 구간이 드러납니다. 앱은 서버와 다릅니다. 이미 설치된 버전은 즉시 회수되지 않으므로, 서버가 구버전 앱의 요청도 당분간 받아 주는지 확인해 두어야 합니다.

배포 시각도 미리 정해 두십시오. 금요일 저녁이나 담당자가 자리를 비우는 시간에 올리면 문제를 늦게 알게 되고, 되돌릴 사람도 없습니다. 이용이 적은 시간대 가운데 확인할 사람이 앉아 있는 시간을 고르는 편이 안전합니다.

공개 전에 화면에 걸려 있어야 하는 것

기능과 무관하게 법이 요구하는 표시가 있습니다. 「전자상거래 등에서의 소비자보호에 관한 법률」 제10조제1항은 사이버몰 운영자가 상호와 대표자 성명, 영업소가 있는 곳의 주소(소비자의 불만을 처리할 수 있는 곳의 주소를 포함합니다), 전화번호와 전자우편주소, 사업자등록번호, 이용약관을 소비자가 쉽게 알 수 있도록 표시하게 합니다. 같은 법 제12조제1항은 통신판매업자의 신고를, 제13조제1항제3호는 청약을 받을 목적의 표시·광고에 그 신고번호와 신고를 받은 기관의 이름을 포함하도록 정합니다. 다만 거래횟수와 거래규모가 공정거래위원회가 고시로 정하는 기준 이하이면 신고 대상에서 빠집니다.

개인정보를 받는 화면이 하나라도 있으면 처리방침도 함께 걸립니다. 「개인정보 보호법」 제30조제1항은 처리 목적, 처리·보유 기간, 파기 절차와 방법, 정보주체와 법정대리인의 권리·의무와 행사 방법, 개인정보 보호책임자의 성명 또는 담당 부서의 연락처 등을 포함하도록 정하고, 제2항은 정보주체가 쉽게 확인할 수 있도록 공개하게 합니다. 이 항목들은 협의해서 줄이는 대상이 아니므로 개발 마지막 주에 몰지 마시고 화면 목록에 처음부터 넣으십시오.

장애는 무엇을 보고 알아차리나요?

서버가 살아 있는지만 보는 감시로는 부족합니다. 사용자가 끝까지 가지 못하는 상태는 서버가 정상일 때도 생깁니다. 출시 전에 아래 네 가지를 어디에서 볼지 정해 둡니다.

• 오류 응답 비율 — 평소 값을 먼저 기록해 두고, 그보다 올라가면 알림이 오게 합니다.
• 핵심 흐름의 완주 수 — 가입, 결제, 신청처럼 돈과 업무가 걸린 흐름의 하루 완료 건수입니다.
• 외부 연동 실패 건수 — 결제와 알림, 로그인은 우리 서버가 정상이어도 따로 실패합니다.
• 처리되지 않고 남은 건 — 접수는 됐지만 담당자가 아직 손대지 않은 목록입니다.

알림은 사람에게 가야 합니다. 대시보드는 열어 보는 사람이 있을 때만 작동합니다.

장애가 났을 때 연락은 어떤 순서로 가나요?

출시 전에 세 자리를 지정합니다. 알림을 가장 먼저 받는 1차 확인자, 1차 확인자가 판단하지 못할 때 연락할 사람, 그리고 고객 공지를 결정하는 사람입니다. 야간과 주말에 누가 받는지도 같이 적습니다. 외부 개발사가 운영을 맡고 있다면 연락 가능한 시간대와 응답 기준을 계약서에서 확인해 두십시오.

고객 공지 기준도 미리 정합니다. 결제나 신청처럼 돈이 걸린 흐름이 막혔으면 복구 전에 알리고, 조회만 느려졌으면 복구한 뒤 기록으로 남기는 식입니다. 기준이 없으면 공지 여부를 장애 중에 논의하게 되고, 그 논의가 복구보다 오래 걸립니다.

업데이트는 무엇을 보고 결정하나요?

업데이트 시점은 기능 요청이 쌓여서가 아니라 외부 요건과 장애 기록에서 나옵니다. 운영체제와 스토어 요건 변경은 날짜가 정해져 오고(앱 개발의 구성을 다룬 글에서 설명했습니다), 장애 기록은 다음에 고칠 순서를 알려 줍니다. 두 가지를 분기마다 한 번 모아 보면 유지보수 범위를 정할 근거가 생깁니다.

운영 비용도 이 자리에서 함께 봅니다. 서버 사용료와 외부 서비스 사용료, 개발자 프로그램 비용은 어느 계정에서 누가 결제하는지까지 정해 두어야 담당자가 바뀔 때 결제가 끊기지 않습니다.

지금 준비할 한 가지

관측 네 항목 가운데 지금 값을 확인할 수 있는 것이 몇 개인지 세어 보십시오. 하나도 없다면 출시일을 정하기 전에 그 화면부터 만드는 편이 빠릅니다.

네오렉트에 출시·운영 준비를 상담하신다면 위 네 항목과 연락 순서를 적어서 보내 주세요. 비어 있는 칸이 어디인지에 따라 배포 절차부터 정할지, 알림 설정부터 할지가 갈립니다.