IT 부서를 운영하면서 실수를 저지르고 있는 건 아닐지 걱정되는가? 하지 말아야 할 목록에는 없을 법한, 하지만 여전히 주의해야 할 8가지 잘못을 소개한다.
CIO라면 더 효과적으로 일하는 방법에 대한 조언을 다양한 경로로 받을 수 있다. CIO.com이 제공하는 CIO 서바이벌 가이드의 베스트 프랙티스부터 수많은 기사와 기고, 그리고 가트너, 포레스터, 맥킨지 같은 여러 컨설팅 회사에 이르기까지 다양하다.
이런 자료 대부분은 CIO가 우선순위로 삼아야 할 과제를 나열하고 있다. 대개는 너무 뻔해서 ‘당연한 소리 대장’이 쓴 듯하지만, 그렇다고 틀린 말은 아니다. 문제는 너무 반복적이라는 점이다. 그래서 이번에는 어디서도 쉽게 들을 수 없는 조언을 해보고자 한다. 절대로 해서는 안되는 ‘대죄(mortal sin)’가 아니라 IT 책임자가 저지를 수 있는 8가지 ‘소죄(Venial Sin)’를 정리했다.
리더십 없이 관리에만 몰두한다
시작부터 거짓말을 했다. 이 역시 하나의 가벼운 죄다. ‘관리만 하고 리더십은 없는’ 문제는 이 목록에서 처음 듣는 이야기가 아니라 오히려 지나치게 자주 접했을 가능성이 높다.
다리가 없는 개에 관한 오래된 농담이 있다. 주인은 매일 아침 그 개를 밖으로 끌고 나갔다고 한다. 리더십은직원들을 억지로 끌고 가는 것과 스스로 올바른 방향으로 움직이게 하는 것의 차이를 만든다.
관리 없이 리더십에만 몰두한다
CIO는 결과물을 내놓는 데 책임이 있다. 관리란 바로 그런 일이다. 맡은 조직이 성과를 내도록 만드는 것이다.
리더십은 이를 달성하는 데 유용한 도구다(앞서 언급한 개를 다시 참고하자). 하지만 전부는 아니다. IT 자체가 하나의 도구이고, 업무 프로세스를 최적화하는 각종 이니셔티브도 그렇다. 리더십에만 지나치게 집중하다 보면, 직원들에게 영감을 주는 데만 몰두한 나머지 정작 본연의 임무를 놓치게 된다.
차지백을 두고 논쟁한다
차지백 제도는 ‘훌륭한 이론이지만 현실성은 없는’ 사례에 해당한다. 이론적으로는 비용센터 책임자에게 IT 자원 사용에 따른 비용을 부과하면, IT에 요청하는 내용이 더 신중해질 수 있다.
하지만 문제는 IT 부서가 이 비용을 계산하는 방법이다. 방법은 두 가지다. 첫 번째는 단순한 방식이다. 예컨대 회사 전체 인원 수나 예산 비율을 기준으로 IT 예산을 나누는 식이다. 누구나 이해하기 쉬운 방식이다. 두 번째는 정교한 방식이다. IT 자원별 단가를 계산하고, 사용량을 추적한 뒤 이를 곱해서 산출하는 식이다.
단순한 방식은 포기하자. 이해하기 쉽다는 장점이 있지만, 비용센터 책임자가 IT 사용량을 줄여도 차지백 비용을 줄일 수 없는 구조라면 이론 자체의 취지를 훼손한다. 정교하고 정확한 방식을 선택해도 문제는 있다. 이 방식은 복잡한 만큼 수많은 가정이 필요하고, 대부분은 입증이 어렵다. 그런 방식으로 계산한 금액이 과연 맞는지에 대한 끝없는 논쟁이 벌어진다.
어느 쪽이 이기든 간에, 서로 낭비한 시간이 곧 비용이고, 결국 같은 돈이 어느 주머니에서 빠져나가느냐의 문제로 귀결된다. 차지백 제도는 그냥 포기하자.
기술 전문가가 아닌 ‘비즈니스 전문가’가 되려 한다
이 조언도 수도 없이 들었을 것이다. 어떤 기업은 IT 책임자에게 CTO라는 직함을 붙이면서, 정작 그 자리에 기술 전문가가 아닌 사람을 앉히는 경우도 있다. 이 얼마나 모순인가?
그러니 이제 그만 놓아주자. 애초에 두 가지를 비교하면 ‘비즈니스 전문가’가 되는 게 훨씬 쉽다. 그런데 기업의 CFO는 재무 전문가가 아니라 비즈니스 전문가여야 하고, CMO는 마케팅 전문가가 아니라 비즈니스 전문가여야 한다고 생각하지 않는 이상, 이 논의는 할 가치가 없다.
하지만 어쨌든 여기까지 읽었으니 한 가지 충고는 남기고 싶다. 기술 전문가가 되길 포기하고 비즈니스 전문가가 되려는 CIO는, 마치 고등학교 시절 ‘인기 많은 아이들’ 무리에 끼려고 안간힘 쓰는 외톨이와 다르지 않다. 그 무리에 끼지는 못하고, 오히려 절실함만 눈에 띄어 더 안쓰러운 모습이 될 뿐이다.
아키텍트를 동사로 사용한다
어디까지나 개인적인 의견이지만, 동사로서 ‘architect’는 ‘engineer’보다 더 구체적인 의미를 전달하지 못한다고 생각한다. “해법을 architect해야 한다”라고 말하는 사람을 보면, ‘비즈니스 전문가 클럽’에 끼지 못한 채 ‘기술 전문가 클럽’에라도 들어가려는 모습이 떠오른다.
베스트 프랙티스라는 표현을 사용한다.
이건 지고 있는 싸움이라는 걸 잘 안다. 어떤 사람이 ‘베스트 프랙티스’라고 말하면서 실제로는 좋은 방법, 검증된 방식, 최소한의 기본 수준을 뜻한다면, 그 표현을 지적하는 것은 “hopefully”를 “I hope”라는 뜻으로 잘못 썼다고 시비 거는 일만큼이나 헛수고다.
프로젝트 관리에서 제품 관리로 초점을 옮긴다
프로젝트 관리는 조직이 계획적이고 의도적인 방법으로 내일을 어제와 다르게 하는 일이다. 반면에 제품 관리는 기업의 제품 또는 제품군을 시장에서 매력을 유지하고 향상시키기 위해 관리하는 비즈니스 기법이다.
IT 제품 관리는 애자일 방법론에서 비롯된 개념이며, 비즈니스 제품 관리와는 연결고리가 매우 약하다. 물론 기업의 기술이나 애플리케이션 포트폴리오 중 일부의 매력을 개선하는 데 어느 정도 의미가 있긴 하다. 그러나 IT 제품 관리의 본질은 그게 아니다.
IT 제품 관리의 핵심은 책임 소재와 의사결정 권한을 설정하는 일이다. 과연 IT 제품 관리가 프로젝트 관리와 충분히 다르고, 또 관심을 가질 만큼 충분히 좋은가? 아닐 것이다. IT 제품 관리는 새로운 사실이라고 하기 보다는 잘못된 이분법에 가깝다.
CIO의 역할을 잘못 이해한다
4번째 실수에 빠져 비즈니스 전문가가 되려고 애쓰지 않았다는 것을 축하한다. 하지만 반대로, 기술 전문가가 되겠다는 쪽으로 진자처럼 흔들리는 것도 조심해야 한다. 기술 쪽으로 기울면 결국 기업의 ‘수석 비즈니스 애널리스트’가 되려는 방향으로 나아가게 되는데, 이 또한 그 나름대로 잘못된 역할 이해다.
물론 CIO는 기술 관련 사안에 대해 기업의 비즈니스 리더 및 관리자와 전략적인 대화를 나눌 수 있을 만큼은 기술에 익숙해야 한다. 또 IT 기술 인력과의 소통에서도 이해할 수 있는 수준의 기술 역량은 필요하다.
하지만 CIO의 역할은 그런 것이 아니다. CIO의 진짜 역할은 조직을 만드는 일이다. 비즈니스에 통합되어 있고, 효과적으로 운영되며, 기업의 모든 아키텍처 계층에 걸친 기술 포트폴리오를 관리하고, 뛰어난 기술 인재를 유치하고, 채용하고, 성장시킬 수 있는 그런 조직을 만드는 것이다.
CIO가 저지르기 쉬운 이른바 ‘소죄’를 모두 살펴봤다. 다음 과제는 무엇부터 바로잡을 것인지 정하는 일이다. 이 중 하나라도 집중해서 개선할 시간이 있다면, 두 가지 가능성 중 하나다. 꽤 훌륭한 CIO라는 뜻이거나, 아니면 현실을 전혀 못 보는 수준이라서 뭘 해도 소용이 없는 상황이다.
dl-ciokorea@foundryco.com
