애자일 방법론 제대로 생각해보기

   최근 회사에서 일하는 방식에 대한 회의감이 부쩍 늘어났다. 내가 의미있게 시간을 보내고 있는건가? 내가 성장하고 있는건가? 라는 의문이 계속 들었다. 그리고 의문의 원인을 찾아나섰다. 우선은 너무나 긴 제품 출시 주기이다. 우리 회사는 전통적인 워터폴 방식을 쓰고 있는데 하나의 프로젝트가 고객에게 출시되기까지 최소 6개월이 걸린다. 평균은 1년 이상인 듯하고 오래 걸리는 프로젝트들은 2년 이상씩도 걸린다. 기획서를 써도 반영이 되지 않으니 내가 잘하고 있는 건지 알기가 어렵다. 두번째는 고객 피드백을 거의 받지 못한다는 점이다. 간혹 출시가 되더라도 고객 데이터 측정이 잘 되지 않는다. 현재 출시되어 있는 제품들을 얼마나 많은 고객들이 쓰고 있는지 알지 못한다. 나의 담당 서비스뿐만 아니라 옆 사람의 서비스의 현황도 마찬가지로 모른다. 어딘가에 일부 데이터가 축적되고는 있으나, 오픈되어 있지는 않다. 심지어, 매출이나 고객 수 같은 데이터는 임원진들에게만 공개된다. 마지막은 우선 순위와 관련된 문제이다. 우선 순위 변경이야 어느 회사에나 있는 문제긴 하지만 업무 사기를 꺾는 큰 요인중 하나인 것은 분명하다. A프로젝트 기획을 하다보면, B 프로젝트의 우선 순위가 높아져서 당장 기획을 해야한다는 지시가 내려온다. 그렇게 B로 작업을 전환해서 부랴부랴 기획서를 쓰고 나면, 정작 B 프로젝트는 개발 리소스가 없다는 이유로 진행되지 않는다. 그리고 개발팀에서는 C프로젝트에 먼저 착수할 예정이니 C 기획서를 재빨리 작성해달라는 요청이 들어온다. 그러면 C 기획서를 급하게 작성해서 넘긴다. A, B에 불필요하게 시간을 낭비하고 나니 정작 C에는 시간을 충분히 들이지 못한다.

   이런 일들을 겪고 나니, 새로운 업무 방식이 필요하다는 생각이 강해졌다. 그래서 애자일 프로세스에 대해 공부하기 시작했다. 애자일 방법론과 쿠팡, 배민, 토스 이야기를 접하며 내 스스로 애자일에 대해서 정의를 해보고 싶어졌다. 참고한 책은 '함께 일하기' (김창준 지음), '프로덕트 오너' (김성한 지음), '배민 기획자의 일' (엄유진 외 7명 지음), '유난한 도전' (정경화 지음) 등이다. 이 외에도 기억은 흐릿해졌지만 과거에 읽었던 책들의 내용도 참고했다. '인스파이어드', '스프린트', '그로스 해킹' 등이다.

 

 

애자일 방법론은 무엇인가?

 

   '조직에 주어진 문제를 빠르게 해결하기 위해 만들어진 조직' 이것이 내가 내린 정의이다. 외부와 내부의 상황이 빠르게 변화하는 상황에서는 일이 계획대로 흘러가지 않는다. 과거에는 A라는 프로그램을 만들자라고 계획을 세우고 몇 년간의 공을 들여 개발을 해서 출시를 하는 것이 보통이었다. 그러나 위 방식은 통하지 않는 경우가 많다. 기술 혁신으로 시장은 급변하고 있다. 계획할 당시만 해도 최신 트랜드였던 프로젝트가 출시할 시점이 되면 낡은 기술에 지나지 않게 될 확률이 급증한 것이다. 이제는 계획부터 출시까지의 기간을 단축시켜서 변화하는 상황에 빠르게 대처해야 한다.

   테크업계에서 주로 사용하는 방법론이니 이를 기준으로 설명하면 구체적인 모습은 이렇다. 6~12명 정도의 인원이 한 팀을 이룬다. Product Owner 1명, 제품 디자이너 1명, 개발자 여러 명으로 한 팀이 구성된다. PO는 팀이 해야할 과제를 정리하고 우선순위를 부여한다. 팀은 1주 혹은 2주를 주기로 스프린트(sprint)를 수행한다. 스프린트 동안 팀은 문제 해결을 위한 가설을 세우고 제품 출시와 테스트를 통해 해당 가설을 실제로 검증한다. 그리고 이런 스프린트를 끊임없이 반복한다. 이것이 애자일 팀의 모습이다. 회사 전체로 시야를 넓혀보면 이런 애자일 팀이 제품 크기에 따라 작게는 1개에서 많게는 수십개 혹은 수백개 존재할 수 있다. 유사한 기능을 가진 애자일 팀(혹은 제품 팀)을 묶고 이를 PM(Product Manager) 혹은 GPM(Group Product Manager)이라는 직책이 관리하기도 한다.

 

 

