스마트링크의 스마트한 프로젝트 진행 방식

스마트링크에서 다양한 분야의 클라이언트로부터 다양한 주제의 웹/모바일앱 서비스를 의뢰받아 기획, 디자인, 개발을 진행하면서 가급적 더 효율적으로, 같은 기간 같은 비용 내에서 더 좋은 결과를 만들기 위해 나름 많은 고민과 시행착오를 경험 했었던 것 같다. 

이런 고민과 시행착오는 대부분 스마트링크 내부 기술 스택의 효율성 재고 뿐만 아니라 기획, 디자인, 검수 단계를 포함하는 전반적인 프로세스 개선 그리고 대내외 커뮤니케이션 노하우로 귀결 되었고, 이런 노력의 결과들로 인해 프로젝트 완료 후 많은 고객들로 부터 좋은 평가를 받을 수 있었다. 

[출처: 위시켓]

프로젝트를 진행함에 있어 가장 조심스럽고도 중요하다고 판단되는 부분은 역시나 커뮤니케이션! 특히, 스마트링크가 그동안 많은 프로젝트를 진행하면서 쌓아온 노하우를 가지고 처음으로 웹/모바일 프로젝트를 시작하는 초보 고객들(스타트업 또는 초기 창업자)과 프로젝트를 진행해야 할 때 가장 고민스럽고 가장 조심스럽다. 사실 답답해 미치겄다! 

웹이나 모바일 앱 개발 프로젝트의 라이프사이클을 이해하거나 기획, 디자인, 개발, 검수 단계에 대한 경험이 있는 고객과 프로젝트를 진행하는 경우 오히려 스마트링크의 비교우위를 인정 받기가 쉽고 (타업체에서 프로젝트를 진행하다 호되게 당하고 오신 분들은 특히 더!) 실제 그런 사례들이 많았다. 문제는 이제 막 부푼 꿈을 안고 사업을 시작하는 스타트업의 대표나 아직 법인 설립도 하지 않은 대한민국의 수 많은 초기 창업자들이 스마트링크의 주요 고객층이라는 것! 

물론, 여기에는 Non-IT 분야에서 사업적 성공을 거두고 이제 막 IT 분야로 뛰어든 연쇄 창업자도 포함된다. 특히 이 부류의 고객들이 가장 커뮤니케이션이 힘들긴하다.

앞으로 스마트링크의 비전이 바뀌지 않는 한 스마트링크의 주요 고객 층은 쉽게 바뀔리 만무하고, 이런 스마트링크와 스마트링크의 미래 고객과의 간극을 조금이나마 좁히기위해 스마트링크의 프로젝트 진행 방식과 왜 그런 방식이 도입 되었는지에 대해 이글을 통해 가급적 쉽게 그리고 충분히 설명 하고자 한다. 물론 프로젝트 특성이나 환경에 따라 진행 방식이 조금씩 달라지는 경우가 있으나 큰틀에서는 대동소이 하다고 할 수 있다. 

린 스타트업과 MVP

프로젝트 진행 방식에 대한 이야기에 앞서, 린 스타트업, 린 방법론에 대해서 먼저 이야기를 하고자 한다. 창업자가 되기 위한, 최소한 IT 기술기반의 새로운 서비스를 시장에 내놓고 사용자의 유입으로 무언가를 해보려고 하는 대부분의 서비스 창업자라면 무엇보다 꼭 필수적으로 알아야 하는 개념이다. 

그렇다고 아래 Lean 관련 서적 2권을 빠른 시일내에 꼭 정독 하라고 말하는 것은...음...맞다! 

사업하시는 분들이라면 공감하시겠지만 종종 답답한 마음에 용하다는 무당을 찾아가 사업의 미래를 점치고 싶은 욕구가 굴뚝 같은때가 있다. 그럴때 그 복채를 아껴 이 책 두권을 꼭 사길 추천 드린다. 사업의 실패 확률을 줄이고 성공 확률을 높일 수 있는 비법이 소개되어 있으니, 책 2권 정도를 구입해서 정독하는 수고 정도는 아끼지 말아야 할 것이다. 

실리콘밸리에서 용하다고 소문난 스타트업 토종비결이니 꼭 보셔야할 비서이다. 스타트업 모임이나 meet-up에서 피봇(Pivot)이나 MVP같은 Lean관련 용어들을 입에 담는 분들은 많이 보았으나 막상 프로젝트에서 필요한 기본 Lean 소양을 제대로 갖춘 창업자 분들을 보기 힘든 것이 안타까운 현실이다.

              

왜 갑지기 린스타트업이냐? 사실 MVP에 대한 이야기를 하고 싶어서이다. 여기서 말하는 MVP는 흔히 스포츠 경기에서 선정하는 MVP(Most Valuable Player)가 아니라 스타트업이 어떤 제품이나 서비스를 시장에 런칭함에 있어 반드시 측정/판단해야만 하는 핵심가정(Hypothesys)을 시험해 볼 수 있는 최소존속제품(Minimum Viable Product - 최소기능제품으로도 번역되는 경우가 있다.)을 의미한다. 

