자칫하면 기업이 ‘흔들’··· CIO의 흔한 실수 8가지

1: 벤더 록인
중요도: 2
일종의 ‘유혹’이다. 벤더들은 낮은 가격과 수 많은 약속으로 IT 책임자인 당신을 꼬드긴다. 이렇게 꼬드긴 후, 자신의 수중에 들어 온 고객을 절대 놓아주지 않는다.

쿠델스키 시큐리티(Kudelski Security)의 앤드류 하워드 CTO는 “거의 모든 벤더가 제품을 판매하고, 고객 환경에 입지를 구축하기 위해 이렇게 한다. IT 관리자는 좋은 의도로 시작을 하지만, 벤더를 교체할 수 없게 된다. 결국 벤더가 IT 자산을 크게 통제하고 있으며, 가격 협상력을 쥐고 있다는 사실을 깨닫는다. 이렇게 벤더를 잘못 관리하는 바람에 해고를 당한 IT 관리자들도 있다”라고 지적했다.

하워드는 록인에 장점 몇 가지가 있다는 점도 인정했다. 무엇보다 대량 조달에 따른 할인을 받을 수 있다. 또 같은 벤더가 공급하는 제품들이기 때문에 통합이 원활하고, 보안도 더 튼튼히 만들 수 있다. 이 밖에 상대할 벤더 수가 줄어드는 것도 장점이 될 수 있다. 규모가 작은 조직에 적합할 수 있다.

그러나 옮기기로 결정을 할 때, 벤더가 여기에 도움을 줄 것으로 기대한다면 지나치게 순진한 것이다. 하워드가 컨설팅 회사에서 일했을 때의 일이다. 그의 회사는 다른 벤더로 옮기고 싶었다. 그러나 관계를 맺고 있던 워크플로 관리 벤더가 소스 코드를 넘겨주지 않아 벤더를 바꾸는 데 어려움을 겪었다. 최초 SLA에는 이런 내용이 포함되어 있었지만, 추후 협상 과정에서 사라져 버린 데 따른 결과였다.

벤더 록인과 관련해서는 클라우드 마이그레이션이 빠질 수 없다. 그는 “많은 파트너들이 PaaS 공급업체와 동일한 문제를 겪고 있다. 일단 투자를 하면, 경쟁 업체로 인프라를 마이그레이션 하기 어렵다”라고 설명했다.

이런 이유로 하워드가 알고 있는 CIO들 중에는 여러 클라우드 공급업체를 이용하고, 튼튼한 기술 관리 정책을 수립해 적용하는 방법으로 위험을 ‘헷징’하는 CIO들이 많다. 그는 IT 관리자가 조달 부서와 더 밀접히 협력, 특정 벤더에 지나치게 의존하는 문제를 피해야 한다고 강조했다.

그는 “기술을 다각화할 필요가 있다. 가장 저렴한 선택지가 가장 좋은 선택지가 되지 못하는 때가 많다. 때론 단기적인 어려움이 장기적으로 이익이 될 수도 있다”라고 말했다.

 2: 클라우드를 내부 데이터센터의 ‘연장선’으로 취급
중요도: 2
2016년 2월, 개인 대출 업체인 베스트 에그(Best Egg)는 VM웨어 기반의 프라이빗 클라우드를 아마존 웹 서비스(AWS) 기반 퍼블릭 클라우드로 마이그레이션 했다. 이 P2P 대출 서비스 업체는 계획 수립과 구성, 저수준 서비스 마이그레이션에 몇 달이라는 시간을 투자했다. 또 보유 서버와 AWS를 1대1로 매핑했다. 그리고 모든 준비가 완료됐다는 판단을 내렸다. 하지만 가동 후 2시간 만에 아주 중요한 AWS 서버가 멈추는 문제가 발생했다.

