짧은 주기의 (모바일) 프로젝트 진행하기

이글의 주제는 "3~4명의 팀원들이 2개월 정도만에 모바일(웹) 서비스 만들기"라고 요약할 수 있겠다.

소프트웨어 마에스트로 프로그램에 참여하는 학생들은 프로그램에 참여하는 순간 멘토와 함께 프로젝트를 진행하게 된다. 2010년부터 시작했으니 4년째 프로그램이 돌아가고 있는데, 매년 프로그램의 운영 방식이 달라지긴 했지만 그래도 만나는 팀원들(3~4명)과 함께 새로운 프로젝트를 진행하기란 여간 까다롭지가 않다. 특히나 짧은 순간에 진행됨에도 불구하고 평가에 있어서 철저한 만큼 멘토로써 내가 해줄 수 있는 가장 큰 선물은 맛있는 저녁이나 간식이 아닌 좋은 평가를 받을 수 있도록 결과물의 완성도를 높이는 일이다. 2달이라고 해봤자. 8주다. 일주일에 두번 만나면 16번의 만남만으로 모든 과정이 정리되어야 한다.

언젠가 한번은 정리해보고 다른 사람들의 의견을 들어보고 싶었던 건데, 혹시나 이 글을 보시고 이견이 있으시거나 나 같으면 이렇게 해볼텐데라고 생각하시는 분들은 가감없이 말씀해주시면 큰 도움이 되겠습니다.

무엇을 어떻게 할 것인가?

멘토와 멘티가 만나게 되는 최초의 접점은 바로 "프로젝트 기획서"다. 그것이 멘토가 제안했든, 아니면 멘티들이 제안했든 우리는 서로에 대해서 잘 알지 못한채로 "프로젝트"에 대해서만 서로의 공감대를 형성한다. 다소 짧은 시간이 주어지는 만큼 평소에 관심있었던 기술이나 서비스등에 호감을 표시하고 매칭이 된다.

1. ICE breaking

멘토링의 첫주는 무조건 ICE Breaking이다. 서로에 대해서 잘 알고 서로의 배경을 알아본다. 그리고 가급적 작은 부분이라도 서로의 공통 관심사를 이끌어내야 서로에 대해서 비로소 공감하고 호감을 갖는다. 그 다음으로는 각자가 원하는 목표에 대해서 알아간다. 나는 주로 이 시점에서 일종의 개인 신상정보 카드 같은걸 작성한다. 일종의 PM으로써 앞으로 어떤 꿈과 희망(비전)을 심어줄지, 어떤 부분들을 채워줄 수 있는지를 명확하게 기억하기 위해서다. 또 내가 받은 첫인상도 함께. 그리고 다른 팀원들과의 관계 형성시에 알아두어야 할 점들을 파악한다. 대부분의 경우 첫번째 모임이 있는 날에는 회식을 한다. 더 진솔한 얘기를 들을 수 있기 때문이다.

2. 기획서 작성

우리가 비록 "프로젝트 기획서"를 통해 매칭이 되었다고는 하지만, 이것은 한 개인의 일방적인 기획서일뿐 각자의 요구 사항을 전혀 반영하지 못하고 있기 때문에 반드시 새로운 기획서를 작성한다. 개인들의 기술셋과 도메인 지식(knowledge)을 총 동원하여 살을 붙이고 떼어낸다. 보통 기획서를 작성하는 데에는 2주 정도(전체 기간의 25%)를 할애하는데 핵심은 모든 팀원들이 문제와 해결책을 명확하게 이해하는 순간까지 기획서를 작성한다는 점이다. 누구라도 동의하지 않고 이해하지 못한다면 서로가 서로를 끊임없이 설득하는 과정을 거쳐 모두의 동의를 얻을 수 있도록 한다. 이는 마에스트로라는 프로그램이 특별해서 이기도 하지만(만드는 제품이 상업적으로 반드시 성공해야 하는 것은 아니므로), 한편으로는 참여하는 팀원들이 서비스나 기술의 소비자라고 했을 때 우리 멤버끼리 공감대를 갖지 못한다면 아마 외부의 고객도 마찬가지 일거라는 생각이 깔려있다. 기획서 작성은 우선 리서치(Research)부터 시작한다. 내가 아는 문제가 실제 문제가 아닐 수도 있고, 이미 누군가가 스마트하게 해결했을 수도 있고, 어쩌면 지금 당장 해결하기 어려울 수도 있기 때문이다. 우리는 무턱대고 도전하는 것만이 아닌 그것이 무엇이든지간에 "잘" 해결하는 방법을 배워야 하기 때문에, 간혹 문제가 너무 당연해보인다고 하더라도 반드시 리서치를 하도록 요구한다. 리서치 방법은 관련 서비스를 검색하는 것부터 시작하는데, 발견되어지는 정보는 기사나 글, 유사한 서비스의 피드백등이 있다. 모바일 서비스의 경우 유사한 서비스를 분석하는 것이 정말 중요하다고 생각한다. 한편 관련자료를 제대로 검색하기 위해서는 키워드를 잘 선정해야 한다. 이는 아직은 부족하지만 우리의 서비스를 좀더 단순하게 그리고 본질적으로 이해하는 첫번째 과정이라고 생각한다. 리서치 관련해서 현재 진행하고 있는 팀에서는 다음과 같은 내용들을 조사했다. 

 [ 서비스 관련 ]

  1) 구글 플레이에서 관련 서비스들을 적어도 10개 검색한다.

  2) 서비스를 설치하고 핵심 기능들을 정리한다.

  3) 다운로드 수와 평가 및 긍정적인 피드백과 부정적인 피드백을 조사한다.

  4) 상위권에 해당하는 서비스의 경우 구글에서 관련된 정보(기사)를 조사한다.

 [ 도메인 관련 ]

  1) 해결하고자하는 문제의 도메인과 관련 키워드들을 구글에서 검색한다.

  2) 솔루션이 나와있는 경우 우리가 생각하는 해결책과 비교해본다.

  3) 도메인 전문가를 찾아서 인터뷰를 한다.

