2011.03.28

[기고] 클라우드 도입 프로젝트 : 3가지 주의점

David Taber | CIO

대부분의 사람들이 클라우드 앱에 대해 기존의 소프트웨어 프로젝트보다 한층 빠르고, 편리한 그런 것이라고 말하고 있다. 맞는 말이다. 클라우드 프로젝트는 그럴 수 있다. 제대로만 도입이 이뤄진다면, 이것들은 몇 개의 소프트웨어가 촘촘하게 얽히고 설킨 소프트웨어 프로젝트에 비해 더 가볍고, 더 간단하고, 분리도 쉽다.

 

하지만 제대로 도입이 이루어지지 않는다면, 대규모 소프트웨어 프로젝트에 도사리고 있는 모든 위험을 고스란히 갖게 된다. 이도 모자라 클라이언트/서버 세상에서는 들어보지 못한 새로운 함정도 있을 수 있다. 사람들은 클라우드 프로젝트를 진행하면서, 제대로 통제를 하지 못하는 기존 서비스를(매시업, RESTful. SOAP) 그대로 활용하려고 시도하곤 한다. 그리고 기존의 외부 서비스를 더 많이 사용할수록, 유쾌하지 않은 경험을 할 확률도 높아진다.

 

필자는 최근 몇 주, 경영진들이 강요 때문에 사실상 실패할 것이 분명한 클라우드 프로젝트들을 접했다. 이런 프로젝트들의 패턴을 그대로 답습하는 의사결정이나 발언들에 주의하기 바란다. 비용과 일정, 품질 문제를 야기시키기 때문이다.

 

1. "우선순위에 대해 뭐라고 말하기 힘들다. 모두 중요한 요건들이기 때문이다!"

경영진으로서는 이런 식의 생각을 하기 쉽다. 특히 고객들에게 프로젝트가 가져다 줄 장점을 잔뜩 설명하고, 이미 판매를 해버린 상황이라면 말이다.

 

하지만 현실은 다르다. 어떤 프로젝트이든 개발과 테스트, 전개를 하는 동안 일종의 타협을 해야만 한다. 여기서 문제가 되는 부분은 이것들이 '은닉적/정치적/무작위'인지, 아니면 '개방적/합리적/경제적'인지 하느냐이다.

 

비즈니스의 가치/혜택 또는 비용 측면에서 정확하게 동등한 두 가지 요건이란 없다. 따라서 '모두가 다 중요하다(더 심한 경우는 절대적이거나, 협상의 여지가 없을 정도로 중요하다)'는 식의 주장은 비즈니스 결정을 왜곡할 뿐이다.

 

최악의 경우 이런 종류의 지시는 해당 팀들이 결정을 내리지 못하도록 유도한다. 또 나쁜 뉴스를 보고하지 못하도록 만든다. 이렇게 되면 최후의 순간까지 '모든 것이 다 잘 돌아가고 있다'는 대답만 하게 된다. 하지만 일반적으로 프로젝트가 실제 끝나는 시점에서는 '아주 좋지 않은 의미'에서의 놀라움만이 기다리고 있을 뿐이다.

 

클라우드 프로젝트의 장점은 빠르게, 하지만 저렴한 비용에 조기 반복 베어본(bare-bone) 기능을 제공한다는데 있다. 또 이후 프로젝트 주기 동안 기능을 점진적으로 확대하도록 해준다.

 

'전부냐 제로냐'식의 의무를 지게 되면 기회를 잃어버린다. 그리고 이는 프로젝트 시간과 비용, 위험을 대가로 한다. 애자일(Agile) 프로젝트가 우리에게 가르쳐준 점은, 요건들이 사용자 피드백에 순응하고 조정 가능하도록 취급되어야 한다는 점이다. 이는 CRM 프로젝트에 있어 더 큰 중요성을 갖는다. 기능(feature)의 활용도가 근간 기능(function)보다 더 중요하기 때문이다. 사용자가 채택을 하지 않는다면, 기능이 뿌리를 내리지 못한다는 이유에서다.

 

2. "우리는 이번 프로젝트의 모든 요소들을 공통의 툴, 라이브러리, 기반 요소에 집어 넣어야만 한다."

