2021.08.27

운영보다 헬프데스크 챙겨라?!··· CIO가 집중해야 할 IT프로세스 3가지

Bob Lewis | CIO
계속 움직여라(Keep the Joint Running Manifesto)’에서는 전략을 세우기에 앞서 숙달돼 있어야 한다고 주장(일곱 번째 원칙)한다. CIO와 IT에도 해당되는 이야기다. IT의 업무는 IT 프로세스와 활동(practices)을 통해 이뤄지지만 ‘능숙성’에 따라 결과가 크게 달라질 수 있다. 이 뚱딴지 같은 이야기를 좀더 자세히 설명하면 다음과 같다. 

본 시리즈의 이전 글(기고 | 효과적인 IT프로세스 구축하기 ‘4가지 전제 조건’)에서 IT의 프로세스와 활동을 개선하는 것’에 관한 냉엄한 진실을 이야기했다. 이제 CIO가 그 중 무엇에 집중해야 하는지 살펴볼 차례다. 

이에 대한 해답은 기본적인 원칙에서 시작된다. 관리자는 절대로 3개 이상의 변화 이니셔티브를 직접 후원해서는 안 된다. 이 수치를 넘어서면 집중하여 주도하는 능력을 잃어버리게 된다. 그렇다면 CIO가 선택해야 하는 3가지는 무엇일까?

집중하지 말아야 할 것 : IT운영
프로세스 개선 프로그램을 구체화하는데 있어 있어서 확실한 후보 도구 중 하나는 잘 알려진 ‘ITIL 프레임워크’이다. 하지만 이것은 실수라 할 수 있다.

ITIL 프레임워크를 도입하는 것이 실수가 아니다. 수십년 동안 성숙한 완벽한 프레임워크이다. ITIL이 IT운영에 초점을 맞추고 있는 것이 문제이다. 그리고 IT 운영은 무엇인가 잘못되었을 때만 관심을 받는다. CIO는 무엇인가 잘 되었을 때 관심을 받아야 한다.
 
따라서 IT조직이 가용성 관리, 역량 관리, 성과 관리, 인프라 라이프사이클 관리, 시스템 관리, 변화 관리 등을 잘 하려면 적절한 사람이 IT운영을 담당하도록 하고 그들의 성과를 중요한 IT운영 지표로만 평가해야 한다.

CIO로써 IT 운영이 매우 중요하기는 하지만 전혀 전략적이지 않다는 사실을 인지해야 한다. 이것이 제대로 되지 않으면 전략적일 수 없다. 이를 위임하고 위임한 관리자가 필요한 모든 도구와 지원을 받도록 해야 한다.

프로세스 우선 순위 1 : 업무지원센터(The help desk)
IT전체의 평판이 높지 않은 경우 업무지원센터 개선이 주요 우선순위가 되어야 한다. 

업무지원센터는 IT의 양아들과 비슷하다. 그 이유는 IT와 나머지 비즈니스 부문의 성공적인 통합의 중요한 요소가 ‘비즈니스/IT 관계의 질’이기 때문이다. IT와 나머지 비즈니스 부문의 관계는 업무지원센터에 따라 좌우된다. 

‘도움이 되지 않는 업무지원센터’라는 말을 듣는가? 비즈니스 부문에서 전화해 업무지원센터에 알려줄 때까지 IT가 시스템이 다운된 이유를 모르는 상황이 발생하는가? 업무지원센터 직원들이 공유하고 있는 멍청한 사용자에 관한 이야기가 회자되고 있는가? 누군가 업무지원센터에 연락하고 쉽고 간단한 것을 요청했을 때 업무지원센터가 지금 당장 필요한 10초짜리 답변을 제공하는 대신에 티켓 번호를 제공하는가?

만약 업무지원센터에서 이런 증상이 나타난다면 위기 신호다. 나머지 IT조직이 빛을 발하게 하기 위해 필요한 비즈니스 지원이 여기에 달려 있다.

