[IT/리뷰] 프로젝트에서 제품으로: 플로우 프레임워크, 디지털 변혁의 시대에서 살아남는 법

프로젝트에서 제품으로 : 네이버 도서 (naver.com)

프로젝트에서 제품으로 : 네이버 도서

토이 프로젝트 또는 회사 프로젝트에서 제품이 되기 위해 필요한 것들을 다루는 책인 줄 알고 읽었다. 하지만 책의 내용은 기존 회사들의 프로세스를 대신하는 프레임워크를 제시한다. 기존 회사들의 프로세스를 거친 것은 그저 프로젝트에 불과하지만 이 책에서 제시하는 프레임워크를 따라가면 제품이라 할 수 있다는 것이다. 즉, 비즈니스적인 가치가 생기거나 추적할 수 있게 됨을 말한다.

 

책의 내용은 너무 어려웠다. 용어들도 어려웠고 단순히 컴퓨터 앞 개발을 벗어나서 비즈니스적인 관점에서 회사 전 부서를 내려다보는 시야를 받아들이기 어려웠다. 나 같은 일반 개발자보다는 스타트업부터 대기업까지 회사를 운영하는 업무를 하는 사람이 봤을 때 배울 점이 더 많은 책이라 생각된다. 나에게는 너무 어려운 내용이었다.

책은 3 부로 구성되어있다. 1 부 내용부터 이해하기가 너무 어려워서 책에 흥미를 잃고 더 이상 읽기 어려웠다. 하지만 2 부에서는 어느 정도 내용을 알아듣기 시작했다. 3 부에서는 많은 예시와 함께 받아들이기 쉬웠다. 이 책을 나와 같은 사람이 읽으려면 공부하려는 관점에서 벗어나 가볍게 '이런 것들이 있구나' 정도로 넘어가면 좋을 것 같다.

 

아무튼 책에서 다루는 내용에 의하면, IT 소프트웨어가 제품으로 가치가 있으려면 비즈니스적인 관점에서 모든 프로세스와 툴을 관찰해야 한다. 설계와 개발부터 영업과 유지보수까지 모든 부서가 제품과 비즈니스의 목표를 공유하고 있어야 하며, 툴을 통해 모든 흐름이 관찰되어야 한다. 전체 제품의 프로세스에서 병목 지점을 확인할 수 있어야 하며, 확인하기 쉽도록 구성되어야 한다. 각 기업의 상황에 따라 세부적인 것들은 달라질 수 있으나 단순히 프로젝트가 아닌 제품이 되기 위해서는 비즈니스적인 관점이 제품 전체를 관통해야 한다.

 

자세한 건 아래에 정리를 차곡차곡 해보도록 하자. 어려워서 나중에 보더라도 이해가 안 될 가능성이 높지만 다시 볼 필요가 생길만한 책인 것 같다.

---

 

오늘날 비즈니스 환경에서 기존 방식의 계획 수립과 시행은 디지털 파괴의 위협에 직면한 기업들에게 더는 도움이 되지 않는다. 수십 년간 기술 관리 방법을 모색했음에도 참담한 결과가 있었다. 프로젝트 관리, 원가 중심적 관리, 전통적인 아웃소싱 전략, 소프트웨어 아키텍처 의존적 개발자 생산성 관리 등 잘 통하던 전략이 효과를 내지 못하게 된 사례를 이용해 설명한다. 그리고 이들을 대체할 '플로우 프레임워크'를 제시한다.

 

대부분의 소프트웨어 관련 책은 '프로젝트'에 초점을 맞춘다. 프로젝트 진행에 필요한 프로세스와 툴을 소개하는 것에 집중한다. 하지만 이 책에서는 사업의 본질인 '제품'을 계획하고 개발하고 소비자에게 전달하는 모든 과정에 초점을 맞춘다.

따라서, 이 책은 이미 대규모 소프트웨어 전달 방법에 숙달한 조직에 필요한 책이 아니다. 소프트웨어 시대로의 전환을 촉진하는 새로운 관리 프레임워크를 제공하고자 하는 것이다.

 

소프트웨어 시대 이전 설립된 수많은 기업은 소프트웨어가 시장에서 성공을 판가름하게 되면서 기술 교체에 따르는 비용이 증가하는 것을 알아차리기 시작했다. 거대 기술 기업이 아닌 경우 디지털 변혁은 실패를 거듭한다.

기업 변혁의 필요성을 깨닫는 것이 문제가 아니라, 과거에 개발된 관리 프레임워크와 인프라 모델을 아직 비즈니스 관리에 사용하는 것이 문제다. 경영 회계 조직 계층 구조, 린 생산은 이전 변혁 과정에서 성공을 위한 필수 요소였으나, 소프트웨어 시대에 비즈니스를 성공적으로 경영하고 보호하려면 관리 프레임워크만으로는 부족하다.

 

소프트웨어를 다룬 지 50년이 지났는데도 왜 이런 일이 일어날까? 대량 생산 시대의 주요 생산기술을 가져온 애자일과 데브옵스 운동은 소프트웨어 개발 분야에 기술적 관리 기법을 도입하는 데 엄청난 진전을 가져왔다. 예를 들어, 지속적 배포 파이프라인과 애자일 테크닉은 각각 자동화된 생산 라인의 모범 사례와 린 제조의 훌륭한 기술적 관리 기법을 소프트웨어 분야로 적용한 것이다.

문제는 소수의 소프트웨어 거대 기업을 제외하고는 이와 같은 기법들이 비즈니스 관리, 예산 책정 및 계획과는 완전히 단절돼 있다는 것이다. 기술 부채나 스토리 포인트와 같이 기술자에게 익숙한 소프트웨어 전달 개념은 IT 이니셔티브(Initiative)를 프로젝트로 관리하고 일정과 지출 비용 준수 여부로 프로젝트를 평가하는 비즈니스 리더에게는 의미가 없다. 프로젝트 지향적 관리 프레임워크는 소프트웨어 시대의 전환점에서 살아남기에는 매우 부적합하다.

 

플로우 프레임워크는 '가치 흐름'에 알맞게 소프트웨어 전달을 측정하고 IT 투자를 조정하는 새로운 방법이다. '가치 흐름'이란 소프트웨어 제품이나 SaaS를 통해 비즈니스 가치를 시장으로 전달하기 위해 수행하는 모든 활동을 말한다. 플로우 프레임워크는 프로젝트 지향 관리 방식(원가 중심으로 예산을 측정하던 방식과 조직 차트로 소프트웨어 이니셔티브를 측정하던 방식)을 대체한다. 지난 방식들은 기술에 대한 투자가 비즈니스 결과로 연결되도록 하는 '플로우 지표'로 대체된다. 플로우 프레임워크는 데브옵스의 세 가지 방법(흐름, 피드백, 지속적 학습)을 기술 조직을 넘어 비즈니스 전체에 적용할 수 있도록 한다.

 

조직의 제품 전달에 맞춰 완전히 연결된 가치 흐름 네트워크를 구축해 사일로에 갇혀있던 이전의 문화를 넘어서서, 플로우에 집중해 측정 가능한 비즈니스 결과에 조직 모든 소프트웨어 전달 활동을 연결해야 한다. 스타트업과 디지털 네이티브 기업의 리더는 개발자 출신으로 개발자의 언어로 의사소통하며 소프트웨어 전략을 효과적으로 전달했다.

개발자 출신의 리더가 있지 않는 기존의 기업이더라도 IT라는 블랙박스를 가치 흐름이라는 투명한 네트워크로 바꾸고 관리할 수 있다. 이를 위해 변혁 활동보다는 측정 가능한 비즈니스 결과에 집중해야 한다. 디지털 시대에 입지를 확보하기 위해 기업을 '프로젝트에서 제품으로' 전환하기 위한 새로운 프레임워크가 필요하다.

