프로젝트를 효율적으로 계획하고 실행하기 위해서는 체계적인 방법론이 필요하다.

프로젝트 관리 방법론(Project Management Methodology)은 팀이 목표를 효과적으로 달성할 수 있도록 도와주는 일의 방식, 프로세스, 철학을 의미한다. 특히 소프트웨어 개발, 서비스 기획, 스타트업 운영 등 다양한 산업에서 상황에 따라 적절한 방법론을 선택하는 것이 성과에 큰 영향을 미친다.

이번 글에서는 대표적인 프로젝트 관리 방식인 Waterfall 방식과 Agile 방식, 그리고 Agile을 실천하는 프레임워크(Scrum, Kanban)에 대해 알아보도록 하자.

1️⃣ 폭포수(Waterfall) 방법론

---

Waterfall 방법론은 소프트웨어 개발 프로세스의 초기 형태 중 하나이다.

이 방법론은 개발 단계가 순차적으로 진행되며 각 단계가 완료되면 다음 단계로 이동하는 선형적인 프로세스를 따른다.

단계가 마치 폭포처럼 위에서 아래로 흐른다고 해서 붙여진 이름이다.

출처: https://www.mindonmap.com/ko/blog/agile-vs-waterfall/

Waterfall 방법론에서는 다음과 같은 단계로 이루어져 있다.

• Requirements
  고객의 문제를 정의하고 요구사항을 문서화하여 정리하는 단계이다.
  → Waterfall에서는 이후 모든 단계가 이 문서를 기반으로 하기 때문에 오류가 있으면 치명적이다.
• Design
  수집된 요구사항을 기반으로 시스템 구조, UI/UX,DB 등을 설계 하는 단계이다.
• Development
  설계한 내용을 실제 코드로 구현하는 단계이다.
• Testing
  개발된 결과물이 요구사항에 맞게 동작하는지 검증하고 오류를 수정하는 단계이다.
• Deployment
  제품을 실제 사용자 환경에 배포하고 릴리즈 하는 단계이다.
• Maintenance
  배포 후 발생하는 문제를 수정하고 기능을 개선하는 유지보수 단계이다.

🛠️ 주요 용도

명확하고 안정적인 계획이 필요한 프로젝트에 적합하다.

✔️ 요구사항이 초기부터 명확하고 변경 가능성이 낮은 프로젝트
✔️ 대규모 예산/조직이 투입되는 정보, 금융, 건설, SI 프로젝트
✔️ 복잡성보다는 안정성과 예측 가능성이 더 중요한 프로젝트
✔️ 규정이나 감사, 표준 준수가 필요한 산업군

🔸 장단점

• 장점
  • 계획의 명확성: 각 단계가 선형적으로 진행되므로 전체 개발 프로세스를 미리 계획할 수 있어서 이로 인해 프로젝트 일정이 명확해지고 예측 가능해진다.
  • 문서화의 용이성: waterfall 방법론은 각 단계에서 생성된 결과물을 문서화한다.
  • 품질의 향상: 각 단계에서 요구 사항을 검증하고 수정할 수 있으므로 소프트웨어의 품질을 높일 수 있다.

---

• 단점
  • 요구사항 변경의 어려움: 순차적인 프로세스를 따르기 때문에 요구사항이 변경될 경우 비용이나 일정에 영향을 미치기 쉽다.
  • 높은 초기 비용: 각 단계에서 결과물을 생성하고 검증하기 때문에 초기 개발 비용이 높을 수 있다.
  • 유연성의 부재: 예측 가능한 프로세스를 따르기 때문에 유연성이 부족할 수 있다.

2️⃣ 애자일(Agile) 방법론

---

애자일(Agile) 방법론은 소프트웨어 개발 및 프로젝트 관리에 있어 유연하고 반복적인 접근 방식을 지향하여, 오늘날 많은 기업에서 사용하고 있는 방법론이다.

애자일 방법론의 핵심 내용은 애자일 선언문에 잘 명시되어 있다.
애자일 선언문에는 4가지 핵심 가치와 12가지의 원칙으로 구성되어 있다.

🔹4가지 핵심 가치

---

출처: 애자일 가치와 이를 수용하는 방법 - FasterCapital

1. 프로세스와 도구보다 개인과 상호작용을 중시한다.

