brunch

매거진 왜 우리 소프트웨어는 안나와요

라이킷 56 댓글 8

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Jinho Yoo Sep 10. 2016

소프트웨어 개발은 반복/반복/반복이다.

한번 만들고 손 터는 게 아닙니다.

소프트웨어 개발을 생각한다면 죽을 때까지 개발한다고 생각하세요.

이 글은 소프트웨어를 만들려고 하는 경영자, 정치인, 비영리 재단 등 소프트웨어 비 전문가들을 위해 쓰는 글입니다

저는 소프트웨어 개발 일정에 대해 논의를 할 때 꼭 이 질문을 합니다. “이 소프트웨어 개발을 어떤 식으로 하면 될까요?” 보통 돌아오는 답은 “요구사항-구현-테스트-출시' 한번 하면 되는 거 아니냐는 답이 대부분입니다. PM(Project manager) 대부분이 이런 생각을 가지고 있습니다.

저의 답은 “당신은 틀렸습니다"입니다. 이것은 착각입니다. 이런 방식을 이른바 ‘폭포수 모델'이란 말로 부릅니다. 실제 사람들 대부분이 이런 식으로 거의 모든 일을 하기 때문에 소프트웨어 개발도 이렇게 되리라 생각을 하는 겁니다. 그러나 이것은 아래의 이유들 때문에 틀렸습니다.

소프트웨어 개발은 일종의 ‘탐험'입니다. 이미 기존에 사용하던 언어와 프레임워크를 가지고 한다고 해도 진행하다 보면 무언가 새로운 문제들을 계속 찾아냅니다.

같은 이유로 개발이 진행되는 동안 ‘아, 우리가 만들던 게 이게 아니야'라면서 기획 자체가 바뀌기도 합니다. 최종 형태가 없습니다. 처음에는 카카오톡에 게임 플랫폼이 올라갈 줄 아무도 몰랐습니다.

개발 시작한 이후 한참 있다가 고객이 만든 소프트웨어를 보고 ‘이게 아닌데'라고 해버리면 난감하기 때문에 고객도 일반적으로 중간에 몇 차례의 데모를 요청합니다. 그렇게 되면 당연히 반복적으로 일을 하게 됩니다.

그러므로 소프트웨어 개발 일정은 반복적으로 잡을 수밖에 없다가 정답입니다.

아래 그림을 보세요. 매번 반복(iteration)마다 데모와 회고(Retrospective)를 거치면서 제품의 방향을 수정해갑니다. 이것을 여러 번 거치고 거치고 거치면서 첫 번째 제품 Release를 진행합니다. (사실 우리 인간이 하는 모든 사업은 이런 방식으로 하고 있습니다.)

여러번의 반복을 거쳐서 고객이 원하는 물건을 만드는게 상식.

그럼 각 반복 주기마다 뭘 해야 할까요? 바로 하나의 완결된 제품이 나와야 합니다. 단 1개나 2개의 기능만 가지고 있어도 됩니다. 하지만 그 자체로 완결된 제품이어야 합니다. 이러한 제품을 바로 MVP(Minimum Viable Product: 최소 기능 제품)이라고 합니다. 이것에 대해서 아래 그림을 보시면 바로 이해가 되실 것입니다.

바퀴 만들고 몸통만들고 아닙니다. 스케이트 보드/킥보드/자전거/오토바이/차 처럼 작지만 완결된 것을 만들어 가는 것입니다.

위의 그림과 같이 바퀴를 만들고 틀을 만들고 이를 각자 조립해서 차를 만드는 것이 아닙니다. 처음에는 스케이트 보드를 만듭니다. 그리고 피드백을 받아서 킥보드를 만듭니다. 그리고 자전거를 만들고 피드백을 받습니다. 이렇게 해서 자동차를 만들어 가는 겁니다. 부족하지만 완결된 제품을 반복적으로 계속 만들어 가는 겁니다. 그리고 제일 먼저 만들 것은 소프트웨어가 가장 크게 가정하는 부분에 대한 것입니다. (예컨대 예상하는 고객이 제일 좋아할 기능들 먼저)

