사업 연속성

회사가 작을 때는 사고가 나면 그때 모여서 해결합니다. 서버가 멈추면 아는 사람이 붙어 고치고, 고쳐지면 그날은 그걸로 끝납니다. 이 방식은 사고의 크기보다 사고가 난 시각에 좌우됩니다. 평일 오후 3시에 난 장애와 토요일 새벽 4시에 난 장애는 같은 장애인데도 복구까지 걸리는 시간이 몇 배씩 차이 납니다.

그래서 이런 새벽이 반복됩니다. 데이터가 날아간 걸 알아챈 사람이 단체 대화방에 글을 올리고, 백업이 언제 것인지 아무도 확답하지 못하고, 담당자에게 전화를 돌리는 동안 30분이 지나갑니다. 다음 날 사후 정리를 하면서 나오는 말은 대개 같습니다. 백업은 있었는데 어디까지 되살릴 수 있는지를 아무도 확인해 본 적이 없었다는 것입니다.

사업 연속성은 이 판단을 사고 전으로 옮겨 놓은 것입니다. 무엇이 멈추면 안 되는지, 몇 시간 안에 되살릴 것인지, 그러려면 평소에 무엇을 갖춰 둬야 하는지를 미리 정해 문서로 남깁니다. 새벽 4시에 필요한 것은 똑똑한 판단이 아니라 이미 정해져 있는 순서라는 전제가 깔려 있습니다. 기업 고객이 생기면 이 문서는 선택이 아니게 됩니다. 계약 전 보안 검토서에 복구 목표 시간을 적는 칸이 있기 때문입니다.

준비는 네 단계로 돕니다.

1. 멈추면 안 되는 것을 고릅니다. 페이지덱으로 치면 문서를 읽고 쓰는 기능이 여기 들어가고, 사용량 통계 화면은 하루쯤 안 되어도 사업이 멈추지는 않습니다. 전부를 지키려 들면 아무것도 못 지킵니다.
2. 고른 것마다 두 숫자를 정합니다. 몇 시간 안에 되살릴 것인가가 복구 목표 시간이고, 최대 몇 분 치의 데이터까지 잃어도 되는가가 데이터 손실 허용 범위입니다. 문서 편집 기능은 복구 4시간에 손실 15분, 통계 화면은 복구 48시간에 손실 24시간 하는 식으로 기능마다 다르게 잡습니다.
3. 그 숫자가 요구하는 수단을 갖춥니다. 두 숫자가 정해지면 수단은 따라옵니다. 손실 15분을 지키려면 백업을 15분마다 받아야 하고, 복구 4시간을 지키려면 백업 파일을 다시 올리는 데 걸리는 시간을 재 봐야 하며, 그 작업을 할 사람이 새벽에도 연락되도록 온콜 당번을 둬야 합니다. 온콜은 정해진 시간에 장애 연락을 받기로 한 당번입니다.
4. 실제로 꺼 보고 고칩니다. 분기에 한 번쯤 예비 환경으로 넘겨 보고 걸린 시간을 잽니다. 문서에 4시간이라 적혀 있는데 재 보니 11시간이 나왔다면, 고칠 것은 대비이거나 문서에 적힌 숫자입니다. 해 보지 않은 계획은 희망에 가깝습니다.

이 네 단계가 겨냥하는 것은 대개 단일 장애점입니다. 그것 하나가 멈추면 전체가 멈추는 지점을 말합니다. 서버가 한 대뿐인 것도, 결제 연동을 한 회사에만 맡긴 것도, 배포 권한을 가진 사람이 한 명뿐인 것도 모두 같은 모양입니다. 연속성을 갖춘다는 것은 대체로 이 지점들을 찾아 둘로 늘리는 일입니다.

이 말이 실제로 오가는 자리는 셋입니다.