베스트 에그의 파트너인 말레트 펀딩(Marlette Funding)의 브라이언 코닌 CIO/CTO는 “첫 날, 경종이 울렸다. 1개 클라우드 서버의 안정성이 직접 관리하는 서버나 가상머신 보다 못하다는 점이 드러났다. 클라우드의 99.999% 업타임을 오해하면 안 된다. 이는 고장난 서버들를 새 서버들로 동적으로 프로비저닝하는 상황에 해당한다”라고 설명했다.

다행히 주말 동안 발생한 사고였기 때문에 다운타임을 초래하지 않고 복구할 수 있었다. 그러나 코닌은 값진 교훈 하나를 얻었다. 클라우드를 보유 데이터센터에 위치한 머신으로 취급해서는 안 된다는 교훈이다.

이후, 베스트 에그는 클라우드 환경 최적화를 우선순위 1번으로 중시했다. 우선순위 2번은 무엇일까? 클라우드 비용을 계속 주시하는 것이다.

그는 “누군가 원할 때마다 서버를 프로비저닝 할 수 있다. 자주 이렇게 하면, 얼마 지나지 않아 계획한 예산의 2-3배를 지출하게 된다”라고 지적했다.

코닌은 또한 서버를 ‘처분’할 수도 있다는 점을 배웠다. 고장이 나면, 그냥 버린다는 의미이다. 베스트 에그는 수 많은 백업을 구성하고, 조금의 다운타임도 허용되지 않는 시스템에 여러 서버를 할당하고, 문제가 있을 때 자동으로 새 서버가 프로비저닝 될 수 있도록 만들었다.

이제 새 소프트웨어를 배포하는 경우, 새로운 서버가 구축되어 코드가 심어진다. 그리고 기존 서버는 없어진다.

그는 “퍼블릭 클라우드의 강점에 맞게 인프라를 구축해야, 퍼블릭 클라우드의 이점을 누릴 수 있다. 클라우드로 서버를 마이그레이션 하는 것만으로 불충분하다. ‘사고방식’과 ‘접근법’도 마이그레이션 해야 한다”라고 강조했다.

3: 비즈니스 케이스를 지나치게 ‘치장’
중요도: 1
아주 오랜 기간 CIO의 머리를 복잡하게 만든 ‘관념’ 한 가지가 있다. 대형 IT 예산 지출을 승인 받기 위해서는 튼튼한 비즈니스 케이스를 구축해야 한다는 생각이다. 관리자는 선택지 조사, 통계 조사 및 분석, 파워포인트 작성에 몇 주를 소비한다.

그러나 비즈니스 리더가 CIO의 제안을 수용하지 않을 경우 헛일이 되는 경우가 많다. 클라우드 기반 ID 서비스(Identity-as-a-Service) 공급업체인 옥타(Okta)의 마크 세틀 CIO는 “몇 년 전, 포춘 200대 기업의 CIO가 되기 위해 면접을 했을 때, CFO에게 비즈니스 케이스의 중요성을 강조한 적이 있다. 그러나 그 CFO는 비즈니스 케이스의 ‘숫자’는 믿지 않는다고 말했다. 그는 비즈니스 리더가 새로운 기능과 역량을 전력으로 활용할 경우에만 대형 IT 이니셔티브를 승인한다고 강조했다”라고 말했다.

물론 인프라나 컴플라이언스에 필요한 지출은 ‘예외’이다. 하지만 모든 전략적 IT 이니셔티브에는 비즈니스 부문의 열정적인 후원자가 필요하다. 경영진의 신뢰를 얻으면, IT 관련 업무를 수월히 처리할 수 있고, 전사적으로 협력해 기존 프로세스를 개선할 수 있다. 이렇게 하면, 전략적인 기회가 발생했을 때 비즈니스 부문 리더들이 CIO의 아이디어에 귀를 기울인다.

그는 “경영진의 후원 없이 스스로 책임을 떠안으면서 비즈니스 케이스를 지나치게 치장하는 행위는 스스로를 더 어렵게 만드는 행위다”라고 강조했다.

