프로젝트에서 제품으로

- 사업부서와 기술부서가 일하고 의사소통하는 방식에 근본적인 문제가 있었다. 좋은 의도를 가진 리더조차 그들의 회사를 불 보듯 뻔한 쇠퇴의 길로 이끌 수 있다.
우리가 소프트웨어를 다룬 지 50년이 지났는데도 왜 이런 일이 일 어날까? 대량 생산 시대의 주요 생산 기술을 가져온 애자일과 데브옵 스 운동은 소프트웨어 개발 분야에 기술적 관리 기법을 도입하는 데 엄청난 진전을 가져왔다. 예를 들면 지속적 배포 파이프라인은 자동 화된 생산 라인의 모범 사례를 빌려온 것이다. 애자일 테크닉 또한 린 제조의 여러 훌륭한 기술적 관리 기법에서 착안한 것들을 소프트웨어 전달에 도입했다.
문제는 소프트웨어 엔지니어 출신이 운영하는 기술에 전문화된 소수의 거대 기업을 제외하고는 이와 같은 기법들이 비즈니스 관리, 예산 책정 및 계획과는 완전히 단절돼 있다는 것이다. 기술 부채나 스토리 포인트와 같이 기술자에게 익숙한 소프트웨어 전달 개념은 IT 이니셔티브를 프로젝트로 관리하고 일정과 지출 비용 준수 여부로 프 로젝트를 평가하는 대부분 비즈니스 리더에게는 별 의미가 없다. 프 로젝트 지향적 관리 프레임워크는 다리를 짓는다거나 데이터 센터를 만드는 데에는 적합하지만, 소프트웨어 시대의 전환점에서 살아남기 에는 매우 부적합하다.
- 넷플릭스의 공동 설립자이자 CEO인 리드 헤이스팅스Reed Hastings는 컴퓨터 과학자 앤드 류 테넨바움Andrew s. Tanenbaum 의 “미국 전역에 걸쳐 비디오테이프를 배달하는 화물차의 대역폭을 계산하라” 라는 유명한 수학 문제에서 영감을 얻어 DVD의 선택 및 물류 분산에 소프트웨어를 적용할 수 있을 것으로 판단했다.15 벤처 투자가 마크 앤드리슨Marc Andreessen 은 「Why Software is Eating the World?」라는 제목의 칼럼에서 페덱스FedEx를 '소프트웨어 네트워크에 트럭, 비행기, 유통 허브를 붙여놓은 것'이라 고 묘사했다. 넷플릭스와 페덱스는 소프트웨어가 유통업계에 폭발적인 이익을 가져다줄 것임을 깨달은 것이다.
- 이 책에서 소개하려는 모델은 제프리 무어의 저서 『Zone to Win』에서 소개된 내용이다. 무어의 세 가지 파괴 유형에는 인프라 모델, 운영 모델, 비즈니스 모델이 있다. 소프트웨어 시대에 대부분 기업이 파괴를 해결하려면 소프트웨어 전 달을 마스터해야만 한다. 파괴의 유형을 파악해야 각 비즈니스에 맞는 효과적인 공격 및 방어 태세를 갖춰 그에 따른 IT 투자와 가치 흐름을 만들어낼 수 있다.
인프라 모델 파괴는 가장 다루기 쉬운 유형으로 비즈니스가 제공 하는 제품과 서비스에 고객이 접근하는 방식이 변화하는 것을 말한다. 판매 방식은 그대로 두고 소셜 미디어를 통해 제품 홍보를 진행하기로 하는 상황을 예로 들 수 있다. 우리가 관찰할 수 있는 인프라 모델 파괴는 경쟁 업체 대비 차별성 있는 디지털 마케팅 및 소통 방법에서 발생한다. 많은 디지털 서비스가 신뢰 경제를 뒷받침하는 소셜 네 트워크와 조합되고 있다.
운영 모델 파괴는 소프트웨어를 사용해 비즈니스와 고객 간 관계 가 변화하는 것과 관련이 있다. 예를 들면 항공사는 이제 최고의 모바일 경험을 제공해야 하며, 그러지 못한다면 비행 예약 승객을 잃는 위험을 감수해야만 한다. 상담사와 콜센터의 역할이 줄어들면서 운영 모델은 근본적으로 변화한다. 스타트업과 경쟁하려면 최고의 디지털 경험이 필요하다. 예를 들어 더 나은 개인별 금융관리 기능으로 고객 을 만족시키는 새로운 스타트업의 서비스는 시중 은행을 파괴할 것이 라 예상할 수 있다.  비즈니스 모델 파괴는 소프트웨어 및 기술을 비즈니스에 좀 더 근 본적인 방식으로 적용해 발생하는 변화에서 기인한다. 고객이 상점에 방문하는 것과 같이 주로 수동적인 과정을 없애 주는 소프트웨어와 물류 혁신이 이에 해당할 것이다. 무어는 이에 대해 기성 기업은 스스로 파괴를 주도할 능력이 없기 때문에 다른 시장 카테고리에서 부상 하는 다음 창조적 파괴의 흐름에 올라탈 수 있도록 혁신 엔진을 구축 해 둬야 한다고 말한다. 비즈니스가 어떤 상황에 있든지 간에 소프트웨어 시대에 성공하려면 어떤 유형의 파괴가 비즈니스를 위험에 빠뜨렸는지 정확히 정의 해야 한다. 어떤 유형이든 다음 단계는 소프트웨어 전달에 상당한 투 자를 요구할 것이다. 이 이니셔티브를 성공시키고 시장에서 승리하기 위한 힘은 소프트웨어 가치 흐름을 정의하고 연결하며 관리하는 능력에 달려 있다.
- 전환점이 얼마나 오래 지속될지 알 수 없지만, 이 시대가 페레스의 50년 주기 모델을 따르고 있으며 1970년대부터 도입기의 신호가 나타나고 있었음을 알아차렸다면 우리는 매년 활용기에 가까워지고 있다고 추정할 수 있다. 활용기에 도달했을 때 새로운 생산 수단을 채 택하지 못한 기업은 연관성Relevance 및 시장 점유율이 하락할 것이다. 그렇게 앞으로 10년 동안 상당수 기업이 시장에서 자리를 잃어 갈 것 이다. 우리는 오랜 기간 많은 기업이 IT, 애자일, 데브옵스 전환을 시 도했다가 실패하는 사례를 지켜봤다. 최신 기술 시대에서 살아남기 위한 싸움을 해 볼 기회를 얻으려는 대부분 기업에는 이번이 마지막 기회가 될 것이다.
- 이제 우리가 찾아낸 단절의 원인을 설명하고자 한다. IT를 코스트 센터로 취급하면 변혁 역시 같은 사고방식을 택하게 된다. 프로젝트 막바지에는 성공적인 비용 절감에 집중하게 되는 것이다. 하지만 경 영진이 디지털 변혁을 승인하면서 얻고자 했던 경영 사례는 빠른 시 장 접근, 경쟁력 있는 제품, 효과적인 전달 등 애자일과 데브옵스의 장점에 있을 것이다. 그러나 이러한 성과는 비용만을 우선시하는 조 직에서 이뤄낸 것이 아니다. 변혁에 있어 비용 절감이 중요한 부분 중 하나일 수는 있지만 그것이 변혁의 주된 문제는 아니다. 문제는 비용 중심적 프레임워크가 속도, 생산성, 효율성을 증가시키지 못해 적은 비용으로 더 적은 비즈니스 결과를 얻게 된다는 점이다.
- 프로젝트 지향 관리는 프로젝트를 진행하는 동안 발생할 수 있는 모든 리스크를 식별하도록 설계돼 있다. 이는 모든 발생 가능한 리스크를 미리 알고 있어야 한다는 의미다. 다른 분야에서는 가능할지도 모르지만 소프트웨어 전달이라는 불확실하고 변화무쌍한 세상에서는 불가능하다.
커네빈 프레임워크cynefin Framework는 의사 결정 상황을 명확함', '어려움’, ‘복합적', '혼돈'의 네 가지로 분류하는 방법을 제공한다.28 기술 스택과 시장이 변화하는 속도로 인해 소프트웨어 이니셔티브는 '복합적’ 영역이나 '혼돈' 영역에 빠지는 경향이 있다. 명확함'과 '어 려움’ 영역의 문제 해결에 최적화된 프로젝트 지향 관리에서는 결국 프로젝트 기간에 발생할 수 있는 모든 우발적인 상황을 프로젝트에 끼워 넣게 된다. 이로 인해 지나치게 보수적인 기간과 불어난 예산이 책정된다. 그럼에도 불구하고 이렇게 사전 계획된 프로젝트가 일반적 인 가설 검정 및 학습 방식보다 제품 · 시장 리스크를 피하는 데 효과 적인 것도 아니다.
이에 반해 제품 지향적 관점에서는 최소 기능 제품MVP과 같은 린 스타트업Lean Startup의 접근 방식을 중요시한다. 리스크를 줄이는 것 외에도 점진적인 제품 지향적 접근 방식은 비즈니스가 정기적인 체크포인트에서 방향을 재설정할 수 있도록 해 선택 가치를 만들어낸다. 더 잦은 리뷰와 체크포인트는 비싼 관리 비용을 요구하기 때문에 추가 비용이 발생한다. 하지만 소프트웨어의 복잡성과 시장이 바뀌는 속도 를 고려하면 제품 생애 주기 전반에 걸쳐 추가 비용이 고루 퍼져 있는 것이 낫다.