프로세스 우선 순위 2 : 애플리케이션 지원
규칙 1 : 애플리케이션 지원팀이 여전히 워터폴(Waterfall) 방법론에 빠져 있는데 무엇을 기다리고 있는가? 지금 당장 그들을 애자일(Agile)로 옮기고 애자일 도입 전략과 실행을 직접 감독한다.

규칙 2 : 애자일은 스크럼(Scrum)보다 중요하다. 스크럼이 아니라 IT가 실제로 수행하는 업무에 적절한 애자일 변종을 선택해야 한다. 왜냐하면 ‘모두가 그것을 사용하고 있기 때문’이다.

규칙 3 : 대부분의 애자일 변종은 애플리케이션 개발을 관리하기 위해 고안되었다. 대부분의 IT 부서는 ‘가능하면 구매하고 반드시 필요한 경우에만 개발한다.’ 자신의 상황이 이런 경우 스크럼은 그냥 무시한다. 대신에 애플리케이션팀이 CRP(Conference Room Pilot)이나 이와 유사한 ATDD(Acceptance Test-Drive Development)를 도입하도록 한다.

규칙 4 : 대부분의 애자일 변종은 소프트웨어를 제품으로써 제공하는 데 초점을 둔다. 이것만으로는 부족하다. 대부분의 기업은 IT가 의도적인 비즈니스 변화를 달성하는 데 협업해야 한다. 그렇게 되도록 애자일 기법을 변경한다.
 
프로세스 우선 순위 3 : IT 아키텍처 관리
IT 아키텍처의 질과 우수성이 부실한 경우, 잘못된 IT 아키텍처 관리 활동의 증상이라 할 수 있다. IT 아키텍처 관리 활동에 도움이 필요하다는 조짐은 또 무엇이 있을까?

“우리의 아키텍처가 얼마나 좋은지 설명할 수 없다”는 것은 놀라우면서도 우울한 공통적인 증상이다. “우리에게 무엇이 있는지 모른다”도 그리 드물지 않다.

또 무엇이 있을까? 다음과 같은 것들이 있다 :

• 나머지 모든 것을 안내하는 아키텍처 원칙에 관한 짧은(12개 이하) 목록을 공개하지 않았다. 그리고 원칙은 짧은 것 외에도 단순하면서 전문 용어를 사용하지 않는 언어로 작성해야 한다.

• 원칙에 기초하며 잘 문서화된 활동에 기초하여 최신 상태로 유지되고 정기적(분기별이면 적당함)으로 갱신되는 표준 목록을 공개하지 않았다.

• 라이프사이클 관리를 표준 활동으로 수립하고 IT 계획 및 예산 책정에 포함시키지 않았다.

• 아키텍처 원칙과 표준 그리고 클라우드는 스토리지 또는 처리 장소가 아니라 아키텍처라는 이해를 중심으로 구축된 클라우드 전략을 개발하지 않았다.

IT 아키텍처에 이런 결함이 없다고 해서 안전하다는 뜻은 아니다. IT 아키텍처 관료제적 수렁이 되는 경향성을 가지기 십상이다. 우수한 아키텍처는 반 관료제적 사고방식이 필요하다. 또한 만족스러운 기능을 갖춘 애플리케이션을 개발하는 프로젝트는 아키텍처 표준을 준수하는 만족스러운 기능을 갖춘 애플리케이션보다 비용이 적게 들기 때문에 재정지원이 필요하다.

그리고 일반적인 임원들이 그 차액을 지불할 의향이 있을 가능성이 낮기 때문에 애플리케이션 기능을 제공하거나 변경하는 프로젝트는 아키텍처 보조금이 필요하다.

건전한 아키텍처를 달성하는 방법을 찾아야 한다. 또한 임원진들에게 좋은 아키텍처를 현명한 비즈니스 투자라는 것을 납득시켜야 한다. 이런 2가지 중요한 우려사항 때문에 CIO는 IT 아키텍처팀과 업무를 직접 감독해야 할 필요성이 높다. 

그렇다면 정보 보안은?
비즈니스에 대한 IT 관련 위협이 확대되고 있다. 범죄 조직과 국가 차원의 범죄가 증가하고 있으며, 피해 규모 또한 기업을 멸망시킬 수준으로 커지고 있다. 요즈음의 시대에 정보 보안은 IT의 주요 우선순위가 되어야 하는 것은 분명하다.

