2015.09.24

당신의 IT 부서가 '속 터지게' 느린 12가지 이유

Bob Lewis | CIO

쓰라린 진실을 직면할 시간이다. 솔직히 말해 당신의 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는 필요 없어진다. 작은 실수 하나로 모든 것이 실패로 돌아가는 그런 경우는 이제 없으니 말이다.
 

CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.



2015.09.24

당신의 IT 부서가 '속 터지게' 느린 12가지 이유

Bob Lewis | CIO

쓰라린 진실을 직면할 시간이다. 솔직히 말해 당신의 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는 필요 없어진다. 작은 실수 하나로 모든 것이 실패로 돌아가는 그런 경우는 이제 없으니 말이다.
 

CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.

X