4: 자신보다 못한 사람을 채용
중요도: 2
성공을 위해서는 성공해내는 팀이 필요하다. 그러나 태도가 나쁘고, 능력이 부족한 단 한 명의 직원이 모두를, 모든 것을 망칠 수 있다.

리크루팅 회사인 스트라이드 서치(Stride Search)의 데릭 존슨 사업 개발 VP는 “IT 관리자가 저지르는 가장 큰 실수는 자신보다 못하고, 자신보다 똑똑하지 않은 사람을 채용하는 것이다”라고 말했다.

불행히도, 관리자의 자존심이 인재 선택을 가로막는 경우가 잦다. 스트라이드 서치는 3년 전 고객인 SaaS 신생 창업회사에 딱 맞는 네트워킹 및 소프트웨어 엔지니어 한 명을 찾았다. 커뮤니케이션 능력이 뛰어나고, 카리스마가 있으며, 컴퓨터 사이언스 박사로 몇몇 특허까지 보유한 인재였다. 모든 사람이 이 인재를 마음에 들어 했다. 그러나 단 한 명 예외가 있었다. 고객사의 CTO였다.

존슨은 “전화 인터뷰는 잘 되었다. 그러나 대인 면접이 ‘재앙’이었다. 공동 창업자 겸 채용 책임자였던 CTO는 자신이 우월하다는 점을 보이고, 인재를 모욕하는 데 면접 대부분의 시간을 썼다. 나머지 경영진은 취업을 제안하기 원했지만, 이 CTO가 반대했다. 결국 이 인재는 경쟁 회사에 취업을 했고, 해당 신생 창업회사를 몰락시켰다. 이런 일이 많다”라고 말했다.

해결책은 뭘까? 고위직의 자존심을 들어내야 할까? 이 어려운 방법보다 더 쉬운 방법이 있다. 단 한 사람이 채용을 거부할 수 없도록 만드는 것이다. 고위직의 경우, 경영진과 이사는 물론 후보자의 부하로 일할 직원들도 채용에 관여해야 한다.

그는 “’A급 인재는 A급 인재를 채용하고, B급 인재는 C급 인재를 채용한다’는 경구가 적용되는 사례이다. 중요한 자리에 적합하지 못한 인재를 채용하거나, 적합한 인재를 그냥 떠나 보내는 것은 ‘재앙’이다”라고 말했다.

5: 잘못된 내부 승진
중요도: 2
유능한 외부 인재를 채용하지 않는 것이 실수인 만큼, 잘못된 내부 승진도 실수이다. IT 소프트웨어 회사인 우노스퀘어(Unosquare)의 지안카를로 디 비시 대표에 따르면, 일반적으로 내부 승진은 아주 좋은 정책이다. 그러나 근거가 타당해야 한다.

근거가 타당하지 못한 승진은 어떤 승진일까? 충성에 대한 보상, 커리어 경로 제공이 근거인 승진, 스스로 좋은 매니저라는 위안을 받고 싶어 단행한 승진을 예로 들 수 있다. 이는 승진시킨 직원이 새로운 직책에 준비가 되어 있지 않은 경우를 중심으로, 스스로 문제와 피해를 초래하는 행위이다.

디비시는 “IT 관리자가 우수한 부하 개발자를 책임자로 승진시켰지만, 이 사람이 책임자 역할에 적응 못해 회사를 그만두는 사례들이 있다. 부하 직원에게 승진 기회를 줘야 좋은 상사라고 생각할지 모르겠다. 그러나 승진 때문에 부하 직원을 잃을 수도 있다. 해당 직원이 정말 좋아하는 일을 빼앗은 셈이기 때문이다”라고 말했다.