초기 창업자분들이 생각보다 흔하게 저지르는 실수가 몇가지 있는데, MVP에 대한 개념 부족에 기인하는 경우가 많다. 스마트링크에서 프로젝트를 진행하면서 경험한 초기 창업자들의 흔하지만 치명적인 실수 몇가지를 먼저 소개한다.

흔하지만 치명적인 실수 1 - 다재다능

어차피 외주 개발이니 나중에 혹시 쓸지도 모르는 기능들을 우겨 넣는다! 이러 접근 방법으로는 시장에서 승부를 걸수 있는 제품이나 서비스가 나오기 힘들다. 현재 유명한 메이저 플레이어들의 초창기 서비스 모습을 생각해 보면 금방 이해가 될 것이다. 예를들어, 카카오톡의 경우 처음엔 단순한 인스턴트 메세징 앱이었다. 전혀 버티컬 플랫폼을 꿈꾸지도 않았을 뿐더러, 지금 줄줄이 붙어 있는 카카오스토리, 카카오드라이버, 카카오택시, 등등 많은 후속 기능이나 제품들이 처음엔 당연히 존재하지 않았다. 그저 기존 유료 서비스인 SMS를 대체하고자 하는 인스턴트 메세징 앱이었을 뿐이다. 

카카오톡의 초기 핵심가정은 아마도 "무료이며, 연락처의 친구를 자동으로 인식할 수 있는 메세징 앱이 있다면, 사용자들은 기존 SMS 문자 메세지 기능을 사용하지 않고 그 무료 앱을 사용할 것이다." 였을 것이다. 그리고 카카오톡은 이 하나의 단순한 핵심가정을 시장에서 시험하고 증명하기 위해 엄청난 노력을 했다.

그렇다. 실제로는 하나의 핵심 기능을 엣지있게 잘 기획하고 개발해서 사용자에게 전달하는 것도 굉장히 어려우며, 사실상 제대로된 마케팅적 접근 없이는 사용자에게 도달하는것 자체도 모든 리소스가 제한된 스타트업으로서는 매우 힘들다. 시장에 이제 진입하는 듣보잡 서비스나 제품은 무조건적으로! 절대적으로! 많은 기능을 가지고 있어서는 안된다. "이런 저런 기능들이 많으니 사용자가 적어도 하나 정도는 써주겠지?"라고 생각하는 순간 그냥 망한 서비스나 마찬가지이다. Fat 하면 안된다! Lean 해야한다! 

흔하지만 치명적인 실수 2 - 장인정신

앞서 소개된 "Running Lean" 서적의 부제를 보자. Lean 개념을 한마디로 잘 설명한 문장이다.

Iterate from Plan A to a Plan That Works 

초기 제품이나 서비스 아이디어를 Plan A라고 보았을때, 스타트업 대표로서 꼭 주지해야 하는 사실은 시장에서 검증이나 피드백을 받지 않은 창업자의 머리속에서 이제 막 쏟아져 나온 아이디어(Plan A)를 계속해서 개인적인 상상력과 추측 그리고 장인정신으로 깍고 또 깍아서 예술작품으로 승화 시키려고 하지 말고, Plan A, 즉, MVP가 완벽하지 않더라도 빨리 시장에 출시하여 실제 고객이나 사용자들로 부터 피드백을 받아 개선된 Plan B 또는 Plan C, 또는 Plan Z가 되는 한이 있더라도 시장에서 먹히는 Plan(a plan thant works)을 최대한 빨리 찾는것이 Lean 방법론의 핵심이라는 것.

대부분의 클라이언트는 프로젝트 계약전 일정이 급박하며 제일 중요하다고 설레발을 치다가, 막상 스마트링크에서 일정에 맞춰 결과물을 내놓으면, 갑자기 일정은 뒷전으로 미뤄지고, 디자인 검수 단계에서 그렇게 좋고 이쁘다고 칭찬했던 모든 컬러와 선, 버튼, 아이콘, 텍스트 크기 등등을 가다듬으며 며칠 아니 몇주를 소비하는 경우가 허다하다. 스마트링크에서 진짜 일정을 맞춰 드려서 많이 놀라신건지? 물론, 제품이나 서비스의 외형과 심미적인 부분도 중요하다. 그러나 이러한 클라이언트들의 수정 요청 사항 중 대부분은 서비스의 핵심과 무관하며, 굉장히 사소한 부분들이다. 실제 사용자는 폰트의 사이즈가 자신이 좋아하는 10px이 아니라 12px이라서 앱을 지우거나 또는 그반대로 하지 않는다. 

중요한 것은, 시장에서 이미 성공한 비즈니스 모델을 카피캣(copycat)한 서비스가 아닌 경우라면, 내가 제품이나 서비스를 통해 해결하고자 하는 문제(핵심가정)와 솔루션(MVP)이 시장에서 먹히는지와 시장 자체가 실제로 존재하는지를 검증하는 것이 더 중요하다. 자신만의 완벽한 Plan A가 아니라 시장에서 먹히는 Plan X를 찾는 것이다. 그것도 최대한 빨리...

