AWS · 클라우드

AWS 재해복구는 어느 수준까지 준비해야 합니까

수준을 먼저 고르는 것이 아니라, 멈춰도 되는 시간과 잃어도 되는 데이터를 먼저 정합니다.

최종 검토 2026-09-18 재해복구RTO RPO복구 전략

이 글의 순서

한눈에 보는 답변

재해복구 수준은 두 숫자가 정합니다. 서비스가 멈춰 있어도 되는 시간(RTO)과, 사고 직전으로부터 잃어도 되는 데이터의 범위(RPO)입니다. 이 둘을 정하면 AWS가 제시하는 네 가지 전략 중 어디에 서야 하는지가 거의 자동으로 좁혀집니다. 백업·복구는 가장 저렴하지만 복구에 시간이 걸리고, 파일럿 라이트와 웜 스탠바이는 일부를 상시로 켜 두어 그 시간을 줄이며, 멀티사이트는 양쪽이 모두 서비스를 받습니다. 중요한 것은 순서입니다. 수준을 먼저 고르고 숫자를 맞추면 대개 과잉이거나 부족하고, 그 사실은 실제 사고가 나기 전까지 드러나지 않습니다.

적합한 경우: 서비스가 멈추면 매출이나 업무가 곧바로 막히고, 지금 준비된 것이 백업뿐인 경우
주의할 경우: 다중 가용 영역(Multi-AZ) 구성을 재해복구로 알고 있는 경우 — 그것은 같은 리전 안의 가용성 장치입니다
핵심 판단 기준: 먼저 RTO와 RPO를 사업 쪽과 합의하십시오. 그 두 숫자 없이는 어느 수준도 과한지 모자란지 판정할 수 없습니다

재해복구 계획을 요구받으면 대개 “어느 수준으로 할까”부터 묻게 됩니다. 그런데 그 질문에는 답이 없습니다. 수준은 고르는 것이 아니라 두 숫자에서 따라 나오는 것이기 때문입니다.

이 글은 그 두 숫자가 무엇인지, AWS가 제시하는 네 가지 전략이 각각 무엇을 상시로 켜 두는지, 그리고 우리 서비스가 어디에 서야 하는지를 판단하는 순서로 정리합니다.

백업, 복구, 재해복구는 서로 다릅니다

세 낱말이 자주 섞여 쓰이는데 가리키는 범위가 다릅니다.

백업 — 데이터의 사본을 다른 곳에 두는 일입니다. 여기까지는 자료의 문제입니다.
복구 — 그 사본으로 데이터를 되돌리는 일입니다. 여기부터 절차의 문제가 됩니다.
재해복구 — 정해진 시간 안에 서비스를 다시 세우는 일입니다. 데이터뿐 아니라 네트워크 구성, 접근 권한, 배포 절차, 그리고 그것을 실행할 사람과 순서가 함께 있어야 성립합니다.

많은 조직이 첫 번째만 갖춘 채 세 번째를 갖췄다고 이해합니다. 백업이 있어도 복구가 안 되는 구조적 이유는 백업은 있는데 왜 복구가 안 되는가에서 따로 다뤘으므로, 이 글은 복구가 된다고 가정한 뒤 어느 속도로 될 것인가에서 시작합니다.

수준을 정하는 두 숫자 — RTO와 RPO

RTO(Recovery Time Objective) — 사고가 난 시점부터 서비스가 다시 정상 동작할 때까지 허용되는 시간입니다. “4시간 안에는 다시 열려야 한다”가 RTO입니다.
RPO(Recovery Point Objective) — 사고 직전으로부터 잃어도 되는 데이터의 범위입니다. “마지막 15분치까지는 잃어도 된다”가 RPO입니다.

두 숫자는 성격이 다릅니다. RTO는 얼마나 빨리 세울 수 있는 구성을 평소에 유지하고 있는가에 달려 있고, RPO는 데이터를 얼마나 자주 다른 곳으로 옮기고 있는가에 달려 있습니다. 그래서 한쪽만 좋게 만드는 것도 가능합니다. 예를 들어 데이터는 실시간으로 복제하면서 애플리케이션을 세우는 절차는 수작업인 구성은 RPO가 짧고 RTO가 깁니다.

두 숫자는 기술 조직이 정하는 값이 아닙니다. 얼마의 손실을 감수할 것인가에 대한 판단이므로 사업 쪽이 정하고, 기술 조직은 그 숫자가 실현 가능한지와 무엇이 필요한지를 답합니다. 그리고 업무별로 나눠 정하는 편이 현실적입니다 — 결제 처리와 사내 게시판에 같은 기준을 걸면 비용이 필요 이상으로 커집니다.

AWS가 제시하는 네 가지 전략

AWS는 재해복구 전략을 네 가지로 나눠 설명합니다. 이 네 가지는 등급이 아니라 상시로 무엇을 켜 두는가의 차이입니다.

