우리는 과연 애자일하게 일하고 있을까?
애자일 방법론이 기업에 잘 적용되지 않는 이유
1990년대를 거치면서 IT 시장은 소수의 전문가들이 주도하던 시대에서 일반 대중이 중심인 시장으로 급격히 변화했다. 기술의 발전 속도는 더 빨라졌고, 사용자 요구 사항도 더욱 다양해지고 복잡해졌으며, 비즈니스 사이클이 빨라졌다. 이러한 변화에 발맞추기 위해, IT 업계는 더 빠르고 유연한 소프트웨어 개발 방식을 필요로 하게 되었고, 그 결과로 2000년대 초 등장한 것이 바로 애자일(Agile) 방법론이다.
애자일 소프트웨어 개발 선언문애자일 방법론
Agile vs Waterfall (출처 : blog.ganttpro.com)애자일은 짧은 개발 주기를 통해 빠르게 피드백을 받고, 이를 바탕으로 프로젝트를 유연하게 조정할 수 있는 점에서 큰 장점을 지녔다. 고객의 요구사항과 취향이 자주 변하는 환경에서도 빠르게 대응할 수 있다는 점에서, 애자일은 많은 기업들 사이에서 유행처럼 번지며 인기를 얻게 되었고, 널리 채택되었다.
애자일은 애초 소프트웨어 개발 방법론이었으나, 이제 기획자와 디자이너는 물론 다른 업권에도 요구되는 방법론이 되었다.
린스타트업(Lean Startup)
Lean UX Cycle (출처 : www.plainconcepts.com)비슷한 개념으로 린스타트업(Lean Startup)이라는 개념도 있는데, Think(아이디어, 생각, 학습) -> Make(프로토타입, 제품 제작) -> Check(측정, 검증, 개선) 을 반복하며, 빠른 사이클로 시행착오를 줄이고 불필요한 자원 낭비를 최소화하는 프로세스를 기본으로 한다.
MVP(Minimum Viable Product)
MVP의 개념 (출처 : blog.crisp.se)여기서 등장하는 추가 개념이 바로 MVP(Minimum Viable Product)인데, 최소 존속 제품, 바로 최소 요건을 갖춘 제품을 출시하여 사용자 반응을 테스트하고, 피드백을 반영하면서 점점 완성도를 높여가는 것이다.
이 모든 방법론과 개념의 핵심은 가설을 검증하고, 피드백을 빠르게 반영함에 있다.
애자일(Agile) vs 폭포수(waterfall)
애자일의 반대되는 개념은 전통적인 방식, 바로 폭포수(waterfall) 방식인데, 폭포수 방식은 프로젝트가 일방향으로 오픈까지 진행되는 프로세스이고, 애자일 방식은 끊임없는 검토와 수정을 거쳐 오픈 전까지 개선 작업을 수행하는 방법이라는 것이 차이점이다.
Agile vs Waterfall애자일(Agile) 방식은 작업을 기능별, 페이지별 등으로 세분화하여 작은 단위로 나누어 진행하는 것이 특징이다. 이 방식은 유연한 조직 구조를 지향하며, 하나의 서비스(프로덕트)를 중심으로 팀이 구성된다. 애자일의 큰 장점 중 하나는 일정이 유연하다는 점이다. 프로젝트 중간에도 새로운 요구사항이나 변경 사항에 쉽게 대응할 수 있으며, 빠르게 가설을 검증하고 이를 바탕으로 프로덕트를 빠르게 출시할 수 있다. 최소 요건만 충족한 상태에서도 프로덕트를 출시할 수 있어, 시장의 반응을 빠르게 확인하고 개선해 나갈 수 있다. 이러한 유연성 덕분에, 애자일은 변화가 잦고 불확실성이 높은 환경에서 특히 유용하다.
폭포수(Waterfall) 방식은 애자일과 달리 각 단계를 순차적으로 진행하는 방식이다. 한 단계가 완전히 마무리된 후에야 다음 단계로 넘어갈 수 있다. 이 방법은 엄격한 조직 구조에서 자주 사용되며, 각 팀은 특정 기능을 담당하는 명확한 역할을 가진다. 폭포수 방식의 특징은 일정이 명확하게 정의된다는 점이다. 프로젝트 시작 시, 전체 계획이 수립되며, 각 단계마다 명확한 목표와 기한이 설정된다. 가설 검증이 어려운 상황이라 사전 리서치와 전략 수립이 중요해지며, 이를 통해 완성된 프로덕트는 프로젝트 완료 후, 한 번에 출시하는 것을 목표로 한다. 이 방식은 프로덕트 출시 후 변화가 적을 것으로 예상되고, 요구사항이 명확하게 정의된 프로젝트에 적합하다.
애자일 방법론이 효과적이라는 것에는 20년이 흐른 지금에도 이견이 없다. 많은 통계자료들이 이를 뒷받침하고 있고, 성공적인 스타트업의 사례에서 이를 잘 적용한 사례를 볼 수 있으니 말이다.
애자일 방법론의 프로젝트 성공률 (출처 : Standish Group 2020 Chaos Report)애자일 방법론이 모든 상황에서 효과적인 것은 아니다.
애자일 방식이 유행처럼 번져, 만능인 것처럼 여겨지기도 하지만 애자일 방식이 모든 상황에서 효과적인 것은 아니다.
애자일 방법론의 효과적으로 작동하려면 명확한 조직 체계와 성숙한 조직 문화가 전제되어야 한다. 하지만 조직 체계가 제대로 갖추어지지 않은 상태에서는 역할 분담이나 의사소통이 원활하지 않아 혼란을 초래할 수 있다. 명확한 책임 소재가 불분명하고, 권한과 역할이 제대로 정의되지 않은 상태에서는 애자일 방법론의 장점을 살리기 어렵다. 이러한 상황에서 애자일 방법론을 무리하게 적용하면, 오히려 조직의 비효율성을 심화시킬 수 있다.
대규모 조직에서 상급자의 결정이 사실상의 의사결정으로 굳어지는 문화가 고착화되어 있으며, 이러한 조직에서는 애자일의 유연한 접근 방식이 어렵다. 각 부서 간의 협업과 조정이 복잡해지며, 전체 프로젝트가 애자일 방식으로 운영되기에는 조직의 규모와 복잡성 때문에 어려움이 따른다. 결국, 애자일의 적용이 오히려 더 많은 조정과 관리를 요구하게 되어, 예상보다 큰 혼란을 야기할 수 있다.
애자일 방법론이 가지는 가장 큰 문제점 중 하나는 과도한 유연성에서 비롯된다. 프로젝트의 방향이 자주 바뀌고, 끊임없이 요구사항이 변경되면서 개발팀은 일관된 목표를 유지하기 어려워지고, 이로 인해 프로젝트의 개념이 흔들리고, 장기적인 계획 수립이 어려워질 수 있습니다. 또한, 지속적인 피드백과 조정 과정에서 불필요한 회의 시간이 증가하며, 팀의 피로감을 초래할 수도 있다.
애자일 방법론이 유행처럼 퍼지면서, 많은 조직이 애자일 방범론을 표면적으로만 채택하는 경우가 많다. 핵심 원칙이나 철학을 이해하지 않고 단순히 프로세스만 모방하는 경우, 구성원들의 피로감만 증가시키고, 프로젝트의 성과를 높이지 못할 뿐만 아니라, 이러한 방법론은 결국 도전에 직면하게 된다.
실제로, 내가 경험했던 모 조직에서는 애자일 방법론을 도입한 뒤 여러 문제가 발생했다. 잦은 회의로 팀원들이 지쳐갔고, 상급자의 결정에 반하는 의견을 내는 경우는 거의 없었다. 기획자, 디자이너, 개발자는 서로 엇박자를 내고 있었으며, 심지어 개발자는 일에 치여 여러 일을 동시에 맡아 처리하고 있었다.
추가 개발을 요청 했더니, 개발자는 이미 다른 일을 하고 있더라
애자일 방법론은 강력한 도구임에 틀림없지만, 조직에 맞는 방법론을 택하는 것이 더욱 중요하다. 애자일 방법론을 채택할 때는 조직의 규모, 프로젝트의 복잡성, 팀의 성숙도 등을 고려하여 신중하게 접근할 필요가 있습니다. 때로는 전통적인 폭포수 방식이나 이를 적절히 섞은 하이브리드 방법론이 더 나은 선택이 될 수도 있다. 결국 중요한 것은, 상황에 맞는 올바른 방법론을 사용하는 것이다.
세 줄 정리
애자일 방법론은 강력한 도구이다.
하지만, 애자일 방법론도 많은 문제를 가지고 있다.
방법론에 얽매이지 말고, 조직에 적합한 방법론을 택하자.
