Ⅱ-8. 컴퓨터 시스템 재해복구(DR) 구조와 복구시간 분석

컴퓨터 시스템에서 재해복구(Disaster Recovery, DR)는 서버 한 대의 장애나 단순한 프로그램 오류를 넘어 화재, 침수, 장시간 정전, 네트워크 장애, 저장장치 손실 등으로 주요 시스템의 정상적인 운영이 어려워진 상황에서 서비스를 복구하기 위한 체계이다.

DR은 단순히 백업 데이터를 보관하는 것과 다르다.

실제 재해가 발생했을 때 어떤 환경으로 서비스를 전환할 것인지, 어느 시점의 데이터를 사용할 것인지, 얼마의 시간 안에 서비스를 다시 제공할 것인지를 사전에 설계하고 실제로 검증하는 것이 핵심이다.

1. 재해복구(DR)의 개념

재해복구는 주요 시스템에 장애 또는 재해가 발생했을 때 별도로 준비된 복구환경을 이용하여 시스템과 서비스를 다시 운영할 수 있도록 하는 체계이다.

일반적인 서버 장애가 특정 장비의 문제라면 DR은 다음과 같이 주 시스템 전체의 운영이 어려워지는 상황까지 고려할 수 있다.

• 데이터센터 장애
• 화재 및 침수
• 장시간 정전
• 주요 네트워크 장애
• 저장장치 대규모 손실
• 핵심 시스템 장애
• 주 운영환경의 장기간 사용 불가

따라서 DR을 분석할 때는 특정 장비의 정상 여부보다 중요 서비스 전체가 다른 환경에서 실제로 다시 운영될 수 있는가를 판단해야 한다.

2. 백업과 DR의 차이

백업은 데이터 손실에 대비하여 별도의 데이터 사본을 확보하는 것이 중심이다.

반면 DR은 데이터뿐만 아니라 실제 서비스를 운영하는 데 필요한 서버, 네트워크, 데이터베이스, 애플리케이션, 인증, 접속환경, 운영절차까지 복구 대상으로 포함할 수 있다.

예를 들어 백업 데이터가 정상적으로 보관되어 있어도 다음과 같은 문제가 있다면 서비스 복구가 지연될 수 있다.

• 복구할 서버가 준비되어 있지 않음
• 네트워크 연결이 준비되지 않음
• 데이터베이스 복구 절차가 없음
• 애플리케이션 설치 및 설정이 필요함
• 인증 시스템을 사용할 수 없음
• DNS 또는 서비스 접속경로 변경이 필요함

따라서 백업은 DR을 구성하는 중요한 요소이지만 백업 자체가 DR 전체를 의미하지는 않는다.

3. DR의 주요 구성요소

DR 환경은 일반적으로 다음 요소로 구성된다.

• 복구 대상 시스템
• 복구용 서버
• 데이터 복제 또는 백업 시스템
• 저장장치
• 네트워크 연결
• 데이터베이스
• 애플리케이션
• 인증 시스템
• DNS 및 서비스 접속환경
• 복구 운영절차
• 담당자와 역할
• 복구 테스트 계획

중요한 것은 각각의 구성요소가 존재하는 것만으로 충분하지 않다는 점이다.

실제 전환 과정에서 서로 정상적으로 연결되고 순서에 맞게 작동해야 하나의 DR 체계가 완성된다.

4. DR 사이트의 구성 형태

DR 환경은 복구 준비 수준에 따라 여러 형태로 구성할 수 있다.

콜드 사이트

기본적인 시설과 공간을 확보하고 실제 시스템은 재해 발생 후 설치하거나 구성하는 방식이다.

구축 및 유지에 필요한 비용을 줄일 수 있지만 장애 발생 이후 준비해야 할 작업이 많아 실제 복구시간이 길어질 수 있다.

웜 사이트

일부 서버와 인프라를 미리 준비해 두고 장애 발생 시 추가 작업을 수행하여 서비스를 복구하는 방식이다.

콜드 사이트보다 빠르게 복구할 수 있지만 시스템과 데이터를 일정 수준으로 유지하기 위한 관리가 필요하다.

핫 사이트

주요 시스템과 데이터를 복구환경에 지속적으로 준비하여 장애 발생 시 비교적 빠르게 서비스를 전환할 수 있도록 구성하는 방식이다.

