애시 모리아 <린 스타트업> - 9장 요약

본문 중에서..

전형적인 제품 개발 주기는 요구사항 / 개발 / 품질보증 / 출시로 이루어져있다.

요구사항 수집 단계에서도 학습을 하지만, 많은 내용을 학습하게 되는건 제품 출시 이후다.

학습 단계에 빨리 도달하기 위해서는 가능한 한 최소 제품을 구축할 수 있게 MVP 범위를 핵심 기능으로 축소하는거다.

- 가장 중요한 문제부터 시작해야한다.

MVP의 핵심은 기장 중요한 문제를 해결하는 솔루션 데모에 반영되어야한다.

- 있으면 좋은 기능과 필요없는 기능들을 제거해야한다.

데모의 모든 요소를 반드시 필요한 기능, 있으면 좋은 기능, 필요없는 기능으로 구분할 수 있어야한다. 필요없는 기능들은 즉시 제거하고, 반드시 필요한 선결 기능이 아니라면 있으면 좋은 기능들은 대기 목록에 추가해야한다.

- 최적화가 아니라 학습에 초점을 둬야한다.

모든 에너지는 학습 속도를 높이는 데에 쏟아야 한다. 속도가 핵심이여서, 서버 / 코드 / 데이터베이스 최적화에 노력을 낭비하면 안된다. 처음 제품 출시 깨는 규모가 문제가 될 가능성은 별로없다. 이런 문제가 드물게 발생하더라도, 일단 하드웨어를 추가해서 효율적으로 문제해결하는 방법을 찾을 때까지 시간을 벌 수 있다.


처음부터 지속적 배포 구현하기

요구사항부터 제품출시까지 주기를 단축하는 또다른 방법은 지속적 배포를 구현하는거다.

지속적 배포는 며칠에 한 번이나 몇주에 한 번씩 소프트웨어를 업그레이드하는게 아니라 끊임없이 업그레이드하는 개발 방식이다.

여기서 목표는 낭비를 없애는거다. 소프트웨어에서 가장 큰 낭비는 소프트위어가 한 단계에서 다음 단계로 이동하는 것을 기다리는 데서 발생한다. 즉 코드가 작성될 때까지 기다리고, 테스트를 기다리고, 배포될 때까지 기다려야 한다. 이런 대기 시간을 단축하거나 제거하면 더 빨리 개선 작업을 반복할 수 있는데 이것이 성공의 열쇠다.

지속적 배포를 정확히 구현하는 경우 품질이 떨어지는 것이 아니라 더 엄격한 테스트와 모니터링 기준을 요구한다.

지속적 배포 프로세스는 학습과 개선을 위한 피드백 고리이며, 소규모로 시작하기에 적합하다.

아직 고객이 없고, 코드도 별로 없고, 염려할 서버가 별로 없는 지금이 지속적 배포를 위한 기반과 업무 관행을 구축하기에 가장 적합한 시점이다.

지속적 배포가 MVP를 더 빨리 개발하는 데는 도움이 안 될지 모르지만, 적어도 개발이 느려지지는 않는다. 그리고 제품 출시 이후 반복 개선의 속도를 높이는 데는 도움이 된다

그리고 지속적 배포는 소스 코드를 작은 단위로 작성한 후, 시스템에 일괄 처리하지만 이 코드를 사용자가 바로 사용할 필요는 없다는 점도 중요하자. 소프트웨어 릴리스와 마케팅 릴리스는 다르다.

요즘 참여하고 있는 사이드 프로젝트를 그저께 사내에서 데모 시연을 했었다. 그런데 때마침 린스타트업의 MVP 챕터를 읽으니, 엄청 잘 와닿는다 ㅎㅅㅎ 인생실전 잼..

아무튼, 메인 프로젝트와 구분된 별도의 장고 프로젝트 / 서버로 관리하고 있고, 배치나 배포도 젠킨스로 관리하고 있는데, 데모 수준에서부터 지속적인 배포를 할 수 있는게 좋은 선택이였단 생각이 든다 ㅎㅅㅎ