2021.10.12

칼럼ㅣ클라우드 마이그레이션만으로 끝이 아니다··· 지금부터 고려할 사항은?

Scott Hutcheson | CIO
여러 클라우드 마이그레이션 사례를 통해 알 수 있는 한 가지 중요한 사실은 클라우드 이전을 완료한 것만으로 성공을 보장할 수 없다는 것이다. 클라우드 마이그레이션을 완료한 후 이니셔티브의 성공을 위해서 기술 리더들이 낡은 사고방식에서 탈피하고 다양한 리더십 유형을 추구할 필요가 있다.
 
ⓒ Gremlin / Getty Images

2011년, <디 애틀랜틱(The Atlantic)>의 선임 에디터 레베카 로젠은 원격 데이터 저장소를 날마다 변화하는 구름에 빗대 ‘클라우드’라는 용어로 표현한 것이 역대 가장 적절한 비유라고 주장했다. 실제로 클라우드 컴퓨팅은 끊임없이 변화하고 있다.

IT 리더들이 지속적으로 변화하는 클라우드에 적응하려고 애를 쓰고 있다. 그리고 이처럼 끊임없이 변화하는 특성 때문에 클라우드 이니셔티브는 높은 실패율을 기록하고 있다. 엔터프라이즈 클라우드 전문 기업 블루 센트리 클라우드의 전략 담당 케네스 존슨은 "대부분의 기술 리더들이 인프라의 유동적이고 역동적인 측면에 대해 사고하는 데 어려움을 겪고 있다"라고 지적했다.

존슨은 "종래의 정적인 방식으로 사고하는 것은 클라우드 전략과 전반적인 사업 전략을 효과적으로 일치시키는 것을 어렵게 만든다"라며, "이것이 클라우드 이니셔티브를 복잡하게 만드는 이유이자 상당수가 실패하는 이유다"라고 말했다. 이어 그는 "예산 한도 내에서 적시에 클라우드로 마이그레이션하는 것은 그 자체로 어렵다"라며, "클라우드 마이그레이션 이후 혁신을 이루는 작업은 훨씬 더 어렵다"라고 말했다.

클라우드와 관련된 설문조사 결과도 이를 뒷받침한다. 2019년 ‘클라우드 씨큐리티 얼라이언스(Cloud Security Alliance)’의 '클라우드가 ERP에 미치는 영향(Impact of Cloud on ERP)' 조사에 따르면 CIO의 90%가 클라우드 관련 작업에서 실패 또는 중단을 경험했다고 답했다. IHS 마킷의 조사에서는 기업의 74%가 애플리케이션을 클라우드로 이전하려고 시도했으나 실패해 온프레미스로 다시 이전해야 했다고 답했다.

클라우드 이니셔티브의 실패는 이전과는 완전히 다른 차원의 사고방식이 요구되는 영역을 IT 리더들이 제대로 이해하지 못할 때 발생한다. 오래된 프로세스와 도구, 인적 역량을 그대로 클라우드로 이전하는 것은 실패의 지름길이다. 특히 보안, 안정성, 비용 거버넌스 부문에서 그렇다.

낡은 사고방식에서 탈피해야 한다
온프레미스 인프라의 비용 거버넌스에서는 장비 구매를 하거나, 벤더와 계약을 맺거나, 또는 직원을 고용하면 비용이 점진적으로 증가한다. 이러한 항목은 관리자의 승인이 필요하고 엄격한 감독 하에 진행되기 때문에 비교적 통제하기 쉽다.

하지만 클라우드에서는 다르다. 기업에서는 1분에 500개의 가상 머신이 작동하고, 수요에 대응하기 위해 오토스케일링(autoscaling) 기능이 실행되면 몇 분 후에는 그 규모가 5,000대로 급격히 늘어난다. 보안 관리 및 워크로드 안정성과 관련된 분야에서도 이와 유사한 경향을 보인다.

낡은 사고방식을 가진 기술 분야의 리더들은 통제와 클라우드의 이점 사이에서 상충 관계에 직면한다.

클라우드를 활용하면 민첩성, 확장성, 비용 절감, 혁신 등의 이점이 있고, 수동 프로세스보다 자동화 방식을 도입하게 된다. 다시 말해 클라우드의 새로운 질서에서는 기존 팀에서 갖고 있던 역량이 필요하지 않을 수 있다. 드라이브를 연결하고 케이블을 구축하는 대신 몇 줄의 코드를 작성하는 방식으로 대체될 경우 업무가 줄면서 팀원들이 (직업 안정성에 대한) 위협을 느낄 수 있다.