빠른 복구가 필요한 중요 서비스에 적합할 수 있지만 구축 및 운영에 필요한 비용과 관리 부담이 증가할 수 있다.

따라서 사이트 형태는 단순히 가장 빠른 방식을 선택하는 것이 아니라 업무 중요도와 요구되는 RTO에 맞춰 결정해야 한다.

5. RTO와 DR 복구시간

RTO(Recovery Time Objective)는 장애 발생 후 서비스를 복구해야 하는 목표 시간이다.

예를 들어 RTO가 1시간이라면 DR 환경과 복구절차가 실제 장애 상황에서 서비스 복구를 1시간 이내에 완료할 수 있도록 설계되어야 한다.

여기서 중요한 것은 서버가 켜지는 시간만 RTO로 보는 것이 아니라는 점이다.

실제 서비스 복구에는 다음 과정이 필요할 수 있다.

복구환경 준비 → 데이터 복구 → 시스템 활성화 → 네트워크 전환 → 애플리케이션 확인 → 서비스 정상 여부 검증

따라서 RTO는 실제 사용자가 서비스를 다시 이용할 수 있게 되는 시점까지의 목표로 보는 것이 적절하다.

6. RPO와 데이터 복구 지점

RPO(Recovery Point Objective)는 장애 발생 시 어느 시점의 데이터까지 복구할 수 있어야 하는지를 나타내는 목표 기준이다.

예를 들어 RPO가 30분이라면 장애 발생 시 최대 약 30분 정도의 데이터 손실을 허용하는 수준으로 설계할 수 있다.

RPO가 짧아질수록 최신 데이터를 유지해야 하므로 데이터 복제 또는 백업 빈도가 높아질 수 있다.

따라서 DR에서는 다음 두 기준을 함께 설정해야 한다.

RTO = 서비스를 얼마나 빨리 복구해야 하는가

RPO = 어느 시점의 데이터까지 복구해야 하는가

두 기준은 서로 다른 목적을 가지고 있지만 실제 DR 설계에서는 함께 결정되어야 한다.

7. 데이터 동기화와 RPO

DR 환경에서는 주 시스템의 데이터가 복구환경에 어느 정도 최신 상태로 유지되는지가 중요하다.

예를 들어 데이터 복제가 1시간 단위로 이루어지는 구조라면 장애 발생 시 마지막 복제 이후의 데이터가 복구되지 않을 가능성이 있다.

반대로 매우 빈번한 복제는 다음과 같은 부담을 증가시킬 수 있다.

• 네트워크 사용량 증가
• 저장장치 I/O 증가
• 복제 시스템의 처리 부담
• 운영 복잡성 증가

따라서 데이터 복제 주기는 단순히 짧게 설정하는 것이 아니라 업무에서 요구하는 RPO를 충족하면서 시스템 부하를 감당할 수 있는 수준으로 결정해야 한다.

8. DR 전환 과정

주 시스템에서 대규모 장애가 발생하면 DR 환경으로 서비스를 전환해야 한다.

일반적인 전환 과정은 다음과 같이 구성할 수 있다.

① 재해 또는 대규모 장애 확인

② 주 시스템의 복구 가능 여부 판단

③ DR 전환 여부 결정

④ DR 환경 상태 확인

⑤ 데이터 동기화 상태 확인

⑥ 복구환경 활성화

⑦ 데이터 및 데이터베이스 복구

⑧ 네트워크와 서비스 접속경로 전환

⑨ 애플리케이션 및 연계 시스템 확인

⑩ 서비스 정상 여부 검증

⑪ 사용자 서비스 재개

이 과정에서 각 단계의 시작과 종료 시점을 기록하면 실제 DR 복구시간을 분석할 수 있다.

9. DR 전환 단계와 시간 기준

DR 복구시간을 하나의 숫자로만 관리하면 어느 단계에서 시간이 지연되는지 알기 어렵다.

따라서 다음과 같이 단계별로 시간을 구분하는 것이 좋다.

