애자일 모델

하이솝·2026년 3월 11일
3학년 1학기소프트웨어공학

소프트웨어공학

목록 보기
3/27

예전 소프트웨어 개발 → 철저한 계획 중시
현대 소프트웨어 개발 → 기민한 대응 중시

폭포수 모델의 결함

  • 시작부터 변화라는 가능성을 아예 차단하고 있음
  • 변화가 심한 현대 비즈니스 환경에서, 경직된 폭포수 모델을 고집하는 것은 매우 위험한 것

애자일 모델

애자일 모델

  • 반복적(iterative)
    전체 주기를 몇 주 내의 짧은 Iteration(반복주기)으로 구분하고,
    각 반복주기 내에 요구분석-설계-구현-테스트-review의 전체 공정 포함
  • 점진적(Incremental)
    단순히 기능을 쌓는(Incremental)것을 넘어, 이전 주기에서 얻은 피드백을 통해 기존 기능을 개선하고 진화(Iterative)시켜 나가는 과정
  • 지속적 전달
    폭포수 모델은 프로젝트가 끝날 때 결과물을 내놓지만, 애자일 모델은 매 반복 주기 종료 시 작동 가능한 증분(Increment) 산출 및 필요시 즉시 릴리즈함
  • 가치 중심 우선순위
    고객이 비즈니스 가치가 높은 요구사항을 우선 선택하여 시작 지점에 확정
  • 변경 수용
    스프린트(주기) 중에는 변경을 제한하여 집중도를 높이되, 종료 후 review를 통해 다음 주기에 비즈니스 가치가 높은 것을 먼저 개발하여 변경 사항 적극 반영

애자일 선언문(Agile Manifesto, 2001)

  • 개인과 상호작용을 도구와 프로세스보다 중시함
  • 작동하는 소프트웨어를 포괄적인 문서보다 중시함
  • 고객과의 협력을 계약 협상보다 중시함
  • 변화에 대응하는 것을 계획을 고수하는 것 보다 중시함

애자일 원칙

애자일 프레임워크

  • ✓ Scrum
    1주~4주 단위의 개발 주기인 스프린트를 반복하며, 명확한 목표를 세운다.
    이 기간이 끝나면 반드시 실제로 작동하는 결과물로 만들어내는 프레임워크
    운영과 관리에 초점
  • XP(eXtreme Programming)
    Scrum이 팀의 운영 방식에 초점을 맞춘다면, XP는 소프트웨어를 만드는 기술적인 탁월함에 중점을 둠
    extreme: 코딩을 하는 과정에서 좋다고 알려진 실천 방법들을 극한까지 밀어붙이기 때문임
    의사소통과 피드백을 극대화하여 최고의 품질을 만드는 것이 핵심 가치
    기술에 초점
    예)
    짝 프로그래밍(Pair Programming)
    책상 하나에 개발자 두명이 앉아 함께 코딩하는 것
    on site customer
    이해관계자를 개발 환경에 상주시키는 것
    테스트 주도 개발(Test Driven Development, TDD)
    실패하는 테스트를 먼저 만든 후,
    그 테스트를 통과하기 위한 코드를 나중에 작성
  • ✓ Kanban
    업무의 흐름(Flow)을 관리하는 데에 집중
    할 일, 진행 중, 완료 라고 적힌 보드에 모든 업무를 포스트잇으로 붙여서
    시각화함
    동시에 진행하는 일의 개수를 제한하는 WIP(Work In Progress) 제한을 둠
    흐름에 초점

정해진 리듬을 타는 스크럼인가? 혹은 유연한 흐름을 중시하는 칸반인가?

SCRUM

  • 현재 널리 사용되는 실용적인 애자일 프레임워크
  • 스프린트(sprint) 라고 불리는 짧고 규칙적인 주기를 반복하며,
    예측 가능하게 제품의 가치를 쌓아가는 방식

스크럼의 흐름

1) 이번 주기에서 무엇을 할지 계획을 세우고 곧바로 실행에 옮김
매일 아침 데일리 스크럼을 통해 서로의 진행 상황을 짧게 확인하게 됨

2) 구현이 끝나면 결과물을 점검하는 리뷰 단계를 거치게 됨

3) 마지막으로 회고를 통해 팀이 더 성장할 방법이 없었는지 되돌아보는 시간을 가짐

계획과 실행, 결과물 점검, 팀 점검의 한 사이클을 가짐
이러한 사이클이 끝날 때 마다 고객에게 실제로 동작하는 소프트웨어인
제품 증분(product increment), 즉 실질적인 가치를 전달하게 됨

제품 증분: 즉시 출시하거나 배포할 수 있는 상태의 구체적인 기능이나 합

