애자일 방식이 도입된 이유와 용어 정리

Ⅰ. 서론

현재 많은 IT기업에서 도입하여 사용하고 있는 애자일 방식을 알아보고자 한다. 기존 IT기업들이 어떤 문제점에 봉착하여 애자일 방식을 도입하게 되었는지, 애자일에 사용되는 용어는 어떤 것이 있는지 알아본다.

Ⅱ. 본론

1. 기존 방식의 문제점과 애자일이 도입된 이유

전통적 개발 방식인 폭포수 모델은 빠르게 변화하는 시장 환경에 대응하지 못하였다. 폭포수 모델은 모든 단계가 순차적으로 진행되며 이전 단계로 돌아가는 것이 어렵다. 폭포수 모델의 각 단계는 상위 단계에 종속성을 갖고 있기에, 해당 상위 단계로 돌아가 수정할 경우, 하위 단계 모두를 다시 수정해야 하는 경우가 생긴다. 이런 구조 때문에 단계가 진행될수록 변경 비용이 기하급수적으로 증가한다. 이는 결함 수정 비용 곡선으로 설명될 수 있다.

Traditional cost of change curve

또한, 폭포수 모델은 제품 출시 전까지 고객의 피드백을 반영하기 어렵다. 이러한 이유로 개발이 잘못된 방향으로 진행될 가능성이 높고, 이는 제품 품질의 저하로 이어질 수 있다.

현실 세계에서는 요구사항이 고정되어 있지 않고, 시장과 고객의 니즈가 계속 변화한다. 그러나 폭포수 모델은 초기에 모든 것을 계획하고 확정한 후 개발하는 방식이기 때문에, 변화에 유연하게 대응하기가 힘들다. 이는 요구사항이 바뀌어도 쉽게 돌아가 반영할 수 없는 경직된 구조를 가진다. 이러한 문제를 개선하기 위하여 신속한 제품 출시와 함께 빠르게 변하는 요구사항을 반영하기 위해 애자일 방식이 도입되었다.

2. 애자일 방식의 장점

애자일 방식은 기존의 폭포수 모델보다 여러 측면에서 우수한 점이 있다. 가장 큰 차이점은 유연성이다. 애자일은 짧은 주기의 반복(iteration)을 통해 개발이 이루어져 요구사항 변경이나 시장 변화에 빠르게 대응할 수 있다.

또한, 애자일은 고객과 사용자의 의견을 적극적으로 반영할 수 있다. 지속적인 피드백을 통해 기능을 개선하고, 실제 사용자와 이해관계자의 요구사항을 신속하게 적용할 수 있다.

리스크 관리 측면에서도 애자일은 강점을 가진다. 애자일 방식에서는 짧은 주기로 기능을 배포하고 검증하므로, 문제가 발생하면 신속하게 수정할 수 있다.

애자일은 팀워크와 협업을 강화하는 데도 효과적이다. 개발팀, 기획자, 디자이너 등 다양한 역할의 팀원들이 긴밀하게 협력하며, 자율적으로 의사결정을 내릴 수 있다.

애자일 방식은 빠른 가치 제공이 가능하다는 장점이 있다. 최소 기능 제품(MVP, Minimum Viable Product)을 신속하게 출시하여 고객에게 가치를 제공하고, 이후 점진적으로 개선해 나갈 수 있다.

3. 애자일 용어

애자일 매니페스토(Agile Manifesto)

애자일 매니페스토는 2001년 미국 유타주의 스노우버드에서 17명의 소프트웨어 개발자들이 모여 발표한 문서로, 보다 유연하고 효과적인 소프트웨어 개발 방식을 제시하는 철학적 선언이다. 애자일 매니페스토에는 핵심 가치 4가지와 애자일 원칙 12가지가 있다.

핵심 가치 4가지

• 프로세스와 도구보다는 개인과 상호작용을 가치 있게 여긴다
• 포괄적인 문서보다 작동하는 소프트웨어를 가치 있게 여긴다
• 계약 협상보다 고객과의 협력을 가치 있게 여긴다
• 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다

핵심 원칙 12 가지

• 고객 만족을 위해 지속적으로 가치를 제공하는 것이 최우선이다
• 변화하는 요구 사항을 적극적으로 수용한다
• 짧은 주기의 반복적인 개발을 통해 동작하는 소프트웨어를 자주 제공한다
• 비즈니스 담당자와 개발자는 긴밀히 협력해야 한다
• 동기부여된 개인들로 팀을 구성하고, 신뢰를 기반으로 자율성을 부여해야 한다
• 직접적인 커뮤니케이션이 가장 효과적이다
• 동작하는 소프트웨어가 진척도의 주요 척도이다
• 애자일 프로세스는 지속 가능한 개발 속도를 유지해야 한다
• 기술적 탁월성과 좋은 설계를 지속적으로 추구해야 한다
• 단순함이 핵심이다
• 최고의 아키텍처, 요구 사항, 설계는 자기 조직화된 팀에서 나온다
• 정기적으로 팀이 자신을 돌아보고, 효율성을 개선해야 한다

애자일 매니페스토는 단순한 프로세스나 방법론이 아니라 사고방식과 철학에 가깝다. 그렇기 때문에 실제 프로젝트에 적용할 때는 조직의 특성에 맞게 가치를 유지하면서도 유연하게 조정하는 것이 중요하다.

반복적 개발과 증분 개발

