[SW Engineering] 04. 애자일 소프트웨어 개발(Agile Software Development)

이번 포스팅에서는 현대 개발 방법론의 핵심인 애자일의 철학부터, 구체적인 실천 방법인 XP(Extreme Programming)와 스크럼(Scrum), 그리고 애자일 방식의 계획 수립(Planning)까지 실무에서 많이 사용하는 아주 중요한 내용들을 다루어 보겠습니다.

 

비즈니스 환경은 급변하고 있습니다. 완벽한 계획을 세우고 개발하기엔 시간이 너무 부족하죠. 그래서 등장한 것이 바로 '애자일(Agile, 기민한)' 개발 방법론입니다.

1. 급변하는 환경과 애자일의 등장

1) 왜 애자일인가?

• 오늘날 비즈니스 요구사항은 매우 빠르게 변화하며, 안정적인 요구사항 세트를 미리 확정하는 것은 사실상 불가능합니다.
• 전통적인 '계획 주도(Plan-driven)' 방식은 이런 빠른 변화를 따라가기 어렵습니다.
• 애자일의 목표: 1990년대 후반 등장한 애자일은 '동작하는 소프트웨어'를 '아주 빠르게' 인도하는 것을 목표로 합니다

2) 애자일 vs 계획 주도 (Plan-driven)

https://curious-notes.netlify.app/posts/agile-methodology에서 설명하는 계획 주도 VS 애자일 주도 비교

• 계획 주도 개발: 각 단계(요구사항, 설계, 구현 등)의 결과물을 미리 계획하고 진행합니다.
• 애자일 개발: 명세, 설계, 구현, 테스트가 서로 맞물려(Inter-leaved) 진행됩니다.
  • 이해관계자가 참여하여 버전을 지속적으로 평가합니다.
  • 문서화(Documentation)보다는 코드(Code) 자체에 집중합니다

2. 애자일 선언문 (Agile Manifesto)

애자일의 4대 핵심 가치

애자일의 정신을 담은 4가지 핵심 가치입니다. (왼쪽 항목의 가치도 인정하지만, 오른쪽 항목을 더 중요하게 여깁니다)

1. 공정과 도구보다 개인과 상호작용을 (Individuals and interactions over processes and tools)
2. 포괄적인 문서보다 작동하는 소프트웨어를 (Working software over comprehensive documentation)
3. 계약 협상보다 고객과의 협력을 (Customer collaboration over contract negotiation)
4. 계획을 따르기보다 변화에 대응하기를 (Responding to change over following a plan)

💡 애자일 5대 원칙

고객 참여	고객은 새로운 요구사항을 제공하고 우선순위를 정하며, 시스템을 평가하는 역할을 합니다.
점진적 인도	고객이 포함할 요구사항을 명시하고, 소프트웨어를 조금씩(Increment) 개발하여 인도합니다.
사람 중심	프로세스보다 팀원의 기술과 능력을 인정하고, 그들만의 작업 방식을 존중합니다.
변화 수용	요구사항은 변하기 마련입니다. 시스템을 변화에 유연하게 설계합니다.
단순성 유지	개발되는 소프트웨어와 개발 과정 모두 '단순함'을 유지하는 데 집중합니다.

3. XP (Extreme Programming)

XP는 1990년대 후반에 개발된 가장 영향력 있는 애자일 방법론 중 하나로, 애자일의 기술적인 실천 방법(Practices)을 '극한'까지 밀어붙인 방식입니다

1) XP의 주요 실천 방법 (Key Practices)

XP는 기술적인 측면에 초점을 맞춥니다. 다음 4가지가 핵심입니다.

① 사용자 스토리 (User Stories)

• 복잡한 요구사항 문서 대신, 고객이 이해할 수 있는 시나리오인 '사용자 스토리'를 카드에 작성합니다
• 예: "사용자는 음악을 재생하기 위해 재생 버튼을 누를 수 있다."
• 개발 팀은 이 스토리를 구현 가능한 작은 태스크(Task)로 쪼개고, 일정과 비용을 추산합니다.

사용자 스토리(User Story)는 애자일에서 요구사항을 정의하는 가장 핵심적인 도구입니다. 딱딱한 '기능 명세서'가 아니라, '누가, 무엇을, 왜' 원하는지를 담은 짤막한 이야기 형식을 띱니다.

'자취방 구하기 서비스' 시나리오를 활용해, 막연한 요구사항이 어떻게 구체적인 사용자 스토리로 바뀌는지 살펴보겠습니다.

1. 사용자 스토리의 기본 공식