흔하지만 치명적인 실수 3 - 변덕

Lean 방법론에서 시장의 피드백에 따라 제품이나 서비스를 변경(Pivot) 할지 또는 지속(Persevere) 할지를 결정하게 되는데, 이때 중요한 것은 결정과 판단의 근거이다. 반드시 시장의 피드백 즉, 사용자들의 제품 사용 행태 등을 Google Analytics와 같은 분석 도구로 측정하고 측정된 데이터를 지표화해서 이를 근거로 판단해야 한다. 대표의 사업적 변심이나 주위 사람들의 의견에 의해서 판단해서는 안된다. 많은 대표님들이 이제 막 태어난 새 생명이 세상에 나가 첫걸음을 떼기도 전에, 성형 수술을 준비하는 경우가 많다. 대부분 이런 경우는 MVP 선정이 제대로 되지 않아서이다. 

시장에서 검증하고 싶은 내 제품, 내 서비스의 핵심 가정이 명확 하다면, 이런 가정을 빨리 검증하고 싶은 마음에 시장에 어떻게든 빨리 출시를 하고 싶은게 정상이겠으나, MVP 선정이 제대로 되지 않아 제품의 핵심 가정과 그것을 시장에서 효과적으로 시험, 측정 해볼 장치가 제품에 제대로 녹아 있지 않은 경우 출시 시점이 되어서야 냉혹한 시장의 피드백에 대한 막연한 공포와 자기 검열 또는 "아~ 이 기능을 넣었어야 했는데"라는 근거 없는 후회로 인해 차일피일 출시를 미루는 경우가 생각 보다 많다. 

충격적인 사실은, 초기 창업자 프로젝트의 경우 제품 개발 완료 이후 평균적으로 10개중 반 이상의 프로젝트가 자체적으로 완벽하지 않다는 미명하에 시장 출시를 포기하거나 무기한 연기한다 라는 것이다. 

흔하지만 치명적인 실수를 피하는 방법

상기에 소개된 Eric Ries의 Lean Startup은 저자 본인의 연쇄 창업 경험과 실리콘밸리 초기 스타트업의 많은 사례 연구(Case Study)를 통해 Lean에 대한 개념과 필요성을 설파하고 있다. 창업자라면 누구나 이 책을 읽으며 무릎을 몇번 칠 정도로 공감하지 않을 수 없는 내용들로 가득하다. 

Ash Maurya의 Running Lean에서는 구체적으로 MVP를 어떻게 도출하는지에 대한 상세한 실전 방법들이 소개가 되어 있다. 제품이나 서비스에서 풀고자 하는 문제(Problem)와 그에 대한 제품(Solution)을 인터뷰를 통해 찾아가는 방법, 일반적으로 초기 창업 시 엄청난 공을 들여 작성하게 되는 수십에서 수백 페이지의, 아무도 보지 않을 사업계획서가 아니라 단 한 장의 Lean Canvas(Business Canvas가 Lean 방식으로 변형된 형태)를 그리고 이를 기반으로 MVP를 도출하는 상세한 과정에 대해 소개되어 있다. 

개인적으로는 꼭 두권을 꼭 다 읽어야 하는 이유이다. 아무리 개념적으로 좋은 방법론이라 할지라도 구체적으로 나의 주어진 상황에서 어떻게 실행 할지에 대한 감이 없다면 탁상공론에 불과하기 때문이다.

사업의 주체인 자신이 직접 도출한 MVP가 있어야만 사실, 스마트링크든, 다른 업체든, 외주 개발에 관한 이야기를 시작할 수 있고 본격적인 기획과 그 이후의 소프트웨어 개발 과정에 대한 이야기가 성립될 수 있다. 아무리 잘난 스마트링크일지라도 사업을 대신해줄 수는 없지 않은가? 가끔씩 사업에 도움이 되시라는 취지에서 린스타트업에 대한 소개를 드리면, 스마트링크와 같이 MVP를 찾아가고 싶어하는 고객분들이 종종 있다. 한마디로 불가능하다! 

참고로, MVP의 구현이 꼭 소프트웨어 개발을 통해서만 가능한 것이 아니다. Eric Ries의 Lean Startup에 소개된 수많은 사례들: Groupon, Zappos, Open Table 등 무수히 많은 성공 케이스에서 볼 수 있듯 번듯한 홈페이지 하나 없이도 충분히 사업적 아이디어에 대한 검증과 실행은 가능하다. 하나의 좋은 예로, Zappos는 온라인 신발 전문 쇼핑몰을 실제로 개발하기에 앞서, 초기 사업모델의 핵심가정("사람들은 온라인으로 신발을 살 것이다")을 검증하기 위해 단순 웹사이트만을 오픈한 후 타 오프라인 신발매장에서 촬영한 신발 사진을 올리고 실제 구매 요청이 들어오면 그 매장에서 신발을 구매하여 택배로 발송하였다. 국내에서는 카닥이 좋은 예이다.

