애자일 이론? (1)-이론적 경험

[제품을 성공시키는 프로덕트의 비밀 참고 및 발최 포스팅]

"일단 빠르게 실험하고 고객 피드백 볼까요?"

 

 

PM 채용 공고에서 자주 언급되는 애자일

 

애자일은 IT 프로젝트에서 사용되는 개발 방법론 중 하나로, 많은 회사들이 애자일 방식을 채택하고 있습니다. 왜냐하면 애자일 방식이 성공 확률을 높이기 때문입니다. 거창한 것을 빼고 일단 빠르게 만들어 배포하여 고객의반응을 살피는 것입니다. 그럼 고객이 이 제품을 원하는지, 원하지 않는 다면 어째서 원하지 않는지. 바로바로 확인 할 수 있거든요.

 

물론 처음부터 완벽한 프로덕트를 만들어 시장에 배포할 수 있다면 좋겠지만 그건 시간이 너무 오래 걸립니다. 경쟁이 심한 시장에서 그건 낭비이죠. 그리고 만약 그렇게 품을 많이 들여 완벽에 가까운 프로덕트를 출시했는데 시장의 반응이 좋지 않다면 그것이야말로 너무 완벽한 실패니까요. 

 

그래서 완벽한 프로덕트를 만들기 위해 오랜 시간을 소모하기 보단, 빠른 속도로 처리하는 것을 기업들은 선호하게 된 것입니다. 이것이 실제로 효과가 있는 해결책인지 알려면 문제해결이라는 관점에 충실한 mvp를 만들고 고객 피드백을 통해 솔루션을 검증한 뒤 빠르게 개선해나가는 것이 낫는 것입니다.

 

---

방법론 2가지

방법론을 왜 알아야하는가?
PM이 방법론을 잘 알면 프로젝트를 성공적으로 이끌 가능성이 높다는 점에서, 방법론에 대한 이해는 중요합니다. 각 방법론은 프로젝트의 성격과 목표에 맞게 선택되어야 하므로, PM이 방법론을 적절히 활용하면 프로젝트의 효율성과 품질을 높일 수 있습니다.

 

애자일(Agile)과 워터풀(Waterfall)비교

워터폴은 순차적으로 한 단계씩 진행하며, 애자일은 반복적이고 점진적인 개발을 통해 유연하게 변화에 대응합니다. 워터폴은 폭포처럼 각 단계를 끝낸 후 다음 단계로 넘어가는 형태로, 애자일은 반복적인 주기(스프린트)를 통해 점진적으로 개발이 이루어집니다.

항목	애자일	워터풀
프로젝트 시작 시 요구 사항	초기 요구 사항이 불완전해도 시작 가능	초기 요구 사항을 명확히 정의하고 시작
계획	요구사항은 계속 진화하며, 계획은 유동적이고 조정	초기 단계에서 모든 요구사항과 계획을 상세히 수립
개발 주기	반복적이고 점진적인 방식, 작은 주기(스프린트)로 개발.  짧은 개발 주기(스프린트), 주기적인 릴리즈	단계별로 순차적으로 진행.  긴 개발 주기, 한 번에 전체 프로젝트 진행
유연성	요구사항 변경에 빠르게 대응 가능.	변경이 어려움. 이미 완료된 단계로 돌아가려면 큰 비용과 시간 소모.
고객 참여	스프린트마다 고객의 피드백을 받고, 지속적으로 반영.	초기 요구사항 정의 이후 고객 참여가 제한적.
문서화	최소한의 문서화  팀과의 의사소통에 집중	상세한 문서 작성
운영업무	시작일과 마감일이 없는 업무, 특정 목표를 위한 일회성/한정된 기간 동안 진행	반복적이고 루틴화된 업무, 지속적으로 관리 및 유지되는 업무
업무 예시	신규 기능 개발, 서비스 개선, 고객지원(CX) 문제 해결을 위한 기능 개발	운영 및 유지보수, 데이터 분석, 고객 경험(CX) 관리

 

