Search
📕

프로덕트 개념의 탄생과 애자일 패러다임

토글 ( )을 클릭하여, 교육자료의 목차를 확인하고 빠른 이동을 할 수 있습니다. (전체 토글을 열고닫는 단축키 - Windows : Ctrl + alt + t / Mac : ⌘ + ⌥ + t )
목차 확인하기

1. 프로젝트에서 프로덕트로 전환

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

2. 애자일 이해하기

위 그림의 각 항목을 보시면, 왜 애자일을 하게 되었고, 애자일을 기반으로 일 하는 방식과 애자일 상태가 되었다는 것의 의미를 함축적으로 이해할 수 있습니다.

왜 애자일을 하는가?

애자일은 우리가 대상에 대해서 아는 상태, 아직 모른다는 것을 아는 상태, 무엇이 더 존재하는지 지금은 알 수 없는 상태로 구분된다고 할 때, 이 대상에 대해서 학습하면서 만들어 가기 위해 필요한 사고방식 입니다. 프로덕트, 특히 디지털 프로덕트를 개발한다는 것은 이러한 대상에 속합니다. 현대와 같이 빠른 속도로 시장, 환경, 고객 요구, 기술이 변하는 상황에서는 더욱 미지의 영역이 크고 지속적인 민첩한 변화가 필요하기 때문입니다.
기존의 긴 개발주기를 가지고 있는 방식은 이러한 환경과 프로덕트 개발에 적합하지 않습니다. 그래서 목표를 달성하기 위해 개발기간과 할 일을 작은 단위로 나누어 아는 만큼 반복점진적으로 개발하는 애자일 기반의 개발 방식이 더 효과적인 프로덕트를 만드는 데에 적합합니다. 또한 작동하는 프로덕트 결과물을 이른 시점에 만들어 낼 수 있어서, 내부적으로 또는 시장에서 직접적인 피드백을 얻을 수 있습니다.

일 하는 방식은 어떻게 하는가?

작은 단위의 개발주기는 파악이 가능한 만큼 계획을 수립하고, 계획에 따라 실행해서 결과물을 만들고, 결과물을 분석하고 검토하여 학습한 것을 다음 개발주기에 반영하는 활동의 연결된 원입니다. 애자일 팀은 프로덕트 개발에 필요한 모든 역할 구성원이 한 팀이 되어 (교차기능 팀), 지속적인 학습과 하나의 목표 지향을 하는 과정에서 T자형 인재가 되는 것을 지향합니다.
애자일의 가치를 현대적으로 재해석한 모던 애자일은 1) 프로덕트의 유저와 만드는 사람들을 위대하게 만들자. 2) 지속적으로 가치를 담아 유저에게 전달하자. 3) 프로덕트 개발조직이 심리적 안전감을 갖고 용기있게 일하게 환경을 조성하자. 4) 빠르게 가설을 실험하고 분석을 통해 학습한 것을 반복하면서 지속적으로 개선하자. 라고 애자일 개념을 정리하고 있습니다.

애자일 한 상태가 되었다는 의미는 무엇인가?