보통 사용자 스토리는 다음과 같은 템플릿으로 작성합니다.

"나는 [어떤 사용자]로서, [어떤 기능]을 원한다. 그 이유는 [어떤 가치]를 얻기 위해서이다."

2. 구체적 예시: 자취방 구하기 앱 (Room Finding App)

상황 1: 조건 검색이 필요한 경우

• 기존의 딱딱한 명세서:
  • "시스템은 보증금, 월세, 층수, 반려동물 여부 필터링 기능을 제공해야 한다."
• 📝 사용자 스토리 1:
  • "나는 자취생(똘똘이)으로서, 내가 가진 예산과 반려동물 허용 여부를 입력해 방을 필터링하고 싶다. 그래야 헛걸음하지 않고 조건에 맞는 방만 골라 볼 수 있기 때문이다."

상황 2: 생활권 확인이 중요한 경우

• 기존의 딱딱한 명세서:
  • "사용자 카드 데이터를 연동하여 POI(Point of Interest) 간의 거리를 계산하는 알고리즘을 구현한다."
• 📝 사용자 스토리 2:
  • "나는 이사 갈 사람으로서, 내 카드 내역을 바탕으로 내가 자주 가는 상점들과 새 집 사이의 거리를 알고 싶다. 그래야 이사를 가서도 지금처럼 편하게 지낼 수 있는지 미리 알 수 있기 때문이다."

상황 3: 방문 전 주변 환경 확인

• 기존의 딱딱한 명세서:
  • "건물 위치 좌표를 기반으로 거리뷰 API를 호출하여 화면에 렌더링한다."
• 📝 사용자 스토리 3:
  • "나는 겁이 많은 세입자로서, 방문하기 전에 건물의 거리뷰를 통해 주변 분위기를 보고 싶다. 그래야 밤길이 위험하지 않은지, 소음 문제는 없을지 미리 파악할 수 있다."

3. 스토리에서 태스크(Task)로 분해하기

사용자 스토리가 완성되면, 개발자들은 다음과 같이 사용자 스토리를 실제로 구현하기 위해 더 작은 단위인 '태스크(Task)'로 쪼갭니다

[사용자 스토리 1] (반려동물 필터링)을 개발하기 위한 태스크 목록 예시:

1. ⬜ DB 설계: 방 정보 테이블에 '반려동물 허용 여부(Boolean)' 컬럼 추가.
2. ⬜ 백엔드: 필터링 조건에 따라 쿼리를 날리는 API 개발 (4시간 소요 예상).
3. ⬜ 프론트엔드: 검색 화면에 '강아지/고양이' 체크박스 UI 만들기 (2시간 소요 예상).
4. ⬜ 테스트: 반려동물 불가 방이 검색 결과에 나오는지 테스트 코드 작성.

정리 및 요약

이렇듯 사용자 스토리는 "기술적인 언어"가 아니라 "사용자의 언어"로 씁니다. 이렇게 하면 개발자가 코드를 짜면서도 "아, 내가 지금 쿼리를 짜는 이유가 똘똘이가 헛걸음하지 않게 하려는 거구나"라고 목적을 잃지 않게 해줍니다.

 

② 리팩토링 (Refactoring)

• 개념: 소프트웨어의 기능을 변경하지 않으면서, 내부 구조(코드)를 개선하는 활동입니다
• 목적: "변화를 예측"하는 것이 아니라, "변화를 쉽게 수용할 수 있도록" 코드를 항상 깔끔하게 유지하는 것입니다.
• 예시: 중복 코드 제거, 클래스 계층 재구성, 긴 메서드 분리 등.

이 내용은 후반부에서 자세히 다룰 예정입니다.

 

③ 테스트 우선 개발 (Test-First Development)

• 개념: 코드를 짜기 전에 테스트 코드를 먼저 작성합니다.
• 과정: 실패하는 테스트 작성 → 기능 구현 → 테스트 통과 → 리팩토링.
• 장점:
  • 요구사항이 명확해집니다.
  • 새로운 기능 추가 시 기존 기능이 망가지지 않았는지 자동으로 확인할 수 있습니다 (Junit 등 사용).
• 단점: 프로그래머가 테스트 작성을 귀찮아하거나, UI처럼 테스트하기 어려운 부분이 존재할 수 있습니다.

여기서 추가적으로 Partition Test 기법을 신경쓰며 테스트를 작성하면 퀄리티 높은 Test First Development를 진행할 수 있습니다. Partition Test란 입력과 출력을 동등한 그룹으로 나누고 대표값을 테스트함으로써 각 그룹을 동등하게 테스트할 수 있습니다.

