1. 서 론

재해복구(Disaster Recovery) 및 업무연속성계획(Business Continuity Plan) 수립이 새로운 주제는 아니다. 두 가지 모두 지난 수년 동안 인구에 회자된 것들이다. 그러나, 그만큼 널리 구현되지는 못했고, 기존의 재해복구나 업무연속성계획들이란 대부분 협의의 개념들이었다. 뉴욕의 어느 금융회사 관계자는 이렇게 말했다. “우리는 9·11 테러 이전에도 업무연속성계획을 세워두고 있었다. 그 계획에는 딜러들을 런던으로 보내 뉴욕에 있는 것처럼 일할 수 있게 하는 것도 있었다. 그러나, 모든 공항이 폐쇄될 줄 누가 알았겠는가?”
이 글에서 말하는 “비상계획”은 재해복구와 업무연속성계획이 결합된 것이다. 네트워크 관리자의 입장에서 보면, 효과적인 비상계획의 수립은 네트워크 기능이 비즈니스에 이익이 됨을 보여주는 대단히 훌륭한 방안이다. 이 글은 네트워크 관리자들이 성공적인 비상계획을 수립할 수 있도록 해주는 프레임워크를 제공하기 위한 것이다.
이 프레임워크는 비상계획에 필요한 정보기술(IT) 부문을 전반적으로 다루면서, 구체적으로는 비상계획의 네트워크 요소에 초점을 맞춘 것이다. 그리고 규모나 내용에 관계없이 모든 기업들에게 실질적으로 도움이 되는 프레임워크를 제공하려고 한다.
이 글에서는 “재해복구” 및 “업무연속성”이라는 용어가 갖는 일반적인 특징뿐만 아니라, 기업의 비상계획에 필요한 다양한 솔루션을 구성하는 주요 기술과 기능 및 프로세스에 대해서도 부분적으로 거론한다(원문에는 주요 기술과 기능 및 프로세스에 대한 논의가 포함되어 있으나, 본지에서는 지면 관계상 기술과 기능 부분은 생략하고 프로세스 부분만을 게재함 - 편집자주).
또한 자금 확보에 관해서도 다루면서 특히, IT 부서가 이 문제에 관해 비즈니스 결정권자와 어떻게 논의할 것인지에 대해 분석한다. 비상계획의 수립에는 반드시 충분한 자금이 IT에 지원되어야만 하고, 이를 제외한 비상계획이란 논의 자체가 무의미하기 때문이다.
이 글은 비상계획을 구현하는 방법을 다루는 추상적인 논문이 아니라, 이미 효과적인 비상계획을 구축했거나 현재 구축중인 여러 선도 업체들의 사례에서 발견한 사실들을 중심으로 기술하는 글이고자 한다. 일부 기업의 경우는 내부 정책상 이 글에서 회사 이름을 명시하지 않았음을 밝혀둔다.

2. 여러 가지 재해복구 방안

이 섹션에서는, 첫째 재해복구 솔루션 구현에 사용할 수 있는 여러 가지 방안을 살펴보고, 둘째 모든 비상계획의 핵심 내용인 ‘데이터 보호’에 대해 알아본다.
단, 데이터 보호에 관한 상세한 설명보다는 데이터 보호를 구현하는 좀더 통상적인 접근 방식의 일부를 설명하기로 한다.
그리고 아래 각각의 시나리오에서 열거한 장점들은 해당 비상 계획이 적절히 수립되었을 경우를 전제한 것이다. 예를 들면, 상시 대기 데이터센터(hot stand-by data center)를 구축하는 주요 목적은 재해 발생 시에도 회사가 자체 애플리케이션에 지속적으로 액세스할 수 있도록 하기 위한 것이다. 그러나, 적절한 비상계획이 수립되어 있지 않고 동일한 재해로 일차 및 백업 데이터센터가 오프라인화 된다면, 상시 대기 데이터센터란 무용지물이 되어 버린다.

◆ 시나리오 1 : 별도의 장소에 테이프 백업

이 경우는 회사가 주요 데이터베이스 컨텐츠를 정기적으로 테이프에 백업하는 것이다. 일일(daily) 백업이 일반적이며 백업 테이프는 차량으로 일정하게 떨어진 장소로 수송, 보존한다. 그리고 데이터센터에 재해가 발생한 경우, 이 백업 테이프를 다시 회사로 가져오는 것이다.
이 방식의 주된 장점은 간편하고 비용이 적게 든다는 것이다. 단점은 마지막 테이프 백업 이후에 생성된 데이터는 모두 손실되고, 또 경우에 따라서는 데이터센터가 수 일 동안 운영되지 못할 수도 있다는 것이다.

◆ 시나리오 2 : 일렉트로닉 볼팅(Vaulting)

이 시나리오는 차량을 사용하지 않는다는 점을 제외하고는 시나리오1과 유사하다. 이 시나리오에서는 회사가 WAN (Wide Area Network)을 사용하여 원격지로 주요 데이터베이스를 전송한다.
이 방식을 이용하는 회사는 대체로 시나리오1의 경우보다 데이터 백업을 더 자주 하며 매시간 업데이트가 일반적이다. 따라서, 시나리오1과 비교하여 시나리오2가 갖는 뚜렷한 장점은 손실되는 데이터가 훨씬 적다는 것이다. 그러나, 일반적으로 시나리오1보다 비용이 많이 들며, 재해의 영향을 받은 데이터센터의 비가동 시간도 줄이지 못한다는 단점이 있다.

