📆 애자일(Agile)이란 무엇인가요?
애자일의 개념 알아보기
애자일(Agile)의 사전적 의미는 "재빠른", "민첩한"이라는 뜻이에요.
최소 단위, 즉 아주 최소한의 기능을 갖춘 제품을 먼저 시장에 배포하여 피드백과 테스트를 거친 다음, 이를 수정하여 다시 시장에 내놓아요. 그리고 이 과정을 짧은 주기로 반복하면서 점점 더 완전한 제품을 만들어 나가는 거죠. 즉, 완제품을 설계&제작하는 대신 작은 규모의 제품을 시장에 선출시하여 직접적인 피드백부터 받고 수정하는 방식이예요. 시장의 변화와 요구사항에 빠르게 적응하기 위한 방법론이죠.
애자일의 등장 배경 알아보기
애자일은 본래 소프트웨어 개발 방법론 중 하나인 애자일 프로세스(Agile Process)를 지칭하는 용어예요. 2001년 17명의 소프트웨어 엔지니어가 발표한
애자일 성명서 초안에서 탄생했지요.
왜 17명이나 되는 엔지니어가 모여 성명서를 발표했을까요? 먼저 애자일의 등장 배경부터 알아봐요.
애자일이 등장 전 소프트웨어 산업 전반은 워터폴(Waterfall) 방식으로 움직였어요. 워터폴 방식이란 순서에 따른 단계별 접근 방식이에요. 고객의 요구사항과 우선순위를 분석하고→이를 정의하고 문서화하여→정의된 요구사항을 충족시킬 수 있는 알맞은 모델을 디자인하고→앞 단계를 실제로 구현하고→구현된 기능이 제대로 작동하는지, 고객의 요구사항에 부합하는지 검증하여→지속적 유지보수를 위한 체계를 마련하는 방식이죠. 한 마디로, 제품 개발에 앞서 고객의 요구사항을 철저히 분석하고 정의한하고 이를 완벽히 반영한 설계안을 만드는 개발 방식이라고 할 수 있겠네요.
너무 당연한 거 아니야? 제품 개발에 앞서 고객의 요구사항을 철저히 분석해야 제대로 설계안을 만들어서 엉뚱한 낭비를 줄일텐데? 이런 생각을 하는 성장메이트님이 있을 거예요. 사실 틀리지 않은 말이에요. 제품 개발에 앞서 고객의 요구사항을 분석하고 설계안을 만드는 건, 어디까지나 효율적인 작업 프로세스를 위한 일이니까요. 하지만 이상과 현실은 달랐어요.
"사람들은 무엇을 경험하기 전까지 자신이 무엇을 원하는지 모른다."라는 말, 너무나 유명한 말이지요? 스티브 잡스가 남긴 이 말은, 사용자의 진짜 욕구는 요구사항을 분석한 결과와 다를 수 있음을 일깨우는 경구이지요. 사용자의 요구에 충실한 설계안을 만들어도, 그게 정말 시장에 통할지는 출시 전 까지는 알 수 없어요. 그리고 100% 실행되는 계획이 없듯, 아무리 완벽한 설계안이라도 현실에 그대로 구현되는 일은 현실적으로 불가능했고요. 그리고 제품 설계에 쏟는 시간이 길어지는 반면, 시장의 변화 주기는 점점 짧아졌기 때문에 제품이 출시될 즈음 시장의 요구 사항과 어긋나는 경우도 발생했고요.
애자일 성명서의 발표는 이러한 워터폴 방식의 한계를 벗어나기 위해, 기획 중심에서 실행 중심으로 나아가겠다는 표명으로 볼 수 있을 거예요.
애자일 vs 워터폴 방식, 비교해보며 알아봐요!
애자일(Agile) vs 워터폴(Waterfall), 두 방식을 비교 분석 해볼까요?
- 실행 우선 vs 기획 우선 : 애자일 방식은 짧고 반복적인 스프린트(sprint)로 구성되어, 우선 제품을 만들어 본 다음 수정을 거치죠. 반면, 워터폴 방식은 고객 요구사항에 따라 설계와 개발이 순차적으로 진행돼요. 기획안이 이미 확정되어 있기 때문에 도중에 다른 팀이 합류하더라도 안정적인 운영이 가능해요
- 유연함 vs 체계적 : 애자일 방식은 여러 소규모 팀들이 과제를 동시에 진행하여, 문제 발생 시 빠르고 유연하게 대처 가능해요. 워터폴 방식은 제품의 앞단계가 개발되고 난 뒤에 뒷 부분이 시작되다 보니 프로젝트 관리가 쉽고 안정적이지만 유연성이 떨어지요.
- 고객 중심적 vs 프로젝트 중심적 : 애자일 방식은 수시로 고객의 요구 사항을 반영하기 때문에 고객의 요구에 부합하는 제품을 만들 수 있지만, 고객이 일일히 요구 사항을 검토해야 하는 어려움이 있어요. 반대로, 워터폴 방식은 협업이 제한적인 고객을 상대로 할 때 안정적 운영이 가능하지요.
- 불확실성이 높은 환경 vs 예측가능성이 높은 환경 : 애자일 방식은 수시로 테스트를 거치기 때문에 빠른 테스팅과 문제 발견이 가능하지만 반대로 지나치게 많은 작업량 때문에 리소스가 부족하거나 예기치 못한 리스크가 발생할 수 있어요. 워터폴 방식은 개발 목표와 사용 리소스가 이미 확정되어 있기 때문에 안정적 상황에서는 결과와 리스크를 통제하기 훨씬 쉬워요.