애자일은 정해진 절차나 도구는 지원 도구일 뿐, 팀원 개개인의 상황과 의사결정이 핵심이고, 문제가 생겼을 때는 유연하게 협력하여 해결하는 것이 핵심이다. 즉, 엄격한 프로세스 보다 사람 중심의 대응을 우선한다.

2. 방대한 문서보다 작동하는 소프트웨어를 중시한다.

방대한 문서 작성보다 실제로 작동하는 소프트웨어를 만드는 데 집중한다. 문서는 필요한 만큼만 작성하고, 고객에게 가치를 주는 것은 결과물 자체임을 강조한다. 즉, 제품이 잘 작동하느냐가 진정한 진척의 기준이다.

3. 계약 협상보다 고객과의 협업을 중시한다.

계약서에 따른 제한된 관계보다 고객과의 지속적인 협업을 더 중요하게 여긴다. 요구사항은 프로젝트 도중에도 변경될 수 있기 때문에, 고객과의 열린 소통을 통해 유연하게 대응해야 한다. 즉, 고객을 프로젝트 파트너로 참여시키는 방식이 더 나은 결과로 이어진다고 본다.

4. 계획을 따르는 것보다 변화에 대응하는 것을 중시한다.

처음 수립한 계획을 엄격히 따르기보다는 변화에 유연하게 대응하는 것을 강조한다. 시장, 기술, 고객 요구사항은 빠르게 변화하기 때문에 고정된 계획만으로는 효과적인 대응이 어렵다. 즉, 변화를 수용하고 빠르게 반영하는 능력이 곧 경쟁력이다.

🔹12가지 원칙

---

1. 고객 만족을 위한 조기·지속적 소프트웨어 배포

최우선 목표는 조기에 작동 가능한 제품을 배포해 고객 가치를 지속적으로 제공하는 것이다. 짧은 주기의 릴리즈를 통해 고객 피드백을 반영함으로써 가치 중심의 개발을 실현한다.

2. 초기 후반에도 요구사항의 변화를 환영

개발 중에도 요구사항은 언제든 바뀔 수 있다는 전제로, 변화 수용을 통해 고객의 경쟁력을 높인다. 오히려 변화는 학습 기회로 삼아 제품을 더욱 개선해 나간다.

3. 작동하는 소프트웨어를 자주 배포

2~4주 단위로 작동 가능한 결과물을 주기적으로 제공함으로써 개발 진행을 명확히 확인할 수 있다. 짧은 반복은 위험을 줄이고 빠른 피드백을 가능하게 한다.

4. 비즈니스 전문가와 개발자가 매일 협력

개발자와 고객 담당자가 매일 얼굴을 맞대고 협력함으로써 요구사항 이해와 문제 해결 속도를 높인다. 이런 긴밀한 업무 관계는 프로젝트의 심층적 이해를 돕는다.

5. 동기 부여된 개인 중심으로 프로젝트 구성

팀 구성원을 믿고 자율성을 부여함으로써 높은 동기와 책임감을 유도한다. 적합한 환경을 제공하면 결과물의 질도 자연스럽게 높아진다.

6. 효율적인 커뮤니케이션은 대면 대화

효율적 의사소통의 핵심은 빠르고 명확한 대면 대화에 있으며, 이는 팀 내부 협업을 강화한다. 원격 환경에서는 화상 회의나 짧은 실시간 소통이 이를 대체할 수 있다.

7. 작동하는 소프트웨어가 진척의 공식 지표

문서보다 실제 작동하는 제품이 진정한 개발 진척을 보여주는 핵심 지표다. 정량적 지표로서 그 자체로 의미 있고, 문서보다 훨씬 더 실질적이다.

8. 지속 가능한 개발 가능 속도 유지

팀은 스프린트마다 현실적인 개발 속도를 유지하고, 번아웃 없이 일정하게 유지 가능한 페이스로 작업해야 한다. 과도한 업무 집중은 오히려 역효과를 가져오기 때문에 지속 가능한 속도 유지가 중요하다.

9. 기술 우수성과 좋은 설계에 주의를 기울인다

지속적인 리팩토링과 자동화된 테스트 등 기술 품질 향상을 위한 노력이 애자일 민첩성 유지에 기여한다. 이는 긴 주기에서도 시스템의 신뢰성과 확장성을 확보하는 핵심 전략이다.

