애자일은 옳고 워터폴은 틀렸다?
"우리는 애자일 방식으로 일해요."
"애자일 방식으로 일해 보신 경험이 있나요?"
IT 업계에서 일을 해본 사람이라면 한 번쯤 들어봤을 법한 말이다. 애자일, 그 애자일이 대체 뭐길래 신봉파/비 신봉파가 나뉘고 심지어는 '조선식 애자일', 'K-애자일'이라는 말까지 등장한 걸까(..) 애자일과 워터폴은 현업에서 어떻게 적용되고 있을까? 우선, 두 방법론의 접근 방식을 간단히 비교하여 정리해 보았다. 비교에 앞서 워터폴과 애자일의 정의부터 가볍게 알아보자.
워터폴(Waterfall)
이러한 방법론들은 소프트웨어에 한정된 것이라 생각하기 쉽지만 이미 다른 업계에서도 사용되고 있는 방식이며, 기원을 거슬러 올라가 보면 제조/건설 산업 현장에서부터 비롯된 프레임워크라는 점을 알 수 있다. 애자일이 등장하기 전까지 워터폴 방식은 거의 모든 분야의 산업에서 보편적으로 활용되고 있었다. 워터폴은 계단식의 단계별 접근 방식으로도 잘 알려져 있는데, 프로세스를 짧게 요약해 보면 아래와 같다.
1. 먼저 고객들의 문제를 정의하고 요구사항을 문서화하여 우선순위를 충분하게 정리한다.
2. 다음 디자인 단계에서는 앞서 정의된 모든 요구 사항을 충족시킬 수 있는 알맞은 형태를 찾는다.
3. 앞 단계에서 설계된 부분을 실질적으로 구현하는 작업을 수행한다.
4. 구현된 제품의 기능이 제대로 동작하는지, 기획 단계의 목적에 부합하는 제품인지 품질 검수를 최종적으로 진행한다.
5. 제품의 지속적인 유지보수를 위한 체계를 완성한다.
워터폴은 요구사항 분석 → 디자인 → 개발 → 검수→ 배포의 과정을 거치게 되는데 해당 방식이 가진 장단점으로는 무엇이 있을까?
워터폴 방식이 가진 장점과 한계, 애자일의 등장
이러한 워터폴 방식은 관리가 용이하다는 장점이 있다. (다소 부족한 비유이기는 하지만) 자동차 공장의 컨베이어 벨트를 머릿속에 연상해보자. 각 단계 별로 만족시켜야 할 최소 요구 사항이 있고, 그러한 요구사항에 관한 문서화가 잘 되어 있기 때문에 전반적으로 프로젝트의 관리가 수월해진다는 장점이 있다. 뿐만 아니라, 요구 조건이 명확하기에 손에 익은 작업일수록 생산(개발) 속도도 빨라진다는 장점이 있다. 각 단계별 업무 분담의 효율성을 최대한으로 끌어올려 기설정한 요구 조건을 만족시키는 것에 집중한다는 느낌이 강하다.
이러한 워터폴 방식이 문제없이, 모든 분야에서 제대로 작동해 주었다면 애자일 방식은 빛을 보기 어려웠을 것이다. 워터폴 방식은 한계점 역시 지니고 있다. 초기 요구사항이 명확하기 때문에, 프로젝트가 끝나고 제품이 완성되었을 때 결과물이 고객의 기대에 미치지 못할 수도 있다. 즉흥적인 대응이 어렵기 때문에 하루가 멀다 하고 고객의 요구사항이 변하는 요즘 같은 시대에는 큰 맹점이 될 수도 있다. 폭포수 방식을 머릿속에 그려보면, 고객이 참여할 수 있는 단계는 시작 단계와 마지막 단계(최종 제품을 받아보는 시점) 뿐이다. 이 경우, 뒤늦게 제품을 다시 수정하고 시험하려면 많은 비용이 들어간다는 단점이 있다. 게다가 이러한 사태를 미연에 방지할 만한 안전장치도 없다. 동시에 선행 단계의 기획이 몹시 중요해지는 이유인데, 기획단에서 제품의 제약사항과 같이 사전에 점검해야 할 부분을 놓치고 미리 정의되어야 할 문제를 흘려보낸다면 이후에 예기치 못한 큰 문제로 돌아올 수도 있다. (간간이 뒤늦게 문제가 발생해 제품의 출시가 미뤄지기도 한다.)
애자일(Agile)이 답인가요?
그렇다면 애자일은 워터폴이 가진 한계를 극복할 수 있을까? 애자일은 어떻게 탄생하게 되었을까. 2001년, 애자일 선언문 발표 후 현업에 적용된 시점을 고려해 보면 이미 애자일은 충분히 자리를 잡았어야 한다. 우선 애자일의 정의부터 살펴보자. Agile은 기민한, 민첩한이라는 뜻을 가진 단어로 이름에서부터 알 수 있듯 '스프린트'라 불리는 짧은 주기의 개발 사이클을 반복해 시장의 변화에 유연하게 대처하는 프레임워크다.
대략 2~4주간의 짧은 사이클로 고객의 요구사항을 최대한 반영한 MVP를 만들기 때문에 워터폴 방식보다는 고객의 참여 범위가 비교적 넓은 편에 속하며 고객 가치를 효과적으로 전달할 수 있다는 큰 장점이 있다. 시장의 변화에 대응하기도 쉽다는 점뿐만 아니라 팀워크 면에서도 제품 개발 과정 속 각기 다른 직무를 수행하는 팀원들의 협력으로 예상치 못했던 시너지 효과가 발생할 수 있다. 이러한 능동성, 유연성 차이로 인해 워터폴이 엄격하고 규칙적인 이미지의 고리타분한 방법론으로 통하는 것인지도 모른다.
우리는 애자일 방식으로 일하고 있을까?
요즘은 산업, 조직을 불문하고 다양한 회사들이 애자일 방식으로 일을 하고 있고(또는 그렇다고 주장하고) 애자일 방식으로 일할 것을 지향한다. 과연 이러한 인식이 당연시되어도 되는 걸까? 앞서 말했듯 애자일은 유연하게 변화를 수용하며 점진적인 발전을 추구한다는 데에 이점이 있다. 하루가 다르게 가치가 변화하는 불확실성이 높은 시장에서는 적합하겠지만 유동성이 낮은 시장에서는 오히려 효율성이 떨어질 수도 있다는 뜻이다.
한 마디로, 고객이 가진 문제와 해결책을 분명하게 이해하고 있고 결과에 대한 확신까지 가지고 있다면 워터폴이 더 적합할 수도 있다는 것. 아래에 요즘 시국에 맞춘 비유를 들어보았다. (부적절한 예시일 수 있으니 흐린 눈으로 봐주세요.) 국가의 공공 정책은 요구사항과 예산이 다소 엄격하며 고정된 경우가 많다. 우선, 4인 가구 가정에 마스크를 상반기/하반기에 나누어 약 100개씩 제공한다는 내용의 지원 정책이 있다고 가정해보자. 코로나가 장기화된 시점에서 마스크는 이미 고객이 필요로 하는 제품이며 별도의 대체제가 없고 무엇보다 추가적인 요구사항이 없을 확률이 높다. 이 경우, 약속된 수량만큼의 마스크를 각 가정마다 최대한 빠르게 공급하는 것이 프로젝트의 핵심이다. 이와 같은 경우엔 오히려 워터폴 방식으로 접근하는 것이 효과적일 수도 있다.
제품 출시라는 전체적인 그림으로 봤을 때, 기획부터 출시까지 각 단계의 예산과 납기가 명확하게 구분된 워터폴에 비해(물론 사고가 터지면 딜레이 되는 경우도 있다.) 애자일은 점진적으로 제품을 개발해 나가는 방식이기에 최종적인 형태의 제품 전달은 오히려 늦어질 수 있다. 또한 짧은 제품 개발 주기에서 항시 좋은 품질과 팀워크를 유지하기가 어렵다는 점도 애자일이 당면한, 해결해야 할 과제로 보인다. 현업에서 애자일을 경험하고 있는 지인들에게 물어보면 가장 먼저 돌아오는 답변이 '방법론 위에 사람 있다'였다. 제 아무리 실용적인 방식이라 해도 같이 일하는 팀원들이 애자일 철학의 이점을 이해하지 못하고 rank-driven 방식으로 일하려 한다면 오히려 역효과가 날 수도 있다. 유연함과 신속성이 단락을 좌우하는 상황에서 팀원들에게 그에 맞는 권한과 책임이 부여되지 않는다면 시너지 효과를 기대하기는 다소 어렵지 않을까.
Agile로 잘 일하고 있다는 것은? 애자일 프레임워크를 채택한 회사들
현재는 국내의 많은 기업들이 애자일 조직 체계를 갖추고 있다. 요즘에는 애자일을 채택하고 있지 않은 회사를 찾기가 더 어려울 정도다. 애자일 체계 하면 쿠팡, 토스, 배달의 민족이 대표적인 사례로 잘 알려져 있는데 이 글에서는 토스의 일하는 방식을 예시로 다루었다. 애자일을 잘한다는 것은 뭘까? 그게 뭔지는 모르겠지만 애자일을 실행함에 있어서 방해 요인이 되는 것이 무엇인지 알고, 팀원들이 그에 맞는 마인드셋을 갖춘다면 이는 애자일 방식으로 잘 일하고 있다는 반증으로 보아도 큰 무리가 없겠다는 생각이 들었다. (앞서 살펴보았듯이, 어떤 방법론이든 그 차이는 결국 일하는 방식에 달려있다고 생각된다.)
토스는 탑다운이 없고 실무자에게 높은 자율성을 부여하는 기업 문화로 이미 업계에서도 잘 알려져 있다. 토스의 기업 문화는 공식 기술 블로그, 토스 피드를 참고했다. 토스는 기본적으로 '사일로'라는 팀을 애자일 방식으로 운영되고 있다. 이 사일로는 Product Owner, Developer, Designer 등 8~9명의 팀원으로 구성되어 있고 각기 다른 팀원들을 '메이커'라는 말로 부르고 있었다. 사일로는 10명 이상을 넘지 않기 때문에 합의점을 비교적 빠르게 도출할 수 있어 신속한 의사결정이 가능하다. 뿐만 아니라, 토스라는 상위 제품을 전체적인 관점에서 관리하고 일관성을 유지하기 위해 직군 별로 '챕터'라는 조직을 두었다.
Q. 기민성을 발휘한 사례가 있나요.
“예를 들어 인슈어런스(보험) 사일로에서 ‘보험금 간편 청구’란 서비스를 출시하는 데 2주밖에 걸리지 않았습니다. 이 정도의 기민성이 있으면 굉장히 많은 것들이 가능해집니다. 작년에만 40여 개의 서비스를 새롭게 론칭했고 그중 절반은 망했습니다. 나머지 절반은 계속 운영되고 있고요. 어떤 서비스들은 일반 대중에게 배포되기도 전에 사라지기도 합니다. 2만~3만 명에게만 배포됐다가 반응이 좋지 않아 팀에서 스스로 서비스를 중단하기도 하고 반대로 반응이 좋으면 빠르게 모든 이용자들에게 배포하기도 합니다.”
토스는 변화가 빠른 핀테크 시장에서 살아남기 위한 전략으로 작은 조직과 빠른 실험 방식을 지향하고 있다. 핀테크 사업은 전통적인 금융사업과 비교해 편리한 사용성을 기반 삼아 폭발적으로 성장해왔다. 뿐만 아니라, 일부 기능에 국한되었던 예전과 달리 은행과 협력하여 경계 없는 다양한 금융 상품을 개발하여 스마트폰 하나로 해결 가능한 세상으로 금융 산업의 판도를 계속해서 바꿔나가고 있다. 시장에서 어떤 상품이 고객의 마음에 후킹될 수 있을지 명확히 알 수 없기에 토스는 최대한 빠른 실험과 실패를 반복하는 방식으로 비용을 최소화했다.
개인적으로 가장 기억에 남았던 부분은 토스가 사일로라는 애자일 팀만 두고 있는 것이 아니라 '챕터'라는 별도의 조직을 두고 있다는 점이었다. 애자일 방식으로 프로젝트를 진행하되 직군 별로 협업할 수 있는 구조를 마련해 두어 전체적인 목표를 잃지 않게 했다는 점이 인상적이었다. 회사 내 애자일 팀이 수십이라면, 서로 피드백을 얻고 '토스'라는 제품의 공동 목표를 달성하는 데 현실적으로 어려움이 있을 수 있다. 내가 팀의 디자이너라면 어떨까? 사일로 팀 내에서 주어진 스프린트 내에 결제 페이지를 디자인해야 하는데 혼자서는 해결하기 어려운 문제에 부딪힌다면? 같은 직무를 수행하는 사람들에게서 조언을 구할 수 있는 환경이 조성되어 있다면 아마 일의 방향성을 세우는 데도 큰 도움이 되지 않을까?
"정보를 공개하지 않고 서로 비협조적이 되거나 불필요한 내부 경쟁이 일어나는 이유는 동일한 핵심성과지표(KPI)를 놓고 사내에서 경쟁시키기 때문입니다. 하나의 지표에 대해 두 개 이상의 팀이 싸우게 만드는 거죠. 더 잘한 팀에 상을 주고 더 못한 팀에 벌을 주기 때문에 회사 안에서 팀끼리 불필요한 경쟁이 일어나고 팀장끼리 알력이 생기게 되는 것입니다. 그래서 비바리퍼블리카는 개인의 성과를 평가하지 않습니다. 개별 팀의 성과도 평가하지 않습니다. 오직 회사 전체의 목표만 있고 그걸 잘했느냐 못했느냐에 따라 모든 구성원의 인센티브와 인사고과가 결정되기 때문에 개인이나 팀끼리 굳이 싸울 이유가 없습니다. 개별 팀은 오히려 협조해 ‘어떻게 하면 저 팀을 더 잘하게 하고 나도 잘해서 회사 전체의 목표를 달성하고 인센티브를 키울 수 있을지’를 고민합니다."
외부자의 시선으로 보았을 때, 토스는 작은 조직으로 빠른 시행착오 과정을 거치면서도 전체적인 목표를 잃지 않게끔 장려하는 회사인 듯 보였다. (그에 대한 책임도 분명히 따르겠지만..) 아래는 토스 피드에서 가져온 프론트엔드 개발자 인터뷰의 원문이다.
Q. 지금까지 진행했던 프로젝트 중 가장 기억에 남는 것을 소개해주세요.
A. 합류한 지 얼마 안 됐을 때 만들었던 ‘내 부동산 시세 조회’ 서비스가 기억에 남는데요. 기획이 끝나자마자 디자인이 이틀 만에 나오고, 개발은 2~3일 만에 끝나서 일주일 만에 실제로 작동하는 MVP(Minimum Viable Product: 사업 가설을 테스트해보기 위해 최소한의 노력과 개발 기간으로 만드는 제품 버전)가 출시됐어요.
토스팀의 애자일 문화 때문이기도 하고 잘하시는 분들도 워낙 많아서 그런 것 같아요. 빠른 개발 속도가 힘들 때도 있지만, 그라파나(토스의 모든 데이터를 볼 수 있는 데이터 플랫폼)에 제가 만든 서비스 지표가 바로 보일 때면 보람이 더 커요. → 토스는 대시 보드를 통해 주요 지표를 구성원들에게 실시간 관리, 공유하고 있다.
또 하나는 1년 동안 눈부시게 발전한 인프라 환경인데요. 예전에는 앱 배포하는 과정이 힘들거나 오래 걸리는 등의 이슈가 있었거든요. 이런 이슈 해결을 위해 저희 플랫폼 팀에서 먼저 제안을 드렸어요. “현재 생산성이 낮은 문제점을 해결해보겠다”고요. 다양한 개발자 분들과 논의를 거치며 설득했더니, 모두 동의해주셨어요. 인프라 환경 개선을 위해 몰입해서 일했고, 지금은 효율적인 구조로 바뀌었습니다.
개발 직군이 단지 주어진 개발 업무만 수동적으로 진행하는 것이 아니라, 팀에 필요한 일이라 생각할 때엔 합리적 근거와 함께 개선 방향을 제시해서 실현시키는 것이 토스팀에선 가능하다는 것을 실감한 프로젝트였어요.
물론 위와 같은 자료만으로 '이 회사가 애자일을 정말 잘하고 있다'라고 판단하는 것은 어불성설인 듯한 느낌이 들어 머쓱하지만, 적어도 위와 같은 인터뷰를 통해서 내부의 구성원들이 어떤 마인드셋을 가지고 있는지는 참고 지표로 활용할 수 있을 것 같아 가져왔다. 직무 커뮤니티를 리서치를 하면서 실제로 애자일을 무기로 쓰는 리더들이 제법 많다는 사실을 알게 됐다. '남들이 다하니까 우리도 해야 해' 같은 마인드로 애자일 철학을 잘못 이해하고 입맛대로 해석하는 리더와 함께 일하는 팀원들의 심정은 어떨까. 애자일을 빠른 완제품 개발로 이해하거나 무한수정으로 받아들이면 당연히 케자일의 굴레에 빠질 수밖에 없다. 애자일을 하라고 지시만 하면서 필요한 총알(자원)은 지원해주지 않는다면 그건 제대로 애자일을 하고 있다고 보기 어렵다.
애자일을 잘하고 있다는 것은 회사의 제품과 시장이 가진 특성이 부합하고, 애자일 방법론을 적용했을 때 그 이점을 거둘 수 있는지에 달려있다. 하지만, 그것 못지 않게 애자일을 실행하는 팀원들의 자세와 역할 역시 중요하다는 것을 항상 염두에 두어야 한다.
Summary
이미 많은 사람들이 알고 있듯, 애자일은 애자일 매니페스토 소프트웨어 개발 선언에서부터 시작된 개념이다.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다.
이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
물론 이러한 인간 중심의 가치들을 현업에 쉽게 적용하기란 쉽지 않다는 점을 알고는 있다. 요즘에는 여러 방법론을 조합해 하이브리드라는 말로 대체해서 사용하기도 하고, 누군가는 "대형 프로젝트에는 애자일을 적용할 수 없다. 그건 애자일이 아니다."라고 못을 박기도 한다. 하지만 시간이 지남에 따라 시장과 회사 내부의 상황, 업계의 트렌드는 계속해서 변하고 있으며, 일부의 조직에서는 애자일의 정신을 잃지 않으면서도 현실에 대입할 수 있는 방법을 찾아가고 있다. 가장 중요한 것은 우리 제품에는 어떤 방법론이 가장 적합한지, 우리의 팀은 어떤 방법론을 채택했을 때 최고의 효과를 낼 수 있는지 충분히 고민해 보는 것이다. '왜 해야 하는지?'라는 질문에 대한 조직 구성원들의 인식을 일치시키고 함께 피드백을 주고받을 수 있을 때 조직은 목표를 효과적으로 달성할 수 있을 것이다.
[참고한 글]
https://subokim.wordpress.com/2016/09/13/what-is-agile-for/
https://hygger.io/blog/the-difference-between-agile-and-waterfall/
https://brunch.co.kr/@svillustrated/24
https://news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=101&oid=050&aid=0000052089