하지만 IT 운영과 마찬가지로 정보 보안 효과는 비가시성 인덱스다. 아무도 관심을 갖지 않은 상황에서도 CIO는 챙겨야 하지만, 이를 전면에 내세우는 것은 비즈니스 혁신을 능숙하게 이끌어가는 측면에서 바람직하지 않다.

한 가지 더 중요한 사실이 있다. 고품질의 IT 아키텍처와 긴밀히 연계되지 않은 정보 보안은 부실한 정보 보안이다. 정보 보안을 IT 아키텍처 활동에 통합하면 CIO로써 관심을 추가적으로 분산시키지 않고 이를 주시할 수 있다.

디지털 혁신 해결하기
혁신을 위한 비즈니스 기회가 어디 있는지 살펴보면 정보 기술이 최우선은 아니더라도 상위 3위 안에 든다는 것을 알게 될 것이다. CIO로써 IT 혁신을 담당하거나 CDO(Chief Digital Officer)를 임원 리더십 팀에 추가하는 아이디어를 도입해야 한다.

하지만 개인적으로 CDO에 대해서는 의구심이 든다. IT리더십이 분열되어 CDO는 해야 할 일을 이야기하고 CIO는 거절만 하는 사람이 될 수 있기 때문이다.  

대신에 IT혁신을 IT아키텍처 활동에도 적용하는 것을 검토해볼 만하다. 그렇게 하면 조직의 혁신을 도모하여 관심이 분산되지 않을 뿐 아니라 IT혁신을 IT아키텍처의 나머지 부분에 통합해야 하는 장기적인 필요로서 혁신을 담당하게 될 것이다. 어쨌든 IT 혁신이 고립된 것이어서는 안 된다.

‘DIY IT’를 처리하는 방법
DIY IT는 ‘셰도우 IT’, ‘악당 IT’(rogue IT), ‘멈춰!!! 편두통이 온다!!!! IT’(STOP IT!!! You’re giving me a migraine!!!! IT)로도 알려져 있다. 이로 인해 너무나 많은 CIO들이 이를 해결하기 위해 노력하고 있다.

그러나 이것은 파도에게 오지 말라고 명령하는 카누트 왕(King Canute)과 같다.

어쨌든, DIY IT는 IT지출 또는 최소한 눈에 보이는 IT지출을 증가시키지 않고 회사의 IT 대역폭을 극적으로 넓혀 주기 때문에 문제라기 보다는 기회이다.

DIY IT의 단점은 대부분 피할 수 있다. 대부분의 경우 IT가 기술 컨설팅 측면에서 약간의 지원을 제공하여 IT아키텍처 표준을 준수하도록 하면 되며, 그 대신에 IT 아키텍처 기능은 DIY IT가 은밀한 IT가 되는 것을 방지하기 위해 필요한 문서를 얻게 된다.

결론
IT가 역량을 확보하려면 잘 고안되고 정의되며 문서화된 프로세스와 활동을 활용하여 성과를 달성해야 한다. CIO는 이 모든 것을 책임지지만 3가지 이상의 전환을 직접 주도하는 데는 무리가 있다.

요약하자면 대부분의 IT 조직에서 CIO의 직접 리더십이 가장 필요한 3가지 프로세스 영역은 업무지원센터, 애플리케이션 지원, IT 아키텍처 관리이다. 이것들을 잘 다듬으면 IT는 눈에 띄게 성공할 것이며, 그 결과는 기업의 비즈니스 성과로 나타날 것이다. 

IT운영은 분명 중요하다. 그러나 CIO는 이 책임을 위임해야 한다. 역설적이지만 그렇다. 이러한 진실을 외면한다면 중요한 3가지를 다듬을 충분한 여유가 없게 될 것이다. 

* Bob Lewis는 IT와 현업 관계, 전략 실행 계획에 중점을 IT 컨설턴트다. ciokr@idg.co.kr