10. 단순하고, 필요 없는 작업은 하지 않는다

불필요한 기능이나 문서는 최대한 제거하고, 가치를 위해 꼭 필요한 작업에 집중한다. 이것은 효율과 속도를 극대화하는 사고방식이다.

11. 최고의 설계는 자율적인 팀이 만든다

최적의 아키텍처와 요구사항은 구성원들의 자율과 책임이 보장된 자기 조직화된 팀에서 자연스럽게 생성된다. 권한 부여가 창의성과 해결책을 촉진한다.

12. 정기적 반성과 조정으로 효율을 개선한다

스프린트 회고를 통해 팀은 정기적으로 프로세스와 협업 방식을 되돌아보고 개선한다. 이는 끊임없는 학습과 성장의 기반이 된다.

🛠️ 주요 용도

요구사항이 계속 변경될 가능성이 높은 프로젝트에 적합하다.

✔️ 제품을 빠르게 출시하고, 고객 피드백을 통해 반복적으로 개선해야 하는 경우
✔️ 팀 간 협업이 중요하고, 짧은 주기로 결과물을 검토하는 경우
✔️ 고객 또는 이해관계자와의 긴밀한 커뮤니케이션이 가능한 환경
✔️ 스타트업, 웹/모바일 앱 개발, SaaS 등 빠른 시장 대응이 중요한 산업

🔸 장단점

• 장점
  • 고객 중심의 유연한 대응: 요구사항이 중간에 바뀌어도 바로 반영 가능하여 지속적인 고객 피드백을 통해 제품의 품질과 만족도를 높일 수 있다.
  • 빠른 개발 및 배포를 통해 위험 최소화: 짧은 스프린트 단위로 기능을 나누어 개발함으로써 빠르게 릴리즈할 수 있고, 자주 테스트하며 점진적으로 개선하기 때문에 문제에 유연하게 대처 할 수 있다.
  • 팀 역량과 협업 강화: 자율성과 책임이 강조되어 팀원들의 동기 부여가 높아진다.
  • 지속적인 개선: 스프린트 회고를 통해 팀의 문제를 정기적으로 반성하고 개선할 수 있다.

---

• 단점
  • 장기적인 예측 어려움: 전체 계획을 처음부터 명확하게 세우기 어렵고, 일정과 예산 산정이 불안정할 수 있다.
  • 요구사항이 자주 바뀌면 혼란: 고객 피드백에 따라 요구가 계속 바뀌면 팀에 피로와 혼란 가중
  • 문서화 부족 가능성: 추후 유지보수나 인수인계 시 문제 발생 가능성
  • 고객의 적극적인 참여가 필수: 고객이 수시로 피드백을 주지 않으면 제대로 작동하지 않음.

🔹프레임워크

---

애자일 방법론은 하나의 고정된 방식이 아니라, 여러 프레임워크를 통해 다양한 형태로 실천된다.
대표적인 프레임워크로는 Scrum, Kanban, XP가 있다.

각각의 팀 문화, 조직 규모, 프로젝트 유형에 따라 적합한 프레임워크를 선택해야 한다.

🔻Scrum

---

Scrum의 어원은 럭비 경기에서 나왔다. Scrum은 럭비 경기에서 선수들이 공을 차지하기 위해 몸을 밀착하고 협력하는 장면에서 나온 용어이다. Scrum formation은 모든 선수가 팀으로 뭉쳐서, 밀고 나아가는 협업의 상징이다.

1986년, 일본 경제학자 Hirotaka Takeuchi와 Ikujiro Nonaka가 Havard Business Review에 발표한 논문 〈The New New Product Development Game〉 에서 처음 Scrum이라는 개념을 소프트웨어 개발 방식에 비유해서 사용했다.

Scrum 프레임워크는 실제로 고도로 협력적이고 자율적인 팀 운영을 지향한다. 각 팀원이 정해진 역할을 가지고, 매일 소통하며 목표를 향해 밀고 나아가는 구조로 마치 럭비 경기의 scrum 처럼 모두가 함께 밀어붙이는 과정이라 볼 수 있다.

스크럼은 작은 주기(sprint)로 개발 및 검토하여 효율적인 협업 방법을 제공한다. 고객 요구사항을 충족시키는데 초점을 맞추고 있으며, 2-4주 주기의 sprint의 반복이라 이해하면 된다.