예를 들어 테스트의 입력과 출력을 동등하게 나누고 각 그룹의 경계값, 범위 밖, 출력 예외값 등을 테스트함으로써 이 테스트가 모든 그룹을 동등하게 반영한다는 확신을 가지고 테스트하는 방법입니다. 이 내용은 추후 자세히 다룰 예정이니 이런 방법이 있구나 하고 넘어가시면 됩니다.

④ 짝 프로그래밍 (Pair Programming)

• 개념: 두 명의 프로그래머가 하나의 컴퓨터에서 같이 개발합니다
• 효과:
  • 실시간 코드 리뷰 효과가 있어 코드 품질이 높아집니다.
  • 팀원 간 지식이 공유되어, 한 명이 팀을 떠나도 리스크가 줄어듭니다.
  • 생산성이 떨어질 것 같지만, 실제로는 두 명이 따로 일하는 것보다 더 효율적일 수 있습니다.

실무에서는 두 명이 서로 맞춰 개발하는 것이 어려워 GitHub 코드리뷰로 대체하거나 LLM을 이용한 Pair Programming을 사용합니다.

 

4. 스크럼 (Scrum)

아마 회사 및 프로젝트에서 Daily Scrum이라는 말을 들어본 적이 있을 것입니다.

XP가 기술적인 실천법이라면, 스크럼은 프로젝트 관리(Management)에 초점을 맞춘 애자일 방법론입니다.

1) 스크럼의 주요 용어

• 스프린트 (Sprint): 2~4주 단위의 개발 주기(Iteration)입니다
• 제품 백로그 (Product Backlog): 해야 할 일(요구사항)의 목록입니다.
• 스크럼 마스터 (Scrum Master): 팀을 이끌거나 지시하는 사람이 아니라, 팀이 방해받지 않고 일하도록 돕는 '촉진자(Facilitator)'입니다.
• 제품 책임자 (Product Owner): 제품의 기능을 식별하고 우선순위를 정하는 사람(고객의 대리인)입니다.
• 벨로시티 (Velocity): 팀이 한 스프린트 동안 처리할 수 있는 업무량의 추정치입니다.

2) 스크럼 진행 과정

1. 계획 (Select & Plan): 백로그에서 이번 스프린트에 할 일을 선택합니다.
2. 스프린트 (Sprint): 팀은 외부와 격리되어 개발에 집중합니다. 매일 짧은 회의(Daily Scrum)를 통해 진행 상황과 문제점을 공유합니다20.
3. 리뷰 (Review): 스프린트가 끝나면 작업한 내용을 이해관계자에게 보여주고 평가받습니다.

스크럼(Scrum)의 핵심은 "우리 팀의 능력을 수치화(Velocity)해서, 딱 그만큼의 일(Story Point)만 가져와 집중하는 것"입니다.

3) 사용자 시나리오를 바탕으로 스크럼 진행하기

일의 난이도/규모를 수치화하는 과정(Planning Game)과 벨로시티를 조정하여 다음 계획을 세우는 과정을 '자취방 구하기 서비스' 팀의 가상 시나리오를 통해 구체적으로 살펴볼까요?

🏃‍♂️ 스크럼 진행 과정: 자취방 앱 개발팀의 2주

① 1단계: 제품 백로그(Product backlog) & 우선순위 정하기 (Product Owner의 역할)

먼저 제품 책임자(Product Owner)가 고객에게 가장 필요한 기능 순서대로 **할 일 목록(Backlog)**을 가져옵니다1111.

• 1순위: 지도에 방 위치 띄우기 (이거 없으면 서비스 불가)
• 2순위: 보증금/월세 필터링 (핵심 기능)
• 3순위: 상세 페이지에서 건물주 연락처 보기
• 4순위: 카드 내역 연동해서 생활권 분석하기 (멋진 기능이지만 당장 급하진 않음)

② 2단계: 플래닝 게임 - 일의 규모 산정 (Story Points)

이제 개발팀이 모여서 각 기능이 '얼마나 어려운지'를 점수(Effort Points)로 매깁니다. 시간(Hour)으로 따지면 변수가 너무 많기 때문에, 보통 상대적인 점수를 사용합니다.

[우선순위 정하기 - 일의 중요도 논의]

• 팀장: "자, '지도 띄우기' 몇 점일까?"
• 개발자 A: "네이버 지도 API 쓰면 금방 해요. 2점 주죠." (기준점)
• 팀장: "그럼 '카드 내역 연동'은?"
• 개발자 B: "어우, 그건 금융 보안 모듈도 깔아야 하고 데이터 분석도 해야 해요. 지도보다 4배는 어려울 듯? 8점이요."
• 개발자 C: "필터링은 UI만 좀 손보면 되니까 지도랑 비슷하게 2점입니다."