이는 클라우드 이니셔티브 성공을 위해 새로운 사고방식이 요구되는 한편, 이전과는 다른 스타일의 리더십이 필요하다는 의미이기도 하다.
 
클라우드 마이그레이션에 필요한 리더 유형
많은 리더들이 앞서 언급한 차이점을 인지하고 있지만, 클라우드 이니셔티브의 실패 확률은 여전히 높다.

휴먼 인사이트의 세바스티안 하머스와 그의 팀은 조직 트랜스포메이션에서 리더십의 역학 관계에에 대해 연구했고, 이를 통해 클라우드 이니셔티브의 실패 확률이 높은 이유를 부분적으로 파악했다. 특히 체계적으로 클라우드 마이그레이션을 수행하는 것이 언제나 성공적인 클라우드 운영 및 비즈니스 혁신을 보장하지 않는 이유를 설명하는 프레임워크를 제시했다. 이들은 광범위한 리서치와 평가를 통해 기술 리더의 두 가지 특징을 관찰하고, 이를 ‘기술 마샬(Technology Marshal)’과 ‘기술 매버릭(Technology Maverick)’으로 구분해 자세히 설명했다.

1. ‘기술 마샬(The Technology Marshal)’의 특성
‘기술 마샬(Technology Marshal)’은 형태가 명확히 보이는 제품 또는 서비스에서 가치를 창출하는 규제 담당자를 의미한다. 이러한 마샬형 리더는 레거시 시스템을 관리하는 데 능숙하다. 또 문제를 효과적으로, 과감하게 해결하기 위해 자신이 갖고 있는 지식과 과거의 경험을 적용한다.

체계적으로 사고하는 이러한 리더 유형은 시스템 관리에 탁월하고 정확하게 실행하며, 주어진 일을 원활하게 진행시킨다. '기술 마샬'은 성장 과정의 초기 단계에서 실현된 것을 최적화하고 보호하는 데 주력하는 반면, 성장과 혁신, 트랜스포메이션의 후기 단계에서 최적의 기여를 한다.

2. ‘기술 매버릭(The Technology Maverick)’의 특성
'기술 매버릭'은 새로운 가능성을 구상하며 비전을 제시하는 리더 유형이다. 이 리더 유형은 A 지점에서 B 지점까지 (가능성을) 탐색한다. 또 이들은 아이디어와 콘텐츠, 개념, 접근법, 제품 및 서비스와 관련해 실험적으로 발견하는 것을 즐긴다.

이러한 리더는 이상향을 추구하고, 건전한 조언을 제공하여 발전을 이루고 싶어한다. 매버릭형 리더의 개념과 아이디어는 주변 사람들이 경계를 뛰어 넘어 생각하도록 자극할 수 있다. '기술 매버릭'은 새로운 아이디어와 방법, 수단을 모색하여 개척에 도움이 되는 결과를 만들어내며, 성장과 혁신, 트랜스포메이션의 초기 단계에서 최적의 기여를 한다.

두 가지 기술 리더 유형은 양극단에 존재한다. 어떤 기술 리더는 특성이 한 쪽으로 치우쳐 있고 다른 한 쪽의 성향을 보이지 않을 수 있다. 휴먼 인사이트가 약 10만 명이 넘는 리더에 대한 데이터를 수집한 결과, CIO와 CTO 중 마샬형 리더가 매버릭형 리더보다 훨씬 더 많은 것으로 나타났다. 이러한 조사 결과는 일리가 있다. 존슨은 "마샬형 리더 외에 데이터 보안을 보장할 수 있는 적임자가 또 있겠느냐"라고 강조했다. 하지만 존슨은 매버릭도 클라우드에서 무엇이 가능한지 모색할 때 필요한 리더 유형이라고 부연했다.

마사 헬러는 ‘CIO 역설: IT 리더십의 모순과 싸우기’라는 제목의 저서에서 마샬과 매버릭 두 가지 유형의 사고방식이 모두 필요하다고 말한다.

그러나 만약 휴먼 인사이트의 하머스 말이 옳다면 마샬과 매버릭 두 가지 특성을 모두 가진 리더는 유니콘 만큼 찾기 어려울 것이다. 그런 리더 유형은 실제로 존재하지 않는다는 얘기다. 하머스는 "아마 마샬 유형의 기술 리더가 훨씬 더 많을 것"이라며, "기술 리더 유형을 두 가지로만 구분하지 않고 CIO와 CTO 사이에서 더욱 다양한 리더십 스타일을 추구할 수 있다"라고 조언했다.

* Scott Hutcheson은 퍼듀대의 애자일 전략 랩에서 디렉터를 맡고 있으며, 조직 리더십에 대해 강의하고 있다. ciokr@idg.co.kr