---

오늘날 IT 조직을 생각해보면, 비즈니스는 조직 구조 및 코스트 센터의 관점으로 IT 분야의 성과를 측정한다. 기업 IT 조직 대부분이 가치 흐름이나 비즈니스 가치 전달 방식을 측정하는 개념을 갖추지 못하고 있다. 심각한 것은 많은 IT 조직이 자신들의 생산 단위가 무엇인지 합의해본 적 없다는 사실이다. 데브옵스의 엔드 투 엔드(end-to-end) 이점을 전달하려는 노력은 여기서부터 실패하게 된다. 그저 production에 배포된 커밋 횟수 정도만 변혁이 돼 버린다. 이러한 결과는 비즈니스적으로 의미도 거의 없다.

경영진이 철강 시대의 테일러리즘 관점에 머물러 있고 기술 혁명의 인프라와 관리 방법을 따라가지 못하는 것이다. IT 조직이 비즈니스에서 분리돼 사일로에 갇혀 기능적으로 특수화돼 있고 단절돼 있는 것이다. 경영진은 디지털 파괴를 전문가가 해결해주길 바라면서 디지털 변혁은 쉽게 일어나지 않는다. 여전히 기술 언어와 비즈니스 언어의 격차는 크다.

 

디지털 파괴(Digital Disruption)란 새로운 생산 방식에 적응하지 못한 기업에게 당연한 결과다. 새로운 생산 방식을 마스터한 기업은 느리게 움직이는 시장일지라도 생산 방식을 마스터하는데 오래 걸리는 기업을 대체할 것이다. 디지털 파괴를 막기 위한 비즈니스 전략을 원한다면 <Zone to Win>(제프리 무어) 책을 읽어보는 것을 추천하며, 이 책에서도 <Zone to Win>에서 소개한 내용들을 이용해 설명한다.

기업들도 디지털 파괴를 막기 위해 디지털 변혁을 추진하고 있지만 실패하고 있다. 실패의 주요 원인으로는 '기술 인재와 전문성 부족', '일반적 문화 이슈', '디지털 변혁을 투자가 아닌 코스트 센터로 취급' 등이 주를 이룬다. 하지만, 이들 중 어느 것도 근본 원인이라고 할 수 없다. 근본적인 원인은 비즈니스 리더와 기술자 사이의 단절 증상이다.

즉, 최고의 전략과 의도가 있어도 소프트웨어 전달 능력과 역량이 디지털 변혁의 병목 지점이 되고 있는 것이다.

 

<Zone to Win>에서 무어가 말하는 세가지 파괴 유형에는 인프라 모델, 운영 모델, 비즈니스 모델이 있다. 소프트웨어 시대에 대부분 기업이 파괴를 해결하려면 소프트웨어 전달을 마스터해야 한다. 각 파괴 유형을 파악해 비즈니스에 맞는 공격과 방어 태세를 갖춰 적절한 IT 투자와 가치 흐름을 만들어낼 수 있다.

인프라 모델 파괴는 비즈니스가 제공하는 제품과 서비스에 고객이 접근하는 방식이 변화하는 것을 말한다. 판매 방식은 그대로 두고 소셜 미디어를 통해 제품 홍보를 진행하기로 하는 상황을 예로 들 수 있다. 관찰 가능한 인프라 모델 파괴 역시 경쟁 업체 대비 차별성 있는 디지털 마케팅 및 소통 방법에서 발생한다.

운영 모델 파괴는 소프트웨어를 사용해 비즈니스와 고객 간 관계가 변화하는 것과 관련 있다. 예를 들어 항공사는 이제 최고의 모바일 경험을 제공하지 않는다면 예약 승객을 잃을 수도 있다. 마찬가지로 상담사와 콜센터의 역할이 줄어들면서 인프라 모델은 근본적인 변화가 이뤄진다.

비즈니스 모델 파괴는 소프트웨어 및 기술을 비즈니스에 좀 더 근본적인 방식으로 적용해 발생하는 변화에서 기인한다. 고객이 상점에 직접 방문하는 수동적 과정 대신 소프트웨어와 물류 혁신이 이를 대체하는 것과 마찬가지다.

비즈니스가 어떤 상황에 있든지 소프트웨어 시대에 성공하려면 어떤 유형의 파괴가 비즈니스를 위험에 빠뜨렸는지 정확히 정의해야 한다.

 

변혁에 실패하는 경우를 보면 비즈니스와 IT 간 단절이 심각하다. 기업 소프트웨어 아키텍처의 공통적으로 잘못된 접근법은 비즈니스 가치 흐름에 기반하지 않고 기술 전문가의 요구 사항에만 초점을 맞추고 있는 것이다. 반대 예시로, BMW 그룹의 라이프치히 공장은 건물 확장성에서 생산 라인 자체의 모듈성에 이르기까지 비즈니스의 변화하는 요구사항에 맞춰 설계해 놓고 있다.

 

저자의 세 가지 깨달음.

1. 소프트웨어 규모가 확장함에 따라 아키텍처와 가치 흐름 사이의 단절로 생산성은 감소하고 낭비는 증가한다.
2. 단절된 소프트웨어 가치 흐름은 소프트웨어 전달의 병목 지점이 된다. 가치 흐름의 단절 원인은 프로젝트 관리 모델의 잘못된 사용에 있다.
3. 소프트웨어 가치 흐름은 선형적인 제조 공정이 아니라 제품에 따라 조정돼야 하는 복잡한 협업 네트워크다.

첫 번째 깨달음. 소프트웨어 시스템의 규모가 커질수록 최조 사용자가 요청하는 수백 가지 기능 중 하나를 추가하는 데 드는 노력과 아키텍처 사이의 거리도 멀어진다. 사용해야 하는 협업 및 추적 시스템의 수 또한 늘어나 많은 낭비와 중복이 발생한다. 이 발견이 저자가 태스크톱(Tasktop)을 설립하도록 했다.

두 번째 깨달음. 쓰레싱(Thrashing) 문제는 개발자만의 문제가 아니다. 소프트웨어 전달에 관련된 모든 전문가(비즈니스 분석가, 디자이너, 테스터, 운영 담당자, 지원 담당자 등)에게 쓰레싱은 낭비의 주요 원인이었다. 소프트웨어 전달 전문가가 더 많이 참여할수록 더 많은 단절이 일어나 더 많은 시간을 쓰레싱, 중복 데이터 입력, 끝없는 상태 업데이트 및 보고에 사용한다. 더 많은 직원, 더 많은 툴, 더 많은 소프트웨어 규모와 복잡성은 문제를 더 악화시킨다.

세 번째 깨달음. 소프트웨어 가치 흐름은 자동차 생산 라인같은 선형 제조 공정 또는 파이프 라인이 아니다. IT 조직이 만든 내외부 제품과 비즈니스 목표를 연결하고 적절히 조정해야 하는 복잡한 협업 네트워크다.

 

노키아 지멘스 네트워크에서 개발한 노키아 테스트는 노키아를 확장형 애자일의 전형으로 굳어지게 만들었다. 노키아 테스트는 반복적 개발이 됐는지, 각 팀의 애자일 적용 상황이 어땠는지 확인하기 위해 스크럼 원칙을 따랐는지를 묻는다. 하지만 애자일 활동과 준수 여부를 평가할 때 실제 활동에서 나온 명확한 결과를 반영하지 않는다는 점이 문제였다.

개발자들은 애자일 기법에 호의적이었다. 그러나 노키아의 강력한 소프트웨어 보안 프로세스가 빌드 테스트 배포 과정을 더디게 만들었다. 노키아가 인수했던 심비안 OS 구조에도 확장성이 부족하다는 큰 문제가 있었다.

