소프트웨어 개발방법론, 애자일(Agile)

🎯 애자일 방법론

Step 1. 배경 이해하기

먼저, 왜 애자일이 나왔을까?

전통적인 소프트웨어 개발 방식인 폭포수(Waterfall) 모델 방식은 아래와 같다.

요구사항 분석 → 설계 → 구현 → 테스트 → 운영

폭포수 모델은 순서대로 딱딱 떨어지는 방식인데, 여기서 어떤 문제가 있을까?

Step 2. 폭포수 모델의 한계, 현실에서의 문제점

1. 변화 대응 부족

• 요구사항이 한번 정해지면 바꾸기 어렵다.
• 고객/사용자의 니즈는 프로젝트 도중에도 변할 수 있는데, 반영이 거의 불가능하다.

2. 후반부 리스크 집중

• 테스트가 마지막 단계에 몰려있어, 큰 결함이 발견되면 수정 비용이 올라갈 수 있다.
• 일정 지연과 비용 폭증의 원인이 될 수 있음.

3. 고객 피드백 부족

• 중간 산출물이 없어서, 고객은 결과를 맨 마지막에야 확인한다.
• “내가 원한 게 아닌데…” 하는 상황이 자주 발생함.

4. 긴 개발 주기

• 요구분석부터 운영까지 완료해야 첫 결과물이 나온다.
• 개발 주기가 길어지면서 시장 변화가 빠른 환경에서는 경쟁력을 상실할 수 있음.

5. 문서 중심

• 실제 돌아가는 소프트웨어보다 “문서 작성”이 더 중요하게 취급되는 경향이 있음.
• 현업에서는 비효율적일 수 있음.

이러한 문제를 극복하기 위해 애자일(Agile)이 등장하였다.

Step 3. 애자일의 정의와 가치

1. 애자일(Agile)의 정의

애자일은 2001년 미국 유타에서 17명의 소프트웨어 전문가들이 모여 발표한 애자일 선언문(Agile Manifesto) 에서 출발했다.

• 기존 폭포수 개발 형식의 한계를 극복하기 위한 등장
• 변화에 대한 유연한 대응, 고객과의 협력, 짧은 주기의 반복 개발을 핵심으로 함.
• “작동하는 소프트웨어”를 빠르게 제공하고, 피드백을 통해 점진적으로 개선하는 개발 철학

2. 애자일 가치 (Agile Manifesto의 4대 핵심 가치)

애자일 선언문에서는 우리는 다음을 더 가치 있게 여긴다라고 말한다.

• 프로세스와 도구보다 개인과 상호작용
  • 정해진 절차보다 팀원 간 협업, 커뮤니케이션이 더 중요하다.
• 방대한 문서보다 작동하는 소프트웨어
  • 문서를 줄이고, 고객이 실제로 쓸 수 있는 기능을 빠르게 제공.
• 계약 협상보다 고객과의 협력
  • 계약서 문구에 얽매이지 않고, 고객과 함께 해결책을 찾아나감.
• 계획을 따르기보다 변화에 대응
  • 초기 계획보다, 변화하는 상황에 맞춰 방향을 유연하게 조정

여기서 포인트는, 애자일은 방법론(methodology)이 아니라, 사고방식(mindset) 과 문화(culture)라는 점이 중요하다.

Step 4. 대표적인 애자일 방법론

1. Scrum (스크럼)

스크럼은 애자일의 대표주자. 럭비 경기에서의 스크럼처럼, 작은 팀이 하나의 목표를 위해 짧은 시간 집중해서 나아가는 방식을 차용했다고 한다.

• 작동 방식
  • 프로젝트는 Sprint라는 2~4주 단위 반복 주기로 진행
  • 해야 할 기능들은 Product Backlog에 정리
  • 매일 15분짜리 Daily Scrum 회의로 진행 상황을 점검
• 역할(Role)
  • Product Owner: 고객 요구사항 우선순위 관리
  • Scrum Master: 팀이 Scrum 규칙을 잘 따르도록 코치
  • Development Team: 실제 개발을 수행하는 자율적 팀
• 장점
  • 짧은 주기마다 결과물이 나오니 고객은 바로 피드백 가능, 팀은 빠르게 개선 가능

2. XP (eXtreme Programming)

XP는 이름처럼 개발 기법을 극한으로 밀어붙이는 방식. 좋은 습관을 조금만 하는 게 아니라, 아예 극단적으로 철저히 해보자!라는 발상에서 출발했다고 한다.

• 작동 방식
  • 짝 프로그래밍(Pair Programming): 두 명이 짝을 지어 함께 코딩
  • 테스트 주도 개발(TDD): 테스트 코드를 먼저 작성 후 구현
  • 지속적 통합(Continuous Integration): 코드 변경 시마다 자동 빌드/테스트
  • 리팩토링(Refactoring): 코드 품질을 지속적으로 개선
• 역할(Role)
  • 개발자: 짝 프로그래밍, 테스트 코드 작성, 리팩토링 수행
  • 고객/사용자: 사용자 스토리 제공, 수시 피드백
  • 코치/리더: XP 원칙 준수 관리, 기술적 의사결정 지원
• 장점
  • 코드 품질 및 유지보수성 향상
  • 결함 조기 발견 및 수정 비용 절감
  • 팀원 간 지식 공유 및 협업 강화

3. Kanban (칸반)

칸반은 원래 일본 도요타의 생산 관리 방식에서 시작됨. 애자일에서는 이를 소프트웨어 개발에 적용해, 업무 흐름을 시각화하는 데 활용했다.

• 작동 방식
  • 작업을 보드(Board)로 시각화 (예: To Do → Doing → Done)
  • WIP(Work In Progress) 제한으로 동시에 진행할 작업 수 제어
  • 작업 흐름의 병목 현상을 관리
• 역할(Role)
  • 팀원: 각자 작업 항목을 보드에 업데이트
  • 관리자/리더: 병목 관리, 우선순위 조정
  • 이해관계자: 보드를 통해 현재 진행 상황을 투명하게 확인
• 장점
  • 업무 흐름이 가시적으로 드러남
  • 병목 관리 및 우선순위 조정 용이
  • 유연한 변경 대응 가능

---

Step 5. 핵심 비교정리

구분	Scrum (스크럼)	XP (eXtreme Programming)	Kanban (칸반)
초점	팀 운영 방식, 프로세스	개발 기법, 품질 관리	작업 흐름, 시각화
핵심 개념	스프린트, 데일리 스크럼, 백로그	짝 프로그래밍, TDD, 지속적 통합, 리팩토링	보드(Board), 작업 시각화, WIP 제한
장점	빠른 피드백, 고객 만족도 향상	코드 품질 향상, 팀 협업 강화, 결함 조기 발견	진행 상황 가시성 ↑, 유연한 변경 가능
적합한 상황	소규모~중규모 프로젝트, 고객 협업 중요	품질이 중요한 프로젝트, 기술적 복잡도 높음	작업량이 많고 흐름 관리가 중요한 팀

---

📚 참고자료

• Agile Manifesto: https://agilemanifesto.org/iso/ko/manifesto.html
• Scrum Guide (Ken Schwaber & Jeff Sutherland, 2020)
• Ken Schwaber & Jeff Sutherland, The Scrum Guide, 2020
• Kent Beck, Extreme Programming Explained, 2004
• David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, 2010