2021.10.12

칼럼ㅣ클라우드 마이그레이션만으로 끝이 아니다··· 지금부터 고려할 사항은?

Scott Hutcheson | CIO
여러 클라우드 마이그레이션 사례를 통해 알 수 있는 한 가지 중요한 사실은 클라우드 이전을 완료한 것만으로 성공을 보장할 수 없다는 것이다. 클라우드 마이그레이션을 완료한 후 이니셔티브의 성공을 위해서 기술 리더들이 낡은 사고방식에서 탈피하고 다양한 리더십 유형을 추구할 필요가 있다.
 
ⓒ Gremlin / Getty Images

2011년, <디 애틀랜틱(The Atlantic)>의 선임 에디터 레베카 로젠은 원격 데이터 저장소를 날마다 변화하는 구름에 빗대 ‘클라우드’라는 용어로 표현한 것이 역대 가장 적절한 비유라고 주장했다. 실제로 클라우드 컴퓨팅은 끊임없이 변화하고 있다.

IT 리더들이 지속적으로 변화하는 클라우드에 적응하려고 애를 쓰고 있다. 그리고 이처럼 끊임없이 변화하는 특성 때문에 클라우드 이니셔티브는 높은 실패율을 기록하고 있다. 엔터프라이즈 클라우드 전문 기업 블루 센트리 클라우드의 전략 담당 케네스 존슨은 "대부분의 기술 리더들이 인프라의 유동적이고 역동적인 측면에 대해 사고하는 데 어려움을 겪고 있다"라고 지적했다.

존슨은 "종래의 정적인 방식으로 사고하는 것은 클라우드 전략과 전반적인 사업 전략을 효과적으로 일치시키는 것을 어렵게 만든다"라며, "이것이 클라우드 이니셔티브를 복잡하게 만드는 이유이자 상당수가 실패하는 이유다"라고 말했다. 이어 그는 "예산 한도 내에서 적시에 클라우드로 마이그레이션하는 것은 그 자체로 어렵다"라며, "클라우드 마이그레이션 이후 혁신을 이루는 작업은 훨씬 더 어렵다"라고 말했다.

클라우드와 관련된 설문조사 결과도 이를 뒷받침한다. 2019년 ‘클라우드 씨큐리티 얼라이언스(Cloud Security Alliance)’의 '클라우드가 ERP에 미치는 영향(Impact of Cloud on ERP)' 조사에 따르면 CIO의 90%가 클라우드 관련 작업에서 실패 또는 중단을 경험했다고 답했다. IHS 마킷의 조사에서는 기업의 74%가 애플리케이션을 클라우드로 이전하려고 시도했으나 실패해 온프레미스로 다시 이전해야 했다고 답했다.

클라우드 이니셔티브의 실패는 이전과는 완전히 다른 차원의 사고방식이 요구되는 영역을 IT 리더들이 제대로 이해하지 못할 때 발생한다. 오래된 프로세스와 도구, 인적 역량을 그대로 클라우드로 이전하는 것은 실패의 지름길이다. 특히 보안, 안정성, 비용 거버넌스 부문에서 그렇다.

낡은 사고방식에서 탈피해야 한다
온프레미스 인프라의 비용 거버넌스에서는 장비 구매를 하거나, 벤더와 계약을 맺거나, 또는 직원을 고용하면 비용이 점진적으로 증가한다. 이러한 항목은 관리자의 승인이 필요하고 엄격한 감독 하에 진행되기 때문에 비교적 통제하기 쉽다.

하지만 클라우드에서는 다르다. 기업에서는 1분에 500개의 가상 머신이 작동하고, 수요에 대응하기 위해 오토스케일링(autoscaling) 기능이 실행되면 몇 분 후에는 그 규모가 5,000대로 급격히 늘어난다. 보안 관리 및 워크로드 안정성과 관련된 분야에서도 이와 유사한 경향을 보인다.

낡은 사고방식을 가진 기술 분야의 리더들은 통제와 클라우드의 이점 사이에서 상충 관계에 직면한다.

클라우드를 활용하면 민첩성, 확장성, 비용 절감, 혁신 등의 이점이 있고, 수동 프로세스보다 자동화 방식을 도입하게 된다. 다시 말해 클라우드의 새로운 질서에서는 기존 팀에서 갖고 있던 역량이 필요하지 않을 수 있다. 드라이브를 연결하고 케이블을 구축하는 대신 몇 줄의 코드를 작성하는 방식으로 대체될 경우 업무가 줄면서 팀원들이 (직업 안정성에 대한) 위협을 느낄 수 있다.