애자일은 Agile 이라는 형용사를 대문자 A로 시작하여 마치 고유명사 처럼 쓰고 말하게 되었는데요. 이 애자일을 한다는 것 Doing Agile 과 애자일한 상태가 된다는 것 Being Agile 으로 구분하여 생각해 볼 수 있습니다. 하는 것의 애자일은 애자일을 실천하기 위한 방법론, 프레임워크, 프랙티스(실천법, 사례)를 행하는 것을 의미합니다. 된다는 것의 애자일은 애자일의 가치와 원칙을 이해하고 체득하여 애자일과 같은 방식으로 사고하고 행동하고 말하게 되는 경지에 이르는 것입니다. 애자일 상태가 된다는 것의 의미는 애자일 선언이 의미하는 바 뿐만 아니라 애자일을 왜 하는지에 대한 그림이 설명하는 배경, 큰 대상물을 작은 단위로 나누어 다룰 수 있게 되는 것, 지속적으로 학습하고 개선을 추구하는 장인정신, 심리적 안전감을 지키기 위해 공감하고 존중하되 용기있는 말하기 와 같은 애자일의 근본적인 마인드셋을 갖추는 것입니다. 애자일 상태가 된 사람들은 자신들만의 애자일 프랙티스를 새로 만들어 나갈 수도 있을 것입니다.
애자일에 대해 알아보다 보면, 애자일 방법론 이라는 개발 프로세스를 의미하는 것으로 보입니다. 실제 업무 현장에서는 애자일이 지향하는 유연하게 여러 사람이 협업을 하면서 효과적인 목표를 품질 높은 개발 결과물로 만들어 내는 과정을 지속하기 위해서는 일 하는 문화와 사람이 중요하다는 것을 알게 됩니다. 그래서 애자일을 실현하는 것은 쉽지 않습니다. 하지만 애자일을 추구하면서 발견하는 문제로 보이는 이슈들은 우리가 기존에 가지고 있었던 또는 방치하고 있었던 점들이 가시화 되는 것이고, 대부분 애자일의 문제가 아닐 것입니다. 프로덕트 자체와 일 하는 방식, 문화에 지속적인 개선을 추구하는 것이 애자일을 실현하는 유일한 방안입니다. 또한 이것은 애자일의 어떤 방법론, 기술, 프랙티스, 프레임워크를 적용했다고 해서 애자일이 실현된 것이 아님을 의미합니다.

3. 애자일 조직의 특징과 일 하는 방식

