2017.08.30

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

Bob Lewis | 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 팀도 사용하게 만들 수 있다. 그러면 자동화의 섬 문제도 동시에 해결된다.

2017.08.30

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

Bob Lewis | 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 팀도 사용하게 만들 수 있다. 그러면 자동화의 섬 문제도 동시에 해결된다.

X