2021.08.27

운영보다 헬프데스크 챙겨라?!··· CIO가 집중해야 할 IT프로세스 3가지

Bob Lewis | CIO
계속 움직여라(Keep the Joint Running Manifesto)’에서는 전략을 세우기에 앞서 숙달돼 있어야 한다고 주장(일곱 번째 원칙)한다. CIO와 IT에도 해당되는 이야기다. IT의 업무는 IT 프로세스와 활동(practices)을 통해 이뤄지지만 ‘능숙성’에 따라 결과가 크게 달라질 수 있다. 이 뚱딴지 같은 이야기를 좀더 자세히 설명하면 다음과 같다. 

본 시리즈의 이전 글(기고 | 효과적인 IT프로세스 구축하기 ‘4가지 전제 조건’)에서 IT의 프로세스와 활동을 개선하는 것’에 관한 냉엄한 진실을 이야기했다. 이제 CIO가 그 중 무엇에 집중해야 하는지 살펴볼 차례다. 

이에 대한 해답은 기본적인 원칙에서 시작된다. 관리자는 절대로 3개 이상의 변화 이니셔티브를 직접 후원해서는 안 된다. 이 수치를 넘어서면 집중하여 주도하는 능력을 잃어버리게 된다. 그렇다면 CIO가 선택해야 하는 3가지는 무엇일까?

집중하지 말아야 할 것 : IT운영
프로세스 개선 프로그램을 구체화하는데 있어 있어서 확실한 후보 도구 중 하나는 잘 알려진 ‘ITIL 프레임워크’이다. 하지만 이것은 실수라 할 수 있다.

ITIL 프레임워크를 도입하는 것이 실수가 아니다. 수십년 동안 성숙한 완벽한 프레임워크이다. ITIL이 IT운영에 초점을 맞추고 있는 것이 문제이다. 그리고 IT 운영은 무엇인가 잘못되었을 때만 관심을 받는다. CIO는 무엇인가 잘 되었을 때 관심을 받아야 한다.
 
따라서 IT조직이 가용성 관리, 역량 관리, 성과 관리, 인프라 라이프사이클 관리, 시스템 관리, 변화 관리 등을 잘 하려면 적절한 사람이 IT운영을 담당하도록 하고 그들의 성과를 중요한 IT운영 지표로만 평가해야 한다.

CIO로써 IT 운영이 매우 중요하기는 하지만 전혀 전략적이지 않다는 사실을 인지해야 한다. 이것이 제대로 되지 않으면 전략적일 수 없다. 이를 위임하고 위임한 관리자가 필요한 모든 도구와 지원을 받도록 해야 한다.

프로세스 우선 순위 1 : 업무지원센터(The help desk)
IT전체의 평판이 높지 않은 경우 업무지원센터 개선이 주요 우선순위가 되어야 한다. 

업무지원센터는 IT의 양아들과 비슷하다. 그 이유는 IT와 나머지 비즈니스 부문의 성공적인 통합의 중요한 요소가 ‘비즈니스/IT 관계의 질’이기 때문이다. IT와 나머지 비즈니스 부문의 관계는 업무지원센터에 따라 좌우된다. 

‘도움이 되지 않는 업무지원센터’라는 말을 듣는가? 비즈니스 부문에서 전화해 업무지원센터에 알려줄 때까지 IT가 시스템이 다운된 이유를 모르는 상황이 발생하는가? 업무지원센터 직원들이 공유하고 있는 멍청한 사용자에 관한 이야기가 회자되고 있는가? 누군가 업무지원센터에 연락하고 쉽고 간단한 것을 요청했을 때 업무지원센터가 지금 당장 필요한 10초짜리 답변을 제공하는 대신에 티켓 번호를 제공하는가?

만약 업무지원센터에서 이런 증상이 나타난다면 위기 신호다. 나머지 IT조직이 빛을 발하게 하기 위해 필요한 비즈니스 지원이 여기에 달려 있다.