◆ 시나리오 3 : 원격 디스크 미러링

이는 시나리오2와 유사하다. 그러나, 가장 큰 차이점은 이 방식을 이용하는 회사는 연속적으로 데이터를 업데이트 한다는 것이다. 따라서, 데이터 손실 가능성이 없다는 큰 장점이 있다. 그러나, 더 큰 용량의 WAN 링크가 요구되기 때문에 시나리오2보다 비용이 더 들고 데이터센터의 비가동 시간을 줄이지는 못한다는 단점은 마찬가지다.

◆ 시나리오 4 : 콜드 사이트(Cold Site) 구축

앞서 기술한 시나리오들에서는 재해에 영향을 받은 데이터센터가 무한 기간 동안 운영되지 않을 수도 있다. 그러나 이 시나리오는 데이터센터의 백업 용도로 콜드 사이트를 구축하는 것으로, 콜드 사이트는 비상계획이 발동된 후 장비를 설치하고 구성하는 곳이다.
이 시나리오는 앞의 다른 시나리오와 함께 사용할 수 있으며, 회사가 핵심 애플리케이션에 접근하지 못하는 시간을 최소화할 수 있는 것이 장점이다. 그러나, 추가 비용이 들고 복잡하다는 것이 단점이다.
제이디에드워즈(J.D. Edwards)사의 엔드리(Endry)는 이 방식과 관련한 복잡함에 대해 “콜드 사이트 방식을 선택하는 회사는 콜드 사이트의 장비에 관해 신중하게 계획을 수립해야 한다. 예를 들어 사양이 오래된 테이프 드라이브로 테이프를 백업한다면, 콜드 사이트에 테이프를 걸기 위해 동일한 종류의 드라이브를 급하게 구해야 하는 어려움을 겪게 될 수도 있을 것”이라고 말한다.

◆ 시나리오 5 : 완벽하게 이중화된 핫 사이트 (Hot-site)

이 시나리오는 업무연속성 솔루션으로 고려할 만한 좋은 방안이다. 이 시나리오는 적절한 애플리케이션 모두를 실행시킬 수 있는 메인프레임이나 서버가 원격지에 있다는 점에서 시나리오4와 다르다. 장점은 재해로 인해 데이터센터가 운영되지 못할 경우, 원격지의 핫 사이트가 아무런 영향을 받지 않고 운영 기능을 넘겨받을 수 있다는 점이다. 물론, 재해가 원격지의 핫 사이트에 영향을 미치지 않았다는 점을 전제로 한다. 단점은 비싸다는 것이다.

3. 비상계획의 핵심 요소

네트워크 전문가들이 적절한 비상계획 방안을 선택하기 위해서는 다음과 같은 질문을 고려할 필요가 있다.

세계적인 회계법인 프라이스워터하우스쿠퍼스(Price-waterhouseCoopers)사의 브라운(Brown)은 간단히 답하기 어려운 질문이라고 한다. 그는 이렇게 부연 설명한다. “연속성을 유지해야 할 핵심 애플리케이션이 산업 부문별로 크게 다르다. 전문 서비스 부문에서는 원격 접속 및 이메일이 핵심 애플리케이션인데 반해, 제조 부문에서는 ERP시스템이 가장 핵심적인 애플리케이션이라 할 수 있다. 중요한 애플리케이션이 무엇인지에 대한 정보는 반드시 IT담당자가 아닌 해당 비즈니스 담당자로부터 얻어야 한다. 왜냐하면, 가치/비용이 애플리케이션의 잠재적 비가용성과 연관될 경우 비즈니스 담당자와 IT 담당자의 우선 순위는 달라지는 경우가 많기 때문이다.”
어바이어(Avaya)사의 미내시언(Minassian)은 단지 어떤 기능들이 비즈니스에 중요한 것인지를 아는 것만으로는 충분치 않다고 조언한다. 그는 “무엇이 비즈니스에 핵심적인지를 아는 것뿐만 아니라 그것이 재해 발생시 변경될 수도 있는지를 파악하는 것도 중요하다. 예를 들면, 예상 사용자들의 수나, 대응 시간 단축 여부 등이 그것이다. 이러한 것들을 알 수 있다면 BC/DR(Business Continuity / Disaster Recovery) 및 설계와 비용에 관한 접근 방식을 바꿀 수 있다”고 말한다.

아이서브(iSERV)사의 코커리(Corkery)는 질문 2와 관련된 문제들에 대해 이렇게 말한다. “1984년 나는 화재가 발생한 대형 통신 회사의 주요 데이터센터 복구에 참여했다. 건물은 물리적 피해를 입지 않았지만 전기 시스템을 다시 설치해야 했고 이 작업에 약 4주가 소요됐다. 우리는 모든 애플리케이션을 “핵심”과 “비핵심”으로 구분하고 핵심 애플리케이션만을 복구하기로 예정되어 있었지만, 4주가 흐르는 동안 모든 애플리케이션들이 비즈니스 사용자에게 중요해졌다. 결국, 우리는 분류 목록을 최대 허용 중단시간(Maximum Tolerable Outage) 기준으로 다시 작성했다. 그 일로 인해 우리는 무엇을 언제 해야 할 것인가 하는 필수 우선 순위 결정에 관해 배웠지만 결국 모든 것을 해야만 한다는 사실도 깨닫게 되었다.”