개발자들이 스크럼을 긍정적으로 생각하더라도 개발자들의 일상 업무는 전혀 다른 툴을 사용하는 경영진의 플래닝 과정과 분리돼 있는 것이 문제다. 활동을 측정하는 것이 아닌 성과 및 결과를 측정해 변혁의 지표로 삼았다면 달라졌을 것이다.

 

노키아의 엔드 투 엔드 가치 흐름에서 애자일 변혁은 부분적 최적화일 뿐이다. 모바일 환경에서의 OS를 전달하는 데 애자일은 병목 지점이 아니었던 것이다. 개발 부서가 아는 것과 사업 부서가 추정한 내용 사이 간극이 너무나 큰 게 문제였다. 그리고 애자일을 바라보는 편협하고 활동 중심적인 시각이 노키아의 실패의 근본 원인이다.

 

소프트웨어 가치 흐름의 '엔드 투 엔드' 개념은 가치 전달이 고객까지 향하는 모든 프로세스가 포함된다. 비즈니스 전략과 아이디어부터 고객에게 채택된 가치가 무엇인지 알아보기 위한 사용량 측정 수단에 이르기까지 다양한 요소가 포함된다. 프로세스 일부분에 해당하는 기능 설계나 배포 과정 등을 최적화하기에 앞서 엔드 투 엔드 프로세스를 이해하고 병목 지점을 찾아야 한다.

 

켄트 백(Kent Beck)은 <익스트림 프로그래밍>에서 엘리야후 골드랫(Eliyahu M. Goldratt)의 제약 이론을 애자일 소프트웨어 개발에 적용한다. 골드랫은 병목 지점이 아닌 곳에 투자하는 것이 얼마나 헛된 일이지 설명한다. 이는 노키아의 애자일 변혁이 실패한 원인과 동일하다.

노키아가 지속적 전달 등 데브옵스 기법을 도입했다면 추세를 전환할 수 있엇을지도 모른다. 이미 노키아에는 테스트 자동화와 같은 몇몇 기법은 도입돼 있었다. 그러나 일반적인 데브옵스의 전달 파이프라인만을 적용했다고 노키아가 몰락을 피할 수는 없었을 것이다. 조직 관리나 문화 측면에서 불협화음이 있었을 수도 있고, 아키텍처가 문제였을 수도 있다.

하지만, 노키아가 데브옵스의 세 가지 방법(플로우, 피드백, 지속적 학습)을 도입했다면 적어도 병목 지점이 어디인지 찾아내려는 방향으로는 흘러갔을 것이다. 개발에서 운영으로의 플로우와 피드백에 집중함으로써 노키아 경영진은 서비스 제공까지 걸리는 시간이 길어지고 있다는 것을 눈치챌 수 있었을 것이다. 그리고 지속적 학습이 개발 리더를 넘어선 수준에서 수행됐으면 경영진은 조직 구조나 소프트웨어 구조에 문제가 있는 것은 아닌지 올바른 질문을 던졌을 것이다.

 

라지뱅크는 노키아의 케이스와는 다르다. 라지뱅크에서 CFO 아래에서  IT 부서는  코스트 센터로서 운영되고 있었다. 즉, 디지털 변혁의 결과가 비용을 얼마나 절감했는지를 통해 비즈니스 성과를 평가하고 관리한다는 것이다. 이런 비용 중심적 경영 관리는 IT가 비즈니스 이해관계자와 긴밀한 협업 없이도 변혁을 실행할 수 있다는 것이었다. 이로 인해 IT 부서는 비용 절감을 목표를 목표로 가치가 아닌 기술에만 집중했다. 비즈니스 부서는 구상한 새로운 디지털 사용자 경험을 설계와 전달 파이프라인으로 디지털 비전을 현실화할 수 있던 IT 부서를 무시했다. 변혁 자체도 비용 절감으로 더 많은 가치 창출보다는 프로젝트 일정 준수를 목표로 했다.

IT를 코스트 센터로 취급하면 변혁 역시 같은 사고방식을 택하게 된다. 비용 절감만을 우선시하는 조직에서는 경영진이 디지털 변혁을 통해 얻고자 했던 경영 사례와는 다른 결과를 얻을 것이다. 변혁에 있어 비용 절감이 중요한 부분 중 하나일 수는 있지만 주된 문제는 아니다.

라지뱅크는 비용 관련 지표만 사용된 것은 아니었다. 애자일 모델을 따르는 팀의 숫자와 같이 일반적 애자일 변혁 측정 기준이나 일간 배포 수와 같은 데브옵스 측정 기준 또한 사용됐다. 그러나, 이것들은 활동 지표이지 결과가 아니다. IT 팀은 하루에 수백 번의 배포를 할 수도 있지만 IT 인력이 비즈니스의 요구사항과 연결돼 있지 않다면 비즈니스를 위한 결과가 도출되지 않을 것이다. 위의 대리 지표는 애자일 훈련이나 배포가 병목 지점일 때 효과가 있다. 하지만, IT 부서가 비즈니스가 분리돼있어 애자일 팀과 데브옵스 배포 라인에 병목이 발생하지는 않을 것 같다.

 

BMW 그룹과 보잉은 이미 존재하는 생산 라인을 관리하고 신제품을 지원할 수 있도록 전환하며 지속적으로 기술, 경쟁, 시장 변화에 적응했다. 이것의 핵심은 프로젝트 관리에 갇혀있는 것이 아닌 시장에 가치를 제공하는 제품 지향적 관점을 갖는 것이다.

 

소프트웨어 생산에는 비용 절감 말고도 많은 것들이 있다. 수익, 이익, 활성 사용자, 고객 만족도, OKR(목표 및 핵심 결과 지표)을 채우는 다른 지표들이 있다. 코스트 센터로 여겨지는 대기업 IT 부서의 보다는 프로핏 센터로 여겨지는 기술 기업이 더 소프트웨어 생산에 있어 더 높은 점수를 받을 수 있다.

예를 들어 보잉은 30년 생산과 30년 유지보수를 생각해 60년 앞을 보고 설계를 한다. 보잉의 성공 여부는 당장의 비용 절감만이 아니라 생명 주기 동안 비행기 채택 및 수익성에도 달려있는 것이다. 그러다보니 보잉은 자연스럽게 소프트웨어의 추적 가능성에 대한 시야를 갖춘 것이다. 소프트웨어를 효율적으로 유지보수하지 못하거나 미래의 규정 변경을 소프트웨어로 쉽게 처리하지 못했으면 생명 주기 동안 수익성에 큰 영향을 미쳤을 것이다.

즉, 보잉에서는 비행기 개발이 프로핏 센터로 여겨진다. 라지뱅크와는 완전히 다른 방향인 것이다. 항공기 생산 및 공급망 비용 감소에 꾸준히 노력하는 보잉이 비용을 신경쓰지 않는다는 것은 아니다. 그러나 동시에 매출과 수익성도 시야에 두기 때문에 가치 흐름의 모듈성에 투자를 통해 기존 제품을 현대화하는 등의 완전히 새로운 의사 결정을 할 수 있다.

 

테일러리즘은 사람을 언제나 교체 가능한 자원으로 본다. 프로젝트에 투입했다가 다른 프로젝트로 재배치하기도 한다. 이렇게 노동자를 기계처럼 대하는 것은 의사 결정의 분산과 자율성의 중요성을 깨달은 헨리 포드(Henry Ford)가 입증한 것처럼 근시안적 접근이다.

