IT부서를 느리게 하는 악성 관행 12가지

InfoWorld

IT부서는 너무 느리다. 솔직히 부정할 수 없는 현실이다. 선의가 변질돼 나타난 결과가 대부분이지만 비즈니스에서 의도는 중요하지 않다. 특히 IT부서가 너무 느릴 때가 언제인가 하면 다른 부서가 IT부서의 결과물을 기다려야 할 때다. ‘가치 창출 시간’(time to value)라는 용어가 유행하지만 실제 업무를 지배하는 용어은 ‘경쟁사보다 먼저’다. IT부서 때문에 차질이 생긴다면 회사 간부는 이를 참지 못할 것이다.

IT부서의 속도를 올리려면 속도 저하의 원인, 즉 병목부터 제거해야 한다. 제일 먼저 살펴보아야 할 12가지 사례를 소개한다. 이를 무시한다면 심각한 위험을 자초하게 된다.



IT병목 1번: 관리 통제

오랫동안 관리 통제 역할을 한 주체로는 각종 위원회가 있다. 위원회의 관리 통제에 따라 IT 부서에서 하는 모든 일의 속도가 정해진다. 위원회가 건드리면 무엇이든 발목이 잡힌다. 관리 통제의 중심에 위원회가 있으면 아무리 다른 부분에서 노력을 하더라도 IT부서는 굼벵이처럼 느려질 수밖에 없다.

규모부터 줄여야 한다. 위원 수가 늘어나면 늘어날수록 의사결정은 더 느려진다. 다섯 명이 넘어가면 진척 속도는 굼벵이 수준으로 떨어진다. 합의에 이를 가능성이 완전히 사라지기 때문이다.

위원들이 자신을 IT리더가 아닌 어떻게든 한 몫을 챙기려는 지역구 대표쯤으로 여긴다면 사태는 더 심각하다. 이런 종류의 위원회는 공동의 문제를 해결하는 게 아니라 끝없이 논쟁만 벌인다.

회의 일정도 문제다. 위원회가 관장하는 모든 프로젝트의 속도가 회의 일정에 따라 결정되기 때문이다. 예를 들어 회의가 매달 열린다면 모든 사안에 대한 의사 결정도 한 달이 걸린다. 이러한 병목이 있는 한 제대로 굴러갈 프로젝트는 많지 않다.

이 문제를 어떻게 해결할까? 문화를 정착시켜 새로운 관리 통제 역할을 하게 만드는 것이다. 차선 도색 작업자라고 생각하고 운영 위원회에는 가드레일 역할을 맡기는 것이다. 그러면 다른 모든 것이 실패하더라도 IT 부서가 낭떠러지에서 떨어지는 일은 없다.

문화를 정착시켜 이 난제를 해결하게 하라. 모든 사람이 무엇이 가장 중요한지 이해하고 여기에 집중한다면 대부분의 관리 통제는 불필요해진다.

IT병목 2번: 멀티태스킹을 당연시
직원의 멀티태스킹(multitasking)은 금지하는 것이 원칙이다. 소프트웨어 개발 프로젝트에서는 특히 그렇다. 연구 결과에 따르면 개발자 업무가 방해를 받을 때마다 생산성에 15분 손해를 본다고 한다. 비단 앱 개발뿐 아니라 IT직원이 집중해야 하는 다른 모든 상황에도 마찬가지이다.

멀티태스킹을 막는 해결책은 기업 프로그램 관리실 손에 달려 있다. 모든 프로젝트에는 직원이 충분히 배치되어야 하며 그렇지 않으면 시작할 수 없다는 것을 철칙으로 삼아야 한다.

직원이 충분히 배치된 프로젝트란 어떤 한 팀원이 시간이 날 때까지 기다릴 필요가 전혀 없는 프로젝트를 말한다. 모든 프로젝트에 직원이 충분히 배치될 수 있는 수준으로 동시 진행 프로젝트 수를 제한한다면 팀원들은 멀티태스킹을 할 필요가 없어진다.

그 결과 각 프로젝트의 완료 속도뿐만 아니라 전체 프로젝트 포트폴리오의 완료 속도가 빨라진다.

-> 기고 | 멀티태스킹 중독··· 대가는 '집중력 분산'

IT병목 3번: 프로젝트
프로젝트는 기업이 신기술을 실현하는 전통적인 방식이다. 설계가 복잡할수록 프로젝트 규모가 커지기 마련이다. 프로젝트 규모가 커지면 실패의 위험이 기하급수적으로 늘어나고 상당한 지연이 발생할 수밖에 없다.

모든 노력을 릴리즈(release)에 집중해야 한다. 릴리즈란 회귀, 부하 검사, 배치를 위한 개별 향상 기능을 하나로 묶은 것을 말한다. IT 관리 경험상 프로젝트는 실패하더라도 향상 기능은 성공한다는 말은 신빙성이 가장 높기 때문에 프로젝트 대신 릴리즈에 집중하는 것이 도움이 된다.