엔드리(Endry)는 자금에 대한 논의 없이 비상계획을 운운하는 것은 불가능하다고 생각한다. 그는 “많은 기업들이 이메일을 핵심적인 비즈니스 기능으로 파악하고 있다. 그렇다면 이메일 용량의 100%를 이중화할 것인지, 아니면 한동안은 용량을 줄여 운영할 것인지를 결정해야 한다. 그 결정에 따라 비용이 크게 달라질 수 있다”고 말한다.
일반적으로, 비상계획의 비용은 상기 질문들에 대한 답과 직접적인 연관이 있다. 특히, 보호를 위해 필요한 기능, 요구되는 보호 수준, 대처해야 할 재해 유형이 증가할수록 비상계획의 비용은 증가하게 된다. 앞서 언급한 바와 같이, 9·11사건으로 인해 비상계획이 뜨거운 이슈로 떠올랐다. 그리고 비상계획을 단순히 9·11 테러 공격과 같은 엄청난 사건에 대비하는 것이라고 생각하는 경향이 늘고 있다. 이는 근시안적인 생각이며, <표 1>에 기술한 것과 같이 재해 유형을 세 가지로 파악하는 것이 올바른 자세라고 할 수 있다.

분명 <표 1>의 내용은 각 기업들이 처한 특정한 상황에 맞도록 어느 정도 조정이 필요할 것이다.
한편 <표 1>과 같은 수단을 통해 IT 부서와 비즈니스 의사결정권자 간에 적절한 대화가 시작될 수 있다.
하지만, IT 부서와 비즈니스 의사결정권자들 간의 대화가 실질적인 의미를 가지기 위해서는 다양한 선택 방안에 대한 비용 문제도 논의에 포함되어야 한다.

4. 고가용성 네트워크 설계

비용 효율적인 고가용성 네트워크를 설계하려면 다양한 기술이 결합되어야 한다는 점을 염두에 두어야
한다. 장비 단계의 이중화는 장비 내의 단일장애점(SPoF: Single Points of Failure)을 없애주지만 링크 장애나 운영자 실수, 설정 오류, 소프트웨어 에러와 같은 ‘소프트’한 장애로부터 분산형 네트워크를 보호하지는 못한다. 분산형 네트워크를 모든 유형의 장애로부터 보호하는 가장 좋은 방법은 주요 종단 시스템(end system) 간에 다수의 병렬 경로를 제공하여 네트워크 수준에서 단일장애점을 제거할 수 있는 탄력적인 네트워크(resilient network)를 설계하는 것이다.
한편 탄력적인 네트워크에 장애가 발생하면 남아 있는 장비와 링크에 일시적으로 부하가 증가해, 장애가 발생하지 않은 경로에 트래픽 페일오버(failover)가 발생하는 것이 일반적이다. 장비 단계의 이중화 및 링크
이중화로 이러한 페일오버 발생 빈도를 줄일 수 있으며, 페일오버가 발생하면 QoS 메커니즘은 더 많은 네트워크 자원을 핵심 애플리케이션 트래픽에 자동으로 할당함으로써 높은 수준의 서비스를 유지할 수 있다.
비용 효율적인 고가용성 네트워크는 일반적으로 네트워크의 복잡성을 증가시킨다는 점도 염두에 두어야
한다. 어바이어(Avaya)의 미내시언은 네트워크 전문가들에게 이렇게 조언한다. “네트워크 설계의 복잡성과 유지관리상의 편리성 간의 균형을 맞추어야 한다. 유용하면서 자체 회복 기능을 갖춘 복잡한 네트워크를
설계할 수 있겠지만, 장애 발생 시에 이를 해결하고 지원할 수 있는 능력을 갖추고 있어야 한다는 점도 명심해야 한다.”

◆ 강력한 LAN 설계