물론 누구나 이동을 최소화 하기 바란다. 그리고 가능한 학습곡선을 최소화 하는 것도 중요하다. 그러나 클라우드 프로젝트는 탄력적일 필요가 있다. 모든 것들이 빠르게 움직이기 때문이다. 예를 들어, PHP 라이브러리의 특정 버전은 어떤 클라우드에는 잘 어울러지지만, 또 다른 클라우드 서비스는 이를 지원하지 않는다. 특정 지불 게이트웨이의 API는 기업이 표준화 하고 있는 게이트웨이를 지원하지 않는다고 명기하고 있을 수도 있다. 이 경우, SOAP, REST, naked XLM 인터체인지를 동시에 사용해야 할 수도 있다.

 

그리고 클라우드 방식의 주요 장점 중 하나는 이런 근간이 되는 도입 규제에 대한 대비책을 제공해준다는 점에 있다. 그렇다고 '하나로 모든 것을 맞추겠다'는 식의 지침을 지나치게 이용해서는 안 된다.

 

3. "사용자 테스트를 해가면서 진행할 시간이 없다. 마지막에 하는 걸로 하자."

군대와도 같은 '명령 및 통제'식 프로젝트 관리 스타일을 고수하는 사람들이 일반적으로 내뱉는 말이다. 확신에 대한 갈증을 충족해주기 때문이다.

 

그러나 이런 확신은 환상이다. 개발(생산) 프로세스의 모든 단계에서의 품질을 견인하지만, 이를 추적하지 않는 상태에서도 제품 비용, 일정, 위험을 경감할 수 있다고 확신해서는 안 된다. 사용자 테스트를 미룬다는 이야기는 함정에 빠지는 것과 다를 바 없다.

 

특히 클라우드 프로젝트에서는, 직접 구축하지도 관리하지도 않는 서비스를 지렛대로 활용한다는 점에서 이런 문제들이 더욱 증폭될 수 있다. 클라우드 서비스는 여러분의 사용자가 원하는 것을 정확히 해줄 수도, 그렇지 못할 수도 있다. 외부로부터 통합해온 클라우드 기능성과 모든 요소들을 실제 시험 배치 해보기 전까지는, 해당 프로젝트가 사용자의 니즈를 충족하는지 알 방법이 없다. 예를 들어, 간단한 맵 매시-업(map mash-up)이 특정 요소에 잘 들어맞을 수 있다. 그러나 중요한 고객에게 혼란을 초래하거나, 대책 없이 느릴 가능성도 있다.

 

따라서 퍼블릭 클라우드 서비스를 이용할 경우, 최소한 몇 주 동안 특정 조건에서 테스트를 진행해 보기 전까지는 성능이나 신뢰성 관련 문제를 발견하지 못할 수도 있다. 개발자가 단위 별로 테스트를 하는 동안에는 모든 것이 정상적으로 작동할 수 있다. 그러나 아무도 이용하지 않는 새벽 2시에 이런 테스트를 했기 때문일 수도 있다.

 

따라서 한창 바쁜 시간에 퍼블릭 클라우드를 시험해 봐야 한다. 다른 서비스로 전환할 필요가 있는지를 발견할 수도 있을 것이다. 프로젝트의 후반기에 이런 점들을 깨닫는다면 너무 늦다. 상당한 비용이 초래되기 십상이다.

 

CRM 프로젝트의 경우 이런 문제들이 더욱 증폭된다. 소프트웨어의 기능성만큼 시스템 데이터가 시스템 가치를 결정하는데 중요한 역할을 하기 때문이다. 거짓 데이터로 사용자 테스트를 하는 것 또한 아무런 의미가 없다. 잘못된 결과를 줄 수 있다.

 

필자는 프로젝트 시작 단계부터 아주 많은 실제 데이터를 이용해 사용자 테스트를 수행할 것을 강력히 권장한다. 또 전체 데이터를 시스템에 넣기 전까지는 최종 결정을 내리는데 참조할 테스트를 시작하지 말기 바란다. 사용자가 시스템을 이용해 실제 업무를 수행하기 전까지는 버그나 단점을 확인하지 못하는 경우가 많다는 점을 명심해야 한다.

 

 * 데이비드 타버는 프렌티스 홀 출판사가 새로 출간한 <세일즈포스닷컴의 성공 비밀(Salesforce.com Secrets of Success)>이라는 책의 저자이자, 세일즈로지스틱스의 CEO다. ciokr@idg.co.kr




