2017.02.08

'밑 빠진 독에 물 붓기' 클라우드 사업이 예산을 초과하는 4가지 이유

David Taber | CIO
최근 클라우드 통합 기업을 상대로 비공식적 설문조사를 한 결과 매우 의외의 사실을 하나 발견했다. 고만 고만하고 정형화 된 퀵 스타트 프로젝트야 그렇다 해도, 새로운 고객을 상대로 한 클라우드 컨설팅의 70%에서 수주 변경이나 비용 초과가 나타난 것으로 조사됐기 때문이다. 특히 프로젝트 규모가 클 수록 비용이 초과될 가능성도 커졌다.



이에 대해 컨설턴트 탓을 할 수도 있고, 애초에 계산을 잘못했다거나 고객이 이상하다고 탓 할 수도 있겠지만, 누군가의 탓을 한다고 문제가 사라지지는 않는다. 중요한 것은 고객과 업체 모두에게 고통을 안겨주는 상당히 심각한 문제가 존재한다는 것이다.

만약 클라우드 비용이 예상을 넘어섰다면 십중팔구 잘못된 기대치 설정이 이유일 것이다. 특히 고객은 자신의 요구사항이 실제보다 훨씬 적은 비용으로 실제보다 훨씬 쉽게 충족할 수 있다고 믿는 경향이 있다. 하지만 설령 이것이 사실이라고 해도 이 부분에 대해 우리가 어떻게 해 볼 방법은 없다. 그러니 이것 외에 비용 초과를 초래하는 원인이 무엇인지 살펴보고 대처방법을 찾는 것이 현명하다.

비용 초과를 부채질하는 4가지 요소
클라우드 프로젝트 대부분은 여러 가지 파트로 정확하게 나뉘어 운용되므로 예상과 실제 비용 사이에 차이가 크게 나는 일은 별로 없다. 하지만 이건 어디까지나 이상적인 이야기이다. 주기적으로 비용 초과가 발생하는 프로젝트 분야는 다음과 같다.

1. 데이터 통합과 이전
데이터 통합과 이전은 마치 머리 둘 달린 괴물과 같다. 늪 한 가운데 빠질 때까지 무엇이 문제인지 모르고 지나치는 경우가 대부분이라 심각한 문제를 야기한다.

비용 초과는 데이터의 양과 데이터 소스에 비례한다. 표면적으로는 말끔해 보여도 포맷 문제, 부적합한 값, 의미론적 과적과 객체-모델(object-model)의 모호함 등 데이터 통합과 이전을 복잡하게 만드는 요소가 수두룩하다. 특히 지속적 통합이 요구되는 상황에서는 초반에 사용한 포인트-투-포인트 어댑터를 결국 미들웨어 시스템으로 대체해야 한다는 것을 알아채지 못할 수 있다.

해법 : 이전 및 통합할 데이터의 양, 데이터 소스에 대한 비용편익 분석을 실시하고 현실적인 비용을 설정해야 한다. 프로젝트를 시작할 때 이전/통합/확인과 관련된 작업을 시작해 프로젝트가 한참 진행된 후에 놀라는 일이 없도록 하자. 데이터 이전과 통합이 프로젝트에 있어 가장 큰 부분을 차지할 수 있다는 점을 미리 염두에 두어야 한다.

2. 커스텀 코드
많은 기업이 프로젝트를 규정함에 있어 ‘코드 없이, 고정 관념의 틀을 깨는’ 프로젝트가 되길 희망하지만 하루도 채 지나지 않아 이를 충족하는 것이 불가능하다는 것을 깨닫는다. 안타깝지만 컨설턴트 중에는 코드를 사랑하는 이들이 많기 때문에, 이들은 적극적으로 고객을 커스텀 코드의 세계로 인도하려 한다.

게다가 SFDC(Salesforce.com) 플랫폼의 훌륭한 코딩 환경은 사용자 인터페이스나 비즈니스 로직 측면에서 봐도 코딩을 더 매력적인 옵션으로 보이게 한다. 그러나 문제는 개발자 생산성과 코드 유지 비용이다. 커스텀 코딩은 표준 설정 방식보다 비용이 훨씬 많이 들어간다.

해법 : 가능한 한 표준적인 시스템 기능과 기성 플러그인 제품을 이용하도록 노력한다. 요구 사항을 최대한 가용 자원에 맞도록 조정하고, 초기 배포 단계에서 코딩을 최대한 배제해 코더가 안정적인 플랫폼에서 작업할 수 있도록 해야 한다. 아이템 개발의 경우 보안 모델, 명령 설정, 배포/파트너 네트워크 등 조합적 확산을 유발할 수 있는 스트림 라인 프로세스와 비즈니스 룰에 위임해야 한다.