- 불타는 시추선에 대한 스테판 엘롭의 메모는 이미 결정된 사안에 대한 묘비명 같은 것일지도 모른다. 하지만 그 글을 처음 읽었을 때 노키아의 엔지니어가 해준 이야기가 다시 떠올랐다. 심비 안 시리즈 60에는 엄청난 양의 기술 부채가 축적돼 있었다. 심비안 시리즈 40은 훨씬 간단한 구조였기 때문에 경영진은 이와 같은 기술 부 채를 다루는 방법에 익숙지 않았다. 부채 수준은 소스 코드나 아키텍 처를 넘어 전체 가치 흐름과 운영 그리고 소프트웨어 제공 계획까지 스며들어 있었다. 40시리즈를 만들 때는 기술자가 조직을 운영하고 있었기 때문에 이렇게 심각한 수준의 기술 부채가 OS에 존재하지 않 았다. 기술 부채가 무엇인지 알고 있는 마이크로소프트에서 온 스테판 엘롭은 기술과 비즈니스 모두에서 문제점을 찾아냈다. 엘롭이 문제를 너무 늦게 발견한 것인지, 모바일 플랫폼의 근본적 결함에 베팅한 것인지, 노키아 조직이 그 시점에 문제를 바로잡기에 는 이미 너무 많이 무너진 상태였는지는 알 수 없다. 2002년 애플이 Mac OS 9에 리팩터링 불가능한 기술 부채를 발견하고 Mac OS X가 되는 다음 세대 운영 체제를 처음부터 다시 만들어야 한다는 것을 깨 달았던 것처럼 노키아도 몇 년 앞서 기술 부채를 발견했다면 어땠을 까? | 노키아의 직원을 인터뷰했던 내용에 비춰 보면 노키아가 정전식 터치 스크린 기술을 애플보다 먼저 도입했다 하더라도 운명이 크게 달라지지 않았을 것이라는 생각이 든다. 요구를 더는 들어줄 수 없을 정도로 기술 부채가 쌓이기 전까지 기술 부채에 우선순위를 할당하는 것은 비즈니스의 안중에 없었다. 대량 생산되는 버튼의 세상에서 소 프트웨어로 움직이는 스크린으로 전환하기 위해 회사를 포지셔닝하는 것은 불가능했다. 여기서 플로우 프레임워크의 가설은 기능 플로우가 부채와 기존 아키텍처에 의해 심한 방해를 받아 플랫폼이 막다른 골목을 마주하게 됐다는 것이다. 활주로와 자본이 고갈되기 전에 새로운 플랫폼에 대한 투자가 이뤄졌어야 했다.