21 린 소프트웨어 개발원칙
성공적인 소프트웨어 신상품 개발가이드
하드웨어 제품 생산의 낭비를 제거하기 위해 도요타 자동차에서 개발된 린의 개념을 (《린 소프트웨어 개발의 적용》(2007)의 저자인) 포펜딕(Poppendieck) 부부는(메리 포펜딕, 톰 포펜딕) 소프트웨어 개발에 적용하였다. 린의 핵심은 낭비를 제거하는 것이다. 이번 섹션에서는 린의 의미와 린 소프트웨어 개발의 원칙을 설명한다.
1) 린(lean)의 의미
소프트웨어는 생산이 없고 하드웨어보다는 설계 변경이 용이하기에 신상품 개발주기가 상대적으로 짧고 시행착오에 대한 실패비용도 상대적으로 작다.
이러한 소프트웨어 특성에 '린'의 개념을 반영한 상품개발 방법론이 실리콘밸리를 중심으로 확산된 린 스타트업 방법론이다. 1970년대 일본 도요타 자동차의 생산방식에서 사용된 ‘린’이라는 용어가 40년이 지나 미국 실리콘밸리의 스타트업에서 유행하는 이유가 무엇일까? 먼저 ‘린’의 의미에 대해 살펴보자.
사전적 의미의 린은 ‘기름기(낭비, 불필요)를 제거한’의 의미이다. 하드웨어 제품 생산에서 린은 필요한 만큼만 생산하여 재고를 최소화하는 것이 핵심이다. 그래서 린 생산은 JIT(Just In Time)로 많이 알려져 있다. 그 이전에는 부품이 있는 만큼 공장을 최대한 많이 가동하는 것이 효율을 높이는 것이라고 생각했다.
스타트업은 펀딩 받은 예산이 소진되기 전에 성장 가능성을 입증해야 살아남는다. 따라서 낭비를 최소화하는 린의 개념이 스타트업 조직이 추구해야 할 방법론의 기본이 된다. 린 소프트웨어 개발원칙은 다음과 같다.
2) 린 소프트웨어 개발의 원칙
포펜딕 부부가 정리한 린 소프트웨어 개발원칙을 요약하면 다음과 같다.
- 낭비를 제거한다
고객에게 가치를 제공하지 않는 모든 활동은 낭비이다. 소프트웨어 상품의 낭비는 상품기획의 낭비, 상품개발의 낭비로 나눌 수 있다.
상품기획의 낭비는 고객이 원하지 않는 기능을 기획하는 것으로 가장 치명적인 낭비이다. 고객이 원하지 않는 기능을 기획하면 그 기능을 개발하고, 문서화하고, 유지하기 위한 시간과 돈은 모두 낭비이다.
상품의 기능이 많아지면 상품의 복잡도가 증가한다. 상품의 복잡도는 인체에 비유하면 비만과 유사하다. 인체의 비만이 면역체계를 약하게 만들듯이 상품의 복잡도는 품질을 취약하게 만든다. 따라서 복잡한 상품구조에서 기능을 추가하려면 테스트 할 내용이 많아져 상품개선의 속도가 느려진다. 상품기획의 낭비를 요약하면 아래 그림과 같다.
상품기획의 낭비상품기획의 낭비를 줄이기 위해서는 고객의 불편사항 또는 혜택을 정확하게 파악하거나 고객이 불필요하다고 생각하는 기능을 최대한 빨리 파악해야 한다. 이는 뒤에서 설명할 린스타트업 방법론의 핵심원칙이다.
상품개발의 낭비는 상품개발 과정에서 발생하며, 피할 수 있었던 재작업(‘삽질’과 같은 의미), 불필요한 문서화 작업, 작업대기 시간이 대표적인 예이다. 애자일 방법론은 상품개발의 낭비를 줄이는 것에 집중한다. 상품개발의 낭비를 초래하는 대표적인 요인은 ‘필요이상의 상세한 계획’ 과 ‘큰 규모의 개발’이다.
계획수립을 위한 정보가 부족하거나 불확실한 상황에서 무리하게 상세계획을 확정하면 이행하는 과정에서 재작업의 낭비가 발생한다. 상세한 계획수립이 나쁘다는 것이 아니다. 충분하고 확실한 정보가 주어졌을 때 상세한 계획을 수립하고 이행하면 계획변경 또는 재작업의 가능성이 줄어든다
큰 규모 일괄작업도 재작업의 가능성을 높인다. 큰 규모의 개발을 하면 요구사항 정의와 개발의 시간차이가 길어진다. 요구사항 정의후 요구사항 개발완료가 오래걸릴수록 요구사항의 변경 가능성은 높아진다. 요구사항은 시간에 취약하다. 시간이 지날수록 요구사항의 변경가능성이 높아진다. 기능을 변경하더라도 릴리즈후 고객의 평가를 받고 변경하는 것이 바람직하다. 또한 큰 규모의 일괄작업은 결함의 발견시기를 늦춘다. 작게 개발하여 빠르게 한번의 사이클을 수행하면 아키텍처상의 결함을 조기에 발견할 가능성이 높아진다. 상품기획의 낭비를 요약하면 아래 그림과 같다.
상품개발의 낭비상품개발의 낭비를 줄이기 위한 대표적인 활동은 불확실성과 변경을 수용하는 애자일 방법론을 적용하는 것이다.
- 부분이 아닌 전체를 최적화한다.
많은 기업들이 전체 최적화보다 부분 최적화에 집중한다. 대표적인 예가 자원효율성의 함정에 빠지는 것이다. 아래 그림과 같이 상품기획, 디자인, 개발, 테스트가 각자의 성과를 최적화하는데 집중하면 제조의 과잉생산의 함정에 빠지게 된다. 상품기획은 보다 많은 요구사항 목록을 만들고, 디자이너는 보다 많은 화면을 디자인하는데 집중한다.
내가 만든 결과물이 후속공정에서 제대로 사용되는지 보다, 보다 빨리 보다 많이 만드는데 집중한다. 자원효율성 관점에서 각 부서를 평가하면 이러한 부작용은 심화된다. 부분최적화를 추구하는 조직은 정신없이 바쁘지만 고객이 원하는 기능을 제공 하기까지의 리드타임은 길어진다.
자원 효율성에 집중하는 부문 최적화모든 조직이 바쁘게 움직이는 것보다 기업이 고객에게 의미있는 가치를 빨리 전달하는 것이 중요하고 이것이 전체 최적화의 핵심이다. 따라서 전체 최적화는 ‘가치의 흐름’을 빠르게 하는데 집중한다. 전체 최적화를 위해서는 상품개발팀의 설계와 운영이 전문조직이 아닌 팀 중심으로 변경해야 한다
흐름 효율성에 집중하는 전체 최적화잘게 나눈 개별 프로세스를 최적화하면 전체 시스템도 최적화될 것이라는 생각은 틀렸다. 부분보다 전체를 대표하는 지표를 발굴하고 관리해야 한다. ‘요구사항의 접수부터 출시까지의 리드타임’이 전체를 대표하는 지표의 예이다. 전체 최적화를 대표하는 지표를 최적화하는 과정에서 하위지표들은 전체를 위해 최적화된다. 신상품 개발의 평가지표가 많은 조직은 부분 최적화 함정에 빠져있을 가능성이 높다.
- 미완성 작업을 최소화한다.
생산공정에서 재고를 쌓아둘수록 재고를 관리하기 위한 비용이 증가하듯이 소프트웨어 개발에서 미완성작업도 개발의 낭비를 초래한다. 미완성작업의 예는 ‘코딩하지 않은 요구사항 문서’, ‘테스트하지 않은 코드’, ‘문서화하지 않은 코드’, ’배포되지 않은 코드’등이다. 미완성 작업이 낭비를 초래하는 이유는 위에서 설명한 재작업 또는 변경가능성이 높아지기 때문이다. 미완성 작업을 줄이기 위해서는 일괄작업의 크기를 줄여야 한다.
결함을 바로 수정하는 것도 미완성 작업을 줄이기 위함이다. 소프트웨어 개발과 테스트를 분리하면 소프트웨어 개발 후 통합 시점에서 테스트비용이 발생한다. 결함 목록을 작성하여 추적 관리하는 것보다 결함이 생기지 않도록 하고 발생한 결함은 빨리 고치는 것이 중요하다. 이는 생산공정에서 불량발견시 라인을 스톱하고 불량을 고치는것과 유사하다. 프로그램에서 발생한 결함을 알고도 나중에 일괄 수정할수록 테스트 및 결함수정 기간이 길어진다.
- 지식을 창출한다
상품개발과정은 학습의 과정이다. 상품개발을 통해 고객들이 해결을 원하는 문제를 이해하고 문제를 해결하는 현재의 방법이 적합한지 학습해야 한다. 또한 상품개발 낭비를 최소화하기 위해 상품개발 프로세스를 개선할 사항도 파악해야 한다. 고민과 성찰이 없으면 학습할 것도 없다. 문제의식을 가지고 고객을 인터뷰하고 관찰해야 고객가치를 발견할 수 있고, 전체 최적화의 관점에서 개별 프로세스를 파악해야 개별 프로세스의 개선사항을 발견할 수 있다. 몰랐던 사실을 학습했다는 것은 기존의 계획이 잘못되었다는 것을 의미한다. 잘못된 것을 개발하고 있었거나 잘못된 방식으로 개발했다는 것이다. 따라서 새로운 지식이나 사실을 학습한 뒤에는 반드시 기존의 계획을 변경해야 한다.
스타트업 조직에서는 보다 싸고 보다 빨리 고객가치를 학습하는 기법이 중요하며 그것이 뒤에서 설명할 린스타업 방법론의 핵심이다.
- 돌이키기 힘든 결정은 늦춘다
상품개발의 의사결정은 적은 비용으로 돌이킬 수 있는 의사결정과 반대로 돌이킬려면 많은 비용이 발생하는 의사결정이 있다. 돌이킬 수 있는 의사결정은 신속하게 결정하고 시행하고 결과를 보고 필요시 의사결정 내용을 변경한다. 상품 전체에 영향을 주지 않는 요구사항이 이에 해당한다. 반면 상품전반에 영향을 주는 중요한 정책이나 개발 아키텍처의 결정은 마지막 순간에 내려야 한다. 요구사항 결정을 미루라는 의미가 아니다. 허용 가능한 마지막 순간에 의사결정해야 재작업이나 변경 가능성이 낮다는 것이다. 허용 가능한 마지막 순간에는 정보의 양도 많고 질도 높기 때문에 정확한 의사결정을 내릴 가능성이 높다.
돌이킬 수 없는 의사결정을 최대한 미루라는 말을 고객에게 가치를 전달하는 스피드를 희생하는 것으로 생각해서는 안된다. 일상의 의사결정과 달리 돌이킬 수 없는 중요한 의사결정은 어느 시점까지는 불확실성을 감당할 수 있어야 한다.
- 빨리 인도한다
린은 고객에게 가치를 제공하는 속도를 높이기 위해 노력한다. 고객에게 가치를전달하는 속도는 ‘가치의 양’과 ‘개발속도’가 결정한다. 개발속도가 같아도 불필요 개발을 최소화하면 같은 시간내에 고객에게 ‘가치의 양’은 증가한다. (불필요 기능이 필요기능의 가치를 잠식하는 것은 고려하지 않았다.) 아래 그림과 같이 고객 인터뷰를 추가하더라도 고객이 필요로 하지 않는 기능을 식별할 수만 있다면 그렇게 하는 것이 고객에게 가치를 전달하는 속도는 높아진다.
불필요 기능개발을 제거하여 가치제공 리드타임 단축개발속도를 저해하는 대표적인 요인은 품질이다. 개발 완료후 품질을 점검하는 시간이 길수록, 점검결과 수정사항이 많을수록 고객에게 가치를 제공하는 속도가 느려진다. 상품개발 속도를 높이기 위해서는 품질을 검검하고 수정하는 시간을 단축해야 한다. 그러기 위해서는 상품개발과정에서 안정적인 품질을 확보해야 한다. 개발과 품질을 분리하여 개발후 테스트를 통해 적정수준의 품질을 확보하려면 상품개발 속도는 느려질 수 밖에 없다.
특수한 상황에서 속도를 위해 품질을 희생할 수 있지만, 스피드를 위해 품질을 일상적으로 희생하는 것은 불가능하다. 그런 상품을 구매할 고객은 지구상에 없기 때문이다. 빠르게 움직이는 개발팀일수록 품질에 대한 규율이 정착되어 있다. 빠른 속도와 꼼수는 다르다.
주어진 시간에 더 많이 개발하여 가치제공 속도를 높이는 것은 린의 사상과는 반대다
- 상품개발팀을 존중한다.
상품개발팀을 성악설의 관점에서 대하면 상명하복과 통제의 대상이 된다. 성악설의 관점에서 사람들은 목표달성의 동기가 약하기 때문에 목표달성을 위해서는 사람들을 통제해야 한다고 생각한다. 그 결과 업무 수행방식을 상세하게 가이드하고 개인별 진척상황을 파악하여 목표달성을 독려한다. 이러한 사고는 테일러의 ‘과학적 관리’의 유산이기도 하다. 데이터를 중시하는 과학적 관리는 중요하지만 사람을 목표달성의 주체가 아닌 도구로만 파악하는 것은 재고의 여지가 있다. 그러나 많은 관리자들이 이러한 방식으로 상품개발팀을 관리한다. 성악설의 관점에서 상품개발팀을 관리하면 최악의 결과는 피할 수 있지만 애자일이나 린에서 추구하는 상품개발 프로세스의 혁신은 달성 할 수 없다.
상품개발팀을 존중한다는 것은 상품개발팀이 목표달성을 위해 최선을 다할 것이라고 신뢰하고, 목표달성 방법은 상품개발팀이 스스로 결정하도록 하는 것을 의미한다. 모든 상황에 적합한 유일한 프로세스는 없고, 대부분의 프로세스는 상황에 맞게 적용해야 한다. 프로세스 선정 및 조정에 대한 결정권한을 상품개발팀에 위임해야 한다. 관리자가 할 일은 상품개발팀이 의사결정을 하고 실행하는데 있어 걸림돌을 제거하는 것이다.
https://brunch.co.kr/@kbhpmp/160