3. 보기 좋은 떡이 먹기도 좋다?
오리지널 SFDC 리포팅 엔진은 파워와 사용 용이성 간의 균형이 훌륭하지만, 최종 결과물은 거의 스프레드시트 수준에 그친다. 따라서 한 눈에 들어오는 보기 좋은 리포트를 원한다면 오리지널 SFDC 엔진만으로는 금세 한계에 부딪힐 것이다.

SFDC의 웨이브 리포팅 시스템은 더 강력하면서도 보기 좋은 리포트를 제공하지만, 이를 제대로 사용하려면 쿼리 코드를 써야 한다. 한걸음 더 나아가 깔끔한 포맷, 멀티 페이지 레이아웃, 자동 오피스 도큐먼트 생성 같은 작업까지 하려면 서드 파티 애드-온이 필요하다. 그러나 모든 프로젝트가 그렇듯 외양에 신경을 쓰면 쓸 수록 비용은 더 많이 들어간다. 최초 설치 비용뿐 아니라 사용자의 요구에 맞춰 이용하는 과정에서도 마찬가지다.

해법 : 포맷과 개별 사용자의 수정 내용에 이르기까지 리포트의 모든 변수를 하나하나 빼놓지 말고 철저히 이해하고 구체화하라. 처음엔 10개를 생각했는데 알고 보니 100개 이상의 리포트가 필요하다면 그 사실을 빨리 알게 될수록 더 좋다. 액세스나 크리스탈 등 시스템 에뮬레이션(emulation)이 필요한 리포트가 있다면 업체에게 포맷과 예외 조건에 대한 주석을 달아 입력 데이터 샘플과 리포트의 결과물을 제시해야 한다.

4. 프로젝트 관리와 감사
이는 철저히 프로젝트 리더, 임원에 의해 주도되는 과정이어서 해당 관리자의 행위는 곧바로 비용 초과로 이어질 수 있다. 프로젝트에서 거리와 지연이 효율성과 경제성을 해치는 가장 큰 위협이라는 것은 익히 알고 있을 것이다. 필자는 여기에 ‘망설임’과 ‘(끝을 모르는) 재발견’을 추가하겠다. 우선 망설임(또는 우유부단함)은 프로젝트의 지연과 방향성 혼란을 야기해 경제성을 해친다는 점에서 명확한 문제이다.

'재발견'은 구체적인 설명이 필요하다. 끝을 모르는 발견이란, 바꿔 말해 요구 조건을 사전에 철저히 체크하지 못해, 작업 방향에 대한 잘못된 가정으로 인해, 그리고 신규 시스템 기능의 동작 방식을 제대로 예측하지 못해 발생하는 문제이다. 범위 추가의 근본적인 원인이라고도 할 수 있다. 실제 현업에서 불충분한 사전 기획으로 인해 대규모 프로젝트에 50% 이상의 비용 추가가 발생하는 사고가 드물지 않게 발생한다.

해법 : 사전 기획 기간을 보다 충분히 갖고 끝난 후에는 기능, 데이터를 함부로 추가하지 못하도록 철저하게 규정을 적용하자. 프로젝트 팀은 소규모로 빠듯하게 운영될수록 좋고, 컨설팅 기관의 참여도 한 곳으로 제한하는 것을 권장한다(사공이 많으면 배가 산으로 간다).

업무는 팀원 간의 신뢰를 쌓아가는 과정이다. 비판만 하는 구성원은 따끔히 정리하는 것이 좋다. 임원과 회계 담당자는 프로젝트에서 최대한 멀리 떼어놓는 것이 유리하며, 성대한 리뷰 미팅 역시 최소화할 필요가 있다. 팀원이 모호하고 임의적인 지표나 프로젝트 대시보드가 아닌 명확한 비즈니스 가치에 집중하도록 하는 것 역시 프로젝트 리더로서 노력해야 할 부분이다.

애자일이 중요한 이유
요즘 필자는 “실수와 실패의 경계선에서 배우다(Being Wrong-Adventures in the Margin of Error)”라는 책을 읽고 있다. 이 책을 읽기 전에는 “왜 전문가는 계속 우리를 실망시키는가(Wrong! Why Experts Keep Failing Us)”라는 책을 읽었다. 어쩌면 조금 질린 것일 수도 있지만, 그래도 필자는 여전히 비용 초과가 잘못된 예상, 파편화된 정보, 불완전한 요구사항과 신뢰의 부족 때문에 발생한다고 생각한다.

