소프트웨어 개발할 때 낭비를 최소화하려면?
필요한 기능을 구현하기 전에 검증부터 해야 한다
Intro
구현이 끝난 소프트웨어를 시장에 내놓았을 때 개발자가 원하는 반응은 어떤 것일까? 아마도 많은 사용자가 편하고 문제없이 잘 사용하고 감탄까지 한다면 더할 나위 없이 좋을 것이다. 만약, 사용자들이 원하는 대로 동작하지 않는 버그들을 발견하여 불만을 접수하고 있다면 곤혹스러운 하루하루를 보낼 수도 있겠다. 하지만 그것 보다도 더 비참한 것은 열심히 노력하여 만든 소프트웨어를 “아무도 사용하지 않는 것”이다.
정말 이런 일이 벌어질까? 대답은 “그렇다”이다. 굉장히 많은 소프트웨어들이 빛을 보지도 못하고 버려지는 것이 이 현실이다. 필자가 인상 깊게 읽었던 “인스파이어드(제이펍, 2009)”의 저자가 쓴 서문의 경험담 일부 내용을 읽어 보자.
“우리는 1년 넘게 이 일에 매달렸다. 그간 반납한 밤과 주말은 셀 수 없이 많았다. 프로젝트 진행 기간 동안 따낸 특허도 몇 건 되었다. 결국 회사에서 요구하는 엄격한 품질 기준을 만족하는 소프트웨어를 개발했다. 우리는 이 제품을 국제 기준으로 표준화했고, 몇 가지 언어도 지원하도록 했다. 영업 인력도 교육했다. 기자들을 불러놓고 기술 시연을 보여 뛰어나다는 리뷰도 받았다. 만반의 준비가 끝난 것이었다. 우리는 제품을 출시했고 출시 자축연도 벌였다.
그런데 한 가지 문제가 생겼다. 우리 제품을 구매한 사람이 하나도 없었다.
시장에서 우리 제품은 완벽한 실패작이었다. 물론 기술적으로는 깊은 인상을 남겼고, 댓글 또한 칭찬 일색이었다. 하지만 우리 제품은 사람들이 원하거나 필요한 것이 아니었다.”
굴지의 글로벌 회사에서 1년 넘게 열심히 개발하여 만든 제품을 아무도 찾지 않았다는 것이었다. 실은 이런 현상은 주변에서 무척 자주 찾아볼 수 있다. 그리고 이는 심각한 낭비를 초래하게 된다. 도대체 무엇이 문제일까?
폭포수 vs 애자일
오래전부터 소프트웨어 개발 방식은 폭포수(Waterfall) 방법론을 따랐다. ‘요구사항 기술’ - ‘설계’ - ‘개발’ -’ 테스트’ - ‘유지보수’를 순차적으로 수행하는 방식이다. 앞 단계가 수행이 되어야 다음 단계로 넘어갈 수 있으며, 다음 단계에서 앞 단계로 다시 돌아올 수 없는 것을 마치 폭포수에 비유한 것이다. 하지만 이렇게 업무를 진행하다 보면 사용자에게 딜리버리하는 시점이 너무 늦어지기 때문에, 처음 의도했던 방향과 많이 틀어질 가능성이 높고, 추후 변경되는 요구사항에 대한 반영이 점점 힘들어질 수 있다. 프로젝트를 시작하기 전에 사용자의 문제점 및 해결책이 명확하게 정의되어 있고 프로젝트가 끝날 때까지 변경되지 않는 한, 폭포수 방법론으로는 사용자가 정말 원하는 소프트웨어를 개발하기가 어렵다. 아니, 거의 불가능에 가깝다.
이를 개선하여 나온 개발 방식이 바로 애자일(Agile) 방법론이다. 상세한 계획을 통해서 주도해 나갔던 과거의 폭포수 방법론과는 다르게 앞을 예측하며 개발을 하지 않고, 일정한 주기를 가지고 끊임없이 동작하는 소프트웨어를 만들어내며 그때그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 방식이라고 할 수 있다. 이를 통해 계획에 너무 의존하여 형식적인 절차를 따르는데 필요한 시간과 비용으로 인해 전체적인 개발의 흐름 자체를 느리게 하는 것을 개선하게 되었으며, 빈번하게 바뀌는 요구사항에 대하여 조금 더 민첩하고 기민하게 대응할 수 있게 되었다. (애자일에 대하여 더 알고 싶다면, 필자가 작성한 글을 참고하기 바란다.)
[출처 : http://blog.procademysoftware.com/agile-is-waterfall/]
하지만, 애자일에서도 여전히 개발하고 있는 소프트웨어가 정말 올바른 제품인 것인지, 고객에게 어떤 가치를 전달하고 있는지를 확인하기 위한 도구가 부족한 것이 현실이다. 이는 애자일의 태생에서 그 원인을 살펴볼 수 있다. 애자일은 MS 오피스와 같이 불특정 다수를 위해 만드는 패키지 소프트웨어를 개발하는 것보다는 특정 고객에게 특화되어 개발하는 커스텀 소프트웨어를 개발하기 위해 탄생하였다. 재미있게도 고객의 요청에 의해 시작된 프로젝트 이건만 고객은 그들의 요구사항을 잘 전달하지 못하는 일이 부기 지수였다. 게다가 프로젝트 막바지에 생각하지 못했던 추가 요구사항 역시 프로젝트를 지연시키는 주범이 되었다. 이를 해결하고자 당대의 유명한 소프트웨어 전문가들이 모여서 선언한 것이 바로 애자일 선언문인 것이다. 그렇다 보니, 사용자가 명확하게 정의되어 있지 않고 제품의 개발 방향성이 뚜렷하지 않은 소프트웨어를 개발하는 스타트업과 같은 조직에게는 애자일만으로는 만족하지 못하는 부분이 분명 존재한다. 필자도 아직 구체적으로 대상이 정해지지 않은 소프트웨어를 기획하는 일에 참여하다 보니 이 사실을 깨닫게 되었다.
이런 상황에서 주목을 받는 방법론이 있다. 바로 ‘린 스타트업’이다.
만들기 - 측정 - 학습의 사이클을 강조하는 린 스타트업
‘린 스타트업’의 린 개념은 일본의 자동차 회사인 도요타에서 유래된 개념이다. 자동차의 재고 관리 공정의 낭비를 최소화하여 최적화된 프로세스로 고객에게 제품을 적시에 납품하겠다는 것이 골자다. 이 개념을 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)이라는 활동 아래 오랫동안 일해온 전통적인 방식이 송두리째 흔들리고 있는 것이 현실이다. 아마 앞으로 불확실성은 점점 극심해질 것이고 듣도 보도 못한 소프트웨어들이 우리의 생활에 깊숙이 파고 들고 있다. 그리고 우리는 이러한 변화에 민첩하고 유연하게 대응해야 한다. 조금씩 점진적으로 여러분만의 최적화된 프로세스를 찾아나가길 소망한다. :)
* 위 글은 패스트캠퍼스와의 요청에 의해 작성한 글이며, 아래 블로그에 필자가 기재한 글을 퍼온 글입니다.