[결과 - 제품 백로그(Product backlog) 점수표]

위의 스크럼이 끝나면 중요도에 따라서 아래 제품 백로그가 완성됩니다.

1. 지도 띄우기: 3점 (보수적으로 잡음)
2. 필터링: 2점
3. 연락처 보기: 1점
4. 카드 연동: 8점
5. 거리뷰 보기: 5점

 

③ 3단계: 스프린트 계획 & 벨로시티(Velocity) 활용

이제 이번 스프린트(2주) 동안 몇 개의 기능을 가져갈지 정해야 합니다. 이를 바탕으로 Sprint Backlog를 정해야 합니다. 이때 현재 팀의 진행속도를 판단하기 위해 사용하는 기준 척도가 벨로시티(Velocity)입니다.

[상황 1: 첫 번째 스프린트 (데이터 없음)]

• 팀장: "우리 팀 벨로시티를 아직 모르니까, 일단 감으로 15점 어치만 가져가 보자."
• 계획: 지도(3) + 필터링(2) + 연락처(1) + 카드연동(8) = 총 14점 선택.

[상황 2: 스프린트 종료 후 (현실 자각)]

• 2주 동안 열심히 달렸지만, '카드 연동(8점)'은 보안 문제 때문에 마무리를 못했습니다.
• 실제 완료한 점수: 지도(3) + 필터링(2) + 연락처(1) = 6점.
• 🚨 결과: 우리 팀의 실제 초기 벨로시티는 6점이었습니다. (15점은 과욕이었음)

[상황 3: 두 번째 스프린트 계획 (벨로시티 조정)]

• 조정된 계획:
  • 지난번에 못한 카드 연동(8점)을 가져오면 다른 걸 하나도 못 함.
  • 전략 수정: 카드 연동은 너무 크니까 쪼개자(Split). -> '카드 API 연동(3점)' + '데이터 분석(5점)'으로 분리.
  • 이번 할 일: 카드 API 연동(3점) + 거리뷰 보기(5점) = 8점 선택.

💡 핵심: 이전 스프린트에서 실제로 해낸 양(Velocity)을 기반으로, 다음 스프린트에 가져올 일의 양을 현실적으로 조정하는 것이 스크럼의 핵심입니다.

4단계: 스프린트 실행 (Daily Scrum)

팀원들은 외부의 방해 없이 개발에만 집중합니다. 매일 아침 15분간 서서 짧게 상황을 공유합니다.

• 개발자 A: "어제 거리뷰 API 연결 성공했고요(진행 상황), 오늘은 화면에 띄우는 거 할 겁니다(계획). 근데 API 키가 만료됐다고 뜨는데 이거 재발급해 주세요(방해 요소)."
• 스크럼 마스터: "네, 제가 바로 처리할게요. A님은 개발 계속하세요."

5단계: 스프린트 리뷰 (Review)

2주가 지났습니다. 팀은 고객(똘똘이)을 불러서 '동작하는 소프트웨어'를 보여줍니다.

• 팀: "자, 여기 보시면 거리뷰가 나옵니다. 주변에 편의점 보이시죠?"
• 고객: "오 좋네요! 근데 밤에는 어두워서 잘 안 보일 것 같아요. 가로등만 밝게 표시해 주는 기능도 추가해 주세요."
• 팀: (속마음: 으악! 일이 늘었다) "네, 그 요구사항은 백로그에 추가해서 다음번 플래닝 때 점수 매겨볼게요!"

정리

📝 지금까지의 과정을 요약하자면, 스크럼이란 다음과 같습니다.

1. 점수 매기기: 시간(Time) 대신 **상대적 난이도(Point)**로 일의 크기를 견적 냅니다.
2. 벨로시티 측정: 한 주기 동안 우리가 실제로 처리한 점수의 합(Velocity)을 구합니다.
3. 조정 및 계획: 다음 주기에는 '우리의 벨로시티'만큼만 일을 가져와서 실패 확률을 줄입니다.

이 과정을 반복하면 팀은 점점 자신의 속도를 정확히 알게 되고, 무리한 야근 없이 예측 가능한 개발을 할 수 있게 됩니다.

프로덕트 백로그 VS 스프린트 백로그

위의 예시에서 두 가지의 백로그가 나옵니다. 이해를 돕기 위해 프로덕트 백로그와 스프린트 백로그의 차이를 정리해봅시다.