프로세스 우선 순위 2 : 애플리케이션 지원
규칙 1 : 애플리케이션 지원팀이 여전히 워터폴(Waterfall) 방법론에 빠져 있는데 무엇을 기다리고 있는가? 지금 당장 그들을 애자일(Agile)로 옮기고 애자일 도입 전략과 실행을 직접 감독한다.

규칙 2 : 애자일은 스크럼(Scrum)보다 중요하다. 스크럼이 아니라 IT가 실제로 수행하는 업무에 적절한 애자일 변종을 선택해야 한다. 왜냐하면 ‘모두가 그것을 사용하고 있기 때문’이다.

규칙 3 : 대부분의 애자일 변종은 애플리케이션 개발을 관리하기 위해 고안되었다. 대부분의 IT 부서는 ‘가능하면 구매하고 반드시 필요한 경우에만 개발한다.’ 자신의 상황이 이런 경우 스크럼은 그냥 무시한다. 대신에 애플리케이션팀이 CRP(Conference Room Pilot)이나 이와 유사한 ATDD(Acceptance Test-Drive Development)를 도입하도록 한다.

규칙 4 : 대부분의 애자일 변종은 소프트웨어를 제품으로써 제공하는 데 초점을 둔다. 이것만으로는 부족하다. 대부분의 기업은 IT가 의도적인 비즈니스 변화를 달성하는 데 협업해야 한다. 그렇게 되도록 애자일 기법을 변경한다.
 
프로세스 우선 순위 3 : IT 아키텍처 관리
IT 아키텍처의 질과 우수성이 부실한 경우, 잘못된 IT 아키텍처 관리 활동의 증상이라 할 수 있다. IT 아키텍처 관리 활동에 도움이 필요하다는 조짐은 또 무엇이 있을까?

“우리의 아키텍처가 얼마나 좋은지 설명할 수 없다”는 것은 놀라우면서도 우울한 공통적인 증상이다. “우리에게 무엇이 있는지 모른다”도 그리 드물지 않다.

또 무엇이 있을까? 다음과 같은 것들이 있다 :

• 나머지 모든 것을 안내하는 아키텍처 원칙에 관한 짧은(12개 이하) 목록을 공개하지 않았다. 그리고 원칙은 짧은 것 외에도 단순하면서 전문 용어를 사용하지 않는 언어로 작성해야 한다.

• 원칙에 기초하며 잘 문서화된 활동에 기초하여 최신 상태로 유지되고 정기적(분기별이면 적당함)으로 갱신되는 표준 목록을 공개하지 않았다.

• 라이프사이클 관리를 표준 활동으로 수립하고 IT 계획 및 예산 책정에 포함시키지 않았다.

• 아키텍처 원칙과 표준 그리고 클라우드는 스토리지 또는 처리 장소가 아니라 아키텍처라는 이해를 중심으로 구축된 클라우드 전략을 개발하지 않았다.

IT 아키텍처에 이런 결함이 없다고 해서 안전하다는 뜻은 아니다. IT 아키텍처 관료제적 수렁이 되는 경향성을 가지기 십상이다. 우수한 아키텍처는 반 관료제적 사고방식이 필요하다. 또한 만족스러운 기능을 갖춘 애플리케이션을 개발하는 프로젝트는 아키텍처 표준을 준수하는 만족스러운 기능을 갖춘 애플리케이션보다 비용이 적게 들기 때문에 재정지원이 필요하다.

그리고 일반적인 임원들이 그 차액을 지불할 의향이 있을 가능성이 낮기 때문에 애플리케이션 기능을 제공하거나 변경하는 프로젝트는 아키텍처 보조금이 필요하다.

건전한 아키텍처를 달성하는 방법을 찾아야 한다. 또한 임원진들에게 좋은 아키텍처를 현명한 비즈니스 투자라는 것을 납득시켜야 한다. 이런 2가지 중요한 우려사항 때문에 CIO는 IT 아키텍처팀과 업무를 직접 감독해야 할 필요성이 높다. 

그렇다면 정보 보안은?
비즈니스에 대한 IT 관련 위협이 확대되고 있다. 범죄 조직과 국가 차원의 범죄가 증가하고 있으며, 피해 규모 또한 기업을 멸망시킬 수준으로 커지고 있다. 요즈음의 시대에 정보 보안은 IT의 주요 우선순위가 되어야 하는 것은 분명하다.

