애자일 소프트웨어 개발 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획에 따르기보다 변화에 대응하기를가치있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
당근마켓에서의 경험은 내게 큰 도움이 되었다. 애자일 워크플로우와 MVP개발방법론의 경험이 그 중 으뜸이다.
여전히 "애자일하게 일하는게 무엇인가"를 글로써 정의하는 것은 힘든일이다. 다만, 내가 당근마켓에서 실제로 보고 겪은 것은 내 생각을 혁신시켰다.
머리를 한대 얻어 맞은 그 기분과 경험의 조각들이 아직 생생하다. 그리고, 그 기억들이 살아있을 때를 틈타서, 내가 실천할 수 있는 것들을 조금이나마 정리해본다.
생각을 멈추고 실행하라
당근마켓의 워크플로우를 경험하기 전에는, 치밀하고 완벽한 계획이 불필요한 리소스를 줄이고 성공으로 빠르게 다가가는 지름길이라고 생각했다.
제품을 개발하며 자꾸 나오는 엣지케이스와 버그들, 논리적인 수정사항들, 그것들이 모두 제대로 준비되지 않은 프로젝트이기에 발생된 해로운 것들로 치부했다. 실패는 용납할 수 없는 것이었지만, 늘 일어났다. 그렇게 점점 실패를 피하기 위한 고민은 길어졌고, 개발 리소스는 늘어만 갔다.
당근마켓에서는 그런 실수를 하기 싫었다. 치밀하게 준비해야했다. 우리는 어떤 우아한 제품으로 유저에게 가치를 전달할지 이틀동안 고민했다.
시장에서 먹힐 만한 아이디어이면서, 팀원 모두가 동의 할 만한 논리를 가진 합의점을 짜내느라 고통스러워 했다.
그런 우리의 모습을 지켜보던 똑똑하고 유능한 멘토가 가볍게 던진 말은 가히 충격이었다.
"그냥 일단 이렇게 만들어 보면 안돼요?"
자유롭게 슥슥 그려낸 프로토타입, 그냥 그저그런 게시판이었다. 우리가 생각하던 모든 문제를 해결한 완벽한 커뮤니티의 형태가 아니었다.
하지만 그게 본질이었다. 유저들이 서로 글을 쓰고 읽을 수 있는 게시판, 정말 '최소' 가치를 지닌 제품이었다.
완벽한 제품을 위해 고민하던 지난 이틀의 우리가 바보같았다. 해야할 일이 명확해졌고, 바로 앞으로 나아갈 수 있었다.
이 경험이 시사한 바는 명확하다. 일단 만들어서 공개해야 개선할 점이 생긴다. 개선을 하면 제품은 발전한다. 이를 반복하며 점점 성숙한 제품이 된다.
생각과 고민만으로는 아무것도 이루어지지 않는다. 어차피 지금의 우리는 해답을 모른다. 빠르게 실패하는 것은 빠르게 보완할 수 있는 길이다. 그리고 이것은 아마 현실적으로 가장 빠르게 성공 할 수 있는 법이다.
계획에 따르기 보단 변화에 대응하기를 / 포괄적인 문서보다 작동하는 소프트웨어를
변화에 열려 있다는 것은, 변화를 예측하는 것이 아니다. 그저 변화가 가능한 것으로 충분하다.
문제를 잘 쪼개라
커뮤니티 서비스를 하면서 가장 힘들었던 점은 유저들로 하여금 글을 쓰게 만드는 것이었다. 사전오픈 페이지를 만들어 보낸 후, 우리는 그럴듯한 게시판 형태를 먼저 먼저 만들었다.
우리는 우리가 얼마나 성공에 가까이 있는 지에 대한 지표로, '유저들이 자발적으로 작성한 글의 수'를 기준삼았다. 그래서, 사람들이 글쓰기 버튼까지 유입되었는지에 대한 퍼널을 측정했다. 그리고 그 퍼널을 개선하는데 상당히 많은 시간을 쏟았다.
몇 일이 흘렀을 때, 우리에게 남은 것은 적당히 잘 동작하는 아무런 글도 없는 게시판 달랑 하나였다. 글쓰기 버튼까지의 퍼널을 성공적으로 개선했음에도, 아무도 글을 써주지 않았다. 사실 가장 먼저 확인해야할 문제는 사람들이 과연 게시판에 글을 쓸 것인가 인데, 우리는 그 앞의 온보딩이 허들이 되니, 마니 하는 이야기로만 하루를 보냈다.
우리는 활성화된 게시판을 원했고, 사실 활성화된 게시판은 글이 자주 쓰여지는 게시판이다. 어떻게 유저들이 글을 쓰게 할 것인가? 는 글을 보여주는 게시판이 없어도 실험 할 수 있는 가설이었다. 글을 어떻게 노출 할지, 접근성은 어떠할 지는 우리가 가진 진짜 문제와는 별개의 문제였다.
이미 많은 리소스와 기회비용을 지불하고 나서야 비로소, 문제를 잘 쪼갠다는 것이 어떤 의미인지 와닿을 수 있었다.
문제를 정의하고 해결을 해야할 때, 문제가 간결하고 명확해질수록 해결방법 또한 떠올리기 쉬워진다. 문제의 해결방법이 너무 복잡하고 길게 느껴진다면, 문제를 더 간단하게 정의 할 수는 없는 지를 늘 생각해 봐야 한다.
측정할 수 있는 환경을 마련하라
앞서 말한 것 처럼, 게시판을 만들기 전, 우리는 사전오픈을 통해 우리 아이템에 대한 유저들의 관심도를 알아보기로 했다. 나름 제품을 만들지 않고 시장에서 가치를 확인하는 멋진 방법이었다. 그리고 유저들에게 한마디씩 커뮤니티에 올릴 글들을 받았다. 작성될 컨텐츠의 특징을 파악하려는 심산이었다.
사전오픈이 마무리 될 쯤, 많은 유저들의 오픈예약과 짧은 한마디들을 얻었다. 상당히 많은 유저가 모였고, 언뜻보면 좋은 결과였다. 그렇게 우리는 많은 유저들이 우리의 제품을 원한다고 착각했다.
실상은 그렇지 않았다. 사람들은 그저 hooking 되어 예약을 신청했을 뿐이고, 우리 아이템의 가치가 시장에 증명된 것은 아니었다. 또한, 사람들이 써준 글들은 너무 각양각색이라 이렇다할 특징을 정의할 수가 없었다.
우리가 그런 착각을 한 까닭은 데이터의 수집방법이 잘못되었기 때문이다.
우리는 애초에 사전예약을 통해서 수집/측정하고 싶은 데이터가 무엇인지 고심하여 정하지 않았다. 데이터를 측정하기 위한 충분한 환경을 마련하지도 못했다.
결과적으로 많은 맥락이 생략되어 빈틈이 많고 가공이 불가능한 데이터 조각들만이 남았다.
유저를 대상으로 하는 서비스의 '고객'은 우리의 제품을 사용해주는 유저들이다.
우리가 제품의 완성도를 목표로 한다면, 완성된 제품을 유저들이 사용하도록 이런저런 말들을 붙여 협상해내야한다. 하지만, 완성도 높은 제품이라고 해서 유저가 그것을 필요로 할 것이라는 생각은 오산이다. 그 제품은 우리에게만 '완성된' 형태이고, 이것은 협상에 낼 만한 좋은 카드가 아니다.
올바른 목표는 제품의 완성도가 아니라 유저들을 알아가는 것이다. 진짜 유저 인터뷰를 통한 소통도 좋지만, 가장 솔직한 유저들의 목소리는 데이터에 담겨있다. 그래서 수집하는 데이터의 종류와 그 방법을 결정하는 것은 제품을 만드는 것 이상으로 중요하다.
계약 협상보다 고객과의 협력을
실패가 중요한 이유는 레슨을 만들어 내기 때문이다. 하지만 레슨은 실패의 결과를 수치적으로 볼 수 있어야 분석을 통해 이끌어 낼 수 있다.
측정이 이루어져야 데이터가 나오고, 데이터가 나와야 분석이 가능하며, 분석이 가능해야 도출된 레슨을 바탕으로 개선된 제품이 나올 수 있다.