그건 그렇고, 이 노선을 택한다면 굳이 급진적인 단어로 설명할 필요는 없다. 스크럼이라고 부르고 얼마든지 즐겨도 된다.

단, 거기서 멈춰서는 안 된다. 릴리즈에 개발 업무를 집중한다고 해도 여전히 지연은 발생한다. 일반적인 스크럼 전력 질주의 지속 시간은 한 달이다. 따라서 업무 변화의 속도도 한 달 단위로 설정된다. 게다가 또 다른 관리 통제 위원회의 일종인 변화자문위원회(CAB) 회의도 기다려야 한다.

따라서 지속적인 통합과 개발, 즉 데브옵스(devops)를 추진해야 한다. 테스트를 자동화하고 소프트웨어 변경 사항은 계속해서 통합하고 소규모 변경 사항은 즉시 적용하라. 변경 사항이 이렇게 작으면 CAB는 불필요하다. 쉼표를 잘못 찍는 바람에 뭔가가 폭발해 버리던 시대는 이제 지난 지 오래지 않은가.

IT병목 4번: 수동 프로비저닝
개발 팀은 몇 분 안에 클라우드에 완전한 환경을 프로비저닝(provisioning)할 수 있다. 반면 IT운영 팀에게 똑같은 환경을 요청한다면 몇 달이 족히 걸리게 된다.

이는 태생적인 한계가 아니라 선택의 문제이다. 몇 달에 비하면 몇 분이 더 짧은 시간이라는 점, 퍼블릭 클라우드 제공업체들이 이미 완벽한 기술을 보유하고 있다는 점을 감안하면 어느 쪽이 나은 선택인지는 명백하다. 자동화를 시작하라. 그리고 개발자들에게 프로비저닝을 직접 처리할 권한을 주어라.

IT병목 5번: 통합 대신 인터페이스 선호
새로운 기능은 새로운 가치를 창출한다. 그러나 대부분의 IT 부서에서 새로운 기능은 뒤로 밀린다. 거미줄처럼 얽힌 포인트 투 포인트 배치 인터페이스(point-to-point batch interface)가 소프트웨어의 변화로 인해 깨지지 않게 하는 데 급급하기 때문이다.

제대로 설계한 통합 시스템으로 복잡한 인터페이스를 정리해야 한다. 그래야 프로젝트 팀의 속도는 높아지고 테스트 시간은 단축되며 배치가 보다 원활하게 진행된다.

여기에서 한 걸음 더 나아가 ‘정보기술’(IT)을 ‘통합시스템’(IS)으로 바꿔라. 통합 시스템의 임무는 데이터와 기능을 안전하고 잘 정의된 서비스로 나타내는 표준 API를 통해 회사의 핵심 응용프로그램 포트폴리오에 대한 안정적인 접근을 제공하는 것이다.

IT병목 6번: 섀도우IT 금지
현업 부서에서 직접 배치한 시스템을 가리키는 섀도우IT(Shadow IT)는 문제를 일으킨다. 특히 섀도우IT에서는 허술한 기초 위에 구축된 자동화는 대개 동떨어진 섬과 같은 존재이기 마련이다.

그런데 섀도우IT는 회사에 필요한 것을 어김없이 해 낸다. IT관리 통제 절차를 통한 승인을 기다릴 필요가 없기 때문에 회사가 당장 필요로 하는 것을 제공한다. 말하자면 똑똑한 업무 분석가와 형편없는 설계자를 보유한 외주 응용프로그램 팀을 공짜로 쓰고 있다고 보면 된다.

섀도우IT를 양지로 이끌어야 한다. 근절하려고 하기보다는 지원을 좀 해 주는 것이 좋다. 배관 작업과 IT의 구축 코드에 맞는 코드 재작성을 통한 재설계 노력을 감안하더라도 대역폭이 크게 늘어나는 결과를 얻을 수 있기 때문이다.

IT를 통합시스템으로 바꿨다면 API를 회사의 섀도우IT 팀도 사용하게 만들 수 있다. 그러면 자동화의 섬 문제도 동시에 해결된다.


IT병목 7번: 100% 솔루션 고집
IT는 완벽주의 본능이 있다. 그러나 트랜잭션 1,000 건 마다 한 번씩 시스템에 발생하는 사례나 하루에 몇 백 번씩 발생하는 사례나 코딩에 걸리는 시간은 별 차이가 없다.

기본 사례만 프로그래밍하고 나머지는 예외 사항으로 빼 놓고 수동으로 처리하던 옛날 IT방식을 교훈으로 삼아야 한다. 컴퓨터는 기본 사례에 능하고 인간은 예외 사항에 능하다.