2011.03.28

[기고] 클라우드 도입 프로젝트 : 3가지 주의점

David Taber | CIO

대부분의 사람들이 클라우드 앱에 대해 기존의 소프트웨어 프로젝트보다 한층 빠르고, 편리한 그런 것이라고 말하고 있다. 맞는 말이다. 클라우드 프로젝트는 그럴 수 있다. 제대로만 도입이 이뤄진다면, 이것들은 몇 개의 소프트웨어가 촘촘하게 얽히고 설킨 소프트웨어 프로젝트에 비해 더 가볍고, 더 간단하고, 분리도 쉽다.

 

하지만 제대로 도입이 이루어지지 않는다면, 대규모 소프트웨어 프로젝트에 도사리고 있는 모든 위험을 고스란히 갖게 된다. 이도 모자라 클라이언트/서버 세상에서는 들어보지 못한 새로운 함정도 있을 수 있다. 사람들은 클라우드 프로젝트를 진행하면서, 제대로 통제를 하지 못하는 기존 서비스를(매시업, RESTful. SOAP) 그대로 활용하려고 시도하곤 한다. 그리고 기존의 외부 서비스를 더 많이 사용할수록, 유쾌하지 않은 경험을 할 확률도 높아진다.

 

필자는 최근 몇 주, 경영진들이 강요 때문에 사실상 실패할 것이 분명한 클라우드 프로젝트들을 접했다. 이런 프로젝트들의 패턴을 그대로 답습하는 의사결정이나 발언들에 주의하기 바란다. 비용과 일정, 품질 문제를 야기시키기 때문이다.

 

1. "우선순위에 대해 뭐라고 말하기 힘들다. 모두 중요한 요건들이기 때문이다!"

경영진으로서는 이런 식의 생각을 하기 쉽다. 특히 고객들에게 프로젝트가 가져다 줄 장점을 잔뜩 설명하고, 이미 판매를 해버린 상황이라면 말이다.

 

하지만 현실은 다르다. 어떤 프로젝트이든 개발과 테스트, 전개를 하는 동안 일종의 타협을 해야만 한다. 여기서 문제가 되는 부분은 이것들이 '은닉적/정치적/무작위'인지, 아니면 '개방적/합리적/경제적'인지 하느냐이다.

 

비즈니스의 가치/혜택 또는 비용 측면에서 정확하게 동등한 두 가지 요건이란 없다. 따라서 '모두가 다 중요하다(더 심한 경우는 절대적이거나, 협상의 여지가 없을 정도로 중요하다)'는 식의 주장은 비즈니스 결정을 왜곡할 뿐이다.

 

최악의 경우 이런 종류의 지시는 해당 팀들이 결정을 내리지 못하도록 유도한다. 또 나쁜 뉴스를 보고하지 못하도록 만든다. 이렇게 되면 최후의 순간까지 '모든 것이 다 잘 돌아가고 있다'는 대답만 하게 된다. 하지만 일반적으로 프로젝트가 실제 끝나는 시점에서는 '아주 좋지 않은 의미'에서의 놀라움만이 기다리고 있을 뿐이다.

 

클라우드 프로젝트의 장점은 빠르게, 하지만 저렴한 비용에 조기 반복 베어본(bare-bone) 기능을 제공한다는데 있다. 또 이후 프로젝트 주기 동안 기능을 점진적으로 확대하도록 해준다.

 

'전부냐 제로냐'식의 의무를 지게 되면 기회를 잃어버린다. 그리고 이는 프로젝트 시간과 비용, 위험을 대가로 한다. 애자일(Agile) 프로젝트가 우리에게 가르쳐준 점은, 요건들이 사용자 피드백에 순응하고 조정 가능하도록 취급되어야 한다는 점이다. 이는 CRM 프로젝트에 있어 더 큰 중요성을 갖는다. 기능(feature)의 활용도가 근간 기능(function)보다 더 중요하기 때문이다. 사용자가 채택을 하지 않는다면, 기능이 뿌리를 내리지 못한다는 이유에서다.

 

2. "우리는 이번 프로젝트의 모든 요소들을 공통의 툴, 라이브러리, 기반 요소에 집어 넣어야만 한다."

