애자일하게 일한다는 것, 그리고 애자일의 덫
애자일의 핵심은 속도가 아닌 학습과 협력이다
프로덕트 개발 방법론으로 '애자일(Agile)'이 업계 표준으로 자리잡으면서 팀에서 스프린트나 스크럼, 칸반, 회고 등 여러 방법론을 적용하며 애자일을 추구하고는 있지만, 막상 우리 팀이 정말 애자일하게 일하고 있는지 생각해보면 다소 확신이 없지는 않으신가요?
프로덕트의 범위는 넓고 기능마다 특성이 다르기 때문에 추상적인 의미의 애자일을 구체적인 업무에 적용했을 때 무엇이 애자일한지 정의하기가 어려울 때가 많습니다. 예를 들어, UI만 변경해 A/B 테스트를 짧게 하면 애자일하고, 완결성 높은 결제 기능을 개발하기 위해 상세 기획 기반으로 1달 동안 작업한다면 워터폴인가요?
번역/편집하여 소개하는 아래의 글은 애자일을 적용하더라도 기획 > 디자인 > 개발의 순차적인 프로세스는 필요하다는 점을 짚어줍니다. 우선 이 글을 읽어보고, '무엇이 애자일인가'에 대해 조금더 다루어보도록 하겠습니다.
The Agile Trap or how to differentiate planning from building — Carlos Yllobre
2020.11.10 / 원문 (링크)
"우리는 더 애자일해질 필요가 있어요."
테크 분야에서 일하고 있다면 무수히 들었을 법한 이야기입니다. 2001년 애자일 선언이 만들어진 이후, 많은 회사들이 애자일 철학을 성공적으로 도입하며 프로덕트 개발 방법에 변화를 시도해왔습니다. 하지만 소프트웨어 개발 외의 여러 다른 비즈니스 영역의 니즈에도 적용할 수 있을만큼 애자일이 가진 방법적 측면에서의 다양성 때문에 여러 문제들이 발생했습니다.
"애자일하지 않고 싶은 사람이 어디있나요?"
애자일의 핵심은 4가지 주요 원칙(프로세스보다는 개인을, 문서보다는 소프트웨어 자체를, 계약보다는 고객과의 협업을, 계획을 따르는 것보다 변화에 대응하는 것을 중시)을 따르며 프로덕트의 작은 개선을 만들어가는 것입니다.
애자일 원칙은 협업을 증진시키는 반복적인 개발 사이클에 효과적으로 적용되었으며, 느리고 고전적인 워터폴 방법론의 대안으로 떠올랐습니다. 그렇다면 무엇이 문제인 걸까요?
"애자일의 덫(The Agile Trap)"
애자일의 덫은 애자일이 단순히 "빠르게 움직이고 부수는 것(move fast and break things)"이라는 생각에서 비롯됩니다. 애자일은 각 개발 사이클마다 요구사항을 충족시키기 위한 다양한 접근방식을 수용할 수 있는 프레임워크인데도 말이죠.
단순히 속도만을 중시하며 다음의 기본적인 원칙을 간과할 때 애자일 덫에 빠질 수 있습니다.
We can’t make progress without a sequence of actions.
일련의 절차 없이는 일을 진전시킬 수 없다.
모든 일은 특정한 단계를 필요로 하며, 순서를 기반으로 결과를 효과적으로 전달할 수 있습니다.
잠깐, 그렇다면 이는 애자일이 아니라 워터폴에 해당되는 것 아니냐구요? 물론 워터폴에서 프로세스를 더 중요시하기는 하지만 그렇다고 애자일에서 일의 절차가 아예 필요없다는 이야기는 아닙니다.
"애자일로 프로덕트 개발할 때도 순서는 필요하다."
애자일하게 진행하더라도 프로덕트를 일단 만들고 테스트하는 것으로 새로운 개발 사이클이 시작되지는 않습니다. 어떤 이터레이션 과정에 있냐에 따라 조금씩 달라질 수는 있지만, 요구사항이 정리되고, 디자인이 진행되고, 다음으로 개발이 시작되는 일련의 단계는 항상 존재합니다.
빠른 테스트만이 애자일이라는 좁은 관점은 워터폴처럼 느껴지는 모든 것에 거부감을 일으킬 수 있습니다. 하지만 문제를 날카롭게 정의하고, 여러 아이디어를 탐색하고, 올바른 해결책을 도출하기 위해서는 명확한 순서를 따라야 합니다.
단순히 빠르게 개발해서 고객에게 전달만 하면 애자일이 되는 것이 아닙니다. 관찰, 리서치, 문서화, 분석을 토대로 철저한 사전 계획이 반드시 필요하며, 올바른 계획 없이는 좋은 프로덕트를 만들 수 없음을 기억해야 합니다.
결국, 애자일과 워터폴의 차이는 단순히 계획이나 절차, 문서나 프로세스가 있고 없음에 좌우되는 것이 아니라는 것을 알 수 있습니다. 개발 속도나 사이클의 길고 짧음도 둘을 날카롭게 구분하지는 못합니다. 그렇다면 대체 무엇이 애자일일까요?
'함께 자라기 - 애자일로 가는 길'의 저자 김창준님은 애자일을 다음과 같이 설명합니다.
애자일은 더 짧은 주기로 더 일찍부터 피드백을 자주 받는 방식을 통해 빠르게 리스크를 줄일 수 있어 불확실성이 높은 현재의 비즈니스 환경에 적합하다. 그 핵심적인 구동원리는 학습과 협력이다. 서로 간의 협력을 통해 새로운 상황에 적응하고 학습해야 불확실성에 잘 대응할 수 있기 때문이다.
핵심은 '피드백'과 이를 통한 학습, 그리고 협력에 있습니다. 기획자가 기획한 내용에 대해 디자이너나 개발자가 아무런 피드백 없이 그대로 작업한다면, 결과물에 고객의 피드백을 지속적으로 반영하지 못한다면 비즈니스, 고객, 협업 방식에 대한 학습이 전혀 이루어지지 못할 것입니다.
애자일 철학을 적용하기 위한 많은 방법론들(스프린트, 스크럼, 칸반, 회고.. )은 모두 학습과 협력을 잘 하기 위해 고안되었습니다. 그러나 애자일 방법론에 정답은 없습니다. 회사마다, 팀마다, 서비스마다, 협업 관계자들의 특성마다 적합한 방법을 찾아야합니다. 그렇기 때문에 우리는 어떤 프로세스나 조직 구성만을 두고 애자일이다, 워터폴이다 쉽사리 결론을 내릴 수 없는 것이지요.
우리 팀이 애자일한지 확인해보고 싶다면 다음의 질문을 해보면 좋겠습니다.
1. 배경이나 목적에 대한 충분한 설명을 기반으로 작업자들과 최선의 솔루션을 함께 찾아가고 있나요?
2. 솔루션이 어떤 가치를 줄지 불명확할 때, MVP 형태로 고객의 피드백을 빠르게 받고 있나요?
3. 일하는 방식에 대해 꾸준히 회고하며 팀에 가장 맞는 방법론을 찾아가고 있나요?
모든 질문에 YES를 자신있게 외칠 수 없다면, 어떤 부분 때문인지 팀원들과 깊게 토론해보기를 추천합니다. 그리고 팀 내에서 어떤 방식으로 애자일을 적용하는 것이 비즈니스 특성상 가장 적합한지, (또는 적용하지 않는 것이 나은지)도 논의해보시기 바랍니다.
애자일 철학을 실제 업무에 어떻게 적용하면 좋을지 조금더 구체적으로 살펴보고 싶다면 다음의 글을 참고해보세요.
구글에서 기획서가 협업에 활용되는 방식 : https://brunch.co.kr/@lulina724/26
애자일 철학을 개발문화에 적용한 버즈빌 사례 : https://brunch.co.kr/@mobiinside/868
프로젝트 진행할 때 활용하는 애자일 방법론 : https://brunch.co.kr/@svillustrated/27
애자일 철학을 적용한 B2B 서비스 개발방식 : https://brunch.co.kr/@jamess/24