재미있는 것은, 양측이 모두 정확한 기대치를 세우고 실제 요구되는 사항에 대한 탄탄한 이해를 기초로 신뢰 관계를 쌓아나갈 수 있는 팔로우-온 프로젝트에서는 비용 초과가 훨씬 적게 발생한다는 것이다. 따라서 초기 프로젝트에 있어서는 클라이언트도, 컨설턴트도 프로젝트가 어느 정도 불확실성을 갖고 있음을 인정해야 한다.

왜냐하면 새로운 프로젝트에 임함에 있어 그 어느 쪽도 모든 것을 확신을 가지고 알지는 못하며, 시간과 돈을 들여 그에 대한 충분한 정보를 얻으려는 마음도 그다지 없기 때문이다. 프로젝트가 실제로 어떤 형태로 전개될 지 모른 채 서둘러 예산을 책정 받는 것이 현실에 더 가깝다. 그리고 실제 중반부가 지나서야 예상과 너무나 다른 전개에 당황하는 경우가 많다.

그렇다면 하이브리드 애자일 테크닉이 문제를 해결해 줄까? 그 생각은 접는 게 좋다. 그다지 도움이 되지 않기 때문이다. 진짜 ‘애자일’한 접근은 우리가 프로젝트에 대해 모르는 것이 많음을 인정하고, 프로젝트 결과의 범주를 유연하게 설정해 주어진 예산과 스케줄에 최대한 맞추는 것이다. 프로젝트를 진행 하면서 예상치 못했던 변수가 발견됨에 따라 우선순위를 바꾸기도 하고, 고정된 (아마도 현실을 고려함 없이 설정된) 기준에 맞추기보다 비즈니스 가치를 극대화하는 데 더 초점을 맞춰야 한다.

제대로만 활용한다면, 프로젝트에 대한 애자일한 접근이야 말로 ‘제 시간에, 예산에 맞춰’를 구호처럼 외치는 재무팀을 만족시키면서도 프로젝트 완성을 통해 사용자에게 가장 중요한 부분을 전달할 수 있도록 해 줄 것이다.

* David Taber는 'Salesforce.com Secrets of Success'의 저자이자 SalesLogistix의 CEO이다. ciokr@idg.co.kr 



2017.02.08

'밑 빠진 독에 물 붓기' 클라우드 사업이 예산을 초과하는 4가지 이유

David Taber | CIO
최근 클라우드 통합 기업을 상대로 비공식적 설문조사를 한 결과 매우 의외의 사실을 하나 발견했다. 고만 고만하고 정형화 된 퀵 스타트 프로젝트야 그렇다 해도, 새로운 고객을 상대로 한 클라우드 컨설팅의 70%에서 수주 변경이나 비용 초과가 나타난 것으로 조사됐기 때문이다. 특히 프로젝트 규모가 클 수록 비용이 초과될 가능성도 커졌다.



이에 대해 컨설턴트 탓을 할 수도 있고, 애초에 계산을 잘못했다거나 고객이 이상하다고 탓 할 수도 있겠지만, 누군가의 탓을 한다고 문제가 사라지지는 않는다. 중요한 것은 고객과 업체 모두에게 고통을 안겨주는 상당히 심각한 문제가 존재한다는 것이다.

만약 클라우드 비용이 예상을 넘어섰다면 십중팔구 잘못된 기대치 설정이 이유일 것이다. 특히 고객은 자신의 요구사항이 실제보다 훨씬 적은 비용으로 실제보다 훨씬 쉽게 충족할 수 있다고 믿는 경향이 있다. 하지만 설령 이것이 사실이라고 해도 이 부분에 대해 우리가 어떻게 해 볼 방법은 없다. 그러니 이것 외에 비용 초과를 초래하는 원인이 무엇인지 살펴보고 대처방법을 찾는 것이 현명하다.

비용 초과를 부채질하는 4가지 요소
클라우드 프로젝트 대부분은 여러 가지 파트로 정확하게 나뉘어 운용되므로 예상과 실제 비용 사이에 차이가 크게 나는 일은 별로 없다. 하지만 이건 어디까지나 이상적인 이야기이다. 주기적으로 비용 초과가 발생하는 프로젝트 분야는 다음과 같다.

1. 데이터 통합과 이전
데이터 통합과 이전은 마치 머리 둘 달린 괴물과 같다. 늪 한 가운데 빠질 때까지 무엇이 문제인지 모르고 지나치는 경우가 대부분이라 심각한 문제를 야기한다.