애자일은 정말로 도움이 될까?

 

   '빠른 시도, 빠른 실패, 빠른 학습'은 애자일의 본질이다. 전통적인 워터폴 개발방법론과 비교했을 때와의 차이점을 기준으로 생각해보자. 10개의 제품 A조직과 B조직이 각각 만든다고 가정해보자. 각 제품을 온전한 형태로 만드는데는 1년이 걸린다. A는 애자일 방법론을 쓰고 B는 워터폴 방법론을 쓴다. A는 우선 각 제품마다 3개월 만의 시간을 쏟아서 출시한다. 1개월 간 고객 지표를 검토한 뒤, 효과가 없는 서비스는 종료하고 효과가 있는 서비스는 고도화한다. 반면, B조직은 모든 제품을 완성된 형태로 만들어 런칭한다. 10개의 제품 중 3개가 성공한다고 가정했을 때, 각 조직이 소모하는 리소스는 아래와 같다.

1. A조직 - 10개 중 3개 성공 시
소모한 리소스 = (실패한 제품 7개 x 3개월) + (성공한 제품 3개 x 12개월) + (제품 10개 x 고객 데이터 검증 1개월)
                        = 67개월
성공 제품 1개당 소모 리소스 = 67개월/3개 = 22.3개월/성공 제품 1개


2. B조직 - 10개 중 3개 성공 시
소모한 리소스 = 실패한 제품 7개 x 12개월 + 성공한 제품 3개 x 12개월
                        = 120개월
성공 제품 1개당 소모 리소스 = 120개월/3개 = 40개월/성공 제품 1개


3. B조직 - 10개 중 5개 성공 시
소모한 리소스 = 실패한 제품 5개 x 12개월 + 성공한 제품 5개 x 12개월
                        = 120개월
성공 제품 1개당 소모 리소스 = 120개월/5개 = 24개월/성공 제품 1개

 

빠른 시도가 가져오는 차이는 이렇게 크다. MVP를 시장에 내놓고 고객 반응이 없다면 빠르게 다른 MVP를 시도하는 것이 애자일이다. 이 때문에 아무도 쓰지 않을 제품에 리소스를 버리는 일을 최소화할 수 있다. 이는 워터폴 방법론에서는 불가능한 일이다. 워터폴에서는 대개 완벽한 제품을 만들려고 하며, 출시 전까지는 고객 반응을 제대로 살피지 못한다.

   이는 리소스 측면에서의 장점이다. 조직의 학습이라는 측면도 애자알이 가지는 커다란 힘이다. 어떤 실험이 성공하고 어떤 실험이 실패하는지에 대한 지식이 조직 내에 축적된다. 이는 어떤 인풋이 더 좋은 아웃풋을 만드는지를 성공적으로 예측할 확률을 높여준다는 뜻이다. 실패가 거듭될 수록 성공 확률이 높아지는 것이다. 막연한 직관, 상상, 추론이 의사결정으로 의사결정을 하는 비중이 줄어든다. 명확한 근거없이 판단을 하게 되면 대개는 직위가 높은 사람의 의견을 따르게 되지만, 근거가 있다면 실무진의 판단이 반영될 여지도 커진다. 데이터 중심 그리고 성과 중심의 조직 문화도 자연스레 자리잡게 되는 것이다.

   물론, 좋은 점만 있는 것은 아니다. 빠른 시도를 위해서는 무언가를 포기해야 한다. 완전한 퀄리티를 포기해야 하며 코드의 확장성과 안정성도 포기해야 한다. 때로는 MVP의 퀄리티가 낮아서 제품의 가치를 고객에게 제대로 전달하지 못할 수도 있다. 조금만 더 가치를 높였다면 성공할 수도 있었던 제품인데 고객에게 반응이 없다고해서 폐기하는 경우도 생길 수 있는 것이다. 애자일 팀 간의 얼라인이 맞지 않는 문제도 생길 수 있다. 디자이너, 개발자가 각기 다른 제품 팀에서 일을 하다보면 디자인이나 코드의 통일성이 떨어질 수 있다. 동일한 직군끼리의 연결망이 있지 않다면 업무의 통일성이나 효율성을 충분히 누리지 못하게 된다.

 

 