협업도구들

프로젝트 킥오프 미팅 이후부터 고객의 머리 속에서 흘러 넘치는 아이디어를 하나의 웹 서비스나 모바일 앱으로 탄생시키기 위해서는 기획, 디자인, 개발, 검수 단계에서 만만치 않은 에너지와 상호 작용(커뮤니케이션)이 요구된다. 물론 필요에 따라서는 유선 전화, 이메일, 대면 미팅 들도 당연히 동반되나, 어떤 프로젝트도 피해갈 수 없는 꼭 공유되어야 되는 정보들과 프로젝트 진행중 발견되는 이슈들 그리고 스마트링크에서 기본적으로 채택하고 있는 애자일 스크럼(Scrum) 방식의 프로젝트 진행 현황을 제대로 파악 하기 위해서는 아래의 협업 도구들이 필수이다. 

가끔 이메일로이나 카톡(특히, 단톡) 사용을 선호하는 고객들이 있어, 이에 맞춰 프로젝트를 진행한 경우가 몇차례 있었으나 결국 소프트웨어 개발 프로젝트라는 것이 하루이틀 진행되는 것도 아닐 뿐더러, 고객 스스로도 정리되고 추적되어야 하는 현안이나 이슈들이 제대로 정리되지 않아 오히려 불편을 호소하며 끝내 항복(?)하는 사필귀정을 많이 목격하게 된다.

협업도구 1 - 트렐로 (Trello)

What is Trello?

Trello is a collaboration tool that organizes your projects into boards. In one glance, Trello tells you what's being worked on, who's working on what, and where something is in a process.

모든 강이 바다로 흘러 모이듯 스마트링크에서는 프로젝트 관련 모든 공유 정보나 대고객 커뮤니케이션을 트렐로를 통해 관리하고 있다. 심지어는 이메일 사용도 자연스럽게 구시대적인 커뮤니케이션 유물로 취급받고 있어 내외부 커뮤니케이션에서 이메일 의존도가 매우 낮다. 사실, 매우 낮은 정도가 아니라 개발, 디자인 팀은 업무중에 거의 이메일을 사용하지 않는다. 

스마트링크와 프로젝트를 진행하든 하지않든 IT 기반의 프로젝트를 진행하기 위해서는 꼭 사용해보시기를 적극 추천한다. 사실 트렐로 정도는 이미 알고 계시는 분들도 많다. 스마트링크에서는 아래와 같이 크게 6개의 리스트를 통해 프로젝트를 관리한다. 수십개의 프로젝트를 거치면서 나름 최적화된 것이니 프로젝트 진행 시 우선은 따라주시면 감사하겠다. 이 링크를 통해 무료 회원가입 및 사용이 가능하다.

1. Information

프로젝트 시 필수적인 아래 정보들이 주로 공유된다.

• 클라이언트의 초기 기획/정책 문서
• 서비스의 브랜드 정책 및 아이덴티티
• 클라이언트 및 스마트링크 참여 팀의 연락처
• 도메인 설정
• 레퍼런스 또는 벤치마크
• Apple/Android 앱스토어 배포용 계정
• Amazon Web Service 계정
• SMS, Email 등 프로젝트별 연동 외부 서비스 계정

2. Client Communication

클라이언트와의 대면 미팅 관련 미팅 노트 및 유선 통화 내용을 주로 정리한다.

3. Issues

프로젝트 진행 중 발견되는 이슈들을 공유한다.

4. Backlog

프로젝트 개발을 위해 스마트링크에서 진행해야 할 업무 목록. 기획, 디자인, 개발, 검수 업무들이 프로젝트 초기에 모두 나열된다. 

5. In Progress

진행 중인 작업들 목록.

6. Done

완료된 작업들 목록.

협업도구 2 - 지라 애자일 (Jira Agile)

Jira는 원래 프로젝트 이슈 트래킹 툴로 시작하였으나, 최근 애자일 스크럼 방식의 프로젝트 관리 기능이 지원 되고 있다. 스마트링크에서는 애자일 스크럼 방법론을 채택하여 모든 프로젝트를 진행하고 있기 때문에 Jira Agile을 적극 활용 중이다. 고객 내부에 기술 관련 책임 인력이 있는 경우 공유해서 프로젝트를 진행하기도 하나, 주로 비기술 기반 스타트업 고객의 경우 앞서 설명된 트렐로만으로도 충분하다. 

협업도구 3 - 깃허브 (Github)

소프트웨어 개발 과정에서 개발자간 협업과 형상 관리에 필수적인 협업 도구이다. 최종 결과물이 산출될때까지 소스코드를 잘 보관하고 최종적으로 고객에게 잘 전달하기 위한 저장소(Repository)라고 보시면 된다. 또한 고객과 스마트링크의 지적재산권에 해당하는 소스코드를 비공개(Private) 저장소에 보관함을 원칙으로 하고 소스코드에 대한 리뷰나 접근이 필요한 경우에 한해 해당 고객을 초대하기도 한다.

