빠른 속도, 좋기만 한 것은 아닙니다.
운영과 프로젝트는 속도를 다르게 인식해야 합니다.
우리나라는 외국에 비해 일상생활에서 ‘빨리빨리’ 문화가 확산되어 있습니다. 음식 배달, 새벽 배송, 인터넷 설치 등이 그 예입니다. 이러한 빨리빨리는 회사의 업무에서도 예외가 아닙니다. 오히려 더 심해집니다. 빨리빨리를 관리하기 위한 지표도 많습니다. ‘리드타임 단축’ 같은 업무를 더 빨리 하는 것을 목표로 하고, ‘생산성 향상’은 같은 시간 동안 더 많이 만드는 것을 목표로 합니다.
대개의 경우 빠른 속도는 좋습니다. 그러나 빠른 것보다 중요한 것은 ‘올바른 일을 빨리 하는가?’입니다. 개발생산성을 ‘생산량/시간’으로 측정하지만 진정한 개발생산성은‘가치/시간’이 맞지 않을까요? 같은 시간에 보고서를 많이 작성하는 것이 기획의 생산성이라고 하면 모두 말도 안 된다고 생각합니다. 그러나 그 말도 안 되는 주장이 소프트웨어 개발에서는 일상적입니다. 같은 시간 동안 더 많이 개발하는 것을 우대하는 분위기를 조성합니다.
빠른 속도를 무리하게 밀어붙이면 다음과 같은 부작용이 발생할 수 있습니다.
결과물의 품질이 나빠집니다.
속도를 높이는 손쉬운 방법은 품질을 희생하는 것입니다. 품질은 일정만큼 눈에 띄지 않아 속이기 쉽기 때문입니다. 기본적인 기능은 작동하지만, 예외사항을 고려하지 않는 개발이 대표적인 예입니다. 품질저하는 지뢰에 비유할 수 있습니다. 지뢰가 작으면 리스크를 감내할 수 있지만, 지뢰가 많아지면 지뢰를 피하기 위해 노력하는 시간이 증가할 뿐 아니라 지뢰를 밟아서 피해를 입을 가능성도 높아집니다. 결과적으로 빨리 개발하기 위한 노력이 오히려 개발을 지연시킵니다.
프로젝트 팀원의 자존심을 떨어뜨립니다.
완성도 낮은 코드를 개발하고 싶은 개발자는 없습니다. 시간이 부족하고, 무리한 일정준수(또는 단축)를 요구하는 분위기 때문에 개발 완성도가 낮아도 완료했다고 보고할 뿐입니다. ‘납기는 생명, 품질은 자존심’이라는 구호는 두 가지 모두를 강조하고자 만든 구호이지만 자존심(품질)을 위해 생명(납기)을 포기할 사람은 많지 않습니다. 프로젝트 팀원들의 자존심이 낮아지면 프로젝트 팀의 활력이 없어집니다.
번 아웃 되는 팀원이 증가합니다.
속도를 높이기 위해 팀원들은 품질을 희생하지만 관리자들은 잔업을 요구합니다. 시간으로 결과를 통제하려는 시도는 아주 짧은 기간은 효과가 있지만 장기적으로는 대부분 실패합니다. 그러나 주변 사람들에게 보여주기 식으로 잔업을 하는 경우도 많습니다. ‘개발속도를 높이기 위해 우리가 이렇게 헌신하고 있다’는 것을 과시하는 것입니다. 이렇게 하는 이유는 빨리 못해도 면죄부를 받기 위해서입니다. 그러나 그 과정에서 영혼을 갈아 넣는 팀원이 한 명 두 명 늘어납니다. 영혼을 갈아 넣을 가치가 있는 일인지 없는지는 팀원들이 자발적으로 결정할 사항이지 관리자가 요청해서는 안됩니다.
‘빨리’가 조직의 문화로 자리 잡습니다.
보다 빠른 개발에만 집중하다 보면 주변을 살펴보지 않고 빨리 달려가는 것에 집중하는 조직문화가 형성되기 쉽습니다. ‘일단 방향을 정하면 경주마처럼 주변은 쳐다보지 않고 빨리 달려가기’가 조직 내에 만연하게 됩니다. 그렇게 되면 빠른 속도의 부작용이 발생할 가능성이 높습니다.
프로젝트의 속도와 운영업무의 속도는 다르게 접근해야 합니다. 특히 신상품을 개발하는 프로젝트는 개발하는 속도보다 고객가치를 학습하는 속도가 중요합니다. 업무유형에 따라 유의해야 할 속도를 바라보는 관점은 다음과 같이 달라야 합니다.
1. 프로젝트에서는 ‘많은 개발’보다 ‘많은 가치제공’에 집중해야 합니다.
프로젝트에서 부작용 없이 일정을 당기는 가장 확실한 방법은 적게 개발하는 것입니다. 100개의 기능(feature)보다 50개의 기능만 개발하면 훨씬 짧은 기간 내에 프로젝트를 완료할 수 있습니다. 프로젝트 팀은 고객들이 가치를 느끼지 못하는 기능들을 많이 개발합니다. 따라서 빨리 개발하라고 상품개발팀을 압박하기 전에 개발할 기능들의 가치를 평가해야 합니다. 같은 기간 동안 얼마나 많은 양을 개발하는가에 집중하는 대신 같은 기간 동안 얼마나 많은 가치를 제공할 지에 집중해야 합니다. 고객이나 이해관계자들은 상품개발팀이 얼마나 열심히 일하고 얼마나 효율적으로 일하는지 관심 없습니다. 그들이 관심 있는 것은 ‘개발의 속도’보다 ‘가치를 제공하는 속도’입니다.
가치를 제공하는 속도를 결정하기 위해서는 각 상품기능에 대해 세 가지 요소를 고려해야 합니다.
- 비즈니스 가치 또는 고객가치 (A)
- 빠른 출시의 필요성 (B)
- 개발기간 또는 개발비용 (C)
가치를 제공하는 속도를 결정하는 식은 ‘(A+B)/C’입니다. 즉 비즈니스 가치가 높고, 빠른 출시가 필요하고, 개발기간이 짧을수록 가치를 제공하는 속도가 빨라집니다. 각 항목의 측정단위는 다르기 때문에 실제의 측정단위가 아니라 사용자 스토리(user story)처럼 개념적인 측정단위인 피보나치수열(1,2,3,5,8,13,21…)의 값을 사용하면 가치를 제공하는 속도를 쉽게 측정할 수 있습니다.
2. 가치를 판단하기 힘들 때는 학습의 속도가 중요합니다.
개발할 상품기능의 가치를 판단하기 힘들 때는 직접 부딪혀 보는 것이 가장 좋습니다. 상품개발팀이 개발할 기능을 고객들이 직접 사용하게 해 보고 고객이 경험하는 가치를 확인하는 것입니다. 스타트업은 창업자의 가설(고객들은 ~~ 상품을 좋아할 것이다)을 투자자들에게 입증해야 투자를 받을 수 있습니다. 스타트업은 생존할 수 있는 기간이 제한되어 있습니다. 예를 들어 초기 투자금이 2억이고 월 운영비가 2천만원이라면 10개월 동안 뭔가를 보여주고 새로운 투자를 유치하지 못하면 더 이상 생존할 수 없습니다. 이를 런웨이(run way)라고 합니다. 비행기가 활주로가 끝나기 전에 이륙해야 하는 것과 같습니다.
‘상품기획 → 상품개발 → 출시’ 과정은 고객가치 또는 비즈니스 가치에 대한 학습과정으로 이해할 수 있습니다. 학습의 속도가 느릴수록 실패에 대한 비용이 커집니다. 예를 들어 10개월 런웨이 동안 단 한 번의 출시만 하는 것과 3번의 출시를 하는 것은 다릅니다. 후자의 경우 두 번의 실패에서 제대로 학습한다면 세 번째 출시에서는 성공의 가능성이 이전보다는 높아집니다. 팀이 의도한 대로 성공하지 않았는데 뭔가를 제대로 배우지 못했다면 그동안의 노력들은 모두 낭비가 됩니다. 그러나 성공하지 못하더라도 의미 있는 통찰을 얻었다면 그동안의 노력들은 낭비가 아닙니다. 에릭리스는 이를 ‘유효한 학습’이라 정의했고 《린 스타트업》 (2012)에서 다음과 같이 강조했습니다.
‘학습’이라는 것은 실패에 대해 가장 흔하게 사용하는 변명이다. 유효한 학습이란 팀이 스타트업의 현재와 미래의 성장에 꼭 필요한 진실을 발견했음을 보여주는 방법이다. 기능 A를 개발했을 때 이것이 고객행동에 어떤 영향을 미쳤는가? 하지만 이 질문에 대답하려면 너무 많은 노력이 필요했다. 정확히 언제 기능 A를 고객들이 사용하기 시작했는가? 어떤 고객들이 그 기능을 사용하기 시작했는가? 이런 질문들에 대답하려면 데이터를 분석하고 또 분석해야 했다.
고객가치를 학습할 때 중요한 세 가지 원칙은 다음과 같습니다.
정확하게 배워야 합니다.
정확하게 배운다는 것은 위에서 설명한 유효한 학습과도 같습니다. 고객이 (출시한 또는 출시할) 상품을 사용하면서 경험하는 내용을 이해하는 것이 정확한 학습입니다. 특정 기능을 고객이 원하지 않는다는 것은 파악하기 쉽지만 고객이 무엇을 원하는지는 파악하기 힘듭니다. 예를 들어 인터뷰 대상에게 프로토타입을 보여주면서 체계적으로 질문하면 특정기능을 고객이 원하는지 원하지 않는지는 비교적 쉽게 파악할 수 있습니다. 그러나 고객이 무엇을 원하는지를 파악하는 것은 다른 문제입니다. 그것을 파악하기 위해서는 고객들이 무엇이 불편한지 즉 고객의 문제를 정확하게 파악해야 합니다.
정확한 고객가치를 학습하기 위해서는 ‘고객의 문제’와 ‘문제해결 방법’을 구분하는 것이 중요합니다. ‘~~ 기능을 포함한 상품이 출시된다면 구매 시겠습니까?’라는 식의 인터뷰를 하기 쉬운데 그런 질문으로는 ‘고객의 문제’를 파악하기 힘듭니다. 고객의 문제를 파악하기 위해서는 ‘왜(why)’에 집중해야 합니다. 왜 이런 기능을 좋아하는지, 싫어하는지 정확하게 이해야 합니다. 이러한 기법들을 VOC 분석기법 또는 상품기획 가설검증 기법이라고 합니다. 이러한 기법을 적용하기 위해서는 시간과 비용이 투입되기 때문에 고객가치를 검증할 필요가 있는 기능인지를 잘 판단해야 합니다.
빨리 배워야 합니다.
출시 후 일정시간이 지나면 상품관리자의 가설을 시장에서 확인할 수 있습니다. 그때라도 고객에 대한 통찰을 얻어 다음 출시에 반영할 수 있지만, 이미 많은 시간과 비용을 지불했다면 다음 기회가 없을 수도 있습니다. 특히 경쟁상품과 빠른 출시를 다투고 있는 상황이라면 빨리 학습한 내용을 상품에 반영하는 것이 중요합니다. 빨리 배우기 위해서는 고객의 경험을 확인하는 시기를 당겨야 하고 그러기 위해서는 고객에게 보여주는 프로토타입을 만드는 시간을 줄여야 합니다. 프로토타입을 만드는 시간을 줄이기 위해서는 핵심개념에 집중하여 최대한 작은 기능을 개발해야 합니다.
싸게 배워야 합니다.
싸게 배우는 것은 빨리 배우는 것과 밀접한 관련이 있습니다. 대부분은 빨리 배울수록 학습을 위한 비용이 줄어듭니다. 학습을 위해 작은 비용을 지불하면 실험이라 할 수 있지만, 큰 비용을 지불하면 실패입니다. 싸게 배우려면 낭비를 제거해야 합니다. 학습과 상관없는 활동은 낭비입니다. 중요도가 낮은 기능을 프로토타입에 포함하거나 프로토타입을 고품질로 개발하는 것이 대표적인 낭비입니다. 고객의 문제를 파악하거나 문제를 해결하는 솔루션의 적합성을 확인하는 것은 고품질이 아니라도 가능합니다.
<러닝린,2012>에서는 학습, 속도, 초점을 벤 다이어그램으로 정리하여 다음과 같이 설명하고 있습니다.
① 초점 없는 속도와 학습은 섣부른 최적화이다.(틀린 것을 배우는 것)
② 학습 없는 속도와 초점은 제자리걸음이다.
③ 속도 없는 학습과 초점은 자원을 소진한다.
3. 잦은 릴리즈보다 적정한 주기로 상품을 릴리즈 하는 것이 좋습니다.
상품개발속도에 집중하면 상품의 릴리즈 주기가 짧아집니다. 릴리즈 주기와 기업의 이익은 어떤 관계가 있을까요? 극단적으로 매주 릴리즈 하면 이익은 어떻게 될까요? 릴리즈 주기가 너무 길어도 문제가 되겠지만 릴리즈 주기가 너무 짧아도 문제가 됩니다. 년간 릴리즈 횟수와 수익성의 관계는 아래 그림과 같습니다.
년간 릴리즈 횟수와 수익성물론 적정 릴리즈 횟수는 기업에 따라 상품에 따라 달라집니다. 적정 릴리즈 횟수는 새로운 기능에 대한 고객과 기업의 수용능력에 달려 있습니다. 새로운 기능을 제공하는 기업의 관점에서는 기존에 릴리즈한 상품에서 고객들이 어떤 경험을 하는지 정확하게 이해한 뒤 다음 릴리즈에 반영할 기능을 결정해야 합니다. 기존 상품에서 교훈을 얻기도 전에 속도전에 밀려 새로운 기능을 개발하면 그 기능을 고객이 좋아할 가능성이 낮습니다. 부실한 기능을 개발하는 문제만 있는 것이 아닙니다. 릴리즈가 잦아지면 개발 비용, 마케팅 비용도 증가합니다. 즉 상품개발과 마케팅에 투입되는 비용이 많아져 상품의 수익성에도 부정적인 영향을 미치게 됩니다.
잦은 릴리즈는 고객관점에서도 부담이 됩니다. 기능 개선을 포함하는 정기 릴리즈를 자주 하는 것이 능사는 아닙니다. 예를 들어 아이폰은 매년 9월에 1회 신상품을 릴리즈하고 세일즈포스닷컴도 년 3회만 기능 개선 릴리즈를 제공합니다. 특히 모바일 앱과 같은 SaaS 상품은 잦은 기능개선이 사용자들에게 부담이 될 수 있습니다. 하드웨어 상품은 고객이 구매를 결정하지만 SaaS 서비스는 고객이 새로운 기능을 강제로 구매당하기 때문입니다. <인스파이어드, 2018>의 저자 마티 케이건은 잦은 릴리즈를 ‘사용자 학대’라고도 했습니다. 특히 B2B SaaS 상품은 신규기능이 릴리즈 되면 기존의 업무 프로세스가 변경되는 경우가 많기 때문에 직원들이 새로운 기능에 적응하기 위해 불편을 감수해야 합니다. 물론 신규기능이 고객에게 혜택을 제공하면 일시적인 불편은 의미가 있습니다. 그러나 고객은 별 불편 없이 특정 상품을 잘 사용하고 있는데 새로운 기능이 릴리즈 되면 다음의 불편을 겪습니다.
- 새로운 기능을 학습하여 기존 업무에 어떻게 적용할지 결정해야 합니다.
- 새로운 기능을 적용할 때 기존 기능에 미치는 부정적인 영향은 없을지 테스트해야 합니다.
- 변경된 기능을 설명하는 문서를 작성해야 하고, 사용자들을 교육해야 합니다.
- 새로운 기능에 대한 문의에 대응하기 위해 고객지원 센터의 상담사들을 교육시켜야 합니다.
지금까지는 기존에 출시된 상품의 기능을 개선하는 속도에 대한 이야기를 했습니다. 그러나 고객이 처음 접하는 상품(제품과 서비스)은 무조건 빠른 것보다 릴리즈의 타이밍(적기)이 중요합니다. 고객이 해당 상품을 받아들일 수 있는 준비가 되지 않는 상태에서는 빠른 릴리즈가 실패로 이어질 수 있습니다. 아이폰의 최초 릴리즈는 2007년 1월이었습니다. 만일 아이폰을 2000년 1월에 릴리즈했어도 성공했을까요? 사용자의 수용능력도 부족하고 사회의 네트워크 인프라가 부실하여 실패했을 가능성이 높습니다.
4. 운영업무에서는 지속가능한 스피드가 중요합니다.
소프트웨어 상품은 최초 출시이후는 개발과 운영을 통합하여 운영합니다. 이를 DevOps라고 합니다. DevOps 모델에서는 개발팀과 운영팀을 구분하지 않고 개발, 테스트, 배포, 운영을 동일한 팀에서 담당합니다. DevOps는 자동화를 기반으로 ‘지속적인 통합’과 ‘지속적인 배포’를 추구합니다. 그러나 조직마다 지속가능한 속도가 있습니다. 100m를 달릴 때와 42km의 마라톤을 할 때의 속도는 달라야 합니다. 짧은 기간 동안은 늦은 야근을 할 수 있지만 오랫동안은 지속할 수는 없습니다. 2023년 3월 정부에서 발표한 주 69시간을 근로자들이 반발하는 것도 비슷한 맥락입니다. 지속가능한 속도를 유지해야 앞서 설명한 빠른 속도의 부작용을 줄일 수 있습니다.
애자일의 12가지 원칙 중에 업무리듬과 관련된 다음의 원칙이 있습니다.
‘애자일 방법론은 지속할 수 있는 개발을 장려한다. 후원자, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.’
지속할 수 있는 개발은 이해관계자와 프로젝트 팀원이 합의 가능한 속도를 찾을 때 가능합니다. 너무 빠른 속도는 프로젝트 팀을 힘들게 하고, 너무 느린 속도는 이해관계자들이 허용하지 않습니다. 일단 그 속도를 찾아 쌍방이 합의한다면 다음은 그 속도를 유지하면 됩니다. 속도를 유지하기 가장 좋은 방법은 속도를 유지할 수 있는 리듬을 반복하는 것입니다. 예를 들어, 매월 마지막 주에 다음 달에 릴리스할 기능을 정의하고, 매월 첫 주에 그 달에 출시할 기능에 대한 개발계획을 수립하고, 매주 금요일 오후에 진행 현황을 리뷰하고, 매월 마지막 주에 그 달에 완료한 기능을 리뷰하는 식입니다.
속도를 유지할 수 있는 리듬은 업무의 루틴입니다. 루틴은 ‘반복적으로 수행하는 활동 또는 습관’을 의미합니다. 개인들이 회사에 출근하여 가장 먼저 하는 일이 루틴의 대표적인 예입니다. 운영업무를 수행하는 조직에 루틴이 많아지면 지속가능한 속도를 유지하는데 도움이 됩니다. 조직에서 루틴업무가 정착되면 그 업무를 수행하는 당위성을 인정 받은 것입니다. 따라서 개인들은 루틴한 업무를 수행하는 시간들은 무엇을 할지 고민할 필요가 없습니다. 그만큼 개인의 업무계획수립에 투입되는 시간은 줄어듭니다.
예를 들어 00 팀장이 사업부장이 요청한 업무를 언제 보고할지 고민할 필요가 없습니다. 긴급하지 않는 대면 보고는 주 또는 월단위로 예정된 회의체에서 보고하면 되기 때문입니다. 그렇지 않다면 누군가는 바쁜 사업부장의 일정과 다른 임원들의 일정 중에서 빈 시간을 찾아서 일정예약을 해야 하는 수고를 해야 합니다. 회의에 배석하는 임원이 많아질 수록 일정조정은 더욱 힘들어집니다.
업무 루틴에 기반한 지속가능한 속도의 장점은 다음과 같습니다.
- 조직내부에 지속 가능하고 예측가능한 리듬을 만듭니다.
최초 출시를 위한 프로젝트가 모든 것을 쏟아붓는 단거리 경주라면, 출시 이후 운영은 상품을 단종하기 전까지 지속하는 마라톤에 비유할 수 있습니다. 마라톤의 페이스처럼 개발 팀이 소화 가능한 리듬을 만들지 못하면 릴리즈 주기를 유지할 수 없습니다. 리듬은 업무를 예측 가능하게 합니다. 예를 들어 매월 마지막 주 목요일에 개선된 상품기능을 릴리즈 한다고 가정합시다. 계획대로 수행하기 위해서는 전월 마지막 주에 다음 달 릴리즈 기능을 확정하고, 매월 초엔 릴리즈 계획을 수립하고, 매월 마지막 주 월요일에는 릴리즈 기능에 대한 쇼케이스를 하면 많은 작업들의 루틴을 정해야 합니다. 상품개발 팀은 에러를 고치고, 조직에서 요구하는 개발 외 업무도 수행하면서 소화 가능한 신규개발 업무의 규모를 나름대로 체득하게 됩니다.
- 상품기획, 영업, 마케팅 업무도 반복적인 리듬을 따릅니다.
매월 신규 기능을 릴리즈하려면 상품개발 팀 외 유관조직도 반복적인 리듬을 따라야 합니다. 상품관리자는 매월 정해진 시점까지 상품 요구사항의 우선순위를 결정해야 합니다. 우선순위가 결정되면 영업·마케팅 팀은 요청한 신규기능이 언제쯤 릴리즈될지 예측할 수 있으며, 금월에 릴리즈 할 기능이 최종 확정되는 시점이 언제인지 알 수 있습니다. 결과적으로 상품개발 외 업무도 정해진 리듬을 따르고 일정을 예측할 수 있습니다.
- 상품의 품질이 좋아집니다.
일정 주기로 릴리즈 하기 위해서는 소프트웨어 아키텍처도 변경에 유연해야 하고, 코드품질도 좋아야 합니다. 품질이 뒷받침되지 않으면 일정주기로 릴리즈 하는 것은 불가능합니다.
- 일정준수를 위한 버퍼 확보나 학생 신드롬을 최소화시킵니다.
1개월 동안 팀이 할 수 있는 업무 규모에 대해 암묵적인 동의가 이루어진 상태이기 때문에 버퍼를 확보할 필요가 없고, 확보도 어려워집니다. 또한 규칙적인 리듬에 따라 일을 하기 때문에 마감일에 임박해 일을 하는 학생 신드롬도 줄어듭니다.
- 릴리즈 주기가 짧으면 비효율적 요소를 제거할 수 있습니다.
릴리즈 주기가 짧아지면 각종 비효율(불필요 문서, 단계별 검토의 비효율 등) 요소를 제거할 수 있습니다. 짧은 릴리즈 주기를 유지할 수 있는 조직일수록 그만큼 상품개발의 비효율이 줄어든 조직입니다.
회사뿐만 아니라 사회에서도 바쁘지 않고 빠르지 않으면 안 된다는 강박관념이 사회전반에 깔려 있습니다. 그러나 빠른 속도에는 ‘명’과 ‘암’이 공존합니다. 빠른 속도의 단점보다 장점이 강조되는 것이 문제입니다. 그러나 어떤 경우라도 속도보다 방향이 중요합니다. 지금 내가 혼신의 힘으로 빨리 하고 있는 일이 올바른 일인지를 항상 확인해야 합니다.
지속가능하고 올바르고 빠른 속도는 많은 가치를 제공합니다.
지금까지 설명드린 내용을 요약하면 다음과 같습니다.
1. 프로젝트에서는 ‘많은 개발’보다 ‘많은 가치제공’에 집중해야 합니다.
비즈니스 가치가 높고, 빠른 출시가 필요하고, 개발기간이 짧을수록 가치를 제공하는 속도가 빨라집니다.
2. 가치를 판단하기 힘들 때는 학습의 속도가 중요합니다.
고객가치는 정확하게 배우고, 빨리 배우고, 싸게 배워야 합니다.
3. 잦은 릴리즈보다 적정한 주기로 릴리즈 하는 것이 좋습니다.
적정 릴리즈 횟수는 새로운 기능에 대한 고객과 기업의 수용능력에 따라 달라집니다.
4. 운영업무에서는 지속가능한 스피드가 중요합니다.
지속가능한 스피드를 유지하기 위해서는 조직이 반복가능한 리듬을 찾아야 합니다. 반복가능한 리듬은 업무의 예측가능성을 높이고 상품의 품질도 향상시킵니다.
https://brunch.co.kr/@kbhpmp/160
https://help.ducalis.io/knowledge-base/wsjf-guide-weighted-shortest-job-first-agile-framework/
https://www.hbrkorea.com/article/view/atype/ma/category_id/5_1/article_no/1174