IT병목 8번: 데이터 웨어하우스 만들기
전형적인 데이터 웨어하우스 프로젝트를 한 마디로 하면 “예정보다 늦다”일 것이다. 뭐 한 마디는 아니고 두 마디이긴 하다. 죄송하게 됐다. 어쨌든 데이터 웨어하우스가 늦어지는 것은 여전히 고질적인 문제이다. 그 원인은 아무도 지금 당장은 알 수 없는 질문에 답할 수 있도록 최적화된 OLAP 데이터 구조를 설계하는 것이 어렵기 때문이다.

여기서 NoSQL이 등장한다. NoSQL이 흥미로운 것은 대량 데이터 처리 능력 때문만은 아니다. 더욱 소중한 능력은 지금 데이터를 접수한 다음 나중에 질의할 때가 오면 분석가가 데이터 구성을 분석할 수 있게 해 주는 것이다.

이러한 ‘스키마 온 디맨드’(schema on demand) 특성 덕분에 하둡(Hadoop) 실행 속도가 상대적으로 엄청나게 빠르다.

IT병목 9번: TCO 강조
비용이 이득을 만들어 낸다는 사실을 의사결정자들이 망각하고 있지는 않은가? 비용을 줄이는 것은 바보라도 할 수 있다. 문제는 비용은 줄이되 산출 결과에는 지장을 주지 말아야 한다는 점이다. 여기에 총 소유 비용(TCO)이 등장하는데 이 접근법은 별로 바람직하지 않다.

TCO 중심적 접근은 기능성을 중시하지 않으며 오히려 이를 막는다. 실제로 기능성이 떨어지는 물건을 제공하고 지원하면 가장 손쉽게 비용을 줄일 수 있다. 쓸모 없는 물건일수록 비용이 덜 드는 법이다.

TCO를 강조하다 보면 이런 일이 필연적으로 발생한다. 측정하지 않는 것은 얻을 수 없다는 불변의 지표 법칙 때문이다. 이 법칙은 IT업무의 가치에도 적용된다. 게다가, 모두가 비용 절감에 집중하고 있으면 아무도 속도 증가에 신경 쓰지 않는다. 속도 증가가 최고 우선순위는 고사하고 일반적인 우선순위도 아니라면 속도가 빨라질 일은 없다.

IT병목 10번: 혁신가들에게 ‘고충실’ IT 아키텍처 강요
과거에 기업들은 어제와 다름 없는 내일을 고집하곤 했다. 데이터가 손실되는 법이 절대 없고 언제나 정답을 제공하는 완벽한 ‘고충실’(high fidelity) 시스템을 요구했다. 그러나 이제는 완벽함 못지 않게 혁신이 중요하다. 그것이 미래다. 그래야 경쟁적 우위를 점할 수 있다.

혁신가들(예: 섀도우IT)에게 ‘고충실’ IT 아키텍처를 강요하면 안 된다. 혁신가들이 문제를 해결하고 미래를 실현시킬 수 있도록 자신만의 독립된 공간을 제공해야 한다. 혁신을 ‘고충실’로 만드는 것은 혁신이 성공한 후에 얼마든지 해도 된다.

IT병목 11번: 현 상태에 안주하는 문화 허용
잘 돌아가는 IT부서라도 맥이 빠질 때가 있다. 누군가가 혁신적인 것을 시도했다가 실패로 돌아가면 위험을 무릅쓴 용기를 칭찬하는 것이 아니라 ‘책임을 묻는’ 회사에서는 특히 그렇다. 현 상태에 안주하는 문화는 기업 활동의 속도를 저하시킨다. 늘 해 온 방식에 젖어 있어서 아무도 속도를 올릴 필요성을 느끼지 못하기 때문이다. 그런 문화는 나서서 바꿔야 한다. 그렇지 않으면 죽을 정도의 지루함을 견디는 수밖에 없다.

IT병목 12번: 형식적인 현업-IT 관계 설정
IT부서는 서비스 수준 계약을 ‘협상’하면서 업무 ‘고객’에게 요건과 사양에 대한 승인을 요청하는 식의 형식적인 절차와 “어떤 일이 필요한가요? 어떻게 도와드릴까요?”라고 시작하는 편안한 대화를 떠올려보자. 어느 쪽의 성과가 더 빠를 것 같은가?

많은 전문가들은 형식적인 방식을 ‘베스트 프랙티스’라고 부른다. 이들이 하는 말은 무시하고 더 나은 방식을 선택해야 한다. 편안하면서도 밀접한 관계를 발전시키되 협상은 금물이다. 왜냐하면 협상은 반대편 사람과 하는 것이기 때문이다. 따지고 보면 IT와 현업 부서는 같은 편이지 않는가?

-> 선무당이 IT 조직을 망친다··· 조심해야 할 베스트 프랙티스 12가지

* Bob Lewis는 관리 및 IT 컨설턴트다. ciokr@idg.co.kr