애자일(Agile)은 오늘날 수많은 IT 기업이 도입해 사용하는 소프트웨어 개발 방식이다. 이 글에서는 기존 개발 방식이 어떤 한계에 부딪혀 애자일이 등장하게 되었는지, 그리고 애자일을 이해하는 데 꼭 필요한 핵심 용어에는 어떤 것이 있는지 입문자 눈높이에서 정리한다.
애자일이 도입된 이유: 폭포수 모델의 한계
전통적 개발 방식인 폭포수 모델은 빠르게 변화하는 시장 환경에 대응하지 못했다. 폭포수 모델은 모든 단계가 순차적으로 진행되며 이전 단계로 돌아가기가 어렵다. 각 단계는 상위 단계에 종속성을 갖기 때문에, 상위 단계로 돌아가 수정하면 하위 단계 모두를 다시 수정해야 하는 경우가 생긴다. 이런 구조 때문에 단계가 진행될수록 변경 비용이 기하급수적으로 증가한다. 이는 결함 수정 비용 곡선으로 설명할 수 있다.
Traditional cost of change curve
또한 폭포수 모델은 제품 출시 전까지 고객의 피드백을 반영하기 어렵다. 이 때문에 개발이 잘못된 방향으로 진행될 가능성이 높고, 이는 제품 품질 저하로 이어질 수 있다.
현실에서는 요구사항이 고정되어 있지 않고 시장과 고객의 니즈가 계속 변한다. 그러나 폭포수 모델은 초기에 모든 것을 계획·확정한 후 개발하는 방식이라 변화에 유연하게 대응하기 힘들다. 요구사항이 바뀌어도 쉽게 돌아가 반영할 수 없는 경직된 구조인 것이다. 이러한 문제를 개선해 신속한 제품 출시와 빠르게 변하는 요구사항 반영을 가능하게 하려고 애자일 방식이 도입되었다.
애자일 방식의 장점
애자일 방식은 기존의 폭포수 모델보다 여러 측면에서 우수하다. 주요 장점을 정리하면 다음과 같다.
- 유연성: 짧은 주기의 반복(iteration)을 통해 개발하므로 요구사항 변경이나 시장 변화에 빠르게 대응할 수 있다.
- 고객 의견 반영: 지속적인 피드백을 통해 기능을 개선하고, 실제 사용자와 이해관계자의 요구사항을 신속하게 적용할 수 있다.
- 리스크 관리: 짧은 주기로 기능을 배포하고 검증하므로, 문제가 발생하면 신속하게 수정할 수 있다.
- 팀워크와 협업 강화: 개발팀·기획자·디자이너 등 다양한 역할의 팀원이 긴밀하게 협력하며 자율적으로 의사결정을 내린다.
- 빠른 가치 제공: 최소 기능 제품(MVP)을 신속하게 출시해 고객에게 가치를 제공하고, 이후 점진적으로 개선해 나갈 수 있다.
애자일 핵심 용어 정리
애자일 매니페스토(Agile Manifesto)
애자일 매니페스토는 2001년 미국 유타주 스노우버드에서 17명의 소프트웨어 개발자가 모여 발표한 문서로, 보다 유연하고 효과적인 소프트웨어 개발 방식을 제시하는 철학적 선언이다. 애자일 매니페스토에는 핵심 가치 4가지와 애자일 원칙 12가지가 있다.
핵심 가치 4가지
- 프로세스와 도구보다 개인과 상호작용을 가치 있게 여긴다.
- 포괄적인 문서보다 작동하는 소프트웨어를 가치 있게 여긴다.
- 계약 협상보다 고객과의 협력을 가치 있게 여긴다.
- 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.
핵심 원칙 12가지
- 고객 만족을 위해 지속적으로 가치를 제공하는 것이 최우선이다.
- 변화하는 요구사항을 적극적으로 수용한다.
- 짧은 주기의 반복적인 개발을 통해 동작하는 소프트웨어를 자주 제공한다.
- 비즈니스 담당자와 개발자는 긴밀히 협력해야 한다.
- 동기부여된 개인들로 팀을 구성하고, 신뢰를 기반으로 자율성을 부여해야 한다.
- 직접적인 커뮤니케이션이 가장 효과적이다.
- 동작하는 소프트웨어가 진척도의 주요 척도이다.
- 애자일 프로세스는 지속 가능한 개발 속도를 유지해야 한다.
- 기술적 탁월성과 좋은 설계를 지속적으로 추구해야 한다.
- 단순함이 핵심이다.
- 최고의 아키텍처, 요구사항, 설계는 자기 조직화된 팀에서 나온다.
- 정기적으로 팀이 스스로를 돌아보고 효율성을 개선해야 한다.
애자일 매니페스토는 단순한 프로세스나 방법론이 아니라 사고방식과 철학에 가깝다. 그렇기 때문에 실제 프로젝트에 적용할 때는 조직의 특성에 맞게 가치를 유지하면서도 유연하게 조정하는 것이 중요하다.
반복적 개발과 증분 개발
반복적 개발은 소프트웨어를 한 번에 완성하려 하지 않고, 여러 번의 반복(iteration)을 통해 점진적으로 개선하는 방식이다. 초기에는 기본 기능을 갖춘 제품을 만들고, 이후 반복하면서 개선해 나간다. 매 반복마다 피드백을 반영해 소프트웨어를 수정하고 발전시키므로 실패를 빨리 발견하고 개선할 수 있다.
증분 개발은 소프트웨어를 한꺼번에 개발하지 않고, 작은 부분(증분, increment) 단위로 개발해 점차 확장하는 방식이다. 처음부터 전체 기능을 만들지 않고 핵심 기능을 먼저 개발한 후 기능을 추가한다. 각 증분은 독립적으로 동작 가능해야 하며, 고객이 빠르게 사용해 볼 수 있도록 작은 배포 단위를 가진다.
애자일에서는 반복적 개발과 증분 개발을 결합해 적용한다. 이렇게 하면 빠른 피드백을 반영하면서 점진적으로 새로운 기능을 추가할 수 있다.
애자일 작업 단위 (Epic·Feature·User Story·Task)
Epic
가장 큰 규모의 작업 단위다. 제품 개발의 주요 기능과 고객 요구사항을 반영하며, 필요에 따라 더 작은 Feature 또는 User Story로 나뉜다. 예시로는 “온라인 쇼핑몰 결제 시스템 구축”, “사용자 프로필 관리 기능 개발” 등이 있다.
Feature
특정 Epic을 이루는 핵심 기능 단위로, 사용자가 독립적으로 사용할 수 있는 하나의 기능이다. Feature는 애자일에서 많이 사용되지만 공식 단위로 정의되어 있지는 않다. 다만 실무에서는 Epic과 User Story의 중간 단위로 활용되는 경우가 많다. 예시로는 “신용카드 결제 추가”, “소셜 로그인 기능 추가” 등이 있다.
User Story
사용자 관점에서 원하는 기능을 서술한 문장이다. 애자일 개발에서 가장 중요한 단위로, 보통 “As a [사용자], I want [기능], so that [이유]” 형태로 작성된다. User Story는 작고 독립적인 기능 단위여야 하며, 완료된 후에는 배포 가능한 상태여야 한다. 또한 사용자가 실제로 가치를 느낄 수 있는 기능을 포함해야 한다. 예시로는 “나는 고객으로서, 신용카드를 이용해 결제할 수 있다.”, “나는 사용자로서, 이메일을 사용해 계정을 만들 수 있다.” 등이 있다.
Task
가장 작은 규모의 작업 단위다. User Story를 개발하기 위해 필요한 세부적인 개발 작업을 Task로 나눈다. Task는 보통 하루, 이틀 내에 끝낼 수 있는 단위로 쪼개진다. 예시로는 “결제 페이지 UI 디자인”, “백엔드 API 개발”, “단위 테스트 작성” 등이 있다.
스프린트(Sprint)
스프린트는 한 달 또는 그보다 짧은 기간 동안 팀이 목표로 정해 놓은 일을 수행하는 것을 말한다. 새로운 스프린트는 직전 스프린트가 끝나는 즉시 시작해야 한다. 스프린트를 진행하는 도중에는 목표 달성을 방해하는 변경을 해서는 안 된다. 또한 필요한 수준까지 Backlog를 정제하고 범위를 명확히 하며, 필요한 경우 프로덕트 오너(PO, Product Owner)와 다시 협상할 수 있다.
스크럼(Scrum)
스크럼은 전 세계에서 가장 많이 사용하는 대표적인 애자일 방법론이다. 고객의 요구사항을 충족시키는 데 초점을 맞추며, 짧은 개발 주기를 갖고 점진적이며 경험적으로 시스템을 지속해서 개발·전달하는 기법이다. 스크럼은 2~4주 주기의 Sprint 반복이며, 스프린트는 Product Backlog, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retro의 순서로 구성된다.
Product Backlog
제품 요구사항(Product Requirement)을 정의하고 이번 분기의 목표(OKR)가 설정되면, 목표 달성을 위한 개발 Task 목록을 만들고 우선순위에 따라 나열한다. 이 목록이 Product Backlog이며, 스프린트를 반복하며 백로그에서 P0 아이템부터 꺼내어 개발한다.
Sprint Planning
스프린트가 시작되는 시점에 개발 플래닝을 한다. Backlog에 있던 아이템 중 이번 스프린트에서 진행할 아이템을 꺼내 담당자를 정한다. 이때 매니저(SDM, Software Development Manager)가 엔지니어를 지정하는 것이 아니라, 업무를 맡고 싶은 개인이 가져간다.
Daily Scrum
매일 30분씩 스크럼 미팅을 통해 어제 한 일, 오늘 할 일을 리뷰한다. 그리고 프로젝트를 방해하는 요소(이슈, issue)가 있다면 공유하고 도움이 필요한 사항을 이야기한다. 애자일에서는 Stand up 미팅을 추천한다. 불필요한 이야기를 없애기 위해 말 그대로 서서 이야기하고, 한 명당 1~2분 내로 이야기를 끝낸다.
Sprint Review
스프린트가 종료되는 시점에 완료한 일을 살펴보고, 있었던 일을 떠올리며, 다음 스프린트에 할 일을 리뷰한다.
Sprint Retro
회고는 스프린트가 끝나는 시점마다 진행해도 되고, 개발 착수·테스트·완료 등 특정 주기를 갖고 진행해도 된다. 주기성을 갖고 회고를 진행하는 조직 문화를 만드는 것이 중요하다. 또한 회고는 문제를 추궁하거나 프로젝트 문제점에 대한 해결 방안을 만드는 자리가 아니다. 프로젝트를 수행하며 느낀 점을 공유하고, 개선점을 만들어 다음 기간에 적용하는 것이 주목적이다. 회고에서는 Keep, Problem, Try 세 가지 주제에 대해 돌아가며 이야기하며, 참석한 모든 사람이 한 가지씩 말하는 것이 중요하다.
- Keep: 좋았던 점을 기반으로 도출하며, 앞으로 프로젝트를 진행할 때 계속 유지되어야 할 사항.
- Problem: 아쉬웠던 점을 기반으로 도출하며, 앞으로 개선되어야 할 사항.
- Try: Problem을 기반으로 다음 스프린트에 적용해 볼 만한 아이템.
칸반(Kanban)
칸반(Kanban)은 간판의 일본식 발음으로, 도요타 생산 방식(TPS-JIT)에서 유래했다. 칸반은 보드 형태의 업무 시각화 도구이며, 모든 업무(프로세스)를 함께 공유해 업무의 가시성을 확보하고 투명한 업무 처리를 가능하게 하는 데 목적이 있다. 또한 문제가 발생했을 때 신속하게 해결해 프로젝트 지연을 예방할 수 있다. 칸반 보드는 기본적으로 계획(To-Do), 진행 중(Doing), 완료(Done)의 형태를 사용한다.
CI/CD
CI/CD는 지속적 통합(Continuous Integration) 및 지속적 제공/배포(Continuous Delivery/Deployment)를 의미하며, 소프트웨어 개발 라이프사이클을 간소화하고 가속화하는 것을 목표로 한다. CI는 코드 변경 사항을 공유 소스 저장소(Repository)에 자동으로 자주 통합하는 사례를 나타낸다. CD는 코드 변경 사항의 통합·테스트·제공을 나타내는 프로세스로, 두 가지 부분(Delivery/Deployment)으로 구성된다.
스파이크(Spike)
스파이크는 가장 간단한 프로그램을 사용해 잠재적인 솔루션을 탐색하는, 익스트림 프로그래밍에서 비롯된 제품 개발 방법이다.
벨로시티(Velocity)와 스토리 포인트(Story Point)
벨로시티는 스프린트당 얼마나 많은 스토리 포인트를 획득할 수 있는지를 나타내는 값이다. 여기서 스토리 포인트를 획득한다는 것은 사용자 스토리를 실제 동작하는 기능으로 구현해 전달한 경우를 말한다.
스토리 포인트는 스토리를 완전히 구현하는 데 필요한 전반적인 노력의 추정치를 나타내는 단위다. 스토리 포인트는 추상적이고 직관적인 특징을 가지므로, 몇 점을 책정해야 할지 스트레스를 받을 필요가 없으며 수정도 가능하다. 스토리 포인트를 책정할 때는 팀의 모두가 참여해 여러 사항을 고려하고 값을 추정한다. 고려 요소로는 복잡성, 작업량, 위험, 불확실성 등이 있다.
최소 기능 제품(MVP, Minimum Viable Product)
MVP는 고객이 실제 실행하려는 비즈니스가 올바로 동작하는 최소한의 기능을 갖춰야 한다. MVP를 통해 고객에게 필요한 기능을 빠르게 제공할 수 있고, 동시에 피드백을 받을 수 있다.
정리
지금까지 기존 폭포수 모델의 한계와, 애자일 방식이 새로운 흐름으로 자리 잡은 이유를 알아보았다. 그리고 애자일에서 자주 사용되는 핵심 용어를 정리해 보았다.
애자일은 하나의 방법론이며 많은 파생이 존재한다. 그렇기에 공식처럼 정해진 틀은 없다. 애자일을 사용할 때는 자신의 상황을 애자일 방식에 맞추기보다, 기존의 애자일 방식을 자신의 상황에 맞게 변형해 사용하는 것이 바람직하다.
💬 댓글 0