1. 기업 고객과의 계약 — 보안 검토서와 SLA를 쓰는 자리에서 나옵니다. SLA 는 고객과 계약으로 약속한 서비스 수준으로, 월 가동률 99.9퍼센트 같은 숫자를 담습니다. 99.9퍼센트는 한 달에 43분까지만 멈춰도 된다는 뜻이라, 복구에 네 시간이 걸리는 체계로는 지킬 수 없는 약속입니다. 영업이 부른 숫자와 준비된 체계가 어긋나는 일이 계약 검토에서 자주 드러납니다.
2. 투자 실사 — 투자자가 회사의 위험을 훑을 때 묻습니다. 핵심 인물이 빠지면 어떻게 되는지, 주요 시스템이 멈추면 며칠 만에 돌아오는지가 확인 대상입니다.
3. 회사 안의 운영 — 인시던트가 났을 때 펴는 문서로 쓰입니다. 인시던트는 서비스에 영향을 준 사고를 가리킵니다. 사고가 끝나면 포스트모템에서 원인과 고칠 점을 정리하는데, 그 결과가 다시 이 문서로 들어옵니다.

클라우드를 쓰면 저절로 해결되지는 않습니다. 빌려 쓰는 쪽은 여러 지역에 나눠 둘 선택지를 줄 뿐이고, 나눠 둘지와 얼마를 더 낼지는 회사가 정합니다.

"이번 보안 검토서에 복구 목표 시간 쓰는 칸이 있는데, 우리 숫자가 뭐죠?"

고객이 계약 전에 요구하는 항목인데 회사가 정해 둔 값이 없는 상황입니다.

"백업은 매일 받고 있는데, 되살려 본 적은 없어요."

준비물은 있지만 복구 시간이 검증되지 않았다는 뜻입니다.

"이건 연속성 문제예요. 그 사람만 접근 권한을 갖고 있잖아요."

한 사람에게 몰린 권한을 단일 장애점으로 지목하는 말입니다.

페이지덱이 처음 이 문서를 쓴 것은 기업 고객 계약 때문이었습니다. 수아가 보안 검토서를 받아 왔는데 복구 목표 시간과 데이터 손실 허용 범위를 적는 칸이 비어 있었고, 태오에게 물으니 "백업은 매일 새벽에 받는데 되살리는 데 얼마나 걸리는지는 안 재 봤다" 는 답이 돌아왔습니다. 그 주에 실제로 재 봤더니 9시간이 나왔습니다.

규원은 이 숫자를 보고 둘을 정했습니다. 문서 편집 기능만 복구 4시간을 목표로 잡고 나머지는 하루로 두는 것, 그리고 백업 주기를 하루에서 15분으로 당기는 것입니다. 전부를 4시간에 맞추려면 예비 환경을 통째로 하나 더 굴려야 해서 비용이 감당되지 않았습니다. 무엇을 지키지 않을지까지 정한 덕에 이 문서가 실제로 쓰이게 됐습니다.

백업이 있으면 연속성이 갖춰졌다고 보는 경우가 가장 많습니다. 데이터가 남아 있으면 복구는 시간문제라고 생각하기 쉽습니다. 하지만 연속성이 답해야 하는 질문은 데이터가 있느냐가 아니라 언제까지 돌아오느냐입니다. 매일 백업을 받고 있어도 그것을 되살리는 데 하루가 걸린다면 하루짜리 정지를 감수하겠다고 선언한 것과 같고, 대부분의 회사는 그 사실을 실제로 꺼 보기 전까지 모릅니다. 되살려 본 적 없는 백업은 압축이 깨진 채로 몇 달을 지나기도 합니다.

두 번째는 이것을 엔지니어링 팀의 일로 미루는 것입니다. 복구와 백업이라는 말이 기술처럼 들리니 자연스러운 오해입니다. 그런데 무엇을 먼저 되살릴지, 얼마까지 비용을 쓸지, 멈춘 동안 고객에게 뭐라고 알릴지는 기술 판단이 아닙니다. 개발자가 대신 정하면 기술적으로 가장 깔끔한 순서가 나오는데, 그 순서가 사업에서 가장 아픈 순서와 같다는 보장이 없습니다. 정지 상황의 고객 응대를 누가 맡을지가 비어 있는 문서도 흔합니다.