몇 년 전부터 3계층의 계층적 설계로 대규모 캠퍼스 스위치 LAN을 구축하는 것이 일반화되고 있다. 이러한 설계는 <그림 2>에서 볼 수 있듯이 와이어링 클로짓(Wiring Closet)과 사이트 백본 그리고 캠퍼스 백본의 물리적 토폴로지와 일치한다.
네트워크의 각 계층은 해당 계층에서 요구되는 기능에 맞춰 최적화된, 다수의 이중화되고 장애에 강한(fault tolerant) 모듈로 구성된다. 소규모 기업의 네트워크는 하나 또는 그 이상의 와이어링 클로짓 모듈에 부합되는 단일 계층 LAN과 WAN 라우터로 구축할 수 있다. 반면, 중간 규모의 기업 네트워크는 와이어링 클로짓과 사이트 백본 모듈을 결합해 구축할 수 있다.
가장 일반적인 스위치 LAN 토폴로지는 와이어링 클로짓 계층에 Layer 2 스위칭과 사이트 및 캠퍼스 계층에 Layer 3 스위칭을 기반으로 한다.
이러한 방식을 L2/L3/L3 방식이라고도 하는데 LAN 설계의 초기 허브/라우터 모델에서 서브넷 구조를 차용하는 이점이 있다. 캠퍼스 계층은 또한 Layer 2 스위칭으로도 성공적으로 구축할 수 있지만, Layer 3 캠퍼스 백본은 훨씬 더 확장성이 높고 강력하다. Layer 3 스위칭은 신속한 페일오버를 가능하게 하며 이는 곧 더 높은 가용성으로 이어진다. Layer 3 캠퍼스 백본은 또한 그물형(meshed) OSPF(Open Shortest Path First) 백본을 통해 병렬적이며 비용이 동일한 경로로 완전한 링크 활용과 부하 공유를 가능하게 한다.
L2/L3/L3 모델의 단점은 클로짓 레벨로부터의 업링크가 Layer 2에서 스위칭 된다는 점이다. 특히, 스패닝 트리 알고리즘 사용으로 병렬 부하 공유(load-sharing) 연결이 각각의 와이어링 클로짓 스위치에서 이중화된 Layer 3 사이트 스위치로 구성되는 것이 불가능할 수 있다. 이러한 병렬 연결을 구성할 수 없다는 것은 해당 LAN 설계의 가용성을 떨어뜨린다.
스패닝 트리 알고리즘을 훼손하지 않고 가용성을 높일 수 있는 효과적인 방법은, <그림 2>와 같이 LAG(Link Aggregation)을 사용하여 와이어링 클로짓 스위치와 중심부의 경계선에 있는 첫번째 Layer 3 스위치 간에 point-to-point 링크를 만드는 것이다. 스패닝 트리 알고리즘은 각각의 LAG을 단일한 논리적 링크로 간주하며, LAG 내에서 부하는 MAG 주소와 포트 디노미네이션을 토대로 구성원 간에 균형 있게 분담된다.
L2/L3/L3모델에서 점차 보편화되고 있는 수정 사항은, 와이어링 클로짓 스위치의 업링크 포트를 포함시키기 위해 Layer 3의 경계를 더욱 확장하는 것으로 이는 백본에서 뿐만 아니라 라이저(riser)에서의 OSOF ECMP(Equal Cost Multi-Path) 부하 분담(load balancing)을 가능하게 한다. 라이저에서의 ECMP로 인해, 주경로가 장애로 작동되지 않을 경우에만 트래픽을 전송하는 예비용 이차 업링크의 비용/성능 부담 없이 단대단(end-to-end) 이중화 네트워크를 설계할 수 있다.
또한 <그림 2>는 와이어링 클로짓에서 서버팜(Server Farm)까지 완전 링크 및 장비 이중화를 갖추고 있는 3계층의 캠퍼스 네트워크 설계에 몇몇 네트워크 레벨 기능들이 어떻게 적용될 수 있는지를 보여주고 있다.
와이어링 클로짓 스위치 “A”의 Layer 2 스위칭으로, 링크 및 라우터 이중화에 LAG과 VRRP(Virtual Router Redundancy Protocol)를 적용할 수 있다.
일차 LAG(primary LAG) 또는 일차 사이트(primary site) Layer 3 스위치 “C”가 작동하지 않을 경우, 트래픽은 예비 LAG을 통해 이차 사이트(secondary site) 스위치 “D”로 전달된다. 반면, 와이어링 클로짓 스위치 “B”의 업링크에 있는 OSPF Layer 3 스위칭은 스위치 “C”와 “D”로의 동일비용경로(equal cost path )에 부하 분담(load balancing)을 가능하게 한다.
사이트 및 백본 계층에서는 ECMP OSPF가 완전 링크 및 장비 이중화를 지원한다. 서버 팜에서는 L2/L3 스위치 “E”와 “F”간의 OpenTrunk 802.1Q VLAN 트렁킹이 서버로 하여금 두 개의 서버 스위치를 연결하는 VLAN에 이중으로 장착될 수 있도록 한다.

◆ 그림 1 - 고가용성 LAN설계

◆ 강력한 WAN 설계

WAN에 네트워크 설계 이중화를 구현시키기 위해서는, 모든 주요 네트워크 사이트들이 이중화된 접속점(WAN에 부하가 균형 있게 분담되는 병렬의 연결을 제공하는 이중 라우터를 갖춘) 구축을 고려해야 한다.
한편 이러한 사이트들로부터 실질적으로 다양한 액세스가 가능하도록 하는 데는 지역교환 통신사업자(LEC: Local Exchange Carrier)와의 협조도 필요하다는 점에 유의해야 한다. 또한 이러한 다양한 접근을 가능케 할 경우 설계상의 비용이 높아진다는 점도 염두에 두어야 한다.

또 다른 기술은 ISDN을 백업 매체로 사용하는 것이다. 일반적으로, ISDN 회선은 일차 WAN 서비스(즉, 전용선이나 프레임 릴레이)가 작동하지 않는 경우 자동으로 활성화되며, 통상 두 개의 B 채널을 사용하거나
역다중화(inverse multiplexing) 및 압축을 사용한다.
그 결과 회선에서 256Kbps의 전송 속도를 기대할 수 있다. 그러나, 장애의 원인이 LEC 접속 회선의 단선인 경우에 이러한 기술은 무용지물이 된다. 이러한 상황이 발생해 지상 회선을 통해 다양하게 라우트된 접속이 용이하지 못하거나 비용상 사용이 불가할 경우, 서비스 공급자의 마이크로웨이브 접속이나 위성 링크 사용과 같은 대체 전략을 고려해야만 한다.