디비시는 자신도 약 1년 전에 직접 경험한 일이라고 말했다. 그는 우노스퀘어의 가장 큰 고객사 중 한 곳을 위해 유능한 개발자를 채용한 후, 고속 승진시켰다. 이 개발자는 얼마 지나지 않아 5개 팀을 관리하는 역할을 맡았다. 3개월 동안 모든 것이 순조로웠다. 그러나 이 개발자는 디비시의 사무실로 찾아와 사직서를 제출했다.

팀은 성과를 일궈내고 있었지만, 이 개발자는 자신이 해야 할 일을 하지 못했다고 생각했던 것이다. 디비시는 이 개발자가 회사에 남도록 설득할 수 없었다.

그는 “커리어를 발전시킬 기회를 제공한다고 생각했지만, 실제로는 아주 유능한 프로그래밍 인재를 잃는 결과가 야기됐다”라고 말했다.

디비시는 이를 계기로, 이후 새로 승진한 직원이 정기적으로 피드백을 제공하고, 제공받고, 상사가 업무를 면밀히 관찰해, 해당 직원을 성공시키는 프레임워크(틀)를 만들었다.

디비시는 여전히 내부 승진이 좋다고 생각한다. 그러나 항상 그런 것만은 아니라는 점 또한 인식하고 있다. 관리자는 지혜롭게 내부 승진을 단행해야 한다.

6: 애자일 기법을 핵심 시스템에 적용
중요도: 3
클라우드 서비스가 폭증하고, 기업의 속도에 대한 요구가 높아지고 있는 추세다. 이런 가운데 많은 부분이 CIO의 통제권을 벗어나고 있다.

쿠델스키의 하워드에 따르면, 클라우드 기반의 도커(Docker) 콘테이너 및 마이크로 서비스 구현에 도움을 주는 애자일 기법을 섣불리 적용하면 이메일, 전화, ERP, 기타 백오피스(지원) 애플리케이션에 ‘재앙적인 결과’를 초래할 수도 있다.

그는 “다른 어떤 문제보다도, 이메일 유지관리 문제 때문에 일자리를 잃는 CIO들이 많다. 이런 애자일 기법은 엄격한 관리가 필요한 핵심 시스템에 맞지 않는 경우가 많다. 핵심 시스템이 정지되면, 기업은 금전적 손해를 본다”라고 말했다.

이런 문제를 줄이기 위해서는 CIO가 확실한 경계선을 그려야 한다. 비즈니스 시스템에는 애자일 변경(변화)을 허락하고, 핵심 시스템은 더 엄격히 변경(변화)을 관리해야 한다. 하나로 모든 것을 해결할 수 없는 법이다.

그는 “애자일 기법을 적용한 부분이 핵심 시스템에 위험을 초래하는 일이 없도록 만들어야 한다. 도전과제는 확실한 경계선을 그려, 이 경계선을 지키는 것이 힘들 수도 있다는 것이다. 비즈니스는 속도를 요구한다. 그러나 신중하려면 변화가 느리고 체계적이어야 한다. 이 두 가지가 대립하면서, IT 관리자가 중간에 낀 상태가 되는 경우가 많다”라고 말했다.

7: 지나치게 자주 ‘YES’라고 대답
중요도: 2
고위 IT 관리자들은 혁신에 ‘NO’라고 말한다는 이유로 비난을 받는 경우가 많다. 그러나 더 큰 문제는 ‘NO’라고 말할 때를 모르고, 이로 인해 시스템 보안을 통제하지 못하는 위험이 초래되는 경우이다. 보안 회사인 앱솔루트(Absolute)의 리차드 핸더슨 글로벌 IT 보안 전략가는 “IT나 보안 담당자들은 ‘고위직’으로부터 위험한 액세스를 요구 받는 경우가 아주 많다. 또한 비즈니스 부서는 IT나 보안 팀의 조사나 승인을 거치지 않고, 새로운 클라우드 기반 도구나 서비스를 배포한다”라고 말했다.

