토스 개발자와 트위터 쪽지를 나누며 애자일을 엿보다
[코드스테이츠 PMB 10기] 워터폴 vs 애자일
비바리퍼블리카 프론트엔드 엔지니어,
유르마무님과 트위터로
소통하게 된 사연
1. 프로덕트 개발 방법론
PM은 What to build(기획)과 How to build(창출)을 통해 우리 서비스의 문제를 단기적·장기적인 관점에서 해결할 수 있어야 한다. 단기적으로는 문제점을 반복 개선해 나가고, 장기적으로는 기시적인 전략을 세워 나갈 수 있어야 한다.
좋은 프로덕트를 만들기 위해서는 좋은 기획을 하는 것 뿐만 아니라 프로덕트 개발 생애주기를 잘 관리하는 것 또한 중요하다. 좋은 제품을 제때 출시하기 위해서는 PM의 관리가 필요하고, 이 관리를 위해서는 프로덕트 개발 방법론인 워터폴과 애자일을 이해하고 있어야 한다.
워터폴 vs 애자일
워터폴(Waterfall)은 고객 테스트 없이 팀 및 이해관계자들끼리의 결정만으로 제품 개발 후 시장에 내놓는 전략이다. 고객이 가진 문제와 해결책을 분명하게 이해하고 있고, 결과에 대한 확신까지 가지고 있는 조직에게 적합한 모델이다. 고객의 요구사항이 분명하기 때문에 요구사항, 가격, 기한은 정해져 있고 품질만이 남은 변수가 된다.
따라서 워터폴은 관리가 비교적 용이하다는 장점이 있다. 각 단계별로 업무 분담의 효율성을 최대한으로 끌어올려 최소한의 요구사항을 만족시키는 데 집중하기 때문이다.
그러나 요구사항을 만족하는 제품을 정해진 가격과 기한 내에, 좋은 품질로 만들어내기 위해서는 체계적인 관리 기법이 적용되어야 한다. 이렇듯 초기 요구사항이 명확하기에 최종적으로 제품이 완성되었을 때 결과물이 고객의 기대에 미치지 못할 수 있다.
뿐만 아니라 고객의 요구사항이 즉각적으로 변화하고, 이에 대한 즉흥적인 대응이 요구되는 최근의 트렌드에는 워터폴이 더더욱 유용하지 못할 수 있다. 능동적이고 유연하게 움직여야 하는 IT 스타트업에서 특히 워터폴의 한계점이 도드라지고는 한다.
반면, 애자일의 경우 소프트웨어를 개발하는 스타트업들에게 보다 적합한 모델이라고 볼 수 있다. 애자일(Agile)은 MVP(최소 기능 제품)을 빠르게 출시하여 사용자들의 피드백을 받고, 이를 개선하는 과정을 반복하는 순환식 개발 방식이다.
1990년대 이후, 소프트웨어의 시장이 넓어지고 시장의 변화가 급속도로 빨라짐에 따라 프로덕트 개발의 불확실성이 증가하기 시작했다. 이전에는 선형적인 작업 순서와 분업으로 시간과 비용의 효율성을 추구하는 방법론이 크게 문제되지 않았지만, 대중들이 원하는 것들이 많아지고 시장에 대한 니즈가 다양해짐에 따라 고객의 요구를 빠르게 확인하고 검증할 수 있는 방식의 필요성이 증대되었다.
프로덕트가 완성되기 전까지는 고객의 반응을 확인할 수 없다는 워터폴의 불확실성을 줄이기 위하여 애자일은 MVP에 집중한다. 애자일은 처음부터 완벽한 프로덕트를 만들려고 하기보다는 고객의 요구를 확인하고 검증할 수 있는 '최소한'의 기능을 먼저 만들고, 고객의 반응을 확인해 피드백을 하면서 프로덕트를 개선한다.
애자일의 사례 : 아이폰
우리가 잘 알고 있는 아이폰 역시 위와 같은 애자일 방법론의 좋은 예시이다. 2007년 처음으로 출시된 당시 아이폰에 탑재된 iOS에는 많은 기능이 빠져 있었다고 한다. 복사-붙여넣기, 메시지로 사진 전송하기, 멀티태스킹과 같은 기능은 2007년부터 2011년에 걸쳐 하나씩 추가되었다. 만약 애플이 이러한 기능들을 2007년부터 한꺼번에 구현하려고 했다면 아마 2007년에 아이폰을 출시하는 데 실패하였을 것이고, 대중의 사랑을 받지 못했을 것이다.
2. 애자일한 문제 해결법
애자일은 무조건 옳은 걸까?
그렇지만 "워터폴은 구식이고, 애자일은 정답이다" 식의 단정은 좋지 않다. 오히려 비즈니스와 서비스의 특성을 제대로 이해하지 못한 채 애자일만을 고집하는 행동은 좋지 않은 결과를 낳을 수 있다. 애자일은 어디까지나 워터폴이 가진 한계점을 보완하기 위해 등장한 방법론이지, 모든 사업에 통하는 만병통치약이 아니기 때문이다.
결국 '애자일을 잘한다'는 것은 애자일이 비즈니스와 서비스에 부합하며, 최종적으로 애자일을 적용했을 때의 이익을 거둘 수 있을지에 달려있다. 이를 위해서는 구성원들의 자세와 역할이 매우 중요하다. "남들이 하니까 우리도 해야 해"와 같은 마인드로 애자일을 시도했다가는 '어설픈 애자일'에 그칠 수밖에 없다.
애자일 프로젝트는 끝이 없다. 애자일의 데드라인은 고객의 완전한 만족이다. 그리고 프로젝트를 한 번이라도 운영해봤던 사람이라면 이것이 얼마나 말도 안 되는 목표인 줄 잘 알고 있을 것이다(...). 설령 프로젝트 경험이 없다고 해도 무언가를 '완전하게' 만족한다는 것이 얼마나 어려운 지 누구나 이해할 수 있을 테다. 한마디로 애자일은 무한의 굴레와 다름 없다는 뜻이다.
애자일하게 일하고 싶다면?
따라서 애자일을 시도하려는 기업, 또는 애자일을 시도 중인 기업은 장기적인 관점에서 사고할 수 있어야 한다. 거시적인 로드맵을 그리고, 그 로드맵을 끊임없이 수정하고, 이를 바탕으로 프로덕트를 계속 개선할 수 있어야 한다.
오늘의 포스팅을 통해 나도 '애자일하게 일하는 것'이 어떤 것인지 이해할 수 있었다. 그동안 취업 준비를 하면서 애자일하게 일해본 경험이 있는 사람을 우대하는 공고를 종종 본 적이 있다. 다들 애자일, 애자일 하기에 서비스 기획 분야의 인기 도서, <현업 기획자 도그냥이 알려주는 서비스 기획 스쿨>까지 구매해서 읽어봤지만 원활하게 이해되는 부분은 많지 않았다.
3개월 동안의 인턴 경험이 전부인 대학생에 불과했던 그때의 나는 애자일을 '개념'으로 이해하려고 했기 때문에 실패했던 것 같다. 애자일은 기획, 개발, 디자인 등 특정 분야에 속한 하위 개념이 아니라 이 모든 프로세스를 포괄하는 총체적인 '방법론'이다. 따라서 "애자일은 ○○이다"라는 방식으로 간편하게 설명되기 어렵다. 이번 포스팅을 통해 최대한 많은 자료와 사례를 찾아보고 체득하는 것이 애자일을 이해하는 왕도라는 점을 깨달았다.
3. 가장 애자일한 서비스, 토스
애자일한 방식으로 운영되고 있는 대표적인 국내 서비스로는 모바일 금융 플랫폼 토스를 들 수 있다. 토스의 운영사인 비바리퍼블리카의 이승건 대표는 2019년 한국경제와의 인터뷰에서 오늘날 기업의 성패를 가르는 것은 기민성(agility)이라고 강조한 바 있다.
이승건 대표는 "굉장히 빠르게 변화하고 있는 핀테크 시장에서 무엇이 통할지 예측이나 직감으로 알아내는 것은 어렵다"며 "빠르게 실험하고 안 되는 것은 빠르게 접어 실패의 비용을 최소화하는 방향으로 (기업 문화를) 진화해 나가야 한다"고 덧붙였다.
이렇듯 비바리퍼블리카는 탑다운이 없고 실무자에게 높은 자율성을 부여하는 애자일 조직 체계를 바탕으로 시장의 변화에 재빠르게 대처하고 있다. 결국 애자일을 핀테크 시장에서 살아남기 위한 전략으로 채택한 것이다.
토스 프론트엔드 슬랙 채널에
나의 포스팅이 공유된 건에 대하여
역시 이런 소제목은 뭔가 잘못되었나...?사실 오늘 주어진 포스팅 주제가 따로 있었지만, 내가 토스를 선택하여 워터폴과 애자일을 공부한 데는 특별한 이유가 있었다. 소제목이 조금 어이 없을 수는 있지만, 요즘 유행하는 라노벨식 제목짓기로 지어보았다...^^
오늘 브런치 방문자 수를 확인해 보니 내가 3월 9일 작성한 포스팅, <뉴닉이 앱에서만 멤버십 콘텐츠를 제공하는 이유>(참고) 의 조회수가 급증한 것을 발견했다. 무슨 이유인가 싶어 유입 경로를 확인하니 오전 9시경 비바리퍼블리카의 프론트엔드 엔지니어이자 토스 ‘내 보험 조회’의 프론트엔드를 담당하신 유르마무님이 나의 포스팅을 인용하여 다음과 같은 트윗(참고)을 남기신 걸 발견했다.
나는 해당 포스팅에서 네이티브 앱, 하이브리드 앱과 같은 앱의 종류를 비교하면서 네이티브 앱의 사례로 토스를 끌어왔었다. 뉴닉의 콘텐츠 탭과 토스의 혜택 탭의 버튼 작동 방식을 근거로 뉴닉은 html 마크업이 유력하지만, 토스는 네이티브 앱임이 분명하다(!)고 확신을 내려버렸다. 그러나 유르마무님의 말에 따르면 혜택 탭은 웹뷰라고 한다.
하단으로 이어진 답글까지 살펴보니, 심지어 헤더까지도 웹뷰라고 한다. 다른 트위터 유저들도 "네이티브 앱인 줄 알았다", "감쪽같이 잘 만들었다"는 등의 반응을 보였다. 그러니 개발에 대한 지식이 빈약한 나로서는 감쪽같이 속을 수밖에. (참고로 첫 번째로 답글을 남긴 YoungJae Kwon님(참고)은 내가 평소에 즐겨보는 인스타툰 작가이자 개발자이신 준진님(참고)을 통해 알고 있던 개발자였기에 그것 또한 너무 신기했다!)
이런 신기한 경험(?)을 통해 배운점이 많았기에, 유르마무님에게 트위터 쪽지를 냉큼 보내봤다. 그랬더니 얼마 지나지 않아 위와 같은 답장을 주셨다. 토스 프론트엔드 슬랙 채널에 포스팅을 공유하셨다고, 그리고 다들 뿌듯해했다고 말씀하셨다(ㅋㅋ). 감사한 마음으로 대화를 마친 나의 머릿속에는 토스 프론트엔드 슬랙 채널이라는 단어가 맴돌고 있었다.
토스 팀 조직구조. 출처=https://blog.toss.im/article/tossdeveloper-interview그래서 토스의 개발 팀은 어떻게 구성되어 있을지 애자일 방법론에 기반하여 찾아보았다. 살펴본 결과, 토스 직원들은 사일로라고 불리는 목적 조직에서 각자 독립적으로 일하고 있다고 한다. 사일로는 토스의 기본 조직 단위이자 소팀제 업무 조직이다. 비바리퍼블리카는 토스의 개별 팀이 마음껏 서비스를 변경하고 배포할 수 있도록 기술적인 기반을 만들어 놓고, 각각의 사일로에서 하나의 제품을 전담하여 일하도록 했다.
또한, 각 사일로에서 동일 업무를 담당하는 직원들끼리의 협의체, 챕터가 존재한다. 챕터는 각 사일로의 마케팅, 디자인, 개발 등의 담당자들이 따로 모여서 논의하는 장인데, 이때는 전문성이 중요하게 작용한다고 한다. 즉, 챕터를 같은 일을 하는 사람들을 모아놓은 작은 조직으로 이해할 수도 있다. 아마 유르마무님이 언급하신 토스 프론트엔드 슬랙 채널은 프론트엔드 엔지니어로 구성된 챕터의 커뮤니케이션 장소가 아니었을까 싶다.
이렇듯 실무자와의 짧지만 재미있는 소통을 통하여 비바리퍼블리카의 애자일 프로덕트 개발 방식까지 엿볼 수 있었다. 2015년에 출시된 토스가 2022년 현재 핀테크 사업의 선두주자로 앞서나갈 수 있었던 결정적인 이유가 바로 이와 같은 '애자일함'이 아니었을까 싶다. 그렇지만 애자일이 언제나 정답은 아니며, 워터폴이냐 애자일이냐를 판가름하는 것보다 우리 서비스에 대한 심도 있는 이해와 고민이 우선시되어야 한다는 점 역시 배웠다.
참고자료
