Offcanvas

경력관리 / 비즈니스|경제 / 클라우드

클라우드, 개발자를 비즈니스에 초대하다

2012.08.13 Bernard Golden  |  CIO
아마존 웹 서비스, 즉 AWS는 IT의 '파괴적인 혁신'을 대표한다. 그리고 파괴적인 혁신이 IT의 미래에 의미하는 바를 이해하기 위해서는 파괴의 기본을 이해하는 것이 중요하다.

클레이톤 크리스텐센의 베스트셀러 저서인 '이노베이터 딜레마와 솔루션(The Innovator's Dilemma and The Innovator's Solution)'에서는 파괴적 혁신 이론이 처음 소개됐다. 파괴적 혁신이란 신생 기업이 기존 시장에 진입해 기존 솔루션(제품 또는 서비스)을 대체하는 새로운 대체 솔루션을 제공해 고객의 기대치를 크게 바꿔놓는 것을 의미한다.

파괴적 혁신은 새로운 시장 진입자가 복잡하고 비싼 기존 솔루션에 불만을 갖고 있는 고객들을 대상으로 저렴하면서, 사용이 편리한 솔루션을 제공하는 방법을 파악했을 때 발생하는 경우가 일반적이다.

크리스텐센은 고객들이 기존 솔루션에 불만을 갖는 이유에 대해 '지나침' 때문이라고 지적했다. 다른 말로 설명하면, 고객의 니즈는 한층 단순하지만 기존 벤더들이 이런 니즈를 충족해주지 않는다. 많은 기능을 갖추고 있어 복잡하고 값비싼 솔루션을 판매할 뿐, 간소화한 저렴한 제품에는 관심을 두지 않기 때문이라는 것이다.

클라우드가 개발자에 전달하는 경쟁력: 속도와 적응성
파괴적 혁신의 맥락에서 볼 때 개발자들이 AWS를 반기는 것은 당연하다. 개발자들은 인프라 자원이 필요할 때 통상 운영 그룹에 이를 요청한다. 그런데 운영 그룹은 본래 생산 체계에 더 초점을 맞추는 법이다. 운영 그룹은 체계적인 프로세스 관리를 중시한다. 모든 중요 생산 애플리케이션의 안정성이 저해되지 않도록 만전을 기하는데 목표를 둔다. 이런 이유로 인프라를 변경하기까지 몇 주가 걸리곤 한다.

이는 생산 애플리케이션에 적합한는 방식이다. 그러나 개발자들은 자원을 빨리 확보하고, 스스로 프로세스를 관리하기 원하며, 결과적으로 불만을 가질 수밖에 없다. 개발자들에게 기존 방식은 '지나친' 방식이다. 마찰이 크지 않으면서도 저렴한 AWS가 광범위하게 보급된 이유는 이런 맥락에서 설명이 된다.

AWS는 시장을 자극했다. 개발자들의 민첩성을 높여 시장의 '창조적인' 활기를 북돋았기 때문이다. 개발자들은 단 몇 분 만에 쉽게, 그리고 저렴하게 자원을 확보할 수 있게 되면서 자유로이 실험을 하고, 애플리케이션 개발을 앞당겼다. 결과적으로 기업이 시장 기회에 빠르게 반응할 수 있도록 일조했다,

즉 AWS는 개발자들이 IT 내부에서 더욱 중요한 위치를 차지하도록 도왔다. 마찰이 크지 않은 서비스를 통해 비즈니스 니즈에 한층 신속하게 반응할 수 있도록 한 것이다.

작지만 저명한 컨설팅 회사인 레드몽크(RedMonk)는 개발자들이 IT 킹메이커 역할을 차지했다고 주장하고 있다. 이들은 상부에서 중요한 IT 도입 결정을 내리는 모델이 잘못됐다며, 대신 CIO들은 전통적으로 폄하됐던 개발자들을 비롯한 IT 조직 하부의 사람들이 내린 결정에 의존해 결정을 내린다고 주장하고 있다. CIO들은 '하부' 개발자들의 결정을 승인하는 역할만 하고 있을 뿐이라는 의미다.

주도할 수는 있어도 지배할 준비는 미진한 개발자들
필자의 개인 경험에 비추어보면 이런 시각에도 타당성이 높다. IT 조직의 경우 창조성이 하부에 자리를 잡고 있기 때문이다. 창의적인 개발자들이 새로운 세대의 툴을 이용해 애플리케이션을 사용하기 시작하면, 상부에서는 얼마 지나지 않아 이들 툴을 공식적으로 승인하곤 한다.

이런 크리에이티브에 있어 AWS의 역할을 간과할 수 없다. 많은 IT 조직들이 프라이빗 클라우드에만 의존하고 있는 기존 전략을 수정해 AWS를 받아들이고 있는 추세다. 필자는 앞서 포스팅한 글에서 이를 '추가(And)' 전략이라고 표현했다. 내부 클라우드와 AWS를 동시에 활용하는 클라우드 전략을 채택하고 있다는 의미다.

그러나 IT 부서들이 이런 개발자 중심의 방식을 무분별하게 채택하는 것도 스스로에게 해가 된다. 이유는 다음과 같다.

오늘날 IT 업무와 관련한 관행에서 어처구니없는 관행들이 있다. 기껏해야 2주에 한차례 회의를 갖는 변경 관리 위원회, 결과보다는 과정에 치우친 ITIL 이행, 안정성을 이유로 애플리케이션 업데이트를 주저하는 운영 그룹 등이다.

그러나 이런 기능/부서/프로세스들이 존재하는 중요한 이유도 있기 마련이다. 따라서 이를 간과하거나 무시하는 것 또한 바른 해법이 아니다. 생산 시스템을 차질 없이 업데이트하고, 누가 인프라를 변경했는지 추적하고 확인하는 등의 기능은 클라우드 컴퓨팅을 도입한다고 해도 없어지지 않는 전사적인 기업 기능이다.

그렇다면 개발자가 주도하는 오늘날의 환경이 이런 부분들에 중점을 두지 않는 이유는 뭘까?
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
Sponsored
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.