비용 초과는 데이터의 양과 데이터 소스에 비례한다. 표면적으로는 말끔해 보여도 포맷 문제, 부적합한 값, 의미론적 과적과 객체-모델(object-model)의 모호함 등 데이터 통합과 이전을 복잡하게 만드는 요소가 수두룩하다. 특히 지속적 통합이 요구되는 상황에서는 초반에 사용한 포인트-투-포인트 어댑터를 결국 미들웨어 시스템으로 대체해야 한다는 것을 알아채지 못할 수 있다.

해법 : 이전 및 통합할 데이터의 양, 데이터 소스에 대한 비용편익 분석을 실시하고 현실적인 비용을 설정해야 한다. 프로젝트를 시작할 때 이전/통합/확인과 관련된 작업을 시작해 프로젝트가 한참 진행된 후에 놀라는 일이 없도록 하자. 데이터 이전과 통합이 프로젝트에 있어 가장 큰 부분을 차지할 수 있다는 점을 미리 염두에 두어야 한다.

2. 커스텀 코드
많은 기업이 프로젝트를 규정함에 있어 ‘코드 없이, 고정 관념의 틀을 깨는’ 프로젝트가 되길 희망하지만 하루도 채 지나지 않아 이를 충족하는 것이 불가능하다는 것을 깨닫는다. 안타깝지만 컨설턴트 중에는 코드를 사랑하는 이들이 많기 때문에, 이들은 적극적으로 고객을 커스텀 코드의 세계로 인도하려 한다.

게다가 SFDC(Salesforce.com) 플랫폼의 훌륭한 코딩 환경은 사용자 인터페이스나 비즈니스 로직 측면에서 봐도 코딩을 더 매력적인 옵션으로 보이게 한다. 그러나 문제는 개발자 생산성과 코드 유지 비용이다. 커스텀 코딩은 표준 설정 방식보다 비용이 훨씬 많이 들어간다.

해법 : 가능한 한 표준적인 시스템 기능과 기성 플러그인 제품을 이용하도록 노력한다. 요구 사항을 최대한 가용 자원에 맞도록 조정하고, 초기 배포 단계에서 코딩을 최대한 배제해 코더가 안정적인 플랫폼에서 작업할 수 있도록 해야 한다. 아이템 개발의 경우 보안 모델, 명령 설정, 배포/파트너 네트워크 등 조합적 확산을 유발할 수 있는 스트림 라인 프로세스와 비즈니스 룰에 위임해야 한다.


3. 보기 좋은 떡이 먹기도 좋다?
오리지널 SFDC 리포팅 엔진은 파워와 사용 용이성 간의 균형이 훌륭하지만, 최종 결과물은 거의 스프레드시트 수준에 그친다. 따라서 한 눈에 들어오는 보기 좋은 리포트를 원한다면 오리지널 SFDC 엔진만으로는 금세 한계에 부딪힐 것이다.

SFDC의 웨이브 리포팅 시스템은 더 강력하면서도 보기 좋은 리포트를 제공하지만, 이를 제대로 사용하려면 쿼리 코드를 써야 한다. 한걸음 더 나아가 깔끔한 포맷, 멀티 페이지 레이아웃, 자동 오피스 도큐먼트 생성 같은 작업까지 하려면 서드 파티 애드-온이 필요하다. 그러나 모든 프로젝트가 그렇듯 외양에 신경을 쓰면 쓸 수록 비용은 더 많이 들어간다. 최초 설치 비용뿐 아니라 사용자의 요구에 맞춰 이용하는 과정에서도 마찬가지다.

해법 : 포맷과 개별 사용자의 수정 내용에 이르기까지 리포트의 모든 변수를 하나하나 빼놓지 말고 철저히 이해하고 구체화하라. 처음엔 10개를 생각했는데 알고 보니 100개 이상의 리포트가 필요하다면 그 사실을 빨리 알게 될수록 더 좋다. 액세스나 크리스탈 등 시스템 에뮬레이션(emulation)이 필요한 리포트가 있다면 업체에게 포맷과 예외 조건에 대한 주석을 달아 입력 데이터 샘플과 리포트의 결과물을 제시해야 한다.

4. 프로젝트 관리와 감사
이는 철저히 프로젝트 리더, 임원에 의해 주도되는 과정이어서 해당 관리자의 행위는 곧바로 비용 초과로 이어질 수 있다. 프로젝트에서 거리와 지연이 효율성과 경제성을 해치는 가장 큰 위협이라는 것은 익히 알고 있을 것이다. 필자는 여기에 ‘망설임’과 ‘(끝을 모르는) 재발견’을 추가하겠다. 우선 망설임(또는 우유부단함)은 프로젝트의 지연과 방향성 혼란을 야기해 경제성을 해친다는 점에서 명확한 문제이다.