협업도구 4 - 구글 드라이브 (Google Drive)

사실 구글 드라이드만 단독으로 협업 도구로 사용하지 않는다. 주로 항목이 많은 기획/정책 문서 또는 검수단계에서 QA 시트등을 트렐로를 통해서 구글 드라이브의 링크를 공유하고 실제 내용은 구글 드라이브 문서를 참조하도록 진행한다. 

다양한 이슈들이 탭으로 분리되어있으나 기본적으로 하나의 문서로 집중한다.

협업도구 5 - 재플린 (Zeplin)

디자인 단계에서 산출되는 결과물을 고객과 공유할 때 사용하며, 내부 개발팀이 프론트엔드 개발시 참고하도록 공유한다. 기존에 디자이너가 디자인 작업과는 별도로 만들어서 공유하던 디자인 가이드를 생략할 수 있고 여러가지 측면에서 꼭 필요한 디자인 협업 도구이다. 스마트링크에서는 프로젝트 진행시 디자인 시안부터  이미지 파일을 압축해서 공유하지 않고 재플린 링크를 공유한다. 이것 또한 트렐로를 통해서...

협업도구 6 - 오븐 (Oven)

기획단계에서 일반적으로 많이 사용하는 파워포인트식의 장표를 만들지 않고, 실제 최종 결과에 근접한 목업(mock-up) 형태의 프로토타입을 만들어 클라이언트와 내부 팀과 공유한다. 전통적인 장표 형식 기획서의 다음과 같은 문제를 개선하기 위함이다.

• 기획자가 만든 이차원 평면위에 펼쳐진 와이어프레임이 하나의 웹 서비스나 모바일 앱으로 살아움직이기 시작할때 기획서를 만든 기획자와 실제 사용자가 느끼는 경험은 매우 다를 수 있다. 비록 목업이 디자인이 배제된 와이어프임으로 구성되었다 할지라도 서비스의 전체적인 랜딩이나 흐름 등을 경험함으로서 전통적인 기획서 보다는 좀더 실체에 가까운 UX를 미리 경험할 수 있다. 

• 기획서 작성 후 내부 팀회의나 클라이언트 리뷰에서 수정이나 개선 사항이 생겼을때 그리고 이런 수정 사항이 서비스의 전체 구조(Information Architecture)에 큰 영향을 주는 경우 전통적인 기획서 작업 방식의 경우 연관된 페이지들을 일일이 찾아다니며 수정을 해야하고 이런 수정이 몇번 반복되다 보면, 서로 참조하고 있거나 연관된 랜딩에서 누수가 생기기 마련이다. 기획 단계에서 발생하는 이런 오류들은 개발을 포함하는 기획 이후의 모든 단계에 치명적으로 작용한다. 농담 같겠지만, 가끔은 개발 마무리 단계에서 기획적인 누수가 발견되어 고생해서 개발한 소스코드를 갈아엎는 경우도 종종 발생한다.

           

프로젝트 1단계 - 기획 

스마트링크에서 책임지는 기획이란? 

위에서 설명하였듯, 기획 단계로 들어가기에 앞서 명확한 MVP가 존재해야 한다. 린 방식을 따르던, 개인적인 영감으로 MVP를 선정하건 MVP는 필수이다. 클라이언트 측에서 도출한 MVP를 사업적 기획의 결과물이라고 본다면, 스마트링크에서 진행하는 기획은 그 사업적 기획의 결과를 토대로 UX를 포함한 구체적인 서비스 또는 제품 기획을 진행한다. 

클라이언트 측에서 구체적인 서비스/제품 기획서까지 만들어서 프로젝트 의뢰를 하시는 경우도 있으나, 스마트링크에서는 이런 경우라 할지라도 기존 기획서를 처음부터 검증하거나 아예 새로 만드는 경우가 대부분이다. 물론 잘 만들어진 기획서가 종종 있기도 하나 대부분은 기본적인 MVP로서의 모델링이 제대로 되어 있지 않거나, 실제 사용할 사용자의 경험(UX)에 대한 배려가 부족하거나 아예 없는 경우가 대부분이다. 

아무리 사업 모델이나 시장성이 좋다할지라도 제품이나 서비스가 시장에서 인정받기 위해서는 그 제품이나 서비스를 최종적으로 사용할 사용자들의 경험(UX)이 결정적으로 중요하단 사실도 간과 해서는 안된다. 대부분의 사용자들은 (성별, 연령, 국가에 따라 다르긴 하나) 이미 다른 많은 서비스를 통해 익숙해져온 UX 경험을 가지고 있다.

아무리 독창적인 비즈니스 아이디어 일지라도 그것이 너무 독특한 또는 일반적이지 않은 UX 경험으로 사용자에게 전달이 된다면, 사용자 입장에서는 기존의 익숙함을 버리고 또 다른 학습과 인지적인 탐험을 강요 받게 되는 것이다. 대부분 이런 상황이 주어지면 사용자들은 학습과 탐험을 선택하기 보다는 회피를 선택한다. 즉, 해당 사이트를 다시 방문하지 않거나 모바일 앱을 삭제한다.