이런 근본적 문제를 개선했던 포드의 방식은 대량 생산 시대를 가속화하는 데 일조했다. 포디즘(Fordism)은 노동자, 직업 훈련, 경제적 복지에 큰 비중을 뒀다. 토요타도 포디즘을 기반으로 해 안돈 코드(Andon Cord)와 같이 비즈니스와 연결되는 방향으로 확장했다.

이 효과는 그대로 BMW 그룹의 라이프치히 공장에서 드러난다. 그런 와중에 많은 IT 기업이 아직도 철강 시대의 유산인 테일러리즘을 바탕으로 프로젝트 지향적 관리를 하고 있다. 이런 단절은 경영진과 기술 부서 사이 커뮤니케이션 간극의 원인이 된다.

 

	프로젝트 지향 관리	제품 지향 관리
예산 편성	새 프로젝트가 만들어질 때 새 예산이 필요	비즈니스 결과에 기반해 제품 가치 흐름에 자금 지원 수요에 따라 예산이 할당
기간	프로젝트 기간(종료일) 고정 프로젝트 이후 유지 관리에 관심이 없음	제품 생명 주기가 끝날 때까지 지속적 유지 관리
성공	코스트 센터 접근 방식 기간 및 예산 준수 여부에 따라 평가 개발의 자본화는 대규모 프로젝트로 귀결 비즈니스는 모든 것을 사전 요구	프로핏 센터 접근 방식 목표 및 성과 달성 여부를 비즈니스 관점에서 평가 점진적 가치 제공 및 정기적 체크포인트에 집중
리스크	시장 조사, 요구 사항 명세, 전략적 결정이 사전 결정되어야 하기 때문에 제품과 시장 적합성과 같은 전달 리스크 극대화	프로젝트 기간과 이터레이션에 걸쳐 리스크가 분산되어 선택 가치를 창출 (가정이 잘못된 경우 프로젝트 종료 또는 전략 피벗 등 선택 가능)
팀	일에 인력을 할당 사람들이 종종 여러 프로젝트에 걸쳐 있거나 이탈 후 재투입되기도 함	사람에게 일을 할당 점진적으로 교차 기능 팀이 가치 흐름 하나에 할당
우선순위	PPM 및 프로젝트 계획 주도 방식 요구 사항 전달에 집중 폭포수 방식	로드맵 및 가설 검정 주도 방식 기능 및 비즈니스 가치 전달에 집중 애자일 방식
가시성	IT는 블랙박스 PMO는 복잡한 매핑과 모호함을 만듦	비즈니스 성과와 직접적 매핑으로 투명성 제공

 

제품 지향 관리는 비즈니스로 가치를 전달하는 투자 단위 각각의 결과 측정에 집중한다. 이 단위에 해당하는 것이 제품이다. 제품이 고객에게 가치를 전달하므로 측정은 반드시 비즈니스 결과를 기반으로 이뤄져야 한다. 기존의 가치 흐름에 투입되는 투자뿐만 아니라 새로운 가치 흐름에 대한 투자 역시 제품의 비즈니스 사례를 기반으로 해야 한다.

특정 가치 흐름을 위한 비용 초과 또는 매출 기회에 빠르게 대응하기 위해 적극적인 린 예산 방식을 제안하기도 했다. 하지만 예산 편성 주기가 연간이든 빠른 주기든 중요한 것은 프로젝트가 아니라 투자 단위인 제품이다.

 

프로젝트 지향적 사고방식으로 제품을 출시한 다음 유지 보수 기간에 비용을 일부 줄일 수 있다고 가정하는 것은 여러 의도치 않은 결과를 초래한다.

한 엔지니어가 가치 흐름을 하나 이상 할당받는 경우 생산성이 크게 떨어진다. 이런 안티패턴은 인력을 연 단위로 할당하는 관행과 유지 보수 기간의 프로젝트에는 업무 시간 중 약간의 시간만 할애하면 될 것이라는 가정에서 비롯된다. 현실은 제품이 사용되는 한 수정 작업이 정기적으로 발생한다는 점이다. 쓰레싱은 구성원의 행복과 생산성 모두에 큰 문제가 된다.

 

프로젝트 지향 관리는 데브옵스 원칙과 반대되는 부작용을 초래한다. 예를 들어 소프트웨어 개발의 자본화는 큰 프로젝트를 만들려는 이유가 된다. 이해관계자들은 프로젝트가 진행되는 동안 필요할지 모르는 모든 것을 경영진에 미리 요구하도록 장려된다. 이는 린 사고방식과 지속적 학습에 완전히 어긋나는 것이다. 제품 지향 관리는 기능적 사일로가 아닌 비즈니스 성과를 위해 조직이 협력할 수 있도록 한다.

 

커네빈 프레임워크(Cynefin Framework)는 의사 결정 상황을 명확함, 어려움, 복합적, 혼돈 네 가지로 분류하는 방법을 제공한다. 소프트웨어 이니셔티브는 복합적 영역이나 혼돈 영역에 빠지는 경향이 있다. 문제 해결에 최적화된 프로젝트 지향 관리는 결국 프로젝트 기간에 발생할 수 있는 모든 우발적인 상황을 프로젝트에 넣게 된다. 이로 인해 지나치게 보수적인 기간과 불어난 예산이 측정된다. 그럼에도 불구하고 사전 계획된 프로젝트가 일반적인 가설 검증 및 학습 방식보다 제품과 시장 리스크를 피하는 데 효과적인 것도 아니다.

제품 지향적 관점에서는 최소 기능 제품(MVP)과 같은 린 스타트업의 접근 방식을 중요시한다. 리스크를 줄이는 것 외에도 점진적인 제품 지향적 접근 방식은 비즈니스가 체크포인트에서 방향을 재설정할 수 있도록 하면서 선택 가치를 만들어낸다. 더 잦은 리뷰와 체크포인트는 비싼 관리 비용을 요구하지만, 소프트웨어 복잡성과 시장이 바뀌는 속도를 고려하면 제품 생애 주기 전반에 걸쳐 추가 비용이 퍼져있는 편이 낫다.

 

프로젝트 지향 관리에서는 리소스가 프로젝트에 할당된다. 사람을 대체 가능한 소모품으로 보는 테일러리즘의 사고방식이다. 소프트웨어 전달이라는 가장 복잡한 지적 작업의 분야에서는 무의미한 일이다.

높은 성과를 내는 소프트웨어 조직은 이미 사람에게 일을 전달하는 것의 효과를 잘 알고 있다. 오래 지속되는 팀은 시간이 지남에 따라 전문성을 쌓고 관계를 구축해 속도와 사기를 높인다. 확장 불가능한 지속적 에스컬레이션 없이도 기획 변경에 대해 조직 말단에서 문제를 해결할 수 있는 등의 다른 장점도 많다. 기능 팀을 도입하는 것 또한 이러한 종류의 할당에 대한 하나의 예시이다.

 

프로젝트 지향적 관리에서는 프로젝트 계획이 우선순위를 결정한다. 계획 변경은 관리, 의사소통, 협업 측면에서 비용이 많이 들기 때문에 가급적 지양한다. 소프트웨어 전달 측면에서는 단계별 프로젝트 계획에 자연스럽게 맞아떨어지는 폭포수 방식이 채택되는 경향이 있다. 이런 특징들은 높은 예측 가능성이 보이는 프로젝트 외에는 역효과를 낸다.

제품 지향적 관리에서는 기능에 대한 로드맵과 지속적 가설 검증을 기반으로 우선순위를 정한다. 이는 경영진을 포함해 전체 조직이 데브옵스의 피드백과 지속적 학습 원칙을 준수함을 의미한다.

 