스크럼 역할

  • PO(Product Owner)

제품 책임자

제품의 비전과 목표 설정: 제품이 나아갈 방향을 제시

제품 백로그 작성 및 관리: 제품에 필요한 모든 요구사항을 만들고 시장 상황과 고객의 요구에 따라 지속적으로 우선 순위를 조정

이해관계자의 목소리 대변: 고객, 경영진 등 다양한 사람들의 의견을 듣고, 제품의 가치를 극대화하는 최종 결정을 내림

  • Scrum Master

팀의 조력자: 팀 자체의 건강과 성장을 책임지는 역할

스크럼 프로세스 리드: 팀이 스크럼을 제대로 이해하고 실천하도록 도움

장애물 제거: 개발팀이 개발에만 집중할 수 없게 만드는 모든 문제(회의, 장비 문제 등)를 해결해줌

팀의 조력자: 회의를 효과적으로 진행하고, 팀원 간의 소통과 협업을 촉진함

  • Developer

실질적 구현을 담당하는 개발자

팀의 규모(Small Size): 10명 이하 (보통 3~9명)로 피자 2판으로 식사를 해결할 수 있는 규모로, 빠르고 긴밀한 소통을 지향함
팀이 너무 커지면 소통 비용이 급격하게 증가하여 민첩성이 떨어짐

"디자인팀에 요청하고 3일 기다리기" 와 같은
외부 의존성을 최소화하여 속도를 높임

다기능 팀(Cross-functional): 스프린트 목표 달성에 필요한 모든 기술 (기획, UX/UI 디자인, 개발 테스트, DB, 인프라 등)을 팀 내부에 보유함

자기 관리 팀(Self-managing): 누가, 어떻게, 무엇을 작업할지 팀 외부에서 지시받지 않고 팀 스스로 결정하고 관리함
보스(BOSS)가 일을 할당하는 것이 아니라, 팀이 스스로 일을 분배

단순히 개발자만을 의미하는 것이 아니라 디자이너, 테스터, 아키텍트 등 모든 기술자를 통칭하는 단어

스크럼 이벤트

  • 스프린트(Sprint): 모든 것을 담는 그릇(컨테이너)
  • 스프린트 계획(Sprint Planning): 무엇을 어떻게 할지 계획하는 시간

목적: 이번 스프린트에 달성할 목표와 무엇을 정하고 어떻게 만들지 계획
참석자: 스크럼 팀 전체
결과물: 스프린트 목표, 스프린트 백로그

  • 데일리 스크럼(Daily Scrum): 목표를 향한 일일 점검

목표: 스프린트 목표 달성을 위한 진행 상황을 점검하고, 일일 계획을 조정하는 시간
규칙:
시간: 매일 같은 시간, 같은 장소에서 15분 이내
참석자: 개발자들을 위한, 개발자들에 의한 이벤트
(PO, SM은 옵저버로 참여 가능)
핵심: 상사에게 하는 상태 보고가 아님 팀 동료간의 목표 공유 및 협업 계획

  • 스프린트 리뷰(Sprint Review): 결과물을 시연하고 피드백을 받는 시간

목적: 완성된 제품 증분을 시연하고, 이해 관계자로부터 피드백 수집
참석자: 스크럼팀 + 이해관계자(stake holder, 고객, 경영진 등)
핵심: 보고가 아닌 협업. 다음엔 무엇을 하면 가장 가치 있을까요?

  • 스프린트 회고(Sprint Retrospective): 팀과 프로세스를 개선하는 시간

목적:
제품이 아닌, 우리 팀에 대해 이야기 하는 시간
사람, 관계, 프로세스, 도구 등 모든 것을 개선하기 위함
참석자: 오직 스크럼팀만
결과물: 다음 스프린트에서 즉시 실행할 구체적인 개선 항목 도출
핵심: 문제점을 불평만 하는 자리가 아니라, 해결책을 찾는 긍정적인 시간

parking lot: 회의의 흐름을 방해하지만, 놓치기는 아까운 주제가 나온다면 잠시 화이트보드 한켠에 마련된 주차장으로 회의가 끝난 뒤에 필요한 사람만 모여서 대화함

스크럼 산출물(Artifact)

  • 제품 백로그(Product Backlog):
    제품의 모든 것. 만들어야 할 것 들의 단일 목록

What? 제품에 필요한 모든 기능, 요구사항, 개선점 등을 담은
살아있는 우선순위 목록
Owner? 제품 책임자(PO). PO는 시장 가치에 따라 이 목록을 정렬하고 관리함
Analogy? 거대한 레스토랑의 전체 메뉴판.
가장 인기 있는 메뉴가 맨 위에 있습니다.

  • 스프린트 백로그(Sprint Backlog):
    이번 스프린트의 계획. 만들고 있는 것 들의 실시간 현황판