DR 단계	주요 작업	시간 기준
재해 확인	대규모 장애 여부 확인	재해 확인시간
전환 판단	DR 전환 필요성 판단	전환 결정시간
복구환경 준비	서버·스토리지·네트워크 준비	환경 준비시간
데이터 복구	필요한 데이터 및 DB 복구	데이터 복구시간
시스템 활성화	OS·DB·애플리케이션 활성화	시스템 활성화시간
접속경로 전환	DNS·라우팅·네트워크 변경	전환 작업시간
서비스 검증	기능·데이터·연계 확인	검증시간
서비스 재개	사용자 서비스 정상 제공	복구 완료

이를 단순화하면 다음과 같이 볼 수 있다.

전체 DR 복구시간 = 재해 확인시간 + 전환 결정시간 + 복구환경 준비시간 + 데이터 복구시간 + 시스템 활성화시간 + 접속경로 전환시간 + 서비스 검증시간

다만 실제 운영에서는 여러 작업이 동시에 진행될 수 있으므로 각 시간을 단순히 모두 더한 값이 실제 경과시간과 반드시 같지는 않다.

중요한 것은 각 단계에서 시간이 어디에 사용되고 있는지를 확인하는 것이다.

10. RTO와 실제 복구시간 비교

DR의 성능을 판단할 때는 설정된 RTO와 실제 테스트에서 측정된 복구시간을 비교해야 한다.

예를 들어

목표 RTO = 60분

실제 DR 테스트 복구시간 = 72분

이라면 현재 DR 구조는 목표를 충족하지 못한다.

이때 단순히 “DR이 느리다”고 판단하는 것보다 어느 단계에서 12분 이상의 차이가 발생했는지를 찾아야 한다.

예를 들어

• 전환 결정 지연
• 데이터 복구 지연
• 네트워크 변경 지연
• 애플리케이션 기동 지연
• 서비스 검증 지연

등으로 원인을 나눠볼 수 있다.

결국 RTO는 목표이고 실제 복구시간은 측정값이므로 두 값을 비교해야 DR의 실제 성능을 판단할 수 있다.

11. DR 전환 과정의 SPOF

DR 환경을 구성했다고 해서 모든 장애 위험이 제거되는 것은 아니다.

주 시스템과 DR 시스템이 다음과 같은 요소를 공통으로 사용한다면 특정 장애가 양쪽 환경에 동시에 영향을 줄 수 있다.

• 동일 네트워크
• 동일 인증 시스템
• 동일 DNS
• 동일 관리 시스템
• 동일 전원환경
• 동일 저장환경

따라서 DR 분석에서도 SPOF와 공통원인고장(CCF)을 함께 검토해야 한다.

특히 DR 시스템 자체가 정상적으로 준비되어 있어도 서비스 전환에 필요한 공통 구성요소가 장애를 일으키면 실제 전환이 불가능할 수 있다.

12. DR과 공통원인고장

DR의 핵심은 단순히 주 시스템과 DR 시스템을 물리적으로 떨어뜨려 놓는 것이 아니다.

두 환경이 같은 장애 원인에 동시에 영향을 받지 않는 구조인지를 확인해야 한다.

예를 들어 주 데이터센터와 DR센터가 서로 다른 장소에 있더라도 다음 요소를 공통으로 사용한다면 장애 독립성이 낮아질 수 있다.

• 동일 네트워크 사업자
• 동일 인증 시스템
• 동일 관리 플랫폼
• 동일 DNS 또는 외부 서비스
• 동일한 운영 절차와 계정 체계

따라서 DR의 독립성은 물리적인 거리뿐 아니라 전원·네트워크·데이터·인증·관리체계 등의 공통 의존성까지 확인해야 한다.

13. DR 테스트와 실제 복구능력

DR은 실제 재해가 발생한 후 처음 시험해서는 안 된다.

정기적인 DR 테스트를 통해 다음 항목을 확인해야 한다.

• DR 전환 가능 여부
• 데이터 복구 성공 여부
• 네트워크 전환 성공 여부
• 애플리케이션 정상 작동 여부
• 데이터 무결성
• 단계별 소요시간
• 전체 복구시간
• 담당자별 대응시간
• 복구 후 서비스 안정성
• RTO 충족 여부
• RPO 충족 여부

특히 문서상으로 “1시간 이내 복구 가능”이라고 되어 있는 것과 실제 테스트에서 1시간 이내 복구되는 것은 다르다.

실제 테스트 결과가 DR 성능을 판단하는 기준이 되어야 한다.