가장 중요한 것은 가시성 문제다. 오늘날 빅데이터와 분석 툴이 보편화되었음에도 많은 기업에서 IT를 블랙박스로 생각할까? IT와 비즈니스 간의 단절의 원인은 데이터 액세스에 있는 것이 아니라 IT에서 이용하는 데이터 모델과 비즈니스에서 이용하는 데이터 모델의 불일치다. IT와 소프트웨어 전달 전문가는 제품 지향적 사고방식과 방법론을 사용한다. 그러나 경영진이 계속 프로젝트 관점에서 사고한다면 소프트웨어 전달의 반복적 특성과 프로젝트 관리 기법의 정적 특성 사이를 계속 맵핑해야 한다.

---

기업은 비즈니스의 가장 큰 비용 중 하나인 소프트웨어 전달에 대한 가시성을 갖지 못할뿐더러 제대로 이해하고 있지 못했다. 반면, 거대 기술 기업과 디지털 스타트업은 성공에 필요한 관리 프레임워크를 마스터했다. 많은 기술자는 애자일과 데브옵스 업무가 변혁에 필수임을 잘 알고 있으며 그것을 조직에 전파하려 한다. 문제는 현대적 소프트웨어 전달 접근 방식이 비즈니스로 옮겨지지 않는 것이다.

비즈니스가 변화하는 소프트웨어와 물리적 제품 생산의 큰 차이를 극복해 제품 지향적 사고방식을 도입할 수 있도록 도와야 한다. 애자일과 린 프레임워크 모범 사례를 비즈니스로 끌어올려 줄 새 프레임워크가 필요하다. 게다가 활동 지향적인 대리 지표에 의존하지 않도록 비즈니스 성과 지향적 지표를 정의해야 한다.

플로우 프레임워크는 시장 변화를 감지하거나 파괴를 막아주는 전략 제안 툴이 아니다. 비즈니스 전략과 기술 전달 사이 가교 역할을 할 뿐이다. 블랙박스였던 IT를 열어 조직 전반에 피드백 루프를 만들고 비즈니스 가치 흐름과 기업의 지속적 학습을 가속화할 것이다.

 

비즈니스 측면에서 변혁, 현대화, 리엔지니어링은 수많은 방법론과 프레임워크가 존재한다. 이러한 방법론과 프레임워크는 언제나처럼 유의미할 것이며 플로우 프레임워크는 비즈니스가 이들 중 가장 적합한 방법을 이미 채택해 사용하고 있다고 가정한다. 플로우 프레임워크의 역할은 비즈니스 수준의 프레임워크와 변혁 이니셔티브를 기술 분야의 프레임워크와 이니셔티브로 연결하는 것이다. 변혁을 위한 이니셔티브가 또다시 고립되어 변혁이 실패하지 않도록 하는 것이다.

 

라이프치히 공장에서는 모든 직원이 고객이 누구인지 알고 누구든 생산 라인을 따라 기업의 가치 흐름 활동을 관찰할 수 있다. 가치 흐름으로부터 고객이 끌어당겨 갈 가치가 무엇인지 알고 있으며, 공장의 병목 지점이 어디인지도 알고 있다. 반면 오늘날 IT 기업은 직원뿐 아니라 경영진조차 생산에 대해 다음과 같은 근본적 질문에 답을 하는 데 어려움을 겪는다.

• 고객은 누구인가?
• 고객이 끌어당길 가치는 무엇인가?
• 가치 흐름은 무엇인가?
• 병목 지점은 어디인가?

플로우 프레임워크는 간단한 방법으로 이러한 문제에 답해준다. 조직은 이미 답을 알고 있는 핵심 직원이 있으며, 그들의 활동과 비전을 조직적 전략과 접근 방식에 연결해야 한다.

• 비즈니스 가치의 엔드 투 엔드 흐름을 실시간 관찰
• 병목 지점을 즉시 찾아내 투자 우선순위 설정에 활용
• 전체 가치 흐름에서 얻은 실시간 데이터에 기반한 가설 검정
• 플로우를 최대화하는 방향으로 조직을 재구성

 

조직도와 기업 구조는 현재의 가치 창출을 가장 잘 표현하는 방법이다. 그러나 이것이 우리를 실패하게 했다. 기술 투자를 비즈니스 성과에 직접적으로 연결하는 지표가 아닌, 멈춰있고 오래된 데이터와 활동 기반 대리 지표를 사용해 소프트웨어 투자와 인력 배치가 제대로 된 근거 없이 결정된다.

플로우 프레임워크는 소프트웨어 전달 결과를 위한 엔드 투 엔드 측정 시스템을 제공한다. 실제 진행되는 작업을 나타내는 소프트웨어 전달의 실측 정보 및 연관 작업을 매출 발생 등 결과로 연결하는 것에 집중한다. 일간 코드 라인 수나 일간 배포 횟수와 같은 대리 지표가 아닌 매출이나 비용처럼 결과 지향적 비즈니스 지표에 완전히 초점을 맞추고 있다.

대리 지표가 중요하지 않다는 것이 아니다. 지속적 배포 자동화가 가치 흐름에 있어 병목 지점이라면 일간 배포 횟수와 같은 대리 지표가 중요한 지표가 된다. 하지만 가치 흐름 속에서 병목 지점을 찾아내는 것 자체를 위해서는 엔드 투 엔드 지표 자체에 중점을 둬야 한다.

플로우 프레임워크가 애자일을 달성하는 방법을 알려주는 것이 아니다. 그것은 애자일 프레임워크와 교육 프로그램의 역할이다. 플로우 프레임워크는 자동화와 애자일에 대한 투자를 추적, 관리, 개선하는 역할이다.

플로우 프레임워크가 구체적인 애자일 프레임워크 또는 작업 모델을 따르게 하지 않는다. 데브옵스나 고객 성공에 대한 구체적 접근 방법 또한 요구하지 않는다. 다만, 플로우 프레임워크는 린 사고방식에 충실할 것만은 요구한다. 궁극적으로 플로우 프레임워크의 목적은 대규모 소프트웨어 전달을 위한 린 사고방식을 구현하는 실행 가능한 방법을 제공하는 것이다.

 

가치 흐름이란 제품이나 서비스를 통해 고객에게 가치를 전달하는 일련의 엔드 투 엔드 활동이다.

 

가치 흐름은 고객에게 비즈니스 가치를 전달하는 데 필요한 모든 활동, 이해관계자, 프로세스, 툴로 구성된다. 예를 들어 지원팀 혹은 비즈니스 이해관계자가 제외된다면 엔드 투 엔드 가치 흐름이 아닌 가치 흐름의 일부분이 된다. 심지어 교차 기능 팀(Cross-Functional Feature Team)이라도 독립적으로 전체 가치 흐름을 구성하는 경우는 매우 드물다. 보통 교차 기능 팀에 지원 팀이 포함되어 있지 않기 때문이다.

가치 흐름의 일부분이 중요하지 않다는 것이 아니다. 각 부분을 운영하고 결과를 측정하는 것이 주제가 아니라는 것이다.  이제는 IT 조직에서 요구 사항 관리, 프로젝트 포트폴리오 관리, 애자일, 지속적 배포와 데브옵스 등 강력한 기법들의 조합을 잘 사용하고 있다. 각 부분은 계속해서 발전하는 다양한 프레임워크, 툴, 지표를 갖는다. 마찬가지로, 엔드 투 엔드 가치 흐름을 관리하기 위한 새로운 기법이 필요하다는 것이다.

 

마이크 로터(Mike Rother)와 존 슈크(John Shook)가 <Learning to See>에서 정리한 것처럼, 제조 공장 운영에서 가장 중요한 기법은 가치 흐름 지도다. 가치 흐름 지도 기법은 생산 흐름 관리와 시스템 낭비 및 병목 지점 식별에 대한 시각적 개념도와 지표를 제공한다. 가치 흐름 지도를 보면, 제조 흐름을 통해 제품을 끌어당기는 고객을 지원하기 위해 어떻게 생산이 계획되는지 볼 수 있다. 대규모 소프트웨어 전달을 위한 비즈니스 가치 흐름에서도 이와 유사한 방법이 필요하다.

 

