이제 국내에서 DR(Disaster Recovery)시스템은 일정 규모 이상의 IT조직에서는 일반화되어 있는 비즈니스 연속성 또는 IT 서비스 연속성의 솔루션이다. DR을 갖추고 있는 IT조직들은 재해가 발생하더라도 IT가 다시 서비스 될 수 있다는 확신을 가지고 있다.
이러한 확신은 IT를 사용하는 사용자나 연관 관계를 가지는 이해당사자들에게도 해당된다.
그러나, 만에 하나 DR시스템이 ‘실제 상황’에서 ‘작동’하지 않거나, 작동하더라도 너무 느리거나 오작동과 작동을 반복하게 된다면 어떻게 될까?
DR시스템의 담당자뿐만 아니라, DR시스템의 투자를 결정한 IT경영진에게는 생각하기도 싫은 상황이겠지만, 여러 IT조직을 관찰한 결과에 따르면 이런 가능성은 ‘충분하다’라고 판단된다.
■DR은 살아있어야 한다?
DR시스템은 ‘서비스중인 IT시스템’을 원격지에 옮겨다 놓은 ‘복제품’이다. 일반적으로 ‘서비스중인 IT시스템’은 외부 환경 또는 사용자 요구에 따라, 세부 구성항목, 용도 및 목적 등이 지속적으로 ‘변화’하고 ‘성장’하게 되어 있다.
‘서비스중인 IT시스템’의 이러한 변화와 성장은 복제되어야 하는 ‘DR시스템’에도 동일하게 적용되어야 한다. 그런데 국내 일부 IT조직들을 관찰한 결과 ‘변화’하지 않거나 ‘성장’하지 않는 DR시스템을 종종 목격하고 있다.
■변화하지 않는 이유
DR시스템이 변화하지 않는 이유는 ‘서비스중인 IT시스템’의 변화가 DR시스템으로 전달되지 않기 때문이다. ‘서비스중인 IT시스템’의 변화는 IT프로세스의 하나인 ‘변경프로세스’를 통해서 처리가 되는 것이 일반적이다.
변경프로세스가 잘 유지되고 있는 IT조직의 경우, ‘서비스중인 IT시스템’의 변화는 상당부분 변경프로세스를 통해 처리가 된다. 그러나, 이런 IT조직이라 하더라도, 변경프로세스에서 반드시 수행해야 하는 변경 영향 평가 활동의 과정에서 ‘DR시스템’에 대한 ‘영향’을 다루지 못하게 되면 결과적으로 ‘서비스중인 IT시스템’의 변화가 ‘DR시스템’의 변화로 이어지지 못하게 된다.
변경프로세스가 부실한 IT조직의 경우는 ‘서비스중인 IT시스템’이 변화하더라도 변화가 일어났는지 아닌지를 조직이 알아채지 못하게 되므로, ‘DR시스템’이 정상적으로 변화하게 될 가능성은 ‘김포공항에 배가 들어올 확률’보다 낮다.
■변화하지 않아서 생기는 문제점들
DR시스템은 IT조직에서 ‘가장 중요’하다고 판단한 ‘서비스중인 IT시스템’을 대상으로 구축하는 것이 일반적이다. 그런데 가장 중요한 ‘서비스중인 IT시스템’은 변화 과정에서 다른 IT시스템과 연결관계가 추가되기도 하고, 또 특정 정보를 다른 IT시스템으로부터 논리적으로 공유할 가능성이 높다.
예를 들어, 가장 중요한 ‘서비스중인 IT시스템’을 ‘ERP시스템’이라 한다면, ERP시스템이 구축된 초기에는 거의 독립적으로 운영이 되지만, 시간이 지날수록 다른 IT시스템이 들러붙게 된다. 또, 초기에는 ‘ERP시스템 내에’ 존재하던 ‘인력 정보’가 인사시스템이 구축된 이후에는, ‘인사시스템 내에’ 존재하는 ‘인력 정보’를 원격에서 당겨오는 형태로 바뀌기도 한다.
이러한 변화가 DR시스템에 반영되지 않는 상황에서 재해가 실제로 일어나게 되면 어떤 상황이 벌어질까?
불행하게도 인력정보를 당겨오는 ‘인사시스템’에 대해서는 DR시스템이 구축되지 않았다면 사용자들은 ERP의 DR시스템에 ‘로그인’할 수 없다.
또 평소 ERP에 연결 관계를 가진 다른 시스템들은 재해 시에는 ERP의 DR시스템과의 인터페이스가 없는 관계로 일부 또는 상당 부분의 IT 기능이 작동되지 않는다. ERP시스템의 사소한 설정 파일 값 변경조차도 DR시스템에 반영되지 않을 경우 DR시스템 작동불능을 초래하는 결과로 나타날 수 있다.
■성장이 멈춰버린 이유
‘서비스중인 IT시스템’은 IT사용자의 수나 사용 회수가 증가하게 되면 ‘용량증설’을 통해 ‘성장’이 일어나게 된다. 그런데 ‘서비스중인 IT시스템’의 성장이 ‘DR시스템’의 성장으로 이어지지 ‘않는’ 경우가 많다.
그 이유는 여러 가지가 있을 수 있으나, 국내 IT조직 내부의 정서를 추정해보건 데, 초기에 많은 비용을 들여 수립한 ‘DR시스템’에 대해 또 투자해야 하는 이유나 필요성을 IT경영진에 납득시키기가 어렵다는 것이 가장 큰 이유가 아닌가 싶다.
‘서비스중인 IT시스템’의 용량증설은 당장 사용자들이 아우성을 치기 때문에 투자해야 하지만, DR시스템의 용량증설은 아우성치는 대상이 없기 때문에 ‘성장’이 취소되거나 유예되기가 쉬울 수 밖에 없다.
■성장이 중단되어 발생하는 문제
재해가 발생해서 성장이 멈춘 DR시스템을 사용자들이 사용하게 되면 어떤 상황이 벌어질까? IT시스템에 재해가 발생 했다는 소식을 사용자들이 접하는 경우, 사용자들은 IT조직을 걱정해주기보다는, 당장 자신의 업무와 관련 있는 IT시스템을 사용할 수 있는가에 관심이 집중될 수 밖에 없다.
따라서 재해가 발생하는 초기에는 IT시스템을 정상적으로 사용할 수 있는지를 확인하기 위한 사용자들의 접속으로 인해 오히려 사용량이 집중적으로 늘어날 수 있다.
성장이 멈춘 DR시스템은 이러한 사용량 집중을 소화해내지 못할 가능성이 크다.
게다가 초기의 집중적인 접속이 사라지고 일상적인 사용 수준으로 돌아간다 하더라도, 성장이 멈춘 DR시스템이 사용자가 인내심을 유지할 수 없을 정도로 속도가 느리다면, DR시스템뿐만 아니라 IT조직에 대한 사용자들의 불만과 비난이 쏟아지는 것은 불을 보든 뻔한 일이다.
평소 IT조직으로부터 DR시스템의 구축에 대한 자랑을 귀가 따갑도록 들어온 사용자들은 이러한 상황을 이해할 수가 없다. DR시스템과 IT조직에 대한 사용자들의 불신이 하늘을 찌르게 되는 순간이다.
IT조직은 이러한 상황이 벌어지게 된 근본적인 원인 중의 하나가 사용자측이 DR시스템에 대한 지속적인 투자에 대해 그 동안 긍정적이지 않았다는 ‘속사정’을 내세워 억울해 하겠지만, 이러한 속사정은 IT의 ‘일반사용자’들에게는 전혀 받아들여질 수가 없다.
■재해시 100% 미만의 성능을 허용하는 경우
재해 시에는 IT의 사용을 제한하고 필수 사용자에게만 허용하겠다는 정책을 사용자측과 IT조직이 합의하는 경우가 있다. 최소한의 투자비용으로 DR시스템을 갖추는 것을 두 이해당사자가 합의한 것이다.
‘서비스중인 IT시스템’의 성능을 100%로 본다면 DR시스템에 대해서는 그 이하 수준, 예를 든다면 70% 수준의 성능을 허용하겠다는 것이다. 이러한 성능 수준에 대한 합의는 DR시스템의 당초 도입 목적인 IT서비스의 ‘연속성’ 원칙을 깨뜨려서는 안 된다.
사용자들의 업무 프로세스를 진행하지 못할 정도의 IT성능은 IT측의 재해라는 특수한 상황을 고려하더라도 사용자 입장에서는 받아들일 수가 없다. 또, 낮은 성능 수준을 합의한 것은 정상 수준을 100%로 놓고 합의한 ‘비율’이므로 ‘서비스중인 IT시스템’이 성장하는 경우, DR시스템도 합의한 비율만큼 성장시켜주어야 한다. 국내 IT조직의 DR사이트 구축과정을 들여다 보면 이러한 논의가 진행되었다고 보기가 어려운 경우를 자주 만나게 된다.
■DR의 지속적인 ‘변화’와 ‘성장’을 유지하려면?
‘서비스중인 IT시스템’의 용량증설을 하는 경우, ‘묻지도 따지지도 않고’ DR시스템의 용량증설을 똑같이 시행하는 글로벌 IT조직을 본 적이 있다. 이러한 단순 무식(!)한 DR시스템 용량증설 ‘원칙’을 이 IT조직이 유지하는 이유는 돈이 많아서가 아니라, 수 십 년간의 IT 운영경험에 바탕으로 재해 시 실패하지 않는 가장 좋은 원칙을 스스로 찾아낸 것이다.
DR시스템의 변화와 성장을 보장하기 위해서는 IT서비스를 연속하기 위한 원칙이 흔들리지 않고 유지되어야 한다.
‘변경 프로세스’를 통해 ‘서비스중인 IT시스템’의 모든 변화가 DR시스템의 변화로 반드시 이어지도록 하겠다는 원칙과 ‘용량프로세스’를 통해 ‘서비스중인 IT시스템’의 성장과 DR시스템의 성장이 일치하거나 또는 ‘동일한 비율’로 성장할 수 있도록 보장하겠다는 원칙이 지켜져야 한다.
이 원칙은 사소한 변경도 빠뜨리지 않고 영향평가를 해낼 수 있는 변경 프로세스의 디테일과 사용자 업무부하 변동과 IT시스템의 성능 제공 능력간의 ‘함수’를 읽어낼 수 있는 용량 프로세스의 능력이 바탕이 되어야만 달성 가능하다.
업무상 IT조직을 방문하게 되면, IT 조직이 보여주는 DR시스템에 대한 자부심과 신뢰의 수준이 나의 예상을 넘어선다고 느낄 때가 많다. DR시스템의 변화와 성장을 유지하는 것이 얼마나 까다로운 일인지, 또 이것이 견고한 IT프로세스를 통해서 가능하다는 것을 알고 있는 나로서는, 그 IT조직이 자랑하는 DR시스템의 ‘외형’보다는 그 조직의 IT프로세스 수준이 마음에 걸리기 때문이다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.