물론 누구나 이동을 최소화 하기 바란다. 그리고 가능한 학습곡선을 최소화 하는 것도 중요하다. 그러나 클라우드 프로젝트는 탄력적일 필요가 있다. 모든 것들이 빠르게 움직이기 때문이다. 예를 들어, PHP 라이브러리의 특정 버전은 어떤 클라우드에는 잘 어울러지지만, 또 다른 클라우드 서비스는 이를 지원하지 않는다. 특정 지불 게이트웨이의 API는 기업이 표준화 하고 있는 게이트웨이를 지원하지 않는다고 명기하고 있을 수도 있다. 이 경우, SOAP, REST, naked XLM 인터체인지를 동시에 사용해야 할 수도 있다.

 

그리고 클라우드 방식의 주요 장점 중 하나는 이런 근간이 되는 도입 규제에 대한 대비책을 제공해준다는 점에 있다. 그렇다고 '하나로 모든 것을 맞추겠다'는 식의 지침을 지나치게 이용해서는 안 된다.

 

3. "사용자 테스트를 해가면서 진행할 시간이 없다. 마지막에 하는 걸로 하자."

군대와도 같은 '명령 및 통제'식 프로젝트 관리 스타일을 고수하는 사람들이 일반적으로 내뱉는 말이다. 확신에 대한 갈증을 충족해주기 때문이다.

 

그러나 이런 확신은 환상이다. 개발(생산) 프로세스의 모든 단계에서의 품질을 견인하지만, 이를 추적하지 않는 상태에서도 제품 비용, 일정, 위험을 경감할 수 있다고 확신해서는 안 된다. 사용자 테스트를 미룬다는 이야기는 함정에 빠지는 것과 다를 바 없다.

 

특히 클라우드 프로젝트에서는, 직접 구축하지도 관리하지도 않는 서비스를 지렛대로 활용한다는 점에서 이런 문제들이 더욱 증폭될 수 있다. 클라우드 서비스는 여러분의 사용자가 원하는 것을 정확히 해줄 수도, 그렇지 못할 수도 있다. 외부로부터 통합해온 클라우드 기능성과 모든 요소들을 실제 시험 배치 해보기 전까지는, 해당 프로젝트가 사용자의 니즈를 충족하는지 알 방법이 없다. 예를 들어, 간단한 맵 매시-업(map mash-up)이 특정 요소에 잘 들어맞을 수 있다. 그러나 중요한 고객에게 혼란을 초래하거나, 대책 없이 느릴 가능성도 있다.

 

따라서 퍼블릭 클라우드 서비스를 이용할 경우, 최소한 몇 주 동안 특정 조건에서 테스트를 진행해 보기 전까지는 성능이나 신뢰성 관련 문제를 발견하지 못할 수도 있다. 개발자가 단위 별로 테스트를 하는 동안에는 모든 것이 정상적으로 작동할 수 있다. 그러나 아무도 이용하지 않는 새벽 2시에 이런 테스트를 했기 때문일 수도 있다.

 

따라서 한창 바쁜 시간에 퍼블릭 클라우드를 시험해 봐야 한다. 다른 서비스로 전환할 필요가 있는지를 발견할 수도 있을 것이다. 프로젝트의 후반기에 이런 점들을 깨닫는다면 너무 늦다. 상당한 비용이 초래되기 십상이다.

 

CRM 프로젝트의 경우 이런 문제들이 더욱 증폭된다. 소프트웨어의 기능성만큼 시스템 데이터가 시스템 가치를 결정하는데 중요한 역할을 하기 때문이다. 거짓 데이터로 사용자 테스트를 하는 것 또한 아무런 의미가 없다. 잘못된 결과를 줄 수 있다.

 

필자는 프로젝트 시작 단계부터 아주 많은 실제 데이터를 이용해 사용자 테스트를 수행할 것을 강력히 권장한다. 또 전체 데이터를 시스템에 넣기 전까지는 최종 결정을 내리는데 참조할 테스트를 시작하지 말기 바란다. 사용자가 시스템을 이용해 실제 업무를 수행하기 전까지는 버그나 단점을 확인하지 못하는 경우가 많다는 점을 명심해야 한다.

 

 * 데이비드 타버는 프렌티스 홀 출판사가 새로 출간한 <세일즈포스닷컴의 성공 비밀(Salesforce.com Secrets of Success)>이라는 책의 저자이자, 세일즈로지스틱스의 CEO다. ciokr@idg.co.kr


X