1. 워터풀 방식:
   • 과정: 바퀴 → 차체 → 자동차
   • 특징: 처음부터 완성된 목표(즉, 자동차)를 만들기 위해 단계별로 차근차근 진행합니다. 각 단계가 끝날 때까지 이전 단계를 완료해야 다음 단계로 넘어갈 수 있습니다.
2. 애자일 방식:
   • 과정: 최소 기능의 보드 → 킥보드 → 자전거 → 오토바이 → 자동차
   • 특징: 최소한의 기능을 가진 제품부터 시작하여 점차적으로 발전시켜 나가는 방식입니다. 초기에는 간단한 형태의 제품을 만든 후, 사용자의 피드백을 반영해 점진적으로 개선하고 확장합니다.

결론: 애자일 방식은 **최소 기능을 가진 제품(MVP)**을 빠르게 개발하여, 점차적으로 기능을 추가하며 제품을 발전시킵니다. 반면, 워터풀 방식은 처음부터 완성된 목표를 설정하고, 그 목표를 이루기 위해 단계별로 진행합니다.

 

애자일 방식이 필요한 이유

기업들은 왜 애자일을 선택할까?
✔ 빠른 출시 → 시장과 고객 반응 확인
✔ 유연한 대응 → 고객 요구사항 반영
✔ MVP 도입 → 최소 기능부터 검증 가능

 

 

우아한 형제들 배민 외식업 광장 '장사캘린더' 오픈 사례

 

배경배민에 입점한 외식업 사장님들이 사용하고 있는 광장이라는 플랫폼에서 장사캘린더 기능을 추가하게 된 이유는, 사장님들이 놓치지 말아야 할 중요한 일정(세금 일정, 위생교육 일정, 지원 사업 신청 일자 등)을 모아서 제공하는 것이었습니다.
장사캘린더 개발 목적장사캘린더의 목표는 사장님들을 위한 콘텐츠 포털로서, 사장님들이 중요한 정보를 쉽게 확인하고 활용할 수 있도록 돕는 것이었습니다.

---

문제점 및 해결 과정
문제 발생콘텐츠 조회수가 높을 때 클릭 수가 증가하고, 조회수가 낮을 때 클릭률이 낮아지며, 콘텐츠 주제에 따라 결과가 달라지는 상황이 발생했습니다. 이에 따라 매일 주제가 바뀌는 방식보다는, 사장님들이 자주 이용할 수 있는 기능을 추가하는 방향으로 전환을 결심했습니다.주간 콘텐츠 발행매주 월요일마다 사장님들에게 중요한 일정을 콘텐츠화하여 발행하였습니다. 이 콘텐츠는 흥행 콘텐츠와 사장님들의 만족도가 높았던 콘텐츠를 바탕으로 진행되었습니다.분석 결과사장님들은 돈이 들어오는 콘텐츠에 관심이 많았습니다. 예를 들어, 대출, 지원 사업 관련 콘텐츠는 조회수가 높았습니다.콘텐츠는 짧고 요약된 형식이 더 인기가 있었습니다. 긴 본문보다는 간결한 요약이 선호되었습니다.경쟁사 분석기존의 시장 플레이어들은 지원 사업을 골라볼 수 있는 서비스를 제공했지만, 대부분 소상공인 전체를 대상으로 하여 외식업 관련 정보는 찾기 어려웠습니다. 또한, 사장님들은 어려운 용어나 까다로운 조건을 가진 공고문에 어려움을 느꼈습니다.

---

애자일 방식 적용
문제 해결을 위한 애자일 접근
애자일 방식의 핵심은 빠르게 시도하고 배우는 것입니다. 배민의 PM은 장사캘린더가 사장님들에게 유용할 것이라는 가설을 세운 후, 빠르게 출시하여 사용자 반응을 통해 가설을 검증하고 인사이트를 반영하기로 했습니다.**최소 기능 제품(MVP)**은 완벽한 제품을 만드는 것이 아니라, 사장님들의 반응을 얻을 수 있는 핵심 기능을 빠르게 제공하여 피드백을 얻는 것이 중요했습니다. 이를 통해 가설을 검증하고, 필요한 개선 사항을 반영할 수 있었습니다.