서비스 공급자로부터 서비스 수준 또는 가동시간에 대한 보장을 얻어 내는 것도 중요하다. 이러한 협상 및 네트워크 관리 문제가 중요한 것은 통상 서비스 공급자들이 서비스 수준을 보장하기는 하지만 불이행에 대한 보상액이 상대적으로 가볍기 때문이다. 따라서, 고가용성의 WAN 구축을 원하는 네트워크 관리자들은
서비스 수준의 보장에 관한 더욱 구체적인 협상을 할 필요가 생기는 것이다.
좀더 의미 있는 서비스 수준 보장에 관한 협상이 비상계획의 중요한 요소로 보이기도 하지만 어바이어(Avaya)사의 미내시언은 이렇게 말한다. “장애 발생 시에 서비스수준협약(SLA: Service Level Agreement)에 의존해서는 안 된다. 어바이어사는 회선의 마지막 구간을 네덜란드의 무선 서비스 공급업체에 하청을 준 적이 있다. 그런데, 네트워크에 장애가 발생했지만 노동법이 12시간 이상 근무를 금해 기술자를 파견하지 못했다. 이러한 법적 제약 때문에 SLA는 재해복구 면에서 아무런 도움이 되지 못했다.” 미내시언은 해당 WAN이 비즈니스에 중요한 부분이라면 경로를 다양화하고 이중화할 필요가 있다고 충고한다.
한편 고가용성 제공이 네트워크 관리의 문제가 된다고 한 이유는, 서비스 수준 보장을 모니터링 하는 데에 비교적 정교한 서비스 관리 도구와 프로세스를 구축해야 하기 때문이다. 서비스 공급자가 제공하는 SLA에 전적으로 의존할 수 없을 경우에는, 경쟁 인터넷 서비스 공급자와 WAN이 제공하는 이중화된 네트워크 서비스에 이중 네트워크 연결을 구축해야 한다. 이러한 예로는 많은 기업들이 자사의 콜 센터 트래픽을 여러
서비스 제공업체로 분산하고 있는 것을 들 수 있다.

◆ 그림 2 - 고가용성 WAM연결

< 그림 2>는 고가용성의 WAN 액세스 아키텍처를 보여준다. 이중화된 액세스 라우터가 서버 사이트 계층의 이중화된 Layer 3 스위치에 연결되어 캠퍼스 LAN과 WAN 사이의 모든 단일장애점(SpoF)을 제거한다.
아이서브(iSERV)사의 코커리는 “고가용성 네트워크 계획을 수립할 때 라우트를 다양화하는 것은 대단히 바람직하다. 그러나, 서비스 지역에 따라 추가 조사가 일부 필요하다. 우리는 서로 다른 통신사업자의 서비스를 사용했는데도 물리적 전송이 동일한 경우를 여러 번 경험했다. 이는 조사를 통해 단일장애점이 명확해질 때에야 알게 된다”고 말한다.
미내시언도 코커리와 같은 의견으로, “어바이어사도 서로 다른 통신사업자들의 이중 회선 서비스(동일한
파이버 백본을 통과하는)를 경험한 적이 있다. 이러한 경우는 많은 공급자들이 빌린 용량을 다시 빌려주는 대서양 횡단 및 태평양 횡단 링크에서 특히 두드러진다”고 말한다. 미내시언은 네트워크 전문가들에게 “서비스 공급자들에게 상세한 라우트 경로를 요구하여 그들이 직접 전송하는지 아니면 전대(轉貸)한 것인지를 구분, 파악해야 한다”고 충고한다.

5.비상계획 수립을 위한 프로세스

여기서는 비상계획에 포함되어야 하는 몇 가지 프로세스에 대해 살펴보고자 한다.

◆ 다른 주요 프로세스와의 링크

IT 비상계획이 실효성을 갖기 위해서는 다른 주요 프로세스와 연계되어야 한다. 예를 들면, 엔드리와 코커리가 강조한 바와 같이, 관련 비즈니스 프로세스와 긴밀하게 연계되어 있지 않은 비상계획으로 재해복구가 이루어질 경우, 시간과 돈을 낭비하게 된다.
또한, IT 업체의 비상계획은 자체 보안계획과 연계할 필요가 있다. 여기에는 두 가지 이유가 있는데, 첫째는 서비스 거부 공격(Denial of Service attack)과 같은 보안 사고로 인해 회사가 온전히 기능하지 못할 수 있기 때문이고, 둘째는 효과적인 보안계획 수립과 효과적인 비상계획 수립이 상당 부분 공통되기 때문이다. 따라서 이러한 두 가지 계획을 연계함으로써 비용을 최소화하고 각 계획의 효율성을 극대화할 수 있다.

? 정기적인 인벤토리 분석 수행
미내시언은 강력한 비상계획을 구축하기 위해서는 네트워크 전문가들이 이렇게 조언한다. “전체적인 설계에서부터 각각 장비에 설치되는 펌웨어의 최신 개정본에 이르기까지 설치와 관련된 모든 사항을 파악해야 한다. 많은 네트워크 팀들이 엔지니어의 PC에 설치된 비지오(Visio) 프로그램으로 작성된 다이어그램을 기반으로 네트워크를 설계하고 있는 실정이다.”