이것말고도 해야 할 일들은 굉장히 많은데, 여기서 아주 요상한 의문이 생긴다. "도대체 언제까지 얼마나 리서치를 하란 말이요? 우린 언제 설계하고 구현하냔 말이요?" 이런 질문에 대한 답은 이렇다. 우리 모두가 문제를 충분히 공감할 때까지, 그리고 그렇게 해서 나온 서비스를 한 문장으로 요약할 수 있을 때까지. 그럼 이렇게 물어본다. "만약 모두가 공감하지 못하면 끝까지 우린 다음 작업을 하지 못하는 건가요?" 맞는 말씀. 아니 문제가 뭔지도 발견하지도 못했는데 도대체 무슨 작업을 시작하는 걸까? 머리속에 그냥 대충 그려본걸 가지고 개발을 한다는건 애초에 말이 안된다. 기획이 되지도 않았다면 시나리오도 생각해볼 수 없고, 화면 설계도 잡을 수 없을 뿐만 아니라 기능 정의도 불가능하므로 결국에는 아무것도 없는 상태(VOID)를 무작정 프로그래밍 언어로 때려박는 상태일 뿐이다. 이를 두고 "우선 만들어보고 피드백을 받아보면 되잖아요."라고 말한다면 그냥 도박을 하세요라고 말하고 싶다. 도박도 생각해보면 이길 확률은 어느정도 있다. 그것이 1%든 0.1%든지간에. 우리가 자원을 투입할 때에는 가급적 성공 가능성을 높이기 위해서다. 설계에 공을 들이는것도, 개발을 잘하는것도, 마케팅을 열심히 하는 것도 성공이 100%라고 했을 때 십시일반 몇 %라도 성공 확률을 높이기 위한 과정이라는 것을 기억해둘 필요가 있다. 기획을 할 때 나는 가급적 기술적인 부분에 있어서도 검증하기를 요구한다. 이때 핵심적으로 필요한 기술들에 대해서는 간단하게 프로토타입을 작성하도록 요구한다. 그래야 다음 과정을 진행할 때 모두가 근본적인 부분에서 모든걸 뒤집는 결과에 대해서 불안해하지 않아도 되기 때문이다. 결과적으로 팀원들 모두가 문제에 공감하고 확신을 가졌다면 이제 다음 과정으로 넘어가도 좋다.

3. UX/UI 설계