일반적으로 사용자는 (실제로 그렇지 않다하더라도) 무지하고, 게으르고, 냉정하다 라고 가정하는 것이 좋다. 내 가족이나 친구가 아닌 이상, 나의 복잡한 또는 일반적인 인식 경험을 벗어나는 제품/서비스를 끝까지 붙들고 이해하기 위해 연구해가며 사용하지 않는다.

프로젝트의 전체 진행 과정에서 가장 중요하고 클라이언트들과 가장 많은 커뮤니케이션이 필요하고, 스마트링크의 에너지를 가장 소모하는 단계가 바로 이런 기획 단계이며, 특히 이런 UX적 요소를 기획에 잘 반영하기 위해 클라이언트와 끊임없이 협의하고 타협해 가는 과정이 힘들지만 가장 중요하다. 

기획 소요 기간

다른 업체에 소프트웨어 개발을 의뢰하였다가 몹쓸 경험을 하고 난 뒤 스마크링크를 찾아오시는 클라이언트 분들이 종종 계신다. 이런 클라이언트 분들에게는 죄송하나 실패한 프로젝트 경험이 스마트링크와의 프로젝트 진행에서는 많은 도움이 되는 경우가 있다. 특히 기간 산정 관련해서는 말이다. 

스마트링크에서는 기본적으로 기획 기간을 한 달(4주)로 산정한다. 프로젝트 의뢰 당시 만들어진 기획서 있건 없건 말이다. 프로젝트를 진행하면서 최소 한달의 기획 기간이 보장되어야 전체 프로젝트가 어려움 없이 진행된다는 스마트링크 나름의 생활 통계적인 기간 산정이다. 

어떤 클라이언트의 경우 "무슨 기획 하는데 한달이나 걸리나요?"라고 물어보시는 경우가 종종 있는데, 사실 질문을 거꾸로 하신 경우이다. "제 고민을 대신해서 한달 동안이나 해주시나요?" 

실제로 프로젝트를 진행해보면, 그 길 다던 한달도, 스마트링크측에서 발견하거나 미비 하다고 판단되는 정책적인 결정을 요청하며 커뮤니케이션을 주고 받다보면, 오히려 클라이언트 측의 결정 장애나 딜레이로 인해 한달 이상이 걸리는 경우가 대부분이다.

최종 결과물

실무적으로 스마트링크의 기획 단계에서는 위의 협업도구에서 언급 하였던 오븐을 사용하여 빠른 프로토타이핑을 진행한다. 예외적인 경우가 아니라면, 전통적인 기획서를 지양하고 상호 효율을 추구하고 있다. 전통적인 기획서를 작성하는데 소모적으로 소요되는 시간을 클라이언트의 핵심 요구사항을 더 깊이 이해하고 UX 경험을 잘 기획하는데 사용하려는 의도이다.

프로젝트 2단계 - 디자인

백문이 불여일견

초기 디자인 미팅에서 클라이언트들에게 "어떤 디자인을 원하세요?"라고 물어보면 (사실 질문자체가 그런 답을 유도 하기도 하는것 같다.) 10명 중에 9명은 "심플하고 깔끔한 디자인이요!"이라고 답한다. 더 이상의 질문과 답변이 의미 없어지는 순간이다. 사실 디자인 단계에서 모든 클라이언트들이 원하는 그 심플하고 깔끔한 디자인을 만들기 위해 디자이너는 클라이언트와 많은 커뮤니케이션을 한다. 백마디 말보다 클라이언트가 원하는 디자인에 가장 가까운 디자인 레퍼런스를 찾는 것이 가장 효율적인 시작점이다.

디자인 리뷰의 중요성

디자인 미팅과 레퍼런스를 분석을 통해 도출된 디자인 시안에 대해 클라이언트의 컴펌을 득하고 나면 이후에는 각 화면별 세부 디자인 진행한다. 디자인이 완료되는 시기에 다시 클라이언트에게 리뷰를 요청한다. 스마트링크의 경험 상 이 순간이 향후 프로젝트의 운명을 결정 짓는 기획 단계 다음으로 중요한 순간인데, 클라이언트 분들에게 사전 공지를 많이 드리고는 있으나 그 중요성을 잘 인식하지 못하는 경우가 많다. 

기획단계에서 치열하게 쌓아 올린 서비스의 구조와 정책과 모든 디테일들이 실제로 사용자에게 어떤 모습으로 전달될지가 확정되는 아주 중요한 순간이다. 아마도 기획 단계에서 무채색의 선과 면으로만 만들어진 프로토타입을 경험하고 난 뒤라 그런지, 디자인이 예쁘게 적용된 결과물을 보는 순간 모든게 다 좋아 보일 수도 있음을 충분히 이해한다. 그러나 이후 개발까지 모두 완료된 정말 살아 움직이는 최종 결과물을 접할때 의외로 많은 클라이언트들이 그제서야 디자인에 대한 피드백을 하기 시작한다. 