애자일을 제대로 하려면 무엇이 필요한가?

 

   애자일 문화는 조직에 쉽게 이식되지 않는다. 겉모습만 흉내낼 경우에는 특히 그렇다. 지라를 쓴다고 해서 스프린트를 한다고 해서 기획자, 개발자, 디자이너가 한 팀이라고 해서 애자일 조직이 되지는 않는다. 애자일의 핵심은 실험을 통해 학습을 하는 것이다. 그러니 가장 먼저 필요한 것은 실험이라는 것을 이해하는 것이다. 실험에 대한 개념을 구성원 모두가 이해해야 하고 이것이 애자일의 목적이라는 것을 알아야 한다.

   실험은 가설을 검증하기 위해서 하는 활동이다. 'A라는 원인때문에 B라는 결과가 나올 것이다.'라는 명제를 검증하는 것이 실험의 목적이다. 이를 위해서는 A라는 요소 외에 모든 변수를 차단해야 한다. 그리고 B라는 결과가 정말로 도출되는지 측정할 수 있는 방법도 갖추어야 한다. 예를 들어, '버튼 색깔을 검정색에서 파란색으로 바꾸면 클릭율이 더 높아질 것이다.'라는 명제를 실험한다고 해보자. 그러면 일단, 버튼 색깔 외에 나머지 요소는 바꾸지 않은 채로 고객에게 제품을 보여주어야 한다. 그리고 나서 클릭율이 높아지는지 살펴야 한다. 우선, 클릭율이라는 지표를 측정할 수 있어야 한다. 그리고 버튼 변경 전의 데이터도 확보해야 한다. 검정색 버튼일 때의 클릭율을 알아야 이보다 높은지 낮은지 확인할 수 있느니 말이다. 엄격한 검증을 위해서는 클릭율이 어느 정도 높아져야 정말로 높아졌다고 말할 수 있는가를 살피는 것이다.

   독립 변인과 종속 변인을 명확히 정의하고, 독립 변인 외의 변수들을 통제하고, 종속 변인에 미치는 영향을 정확히 측정할 수 있는 기반이 갖춰져야만 진정한 애자일 문화를 수행할 수 있는 것이다. 제품을 기준으로 생각해보면 하나의 실험에서 너무 많은 변수가 영향을 주어서는 안되며 고객 데이터를 정확히 측정할 수 있어야 한다는 의미가 된다.

   여기에 더해 애자일은 불확실성에 대응하는 방법이라는 마인드셋도 함께 필요하다. MVP에 대한 이해가 필요하다. 실험을 할 정도의 퀄리티가 갖춰지면 제품은 고객에게 전달되어야 한다. 실험 환경도 100% 완벽하게 갖출 수는 없다. 신뢰도가 일정 수준 이상 갖춰졌다는 판단이 들면, 실험을 해야 한다. 실험실을 세팅하는데 너무 많은 시간을 들여서는 안된다. 

 

 

지금 당장 할 수 있는 일은 무엇일까?

 

   거대한 조직의 일원이라면 입사한 지 얼마나 안된 구성원에 불과하다면 조직의 문화를 바꾸는 것은 불가능한 일처럼 보일 것이다. 그럼에도 방법은 있다. 우선, 내가 할 수 있는 일부터 찾아야 한다. 주어진 조건을 최대한 활용해야 한다. 반드시, 기획자, 개발자, 디자이너가 한 팀이어야 하는 것은 아니다. 지라를 꼭 써야 하는 것도 아니다. 워터폴 방법론을 쓰고 있더라도 마찬가지이다. 첫번째는 고객의 반응을 찾는 것이다. 모든 것은 여기에서 시작되어야 한다. 나의 제품에 고객이 어떻게 반응하고 있는지 살피자. 데이터가 축적되어 있지 않다면 DB에서 찾거나 새롭게 축적할 방법을 살펴보자. 정량 데이터가 없다면 유저 테스트, 고객 인터뷰를 통해 정성적인 데이터라도 얻어야 한다. 그리고 제품이나 서비스에 변화가 생길 때마다 결과를 추적해보는 것이다.

   데이터를 확보했다면, 두번째는 실험이다. 내가 영향을 줄 수 있는게 무엇인지 찾아본다. 대규모 기능을 넣는게 불가능하더라도 말이다. 작은 문구 하나, 작은 팝업 하나라도 괜찮다. 일단은 나에게 허락된 실험이 무엇인지 알아야 한다. 그리고 작은 변화를 통해 실험 마인드셋과 프로세스를 익혀야 한다. 내가 실험에 익숙해졌다면 이제는 지원군을 확보해야 한다. 동료들을 돕거나 불편한 점을 물어보면서 업무 프로세스에 대한 고충을 파악하는 것이다. 공감대를 확보하고 조직에 불어넣을 수 있는 가장 작은 변화가 무엇일 지 생각해본다. 효과는 있지만 사람들을 불편하게 만들 지는 않을 만한 변화가 필요하다. 그리고 이런 변화들이 쌓이면 느리더라도 새로운 문화가 자리잡을 수 있을 것이다.

   물론, 조직 문화라는 것이 그리 간단히 바뀔 수 없다는 것은 알고 있다. 그러나 불가능한 것도 아니다. 나와 우리에게 주어진 것이 무엇인지를 살피고 나의 의견에 공감하는 사람들의 수를 늘려가다 보면 어제보다는 나은 오늘이 될 것이다.

 

 

2024.01.28