기술 책임자는 정기적으로 ‘소규모 위기’ 상황에 대응할 가능성이 높다. 하지만 정말로 끔찍한 일이 벌어졌을 때 어떻게 대응할까? 상황을 최대한 잘 관리하는 방법을 생각할 수 있도록 차분함을 유지하면서 리더십을 보여주는 방법은 무엇일까?
위기 상황이 닥치면 어떤 일이 발생하는지 살펴보자. 어떤 리더들은 문제에 정면으로 대응하지만 어떤 리더들은 불확실성 때문에 얼어버린다. 이런 위기 사고가 개별 운영 시스템에 영향을 끼치기도 한다. 때로는 대규모 혁신 프로그램에 영향을 끼쳐 조직의 명성이 바닥으로 추락할 수도 있다.
따라서 위기관리 능력도 혁신에 포함된다.
개인적인 예를 들어 설명해 보겠다. 수년 전 필자가 CUA에서 CIO직을 맡았을 때 우리는 주요 핵심 온라인 모바일 뱅킹시스템 변경을 준비하고 있었다. CEO는 이를 준비하면서 ‘위기 모드’로 실시하도록 제안했다.
그래서 관리팀과 혁신팀 전체가 모든 것이 안정될 때까지 2주 동안 하루에 4번씩 회의를 진행했다. 이 회의는 주말에도 열렸으며, 명확한 소통과 적절한 인원 확보가 직면한 상황과 시나리오에 대응하는 데 큰 차이를 나타냈다. 다른 기업에도 이런 특성을 적용하면 좋을 것이다.
1. 최악에 대비하라
포괄적인 계획으로 시작하는 것이 좋다. 위기 시에는 항상 예상치 못했던 요소가 발생하지만 위기관리 계획을 수립하면 공통의 이해와 체계를 적용할 수 있다.
새로운 위협이 등장하는 경우 항상 계획을 조정할 수 있지만 반드시 시작점이 있어야 한다.
계획은 공통의 위기 상황을 다루고 경영진, 직원, 고객에 신뢰를 제공하여 사건 발생 시에 적용할 수 있어야 한다. 위기 시에는 좌절감을 느끼는 것이 보통이기 때문에 미리 시간을 갖고 대응 방식 그리고 다양한 이해 당사자와 소통하는 방법을 예측해야 한다.
그리고 계획이 예상대로 실질적인 효과가 있는지 ‘시험’한다. 최근, 필자는 일본에서 근무하면서 북한에서 미사일 공격을 개시하는 경우에 대비한 위기 시뮬레이션 계획을 작성했다.
이는 당시 위기관리 계획에는 포함되지 않은 시나리오였으며, 임원들은 즉흥적으로 상황에 대응해야 했다. 또한 이 계획은 사이버보안 공격 이후에 해야 할 일에 대한 조항이 포함되어 있었다.
2. 사실을 파악하라
위기의 진짜 원인이 항상 명확한 것은 아니다. 위기팀을 동원하고 계획을 적용하여 상황을 해결해야 한다. 계획에서 팀은 이미 의사결정 지연을 방지하기 위해 업무 책임과 경험이 있는 이상적인 후보자를 확보해야 했다.
(때에 따라 CIO가 될 수 있는) 위기 책임자는 더욱 광범위한 팀을 동원하여 구체적인 사항을 조사하고 기저 원인을 판단해야 한다. 위기 중에는 실제 문제와 직접 관련되지 않은 증상이 먼저 보고되는 경우가 많다.
이를 위해서는 일반적으로 필수 지식과 역량을 갖춘 다양한 인력으로 구성된 팀이 필요하다. 하지만 이를 위해 위기 책임자의 명시적인 승인 없이는 내/외부에 전달할 수 없어야 한다. 이때, 미디어에 대한 교육을 받은 직원이 ‘준비된’ 성명서를 가져다가 잠재적인 대응의 초안을 작성하기 시작해야 한다.
3. 작전실을 마련하라
이런 장소를 미리 마련해야 한다. 위기가 발생하면 항상 팀은 같은 곳에 함께 상주해야 한다. 작전실은 적절한 기술(전화, 와이파이, 프린터, 프로젝터)과 함께 화이트 보드와 종이가 있어야 한다.
모두가 볼 수 있도록 벽에 위기관리 계획을 투사하고 두 번째 프로젝터로는 이벤트 기록을 보여주는 것이 이상적이다. 모든 팀이 진행 상황을 추적하고 정보를 널리 공유하려면 일정 수준의 투명성이 보장돼야 한다.
작전실은 위기 중 상시 운영해야 하며 다른 사람들이 이 공간에 침범하지 않도록 주의해야 한다.
4. 분위기를 만들라
위기 시에 팀은 당신을 찾는다. 차분하면서 도전하는 자세를 취해야 한다. 아직 희생양이나 비난의 대상을 찾기 시작할 때가 아니다.
이 문제를 해결하기 위해 노력 중인 사람들은 문제를 담당하는 사람들이기도 하다. 그들이 영향에 대해 걱정하도록 만들어도 적절한 분위기가 형성되지는 않는다. IT와 현업이 분위기를 조성해야 한다. 현업은 민감하고 초조해할 것이고 고장 정지에 대해 비난할 누군가를 찾을 수 있다.
차분하면서도 믿음을 유지하면서 걱정하고 소통해야 한다. 여러 팀이 핵심 및 온라인 뱅킹 시스템을 다운시킨 주요 위기에 관련된 은행의 고장 정지 사례를 목격한 바 있다.
이 경우에 문제가 어디에서 시작되었는지 확실하지 않았고 ‘책임 전가’가 발생했다. 무작위 비난은 상황에 도움이 되지 않으며 두 팀이 협력하여 문제를 해결해야 한다.
5. 자주 소통하라
항상 소통함으로써 분위기를 만들며, 이런 역할이 중요하다. 경영진에 알려 줄 확인 목록을 작성한다. 주요 위기를 인지한 즉시 경영진에 알린다. 일반적으로 의사소통 방법과 수단에 대한 프로토콜이 존재한다.
문제는 모두가 기저 원인과 제공되는 것 이상의 세부사항을 알고 싶어 한다는 점이다. 따라서 CEO, 임원 전체, 이사회에게도 고지해야 할 수 있다. 주요 위기는 세간의 이목을 집중시키며 잠재적으로 외부에 부정적인 영향을 끼치기 때문에 절대적인 주의가 필요하다.
6. 서비스를 복원하라
마법이 일어나서 위기를 방지했다. 때에 따라서는 건전한 자기 치유 메커니즘이 있지만 모든 시스템을 재부팅하는 것으로 해결될 때도 있다. 서비스가 복원되면 CIO와 팀이 모두 한숨 돌리게 된다.
하지만 아직 일이 끝난 것이 아니기 때문에 긴장의 끈을 놓아서는 안 된다. 실질적인 영향 그리고 이 위기로 인해 발생한 의도하지 않은 문제를 파악하려면 포괄적인 점검과 확인이 필요하다. 이제 IT운영에 대한 영향은 끝났지만 비즈니스 운영 문제가 증가하고 있으며 ‘기저 원인’ 분석 마무리에 주의를 기울여야 한다.
7. ‘실천 후 검토’하라
다음에 답하기 위해서는 군대에서 사용하는 전통적인 ‘실천 후 검토’가 필요하다.
• 의도한 결과는 무엇이었나?
• 실제 결과는 무엇이었나?
• 이러한 차이가 왜 발생했는가?
어떤 교훈을 얻었는지 정리하려면 위기 후 10일 이내에 팀을 소집하도록 해야 한다. 매우 고통스러울 때도 있지만 완료한 후 다양한 관리 거버넌스 프로세스를 통해 보고해야 한다.
때로는 잠재적으로 꽤 파괴적일 수 있지만 중립적인 써드파티를 통해 실시하는 것이 이상적이다. 이 마지막 단계에는 규제자와 외부의 고객/파트너가 개입할 수 있기 때문에 안심하지 말자.
사실 주요 IT 위기를 방지하는 것은 불가능하다. 앞서 언급했듯이 혁신 활동으로 이런 일이 발생할 수 있게 된다. 우리는 이런 움직임이 기업에 긍정적인 변화를 일으킬 수 있기 때문에 포용하고 환영해야 한다.
행운을 빈다.
*David Gee 일본 메트라이프생명 CIO며 그 전에는 CUA CIO를 지냈다. ciokr@idg.co.kr