이쯤되면 총 8주 중에서 3주가 지나간다. 그래도 걱정할 필요는 없다. 참여한 팀원들은 개발에 있어서는 선수니까. 기획을 통해 우리가 무엇을 해야할지, 최종 완성되는 형태는 무엇이 되어야할지를 모두가 이해하게 되었다면 이제 곧바로 만들어야 할 서비스의 모습을 그려본다. 모바일나 웹 서비스라면 화면을 스토리 보드를 그리면 되지만 엔진을 만든다거나 라이브러리를 구현하는등의 프로젝트는 다를 수 밖에 없다. 스토리 보드를 그리면 우리가 파악하고 있는 것들을 좀더 명확하고 분명하게 이해할 수 있게 되는데, 방법으로는 핵심 기능들을 가장 먼저 나열하고 필요하다고 생각되는 부가적인 기능들을 나중에 고려해본다. 그리고나서 외부의 도움을 받을 수 있다면 몇몇 지인들에게 핵심기능들에 대해 피드백을 받아본다. 이렇게 만들어보면 쓸모가 있을까요? 없을까요? 서비스의 근간을 흔드는 부정적인 질문이 아닌 경우에는 크게 두려워할 필요 없다. 왜냐하면 입장바꿔놓고 생각해봐도 그림이나 설명만 떡하니 가지고 오고선 좋아? 싫어?라고 물어보면 누가 거기다 대고 찬란한 미래를 말해줄 수 있을까? 우린 이미 기획단계에서 철저하게 준비했으니 가벼운 피드백이라고만 생각해두자. 일단은. 스토리 보드를 완성하고 나서 가상이긴 하지만 만들 서비스를 사용하는 모습을 연출해본다. 자연스러운지, 재밌는지, 필요한지의 느낌이 전해질 것이다. 이 때 디자이너의 도움이 좀 필요하다. 보기좋은 떡이 먹기도 좋다고, 스토리 보드에 올라가는 내용도 최종은 아니지만 우리의 컨셉이 반영된 작품(?)이 나왔을 때와 아닐때는 느껴지는 서비스의 품질이 다르기 때문이다. 이 정도의 작업을 거치면 아마도 1.5주 정도 지났을 것이다. 벌써 4.5주나 지났다.

4. 아키텍처 설계

스토리 보드가 완성되면 필요한 요소들이 모두 반영되었기 때문에 필요한 데이터(자료 구조)와 데이터의 흐름, 처리 방식에 대해서 쉽게 파악할 수 있다. 방법은 스토리 보드의 각 페이지마다 사용되는 데이터를 뽑아내고 해당 데이터를 얻기 위한 방식(서버에서 가져오는지 사용자로부터 얻는지, 아니면 가공하는지)을 적어둔다. 소프트웨어는 별거 없다. 입력->(자료)->처리->(자료)->출력이라는 단순한 구조만 기억하자. 스토리보드를 기준으로 한 페이지씩 만들다보면 데이터베이스에 그려넣은 Table들이 보이게 되고 그것들의 관계가 자연스럽게 정리된다. 억지로 생각할 필요도 없고, 서비스와 동떨어진 데이터 구조를 만들 이유도 없다. 그냥 만들어질 뿐이다. 필요한 만큼, 부족하지도 않고 넘치지도 않는다. 이 과정이 모두 끝나면 서비스의 세 축이 완성된다. 크게는 클라이언트-서버 구조가, 작게는 클라이언트-서버-데이터베이스 구조가 완성된다. 이쯤 되면 팀원들의 역할 분담이 가능하게 되는데 분량이 많다고 생각되거나 전문 분야가 있는 경우를 고려해서 팀원들이 분야를 전담하게 한다. 워낙 주기가 짧아서 전담분야를 잘 매칭시켜야만 프로젝트가 원활하게 돌아갈 수 있다. 현실적으로는 충분한 기술셋을 갖추지 못했을 가능성이 높으므로 반드시 멘토가 전체적인 틀에서 문제를 해결할 수 있어야 한다. 프로젝트 전체를 보면 멘토의 역할이 프로젝트를 리드하는 입장이지만 이 단계에서는 가급적 실무적으로 참여할 수 있어야 한다. 그것이 곧 역량있고 경험있는 멘토를 선정한 이유일 테니까. 역할을 나누기는 했지만 모두가 함께 배워나가야하는것이 목표이므로 매번 모임을 할 때마다 진척도를 발표하고 피드백을 받을 수 있도록 한다. 스토리보드에서 정의한 내용들을 기준으로 클라이언트와 서버는 각자의 아키텍처를 설계하고 최종적으로는 서로간의 Interface를 정의하는 단계까지 이르게 된다. 이 기간은 1주가 걸리므로 어느덧 5.5주가 지났다.

5. 구현