전략	평소에 켜 두는 것	RTO 성격	RPO 성격
백업·복구	데이터 사본만	길다 — 사고 후 자원을 만들고 배포한다	백업 주기만큼
파일럿 라이트	데이터 계층 등 시간이 오래 걸리는 부분만	중간 — 나머지를 켜면 된다	복제 방식에 따라 짧아진다
웜 스탠바이	축소된 규모의 전체 구성	짧다 — 규모만 키우면 된다	짧다
멀티사이트 액티브-액티브	양쪽 모두 실제 트래픽을 받는다	가장 짧다	가장 짧다

핵심은 위에서 아래로 갈수록 평소에 쓰지 않는 자원이 늘어난다는 것입니다. 복구 시간과 상시 비용은 맞바꾸는 관계이고, 어느 쪽으로 기울일지를 RTO가 정합니다.

금액은 이 글에서 말하지 않습니다. 구성마다 상시로 켜 두는 자원의 종류와 양이 달라 일반화할 수 있는 수치가 없기 때문입니다. 지금 구성을 기준으로 한 추정이 필요하시면 AWS 비용 분석 · 간편 견적에서 직접 계산해 보실 수 있습니다.

자주 어긋나는 세 가지

다중 가용 영역(Multi-AZ)은 재해복구가 아닙니다

가장 흔한 오해입니다. 다중 가용 영역은 같은 리전 안의 물리적으로 분리된 구역에 이중화해 한 구역의 장애를 견디는 가용성 구성입니다. 재해복구는 리전 단위의 사고나 데이터 자체의 손상처럼 그 범위를 넘는 상황을 다룹니다.

차이가 분명해지는 경우는 데이터가 망가졌을 때입니다. 운영 실수로 테이블을 지웠거나 악성 코드가 파일을 암호화하면, 그 상태가 이중화된 쪽에도 그대로 복제됩니다. 가용성 구성은 복제를 잘 하도록 만들어진 장치라 잘못된 상태도 잘 복제합니다. 되돌리려면 시점을 거슬러 갈 수 있는 백업이 있어야 합니다.

복제와 백업은 다른 물건입니다

같은 이유로, 실시간 복제를 백업의 대체물로 쓰면 안 됩니다. 복제는 지금 상태를 같게 유지하는 장치이고 백업은 과거 어느 시점으로 돌아가게 하는 장치입니다. 사람의 실수와 악성 코드는 후자만 막습니다.

적어 둔 RTO는 훈련 전까지 목표가 아닙니다

문서에 “RTO 4시간”이라고 적는 일과 실제로 4시간 안에 세울 수 있는 일은 다릅니다. 둘 사이의 차이는 대개 사고 당일에 드러납니다. 그래서 복구 훈련을 주기적으로 넣고 걸린 시간을 기록해 정해 둔 값과 대조하는 절차까지가 계획에 들어갑니다. 훈련으로 검증되지 않은 절차서는 사고 당일에 가장 먼저 버려집니다.

어느 수준이 맞는지 정하는 순서

업무를 나눕니다. 전부에 같은 기준을 걸지 않습니다. 멈추면 곧바로 매출이나 법적 의무가 걸리는 업무와, 하루 멈춰도 되는 업무를 먼저 가릅니다.
업무별로 RTO와 RPO를 사업 쪽과 합의합니다. 이 단계가 빠지면 이후의 모든 판단이 근거를 잃습니다.
지금 구성이 그 숫자를 만족하는지 계산합니다. 데이터를 옮기는 주기, 자원을 만드는 데 걸리는 시간, 배포 절차에 사람이 개입하는 지점을 각각 재서 더합니다.
모자란 만큼만 위 표의 위쪽으로 올립니다. 전부를 한 수준으로 맞추지 않습니다.
훈련 주기와 기록 방식을 함께 정합니다. 여기까지가 계획입니다.

3번에서 자주 빠지는 것이 사람이 개입하는 시간입니다. 자동화되지 않은 단계는 담당자가 연락을 받고 자리에 앉기까지의 시간이 함께 붙습니다. 사고는 업무 시간에만 나지 않으므로, 이 시간을 빼고 계산하면 실제보다 낙관적인 숫자가 나옵니다. 장애 대응에서 역할과 기록이 왜 먼저인지는 AWS 장애 대응에 반드시 필요한 역할과 기록에서 다뤘습니다.

어디까지가 우리 몫인가

빌드업웍스의 운영 경험에서는, 재해복구가 비어 있는 경우보다 적어는 뒀는데 검증된 적이 없는 경우가 더 자주 문제가 됩니다. 계획서와 실제 구성이 갈라지는 것은 조용히 일어나고, 그 사실은 훈련하거나 사고가 나야 드러납니다.

운영을 맡는 범위에서는 복구 절차의 유지와 훈련 실행, 그 결과 기록이 포함될 수 있습니다. 다만 어느 수준으로 갈 것인가는 사업 판단이고 그 판단을 대신하지 않습니다. 운영 위탁의 수준을 어떻게 정하는지는 운영을 맡기기로 했다면 어느 수준으로 계약해야 합니까에 정리돼 있습니다.

다음 단계

지금 구성이 어느 수준에 서 있는지부터 확인하시는 것이 순서상 먼저입니다. AWS 무료 점검에서 백업과 복구 구성이 현재 어떤 상태인지 함께 정리해 드립니다.