문제는 디자인에 대한 수정이 사실상 디자인 자체의 수정만으로 끝나지 않는 경우가 많다는 것이다. 기획상의 정책 변경이 수반되거나, 개발 단의 각종 처리 방식이나 핵심 로직이 변경된다면 서로 난처해지기가 일수 이다. 그러므로, 디자인 단계가 완료되어 클라이언트가 디자인을 리뷰하는 시점에서 클라이언트 분들께 당부 드리고 싶은 것은, 디자인 검수의 중요성을 인지하고 최종적인 제품 UI의 마지막 버전을 리뷰한다라는 가정으로 임해주시기를 바란다. 디자인 단계 내에서 몇 차례의 수정은 당연히 필요하나, 개발이 완료되고 난 이후의 디자인 수정은 정말 남감하다. 의외로 기차 떠나고 난 다음 손 흔드시는 분들이 많다.

프로젝트 3단계 - 개발

스마트링크는 2001년 부터 C, C++, Object Pascal, PHP, Java, JSP/Servlet, Ruby on Rails, Python 등의 개발 언어와 다양한 플랫폼, 프레임워크, 라이브러리들 이용해 프로젝트를 수행해왔다. 스마트링크의 주요 고객층인 스타트업의 소프트웨어 개발에서 필요한 유연성과 time-to-market을 보장하기 위해 아래와 같은 원칙으로 구현 기술을 선택하고 있다. 

• Full-stack: Front-end에서부터 Back-end 까지 일관된 언어로만 개발을 진행
• Schemaless Database: 잦은 기획 변경 및 초기 아이디어의 런칭 전후 시장 학습을 빠르게 반영할 수 있는 Schemaless 데이터베이스 만을 사용
• State & Declarative: 모바일 네이티브 앱은 물론 웹 개발 시에도 전통적인 Stateless 방식이 아닌 State 방식과 선언적 패러다임의 프레임워크 및 방법론을 사용

소프트웨어 개발 분야는 기술 변화의 속도가 매우 빠르다. 또한 프로젝트의 진행에서 요구 사항에 따라 어떤 기술 스택을 사용하느냐에 따라 향후 프로젝트 진행 양상이 크게 영향을 받기 때문에, 소프트웨어 개발팀은 프로젝트 효율을 개선할 수 있는 새로운 기술이나 방법론에 대한 목마름이 항상 있어야 된다. 스마트링크의 개발팀은 이런 부분에 있어서는 기본적으로 오픈엔드(open-ended)이며 언제든 앞선 기술의 Early Adapter가 될 준비가 되어 있다. 

현재 스마트링크에서는 다음과 같은 기술 기반으로 프로젝트를 진행하고 있으며, 동시에 효율을 더 끌어올릴 수 있는 새로운 기술이나 방법론을 계속해서 찾고 있다.

• Front-end: Semantic UI, React, React Native
• Back-end: Meteor, Nodejs
• Testing: Mochajs, Jest
• DevOps: AWS, Jenkins, Docker, Phusion Passenger, Nginx
• DB: MongoDB

프로젝트 개발 진행시는 스크럼(Scrum) 방식을 도입하여 1주 단위의 스프린트를 진행하고 있다. 또한 협업도구에서 소개된 Jira라는 툴을 사용하여 프로젝트를 진행한다. 

프로젝트 4단계 - 검수

버그 없는 소프트웨어는 존재하지 않는다. 기획 단계에서 부터 꼼꼼히 누수가 발생하지 않도록 많은 노력을 기울이고는 있으나 소프트웨어 특성상 개발 완료 이후 검수 단계에서 이런 저런 버그가 발생하기 마련이다. 하자와 관련된 이슈에 대해서는 기본적으로 계약에 명시된 하자보수 기간 동안 스마트링크에서 책임을 진다. 단, 기능상의 개선과 개발 완료 이후 변경에 대해서는 유지보수로 분류한다. 

스마트링크 내부에서 자체적으로 기본적인 검수를 진행한 이후 클라이언트 검수가 진행되는데, 아래와 같이 QA 시트를 작성하여 내부 검수 단계에서 부터 발생한 버그들을 클라이언트와 모두 공유한다.

프로젝트 5단계 - 출시

DevOps

최근 클라우드 인프라 서비스가 보편환되고, 스타트업에서도 많이 활용하게 되면서 스마트링크에서는 아마존 웹 서비스(Amazon Web Service, AWS)를 기본 배포 인프라로 채택해서 쓰고 있다. 초기 운영 비용에 민감한 스타트업의 주머니 사정을 고려하여, 사용자가 많지 않은 초기 시험 운영단계에서는 무료로 사용할 수 있는 AWS의 프리티어(Free Tier)에 배포를 진행한다. 물론 이후 본격적인 운영단계로 접어들면, Elastic Load Balancer, Auto Scaling, MongoDB Replica Set등을 통해 Production 레벨로 설정을 변경하기도 한다.

