쓰라린 진실을 직면할 시간이다. 솔직히 말해 당신의 IT 부서는 너무 느리다. 의도가 좋다는 점은 인정하지만 결과는 신통치 않다. 현실 비
IT가 ‘느리다’는 건 무슨 뜻일까? 간단하다. 다른 부서에서 IT의 결과물을 기다려야만 하는 상황이 생긴다면, 그건 IT 부서의 일 처리가 느리다는 뜻이다. ‘좀 느려도 제대로’ 하는 것을 강조하는 시대라 해도 여전히 현실은 ‘경쟁 업체보다 더 빨리’인 경우가 많다. 협업 부문의 갈 길을 IT가 지체시키고 있다면 기업 최고 책임자들이 IT 부서에 대한 인내심을 잃는 것도 무리는 아니다.
IT 부서 일 처리를 더욱 빠르게 하고픈가? 그렇다면 우선 병목현상을 일으키는 저해 요소들부터 찾아보자. 여기 IT의 발목을 잡는 대표적 요소 12가지를 꼽아 보았다.
No. 1: 운영 방식(Governance)
No. 2: 멀티태스킹
No. 3: 프로젝트
No. 4: 매뉴얼 프로비저닝
No. 5: 통합(integration)보다 인터페이스 중시
No. 6: 셰도우 IT의 지나친 통제
No. 7: 100점짜리 솔루션을 고집하는 것
No. 8: 데이터 웨어하우스
No. 9: TCO만 강조하기
No.10: ‘고 충실도’ IT 아키텍처에 대한 강요
No. 11: 현 상태에 안주하는 기업 문화
No.12: 비즈니스/IT 관계 구축 실패
No. 1: 운영 방식(Governance)
위원회는 낡은 운영 방식이다. 위원회가 개입하면 모든 것이 느려진다. 그런 위원회를 IT 운영의 중심으로 두고 있다면? 아무리 노력해도 IT 부서의 작업 속도가 바닥을 기는 것이 당연하다.
위원회의 규모부터 줄여나가자. 위원회 사이즈가 커질수록 의사결정 속도도 느려진다. 멤버가 다섯 이상이 되면 더 이상 의견 합의는 불가능에 가까워지고, 업무 처리 속도가 급속히 느려지기 시작한다.
게다가 위원회 멤버들이 스스로를 IT 부서 의사결정의 일원으로 여기지 않고 스스로의 몫을 챙기기 급급하다면 문제 해결보다는 무의미한 논쟁에만 매달리게 될 확률이 더더욱 높다.
미팅 스케줄도 문제다. 미팅 스케줄은 위원회가 주관하는 모든 프로젝트의 페이스를 결정하는 메트로놈 같은 존재다. 위원회의 미팅에 한 달에 한 번 열릴 경우 아무리 급한 결정이라도 한 달을 기다려야만 답을 들을 수 있다. 이런 장애물을 안고 성공할 수 있는 프로젝트가 몇 개나 되겠는가?
위원회가 초래하는 이런 문제들을 어떻게 해결하면 좋을까? 운영 방침으로 위원회의 의사 결정 대신 직원들간의 공감대와 합의 형성을 추천한다. 위원회는 더 이상의 해결책이 없을 때를 대비한 최후의 보루로 남겨두고, 대신 직원들의 합의로 위원회의 역할을 대체하라. 직원들 모두가 가장 중요한 것이 무엇인지, 또 무엇에 집중해야 하는지 동의하고 있다면 위원회가 무슨 필요 있겠는가?
No. 2: 멀티태스킹
멀티태스킹에 대한 룰은 매우 단순하고 분명하다. ‘하지 말아야 된다.’
이는 특히 소프트웨어 개발 프로젝트에 있어 적용되는 말이다. 심지어 멀티태스킹으로 인해 집중력이 흐트러질 때마다 개발자의 생산성이 15분씩 저해된다는 연구 결과도 있다. 그러나 이는 비단 소프트웨어 개발뿐 아니라 IT 부서의 모든 상황에 적용되는 말이다.
멀티태스킹을 하면 안 된다는 사실을 아는 것만으론 충분하지 않다. 어떻게 멀티태스킹을 피할 것인가가 관건이다.
기업 프로그램 매니지먼트가 이에 대한 한 답이 될 수 있다. 그리고 이를 통해 한 가지 규칙만 잘 지키면 된다. 모든 프로젝트는 인원수에 딱 맞게 구성해야 하며 그렇지 않을 경우 시작하지 않는다는 규칙이 그것이다.
인원수에 딱 맞게 구성한다는 게 무슨 뜻이냐고? 놀거나 모자라는 인력 없이, 모든 팀원이 한 번에 하나의 프로젝트에 참여한다는 뜻이다. 이렇게 하면 누구도 멀티태스킹을 할 필요가 없어진다.
이렇게 하면 각각의 프로젝트를 더 빨리 끝낼 수 있을 뿐 아니라 프로젝트 포트폴리오 자체도 훨씬 빨리 완성된다.
No. 3: 프로젝트
프로젝트는 전통적으로 기업들이 새로운 테크놀로지를 도입하는 방식이었다. 프로젝트가 클수록 설계도 복잡했다. 그러나 프로젝트 규모가 커짐에 따라 실패의 확률도 기하급수적으로 늘어나며 일이 지체될 확률도 높아진다.
이제 프로젝트 대신 릴리즈(release)로 대체해보는 건 어떨까? 스트레스 테스팅, 디프로이먼트 등 각각의 과정을 릴리즈 단위로 한 묶음씩 나누는 것이다. 이러한 방식을 채택할 경우 장점이 있다. 바로 IT 관리에서 흔한 현상 중 하나인 ‘과정은 성공하고 프로젝트는 실패하는’ 일을 피할 수 있다는 것이다.
그런데, 이 접근법을 선택한다 해서 이를 극단적인 것이라 여길 필요는 없다. ‘스크럼(scrum)’이라 생각하고 함께하는 사람들과 즐겁게 일하면 된다.
거기서 끝이 아니다. 일을 릴리즈 단위로 쪼개 조직해도 여전히 지연이 발생할 수 있다. 일반적인 스크럼 스프린트는 약 한달 정도 지속되며 이것이 결국 한 달 단위의 비즈니스 사이클을 형성하게 되는데 여기에는 CAB(Change Advisory Board) 미팅(역시 위원회의 미팅 중 하나)은 포함되지 않기 때문이다.
즉 지속적 통합과 디플로이먼트, 다시 말해 데브옵스(devops) 방식을 채택해야 한다. 테스팅을 자동화 하고, 소프트웨어의 변화를 지속적으로 통합하고, 작은 변화라도 바로 생산에 반영한다. 이런 작은 변화들 만으로도 CAB는 필요 없어진다. 작은 실수 하나로 모든 것이 실패로 돌아가는 그런 경우는 이제 없으니 말이다.
No. 4: 매뉴얼 프로비저닝
개발 팀에서 클라우드를 이용해 몇 분 만에 프로비저닝 할 수 있는 것도 IT에 부탁하면 수 개월이 걸릴 수 있다. 당연히 수 개월 걸리는 것보단 몇 분 만에 뚝딱 해내는 게 더 낫고, 퍼블릭 클라우드는 이미 완성된 기술임을 생각해 볼 때 무엇이 더 현명한 선택인지는 자명하다. 자동화를 시작하고, 개발자들이 스스로 프로비저닝 하도록 하라.
No. 5: 통합(integration)보다 인터페이스 중시
새로운 기능은 새로운 가치를 창출해야 한다. 그렇지만 현실은 그렇지 못하다. 대부분 IT 부서는 새로운 기능과 관련해 가만히 뒷짐지고 서서 소프트웨어 변화가 촘촘히 형성되어 있는 커스텀 프로그램 된 포인트 투 포인트 배치 인터페이스를 망치지는 않는지 살펴보는 것이 전부다.
통합 시스템을 통해 얽히고 설킨 인터페이스를 정리하면 프로젝트 팀의 속도도 빨라지고, 테스팅 시간도 더 적게 걸리며, 배치도 더욱 매끄럽게 이뤄진다.
그리고 거기서 한발 더 나아가, ‘정보기술(IT)’을 ‘통합 시스템(Integration Systems)’으로 전환하는 건 어떨까? 데이터와 기능을 안전하고 명확한 서비스로 드러내주는 표준 API로 기업의 핵심 애플리케이션 포트폴리오에 더욱 안정적인 액세스를 가능케 해 줄 것이다.
No. 6: 셰도우 IT의 지나친 통제
셰도우 IT는 문제를 일으킨다. 특히 셰도우 IT의 경우 예외 없이 허술한 기반을 가진 ‘자동화 섬(islands of automation)’ 문제가 발생하곤 한다.
그렇지만 셰도우 IT의 가치도 분명 있다. 현업 부문이 필요로 하는 것을 실패 없이 해낼 수 있다. IT 운영 프로세스의 OK 사인을 기다릴 필요도 없으며, 이에 따라 필요로 하는 것을 지금 당장 충족시켜 줄 수 있는 것이다.
비유를 들자면, 훌륭한 비즈니스 애널리스트와 최악의 아키텍처로 구성된 아웃소싱 애플리케이션 팀이라고 할 수 있다.
셰도우 IT를 양지로 끌어내자. 무조건 안 된다고만 하기 보다 약간의 여지를 두는 것이다. 그렇게 함으로써 IT의 ‘빌딩 코드’를 만족시키는 디자인을 리팩터하는데 들어가는 노력을 고려하더라도 서비스 폭을 넓힐 수 있다.
참고로 IT를 하나의 통합 시스템으로 전환하는데 성공했다면 셰도우 IT 팀도 API를 이용할 수 있으며, 이에 따라 ‘자동화 섬(islands of automation)’문제를 해결하는 데 도움이 된다.
No. 7: 100점짜리 솔루션을 고집
IT는 본능적으로 모든 것을 안전하게 하려 한다. 그러나 수천 번의 트랜잭션 중 한 번 문제를 일으킬까 말까 한 케이스보다는 하루에도 수백 번씩 문제를 일으키는 케이스를 코딩 하는 것이 더 효율적이지 않을까?
옛 IT로부터 교훈을 얻어야 한다. 메인이 되는 케이스들만을 프로그램 하고 나머지는 예외적인 경우로써 매뉴얼 프로세싱으로 처리한다는 그 지혜 말이다. 메인 케이스는 컴퓨터에게, 예외적인 경우는 사람이 직접 하는 것이다.
No. 8: 데이터 웨어하우스
데이터 웨어하우스 프로젝트를 가장 잘 묘사하는 문장이 있다면 그건 바로 ‘일정에 쫓기는 프로젝트’가 될 것이다.
엄밀히 말해 문장은 아니지만, 그게 뭐 대수인가. 진짜 문제는 데이터 웨어하우스들이 그 누구도 물어볼지, 물어보지 않을지 알 수 없는 문제들에 답하도록 최적화 된 OLAP 데이터 스트럭처를 디자인하느라 만성적인 스케줄 지연에 시달리고 있다는 것이다.
이 경우 NoSQL이 도움이 될 수 있다. NoSQL은 단순히 대량의 데이터 볼륨을 처리할 수 있을 뿐 아니라 데이터를 받아들였다가 나중에 애널리스트들이 쿼리(query)를 해야 할 때 그 구성을 분석할 수 있도록 해준다는 데 그 장점이 있다.
이러한 ‘스키마 온 디맨드(schema on demand)’ 성격 덕분에 하둡(Hadoop)이 비교적 빠른 속도로 실행할 수 있다.
No. 9: TCO만 강조하기
여러분 기업의 최고 임원들도 투자한 만큼 수익이 나온다는 단순한 사실을 간과하고 있는가?
비용 절감은 아무리 멍청한 이라도 할 수 있다. 중요한 건 결과물의 퀄리티를 낮추지 않고 비용만 낮추는 것이다. 바로 이 부분에서 TCO라는 개념이 등장한다. 물론 좋지 않을 쪽으로 말이다.
TCO에 치중하다 보면 기능에는 소홀해지게 된다. 비용을 절감하는 가장 쉬운 방법이 기능과 유용성을 포기하는 것이니, 어쩌면 당연한 일인지도 모른다. 더 적은 비용을 투자하면 그만큼의 결과물이 나오는 것이 당연하다.
TCO만을 강조하다 보면 이런 결과가 나타날 수 밖에 없다. 비용을 투자하지 않는 것은 온전히 내 것이 될 수 없다는 자명한 규칙이 있는 한 말이다. IT도 마찬가지다.
게다가 모든 사람이 비용 절감에만 신경을 쓴다면 일 처리 속도에 신경 쓰는 사람은 없게 된다. 그 누구도 일 처리 속도를 우선순위로 두지 않는데 빠르게 일이 진행될 리가 없다.
No.10: ‘고 충실도’ IT 아키텍처에 대한 강요
기업은, 최소한 경영진들은 안정적인 미래를 갈구한다. 그런 그들이 내세우는 일종의 보험이 바로 ‘고 충실도(high fidelity)’다. 고 충실도 시스템이란 데이터 손실이 없고 언제나 올바른 답을 전달하는 시스템을 의미한다.
그러나 이제 이제는 많은 이들이 혁신이라는 이슈에 눈을 뜨게 됐다. 혁신은 미래며, 경쟁사들과 자신을 차별화 해줄 지점이다.
이제 구별이 필요한 시점이다. ‘고 충실도’ IT 아키텍처가 중요한(예를 들자면 셰도우 IT) 영역들에 혁신까지 강조하는 것은 옳지 못한 일이다. 혁신을 장려하고 싶다면, 혁신가들에게 그들만의 공간을 마련해주고 그 안에서 미래를 그려나가는데 집중할 수 있도록 하는 것이 필요하다. 이 구조가 마련된 후라면 고 충실도와 혁신 두 이슈는 자연스레 융합이 가능해질 것이다.
No. 11: 현 상태에 안주하는 기업 문화
뭔가 새롭고 혁신적인 것을 시도했다가 성공하지 못할 수 있다. 이 때 그 시도를 칭찬하지는 못할 망정 그 책임을 개인에게 뒤집어 씌우는 기업은 이내 한계에 도달하게 된다.
현재 상태에 만족하는 기업 문화는 결국 직원들의 태도까지 나태해지게 만들어 느려질 수 밖에 없다. ‘이제까지도 쭉 그래왔는데 뭘’ 하는 마인드 말이다.
만일 당신이 일하는 기업의 문화가 이렇다면, 진지하게 고민해보기 바란다. 도태되는 기업을 기다리는 건 죽음뿐이다.
No.12: 비즈니스/IT 관계 구축 실패
여기 두 기업이 있다. 한 곳에서는 IT가 비즈니스 ‘고객’들과 SLA를 ‘협상’하며 항목들에 관한 ‘서명’을 받는다. 그리고 다른 기업에서는 “이번에 하는 프로젝트는 뭐고 어떤 기술이 필요해?”라는 동료들 간의 대화로 이 과정이 시작된다. 과연 어느 기업에서 더 나은 결과물이 더 빠르게 창출될 수 있을까?
소위 전문가라며 점잔 빼는 사람들은 하나같이 전자와 같은 방식을 최고라고 꼽는다. 이들의 말은 무시해도 된다. 후자의 방식이 전자보다 훨씬 더 낫다. 상대방과 격식 없는 관계를 맺고, 절대 ‘협상’하려 하지 마라.
왜냐고? 협상이란 서로 테이블의 ‘반대편’에 앉는 행동이기 때문이다. 따지고 보면, IT와 여타 비즈니스 영역은 결국 한 기업을 위해 활동하는, ‘같은 편’ 아닌가?
* Bob Lewis는 델 디지털 비즈니스 컨설팅의 선임 대표 컨설턴트다. 그는 차세대IT 커뮤니티 실행 부문을 담당한다. 그러나 본 기고문의 모든 아이디어는 온전히 그의 것들이다. dl-ciokorea@foundryco.com