플로우 프레임워크는 소프트웨어 전달의 생산 흐름을 제조업처럼 시각화해보려던 시도에서 출발했다. 핵심은 비즈니스 가치의 엔드 투 엔드 흐름을 측정해야 한다는 것이다. 플로우 프레임워크의 목표는 우리가 비즈니스 결과와 연관시킬 수 있는 엔드 투 엔드 관점을 갖는 것이다. 플로우 프레임워크의 최상위 수준에서는 엔드 투 엔드 플로우 아이템과 지표가 비즈니스 성과에 연관되는지에만 초점을 맞춘다.

 

소프트웨어 플로우란 소프트웨어 가치 흐름을 따라 비즈니스 가치를 생산하는 것과 관련된 활동이다.

 

플로우 프레임워크는 엔드 투 엔드 가치 흐름과 비즈니스 결과의 상관관계에 집중한다. 가치 흐름 네트워크에서 아티팩트의 흐름으로 관측되는 소프트웨어 전달의 실측 정보로 측정된다. 애초에 병목 지점이 숨어 있던 곳을 식별하기 위해 엔드 투 엔드 지표에 중점을 둔다. 애자일과 데브옵스 지표 그리고 원격 측정은 플로우 프레임워크 보다 한 계층 아래쪽에 위치한다.

플로우 프레임워크는 플로우 지표를 추적하고 결과와 상호 연관시키기 위해 활동 측정을 지양한다. 어떻게 애자일을 하고, 데브옵스를 다루는지에 대한 지표는 존재하지 않는다. 각 가치 흐름으로 얼마나 비즈니스 가치가 흘러가는지와 어떤 가치가 만들어지는지에 집중한다. 예를 들어 시장에 대한 빠른 대응이 핵심 요구사항이라면 플로우 프레임워크는 특정 가치의 플로우와 피드백이 느리다는 것을 밝혀낼 수 있다.

 

비즈니스에서 생산성이 무엇인지에 대한 합의 없이, 생산성 측정 방법에 대한 정의 없이, 병목 지점이 무엇인지 합의하는 것은 불가능하다.

린 사고에서 생산은 제품에서 시작하는 것이 아니라 고객이 가치를 끌어당기면서 시작된다. 고객이 가치를 끌어당기려면 가치가 무엇인지 고객 스스로 볼 수 있어야 하며 기꺼이 경제적 단위와 가치를 교환할 의사가 있어야 한다. 내부 제품의 경우 소프트웨어 채택이 경제적 단위가 될 수 있다.외부 제품의 경우라면 매출이 경제적 단위에 해당할 수 있다. 소셜 미디어 툴과 같이 간접적 제품이나 광고 기반 수익 모델 제품의 경우 제품 사용 시간이 경제적 단위가 될 것이다. 정보나 비영리 조직이라면 새로 출시한 디지털 서비스 사용률이 경제적 단위가 될 수 있다.

 

플로우 아이템이란 제품 가치 흐름을 통해 이해관계자가 끌어당기는 비즈니스 가치 단위다.

 

가치 흐름 내 모든 사람과 팀에 걸쳐 있는 작업을 플로우 아이템 중 하나로 특정 지을 수 있다. 조직의 모든 프로세스와 툴이 완전히 가시적이라고 가정하면 특정 기능을 생산하고 배포하며 지원하는 모든 직원이 정확히 식별할 수 있다.

 

리스크에 대한 개념이나 기술 부채는 플로우 프레임워크에서 새롭게 소개되는 것은 아니다. 하지만 플로우 프레임워크를 사용할 때 기술 부채 작업은 반드시 가치 흐름을 통해 미래 플로우를 증가시킬 수 있는 작업으로 우선시돼야 하는 것이다. 아키텍처 계층 분리를 개선하는 것과 같은 소프트웨어 아키텍처만을 위한 작업은 피해야 한다. 각 플로우 아이템의 흐름이 소프트웨어 아키텍처를 형성해야 한다는 의미다. 아키텍처가 플로우 아이템을 형성하는 방향이어서는 안 된다.

 

플로우 아이템	전달하는 것	가치를 당기는 주체	설명	아티팩트 예
기능	새로운 비즈니스 가치	고객	비즈니스 결과를 달성할 새로운 가치 추가 고객에게 가시적	에픽, 유저 스토리, 요구 사항
결함	품질	고객	고객 경험에 영향을 미칠 품질	버그, 문제, 사건, 변경
리스크	보안, 거버넌스, 규정	보안 및 리스크 관리자	보안, 프라이버시, 규정 문제 해결	취약점, 규제
부채	미래의 장애물 제거	아키텍트	소프트웨어 아키텍처 개선	API 추가, 리팩터링, 인프라 자동화

 

네 가지 플로우 아이템은 서로 상호 배제, 전체 포괄(MCCE, Mutually Exclusive and Collectively Exhaustive) 원칙을 따른다. 소프트웨어 가치 흐름 속 모든 플로우 작업은 네 가지 플로우 아이템 중 하나의 특징만을 갖는다.

 

가치 흐름 네트워크는 플로우 개선을 위한 별도의 플로우 아이템은 없다. 프로젝트에서 제품으로 전환 시에는 가치 흐름 네트워크 자체가 하나의 제품으로 취급되어야 한다. 안정된 전달 팀이 전담해야 하며 정해진 기한이 있는 프로젝트로 여겨서는 안 된다.

 

효괒거인 소프트웨어 전달에 대해 기술자가 알고 있는 것과 비즈니스가 소프트웨어 프로젝트에 접근하는 방법 사이에는 간극이 있다. 데브옵스와 애자일은 기술자의 업무 방식에 영향을 줬지만 지나치게 기술 중심적이었고 비즈니스 이해관계자에 의해 채택되지 않았다. 비즈니스 언어와 기술 언어를 아우르고 프로젝트에서 제품으로 전환을 가능하게 할 새로운 프레임워크가 필요하다. 새로운 프레임워크, 플로우 프레임워크를 통해 데브옵스의 세 가지 방법인 플로우, 피드백, 지속적 학습을 비즈니스 전체로 확장할 수 있다.

---

플로우 프레임워크의 목표는 소프트웨어 전달 과정을 제조업 수준으로 가시화하고 비즈니스 수준에서 수행하는 것이다. 이를 위해 소프트웨어 개발 과정에서 비즈니스 가치가 어떻게 흘러가는지 추적하기 위한 핵심 지표가 필요하다. 플로우 프레임워크에서는 이를 '가치 흐름 지표'라 한다.

앞서 설명한 네 가지 플로우 아이템의 전달로 정의되는 비즈니스 가치 흐름을 높은 수준으로 가시화하기 위한 새로운 플로우 지표를 정의할 것이다. 대리 지표와는 달리 플로우 지표의 목표는 각 제품의 가치 흐름에 대한 투자와 비즈니스 결과를 연관 짓는 메커니즘을 제공하는 데 있다. 이로써 기술 투자와 비즈니스 결과를 연결할 수 있다. 또한, 플로우 프레임워크의 가치 흐름 지표에서 가장 중요한 것은 플로우 지표와 함께 각 제품의 비즈니스 가치 흐름의 결과 또한 측정한다는 것이다. 여기서 제품은 수익을 창출하는 제품을 포함해 수익이 발생하지 않는 최소 기능 제품(MVP)과 한 플랫폼 내부에서만 쓰이는 구성요소까지 포함한다.

 

