Last updated on 2월 8th, 2021 at 10:40 오후
구현이 끝난 소프트웨어를 시장에 내놓았는데 좋은 평가를 받기는커녕 각종 버그로 인한 불만을 접수하게 된다면 참 곤혹스러울 것이다. 하지만 그보다 더 비참한 일이 있다. 열심히 노력하여 만든 소프트웨어를 ‘아무도 사용하지 않는 것’이다.
정말 이런 일이 일어날까 싶지만, 생각보다 빈번히 일어난다. 굉장히 많은 소프트웨어들이 빛을 보지도 못하고 버려지는 것이 다반사다. 필자가 인상 깊게 읽었던 “인스파이어드(제이펍, 2009)”의 서문 중 일부를 읽어 보자.
“우리는 1년 넘게 이 일에 매달렸다. 그간 반납한 밤과 주말은 셀 수 없이 많았다. 프로젝트 진행 기간 동안 따낸 특허도 몇 건 되었다. 결국 회사에서 요구하는 엄격한 품질 기준을 만족하는 소프트웨어를 개발했다. 우리는 이 제품을 국제 기준으로 표준화했고, 몇 가지 언어도 지원하도록 했다. 영업 인력도 교육했다. 기자들을 불러놓고 기술 시연을 보여 뛰어나다는 리뷰도 받았다. 만반의 준비가 끝난 것이었다. 우리는 제품을 출시했고 출시 자축연도 벌였다. 그런데 한 가지 문제가 생겼다. 우리 제품을 구매한 사람이 하나도 없었다. 시장에서 우리 제품은 완벽한 실패작이었다. 물론 기술적으로는 깊은 인상을 남겼고, 댓글 또한 칭찬 일색이었다. 하지만 우리 제품은 사람들이 원하거나 필요한 것이 아니었다.”
굴지의 글로벌 회사에서 1년 넘게 고생해 만든 제품을 아무도 찾지 않았다는 것이다. 이런 현상은 생각보다 자주 일어나며, 심각한 낭비를 불러온다. 이런 일이 일어나는 이유는 무엇일까?
폭포수 vs 애자일
오래전부터 소프트웨어 개발 방식은 폭포수(Waterfall) 방법론을 따랐다. ‘요구 사항 기술’ – ‘설계’ – ‘개발’ – ’테스트’ – ‘유지 보수’를 순차적으로 수행하는 방식이다. 앞 단계가 수행이 되어야 다음 단계로 넘어갈 수 있으며, 다음 단계에서 앞 단계로 돌아올 수 없는 것을 폭포수에 비유한 것이다. 하지만 이렇게 업무를 진행하다 보면 사용자에게 딜리버리되는 시점이 너무 늦어지기 때문에 처음 의도했던 방향과 틀어질 가능성이 높고 추가되는 요구 사항의 반영도 힘들어질 수 있다. 프로젝트를 시작하기 전에 사용자가 느끼는 문제점과 해결책이 명확하게 정의되어 있지 않는 한, 폭포수 방법론으로는 사용자가 정말 원하는 소프트웨어를 개발하기가 어렵다. 아니, 불가능에 가깝다.
이를 개선하여 나온 개발 방식이 바로 애자일(Agile) 방법론이다. 폭포수 방법론처럼 먼 미래를 예측하며 개발 하는 것이 아니다, 일정한 주기를 가지고 끊임없이 동작하는 소프트웨어를 만들어내며 그때 그때 필요한 요구를 더하고 수정한다. 이를 통해 계획과 절차를 따르는데 필요한 시간과 비용이 전체적인 개발 흐름을 느리게 하는 문제점을 개선할 수 있으며, 빈번하게 바뀌는 요구 사항에 더 민첩하고 기민하게 대응할 수 있다. (애자일에 대하여 더 알고 싶다면, 필자가 작성한 글을 참고하기 바란다.)
이미지 출처 : http://blog.procademysoftware.com/agile-is-waterfall
만들기 – 측정 – 학습의 사이클을 강조하는 린 스타트업
‘린 스타트업’의 린은 일본의 자동차 회사 도요타에서 유래된 개념이다. 자동차의 재고 관리 공정의 낭비를 최소화하여 최적화된 프로세스로 제품을 적시에 납품하겠다는 것이 골자다. 이 개념을 2008년에 에릭 리스가 책 <린 스타트업(인사이트)>을 통해 ‘스타트업’에게 잘 들어맞는 방법론을 정의를 한 것이 바로 ‘린 스타트업’이다. 여기서 말하는 ‘스타트업’은 작은 벤처 회사를 의미하는 것이 아니라 ‘극심하게 불명확성이 높은 환경에서 새로운 제품 혹은 서비스를 개발하는 모든 조직’을 일컫는다.
이러한 ‘린 스타트업’에서 강조하는 3 가지의 꼭지가 바로 만들기(Build) – 측정(Measurement) – 학습(Learn)이다. 제품에 대한 아이디어를 구체화하여 프로토타입을 작성(만들기) 하고, 최대한 빨리 최소 요건의 제품(MVP, Minimum Viable Product)을 출시한 다음, 여러 가지 방식으로 시장의 반응을 살핀 후(측정), 측정된 데이터 기반으로 제품의 방향성을 지속할지 아니면 방향성을 변경하거나 포기할지(학습)를 계속 반복하는 것이 핵심이다.
그렇다면 이 사이클을 어떻게 소프트웨어 개발에 접목할 수 있을까?
이미지 출처: http://smartbooks1.tistory.com/233
소스 코드로 구현한 제품으로 사용자의 반응을 보는 것은 너무 늦다
만약, 여러분이 애자일의 스크럼을 도입하여 소프트웨어 개발을 하고 있다고 가정해보자. 프로젝트가 시작되면 처음 생각했던 기능들을 모은 제품 백로그를 준비한 다음, 스프린트(이터레이션)를 시작할 때마다 스프린트 백로그를 정의하여 개발을 하게 된다. 백로그에는 사용자 스토리가 작성이 되어 있다. 각 프로젝트마다 백로그의 작성 수준이 다르긴 하지만, 해당 사용자 스토리를 기반으로 화면을 디자인한다. 이렇게 디자인이 완료되면, 퍼블리싱 작업을 거쳐서 개발자에게 전달한다. 개발자는 화면 및 백단의 서버 로직을 개발한 다음에 스프린트 리뷰 시 사용자 혹은 이해관계 당사자들에게 시연을 하여 피드백을 받는다. 이렇게 받은 피드백에 의해서 해당 화면을 다시 수정하거나 완료하는 방식으로 개발을 하는 것이 일반적이다.
그런데 사용자에게 전혀 필요 없는 기능이라는 피드백을 받았다고 가정해보자. 아니면 사용자의 니즈에 의해 작성된 요구 사항을 화면 디자이너나 개발자가 잘못 이해했을 수도 있다. 이런 경우 사용자 스토리를 작성하였던 공수, 화면 디자인 및 퍼블리싱에 들어간 공수, 개발자들이 소스 코드를 작성한 공수가 모두 ‘낭비’가 되고 만다. 이 낭비를 초래한 원인은 무엇일까?
소스 코드로 구현이 완료된 제품으로 사용자의 피드백을 받았기 때문이다. 지난 글에서도 언급했지만 소스 코드를 작성하는 행위는 프로젝트 내에서 가장 비싼 활동이다. 이런 활동을 모두 수행한 다음에 화면의 검증을 하는 것은 너무 늦다. 소스 코드를 작성하기 전에 이 기능이 정말 필요한지 확인할 수 있는 방법은 없을까?
‘린 스타트업’의 첫 번째 꼭지는 아이디어를 구체화하여 최소한의 제품(프로토타입)을 작성하는 것이다. 여기서 말하는 ‘프로토타입’이 바로 ‘측정’의 대상이 되며 컨셉을 ‘검증’할 수 있는 도구가 된다. 이 프로토타입은 애자일에서는 ‘동작하는 소프트웨어’를 일컫지만, ‘린 스타트업’에서는 동작하지 않더라도 제품의 컨셉만 증명할 수 있으면 무엇이든 될 수 있다고 말한다. 종이 위에 그린 그림일 수도 있고, 프로토 타이핑 툴을 활용하여 만든 몇 개의 화면일 수도 있으며, 동영상이 될 수도 있는 것이다. 바로 이 프로토타입이 낭비를 줄이기 위한 열쇠가 된다.
검증을 마친 후에는 사용자 스토리를 구체화하자
샌프란시스코에 위치한 피보탈 랩스의 개발 프로세스를 보면 힌트를 얻을 수 있다. 소스 코드를 작성하기 이전에 화면 디자인으로 이루어진 고수준 프로토타입을 활용하여 제품 기능에 대한 검증을 먼저 한다. 충분히 해당 화면이 검증이 되었다고 판단이 서면, 사용자 스토리를 작성하여 제품 백로그를 정의한다. 그리고 현시점으로부터 3~4주 치의 백로그를 정의한다. 제품의 방향성은 언제든지 바뀔 수 있기 때문이다. 바뀔 가능성이 조금이라도 있다면 사용자 스토리조차도 상세하게 정의하지 않는다.
사용자 스토리는 어떤 개발자가 보더라도 궁금한 사항이 없을 정도로 구체적으로 정의한다. 제목을 기재한 뒤, 상세 사항에 이 스토리를 통해서 사용자가 얻을 수 있는 가치를 기재한다. 그런 다음 구현이 완료된 시점에 수행되는 인수 테스트 조건이 기술된다. Given – When – Then 형식으로 작성하며, 어떤 화면이 주어졌을 때 사용자가 어떤 이벤트를 발생시키느냐에 따라 어떤 결과가 나온다는 것을 보여주는 것이다. 이 조건은 개발자들이 TDD(테스트 주도 개발) 기반의 테스트 케이스 작성을 할 때 소스 코드에 그대로 포함된다. 그렇기 때문에 최초의 기획과 의도를 벗어나는 경우를 최소화할 수 있다. 개발자나 디자이너에게 전달하고자 하는 내용도 추가로 작성한다.
그리고 이미 화면 검증이 완료되었기 때문에, 구현이 완료된 모습과 똑같은 화면 디자인의 링크를 첨부한다. 화면 없이 사용자 스토리만으로 개발하다가 잘못된 방향으로 개발한 경험이 한 번이라도 있는 개발자라면 이 부분이 얼마나 도움이 되는지 알 것이다.
출처 : https://www.pivotaltracker.com/blog/principles-of-effective-story-writing-the-pivotal-labs-way/
개발 완료 유무는 사용자 스토리를 작성한 사람이 판단한다
이렇게 작성된 사용자 스토리는 백로그에 포함되며, 이터레이션 계획 수립 시 담당자가 정해진다. 그리고 개발이 완료되면, 사용자 스토리를 정의한 사람이 인수 테스트를 직접 수행한다. 이는 최초 의도대로 구현이 잘 되었는지 확인하기 위함이다. 여기에도 낭비를 최소화하기 위한 장치가 숨어 있다.
프로젝트를 들여다보면 비즈니스 요구 사항을 구체화하는 사람과 사용자 스토리를 작성하는 주체가 다른 경우가 많다. 스크럼의 제품 오너와 같은 비즈니스 측 인력에게 사용자 스토리를 상세하게 작성해보라고 하면 어려워하는 경우도 많다. 하지만, 요구 사항을 정의하는 사람이 실제 사용자가 소프트웨어를 사용할 때의 구체적인 상황을 정의하지 못하는 것도 이상하다. 같은 사람이 인수 테스트 조건을 작성하기 시작하면 사용자 스토리의 수준은 높아질 수 있다. 요구 사항에 대해서 더 깊이 고민할 수 있으며 개발자 입장에서도 재작업 없이 해당 백로그 구현을 마무리할 수 있게 된다. 게다가 그 인력이 인수 테스트를 직접 수행한다. 행여라도 개발자가 놓친 부분이 있거나 본인이 요구 사항을 명확하게 정의하지 못했더라도 인수 테스트 과정에서 대부분 도출해낼 수 있다. 커뮤니케이션 비용을 크게 줄일 수 있다.
테스트 주도 개발과 페어 프로그래밍
자, 그럼 수준 높고 상세한 사용자 스토리가 인수 테스트 조건과 함께 준비가 되었다. 개발자 입장에서 낭비를 최소화하기 위한 방법은 무엇이 있을까?
위에서도 언급했지만, 가장 중요한 것 중 하나는 테스트 케이스를 작성하는 것이다. 최소한 사용자 스토리에 기재되어 있는 인수 테스트 조건은 소스 코드로 작성이 되어 ‘스펙’이 되어야 한다. 이렇게 먼저 작성된 테스트 케이스를 기준으로 제품 코드를 작성한다. 이는 테스트 자동화를 통한 품질 향상에 도움을 주며, 소스 코드 간의 의존성을 제거하면서 설계적으로도 훌륭한 제품을 만드는데 기여한다.
또한, 다른 개발자와 짝을 지어 프로그래밍 하는 페어 프로그래밍도 좋은 방법이다. 한 대의 컴퓨터에 두 대의 모니터와 키보드가 있는 셈이다. 코드를 작성하고 있는 동료의 코드를 주시하면서 실시간으로 코드 리뷰를 수행하고, 막히는 곳이 나타나면 바로 도움을 줄 수도 있다. 파트너가 주니어라면 역량 향상을 빠르게 할 수도 있다. 중장기적으로 보았을 때 팀의 개발 생산성을 향상하는데 기여한다. 그리고 짝을 계속해서 바꾸는 방법도 고려해보자. 팀 내 개발자가 소스 코드를 모두 읽고 리뷰를 할 수 있는 기회를 제공하며 기술적으로나 비즈니스적으로 얻은 통찰들을 실시간으로 공유하는데 기여한다.
이러한 활동들로 개발자 역시 제품에 대한 이해 수준을 최대한 끌어올리고 제품이 잘못된 방향으로 구현되는 것을 미연에 방지할 수 있다.
마무리
테스트 주도 개발과 페어 프로그래밍, 이 두 가지는 애자일의 도구 중 하나인 XP(eXtreme Programming)에서 소개하고 있는 활동이다. 애자일과 린 스타트업은 서로 목적이 다른 도구이지만 함께 사용할 때 훨씬 강력해진다. ‘만들기’에 최적화되어 있는 애자일과 ‘측정’ 및 ‘학습’에 초점을 맞춘 ‘린 스타트업’이 서로의 부족한 점을 채워주기 때문이다. 이 멋진 조화가 낭비 없이 정해진 시간에 원하는 제품을 적시에 만들 수 있는 가장 인기 있는 도구인 셈이며, 이미 많은 곳에서 다양한 방식으로 이 도구들을 훌륭히 활용하고 있다.
이미지 출처 : https://svsg.co/lean-and-agile-partners-in-customer-delight
위에서 언급한 여러 활동들이 다소 이상적이기 때문에, 혹은 다른 사정 때문에 실천하기 어려울 수도 있다. 국내 유명 소프트웨어 회사들의 개발자들과 대화를 하다 보면, 자유롭고 수평적인 문화를 지향하고 있지만 팀 내 역할이 엄격하게 분리되어 하는 일이 고정되어 있고, 불분명한 요구 사항으로 인해 오프라인 미팅 없이는 개발을 순조롭게 진행하기 어렵고, 팀 자체도 지나치게 작게 세분화됨으로써 좁은 영역의 업무만을 제어할 수 있는 상황 때문에 생기는 제약사항이 무척 많다. 심지어는 변화에 따라 민감하게 반응해야 하는 작은 규모의 스타트업에서도 이런 현상을 찾아볼 수 있었다. 알게 모르게 자리 잡혀 있는 비효율로 인하여 서로 협업하기가 점점 어려워지고 있고 사기 또한 저하되는 현상이 쉽게 목격된다. 이런 문제를 해결하기 위한 발걸음이 변화의 시작이 될 수 있지 않을까.
필자는 업무상 다양한 회사에서 이런 방식으로 일하는 것을 직/간접적으로 보았다. 그중에는 글로벌 탑 소프트웨어 컨설팅 펌도 있었고, 유명한 소프트웨어 전문 업체도 있었으며, 심지어는 오랜 기간 자동차나 터빈과 같은 하드웨어만 만들어서 팔던 회사들도 있었다. 세상이 디지털 트랜스포메이션(Digital Transformation)이라는 이름 아래 전통적인 방식이 송두리째 흔들리고 있다. 앞으로 불확실성은 점점 심해질 것이고 듣도 보도 못한 소프트웨어들이 우리의 생활에 깊숙이 파고들고 있다. 그리고 우리는 이러한 변화에 민첩하고 유연하게 대응해야 한다. 지금 조직에서 체감하고 있는 pain point를 객관적인 시각으로 분석해보자. 그리고 그 부분을 해소할 수 있는 작은 활동이라도 실천해보자. 조금씩 점진적으로 우리만의 최적화된 프로세스를 찾아나가길 바란다. 그리고 성공/실패 사례를 적극적으로 공유하여 개발 커뮤니티가 함께 성장해나가는데 기여해주었으면 한다. 🙂
입문자부터 실무자까지, 패스트캠퍼스 프로그래밍 강의 자세히 보기 >>> [클릭]