애자일 조직의 프랙티스, 애자일 방법론, 애자일 프레임워크 중 주요한 / 관련된 키워드들을 살펴보겠습니다.
•
작은 규모의 팀: 애자일 조직에서는 일 하는 단위의 팀을 작은 규모로 나누고, 그 팀은 하나의 목표를 가지고 이를 달성하기 위해 일 하도록 합니다. 하나의 프로덕트 또는 큰 프로덕트의 한 부분을 담당한다고 볼 수도 있습니다. 이러한 규모의 팀을 스포티파이 (애자일을 기반으로 성공적으로 성장한 음악 재생 / 음원 프로덕트 스타트업) 사례에서는 ‘스쿼드’ 라고 합니다. 아마존 (미국의 대표적인 이커머스 중심 빅테크 기업) 사례에서는 ‘피자 두 판 팀’ 이라고 했습니다. 애자일을 실행하는 프레임워크 중 많이 활용하는 스크럼 프레임워크에서는 ‘스크럼 팀’ 이라고 합니다. 3~9 명 사이 정도의 규모로 작은 목적 지향 팀 입니다.
•
자율경영 Self-management: 애자일 팀은 충분한 동기와 기술을 가진 사람들로 구성합니다. 이들에게는 관리보다는 일을 잘 할 수 있는 권한과 환경을 제공합니다. 팀은 자율적으로 담당하는 프로덕트를 진화시켜 나가는 한편, 팀이 일 하는 방식과 일의 진척도 팀원 모두 스스로 결정하고 관리합니다. 그렇기 때문에 애자일 팀을 자율경영 팀이라 할 수 있게 됩니다.
•
교차기능 Cross-functional: 전통적인 조직에서는 역할이 같은 사람을 한 팀으로 묶었습니다. 예를 들면, 기획팀, 개발팀, 디자인팀과 같이 말이죠. 애자일 팀은 한 팀이 같은 목표를 달성하는데 필요한 모든 기술을 갖춘 팀으로 구성합니다. 그래서 여러 필요한 역할자들을 한 팀으로 묶습니다. 이를 여러 역할 기능이 전통적인 조직도 위에 교차한 묶음이라 하여 교차기능 팀이라 합니다. 교차기능 팀은 각자의 역할만 하는 개인의 집단이 아닌, 각자의 전문적인 역량을 중심으로 서로 협업을 통해 가치있는 프로덕트를 완성하는데 필요한 모든 일을 함께 하는 원팀을 지향합니다.
•
린 생산방식 Lean Production: 린은 낭비요소를 최소화 하여 적시에 시장에 제품을 출시하는 도요타 (일본의 최대 자동차 제조기업)의 생산방식에서 탄생했습니다. 리드타임 Lead time (할 일이 생성되어서 부터 - 주문, 할 일을 완료할 때까지 - 출시)를 최소화 하려는 노력입니다. 초과생산, 재고, 운송, 동작, 대기, 결함, 과도한 프로세스 7가지 분야에서 낭비를 줄입니다. 소프트웨어 개발에도 적용하여 낭비 요소를 최소화하고 리드타임을 짧게 합니다.
•
린 스타트업 Lean Startup: 스타트업에 적합한 전략으로 이른 시점에 가설을 제품으로 만들고 검증하여 학습한 것을 적용하는 것을 반복하는 것입니다. 스타트업의 기업 상황에서 인력과 자원이 풍부하지 않고, 새로운 제품이나 시장을 개척하는 만큼 아이디어를 빠르게 실현시킨 후 지속적인 개선을 통해 프로덕트의 생존과 성공 가능성을 높이는 방안입니다. 이 전략에서 중요한 최소기능제품 Minimum Viable Product - MVP 기법이 탄생하였습니다.
•
칸반 Kanban: 칸반은 큰 보드에 업무흐름을 시작부터 완료 단계까지 표시하고, 각 단계를 시각화하여 각 업무의 흐름이 원활하도록 유지하는 방법입니다. 기본적으로는 업무흐름을 할 일 To-do / 진행 중 In-Progress 또는 Doing / 완료 Done 의 세가지 상태로 구분하는데, 프로덕트의 실제 개발 흐름에 맞추어 열을 추가할 수 있습니다. 이 때, 진행 중 열에 WIP Limit 이라는 진행 중 열에 둘 수 있는 최대 할 일의 갯수에 제한을 두어서, 진행하는 업무를 우선적으로 빠르게 완료까지 진행하는 것에 집중하게 합니다. 할 일이 다음 열의 단계로 이동하여 작업자가 담당하는 할 일이 없어지면, 작업자는 이전 단계의 열의 최상단(가장 우선순위가 높은 할 일이 최상단에 위치함)에 있는 할 일을 당겨와서 Pull 진행합니다.
•
스크럼 Scrum: 스크럼은 경험주의 기반의 프로덕트 개발 협업 프레임워크 입니다. 계획 - 실행 - 적응 단계를 거치면서 경험한 것을 기반으로 지속적인 개선을 하는 틀을 제시합니다. 스크럼에서 짧은 주기의 반복적인 개발 주기를 스프린트 라고 하고, 스프린트를 반복할 때 진행하는 스크럼 이벤트 4가지 (스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고)가 있습니다. 스크럼을 실행하는 스크럼 팀에는 3가지 역할 (프로덕트 오너, 개발자들, 스크럼 마스터)이 있습니다. 이 팀은 스프린트를 진행하는 과정에서 3가지 산출물 (프로덕트 백로그, 스프린트 백로그, 개발 증가분)을 만들게 됩니다. 또한 스크럼 팀은 5가지 지향하는 정신적 가치 (약속, 집중, 열린마음, 존중, 용기)를 근본적인 마인드셋으로 갖추어야 합니다. ⇒ 스크럼 프레임워크에 대해서는 심화 학습 항목으로 더 자세하게 다룹니다.
애자일을 애자일 하게 익히기! 애자일과 관련된 키워드와 개념들은 경험과 실천 없이 온전히 이해하는 것은 쉽지 않습니다. 이론에 나온 단어와 정의 등을 외우는 식으로 학습하기 보다는 경험을 기반으로 작성된 글 읽기와 실전 경험을 반복하면서 다음 경험 자체를 개선해 나가는 여정을 해보세요.
다음 주제 →
Copyright 2022. ⓒ TeamSparta All rights reserved.
Made with