???? ???? ???? ?? ??? CIO? ?? ???? ??? ? ??? ??. ???? ?? ??? ???? ???? ?? CIO? ?? ??? ?? ? ??? ? ??. CIO의 업무는 리스크 비즈니스다. 주의를 기울이든 기울이지 않든 책임의 모든 부분에 위험이 따른다. 위험 감수(risk-taking)가 현명하고 유일한 길이라고 찬양하는 책들도 쏟아져 나오지만, 그 저자들은 CIO가 매일 직면해야 하는 가장 큰 위험, 즉 위험 감수를 실제로 지원하지 않으면서도 이를 설교하는 데 능숙한 경영진을 마주하지 않는다는 사실을 기억할 필요가 있다. 예를 들어 리더 중에는 위험 감수의 가치를 강조하면서 동시에 ‘사람들에게 책임을 물어야 한다’라고 주장하는 사람이 있다. 이것이 회사의 경영진이 자주 꺼내는 말이라면 위험 감수는 허황된 덕목에 불과해진다. 피해를 입지 않으려면 성공 가능성이 낮고, 혹시 성공하더라도 쿨 테스트를 통과할 수 있으며, 실패하더라도 큰 피해가 없는 무해한 이니셔티브를 몇 개 선정하는 것이 좋다. 그리고 이런 이니셔티브가 회사의 위험 감수 문화에 부합한다는 점을 명확하게 보여주는 파워포인트를 준비하고 경영진에게 홍보하라. 이니셔티브가 개시되면 위험을 감수한 것에 대한 공로를 인정받을 수 있다. 만약 이니셔티브가 실패하면 회사 경영진에게 이니셔티브가 애초에 실패할 운명이었음을 상기시키거나 해당 이니셔티브의 리더에게 책임을 물을 수 있는데, 이는 실패에 대한 비난을 피하고 누군가에게 책임을 묻는 힘든 일을 해내며 공로도 인정받을 수 있는 보호막이 된다. 전문가의 조언: 가장 귀찮게 하는 직원과 스폰서를 이니셔티브의 책임자로 지정하라. 최악은 이니셔티브가 성공해 마음에 들지 않는 사람들이 한두 가지 신세를 지는 경우다. 최선은 이니셔티브가 실패하고 그들이 책임을 지는 경우다. 손해 볼 건 없다. 위험 감수 대 위험 대응위험 감수를 장려하는 사람들은 종종 위험 감수에도 종류가 있다는 사실을 무시한다. 분명 위에서 설명한 것처럼 잠재적인 이점은 있지만 실패할 확률이 높은 이니셔티브도 있다. 하지만 또 다른 종류도 있다. 실제로 현실화될 수 있고 현실화될 경우 IT 조직과 비즈니스 협력업체에 심각한 피해를 입힐 수 있는 ‘구조적 위험’이다. 위험한 이니셔티브는 시작하지 않거나 잠재적인 이점을 무시하거나 회피할 수 있다. 구조적 위험도 무시할 수는 있지만, 그렇게 해서는 위험을 없앨 수 없으며 위험이 ‘현실화’될 경우 책임을 져야 한다. 몇 가지 예를 들어 설명해 본다. 애플리케이션 포트폴리오 합리화: 기술 아키텍처 관리의 기본적인 원칙은 필요한 각 서비스를 정확히 한 번만 채우는 것이다. 애플리케이션 포트폴리오가 합리화되지 않은 경우, 다시 말해 기능적으로 중복되는 여러 기능이 포함되는 경우에 기하학적으로 확장되는 동기화 컬렉션이 필요하게 되고 다른 취약점도 많이 발생하게 된다. 애플리케이션 포트폴리오가 합리화되지 않고 다른 아키텍처 계층의 합리화가 제대로 이뤄지지 않으면 한마디로 ‘위험’이 발생한다. 애플리케이션 포트폴리오를 합리화하면 이런 위험이 실현될 확률을 줄일 수 있다. 위험 관리 측면에서 보면 위험을 ‘예방’하는 것이다. ID 관리: 최신 보안 아키텍처에는 직원을 인증하고, 역할에 할당하고, 개인이 아니라 수행되는 역할에 권한을 할당하는 등 ID 관리를 위한 도구가 포함된다. ID를 제대로 관리하지 않으면 잘못된 사람이 잘못된 일을 할 수 있는 권한을 갖게 된다. 견고한 ID 관리 관행을 도입하면 여러 위험이 현실화될 가능성을 줄일 수 있다. 만약 조직이 예방 조치를 취했는데 위험이 현실화되는 경우라면 그 피해를 줄일 수 있다. 위험 관리의 사전적 의미에서 ‘예방’은 가능성을 줄이는 것이고, ‘완화’는 피해를 줄이는 것이다. 랜섬웨어: 인공지능으로 인해 랜섬웨어가 일선에서 밀려나긴 했지만 완전히 사라지진 않았다. 공격의 희생양이 될 수 있는 위험도 여전하다. 랜섬웨어 위험에 대처하기 위해서는 4가지 위험/대응 전략을 모두 취해야 한다. 예방(확률 감소), 완화(피해 감소), 최악의 결과로부터의 보장(비용을 분담하는 보험), 그리고 솔직하게 말하자면 마지막 위험 대응 항목인 ‘희망’, 즉 수용도 필요하다. 위험 대응의 한계어떤 일을 하든 위험에 완벽하게 대응하기란 불가능에 가깝다. 구체적인 위험 대응 항목을 소개한다. 예방: 예방은 위험이 실현될 확률을 줄여주지만, 위험을 제거하지는 못한다. 결국 위험은 현실이 되거나 되지 않을 것이다. 만약 현실화된다면, 누가 책임을 져야 할까? 이때 IT 위험에 대해 반박할 수 없는 법칙이 또 하나 적용된다. 성공적인 예방은 위험이 없는 상황과 구별할 수 없다는 것이다. 즉, 예방 조치가 효과를 보인다면, 위험을 부풀려 소란 피웠다고 비난을 받게 될 가능성이 있다. 완화: 완화는 위험이 현실화됐을 때 피해를 줄이는 것이다. 예방 조치가 완벽할 수 없듯이 완화 조치도 완벽할 수 없다. 위험이 현실화되면 완화 조치로 피해를 완전히 제거하기 어려우며, 피해가 발생하면 책임을 지게 될 수 있다. 그리고 혹시라도 예방 조치가 완전히 성공한다면, 불필요한 완화 조치에 예산과 노력을 낭비했다는 비난을 받을 수도 있다. 보험: 어떻게 돌아가는지는 잘 알고 있을 터다. 보험에 가입한 뒤, 보장되는 위험이 발생하지 않으면 보험료 낭비에 대해 비난을 받는다. 그리고 위험이 현실화되면 예방 실패와 불충분한 완화 조치로 비난을 받는다. 리스크의 핵심: 회사의 경영진이 진정으로 위험 감수를 중요하게 생각한다고 해도, 그들이 중요하게 여기는 위험은 IT 리더가 매일매일 처리해야 하는 주요 위험과는 거의 관련이 없다. 논쟁할 필요는 없다. 다만 위험한 이니셔티브와 구조적 위험 관리에 대한 대화를 분리해서 진행할 필요가 있다. 그렇지 않으면 기회를 놓치고 비즈니스를 위험에 빠뜨리는 2가지 위험을 감수해야 한다. * Bob Lewis는 IT 비즈니스 전략 및 통합 분야를 전문으로 하는 IT 컨설턴트다. dl-ciokorea@foundryco.com ???? ???? ??? ??? IT ??? ???? ??? ????! ??? ??? ??? ?????. ????