---

MVP 범위와 우선순위의 중요성
어려움
MVP의 범위에 대해 팀 내에서 의견이 나뉘었습니다.의견 1: "굴러가기만 하면 되니까 지금 출시하자."의견 2: "아니, 이 정도는 있어야 한다. 완성도가 떨어지면 안 된다."결론: MVP의 범위와 우선순위를 정확하게 정의하는 것이 중요하다는 점을 인식하게 되었습니다. 애자일 방식으로 일할 때, 제품의 최소한의 기능을 빠르게 제공하면서도, 사용자 반응을 바탕으로 점진적으로 개선해 나가는 접근이 필요했습니다.

---

결론
애자일 방식으로 MVP의 범위와 우선순위를 명확하게 설정하고, 빠르게 피드백을 받아 지속적으로 개선하는 과정이 중요하다는 점을 다시 한 번 확인할 수 있었습니다. 장사캘린더는 사장님들에게 유용한 기능을 제공하면서도, 애자일 방식의 접근을 통해 점진적으로 개선되어 갔습니다.

 

애자일과 워터풀은 각기 다른 개발 방법론으로, 각자의 장단점이 존재합니다. 어느 것이 더 좋은지는 프로젝트의 성격과 요구 사항에 따라 다릅니다. 두 방식의 차이를 잘 이해하면, 각 상황에 맞는 방법을 선택할 수 있습니다.

 

 

 

 

 

 

---

 

상황에 따른 애자일과 워터풀 방법론의 사용 경우

1. 애자일(Agile)

주요 특징:

• 유연성: 요구 사항 변화에 쉽게 적응 가능하고, 고객의 피드백을 반영하여 제품을 개선할 수 있음.
• 빠른 출시: 주기적인 릴리스와 피드백을 통해 제품을 점진적으로 개선함.
• 협업 중심: 팀원들 간의 협업과 의사소통을 중시.
• 단점: 자주 요구사항이 바뀌기 때문에 관리가 복잡할 수 있음. 장기적인 계획이 어려움.

애자일이 적합한 경우:

• 시장의 변화가 빠르고, 제품을 출시하여 피드백을 받고 개선하는 것이 중요할 때.
• 고객의 요구가 자주 변하고, 그에 맞춰 빠르게 대응해야 할 때.
• 경쟁이 치열하고 빠른 개발이 필요할 때.

예시: 모바일 애플리케이션, 스타트업 제품 개발 등.

2. 워터풀(Waterfall)

주요 특징:

• 명확한 요구사항: 프로젝트 초기 단계에서 요구 사항이 명확하고 변하지 않을 때 적합.
• 단계적 진행: 각 단계가 완료된 후 다음 단계로 넘어가며, 명확한 데드라인과 예측 가능한 일정 관리가 가능.
• 품질 보장: 예측 가능성이 높고, 각 단계에서 품질을 점검하며 진행하므로 품질 관리가 용이.
• 단점: 요구사항이 변경되기 어렵고, 변경 시 일정에 큰 영향을 미칠 수 있음.

워터풀 방식이 적합한 경우:

• 명확한 요구사항과 정해진 데드라인이 있고, 품질에 신경 써야 할 때.
• 예를 들어 정부 프로젝트나 대형 인프라 구축 프로젝트 등.

예시: 정부의 온라인 투표 시스템, 대형 금융 시스템 등.

3. 애자일이 주목받는 이유

2000년대 초반부터 IT 개발 환경이 빠르게 변화하면서, 기업들은 시장 출시 시간(Time-to-Market)이 중요한 경쟁 요소로 떠오르게 되었습니다. 기존의 워터풀 방식은 개발 과정에서 요구 사항 변경에 대한 유연성이 부족하고, 긴 개발 주기와 변경에 대한 어려움이 단점으로 작용했습니다.