◆ 백업 장비 배비(配備)

뉴욕에 위치한 한 금융회사의 CTO는 9·11사건 이후 주식 시장이 다시 개장됐을 때 3000 명의 관련 직원들이 정상적으로 업무를 수행할 수 있었다고 한다. 그는 이것이 가능했던 이유 중 하나로 표준 데스크탑 환경을 갖추고 있었다는 점을 들었다. 표준 데스크탑 환경 덕분에 비교적 손쉽게 적절한 소프트웨어를 백업 데스트탑에 설치할 수 있었던 것이다. 그 과정에서 가장 까다로운 부분이 PC 3000대를 새로 구입하는 것이었다.

◆ IT 위기 관리팀 구성

재해에 신속히 대처하기 위해서는 재해 발생 이전에 IT 위기 관리팀과 대체 부서를 구성하고 업무 내용을 명확히 규정해 두어야 한다. 또한 위기 관리팀이 즉각 가동되도록 하려면 모든 사람들이 대체 관리팀, 위기 관리팀과 연락 가능하도록 최신 연락 정보를 작성하고 관리해야 한다.

◆ 효과적인 커뮤니케이션 방안 확립

위기 관리팀이 효과적으로 운영되기 위해서는 효과적인 커뮤니케이션 방안이 마련되어야 한다. “위기 발생시에는 효과적인 커뮤니케이션이 중요해지는데, 리서치인모션(Research-in-Motion)의 블랙베리(Blackberry) 제품군과 같은 신기술 제품의 사용이 매우 효율적인 것으로 밝혀졌다.
지난 봄, 도로변 변전실의 화재로 인해 우리 건물이 폐쇄되는 일이 발생했다. 당시, 상급 관리팀이 아침 출근길에 있을 때 우리가 이 문제에 대해 자문을 받게 되었다. 우리가 도착했을 때, 대체 사무실 공간을 사용하기 위한 정비가 이루어졌으며 고객지원센터의 전화선이 재정비되어 있었다. 비즈니스 사용자에게 이는 당연한 일이었지만 블랙베리의 문자 메시징이 없었다면 결코 해낼 수 없었던 일이었다.” 코커리의 말이다.

◆ 후임자 육성계획 수립

IT부서가 정상적으로 운영되기 위해서는 후임자 육성계획을 수립해야 한다. 이러한 계획의 필요성은 비상계획 수행 시에 더욱 돋보인다. IP 주소 체계와 같은 네트워크의 핵심 사항에 관한 모든 지식이 주로 한두 사람의 머리 속에만 있다는 것은 큰 취약점으로 나타날 수 있기 때문이다.
미내시언은 네트워크 전문가들에게 이렇게 조언한다. “회사 네트워크에 대해 알고 있는 사람이 두 명 이상이 되도록 해야 한다. 직원 한 명에게만 의존하다 해당 직원이 모든 지식을 가지고 떠나버리는 경우가 비일비재하므로, 공식적인 후임자 육성계획을 즉시 수립해야 한다.”

◆ 직원 교육

비상계획이 효율적으로 운영되기 위해서는 회사 직원들이 이를 깊이 있게 인식하고 있어야 한다. 신입사원 오리엔테이션이나 업무 수행 과정에서 공식적인 교육을 실시함으로써 이러한 인식을 높여야 한다. 이를 위해 여러 가지 다른 방법들도 활용할 수 있다. 예를 들면, 뉴욕의 많은 회사들이 비상 정보 카드를 활용하고 있는데, 이 카드는 셔츠 주머니에 넣고 다닐 수 있도록 만든 얇은 카드로 재해 발생시 취해야 할 행동 요령을 담고 있다.

◆ 비상계획 테스트
코커리는 “재해복구나 업무연속성계획은 테스트를 거쳐 보완되어야 개발이 완료된다. 우리는 재해복구 및 업무연속성계획을 연 4회(정규 테스트 3회와 ‘불시’ 테스트 1회) 테스트한다”고 말한다.
코커리는 불시 테스트를 시행할 때 사전에 직원이나 동료가 화재나 폭발물의 폭발 등으로 인해 업무를 볼 수 없게 되었다는 내용을 담은 쪽지를 직원의 책상에 남겨두곤 한다. 이런 방법으로 테스트는 더욱 실제 상황에 가까운 시뮬레이션이 되는 것이다.
코커리는 또한 최신 호출 번호로 꾸준히 업데이트해야 한다고 강조한다. 그는 경험을 통해 “통상 90일이 지나면 20%가 바뀐다는 것을 알게 됐다”고 말한다.
프라이스워터하우스쿠퍼스(PricewaterhouseCoopers)사의 브라운(Brown)은 “테스트는 재해복구 계획의 가장 중요한 요소 중 하나로, 여기에는 예비 하드웨어의 가용성에서부터 디젤 발전기에 연료가 채워져 있는지 또 제대로 작동하는지에 이르기까지 모든 것이 포함되어야 한다”고 말한다. 브라운은 예전에 “건물 배전이 바뀌어 결국 디젤 발전기가 작동하지 않았음을 알게 되었다. 이러한 사실은 통상적인 분기별 테스트를 통해 밝혀졌는데, 이는 정기적 테스트가 얼마나 중요한지를 단적으로 보여준다”고 말한다.
미내시언은 네트워크 전문가들이 또한 자사의 대역외(out of band) 관리 액세스를 정기적으로 점검해야
한다고 조언한다. 그는 “모뎀 사용을 위한 링크를 단선시킨 후 링크를 다시 연결하도록 기술자들에 지시하지 않는 경우가 많다.
뒤늦게 긴급 상황에 대처하기 위한 액세스가 필요할 때에야 이런 사실을 발견하게 된다”고 말한다.