인프라를 새로 세우거나 옮기는 과정에서 재해복구 수준을 함께 정해야 하는 상황이라면 AWS 구축 · 이전에서 설계 범위를 확인해 보십시오. 우리 업무 기준으로 RTO와 RPO를 어떻게 나눠 잡을지 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

작성 빌드업웍스 기술팀 최초 작성 2026-09-18 최종 검토 2026-09-18

이어서 확인하실 것

서비스AWS 구축 · 이전 — 인프라 설계 범위 서비스AWS 관리 대행 — 운영 범위와 책임 경계 진단AWS 무료 점검 — 지금 구성부터 확인

자주 묻는 질문

백업이 있으면 재해복구가 되는 것 아닙니까?

백업은 재해복구의 재료이지 재해복구 자체가 아닙니다. 재해복구는 사고가 났을 때 정해진 시간 안에 서비스를 다시 세우는 일이고, 그러려면 데이터 말고도 네트워크 구성, 접근 권한, 애플리케이션 배포 절차, 그 절차를 실행할 사람과 순서가 함께 준비돼 있어야 합니다. 데이터만 남아 있고 나머지를 사고 당일에 만들어야 한다면 복구는 가능하되 며칠이 걸릴 수 있습니다. 그 며칠을 감당할 수 있는지가 곧 수준을 가르는 질문입니다.

RTO와 RPO는 누가 정합니까?

기술 조직이 아니라 사업 쪽이 정하고 기술 조직이 실현 가능성을 답하는 순서가 맞습니다. RTO는 서비스가 멈춰 있어도 되는 시간이고 RPO는 사고 직전으로부터 잃어도 되는 데이터의 범위인데, 둘 다 얼마의 손실을 감수할 것인가에 대한 판단이라 기술적으로 결정할 수 있는 값이 아닙니다. 실무에서는 업무별로 나눠 정하는 편이 현실적입니다. 결제와 사내 게시판에 같은 기준을 걸면 비용이 필요 이상으로 커집니다.

다중 가용 영역(Multi-AZ) 구성이면 재해복구가 된 것입니까?

다른 문제를 다루는 장치입니다. 다중 가용 영역은 같은 리전 안의 물리적으로 분리된 구역에 이중화해 한 구역의 장애를 견디는 가용성 구성이고, 재해복구는 리전 단위의 사고나 데이터 손상처럼 그 범위를 넘는 상황을 다룹니다. 예를 들어 운영 실수나 악성 코드로 데이터 자체가 망가지면 이중화된 쪽에도 같은 상태가 복제되므로 가용성 구성으로는 되돌릴 수 없습니다. 두 가지는 함께 두는 것이고 한쪽이 다른 쪽을 대신하지 못합니다.

재해복구 환경은 평소에도 켜 두어야 합니까?

고르신 수준이 그것을 정합니다. 백업·복구 전략은 평소에 데이터만 보관하고 필요할 때 자원을 만들며, 파일럿 라이트는 데이터베이스처럼 시간이 오래 걸리는 부분만 상시로 켜 두고, 웜 스탠바이는 축소된 규모의 전체 구성을 계속 돌립니다. 즉 상시 비용과 복구 시간은 맞바꾸는 관계이고, 어느 쪽으로 기울일지가 RTO에서 나옵니다. 상시로 켜 두는 자원이 늘수록 복구는 빨라지고 평소 비용은 커집니다.

복구가 실제로 되는지는 어떻게 확인합니까?

실제로 복구해 보는 것 말고는 확인할 방법이 없습니다. 백업 작업이 성공으로 표시되는 것과 그 백업으로 서비스가 다시 서는 것은 다른 사실이며, 둘 사이의 차이는 대개 사고 당일에 드러납니다. 그래서 복구 훈련을 주기적으로 넣고, 훈련 때마다 걸린 시간을 기록해 정해 둔 RTO와 대조하는 절차를 함께 둡니다. 훈련 없이 적어 둔 목표 시간은 목표가 아니라 희망입니다.

재해복구 계획을 문서로만 갖고 있어도 됩니까?

문서는 필요하지만 그것만으로는 계획이 서 있다고 보기 어렵습니다. 사고 상황에서는 평소 그 작업을 하던 사람이 자리에 없을 수 있고, 문서에 적힌 절차가 그 사이 바뀐 구성과 어긋나 있는 경우도 흔합니다. 문서는 훈련으로 검증될 때만 살아 있고, 검증되지 않은 절차서는 사고 당일에 가장 먼저 버려집니다.

이 글로 해결되지 않은 것이 있으신가요?

상황을 한 줄로 적어 주시면 관련된 내용을 찾아 드립니다.

이름·연락처·AWS 액세스 키·비밀번호 등 민감정보는 입력하지 마세요.

이런 질문이 많습니다

한 팀에게, 끝까지 맡겨 보세요

개선하고 싶은 업무를 한 줄만 남겨주세요. 무엇을 어떻게 만들 수 있는지 먼저 정리해 알려드립니다.

상담 신청 카카오톡 채널 텔레그램 상담