14. DR 복구시간의 정량적 분석

DR 성능을 평가할 때는 평균 복구시간만 보는 것보다 여러 차례의 테스트 결과를 함께 비교하는 것이 좋다.

예를 들어 다섯 번의 복구 테스트 결과가 다음과 같다고 가정해 보자.

50분 / 65분 / 55분 / 90분 / 60분

평균 복구시간은 64분이다.

하지만 평균값만 보면 한 번의 테스트에서 90분이 소요된 원인을 놓칠 수 있다.

따라서 다음 항목을 함께 확인하는 것이 좋다.

• 평균 복구시간
• 최대 복구시간
• 최소 복구시간
• 복구시간 분포
• 복구 실패 횟수
• RTO 초과 횟수
• 단계별 최대 지연시간

특히 최악의 복구시간이 업무상 허용 가능한 범위를 초과하는지도 확인해야 한다.

평균적으로 빠르다는 이유만으로 실제 재해 상황에서도 반드시 목표시간을 만족한다고 판단할 수는 없다.

15. DR 운영 데이터와 지속적인 개선

DR 성능을 장기적으로 관리하려면 실제 테스트와 장애 데이터를 축적해야 한다.

다음과 같은 정보를 기록할 수 있다.

• 실제 장애 발생시간
• 재해 확인시간
• DR 전환 결정시간
• DR 전환 시작시간
• 복구환경 준비시간
• 데이터 복구시간
• 시스템 활성화시간
• 네트워크 전환시간
• 서비스 검증시간
• 전체 복구시간
• 데이터 손실 범위
• RTO 달성 여부
• RPO 달성 여부
• 복구 실패 여부

이 데이터를 축적하면 단순히 “DR이 있다”는 사실을 넘어 실제 복구능력이 어느 수준인지를 지속적으로 판단할 수 있다.

16. DR과 서비스 연속성

DR의 궁극적인 목적은 단순히 서버를 다시 켜는 것이 아니다.

중요한 업무와 서비스를 다시 제공할 수 있어야 한다.

따라서 복구 우선순위를 결정할 때는 다음을 함께 고려해야 한다.

• 업무 중요도
• 서비스 간 의존관계
• 데이터 중요도
• 사용자 영향
• 복구에 필요한 자원
• 제한된 기능으로 업무를 유지할 수 있는지 여부

예를 들어 여러 시스템이 동시에 장애를 일으킨 상황에서 모든 시스템을 한꺼번에 복구할 수 없다면 가장 중요한 서비스부터 복구하는 우선순위가 필요하다.

따라서 DR은 기술적인 복구환경뿐 아니라 업무 관점의 복구 우선순위까지 포함해야 한다.

17. 최종 판단 — DR은 ‘구축 여부’보다 ‘실제 전환 가능성’이 중요하다

DR 시스템이 존재한다는 것만으로 재해복구 능력이 확보되었다고 볼 수 없다.

실제로는 다음 질문에 답할 수 있어야 한다.

주 시스템을 사용할 수 없게 되었을 때 DR 환경으로 실제 전환할 수 있는가?

설정된 RTO 안에 서비스를 다시 제공할 수 있는가?

RPO에 맞는 데이터를 실제로 확보할 수 있는가?

주 시스템과 DR 시스템이 동일한 장애 원인을 공유하고 있지는 않은가?

실제 DR 테스트에서 문서상의 복구절차와 동일한 결과가 나오는가?

결국 DR의 신뢰성은 복구환경의 존재 여부가 아니라 실제 장애 상황에서 정해진 데이터와 시간 기준을 충족하며 서비스를 다시 제공할 수 있는가로 판단해야 한다.

핵심정리

• RTO는 목표시간이고 실제 DR 복구시간은 측정값이다. 둘을 비교해야 DR 성능을 판단할 수 있다.
• RPO는 데이터 복구 지점, RTO는 서비스 복구시간을 결정한다.
• DR은 백업 데이터만 확보하는 것이 아니라 복구환경·데이터·네트워크·애플리케이션·운영절차가 실제로 함께 작동하는지 확인해야 한다.
• 가장 중요한 것은 “DR이 있는가?”가 아니라 “주 시스템을 사용할 수 없을 때 실제로 DR로 서비스를 전환할 수 있는가?”이다.