이제 막판에 달려야 한다. 남은 시간은 약 2주 가량이다. 이게 가능해?라고 묻는다면, 이렇게 대답하고 싶다. 우리가 구현하고자 하는 기능들이 명확하고 목표가 분명하지만 어쩔 수 없는 기간으로 인해 개발 기간이 짧다면 결국 최선의 방안은 남은 기간내에 구현할 수 있는 기능들을 정리하고 Milestone을 찍는 수밖에 없다고. 이것은 정해진 시간(2주)을 기준으로 무작정 개발하다가 여기까지 밖에 못했네요라는 것과는 다르다. 철저하게 계획적으로 움직일 필요가 있다. 어차피 소프트웨어라는게 "2013년 8월 23일 완성. 더 이상의 업데이트는 없음." 이런게 말이되냐고. 그런 일은 애시당초에 없기 때문에, Milestone을 잘 찍어가는 것도 배워둘 필요가 있다. 암튼 이런저런 이유에도 불구하고 가능하다면 일정내에 완성할 수 있는 Scope을 정하고 일을 진행하는 것이 좋다. 나는 짧은 기간이 주어졌으니 문제도 그 만큼 작아야해요라기보다는 리서치 과정중에서 나온 결과를 토대로 일정이나 Scope을 정해가면서 일을 진행하는 것도 나쁘지 않다고 생각하기 때문이다. 프로젝트 진행은 Scope-Time-Cost의 세 축을 예술적으로(?) 잘 조정하는것 아니겠는가? Time과 Cost가 상수라면 남은건 Scope이니 저거라도 변수로 만들어야지. 앞서 팀원들의 역할이 나뉘었기 때문에 매번 모임 때마다 진척도를 점검하고 문제가 있을 때에는 언제든지 연락해서 해결할 수 있도록 한다. 그것이 내부의 리소스이든, 아니면 외부든지 간에. 완전히 기술적으로 구현이 불가능한 문제가 아니라면 대부분의 경우 2주안에 기능을 구현하기에 충분했다. 2주라는 시간이 짤기는 하지만 그렇다고 해서 아무것도 못하는 정도는 아니다. 뭘해야하는지 명확하다면, 진격의 시간만이 남아있을 뿐이다. 

Project Management Triangle

구현을 할 때에는 가급적 테스트 코드를 작성할 수 있도록 한다. 특히 서버의 경우에는 문서를 작성하는 것보다 잘 짜여진 UnitTest가 두고두고 도움이 된다. 클라이언트가 서버 개발자를 귀찮게 하지 않아도 되기 때문이거니와 코드를 검증하는 차원에서도 중요하다. UnitTest가 잘 작성되어 있으면 Stress Test에도 활용할 수 있어서 매우 유용하다. 두달짜리 프로젝트에 왠 QA?라고 할수도 있겠지만, 그래도 프로젝트를 마무리하기 전에 팀원 모두가 서비스를 사용해보면서 QA 시간을 갖는다. 서로에게 피드백도 주고 제품에 대해서 둘러본다. 이쯤되면 서비스의 기능이 완성되었거나 아니면 버전 1.0에 해당하는 Milestone정도를 완성했다고 봐야하는데, 한 턴을 잘 마무리하는 단계도 중요해보인다. 이렇게 작업을 하면 7.5주가 된다. 이제 0.5주 남았다.

6. 자료 정리

지금까지의 과정을 잘 따라왔다면 별도의 자료를 정리할 이유는 거의 없다. 그냥 만들어진 산출물만 짜맞춰도 훌륭한 보고서(?)나 발표자료를 만들 수 있을테니까. 사람의 기억력이 좋지 않기 때문에 일의 순서대로 정리하면 나중에 봐도 큰 도움이 된다. 만약 이 단계에서 누군가에게 발표를 해야 한다면 오히려 구현에 관한 내용보다는 문제를 어떻게 정의했고 어떤 방식으로 해결하려고 했는지를 강조하는게 좋겠다.

짧은 글로 시작하려고 했는데, 쓰다보니 길어지고 더 자세하게 언급하고 싶지만 대략 이정도로 마무리하려고 한다. 이쯤에서 몇가지 질문을 정리해 보면,

Q) 프로젝트 관리 도구는 뭘 쓰나요?

 - 형상 관리는 반드시 해야 하는데, Git이나 SVN을 사용하게 된다. 요즘 친구들은 왠만하면 둘 중 하나는 이미 사용해본 경험이 있어서 선호하는 방식을 쓰고 이를 위해서 별도의 서버를 구축하지는 않는다. Bitbucket의 경우에는 private도 무료로 저장소를 제공하고 있다. 일정 관리는 엑셀이나 구글 드라이브 정도로만 정리한다. 팀원 모두가 익숙한 도구가 있다면 모르겠지만, 새로운 툴을 학습하고 "잘" 사용하기란 쉽지 않아서 추가적인 부담을 주지는 않는다.

Q) 꼭 이렇게 해야 하나요?

 - 아니 절대로 그렇지는 않다. 여전히 가능성의 문제이긴 하지만 그래도 전체적인 과정을 거치면서 '확신'을 가져가는 편이 좋지 않을까 싶어서다. 나는 성공을 하더라도 왜 성공했는지를 배우는게 중요하다고 생각한다(아직도 배우고 있는 중이라서 성공 못했다). 그래야만 성공 DNA가 생기니까. 하긴, 인생 한방도 중요하다. 가끔 그다지 큰 고민을 하지 않고 서비스를 만들었는데 성공했어요라고 하더라도 조금만 더 들여다보면 처음만 고민없이 시작했을 뿐이지 그것이 고객에 의해서 사용되는 순간부터는 끊임없이 개선하고 발전시켜나가는 고통의 순간을 겪게 된다. 운좋게 빵 터졌다는 뻥은 믿지 말자. 아니 안 믿는게 속편하다.