CIO에게 아킬레스건이 있다면, ‘자기 기만’이다. 비즈니스와 IT의 정렬이 탄탄하다고 자신하며, 정보 보안이 굳건하
스코틀랜드의 소설가 월터 스콧(Walter Scott)은 “오, 우리는 어찌나 거짓말을 촘촘하게 이어나가는가! 우리가 처음으로 거짓말을 했을 때!”(Oh, what a tangled web we weave when first we practice to deceive)라고 말했다. 그러나 다른 사람에게 하는 거짓말 거미줄이 아무리 엉망이어도 우리가 스스로를 속일 때만큼 엉망은 아니다.
물론 의도적으로 우선순위를 잘못 설정하고 잘못된 결정을 내리며 잘못된 목표를 추구하지는 않는다. 그러나 희망 사항이라는 안경을 통해 세상을 보면서 훨씬 쉽게 스스로를 속인다.
CIO들이 자신의 IT 직원이나 동료가 아닌 스스로에게 하는 보편적인 9가지의 거짓말은 다음과 같다.
CIO의 자기 기만 #1: 우리는 비즈니스 부문과 잘 정렬돼 있다.
많은 CIO들이 ‘IT와 비즈니스의 정렬’을 위해 정교한 IT 거버넌스(Governance) 프로세스를 구성하고 있기 때문에 문제가 없는 것처럼 보인다.
그러나 애석하게도 비즈니스와의 정렬은 제대로 이뤄져 있지 않은 경우가 대부분이다. 그들은 파트리지(Partridge)보다는 달라스(Dallas)의 이윙스(Ewings)에 가깝다. 일반적으로 비즈니스 부문과의 정렬은 정치적인 권력자를 달래거나 차지백(Chargeback) 시스템을 구성하는 방식으로 이뤄진다.
차지백(Chargebacks)? 그렇다. 차지백이다. IT는 심부름센터와 같다는 생각이다. 프로젝트에 재정을 지원하는 한 무엇이든 원하는 것을 제공한다.
차지백은 IT가 비즈니스가 아닌 비즈니스 예산과 정렬되게 만든다. 그 예산이 비즈니스와 정렬돼 있다면 아무 문제가 없다. 만약 그렇지 못 하다면, 다른 누군가의 문제로 전환된다.
CIO의 자기 기만 #2: 소프트웨어를 업그레이드하는 유일한 이유는 새로운 버전이 중요한 비즈니스 가치를 제공할 때뿐이다.
이를 주장하는 CIO는 분명 비즈니스에 집중하고 있을 것이다. 또 기술 자체를 위한 기술 지출이라는 비난에서 자유로울 수 있을 것이다. 게다가 IT 예산은 최신 상태를 유지하는 비용을 감당할 필요가 없기 때문에 절감될 수 있다.
하지만 이를 주장하는 CIO는 충돌 후 수 세대의 기술을 건너뛰는 업그레이드를 경험해보지 못했거나 그렇게 했다 하더라도 책임을 회피했던 사람일 것이다.
소프트웨어 업그레이드는 예방적 유지보수이다. 지금 지불하지 않으면 나중에 지불해야 한다. 나중에는 금액이 더 커진다.
CIO의 자기 기만 #3: 업무에 중대한 프로젝트가 일정보다 뒤쳐졌다? 다음 단계에서 따라 잡아 납기를 지킬 것이다.
일반적으로 이렇게 진행된다.
비즈니스 케이스: 관리자들은 ROI가 절사율을 초과할 때까지 빈둥거리며 배배 꼬다가 수정된 가정이 여전히 완전히 합리적이지는 않더라도 최소한 약간의 운과 강력한 지원이 있다면 실행 가능하다고 스스로를 납득시킨다.
요건 및 사양: 요건 및 사양 예측 단계는 골칫거리일 뿐이다. 프로젝트가 클수록 모르는 것들이 더 많으며 그 모든 것들로 인해 상황이 더욱 복잡해진다. 요건 및 사양 단계는 항상 길지만 상관 없다. 우리가 어떻게든 해낼 것이다.
계획: 계획 작업이 실제 일정에 상관 없이 이루어진다. 그 누구도 일정을 제대로 살피지 않는다면 절망에 빠진 프로젝트 관리자는 타당한 일정이 계획될 때까지 빈둥거리며 있는다.
경고 신호: 프로젝트 상태를 나타내며 일정에 뒤쳐져 있고 구원할 길이 없지만 기한 전까지 충분한 시간이 있기 때문에 현실보다는 부정이 앞선다. 숙련된 프로젝트 관리자는 프로젝트가 이 단계에 도달하면 두 가지 조치를 취한다. 우선, 테스트 과정을 쥐어 짠다. 이를 통해 프로젝트와 팀의 복잡성이 녹색으로 바뀐다.
그리고 나서는 프로젝트로 인해 자신의 명성에 금이 가기 전에 구직 활동을 시작한다.
탈선: 새로운 CIO가 운행을 중지시킨다. 그의 전임자는 프로젝트 관리자를 탓한다.
CIO의 자기 기만 #4: 우리는 ITIL을 하고 있다.
의미론적으로 사소해 보일 수 있지만 ITIL을 ‘한다’는 개념이란 없다. ITIL은 프레임워크일 따름이다.
ITIL은 IT가 잘 해야 하는 것들을 목록으로 작성한다. 모든 상황에 효과가 있는 ITIL의 목록이란 없기 때문에 때문에 잘 하는 방법에 대한 처방도 없다. (믿지 못하겠는가? 작은 광고회사에 다니는 상황에서 IT를 어떻게 운영할지 생각해 보자. 이제 사이버 보안에 특화된 대형 정부 계약 기업에서 어떻게 운영할지 생각해 보자.)
애석하게도 많은 CIO들이 ‘ITIL을 하는 것’을 업무 지원 센터를 꽤 잘 운영하는 것과 동일시하고 있다.
CIO의 자기 기만 #5. 우리는 애자일하다.
워터폴(Waterfall) 애플리케이션 개발 기법에서 하나 이상의 애자일(Agile) 변종으로 이전했거나 그 과정에 있는 IT 부서들이 있다.
그러나 실제로는 수십 명이 애자일 혁신의 정신을 일절 무시하면서 스크럼(Scrum)의 모든 형식주의를 엄격히 준수하는 대신에 일정 형태의 ‘애자일폴’(Agilefall)을 따르고 있을 뿐이다
다른 여러 비즈니스 및 IT 사례와 마찬가지로 확인란을 체크하는 것과 확인란으로 추적하는 업무를 적절히 수행하는 것 사이에는 차이가 있기 마련이다.
애자일폴 함정을 피한 IT 부서들일지라도 그 중 절반은 다른 방향으로 우회했을 것이라 생각한다. 그들은 아길라(Agila)를 연습하고 있지 않다. 대신에 그들은 해퍼자드(Haphazard)를 구성했다.
CIO의 자기 기만 #6. 우리는 데브옵스(DevOps)를 하고 있다.
그렇지 않다. 심지어 애자일조차 하고 있지 못 하다.
데브옵스에 대한 이야기가 무성하지만 그 지지자들은 협업을 모른다는 사실을 알아야 한다. 애자일폴이 아닌 진정한 애자일은 데브옵스가 등장하기 오래 전부터 협업과 긴밀한 관계를 가졌지만 솔직히 개발자들은 IT 운영부서와 협업하지 않았다.
현실 속의 흔한 데브옵스는 애자일에 다음과 같은 것들이 추가돼 이뤄진다.
우선, 개발팀에는 순수하게 이기적인 이유로 IT 운영팀이 포함된다. 그들은 환경이 구축되기를 기다리지 않으며 CAB가 소프트웨어 변경사항을 배치할 때까지 기다리고 싶어하지 않는다. 둘째로 모든 곳에서 자동화가 이루어진다는 생각은 정말이지 좋은 생각이다. 그러나 단계를 거치면서 수동으로 소프트웨어 변경사항을 유도해야 한다는 것은 말이 안 된다.
셋째로 데브옵스가 애자일 변종들이나 워터폴과는 다른 점이 바로 소프트웨어가 항상 배치 가능한 상태라는 점이다. 대부분의 애자일 부서에게 있어서는 데브옵스와 스크럼이 완전히 호환되지 않는다. 칸반(Kanban)이 더 효과적이다.
비보를 전하게 되어 유감이다.
CIO의 자기 기만 #7: 우리에게는 고객 서비스 문화가 있다.
업무 지원 센터에서 낄낄거리는 소리를 들어보자. 업무 지원 센터 직원들은 사용자의 이야기를 무시한다. 고객 서비스 문화가 없다. 이런 것들은 존중으로 시작된다.
고객 서비스 문화의 부재로 인해 차지백 같은 부적합한 개념으로 이어진다. IT 청구서에 대해 논쟁하면서 시간, 에너지, 신뢰를 낭비하기에 훌륭한 기회이다.
‘고객 서비스 문화’가 왜 잘못된 생각인지 확실히 모르겠다면 ‘고객’이라는 단어를 삭제해보자. CIO는 IT에서 서비스 문화를 발전시켜야 한다.
서비스 문화가 있는지 없는지 어떻게 알 수 있을까? 고객의 이야기가 여전히 멍청하게 들린다면 없다고 보는 것이 맞다.
CIO의 자기 기만 #8: 우리의 정보 보안은 엄격하다.
애자일폴과 확인목록에 관한 이야기를 기억하는가? 확인목록이 있을 때 확인목록을 추적하는 수단으로 활용하는 대신에 확인란을 체크하는 것이 전부가 되는 경우가 많다. 정보 보안도 같은 문제가 발생하며 준수성 인증이 첨부된 경우에는 더욱 그렇다.
결제카드 산업보안 표준인 PCI가 떠오른다. 타깃(Target)이 PCI 준수성에도 불구하고 2013년 4,000만 명 이상의 고객 기록을 잃어버린 사실을 기억할 것이다.
CIO가 정보 보안이 엄격하다고 생각한다면 그 생각이 틀렸을 가능성이 높다. 정보 보안을 고민하는 CIO라면 몇 개의 구멍을 이내 떠올릴 수 있을 것이다.
CIO의 자기 기만 #9. IT 거버넌스 프로세스를 통해 비즈니스 가치가 높은 프로젝트에만 착수한다.
비즈니스 정렬에 대한 이야기 전체를 다시 해보자.
IT 거버넌스는 가치가 가장 높은 프로젝트에만 재정을 지원해야 한다. 그러나 그 프로세스가 얼마나 잘 구성되어 있는지에 상관 없이 처음부터 서로 ‘정렬’되지 않은 인물들이 여전히 이행하고 있다. 따라서 각 프로젝트의 비즈니스에 대한 가치를 추정하는 것 외에 최종 결정에는 흥정과 순수한 심술이 있다.
다른 불편한 현실도 있다. 비용 절감을 위한 프로젝트가 매출 증가를 위한 프로젝트보다 우선한다. 왜일까? 비용 절감은 비즈니스의 통제 하에 있다. 모든 것이 계획대로 이뤄지면 비용이 감소한다.
하지만 매출을 높이려면 내가 원하는 대로 고객들이 움직여야 한다. 그렇지 않은 경우가 많다. 그들에게 이래라저래라 지시할 수 없다. 그들을 설득해야 한다.
이 모든 이야기의 요약본을 원하는가? 다음과 같다. 확신이 든다면 잘못되었을 가능성이 높다는 것이다. 만약 자신이 CIO로서 이 9가지 주제 중에 확신이 드는 부분이 있다면 스스로에게 간단하게 질문해 보자. 나는 왜 그렇게 생각하고 있을까?
* Bob Lewis는 한 글로벌 IT 서비스 기업의 선임 컨설턴트다. dl-ciokorea@foundryco.com
