본론으로 들어가기 전에, 프로젝트의 최종 목표를 명확히 하는 것이 중요합니다. 지금으로부터 한 달, 반년, 일 년 후의 결과물이 어떤 모습일지 구체적으로 그려보는 것이 좋습니다. 이렇게 하면 예측 가능성, 유연성, 민첩성, 시장 출시 속도 및 비용 효율성에 대한 현실적인 관점을 설정하고, 기본 기대치를 수립할 수 있습니다.
오늘날 워터폴 방식의 프로젝트를 고수하는 것은 시대착오적인 생각일 수 있습니다. 특히 급변하는 시장에 신속하게 대응해야 할 필요성이 더욱 커지고 있는 상황에서는 민첩성이 필수불가결합니다. 하지만, 만약 목표가 처음부터 명확하고 제한적인 기능을 가진 제품을 1년 후에 출시하는 것이며, 애자일 방법론 경험이 없는 팀으로 구성되었다면 보수적인 접근 방식을 택하여 워터폴 방식을 고려해볼 수 있습니다.
그러나 모든 프로젝트가 이렇게 단순하게 결정될 수 있는 것은 아닙니다. 프로젝트에 어떤 방법론이 더 적합한지 더 자세히 살펴보겠습니다.
워터폴 방식이란 무엇인가?
이미 널리 알려진 정의를 나열하는 대신, 워터폴 방식 프로젝트의 실제 진행 과정을 살펴보겠습니다.
이 전체 과정은 수개월에서 수년이 걸릴 수 있습니다. 예상대로 사용자는 이 과정이 끝날 때까지 결과를 볼 수 없습니다. 따라서 긴 기다림 끝에 성공 또는 실패의 순간이 찾아옵니다.
만약 오랜 기간 동안 상황이 바뀌어 최종 제품이 다소 달라져야 한다면, 이는 변경 요청으로 처리됩니다. 설계를 다시 검토하고, 재작업하고, 다시 승인해야 합니다. 이러한 변경으로 인해 전체 일정이 늘어납니다. 모든 변경 사항에 대해 이전의 전체 과정을 다시 시작해야 합니다.
반면, 단계별 정의가 명확하고, 각 단계에 대한 예산과 일정이 고정되어 있다면 첫 번째 결과를 얻는 데 오랜 시간이 걸리더라도, 중간에 변경될 가능성이 거의 없다면 여전히 선호할 수 있는 선택이 될 수 있습니다.
애자일 방식은 어떤 모습인가?
애자일 환경에서 프로젝트가 어떻게 진행되는지 살펴보겠습니다.
위의 내용은 간략한 요약이지만, 워터폴 방식과의 차이점은 분명합니다. 빠른 피드백, 적응, 현재 요구 사항 반영, 가능한 한 빨리 가치 있는 제품 제공은 워터폴 방식에서 찾아볼 수 없는 장점입니다.
애자일 대 워터폴
적절한 프로젝트 관리 방법론이 없다면 프로젝트는 성공하기 어렵습니다. 이는 프로젝트를 구성하는 팀의 프로세스, 지표, 평가 및 일반적인 작업 방식을 정의하는 것을 의미합니다.
팀은 따라야 할 규칙, 이정표의 내용, 도달 시점, 성공을 측정하고 평가하는 방법을 알아야 합니다. 동시에 이해관계자는 프로젝트에서 무엇을 기대할 수 있는지, 언제 첫 번째 결과물을 확인할 수 있는지 이해해야 합니다.
일반화하자면, 클라우드 환경에서 운영되는 프로젝트는 애자일 방법론을 선호하는 경향이 높습니다(적어도 그래야 합니다). 반면, 온프레미스 인프라를 사용하는 프로젝트는 여전히 워터폴 방식을 선호하는 경우가 많습니다. 이는 자연스러운 결과입니다.
클라우드 환경은 끊임없이 변화하는 환경에 맞춰 설계되었습니다. 새로운 현실에 최대한 빠르게 적응합니다(다양한 “탄력적인” 서비스 활용). 온프레미스 환경은 종종 초기에 사전 정의됩니다. 시간이 지남에 따라 변경하기가 어렵기 때문에 팀은 프로젝트 기간 내내 결정된 변수를 사용하여 작업하게 됩니다.
다음은 애자일 방식과 워터폴 방식의 주요 차이점을 요약한 표입니다.
| 특성 | 워터폴 방식 | 애자일 방식 |
| 사용자 요구 사항 처리 | 변경은 공식적인 프로세스(변경 요청)를 거쳐 처리됩니다. 재작업이 필요하며 비용과 일정에 영향을 미칠 수 있습니다. | 변경 사항은 표준 프로세스의 일부로 수용되며, 비용이나 일정에 큰 영향을 주지 않습니다. |
| 프로젝트 계획 및 범위 | 처음에 범위를 정의하고 이를 준수합니다. 단계는 엄격하며 원래 계획을 따릅니다. | 최종 제품에 대한 명확한 비전이 있지만, 변경이 허용됩니다. 작업은 스프린트로 구성되어 유연하게 진행됩니다. |
| 프로젝트 진행 상황 추적 | 각 단계 내 진행 상황을 추적합니다. 한 단계의 지연은 전체 프로젝트 일정에 영향을 미칠 수 있습니다. | 각 스프린트가 끝날 때 데모 세션을 통해 진행 상황을 추적합니다. 실행 가능한 제품에 중점을 둡니다. |
| 팀 협업 | 다양한 프로젝트 단계에서 다양한 사람이 작업하며, 상호 작용이 제한적입니다. | 팀 구성원 및 이해 관계자 간의 지속적인 의사소통이 가능한 교차 기능 팀입니다. |
| 위험 관리 | 각 단계의 상태를 추적합니다. 계획을 준수하면서 사후적으로 위험에 대응합니다. | 팀과 활동 간의 종속성을 사전에 해결하는 데 중점을 둡니다. 예상되는 위험을 제거하기 위해 계획을 조정합니다. |
| 구현 프레임워크 | 전통적인 방법론입니다. | 애자일 방식에 적응하려면 혁신적인 접근 방식이 필요합니다. 습관과 사고방식의 변화가 필요합니다. |
하지만, 이러한 선택은 프로젝트 실행의 여러 측면을 정의합니다.
#1. 프로젝트 요구 사항 및 변경 관리
선택을 결정하는 가장 중요한 요소 중 하나는 사용자의 요구 사항을 처리하는 방식입니다. 또한 이미 합의된 요구 사항을 나중에 변경해야 하는 경우 어떤 절차를 따르게 되는지도 중요합니다.
워터폴 방식의 프로젝트에서는 이해관계자가 처음부터 모든 요구 사항을 정의하고 승인합니다. 이러한 요구 사항이 변경되면 변경 요청으로 처리됩니다. 변경 요청은 다시 검증하고 합의하고 확인해야 합니다.
그 시점까지 이미 수행된 모든 작업을 검토하고 다시 시작해야 합니다. 또한, 비용을 재조정해야 합니다. 이는 원래 계약에 포함되지 않은 추가 작업이기 때문입니다. 최악의 경우 전체 프로젝트 일정도 연장될 수 있습니다.
애자일 방식에서는 변경 사항을 환영합니다. 변경 사항을 일상 업무의 일부로 처리합니다. 프로젝트의 비전을 유지하려면 변경이 필수적이라는 점을 이해관계자들이 인지합니다(최신 스프린트 데모 결과 등). 그런 다음 다음 스프린트에 대한 변경 사항을 즉시 예약합니다.
기존 콘텐츠는 변경에 따라 조정되며, 팀은 새로운 요구 사항에 맞춰 작업을 계속합니다. 시간이나 비용 손실은 발생하지 않습니다. 새로운 상황에 즉시 적응하고, 원래 계획을 새로운 계획으로 변경하면 됩니다. 별도의 변경 요청 관리가 전혀 필요하지 않습니다. 이러한 모든 과정이 스프린트 계획의 일부입니다.
#2. 프로젝트 계획 및 범위
워터폴 방식의 프로젝트는 초기 단계에서 모든 범위를 설정하고 확정합니다. 이 범위를 중심으로 프로젝트 계획을 수립합니다. 그런 다음 프로젝트 기간을 특정 단계(분석, 설계, 개발, 테스트, 배포, 지원 및 유지 관리)로 나누고, 해당 단계를 중심으로 팀과 리소스를 조정합니다. 대부분의 프로젝트 일정에서 주요 목표는 비용과 시간 측면에서 원래 계획을 최대한 준수하는 것입니다.
애자일 프로젝트는 엄격한 계획 대신 최종 제품에 대한 비전을 가집니다. 최종 상태는 분명하지만, 그 상태에 도달하는 방법은 자유롭게 변경할 수 있습니다. 또한, 프로젝트 일정은 프로젝트 작업팀의 수요 및 용량 경험에 대한 추정을 기반으로 정의되고 합의됩니다. 계획에는 별도의 단계가 없습니다. 대신 각 스프린트는 팀이 제품을 성공적으로 출시하는 데 필요한 모든 활동을 포함하는 작은 단계입니다.
결론적으로 워터폴 방식의 프로젝트는 변경 사항을 처리해야 할 복잡성(그리고 공급업체가 추가 자금을 확보할 수 있는 기회)으로 간주합니다. 반대로 애자일 프로젝트는 변화를 추가적인 결과(더 적합한 최종 제품이라는 결과를 제외하고) 없이 일상적인 업무로 취급합니다.
#3. 프로젝트 진행 상황 추적
워터폴 방식의 프로젝트에서는 프로젝트 단계 내에서 계획의 진행 상황을 추적합니다. 분석 단계가 완료되기 전에는 설계 단계를 시작할 수 없고, 전체 빌드가 완료되기 전에는 테스트를 시작할 수 없습니다.
일부 단계가 지연되면 프로젝트의 나머지 단계 진행에 영향을 미칩니다. 따라서 각 단계 내의 활동을 점검하고 해당 기간 동안 선형적으로 진행되는지 확인하는 것이 중요합니다. 그렇지 않으면 특정 단계가 지연되고, 결과적으로 전체 프로젝트가 지연될 위험이 높아집니다.
애자일 프로젝트에서는 각 스프린트가 끝날 때마다 열리는 데모 세션을 통해 진행 상황을 추적합니다. 실행 가능한 제품은 진행 상황의 주요 척도입니다. 당연히 각 스프린트가 완벽한 콘텐츠로 완료되기를 바랍니다. 다음 스프린트로 이월되는 스토리는 최소화해야 합니다.
궁극적으로 현재 제품 증분을 직접 사용해보고 즉시 팀에 피드백을 제공할 수 있다면 프로젝트의 전반적인 진행 상황을 파악하는 것이 훨씬 쉽습니다.
#4. 팀 협업
이 부분은 엄격하게 분리된 워터폴 활동과 애자일 팀의 모든 이해관계자 간의 지속적인 협업에 관한 것입니다.
워터폴 방식의 프로젝트에서는 일반적으로 프로젝트의 여러 단계에서 다양한 사람이 작업합니다. 어느 정도 중복되는 부분도 있지만, 각 단계는 서로 다른 그룹으로 간주됩니다. 서로 단절된 사일로라고 표현할 수도 있습니다.
애자일 팀의 핵심 가치는 의사소통과 협력입니다. 또한 모든 제품 수명 주기 활동을 실행할 수 있는 다기능 팀이어야 합니다. 팀의 사일로는 존재해서는 안 됩니다. 팀과 외부 이해관계자 간의 끊임없는 커뮤니케이션은 성공적인 애자일 프로젝트의 핵심 요소입니다.
#5. 위험 관리
프로젝트 기간 동안 발생할 수 있는 모든 위험, 문제 또는 장애물을 추적하기 위한 프로세스가 필요합니다.
워터폴 방식의 프로젝트에서는 프로젝트의 현재 단계에 대한 상태 추적으로 변환됩니다. 표준 신호등과 같은 상태 보고는 녹색(모든 것이 정상이고 계획대로 진행됨), 노란색(일부 중요한 문제가 있지만 해결 방법은 알고 있음) 또는 빨간색(프로젝트에 원래 일정이나 예산에 영향을 미칠 수 있는 심각한 문제가 있음을 의미)으로 표시됩니다.
애자일 프로젝트는 접근 방식이 다릅니다. 목표를 향한 진행 상황을 추적하기보다는 다양한 팀과 활동 유형 간의 종속성을 해결하는 데 중점을 둡니다. 목표는 진행 중인 활동으로 인해 어떤 팀도 다른 팀을 기다리지 않도록 하는 것입니다.
물론 위험이 나타날 수 있지만, 해결책은 원래 계획을 유지하면서 위험에 대한 해결책을 찾는 대신, 앞으로 계획을 변경하여 위험을 제거하는 것입니다.
즉, 애자일 프로젝트에서는 예상되는 위험에 직면하지 않도록 계획을 변경하는 데 모든 노력을 기울이며, 이는 위험 관리가 사전에 이루어진다는 것을 의미합니다. 워터폴 프로젝트에서는 원래 계획을 유지하면서 위험에 사후적으로 대응하고 최대한 빨리 해결하려고 노력합니다.
#6. 구현 프레임워크
워터폴 방식 프로젝트의 구현 전략은 애자일 프로젝트보다 간단합니다. 일반적으로 워터폴 방법론은 오랫동안 사용되어 온 기존 방식입니다.
반면, 애자일 프로젝트에는 습관, 사고방식, 작업 방식을 바꾸기 위한 혁신적인 방법이 필요합니다. 이러한 변화는 어렵고 시간이 오래 걸릴 수 있습니다. 기업들은 애자일 프로세스에 적응하도록 사람들을 교육하는 데 상당한 시간과 자원을 투자하고 있습니다.
변화하는 고객 요구에 빠르게 적응할 수 있다는 큰 장점이 있지만, 사람들의 사고방식과 전반적인 작업 환경을 바꾸는 것이 가장 어려운 부분입니다.
대부분의 경우, 이것이 시장에서 경쟁력을 유지하는 유일한 방법이기 때문에, 성공한 기업들은 이러한 노력에 대한 큰 보상을 받고 있습니다.
맺음말
분명히 말하자면, 결과물을 프로덕션 환경에 빠르게 제공해야 할 큰 동기가 없는 매우 보수적인 고객이 아니라면(어떠한 이유에서든) 처음부터 애자일 팀 모델링을 시작하는 것이 가장 좋은 방법입니다. 이는 오늘날의 세계에서 너무나 당연한 일입니다. 기존 온프레미스 시스템 설정의 경우에도 마찬가지입니다. 특히 팀이 처음부터 시작하는 새로운 사람들로 구성된 경우라면 애자일 방법론에 맞춰 프로세스를 전환하는 것이 합리적입니다.
그럼에도 불구하고 여전히 애자일 프로세스나 다른 설정을 따르기를 거부하고 엄격한 단계별 작업 구성을 고수하는 프로젝트를 접하게 됩니다. 그들은 특정 시간과 예산을 기준으로 작업을 계약하는 일반적인 경로를 따릅니다. 그리고 프로젝트가 계획과 비용에서 벗어나지 않고 이러한 설정을 따를 것이라고 기대합니다(그 결과는 일반적으로 좋지 않습니다).
물론 그들은 그러한 결정을 내릴 권리가 있지만, 그러한 결정으로 인해 과거에 머무르게 된다는 것을 의미합니다. 당분간은 효과가 있을 수 있지만, 더 이상 효과가 없을 때까지는 시간문제일 뿐입니다.
다음으로는 애자일 테스트 수명 주기에 대한 자세한 기사를 살펴보시기 바랍니다.