플로우 지표	설명	예시
플로우 분포	단위 시간당 하나의 플로우 상태 내 상호 배제 전체 포괄(MECE)인 플로우 아이템 할당량	특정 스프린트에서 자겅 중인 각 플로우 단위 비율
플로우 속도	단위 시간당 완료된 플로우 아이템 작업 개수	특정 릴리즈에서 해소된 기술 부채
플로우 타임	플로우 아이템이 가치 흐름에 들어온 시점부터 고객에게 전달된 시점 사이의 시간	새 기능을 도입하기로 승인한 시점부터 고객에게 기능을 전달하기까지 걸린 시간
플로우 부하	플로우 상태가 활성/대기 상태인 플로우 아이템 개수(WIP)	플로우 부하가 특정 임게치를 넘으면 플로우 속도가 저하됨
플로우 효율	전체 시간 대비 플로우 아이템이 능동적으로 작업되는 시간 비율	의존성으로 팀이 다른 요소를 기다리게 되면 플로우 효율이 줄어듦

 

플로우 분포란 비즈니스 가치를 극대화하기 위해 각 흐름의 필요에 따라 조정된 가치 흐름 내 플로우 아이템의 비율이다.

 

플로우 분포를 사용해 비즈니스에 전달하고자 하는 결과에 맞춰 가치 흐름을 재단할 수 있다. 즉, 제품의 위치에 따라 기능, 결함, 리스크, 기술 부채 네 가지의 플로우 아이템의 비율이 달라질 수 있는 것이다.

플로우 분포는 비즈니스 우선순위를 어떻게 지원할지 결정하는 제로섬 메커니즘이다. 생산 라인을 이루는 모든 것은 요구되는 플로우의 유형에 맞춰 설계돼 있었다. 라이프치히 공장도 살펴보면 i3, i8 모델의 생산 라인과 1, 2시리즈의 생산 라인의 구조가 그토록 상반되게 디자인된 이유다. 각 생산 라인에서 만들어지는 차가 비슷한 크기나 모양일 수는 있어도 생산 라인 하나에는 혁신, 다른 하나는 대량 생산이라는 서로 다른 비즈니스 요구사항과 제약 조건에 맞춰진 것이다.

 

플로우 분포의 장점은 제품 및 엔지니어링 팀과 관리자가 일상적으로 사용하는 계획 방식 그대로 비즈니스 수준에서 명시적이고 규모에 맞게 수행할 수 있다는 것이다. 플로우 분포의 트레이드오프를 고려해 비즈니스는 소프트웨어 전달의 트레이드오프를 더 잘 이해할 수 있게 된다.

플로우 분포 트레이드오프라는 제로섬 게임은 계획되지 않은 작업이 가치 흐름에 들어왔을 때마다 개발 리더가 내려야 하던 다른 작업을 포기하는 결정을 비즈니스에게도 강제한다. 결함에만 집중하면 기술 부채 백로그의 증가로 더이상 새로운 기능 전달이 불가능할 수 있다. 리스크의 우선순위를 조정하지 않는다면 비즈니스에서는 잘 보이지 않는 위험 요소들이 해결되지 않을 것이다. 균형 잡힌 플로우 분포를 보려면 각 플로우 아이템은 비슷한 수준의 작업 공수와 크기를 가져야 한다. 

 

플로우 속도는 애자일의 속도 개념을 차용한 것이다. 얼마나 많은 작업 단위를 주어진 시간 동안 한 팀이 전달하는지를 측정하는 것이 애자일에서 말하는 속도다. 플로우 속도 역시 같은 개념을 네 가지 플로우 아이템에 적용한 것이며 좀 더 단순하고 덜 세분화된 측정 방식이다.

플로우 분포만으로는 플로우 아이템의 처리 기간이나 상태에 대해 알 수 없다. 따라서 이번 릴리즈에서 진행 중이거나 완료된 작업에 대해 알아보거나 미래를 예측할 수 없다. 일정 단위 시간 동안 완료된 플로우 아이템 수를 측정하기 위해서 플로우 속도가 필요하다.

 

코드 라인 수 같은 측정치는 얼마나 많은 가치를 전달했느냐를 보는 것이 아니다. 단지 개발자가 특정한 종류의 작업을 얼마나 많이 했는지를 계산한다. 예를 들어 제품의 '좋아요' 버튼 동작을 바꾸는 작업은 몇 줄 안되는 코드만 필요하겠지만 많은 분석과 설계를 요할 수도 있다. 따라서 코드 라인 중심 지표는 다양한 가치 흐름에서 일어나는 작업의 세세한 측면을 이해하는 데 도움이 되지만 비즈니스 가치를 캡슐화하는 데 부적합하다.

 

플로우 타임은 전달 속도를 알아내기 위해 필요하다. 플로우 분포와 플로우 속도만으로는 작업 사이클이 얼마나 빨리 시스템을 통과하는지를 나타내지 못한다.

린 제조에서 리드 타임과 사이클 타임 두 가지 핵심 지표가 있다. 리드 타임은 전체 프로세스를 아우르는 시간을 측정하는 것이고, 사이클 타임은 프로세스 안에서 한 단계를 마치는 데 걸리는 시간이다. 따라서 가장 긴 사잉클 타임을 갖는 단계가 보통 병목지점이며, 리드 타임은 모든 프로세스를 거치는 데 걸리는 시간을 알려준다.

그동안 애자일과 데브옵스에서 리드 타임은 잘못 사용되어지고 있었다. 데브옵스 커뮤니티에서 자주 쓰이는 '코드 커밋부터 배포까지의 리드타임'은 사실 가치 흐름 중심의 관점에서 보면 배포 사이클 타임으로 봐야 한다.

 

플로우 타임은 플로우 아이템의 4가지 플로우 상태 변화에 기반한다. 4가지 상태는 '신규', '대기', '활성', '완료'이다. 단일 플로우 아이템의 리드 타임은 항목의 '신규' 상태일 때부터 '완료' 상태로 변경될 때까지의 시간으로 측정될 수 있다.

 

플로우 부하란 하나의 가치 흐름 내에서 진행 중인 플로우 아이템의 개수다. 비즈니스는 가치 흐름 내 자원 활용을 극대화하려는 경향이 있다. 그런 경향은 제조 분야에서 로봇 가동률 100%라는 형태로 나타난다. 하지만 이러한 과다 활용은 제품 개발에 부정적인 영향을 준다.

플로우 부하 지표는 다른 플로우 지표들과 연결돼 결과를 명확히 하고, 플로우 속도는 최대화하며 플로우 타임은 최소화하는 수준으로 설정할 수 있도록 가시성을 제공한다. 플로우 부하의 수준은 가치 흐름에 따라 다양할 수 있다.

 

플로우 효율은 각 플로우 아이템의 활성 작업 시간을 추적하는 것이다. 대기 중인 항목이 많을수록 더 많은 WIP가 발생하고 가치 흐름의 대기열이 점점 늘어난다. 결국 리소스 과다 활용과 콘텍스트 스위칭으로 낭비가 많아져 지연이 심해진다.

---

플로우 프레임워크의 핵심 목표는 가치 흐름을 측정하기 위한 일련의 핵심 지표를 제공하는 것이다. 비즈니스를 위해 필요한 매우 방대하고 세부적인 지표 중 각 제품의 가치, 비용, 품질, 행복도의 네 가지 지표를 요구한다.

---

 