'재발견'은 구체적인 설명이 필요하다. 끝을 모르는 발견이란, 바꿔 말해 요구 조건을 사전에 철저히 체크하지 못해, 작업 방향에 대한 잘못된 가정으로 인해, 그리고 신규 시스템 기능의 동작 방식을 제대로 예측하지 못해 발생하는 문제이다. 범위 추가의 근본적인 원인이라고도 할 수 있다. 실제 현업에서 불충분한 사전 기획으로 인해 대규모 프로젝트에 50% 이상의 비용 추가가 발생하는 사고가 드물지 않게 발생한다.

해법 : 사전 기획 기간을 보다 충분히 갖고 끝난 후에는 기능, 데이터를 함부로 추가하지 못하도록 철저하게 규정을 적용하자. 프로젝트 팀은 소규모로 빠듯하게 운영될수록 좋고, 컨설팅 기관의 참여도 한 곳으로 제한하는 것을 권장한다(사공이 많으면 배가 산으로 간다).

업무는 팀원 간의 신뢰를 쌓아가는 과정이다. 비판만 하는 구성원은 따끔히 정리하는 것이 좋다. 임원과 회계 담당자는 프로젝트에서 최대한 멀리 떼어놓는 것이 유리하며, 성대한 리뷰 미팅 역시 최소화할 필요가 있다. 팀원이 모호하고 임의적인 지표나 프로젝트 대시보드가 아닌 명확한 비즈니스 가치에 집중하도록 하는 것 역시 프로젝트 리더로서 노력해야 할 부분이다.

애자일이 중요한 이유
요즘 필자는 “실수와 실패의 경계선에서 배우다(Being Wrong-Adventures in the Margin of Error)”라는 책을 읽고 있다. 이 책을 읽기 전에는 “왜 전문가는 계속 우리를 실망시키는가(Wrong! Why Experts Keep Failing Us)”라는 책을 읽었다. 어쩌면 조금 질린 것일 수도 있지만, 그래도 필자는 여전히 비용 초과가 잘못된 예상, 파편화된 정보, 불완전한 요구사항과 신뢰의 부족 때문에 발생한다고 생각한다.

재미있는 것은, 양측이 모두 정확한 기대치를 세우고 실제 요구되는 사항에 대한 탄탄한 이해를 기초로 신뢰 관계를 쌓아나갈 수 있는 팔로우-온 프로젝트에서는 비용 초과가 훨씬 적게 발생한다는 것이다. 따라서 초기 프로젝트에 있어서는 클라이언트도, 컨설턴트도 프로젝트가 어느 정도 불확실성을 갖고 있음을 인정해야 한다.

왜냐하면 새로운 프로젝트에 임함에 있어 그 어느 쪽도 모든 것을 확신을 가지고 알지는 못하며, 시간과 돈을 들여 그에 대한 충분한 정보를 얻으려는 마음도 그다지 없기 때문이다. 프로젝트가 실제로 어떤 형태로 전개될 지 모른 채 서둘러 예산을 책정 받는 것이 현실에 더 가깝다. 그리고 실제 중반부가 지나서야 예상과 너무나 다른 전개에 당황하는 경우가 많다.

그렇다면 하이브리드 애자일 테크닉이 문제를 해결해 줄까? 그 생각은 접는 게 좋다. 그다지 도움이 되지 않기 때문이다. 진짜 ‘애자일’한 접근은 우리가 프로젝트에 대해 모르는 것이 많음을 인정하고, 프로젝트 결과의 범주를 유연하게 설정해 주어진 예산과 스케줄에 최대한 맞추는 것이다. 프로젝트를 진행 하면서 예상치 못했던 변수가 발견됨에 따라 우선순위를 바꾸기도 하고, 고정된 (아마도 현실을 고려함 없이 설정된) 기준에 맞추기보다 비즈니스 가치를 극대화하는 데 더 초점을 맞춰야 한다.

제대로만 활용한다면, 프로젝트에 대한 애자일한 접근이야 말로 ‘제 시간에, 예산에 맞춰’를 구호처럼 외치는 재무팀을 만족시키면서도 프로젝트 완성을 통해 사용자에게 가장 중요한 부분을 전달할 수 있도록 해 줄 것이다.

* David Taber는 'Salesforce.com Secrets of Success'의 저자이자 SalesLogistix의 CEO이다. ciokr@idg.co.kr 

X