이는 클라우드 이니셔티브 성공을 위해 새로운 사고방식이 요구되는 한편, 이전과는 다른 스타일의 리더십이 필요하다는 의미이기도 하다.
 
클라우드 마이그레이션에 필요한 리더 유형
많은 리더들이 앞서 언급한 차이점을 인지하고 있지만, 클라우드 이니셔티브의 실패 확률은 여전히 높다.

휴먼 인사이트의 세바스티안 하머스와 그의 팀은 조직 트랜스포메이션에서 리더십의 역학 관계에에 대해 연구했고, 이를 통해 클라우드 이니셔티브의 실패 확률이 높은 이유를 부분적으로 파악했다. 특히 체계적으로 클라우드 마이그레이션을 수행하는 것이 언제나 성공적인 클라우드 운영 및 비즈니스 혁신을 보장하지 않는 이유를 설명하는 프레임워크를 제시했다. 이들은 광범위한 리서치와 평가를 통해 기술 리더의 두 가지 특징을 관찰하고, 이를 ‘기술 마샬(Technology Marshal)’과 ‘기술 매버릭(Technology Maverick)’으로 구분해 자세히 설명했다.

1. ‘기술 마샬(The Technology Marshal)’의 특성
‘기술 마샬(Technology Marshal)’은 형태가 명확히 보이는 제품 또는 서비스에서 가치를 창출하는 규제 담당자를 의미한다. 이러한 마샬형 리더는 레거시 시스템을 관리하는 데 능숙하다. 또 문제를 효과적으로, 과감하게 해결하기 위해 자신이 갖고 있는 지식과 과거의 경험을 적용한다.

체계적으로 사고하는 이러한 리더 유형은 시스템 관리에 탁월하고 정확하게 실행하며, 주어진 일을 원활하게 진행시킨다. '기술 마샬'은 성장 과정의 초기 단계에서 실현된 것을 최적화하고 보호하는 데 주력하는 반면, 성장과 혁신, 트랜스포메이션의 후기 단계에서 최적의 기여를 한다.

2. ‘기술 매버릭(The Technology Maverick)’의 특성
'기술 매버릭'은 새로운 가능성을 구상하며 비전을 제시하는 리더 유형이다. 이 리더 유형은 A 지점에서 B 지점까지 (가능성을) 탐색한다. 또 이들은 아이디어와 콘텐츠, 개념, 접근법, 제품 및 서비스와 관련해 실험적으로 발견하는 것을 즐긴다.

이러한 리더는 이상향을 추구하고, 건전한 조언을 제공하여 발전을 이루고 싶어한다. 매버릭형 리더의 개념과 아이디어는 주변 사람들이 경계를 뛰어 넘어 생각하도록 자극할 수 있다. '기술 매버릭'은 새로운 아이디어와 방법, 수단을 모색하여 개척에 도움이 되는 결과를 만들어내며, 성장과 혁신, 트랜스포메이션의 초기 단계에서 최적의 기여를 한다.

두 가지 기술 리더 유형은 양극단에 존재한다. 어떤 기술 리더는 특성이 한 쪽으로 치우쳐 있고 다른 한 쪽의 성향을 보이지 않을 수 있다. 휴먼 인사이트가 약 10만 명이 넘는 리더에 대한 데이터를 수집한 결과, CIO와 CTO 중 마샬형 리더가 매버릭형 리더보다 훨씬 더 많은 것으로 나타났다. 이러한 조사 결과는 일리가 있다. 존슨은 "마샬형 리더 외에 데이터 보안을 보장할 수 있는 적임자가 또 있겠느냐"라고 강조했다. 하지만 존슨은 매버릭도 클라우드에서 무엇이 가능한지 모색할 때 필요한 리더 유형이라고 부연했다.

마사 헬러는 ‘CIO 역설: IT 리더십의 모순과 싸우기’라는 제목의 저서에서 마샬과 매버릭 두 가지 유형의 사고방식이 모두 필요하다고 말한다.

그러나 만약 휴먼 인사이트의 하머스 말이 옳다면 마샬과 매버릭 두 가지 특성을 모두 가진 리더는 유니콘 만큼 찾기 어려울 것이다. 그런 리더 유형은 실제로 존재하지 않는다는 얘기다. 하머스는 "아마 마샬 유형의 기술 리더가 훨씬 더 많을 것"이라며, "기술 리더 유형을 두 가지로만 구분하지 않고 CIO와 CTO 사이에서 더욱 다양한 리더십 스타일을 추구할 수 있다"라고 조언했다.

* Scott Hutcheson은 퍼듀대의 애자일 전략 랩에서 디렉터를 맡고 있으며, 조직 리더십에 대해 강의하고 있다. ciokr@idg.co.kr

X