프로덕트 백로그 (Product Backlog)

• 정의: 프로젝트 전체에서 수행해야 할 모든 요구사항을 우선순위에 따라 나열한 목록입니다.
• 특징:
  • 아직 구체적이지 않을 수 있으며, 아이디어 단계의 기능도 포함됩니다.
  • 제품 책임자(Product Owner)가 고객의 니즈에 맞춰 계속해서 순서를 바꾸거나 항목을 추가/삭제합니다.
• 예시:관리: 기획자(Product Owner)
  1. 지도에 방 위치 표시하기 (우선순위 1)
  2. 보증금/월세 필터링 (우선순위 2)
  3. 건물 상세 페이지 (우선순위 3)
  4. 카드 내역 연동 서비스 (우선순위 4 - 아직 아이디어 단계)
  5. VR 룸투어 기능 (우선순위 5 - 나중에 개발)

스프린트 백로그 (Sprint Backlog)

• 정의: 프로덕트 백로그 중에서 "이번 턴(스프린트)에 끝내기로 약속한 항목들"을 따로 떼어온 목록입니다.
• 특징:
  • 개발 팀이 이번 스프린트 내에 완료할 수 있다고 판단한 만큼만 가져옵니다.
  • 사용자 스토리를 실제로 구현하기 위해 '상세 태스크(Task)'로 쪼개져 있습니다 (예: DB 설계, API 구현, UI 디자인 등)
• 예시:관리: 개발팀
  • 목표: "지도와 필터 기능 완성하기" (프로덕트 백로그 1, 2번을 가져옴)
  • 상세 할 일 목록(Tasks):
    • [백엔드] 카카오 지도 API 연동하기
    • [프론트] 지도 마커 클릭 이벤트 처리
    • [DB] 보증금/월세 데이터 쿼리 최적화
    • [디자인] 필터링 슬라이더 UI 만들기

구분	프로덕트 백로그 (Product Backlog)	스프린트 백로그 (Sprint Backlog)
비유	전체 요리 메뉴판 (식당이 팔 수 있는 모든 요리)	지금 조리 중인 주문서 (주방장이 지금 만들고 있는 요리)
범위	프로젝트 전체 기간 동안 해야 할 모든 일	이번 스프린트(2~4주) 동안 해야 할 일
내용	고객이 원하는 요구사항(User Story)의 우선순위 목록	프로덕트 백로그에서 가져온 항목 + 구체적인 개발 태스크(Task)
관리자	제품 책임자(Product Owner)가 관리 및 우선순위 결정	개발 팀(Development Team)이 스스로 선택하고 관리
변동성	프로젝트 내내 계속 추가되고 바뀔 수 있음	스프린트가 시작되면 원칙적으로 바뀌지 않음 (변경 통제)

5. 애자일 계획 (Agile Planning)

애자일에서는 처음부터 모든 계획을 완벽하게 세우지 않습니다.

1) 릴리즈 계획 vs 반복(Iteration) 계획

• 릴리즈 계획: 수개월 앞을 내다보며 어떤 기능들이 포함될지 결정합니다21.
• 반복 계획 (Iteration Planning): 당장 다음 2~4주 동안 수행할 작업을 상세하게 계획합니다

2) 플래닝 게임 (The Planning Game)

• 스토리 포인트: 각 사용자 스토리에 개발 난이도와 시간을 고려한 '점수(Effort points)'를 부여합니다
• 벨로시티 활용: 우리 팀이 지난번에 30포인트만큼 일했다면, 이번에도 약 30포인트어치의 일을 할당합니다
• 태스크 할당: 개발자들은 스토리를 구체적인 태스크(4~16시간 분량)로 쪼개고, 스스로(Sign up) 자신이 할 일을 선택합니다 25. 이것이 팀원들에게 주인의식(Ownership)을 줍니다.

3) 애자일 계획의 어려움

• 고객이 계획 수립 과정에 지속적으로 참여하기 어려울 수 있습니다
• 팀원이 자주 바뀌거나 지리적으로 분산된 대규모 팀에서는 적용하기 어렵습니다

 

6. 📝 요약

애자일 개발은 불필요한 절차를 줄이고 '고객 가치'와 '작동하는 소프트웨어'에 집중하는 것입니다.

이를 위해 XP의 기술적 실천법(리팩토링, TDD, 짝 프로그래밍)과 스크럼의 관리 프로세스(스프린트, 데일리 스크럼)를 적절히 활용해야 합니다. 무엇보다 중요한 것은 계획을 따르는 것보다 변화에 유연하게 대처하는 태도입니다!