<aside>
📚 토글 (▶ )을 클릭하여, 교육자료의 목차를 확인하고 빠른 이동을 할 수 있습니다.
(전체 토글을 열고닫는 단축키 - Windows : Ctrl + alt + t / Mac : ⌘ + ⌥ + t )
1900년대 후반까지 소프트웨어 개발의 일반적인 구조는 프로젝트를 진행하는 것이었습니다. 프로젝트는 건축 산업의 프로젝트와 같은 방식으로 기획, 설계, 시공, 완공과 같은 순차적인 단계를 거쳐 시작 일시부터 완료 목표 일시까지 계약된 결과물을 잘 만드는 것입니다. 프로젝트의 특징은 개발할 범위를 사전에 정하고, 개발 기간을 기준으로 계약을 통해 약속한 상황에서 이 약속을 이행하기 위해 필요한 사람과 자원을 투입하는 방식입니다. 발주 주체와 수주 주체, 설계, 시공 등 각 단계의 일을 진행하는 사람이나 조직도 별개이고 목표도 다른 것이죠. 프로젝트 방식에 적합하도록 정착된 소프트웨어 개발 방법론이 워터폴 개발 방법론(이하 ‘워터폴’) 입니다.
그림 출처: https://www.credera.com/insights/waterfall-or-agile-or-both-a-hybrid-project-management-approach
폭포처럼 각 단계를 거치면서 진행을 해나간다는 의미로 이름이 붙여졌습니다. 워터폴은 그림이 보여주는 것과 같이 다음 단계로 넘어가면 이전 단계로 되돌아가는 과정이 없습니다. 전체 프로젝트 기간에 맞추어 역할 직무 별로 완성된 결과물을 만들고 다음 단계로 전달하는 것입니다. 한 번에 완성된 결과물을 만들어야 해서 프로젝트 기간에 발생할 수 있는 변수를 포용하기 어렵습니다. 범위는 고정되어 있는데, 기간이 정해져 있으므로, 변수가 발생하거나 초기에 규모 산정이 적절하지 않은 경우에는 프로젝트는 계약한 계획대로 완료되지 못합니다.
소프트웨어 개발 업계에서는 프로젝트가 초기 계획대로 수행되지 않는 과정이 종종 발생하면서, 1) 계약 이행 실패, 2) 개발사가 수주하면서 받은 금액이 부족한 경우, 3) 계약대로 이행하기 위해 프로젝트에 투입된 사람들이 힘들게 일하는 경우, 4) 프로젝트 기간 동안에 발생한 시장 또는 고객의 요구 변화에 대응하지 못한 결과물 완성, 5) 마지막 단계에 몰아서 결과물을 검증하면서 발생가능한 많은 수의 결함 과 같은 문제와 고통이 반복되고 있었습니다.
사람의 업무 관점에서는 프로젝트는 고객과 함께 일하지 않고 계약 관계로 맺어지기 때문에 고객의 요구사항을 일방적으로 받는 방식으로 개발을 합니다. 더욱이 프로젝트 내 구성원들도 자신의 역할과 단계에만 집중하고 다음 단계로 결과물을 전달하는 방식으로 인해 책임성 부족, 품질보다는 완성을 우선, 전달 과정에서 발생하는 중요한 정보의 상실이 발생합니다.
프로덕트는 소프트웨어 개발 과정이 프로젝트와 같은 기간 / 단계 / 사람의 단절보다는 장기적인 관점 / 역할 간의 협업 / 원팀으로 진행되는 연속적인 업무로 결과물을 만들어 가는 것의 핵심 단어입니다. 프로덕트는 탄생부터 환경, 기술, 고객의 요구에 맞추어 계속해서 진화하는 살아있는 유기체와 같은 특성을 같습니다. 프로덕트를 개발하는 사람들은 특정 기간 동안에 요구사항을 충족하는 개발을 우선하기 보다는 프로덕트가 고객과 시장에 줄 수 있는 임팩트를 우선하며, 장기적인 관점에서 효과와 품질을 고려합니다. 프로덕트를 만드는 사람들도 프로덕트와 함께 성장하기를 지향하게 되었습니다.
사람들이 이 프로덕트를 사용함으로써 위대한 일을 할 수 있게 하자. 이런 프로덕트를 만드는 사람들도 대단한 사람들이 만드는 위대한 일을 하고 있다는 것을 인식하게 하자. 프로덕트로 관점을 전환하게 되면서 프로덕트를 만드는 사람들이 지향하게 된 정신입니다.
(그림 출처: https://agilemanifesto.org/iso/ko/manifesto.html)
<aside> 💡 과제 : 위의 그림 출처인 웹사이트에 접속하여 애자일 소프트웨어 개발 선언의 4가지 가치와 12가지 원칙을 읽어봅시다.
</aside>
선구적인 소프트웨어 엔지니어들을 중심으로 애자일 소프트웨어 개발 선언문이 작성되어 전파됩니다. 2001년 미국에서 소프트웨어 개발 역할을 중심으로 17명의 업계 사람들이 모여서 어떻게 하면 우리의 업무 과정과 결과가 더 좋은 가치를 가질 수 있을지 고민하고 논의한 결과 입니다. 소프트웨어 업계에서는 애자일 선언 이후 일 하는 방식의 개선과 프로덕트의 가치가 부상하는 패러다임의 변화가 발생합니다.
기존의 사업 부서 주도로 개발이 진행되던 프로젝트 방식에서 개발 부서가 주도하고 프로덕트 자체가 사업을 리드하는 프로덕트 방식으로 중심이 이동하게 됩니다. 그 이후부터 지금까지를 살펴보면 소프트웨어 / 테크 기업과 디지털 프로덕트가 세상의 변화를 주도해 오고 있습니다.
기업 내에서도 프로덕트 단위 별로 소통, 계획, 개발, 출시 까지 전체적인 수명주기를 관리하고 경영하는 역할이 필요하게 되었습니다. 이 역할을 하는 것이 프로덕트 매니저 입니다. 조직의 성격에 따라 가능한만큼의 자율권을 가지고 프로덕트를 중심으로 사업을 리드하며 고객, 이해관계자, 사업 부서, 엔지니어링 부서를 통합적으로 아우르는 역할이 부상한 것입니다.
<aside> 💡 실제 업무 환경에서는 프로덕트 조직도 여러 프로젝트를 수행하면서 프로덕트를 개발해 나갑니다. 이 때의 프로젝트는 프로덕트의 일부분, 하나의 목표를 달성하기 위해 계획하여 진행되고, 여러 프로젝트들이 동시에 또는 연속적으로 발생할 수 있습니다. 프로덕트 조직의 프로젝트는 이 챕터 앞부분에서 언급한 프로젝트와는 조금 다른 성격으로 볼 수 있습니다. 이 챕터에서 프로덕트와 대비되는 개념으로 언급한 ‘프로젝트’는 개발 조직이 기업 내부에 없어서 외주 개발사에게 개발을 의뢰하는 상황으로 이해하시면 좋겠습니다.
</aside>