◆ 복구

앞서 언급한 바와 같이 1984년에 아이서브(iSERV)사의 코커리는 화재가 발생한 대형 통신 회사의 주요 데이터센터 복구에 참여한 적이 있다. 그는 이를 통해, 재해 상황이 완료된 후에 어떤 작업이 비상계획에 포함되어야 하는지를 알게 됐다. “당시 화재 사건에서 배운 두 번째 교훈은, 비록 우리가 대체 데이터센터 가동 방안을 훌륭하게 수립했고 이를 거의 완벽하게 실행은 했지만, 원상 복구 방안에 대한 계획은 가지고 있지 않았다는 것이다. 모든 것을 원상 복구시키는 것은 또 다른 재해 상황이라 할 만한 것이었다. 결국 이 모든 것들을 천천히 조심스럽게 복구하는 데에 추가로 수개월이 소요되었다.” 코커리의 말이다.

6. 비즈니스 사안 분석

재해를 입은 회사의 40%가 수년 내에 문을 닫는다는 것이 IT 업계의 일반적인 인식이다. 이러한 통계는 기업들이 비상계획을 수립하도록 하는 자극제로는 충분하지만, 비상계획 구축에 막대한 자금을 투자할 수 있도록 경영진을 움직이는 데는 다소 역부족이다. 이를 위해서는 네트워크 관리자들이 회사 내의 의사결정권자들과 협의하여 자사의 환경에서 신뢰할 수 있는 비즈니스 사안 분석을 실시해야 한다. 이러한 비즈니스 사안 분석은 다운타임(down time) 비용을 파악하는 것에서 시작한다.
먼저, 대부분의 비즈니스 기능의 경우 그 기능이 수 시간 혹은 하루 동안 작동하지 않으면, 회사에 분명 손실이 발생할 수 있다는 사실이 아직 일반적인 인식으로 자리잡지 못했다는 점을 지적할 필요가 있다. 이는 해당 비즈니스 기능이 작동하지 않는데도 사람들이 무덤덤하다는 말이 아니다. 그보다는 그러한 기능의 장애발생 가능성을 줄이기 위해 추가로 비용을 지불할 의사가 없음을 지적하고자 하는 것이다.
그러나, 몇 가지 비즈니스 기능들에 대해서는 많은 회사들이 다운타임으로 인한 비용을 인정하고 있다. 그 기능들은 다음과 같다.

● 증권 거래
● 온라인 판매
● 적시(Just-in-Time) 생산
● 온라인 예약

이러한 기능들의 장애 비용을 산정하는 데 고려하는 여러 가지 요소들이 있으며, 이는 다음과 같다.

● 매출 감소
● 고객 감소
● 신뢰 상실

IT 부서는 비상계획 수립을 위한 비즈니스 사안 분석에서 <표 2>와 같은 표를 만들어 분석을 수행해야 한다. 이 표는 몇몇 주요 지점과 주요 기능 또는 전체 운영에 관한 것으로, 먼저 회사 내에서 장애로 인한 비용이 가장 클 것으로 보이는 비즈니스 상황부터 시작하는 것이 실질적인 접근 방법이다. 만약 비즈니스 담당자들이 그런 상황에 대비한 비상계획에 자금을 투자할 의사가 없다면, 더 이상의 작업은 시간 낭비일 것이다.
예를 들어, <표 2>가 대형 증권회사의 장내 거래에 관한 것이라고 가정해 보자. 또 분석할 특정 사안이, 회사 소속의 거래자들이 재해에도 불구하고 지속적으로 시장 데이터에 접근할 수 있도록 하는 비상계획 구축의 경제적 가능성이라고 가정해 보자.

이 경우 표를 작성하는 목적은, 비상계획에 대한 자금 지원 여부를 최종 결정하는 사람(또는 사람들)에게 IT부서가 대안을 제시하도록 하는 데 있다. 이런 맥락에서 보면, 하나의 솔루션은 여러 가지 기술과 기능 및 프로세스가 결합된 것이라 하겠다.

표를 작성하기 위해, IT 부서는 두 가지 핵심 요소를 기준으로 여러 가지 유망 솔루션을 검토해야 한다. 또한 그 과정에서 특정 솔루션 구축에 드는 비용을 추정 산출해야 하는 점에도 유의해야 한다. 이러한 유망 솔루션 비용도 <표 2>에서 매우 중요한 요소다.

