2021. 11. 18. 21:42ㆍPM 성장 스토리/Product
우리는 애자일이 최선인 것인가?
요즘 IT 업계에서 핫하게 떠오르는 '애자일'이라는 단어는 한 번쯤 들어봤을 것이다. 특히 요즘 스타트업에서는 애자일 방법론을 이용하는 것이 대세 아닌 대세로 이어지고 있다. 그럼 그들은 왜 애자일 방법론을 사용하는 것일까?
효율적이고 유연하게 목표에 다가가자
지금처럼 애자일이 보편화되기 전 기존 IT업계는 일명 '폭포수 모델'(Waterfall model)이라는 전통적 개발 방법론을 사용해 왔다.
폭포수 방법론은 Waterfall이라는 뜻처럼 '요구 분석 → 기획 → 디자인 → 개발 → 테스트 → 출시' 프로세스를 위에서 아래로 폭포처럼 떨어지는 방식을 의미한다. 하지만 시간이 지나면서 시장이 변하는 속도는 빨라지고 고객들의 니즈도 빠르게 변하면서 오랫동안 이어져 온 워터풀 방식에 문제가 생기게 된다.
핵심 문제는 세상이 빠르게 변하고 고객이 원하는 제품의 트렌드도 정말 빠르게 변화되고 있다 보니 워터폴 방식의 요구분석, 기획 단계에서 진행했던 일련의 과정들이 고객의 요구를 100% 충족하는 경우가 거의 없다는 점이다. 기업은 이러한 기회비용 낭비를 방지하기 위해 고객의 요구 사항들을 민첩하고 기민하게 충족시켜 개발하는 것이 오히려 효율적이라고 판단하여 생각해낸 방법이 '애자일' 방법론이다.
애자일의 특징은 개발을 좀 더 작은 단위로 구성하여 완성을 목표로 하는 것이 아닌, 최소한의 MVP를 개발하여 직접 고객에게 선보이고 피드백을 빠르게 전달받아 수정이나 이슈 처리에 대한 기민한 대응을 하자는 것이라고 볼 수 있다. 물론 해당 방법이 완벽하지는 않지만 빠르게 변하는 시장에서 완벽을 추구하며 제품을 개발하다 보면 시대에 뒤쳐질 수 있고, 고객이 정확히 무엇을 원하는지 알 수 없기에 고객의 요구사항을 증명할 수 있는 개발을 통해 피드백을 받고 요구사항을 반영하며 개발하는 것이 더욱 효율적이고 유연하게 목표에 도달할 수 있다고 판단한 것이다.
무엇이 애자일 스러운가? (feat. 스크럼, 칸반)
만약 기업 입장에서 앞서 설명한 애자일 방법론을 사용하고자 한다면 어떻게 애자일을 도입할 수 있을지 고민할 것이다. 단순히 "우리는 애자일이야!"라고 선언함과 동시에 애자일 조직으로 바뀌는 게 절대 아니다. 우선 애자일을 이해하기 위해서는 다양한 업무 방식에 대한 학습이 필요하다.
본인은 이번 포스팅에서 애자일에 대한 이론보다는 실제 애자일 방법론이 어떻게 이용되고 어떠한 프레임워크를 통해 진행되는지를 설명하고 싶다. 그렇다면 글을 읽는 독자는 애자일 방법론에서 대표적으로 손꼽히는 스크럼과 칸반에 대해 이해하고, 어떤 핵심 요소가 필요한지와 알게 된다면 애자일에 대해 보다 실무적으로 판단할 수 있는 계기가 되지 않을까 생각한다.
우리는 '결과'를 위해 움직인다_by. 스크럼
애자일 방법론에 대표적으로 뽑히는 스크럼을 설명하자면 5~9명으로 구성되는 소규모의 다기능 팀이 제품 개발을 완성하기 위해 스프린트(sprint)라고 불리는 업무 주기를 반복하는 팀이라고 볼 수 있다. 혹시 스크럼에 대한 이론적 정의가 필요하다면 '해당 글'에서 스크럼에 이론을 기재했으니 참고하길 바란다.
위 이미지는 스프린트라는 반복적인 개발 주기를 설명한 것이다. '스프린트'라는 뜻을 모른다면 이해하기 힘들 수 있는데, 스프린트의 사전적 의미는 아래와 같다.
스프린트(sprint): 육상 경기·수영 경기·스피드 스케이트 등의 단거리 레이스. 또는, 단거리를 전력(全力)으로 행하는 질주(疾走)나 역영(力泳).
스프린트는 즉 위와 같이 정의한 사전적 의미를 업무에 대입하여 매우 크지 않은 태스크(단거리)를 적당한 기간 동안 집중해서 전력 질주하듯 업무를 수행하는 것을 스프린트라고 생각하면 된다.
그럼 스프린트를 운영하기 위해서는 최소한의 인원이 필요한데, 대표적으로 제품 책임자(Product Owner), 스크럼 마스터(Scrim Master), 개발자(Developer)를 이야기할 수 있다. (회사 사정에 따라 다른 인원이 충원될 수 있음)
프로덕트를 책임지는 PM의 중요성
스프린트 팀은 모든 구성원에 역할이 정말 중요하다. P.O는 고객을 대변하는 비즈니스 담당자로서 비즈니스 입장에서 팀을 총괄하고 기획할 것이고, 개발자 역시 기술적인 문제를 해결하기 위해 노력할 것이다.
그렇다면 본인과 같은 PM(Product Manager)의 역할은 무엇일까? PO와 직무 이름이 비슷하여 겹치는 업무가 있을 수 있지만 PM의 핵심 역할은 팀이 해결하고자 하는 문제, 즉 우리 제품을 이용하는 유저가 겪는 문제를 정의해야 한다. 그다음 해당 문제를 유저 입장에서 생각할 수 있는 '유저 스토리'에 근거하여 작성한 뒤 PM은 팀이 해당 문제 해결을 위해 해야 할 일을 '우선순위'로 분간하여 공유하는 역할을 한다고 생각한다. 그렇기에 PM은 프로젝트에 대해 가장 깊은 이해가 필요하고 팀이 차질 없이 일을 진행할 수 있도록 도와야 한다.
스프린트의 중요한 요소
스크럼은 작은 개발팀, 짧은 개발 주기, 팀의 집중력과 생산성을 유지시켜 점진적으로 제품(소프트웨어)을 산출하는 대표적인 애자일 방법론이라고 할 수 있다. 그렇다면 스프린트는 스크럼 팀을 통해 Product Backlog를 바탕으로 반복적인 개발 주기를 지정해서 제품을 구현이나 문제를 '빠르게' 해결해 나가는 것이라고 할 수 있다. 그럼 스크럼 팀에 PM으로 소속되어 스프린트를 실행한다면 중요한 요소는 무엇이 있을까?
- 업무 진행에 차질이 없도록 상세한 백로그는 필수
- 완벽함보다는 스프린트 기한 안에 목표를 달성하는 것!
- 구성원 업무 진행 과정에 대한 투명한 공유
스프린트 팀은 서두에서 이야기한 것처럼 '목표'를 향해 빠르게 돌진하는 팀이다. 그렇기에 어떠한 방해 요소가 발생하여 진행에 차질이 생기고 혼란을 야기하게 된다면 본질을 상실할 수 있다. 스프린트 팀을 관리하는 PO, PM로서 모든 구성원이 업무를 차질없이 달려 나갈 수 있도록 사전에 확실한 백로그는 필수이고 구성원 모두가 '목표'를 인지하고 과정을 공유할 수 있어야 한다.
우리가 핵심으로 해결해야 할 문제를 공유한다_by. 칸반
Kanban은 일본어로‘시각적 신호’를 의미한다. 즉 칸반은 칸반 보드로 시각화되고 각각 단계는 열로 표시하여 구성원 전체가 프로세스를 이해하고 백로그에 따라 자유롭게 내용을 공유하고 수정할 수 있는 프로세스를 의미한다.
위 이미지는 칸반 보드를 단적인 예로 나타내고 있는 것이며, 대표적으로 To do- 해야할 일 / Doing - 진행 중인 업무 / Done - 완료된 업무로 구분할 수 있다. 스크럼은 스프린트로 인해 이용할 수 있는 작업 시간을 제한하여 생산성을 제어하는 반면, 칸반 보드에 핵심은 동시에 처리할 수 있는 이슈의 수를 제한함으로써 생산성과 속도(velocity)를 제어한다는 것에 있다.
우리는 이제 알 수 있다 "스크럼과 칸반의 차이"
그럼 스크럼과 칸반은 도대체 어떠한 차이가 있는 것일까? 앞서 설명한 것만 보면 단순해야 할 일을 시각화하고 공유하는 것 이외에는 큰 차이를 느끼지 못했을 것이다. 하지만 스크럼과 칸반은 명확한 차이가 존재한다.
이슈에 대한 유동적 VS 제한적
스크럼과 칸반은 비슷하지만 명확한 차이가 있다. 그중에서 대표적으로 이야기할 수 있는 것은 이슈 대처 방안이다. 우리는 업무를 하면서 아무리 사전 계획을 완벽히 세운다고 해도 생각하지 못했던 문제나 갑작스러운 이슈 상황이 생길 수 있다. 여기서 스크럼과 칸반은 이슈를 대처하는 방식이 명확하게 대비된다.
'스크럼'은 이슈로 인해 Backlog(우선순위)를 절대 변경하지 않는다.
앞서 스프린트 팀을 설명하면서 가장 강조했던 부분은 '목표'를 향해 달려 나가는 팀이라고 설명했다. 그럼 사전에 계획한 우선순위 업무들을 빠르게 헤쳐나가면서 정해진 시간 안에 처리하는 것이 가장 중요할 것이다. 그런데 열심히 달려 나가는 도중에 생각하지 못했던 이슈 상황이 생겼다는 이유로 우선순위를 변경해 버린다면 목표를 달성하는 것에 있어 큰 어려움이 생길 것이다. 그렇기 때문에 스프린트 팀에서는 이슈 상황을 절대 백로그에 넣지 않고, 다음 스프린트 턴에 넣는 방식을 고수한다.
'칸반'은 WIP (Work In Progress) 제한이 핵심이다!
칸반과 스크럼의 가장 두드러지는 차이는 스프린트 기간이 정해져 있지 않다는 것이다. 칸반은 스프린트처럼 약속된 종료일이 없기에 벅차게 달려 나갈 필요는 없다. 그럼 칸반 보드에 있는 백로그에는 생기는 이슈마다 모든 것을 유동적을 다 넣고 업무를 헤쳐나가면 되는 것일까? 소제목에 설명한 '칸반에 핵심은 WIP (Work In Progress) 제한'이라고 했던 것처럼 In Progress, 즉 현재 진행 중인 업무에 제한을 둔다는 뜻이다. 즉 스프린트처럼 중간에 이슈 사항을 무조건 거절하는 것은 아니지만, 한번 이슈를 처리하기 시작하면 해당 이슈를 끝낸 후 다음 이슈를 확인하고 업무에 적용되는 프로세스 방식이다. 이는 수많은 In Progress가 생기면 한 가지 업무에 집중할 수 없고 일명 '멀티 태스킹' 상황이 발생하여 업무 질이 떨어질 수 있음을 방지하고자 한 것 같다.
그럼 우리가 필요한 방법은 무엇인가?
앞서 칸반과 스크럼 프레임워크를 설명하고 각 차이점을 이야기했다. 만약 본인이 진행하는 업무 방식이 기한이 짧고 빠르게 진행되어야 한다면 스크럼 방식을 추천하고, 지속적인 업무를 다루며 개발 프로세스(데브옵스)까지 다뤄야 하는 상황이라면 칸반을 이용하는 것도 좋을 것이다.
우리는 도구의 의미를 알아야 한다
우린 PM이다. 모든 기업이 애자일 방법론을 선호한다고 해서 애자일 방법론이 무조건 옳다고 볼 수 없다. 스크럼, 칸반 또한 애자일 방법론에 사용되는 일종의 프레임워크, 즉 '도구'에 불과하다. 우리는 '도구'를 사용하는 목적을 이해하고 이것을 통해 얻고자 하는 것에 집중해야지, 도구를 사용하는 것에 대한 매너리즘에 빠지면 안 된다.
쉽게 설명하자면 포크, 나이프, 젓가락은 밥을 먹기 위해 사용하는 도구다. 도구를 사용하는 이유는 각자 무언가를 얻기 위해 사용하는 것이지 어떤 도구를 사용한다고 하여 그것이 잘못됐거나 옳지 않다고 비판하는 것은 잘못된 것이다. 우리는 PM으로서 비판이 아닌 이해를 통해 도구를 비교하고 적용할 줄 아는 인사이트를 가져야 한다.
관련 자료
https://kood-dev.tistory.com/2
https://ko.myservername.com/versionone-tutorial-all-one-agile-project-management-tool-guide
https://brunch.co.kr/@seaweed/3
항상 창의적인 크레이티브를 만들어내기 위해 노력하는 기획자입니다
제안은 언제나 환영입니다
Creative Owner l wogud544@naver.com
'PM 성장 스토리 > Product' 카테고리의 다른 글
| [코드스테이츠 PMB 8기] 프로젝트 관리툴 지라(Jira)로 애자일 협업하기 (0) | 2021.11.22 |
|---|---|
| [코드스테이츠 PMB 8기] PM으로서 제품 개선을 위해 이해관계자와 해야 할 일 (0) | 2021.11.19 |
| [코드스테이츠 PMB 8기] 카톡 멀티 프로필 '스크럼' 방식으로 레벨업 시키기 (0) | 2021.11.17 |
| [코드스테이츠 PMB 8기] 기술 블로그만 봐도 회사의 '문화'를 알 수 있다 (feat. 당근마켓) (0) | 2021.11.15 |
| [코드스테이츠 PMB 8기] 기획자 입장에서 API, Open API 이해하기 (0) | 2021.11.12 |