이러한 문제를 해결하기 위해 2001년, 미국의 개발자 17명이 애자일 선언문을 발표하면서 애자일 방법론이 본격적으로 주목받기 시작했습니다. 애자일 선언문은 고객과의 협력, 변화에 대한 수용, 작동하는 소프트웨어의 우선성 등을 강조하며, 시장의 빠른 변화에 대응하고 경쟁력을 확보하는 데 큰 도움이 되었습니다.

애자일 선언문의 주요 원칙:

• 변경에 유연하게 대응: 요구 사항이 바뀔 때마다 유연하게 대응하는 것이 중요.
• 고객과의 협력: 개발 과정에서 고객과의 긴밀한 협력이 필요.
• 작동하는 소프트웨어: 최종 목표는 작동하는 소프트웨어를 제공하는 것.
• 개발자와의 협업: 개발자, 디자이너 등 팀원 간의 협업을 중시.

결론:

• 애자일은 빠른 출시와 유연한 피드백 수렴이 필요한 환경에서 유리하며, 워터풀은 명확한 요구사항과 품질 보장이 중요한 환경에서 적합합니다.
• 경쟁이 치열한 요즘, 애자일이 더 많이 선택되는 이유는 빠르게 변화하는 시장에서 경쟁력을 유지하고, 고객의 피드백을 반영하기 위함입니다.

애자일 선언문이란?
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정과 도구보다 개인과 상호작용을포괄적인 문서보다 작동하는 소프트웨어를계약 협상보다 고객과의 협력을계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

 

가치설명PM의 역할

항목	애자일(Agile) PM의 역할	워터풀(Waterfall) PM의 역할
개인과 상호작용	✔ 도구나 절차에 의존하기보다는 사람 중심의 협력과 문제 해결에 집중  ✔ 팀원 간 협업 활성화	✔ 프로세스와 절차 중심, 계획된 대로 진행
작동하는 소프트웨어	✔ 개발 초기에 방대한 문서를 작성하는 대신, 빠르게 프로토타입이나 결과물을 만들어 고객에게 제공  ✔ 최소 기능 제품(MVP)을 정의하고, 반복적으로 개선	✔ 전체 프로젝트 계획에 맞춰 최종 결과물 제공
고객과의 협력	✔ 계약 조건을 따지기보다는, 고객/사용자와 긴밀히 협력하여 요구사항 변화에 유연하게 대응  ✔ 고객과 정기적인 소통을 유지하고, 피드백을 적극 반영	✔ 초기 요구 사항을 명확히 하고, 고객의 피드백을 제한적으로 반영
변화에 대한 대응	✔ 처음 계획에 얽매이기보다는, 환경 변화와 고객 요구에 맞게 유연하게 조정  ✔ 팀이 변화에 빠르게 적응	✔ 시장 변화와 고객 요구를 주시하고, 계획을 변경하려면 큰 조정 필요

 

 

 

포스팅 요약

애자일한 방법론과 환경에서의 경험은 매우 중요합니다. 애자일은 워터폴과 비교하여 점진적으로 개선해 나가는 개발 방법론으로, 애자일 환경에서는 기획이 모두 완료된 후 디자이너와 개발자가 협의하는 방식이 아니라, 초기 단계부터 협업을 통해 진행해야 합니다. 특히 MVP(최소 기능 제품) 설정이 중요한 단계입니다.

워터폴 방식이 나쁜 것은 아니며, 특정 프로젝트에서는 워터폴이 유리할 수 있습니다. 하지만 애자일 방식에서는 ‘개인과 상호작용’, ‘작동하는 소프트웨어’, ‘고객과의 협력’, ‘변화에 대한 대응’ 이 네 가지 협업 가치를 중심으로 프로젝트가 진행됩니다. PM은 협업을 활성화하고, MVP를 정의하여 반복적으로 개선하며, 고객의 피드백과 시장 변화를 적극적으로 반영하는 태도를 가져야 합니다.