이중화와 백업은 서로 다른 문제를 해결합니다
서버 이중화는 한 구성 요소에 문제가 생겼을 때 다른 환경으로 업무를 이어갈 수 있도록 준비하는 것입니다. 백업은 데이터나 설정을 이전 시점으로 복원할 자료를 확보하는 것입니다. 서버가 두 대라는 사실만으로 데이터 손상이나 잘못된 삭제까지 복구할 수 있는 것은 아닙니다.
같은 잘못된 변경이 복제 환경에도 반영될 수 있으므로, 복제와 과거 시점 복구를 구분해서 확인해야 합니다. 백업도 파일이 있다는 사실보다 실제로 복원하고 기록을 대조한 결과가 중요합니다. AWS의 재해 복구 문서도 복구 전략과 정기 검증을 함께 다룹니다.
복구 시간과 복구할 데이터 시점을 나누세요
복구 시간 목표(RTO)는 중단 후 얼마 안에 서비스를 복구하려는지를 뜻합니다. 복구 시점 목표(RPO)는 어느 시점까지의 데이터를 복구해야 하는지, 허용할 데이터 손실의 시간 범위를 뜻합니다. 두 목표는 같지 않으며 백업 주기만으로 실제 복구 시간을 알 수 없습니다.
가상의 복구 목표 예시
복구 시간을 2시간으로 정하고 데이터 복구 시점을 장애 직전 15분 이내로 정했다면, “2시간 내 복구”와 “최대 15분의 데이터 차이”를 별도로 검증해야 합니다. 이는 용어를 설명하는 예시이며 베스트솔루션의 보장 수치가 아닙니다.
복원 후에는 로그인만 확인하지 말고 주요 기록, 설정, 외부 연결과 마지막 변경분을 대조하세요. 업무별 허용 범위가 다르면 핵심 기능의 우선 복구 순서도 정해야 합니다.
가동률 숫자에는 측정 범위가 필요합니다
| 설명 문구 | 추가로 확인할 질문 |
|---|---|
| 가동률 보장 | 어떤 기능을 어떤 주기로 측정하고 계획 점검은 어떻게 계산하나요? |
| 자동 전환 | 어떤 장애에서 전환하고 데이터 동기화·복귀는 어떻게 확인하나요? |
| 디도스 방어 | 보호 범위, 제한 조건, 공격 중 연락·대응 절차는 무엇인가요? |
| 24시간 지원 | 접수 가능 시간인가요, 기술 담당자가 실제 대응하는 시간인가요? |
| 빠른 복구 | 목표 시간, 측정 시작·종료와 최근 점검 결과를 확인할 수 있나요? |
외부 게임·데이터 공급사의 중단과 자체 플랫폼 중단은 원인도 책임도 다릅니다. 지원 약정(SLA)을 검토한다면 포함·제외 항목, 측정 방식과 보고 절차를 확인해야 숫자의 의미를 비교할 수 있습니다.
장애 연락에는 확인 가능한 사실을 담으세요
“안 됩니다”라는 메시지보다 발생 시각, 영향을 받은 화면·기능, 요청 식별자와 관찰한 상태를 전달하면 진단 범위를 좁힐 수 있습니다. 비밀번호나 인증 키 대신 민감 정보를 가린 오류 화면과 관련 기록을 준비하세요.
담당자가 바뀌어도 연락이 이어지도록 접수 창구, 긴급 연락 기준, 진행 공유 방법과 최종 보고 담당자를 정하세요. 복구 후에는 원인, 영향 범위, 조치, 재발 방지 항목과 남은 과제를 나눠 기록하는 것이 좋습니다. 문의를 접수했다는 답과 문제가 해결됐다는 답도 구분해야 합니다.
복구 기준을 확인할 공식 자료
문서에서 제시하는 구조는 검토를 위한 참고입니다. 실제 인프라 구성, 보호 서비스와 지원 약정은 선택한 환경과 계약 조건에서 확인하세요.