표에 포함되어야 하는 두 가지 핵심 요소 중 하나는 비상계획이 제공하는 보호의 수준(Amount of Protection)이다. 보기에서는 두 가지로 살펴보았다. 하나는 거래자들이 거래 데이터에 지속적으로 접근할 수 있는 경우고, 다른 하나는 거래자들이 최대 4시간 동안 거래 데이터에 접근하지 못하는 경우다.
표에 포함되어야 하는 또 다른 핵심 요소는 비상계획이 대처해야 하는 재해의 강도(severity)다. 재해 유형 분류법은 <표 1>에 자세히 설명되어 있다. 보기에서는 세 가지 유형을 모두 고려했다.
< 표 2>와 같은 수단을 활용하면 다음과 같은 성과를 거둘 수 있다.

● IT 부서를 회사의 비즈니스 및 기능 관리자의 파트너로 확고하게 자리매김해준다. 이는 IT 부서가 비즈니스 의사결정권자들이 고려할 대안을 제시하고 있기 때문이다.
● 의사결정시 고려해야 할 비용 요소를 제시한다. 엔드리의 말을 빌리면, 비용 요소를 제시하지 못할 경우, 먼저 업무연속성계획의 필요에 의해 회사 이메일의 100%를 이중화해야 하는 상황이 벌어질 수도 있을 것이다. 그리고 회사 이메일의 100%를 이중화하는 데 소요되는 비용을 계량화한 후에야, 회사 이메일의 50%만을 이중화해도 괜찮은지를 비즈니스 관점에서 제대로 판단할 수 있을 것이다.

7. 요 약

재해복구 및 업무연속성이 뜨거운 이슈로 떠오르는 데는 9·11사건도 한몫 했다. 그런데 미국에 대한 공격이 초래한 여러 가지 영향들이 사람들의 뇌리에서 희미해지고 있는 반면, 재해복구 및 업무연속성은 여전히 수많은 기업에 중요한 문제로 인식될 것이다. 여기에는 두 가지 이유가 있다. 하나는 많은 회사에서, 9·11 공격의 영향이 사라지지 않은 것이고, 다른 하나는 재해복구와 업무연속성이 9·11과 같은 엄청난 사건에 대비해 단지 ‘보호’ 기능을 제공하는 것 이상의 의미가 있기 때문이다.
이 글은 이런 점들을 염두에 두고, 네트워크 담당자들이 IT 비상계획(회사의 특정한 상황과 요구를 반영하는)의 수립에 사용할 수 있는 프레임워크를 제시했다. 예를 들어, 어떤 회사들은 비교적 간단한 비상계획을 원할 것이고, 또 어떤 회사들은 좀더 포괄적인 비상계획을 원할 것이다. 어느 경우든, IT 비상계획의 효과를 극대화하기 위해서는 다른 두 가지 요소 즉, 회사의 보안 계획 및 IT 비상 계획에 대응하여 구현되고 있는 비즈니스 프로세스들과 긴밀하게 연계되어야 한다.
이 글에서 소개한 프레임워크는 비상계획 수립 시에 네트워크 전문가들이 <표 1>과 같이 재해를 세 가지로 분류해 볼 것을 제안하고 있다.
또한 이 글은 고가용성의 LAN과 WAN 인프라 구축의 가이드라인 몇 가지를 제시하고 있다. 그러나, 실제로 비상계획에 이러한 가이드라인이 적용될 경우 네트워킹 비용이 증가할 수도 있고, 네트워크 인프라가 복잡해질 수도 있다.
이 프레임워크는 비상 상황을 위한 솔루션에 여러 가지 기술과 기능 및 프로세스를 결합할 것을 제시하고 있다. 이 글에서 언급한 바와 같이 이러한 솔루션을 만드는 데 사용될 수 있는 기술들은 대단히 많다. 주로 백업 전력(backup power)과 전화의 재설정 등의 몇 가지 기술들이 비상계획 수립에 적용되고 있다. 그러나, VoIP와 컨텐츠 분산 네트워크(content distribution network) 등의 수많은 다른 기술들은 일반적으로 비상계획에 사용될 수 있음에도 불구하고 이러한 비상 계획과는 무관하게 구축되고 있다.
재해에 대한 취약성을 줄이기 위해 많은 회사들이 도입하고 있는 기능 몇 가지를 소개하면 다음과 같다.

● IT 인프라스트럭처의 단순화
● 회사의 부동산 보유의 다양화
● 호스트된 솔루션의 활용

또한, 비상계획 솔루션을 구성하는 데 부분적으로 사용될 수 있는 프로세스들도 다양하다. 이러한 프로세스 가운데 정기적인 인벤토리 분석 수행 등은 그 자체가 의미 있는 IT 관리 프로세스라고 할 수 있다. 그러나, 이러한 프로세스들의 핵심은 비상계획 지원에 있다. 따라서, 이러한 프로세스를 구현하는 것은 업무 및 비용의 증가를 의미한다.
집필에 도움을 준 수많은 고위 IT 담당 간부들은 적절한 자금 조달 방안에 관한 논의 없이는 비상계획에 대한 의미 있는 논의가 이루어질 수 없다는 점에 대해 모두 동의했다. 이 글은, 이제 막 비상계획을 준비하고 있는 IT 부서들이 다운타임으로 인해 엄청난 비용이 발생할 가능성이 가장 높은 비즈니스 상황부터 시작할 것을 제안하고 있다. 회사 내의 비즈니스 경영진들이 이러한 핵심 상황에 대비한 비상계획에 자금을 투입할 의사가 없다면 더 이상의 비상계획을 위한 작업은 시간 낭비가 될 것이기 때문이다.