최근 린 방법론이나 애자일 방법론 등에서 공통적으로 주장하는 "가볍고", "빠르고", "반복적인" 제품의 개발과 배포의 라이프사이클 주기가 중요하다라는 업계의 인식이 생겨나면서, 더 이상 개발과 운영을 별개의 독립적인 팀이나 프로세스로 구분하지 않고 개발과 운영을 합쳐 DevOps(Development + Operations) 라 부른다. 

스마트링크에서는 프로젝트 배포 단계에서, DevOps 개념을 도입하여 개발 완료 후 AWS와 같은 클라우드 인프라에 지속적인 통합과 배포가 가능하도록 Mocha나 Jest같은 테스팅 프레임워크와 Jenkins등의 CI (Continuous Integration), CD(Continuous Deployment)를 적용하고 있으며, 빠른 릴리즈를 보장하고 Time-To-Market을 줄일 수 있도록 노력하고 있다. 

운영 < 지표 측정

출시 시점 부터 클라이언트가 본격적으로 바빠지는 시간이다. 사업에 필요한 무기가 생겼으니, 이제 이 무기를 활용해서 사업을 성공 시켜야하는 본 게임이 시작되는 것이다. 운영 단계에서는 기술적인 지원과 기능적인 유지보수도 중요하지만 실제로 중요한 것은 제대로 된 지표 측정과 이에 대한 분석이다. 

앞선 린 스타트업 섹션에서 언급하였듯 잘 개발된 제품(MVP)을 시장에 내놓는 이유는 너무 명확하다. 시장의 반응을 측정해서 MVP를 변경(pivot) 할지 또는 지속(persevere) 할지의 여부를 결정하는 것이다. 초기 계획(plan A)이 시장에서 먹히는 제품이나 서비스(a plan that works)가 될때 까지! 물론, 단 한번의 Pivot도 없이 출시하자마자 곧 바로 하키스틱 성장곡선을 그릴 수도 있겠지만 이런 예는 극히 드물다. 지표 측정과 분석에 대해서는 Lean Startup과 Running Lean에서 구체적인 방법을 학습하시기를 추천 드린다.

출시 이후의 유지보수

최종적으로 프로젝트가 완료되어 운영이 시작되면 클라이언트의 또다른 걱정이 시작된다. 스마트링크 덕분에 개발은 잘 되었는데, 이제 유지보수는 어떻게 해야할까? 

이 질문은 받는다는 것은 스마트링크 입장에서는 행복한 경험의 순간이다. 대부분의 작은 영세 개발 외주 업체에서는 클라이언트와 협의된 일정이나 퀄리티 기대 수준을 만족하며 프로젝트를 성공적으로 아니 무사히(?) 마무리하는 경우가 생각보다 드물다. 프로젝트를 퀄리티 있게 잘 마무리 할수록 클라이언트는 이후 유지보수가 더 고민 된다. 내부 인력을 뽑을 것인가? 계속 외주로 진행할 것인가?

모든 리소스가 제한적인 스타트업의 경우 답은 명확하다. 당연하게도, 런칭 이후 지표 측정과 분석을 통해 사업의 성장 추이를 민첩하게 모니터링하면서 향후, 운영 및 유지보수 계획을 수립해야 한다. 비즈니스의 성장 추이와 발맞춰 내부 개발 인력을 구성하거나 기존 개발 업체를 통한 유지보수를 진행해야 한다. 

스마트링크에서는 앞서 "개발" 섹션에서 언급되었듯이, 프로젝트 개발시에 사용하는 기술 스택을 선택함에 있어 기술의 난이도보다는 개발의 효율성 및 결과물의 퍼포먼스를 위주로 판단하기 때문에, 자연스럽게 최신 기술 또는 난이도가 높은 기술 기반으로 프로젝트가 진행되는 경우가 많다. 클라이언트 측에서 내부 개발인력 구성시 이에 대한 고려가 필요하다.

맺음말

여러 클라이언트와 함께 다양한 제품과 서비스를 한 팀 처럼 개발하며 그 동안 스마트링크는 많은 성장을 해왔다. 그리고 또 앞으로도 계속해서 좋은 클라이언트와 좋은 프로젝트를 만나 성장하고 진화하기를 고대하고 있다. 

대부분의 클라이언트가 스마트링크 팀원들의 프로페셔널과 열정적인 노력에 항상 지지와 감사로 응원을 해 주었지만, 어떤 경우에는 급한 일정으로 인해 주말 밤낮을 가리지 않고 무리하게 프로젝트를 진행하여 결과물이 나왔으나, 클라이언트 측의 반복되는 흔하지만 치명적인 실수로 인해 귀한 노력의 산물이 빛을 보지 못하는 경우도 많았다. 

스마트링크의 미래 클라이언트에게 스마트링크의 스마트한 프로젝트 진행 방식을 미리 소개함으로써 상호 신뢰 기반의 효율적이고 효과적인 프로젝트를 진행할 수 있기를 희망하며 이 긴 글을 맺는다.