반복적 개발은 소프트웨어를 한 번에 완성하려고 하지 않고, 여러 번의 반복(iteration)을 통해 점진적으로 개선하는 방식이다. 초기에는 기본 기능을 갖춘 제품을 만들고, 이후 반복하면서 개선해 나간다. 매 반복마다 피드백을 반영하여 소프트웨어를 수정하고 발전시킨다. 그렇기 때문에 실패를 빨리 발견하고 개선할 수 있다.

증분 개발은 소프트웨어를 한꺼번에 개발하는 것이 아니라, 작은 부분(증분, increment) 단위로 개발하여 점차 확장하는 방식이다. 처음부터 전체 기능을 만들지 않고, 핵심 기능을 먼저 개발한 후 기능을 추가한다. 각 증분은 독립적으로 동작 가능해야 한다. 고객이 빠르게 사용해 볼 수 있도록 작은 배포 단위를 가진다.

애자일에서는 반복적 개발과 증분 개발을 결합하여 적용한다. 이렇게 하면, 빠른 피드백을 반영하면서 점진적으로 새로운 기능을 추가할 수 있다.

애자일 단위

Epic

가장 큰 규모의 작업 단위이다. 제품 개발의 주요 기능과 고객 요구 사항을 반영한다. 필요에 따라 더 작은 Feature또는 User Story로 나누어진다. Epic의 예시로는 “온라인 쇼핑몰 결제 시스템 구축”, “사용자 프로필 관리 기능 개발”과 같은 것이 있다.

Feature

특정 Epic을 이루는 핵심 기능 단위이다. 사용자가 독립적으로 사용할 수 있는 하나의 기능 단위이다. Feature는 애자일에서 많이 사용되지만 공식적인 단위로는 정의되어 있지 않다. 하지만 실무에서는 Epic과 User Story의 중간 단위로 활용되는 경우가 많다. Feature의 예시로는 “신용카드 결제 추가”, “소셜 로그인 기능 추가”와 같은 것이 있다.

User Story

사용자의 관점에서 원하는 기능을 서술한 문장이다. 애자일 개발에서 가장 중요한 단위로, 보통 “As a [사용자], I want [기능], so that [이유]”형태로 작성된다. User Story는 작고 독립적인 기능 단위여야 하며 완료된 후에는 배포 가능한 상태여야 한다. 또한, 사용자가 실제로 가치를 느낄 수 있는 기능을 포함해야 한다. User Story의 예시로는 “나는 고객으로서, 신용카드를 이용해 결제할 수 있다.”, “나는 사용자로서, 이메일을 사용하여 계정을 만들 수 있다.”와 같은 것들이 있다.

Task

가장 작은 규모의 작업 단위이다. User Story를 개발하기 위해 필요한 세부적인 개발 작업을 Task로 나눈다. 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

지속적 통합(Continuous Integration) 및 지속적 제공/배포(Continuous Delivery/Deployment)를 의미한다. 소프트웨어 개발 라이프사이클을 간소화하고 가속화하는 것을 목표로 한다.

CI는 코드 변경 사항을 공유 소스 저장소(Repository)에 자동으로 자주 통합하는 사례를 나태낸다. CD는 코드 변경 사항의 통합/테스트/제공을 나타내는 프로세스로, 두 가지 부분(Delivery/Deployment)으로 구성된다.

스파이크(Spike)

가장 간단한 프로그램을 사용하여 잠재적인 솔루션을 탐색하는 익스트림 프로그래밍에서 비롯된 제품 개발 방법이다.

벨로시티(Velocity)

벨로시티는 스프린트당 얼마나 많은 스토리 포인트를 획득할 수 있는지를 나타내는 값이다. 여기서 스토리 포인트를 획득한다는 것은 사용자 스토리를 실제 동작하는 기능으로 구현해 전달한 경우를 말한다.

스토리 포인트(Story Point)

스토리 포인트는 스토리를 완전히 구현하는데 필요로 하는 전반적인 노력의 추정치를 나타내는 단위이다. 스토리 포인트는 추상적이고 직관적인 특징을 가진다. 그 때문에 몇 점의 포인트를 책정해야 할지 스트레스를 받을 필요는 없으며 수정 또한 가능하다. 스토리 포인트를 책정할 땐 팀의 모두가 참여하여 여러 가지 사항을 고려하고 그 값을 추정한다. 스토리 포인트의 고려 요소로는 복잡성, 작업량, 위험, 불확실성 등이 있다.

최소 기능 제품(MVP, Minimum Viable Product)

MVP는 고객이 실제 실행하려는 비즈니스가 올바로 동작하는 최소한의 기능을 갖춰야 한다. MVP를 통해 고객에게 필요한 기능을 빠르게 제공할 수 있고 동시에 피드백을 받을 수 있다.

Ⅲ. 결론

지금까지 기존의 폭포수 모델이 가진 한계점과 애자일 방식이 새로운 흐름으로 자리 잡게 된 이유를 알아보았다. 그리고 애자일 방식에서 자주 사용되는 용어를 나열해 보았다.

애자일 방식은 하나의 방법론이며 많은 파생이 존재한다. 그렇기에 공식처럼 정해진 틀은 없다. 애자일 방식의 사용자는 자신의 상황을 애자일 방식에 맞춰가기보다는 기존의 애자일 방식을 자신의 상황에 맞게 변형시켜 사용하는 것이 바람직하다.