클라우드 스토리지와 SaaS 솔루션 같은 도구들이 팀에 큰 이익이 될 수도 있다. 그러나 IT 관리자가 예외적인 요청을 모두 승인하는 경우, 조직에 새로운 ‘구멍’이 생기고, 이것이 새로운 ‘취약점’을 초래할 수 있다.

헨더슨은 CEO가 특별한 요청을 할 때, 이를 거절하기 어렵다는 점을 인정하며, 이런 드문 예외에 대처할 수 있는 계획을 수립해야 한다고 강조했다. 또 튼튼한 자산 관리 체계를 구현해야 한다. 엔드포인트 장치를 모니터링 하고, 사용자가 많이 사용하는 클라우드 서비스에 로그인 할 때 이를 알려주는 소프트웨어를 도입하는 것이 좋다.

지나치게 자주 ‘YES’라고 말하면, 모든 것을 패칭하고, 모든 준수해야 할 것을 준수하기 불가능하다. 마케팅 부서의 누군가 새 AWS 인스턴스를 도입하는 결정할 때, IT 부문을 우회하는 경우는 더욱 그렇다.

헨더슨은 “금지가 목적이 아니다. 서비스를 사용하는 사람과 팀이 데이터 보호에 필요한 최소한의 요건을 준수하도록 만드는 것이 중요하다. CIO는 ‘원한다면 지원하겠습니다. 그러나 반드시 지켜야 할 보안 측면의 기준이 있습니다’라고 말해야 한다”라고 강조했다.

8: 문제를 숨김
중요도: 3
대형 프로젝트가 잘못된 방향으로 나아갈 때, 일단 문제를 덮은 후 상사가 알기 전에 이를 바로잡으려 시도하는(희망하는) IT 관리자가 많다. 그런데 통상 여기에서부터 문제가 악화된다. 새로운 코드가 전체 시스템을 48시간 정지시켰으며, 프로젝트 완료에 400만 달러의 추가 예산이 필요하다고 털어놓을 시점에는, 이미 신뢰를 잃어버린 상태이다.

옥타의 세틀은 “나쁜 소식을 빨리 공개할수록 좋다. 나쁜 소식이 스스로 좋은 소식으로 변하는 법은 없기 때문이다. 사람들이 문제를 빨리 다뤄야, 프로젝트를 다시 정상 궤도에 올려놓을 확률이 높다”라고 강조했다.

나쁜 소식을 전달하기란 어렵다. 그러나 비즈니스 부문 책임자들과 좋은 업무 관계를 구축해 유지한다면, 여기에 도움을 받을 수 있다.

경영진을 처음 찾아가는 때가 ‘돈’이나 ‘용서’를 구하려 찾아가는 때가 되어서는 곤란한다. 이것이 지켜야 할 규칙 1번이다. 6개월 넘게 교류가 없었던 경영진, 처음 대면하는 경영진에게도 똑 같이 적용되는 원칙이다”라고 말했다.

IT 관리자는 위기 상황이 아닐 때, CFO를 비롯한 비즈니스 부문 책임자들과 대화를 할 기회를 만들어야 한다. 기술 분야의 사람들에게 쉬운 일이 아닐 수도 있다. 그러나 이런 스킬을 개발해야 한다.

세틀은 “농담이라도 해야 한다. 경영진에게 직면한 문제들을 이야기 하는 것이 좋다. 그래야 정말 큰 문제가 있을 때, 또는 ‘돈’이 필요할 때 훨씬 쉽게 대화를 할 수 있다”라고 강조했다.

* Dan Tynandms 마크 주커버그가 젖먹이였던 시절부터 기술 분야에 대한 글을 저술해왔다. 인포월드와 PC월드를 비롯해 지금껏 70여 곳이 넘는 매체에 글을 기고해왔으며 야후 테크 편집장을 역임했다.

dl-ciokorea@foundryco.com