What? 이번 스프린트에서 만들기로 선택된
제품 백로그 아이템 + 그것을 완성하기 위한 구체적인 실행 계획
Owner? 개발자들. 이것은 그들 스스로 세운 계획이며, 매일 업데이트됨
Analogy? 오늘 레스토랑에서 만들기로 결정한 주방의 작업 보드

  • 제품 증분(Increment):
    우리가 만든 실질적인 가치. 완성한 것 들의 총합

What? 이번 스프린트에서 완성한 제품 백로그 아이템과 이전 스프린트들에서 완성된 모든 것들의 총합
핵심 조건? 반드시 사용 가능한 상태여야 하며, 완료의 정의를 충족해야 함
완료의 정의 예시(DoD, Definition of Done) 팀 전체가 공유하는 품질 기준의 체크 리스트로, 작업 중과 작업 완료를 구분하는 명확한 경계.
코드 리뷰 통과, 테스트 완료, 사용자 문서 업데이트 등이 있음

Purpose 스프린트 리뷰에서 시연되고, 이해관계자들에게 실질적인 가치를 증명하는 결과물. 이론적으로는 언제든 출시 가능해야함

Kanban

업무 단계를 시각화하고 진행 중인 일을 제한하여, 전체 프로세스 효율을 극대화하는 시각적 업무 관리 시스템

칸반의 핵심: 흐름 관리

  • ✓ 시각화(Visualizing)
    핵심 내용: 업무의 시작부터 끝을 보드 위에 나열
    기대 효과: 누구나 업무 상태를 즉시 파악(투명성)
  • ✓ WIP 제한(Limit WIP)
    핵심 내용: 동시에 진행하는 업무 개수를 엄격히 제한
    기대 효과: 멀티태스킹 방지 및 병목 현상 제거
  • ✓ 흐름 관리(Flow)
    핵심 내용: 정체 구간을 찾아 흐름이 끊이지 않게 조절
    기대 효과: 업무 완료 속도 향상 및 예측 가능성 증대

XP(eXtrme Programming)

  • TDD(Test Driven Development)
    테스트 코드 작성 → 테스트 코드를 해결하는 코드 작성 → 코드 개선 반복

테스트 코드 작성
오류가 생긴다면 그 즉시 해결 코드 작성
테스트 코드 작성은 매우 짧은 주기로 반복

StringReverserTest.java

public class StringReverserTest() {
	@Test
    void testReverseForSingleChars() {
    	StringReverser reverser = new StringReverser();
        // 테스트 코드 작성 먼저 시작했으므로 StringReverser 클래스가
        // 정의되지 않았기 때문에 오류 발생 → 해결 코드 작성
        // 추가적으로 클래스 이름을 StringReverser로 선언 (디자인)
    }
}

StringReverser.java

public class StringReverser {
	public String reverse() {
    // 클래스가 정의되었으므로 오류가 사라짐 → 테스트 코드 다시 작성
    }
}

위의 과정을 반복하면서 개발하는 방식이 TDD

빨간 줄(오류) 만들기 → 초록 줄(오류 해결) → 코드 개선

공동 소유권
테스트 코드를 통과시킬 수 있는 범위 내에서 코드를 자유롭게 수정 가능

✓ Regression(상처, 생채기) Testing
새로운 코드 변경이
기존에 잘 작동하던 기능을 망가뜨리지 않았는지 테스트하는 코드

Anti Pattern

흔히 사용되지만,
실제로는 문제를 더 악화시키거나 비효율적인 해결책의 패턴

Over-Testing

  • 테스트를 필요 이상으로 과도하게 작성하는 안티 패턴

Over Mocking

  • 테스트에서 Mock 객체를 필요 이상으로 사용하는 안티 패턴

Fragile Test

  • 실제 로직은 변경되지 않았는데 테스트가 깨지는 안티 패턴

Slow Test

  • 테스트 실행 속도가 너무 느린 안티 패턴

Mystery Guest

  • 테스트에 필요한 데이터나 설정이 테스트 코드 밖에 숨어 있어서
    테스트만 보고 무슨 테스트인지 알 수 없는 안티 패턴

Assertion Roullete

  • 하나의 테스트에 검증이 너무 많아서 어떤 검증이 실패했는지 알 수 없음

Non Repeatable

  • 실행할 때마다 결과가 달라지는 안티 패턴

Not Isolated

  • 테스트가 서로 영향을 주고받는 안티 패턴
profile
하이솝
이전 포스트

폭포수 모델

다음 포스트

AI와 소프트웨어 공학

0개의 댓글