하지만 IT 운영과 마찬가지로 정보 보안 효과는 비가시성 인덱스다. 아무도 관심을 갖지 않은 상황에서도 CIO는 챙겨야 하지만, 이를 전면에 내세우는 것은 비즈니스 혁신을 능숙하게 이끌어가는 측면에서 바람직하지 않다.

한 가지 더 중요한 사실이 있다. 고품질의 IT 아키텍처와 긴밀히 연계되지 않은 정보 보안은 부실한 정보 보안이다. 정보 보안을 IT 아키텍처 활동에 통합하면 CIO로써 관심을 추가적으로 분산시키지 않고 이를 주시할 수 있다.

디지털 혁신 해결하기
혁신을 위한 비즈니스 기회가 어디 있는지 살펴보면 정보 기술이 최우선은 아니더라도 상위 3위 안에 든다는 것을 알게 될 것이다. CIO로써 IT 혁신을 담당하거나 CDO(Chief Digital Officer)를 임원 리더십 팀에 추가하는 아이디어를 도입해야 한다.

하지만 개인적으로 CDO에 대해서는 의구심이 든다. IT리더십이 분열되어 CDO는 해야 할 일을 이야기하고 CIO는 거절만 하는 사람이 될 수 있기 때문이다.  

대신에 IT혁신을 IT아키텍처 활동에도 적용하는 것을 검토해볼 만하다. 그렇게 하면 조직의 혁신을 도모하여 관심이 분산되지 않을 뿐 아니라 IT혁신을 IT아키텍처의 나머지 부분에 통합해야 하는 장기적인 필요로서 혁신을 담당하게 될 것이다. 어쨌든 IT 혁신이 고립된 것이어서는 안 된다.

‘DIY IT’를 처리하는 방법
DIY IT는 ‘셰도우 IT’, ‘악당 IT’(rogue IT), ‘멈춰!!! 편두통이 온다!!!! IT’(STOP IT!!! You’re giving me a migraine!!!! IT)로도 알려져 있다. 이로 인해 너무나 많은 CIO들이 이를 해결하기 위해 노력하고 있다.

그러나 이것은 파도에게 오지 말라고 명령하는 카누트 왕(King Canute)과 같다.

어쨌든, DIY IT는 IT지출 또는 최소한 눈에 보이는 IT지출을 증가시키지 않고 회사의 IT 대역폭을 극적으로 넓혀 주기 때문에 문제라기 보다는 기회이다.

DIY IT의 단점은 대부분 피할 수 있다. 대부분의 경우 IT가 기술 컨설팅 측면에서 약간의 지원을 제공하여 IT아키텍처 표준을 준수하도록 하면 되며, 그 대신에 IT 아키텍처 기능은 DIY IT가 은밀한 IT가 되는 것을 방지하기 위해 필요한 문서를 얻게 된다.

결론
IT가 역량을 확보하려면 잘 고안되고 정의되며 문서화된 프로세스와 활동을 활용하여 성과를 달성해야 한다. CIO는 이 모든 것을 책임지지만 3가지 이상의 전환을 직접 주도하는 데는 무리가 있다.

요약하자면 대부분의 IT 조직에서 CIO의 직접 리더십이 가장 필요한 3가지 프로세스 영역은 업무지원센터, 애플리케이션 지원, IT 아키텍처 관리이다. 이것들을 잘 다듬으면 IT는 눈에 띄게 성공할 것이며, 그 결과는 기업의 비즈니스 성과로 나타날 것이다. 

IT운영은 분명 중요하다. 그러나 CIO는 이 책임을 위임해야 한다. 역설적이지만 그렇다. 이러한 진실을 외면한다면 중요한 3가지를 다듬을 충분한 여유가 없게 될 것이다. 

* Bob Lewis는 IT와 현업 관계, 전략 실행 계획에 중점을 IT 컨설턴트다. ciokr@idg.co.kr

X