이때 가장 중요한 것은 매 반복마다 데모를 한다든가 산출물을 같이 점검하는 피드백을 받아야 한다는 겁니다. 당신에게서, 당신의 고객에게서, 그리고 개발진에게서 말입니다. 그 피드백은 반드시 다음 개발의 방향을 바꿔야 하는 것이고요. 사실 이 반복 개발을 하면서 이른바 몇 군데는 대충 만드는 기술적인 빛(Technical dept)을 지고 있을 겁니다. 이렇게 대출해온 자산은 대출이자보다 더 큰 이윤을 내야 합니다. 그 방법이 바로 ‘피드백받기'입니다. 자꾸 사람들에게 보여줘서 최대한 많은 이야기들을 들어보고 다음 단계 할 일을 결정하는 것입니다.

그리고 이렇게 몇 차례에 걸쳐 만들어가다 보면 자연스럽게 개발 조직의 일하는 속도를 가늠하게 됩니다. 이것은 개발팀의 실력, 프로젝트의 성격마다 다르니까 각 프로젝트마다 다릅니다. 그리고 어떤 식으로 일을 나눠서 정리해야 하는지도 답이 나옵니다.

각 반복 주기는 얼마나 하는 것일까요? 이것은 프로젝트의 성격마다 다르긴 합니다. 제가 쓰는 직관적인 방법을 알려 드릴게요.

한 번의 주기는 보통 2~3주를 생각한다.

실험적인 프로젝트일수록 최소 1주일로도 반복 주기를 잡아볼 수 있다. 실험적일수록 빨리 확인하고 실패를 해야 하기 때문이다. 그 이후 큰 그림이 그려지면 2~3주의 정상적인 반복 주기로 잡을 수도 있다.

언제까지 반복을 계속해야 하는 건가요? 계속해야 합니다. 고객이 만족할 때까지. 한번 만들고 버릴 거면 그냥 안 해야 합니다. 당신이 “이번만 만들 거야"라고 말하는 순간 개발팀들은 아주 저질 소프트웨어를 만들어도 된다라고 생각하고 막 만들 것이기 때문입니다. 빨리만 끝내고 돈 받으면 되니까요. 하지만 계속 개발할 거라고 하고 이 일을 당신들이 계속해야 한다면 그들은 아주 유지 보수하기 좋게 구조를 잡고 또 문서화도 신경 쓰게 됩니다. 그래서 더 나은 제품을 받아볼 수 있습니다.

그리고 아무에게나 맡겨도 다 잘해줄 거라 생각하지 마세요. 사람의 질에 따라 한 10000배쯤 차이 나는 게 소프트웨어 엔지니어입니다. 우리가 사무실 인테리어 공사를 맡겨도 회사마다 그 질이 꽤 차이가 나는데 싸다고 아무 데나 맡기지 않잖아요? 당연히 좋은 개발자/개발팀은 비쌉니다. 그러니 그 정도의 가격을 지불할 생각이 없으면 처음부터 하지 않는 게 맞는 투자입니다.

그래서 계속 같이 갈 수 있는 개발자/개발팀을 구해야 합니다. 지속적으로 반복적으로 소프트웨어를 만들어갈 수 있는 사람들을 말이죠. 당연히 이 사람들을 ‘정규직'으로 고용할 수 있어야 합니다. 처음 프로젝트를 시작하는데 비정규직으로 몇 시간씩만 일해서는 견적이 안 나옵니다. 그리고 만약 당신이 조바심으로 ‘갑질'한번 하면 실패율이 약 10%씩 올라갈 겁니다. 이전에 평균적인 소프트웨어 프로젝트의 성공률이 얼마인지 기억하세요.

이 이야기는 현재 개발팀이 회사에 있다면 하나의 제품에 집중할 수 있게 해줘야 한다는 이야기도 됩니다. 사람은 한 번에 하나 이상 할 수 없습니다. 그런데 자주 관리자들은 이런 소리를 합니다. “60%는 이 일, 40%는 저 일 할 수 있지?” 그렇게 할 수 있는 일은 미싱 작업 같은 것 밖에 없습니다. 청바지 라인에서 2시간 일하다가 티셔츠 라인에서 3시간 일하면 되거든요. (참고로 요즘 공장에서도 이렇게 일 안 하거든요.) 그런데 지식 노동인 소프트웨어 개발은 모두를 쏟아서 집중해서 일해야 나오는 일입니다. 의사들에게 "오늘 일과의 30%는 안과, 40%는 내과, 나머지 30%는 내분비외과를 보세요"라고 하지 않습니다. 개발자들도 의사들 못지않은 지식 전문가들입니다. 아, 이걸 인정 안 하시려면 직접 하세요.