✨ 주요 특징

• 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
• 개발 주기는 1~4주 정도로 하고 개발 주기마다 실제 동작할 수 있는 결과를 제공한다.
• 매일 15분 정도의 Scrum meeting 회의를 가진다.
  → 공유하는 자리이며 보고하는 자리가 아니다.
• 자신의 task보다 항상 팀을 우선으로 생각한다.
• 원활한 의사소통을 위하여, 구분 없는 열린 공간과 마음을 유지한다.

scrum의 주요 역할자로는 Product Owner와 Scrum Master가 있다. 두 사람은 서로 보완하는 역할을 수행한다.

1. 제품 책임자(Product Owner)
비지니스 목표를 충족시키는 제품을 만들기 위해 제품 백 로그를 관리하고 제품을 검토한다.
제품 백로그(요구사항) 관리와 설명을 담당하고, 우선순위를 관리한다.

출처: https://www.mindonmap.com/ko/blog/agile-vs-waterfall/

2. 스크럼 마스터(ScrumMaster)
Product Owner와 Development Team이 가치(Value)와 원칙(Principle)으로 성공적인 제품을 만들고, 조직 변화를 촉진하고 민첩한 작업 방식을 수립하여 유지할 수 있도록 책임을 가진다.
팀을 보호하고 장애 요소를 해결하며 일일 스크럼 회의를 진행하는 역할을 한다.

출처: https://www.mindonmap.com/ko/blog/agile-vs-waterfall/

🔻Kanban

---

Kanban은 제조 산업에서 시작되었으며, 시스템은 가치 체인의 시작 지점(공급업체)부터 소비자에게 도달할 때까지 전체 가치 체인을 제어한다.

기업이 공급 중단, 과잉 재고, 공급망의 병목 현상을 피할 수 있도록 돕는다. 지속적인 모니터링 기능이 포함되었기 때문에 배송 리드 타임을 단축하는 데 도움이 된다.

Kanban은 시각적인 작업 관리 시스템으로, 팀원들이 진행 중인 작업의 상태를 쉽게 이해하고, 업무의 흐름을 관리할 수 있도록 돕는다. 각 작업은 Kanban Board에서 카드 형태로 진행되며, 작업의 단계에 따라 보드의 여러 열에 배치된다.

✨ Kanban의 핵심 원칙 5가지

1. 작업 흐름 시각화

팀원들은 한눈에 전체 작업 흐름을 파악하고, 각 작업의 현재 상태를 쉽게 확인할 수 있다.

2. 진행 중인 작업(WIP:Work In Progress) 제한

각 작업 단계에서 동시에 처리할 수 있는 작업의 수를 제한하여 멀티태스크링을 줄이고 각 작업에 집중 할 수 있다.

3. 흐름 관리

작업이 시스템을 통해 얼마나 원활하게 이동하는지 측정하고 최적화한다.

4. 프로세스 정책 명시화

팀은 작업 방식에 대한 명확한 가이드라인을 설정하고 공유하여, 모든 팀원이 프로세스를 이해하고 따르는 데 도움이 된다.

5. 피드백 루프 구현

정기적인 팀 미팅과 성과 지표 검토를 통해 지속적인 개선을 추구한다.

👀My thoughts

---

• 프로젝트를 진행하면서 그동안은 '프로젝트 방법론'이라는 개념 자체에 대해 한 번도 생각을 해본 적이 없었다. 하지만 이번에 벨로그를 작성하기 위해 공부를 하면서 실제 현업에서는 프로젝트를 진행할 때 수많은 방식과 요소들을 체계적으로 고려한다는 사실을 새롭게 알게 되었다.
• 일을 처리하는 방법에도 여러 가지 방법이 존재하고, 회사마다 더 나아가 각 팀마다 적합한 일처리 방법이 다를 수 있다는 점이 인상적이었다.
  여러 글을 참고하다가, 한 협업자 분이 기존에는 Scrum 방식을 사용했지만 Kanban 방식으로 전환한 뒤 팀 퍼포먼스가 눈에 띄게 향상되었다는 경험을 공유한 글을 보게 되었다. 같은 애자일 방식이라도 상황에 따라 유연하게 적용하는 것이 중요하다는 것을 알게 되었다.