툴의 급증과 조직의 전체적인 인프라 계층 부족은 소프트웨어 가치 흐름의 단절을 이끈다. 소프트웨어 가치 흐름의 단절은 소프트웨어 생산성에서 심각한 병목 지점이다. 이 단절 문제는 비즈니스 이해관계자부터 지원 부서의 구성원에 이르는 모든 소프트웨어 전문가에게 걸쳐 있다. 제품 지향적 소프트웨어 가치 흐름상 엔드 투 엔드 전달 아키텍처와 프로젝트 운영 모델이 잘못돼있는 것이다. 제조업을 예로 들면 어떤 단계의 작업을 시작하기도 전에 다음 워크스테이션으로 부품을 넘기는 것이다.

---

전문화를 통해 증가하는 복잡성을 처리할 수 있지만 전문화가 만드는 사일로가 효과적으로 연결돼 있어야만 전문화의 이점을 제대로 활용 가능하다. 사일로 중 몇몇은 사람 간 협업과 상호 작용으로 연결될 수 있다. 그러나 그 외의 경우 구성원이 일상 업무에서 처리하는 복잡한 지식을 함께 작업하고 나눌 수 있는 인프라로 사일로 간 통합이 이뤄져야 한다.

---

플로우와 가시성이라는 핵심 개념을 소프트웨어 전달에 적용하기는 어려움이 많았다. 지속적 통합과 지속적 배포 부분은 일련의 자동화 단계이기에 제조업 개념으로 매핑하는 것이 어렵지 않았다. 그만큼 병목지점 식별도 쉽다.

하지만 디자인, 코딩, 배포를 담당하는 팀 간 역학 관계에서 가로막혔다. 처리 능력이 충분하지 않은 UX 팀 하나를 여러 개발 팀이 기다리는 경우나 지원 팀에서 나올 고객 환경 정보를 기다리는 경우, 다운 스트림 작업을 위해 API가 추가되기를 기다리는 경우 등 플로우 문제에 대해서는 다양한 경험이 있다.

결국, 가치 흐름을 통해 흘러가는 내부 아티팩트를 시각화하는 것이 문제다. 작업에 대한 피드백에서 생산 라인이나 가치 흐름 지도를 연상할 수 있게 제조업에 빗댄 개념을 사용할 것을 목표로 잡았었다. 하지만, 이는 잘못된 비유 방법이었다. 고객의 가치 흐름에서 볼 수 있던 것은 선형적 제조 공정 같은 것이 아니었고, 오히려 항공 노선 네트워크에 더 가까웠다.

 

네트워크 관리에서 병목 지점은 간단하게 경로를 변경해 처리할 수 있는 제약 사항에 불과하다. 선형 프로세스처럼 플로우를 멈출 필요가 없다. 일부 기상이 좋지 않을 때, 약간의 지연이 발생하겠지만 항공 교통 운영 시스템은 항로를 변경해 승객이 목적지에 무사히 도착할 수 있도록 할 수 있다. 소프트웨어 전달 팀들이 병목 지점을 맞닥뜨렸을 때 창의적으로 작업 경로를 우회했던 것과 아주 유사하게 말이다. 이런 즉각적인 경로 변경이나 툴 변경은 제조업에서 쉽게 할 수 없다.

 

폭포수 모델 방식은 소프트웨어 전달에 있어 복잡하게 얽힌 이해관계자를 선형적으로 단순화해 보여주기 때문에 이론상으로는 훌륭해 보인다. 하지만 이 이론은 실패하고 말았다.

애자일 개발은 이러한 상황을 타개하고자 나타났지만 비즈니스 분석가와 운영 담당자 등 이해관계자를 제외함으로써 소프트웨어 전달의 관점을 지나치게 단순화했다.

데브옵스는 배포 프로세스 운영, 자동화, 반복 가능성을 받아들이면서 애자일에서 제외된 부분을 보완했다. 하지만 엔드 투 엔드 플로우 및 피드백에 집중하기보다 선형적 프로세스에만 너무 많이 집중해 조직들은 지나치게 선형적인 데브옵스를 도입하는 실수를 반복했다. 자동화된 반복 가능한 방법으로 잦은 릴리즈를 줄여가는 능력은 데브옵스 변혁의 훌륭한 출발점이 될 수 있다. 그러나 이는 제품의 엔드 투 엔드 가치 흐름을 최적화하기 위한 작은 한 걸음일 뿐이다.

 

플로우에 관한 생각을 생산 라인에서 네트워크로 옮기면 많은 린 개념들이 의미를 갖게 된다. 진행 중인 작업(WIP)을 최소화하기 위한 작은 배치 크기나 한 개 흐름(One piece flow)과 같은 것들이 그렇다. 그러나 제조업적 관점을 지나치게 적용하는 것을 피하려면 제조업의 선형적 가치 흐름 관리와 네트워크 기반 가치 흐름 관리의 핵심적 차이를 확실하게 정의해야 한다.

• 가변성
  • 제조업은 생산 라인 끝에서 어떤 것이 생산될지 잘 정의된 바리에이션 목록을 정해 놓는다.
  • 소프트웨어 기능의 디자인은 얼마든지 조정할 수 있다. 이를 받아들여야 한다.
• 반복성
  • 제조업은 대량 생산을 목표로 한다.
  • 소프트웨어는 반복과 피드백을 최대화해 제품을 계속 개선하는 것을 목표로 한다.
  • 엔드 투 엔드 플로세스를 위해서는 반복성뿐만 아니라 플로우, 피드백, 지속적 학습을 최적화해야 한다.
• 설계 빈도
  • 제조업은 수년에 걸친 프로젝트 중심 주기에 따라 설계된다. 생산 라인 자체에 변경을 요구하는 설계 변경은 자주 일어나지 않는다.
  • 소프트웨어는 제품 지향적 방식으로 기능 전달을 위해 가치 흐름을 흐르는 플로우 아이템의 비율에 따라 설계 빈도가 증가한다.
• 창의성
  • 제조업 프로세스는 최대한 많은 자동화를 목표로 한다. 창의적이나 결정되지 않은 작업을 생산 프로세스에서 제거한다.
  • 소프트웨어 전달은 각 단계에서 창의성과 협업을 가능하게 하는 것에 초점을 맞추며 창의성을 지원하기 위한 자동화를 활용한다.

 

가치 흐름에서 낭비의 원인으로 지목되는 다섯 항목을 살펴보자.

• 과도한 WIP
  • 너무 많은 WIP 가치 흐름에 있으면 대기열이 생기고 전달 속도가 떨어진다.
• 알려지지 않은 종속성
  • 소프트웨어 전달에서 관리가 가장 어려운 것 중 하나는 팀, 구성 요소, 제품 간 종속성이다.
  • 각 종속성은 아티팩트 네트워크에서 분명하게 드러난다.
• 계획되지 않은 작업
  • 소프트웨어 전달 일정에 예측 불가능성을 추가하는 원인 중 하나다.
• 우선순위 충돌
  • 플로우 프레임워크는 플로우 아이템 수준에서 충돌하는 우선순위를 드러나게 한다.
  • 기능, 결함, 리스크, 기술 부채 각각에 얼마나 큰 노력을 기울일 것인가를 이해관계제에게 명확히 결정하도록 갖게 한다.
• 방치된 작업
  • 기술 부채와 좀비 프로젝트 등과 같이 방치된 작업은 낭비의 원인이다.

 

통합 모델은 툴 네트워크를 추상화하는 계층을 제공해 점점 늘어나는 전문적 역할과 툴을 연결한다. 이로써 전문가와 팀 사이에 정보의 자동화된 흐름을 만든다. 활동 모델은 이렇게 흐르는 아티팩트와 상호 작용을 플로우 아이템 및 가치 흐름의 다양한 단계로 매핑할 수 있게 한다. 제품 모델은 플로우 지표를 계산하고 이를 비즈니스 결과로 연관시키기 위해 흐름과 활동을 소프트웨어 제품에 정렬시킨다.