스타트업을 시작한지 6년이 넘었다. 그리고 클라이언트에게 서비스를 기획, 디자인, 개발하는 개발 서비스업을 한지도 3년이 넘었다. 그 동안 많은 사람들을 만나면서 느낀점들이다.

.

#1

개발사 또는 개발자는 당신의 프로젝트에 관심이 없다. 따라서 투자자에게 설명하듯 장황하게 설명할 필요 없다. 그리고 본인이 준비하는 사업이 얼마나 매력적인지, 왜 이 사업을 하려는지, 누가 이 사업을 도와주고 있는지는 궁금하지 않다. 만들려는 것이 무엇이고, 일정과 예산이 궁금할 뿐이다. 무엇을 언제까지 만들고 싶은지 명확히 정리하자.

사업의 파트너를 찾는 것과 개발사를 찾는 것은 분명 다르다. 개발사 입장에서 ‘파트너’라는 단어는 ‘싸게 해달라’는 의미밖에 안된다. ‘나중에 잘 해주겠다’는 얘기도 역효과다. 당신은 개발사와 처음 일해볼 가능성이 크지만 개발사는 수많은 사업가와 기업 대표, 직장인들을 상대해왔다.

.

#2

개발자 또는 개발사가 성의와 능력을 갖추고 있다고 가정했을 때, 가급적 하나의 프로젝트로 진행하기보다는 두세 번으로 나눠서 진행하는게 좋다. 핵심적인 사용자 플로우만 구현해서 버그 수정까지 완료된 ‘클린 버전’을 하나 만들고, 그 동안 정리해놓은 주요 기능들을 하나씩 구현해서 업데이트하는게 좋다. 프로젝트 설계 시점에 가장 중요한 의사결정이라고 생각한다.

중요한 주제인만큼 좀 더 얘기해보자.

보통 모바일 서비스 하나를 기획하는데 1달 정도의 시간이 걸린다. 보통 1달의 시간이면, 기본적인 기능들을 배치하고, 중요한 UX를 결정할 수 있다. 이 정도가 완료되면 디자인이 시작된다. (상황에 따라서는 기능 명세서가 완료되어, 개발이 디자인과 함께 시작될 수도 있다.) 경험적으로는 1달 분량이 넘어가는 기획은 프로젝트에 참여하는 전체 인원이 한번에 이해하기 어렵다. 그만큼 시행착오가 생기고, 프로젝트 종료 시점에 테스트해야할 분량이 많아진다. 당연히 개발자가 사소하게 잘못 이해했던 부분이 크게 돌아오기도 한다. 내가 생각하는 적정 분량은 기획 1달, 디자인 1달, 개발 3개월이다. 기획은 독립적으로 이루어지고, 디자인과 개발은 동시에 진행될 수 있다. 이 정도면 클라이언트가 쉽게 얘기하는 ‘A 서비스를 기본으로 B, C, D 와 같은 차별화 포인트가 핵심인 서비스’를 만든다고 할 때, 기본이 되는 A 정도를 만들 수 있다. 어쩌면 A의 기본 뼈대만 구현할 수 있는 시간이기도 하다.

어쨌든 기본 뼈대가 완성되면 몇 가지 긍정적인 결과가 생겨난다.

• A를 완성하는 과정에서 개발팀이 비로소 서비스의 구조를 이해한다.
• 따라서 개발팀은 B, C, D를 꽤나 효율적으로 개발할 수 있다.
• 운이 좋다면 개발팀은 서비스에 흥미를 갖을 수 있다.
• 프로젝트 전체가 실패할 가능성이 줄었기 때문에 어느정도의 심리적 안정감이 생긴다.
• 클라이언트가 영업, 마케팅, 투자 등으로 ‘드디어’ 바빠지기 시작한다.

.

이와 반대로, 원하는 기능을 한번에 구현하고자 한다면 다음의 조건이 필수적이다.

• 프로젝트 전체를 디테일하게 이해하고, 의사결정할 수 있는 풀타임 PM이 있어야 한다.
• PM은 가급적 클라이언트에 소속되는 것이 좋고, 온전히 한 프로젝트만을 담당해야 한다.
• PM을 지원할 수 있는 QA 담당자가 필요하다. 풀타임 참여가 아니어도 좋다.

.

만약 역량있는 풀타임 PM과 그를 지원할 QA 담당자가 없다면, 프로젝트는 거의 실패한다. 그리고 그들이 클라이언트에 소속되어야하는 이유는 간단하다. 아마도 개발자/개발사가 PM과 QA까지 지원하기에는 프로젝트 예산이 여유롭지 않을 가능성이 높기 때문이다. 당연히 그들은 의사결정 권한이 없기도 하다.

.

#3

묻기전에 검색은 한 번 해보자.

예를 들어 ‘서버비는 얼마나 나올까요?’ 같은 질문이 가장 흔하다. 어떤 프로젝트에서는 도입해야할 VPN 솔루션 비용, 각종 API 사용 비용까지 물어본다. 문자 발송 비용이 얼마인지, 푸쉬 에이전트 사용 비용이 얼마인지는 검색해서 찾아보기 전까지는 개발자도 정확히 모른다.

.

#4

미팅보다는 전화로, 전화보다는 이메일로 연락하자. 외부에서 미팅 한번 하고나면 퇴근시간이다. 그리고 친한 사이가 아니라면 카카오톡은 지양하자. 페이스북 메시지도 좋지 않다. 이메일을 보내고, 필요하다면 전화를 하자. 이메일 회신이 느리거나, 이메일을 통해 명확히 커뮤니케이션할 수 없는 개발사라면 함께 일하지 않는게 좋다.

.

#5

프로젝트를 하고 안하고는 고객의 선택이다. 하지만 선택을 했다면 명확히 알려주는게 좋다. ‘준비해서 다음 주, 다음 달에 연락하겠다’는 얘기는 안하는게 좋다. 차라리 ‘잘 모르겠으니 시간을 갖고 고민해보겠다’고 솔직하게 얘기하자. 그리고 고민 끝에 다시 연락했다면, 다시 원점으로 돌아가지 말자. 같은 얘기를 무한히 반복하는건 서로에게 피곤한 일이다.

실제로 이런 일은 자주 있다. 문의 > 논의 > 견적 > 고민의 무한 루프에 빠지는 사람이 많다. 고민은 견적을 받고 하는것이 아니라 문의하기 전에 하는 것이다.

.

#6

기획은 기획자가, 디자인은 디자이너가, 개발은 개발자가 하는 것이다. 처음 기획하는 스타트업 대표가 온갖 꿈과 희망을 담아 만들어놓은 기획안은 사실 쓸모가 없다. ‘기획은 완료되었고…’로 시작하는 프로젝트를 가급적 피하는 이유가 있다. 그 외에도 피해야할 단어들은 많다. 가급적 프로젝트의 난이도와 기간을 표현하는 ‘형용사’는 쓰지 말자. ‘심플하게…’로 시작하는 문장을 듣는다면, 그 프로젝트도 가급적 피하려 노력한다.

오히려 어려운 것을 어렵게 표현하는게 좋다. 개발자라면 어느정도는 새로운 기술과 도전에 열려있다. 어려워보이지만 의외로 쉽게 해결되는 기능들이 많다. 원하는 것을 정확하게 전달하면서, 개발자에게 해결책을 요구하는 것이 좋다.

.

그렇다면, 처음 개발을 의뢰해야하는 입장에선 어떻게 접근하는게 좋을까. ‘난 내가 원하는게 무엇인지 모르겠다’에서 출발하는게 가장 합리적이다. 이 경우에는 개발사들에게 속는게 아닐지 우려될 때가 있다. 그렇다면 프로젝트를 최대한 작게 잘라서 하나씩 진행해보는게 좋다. 좀 더 자세하게 설명해보면 아래와 같다. (이건 조금은 극단적인 하나의 예시다.)

.

1단계.

전문 프리랜서 기획자를 고용한다. 전체 기획안을 의뢰하기보다는 1주일에 정해진 시간만큼의 기획 업무와 한 차례의 미팅을 요청한다. 즉, 기획자의 기획 속도가 내가 생각하고, 고민하는 속도를 넘어서지 않도록 만드는 것이 중요하다. 기획자가 한 페이지를 기획했다면, 난 1주일 동안 그 한 페이지를 놓고 고민하고, 그 결과를 다음 미팅에서 피드백한다. 이 과정을 무한히 반복한다. 두세달 정도가 지나면, 어느정도 단단한 기획안이 만들어질 수 있다. 이 때는 돈이 좀 들더라도, 좋은 기획자를 고용하는 것이 좋다.

.

2단계.

디자인을 의뢰한다. 이 때는 한 명의 디자이너를 고용하기보다는 99designs와 같은 서비스를 이용하는 것도 좋다. 디자인은 1단계에서 작성한 기획안을 수정하지 않는 범위에서 제한적으로 진행한다. ‘좋은 디자인 아이디어’를 발견하더라도 기획안과 다른 부분이 있다면, 다음으로 미루는 것이 좋다. 디자인은 기획안에 색을 입히고, 폰트와 라인을 정리하는 개념으로 진행한다. 이런 식의 디자인이라면 한 달안에 마무리될 수 있다.

.

이제 기획안도 있고, 디자인도 있다. 개발만 남았다. 이제 개발을 진행하기 전, 해야할 일이 하나 남았다. 1) 이걸 정말 개발할 것인지 다시 한번 고민한다. 2) 그리고 기획안에 포함된 기능들을 A.필수, B.필요, C.욕심으로 나눈다.

• A.필수는 ‘내가 테스트해보고 싶은 서비스의 핵심’ 기능을 의미한다.
• B.필요는 ‘앱/웹 서비스라면 보통은 다들 가지고 있는 보편적’ 기능을 의미한다.
• C.욕심은 ‘기술적 차별화를 위한 모든 기능’을 의미한다.

최근에 개발을 완료한 온라인 커머스의 경우 A.필수는 로그인/회원가입, 상품 리스트, 상품 세부, 카트, 주문서, ‘할부 결제’다. 여기서 핵심은 상품을 보고, 할부 금융을 통해 결제할 수 있는 시스템이 개발되는 것이었다. 따라서 과거 주문 내역, 프로필 정보 수정, 배송 추적, 배송지 관리, 쿠폰 및 적립금 등은 B.필요 사항으로 분류되었다. 거의 모든 커머스 서비스가 제공하는 매우 일반적인 기능들이지만, 이번 프로젝트에서는 우선순위가 낮았고, 이 중 일부는 개발 범위에 포함되지 않았다. C.욕심 사항에서는 할부 금융을 이용할 때 해당 ‘제2금융권’ 시스템과 연동하는 작업이었다. 즉, 사용자가 상품을 골라 할부 금융을 신청하면, 할부 금융 업체의 내부 심사 프로세스와 연동되는 형태였다. 서비스의 성격을 설명할 수 있는 중요한 기능이지만, 그만큼 개발 난이도가 높은 영역일 수 있다.

.

3단계.

개발을 의뢰한다. 반드시 A.필수 항목의 개발만 요청한다. 그럼 누구와 개발을 해야할까. 개인적인 경험으로는 다음과 같다. 좀 우울한 결론이지만 현실이 이렇다.

• 회사의 크기는 개발 결과물과 연관성이 없다.
• 견적의 크고, 작음 역시 결과물과 연관성이 없다.
• 기간의 길고 짧음도 결과물과 연관성이 없다.
• 회사가 보유한 유사 서비스 개발 경험도 결과물과 연관성이 없다.

.

내가 생각할 때 가장 의미있는 방법은 ‘회사가 보유한 유사 서비스 개발 경험’을 확인하고, 그 프로젝트에 참여했던 개발자가 이번 프로젝트를 진행할 수 있는지 확인하는 것이다. 같은 회사라도 어느 개발자가 진행하는지에 따라 전혀 다른 결과물이 나올 수 있다. 하지만 현실적으로 개발자를 확인하는 것이 불가능에 가깝기 때문에 프로젝트는 실패할 수 있다는 (원하는 만큼의 결과가 제시간에 완료되지 못하는) 가능성을 충분히 감안하고 진행하는게 좋다.

실패하더라도 피해가 최소화될 수 있게 준비하는게 현실적이다. 그 후에 해당 개발이 성공적이라면 그 개발사와 남은 개발건을 지속하는 것이 좋다.

• 첫 개발 프로젝트는 최소 Scope으로 진행한다.
• AWS, Github, Google 등 필요 계정은 직접 만들어서 전달한다.
• 초기 기획안에 대한 변경은 어떠한 경우에도 요구하지 않는다.
• 문서화에 대한 요구는 반드시 계약서에 명시하고, 꼼꼼하게 챙긴다.
• 테스트는 직접 진행한다.

즉, 개발사가 개발을 중단하더라도 다음 개발자/개발사가 개발을 이어갈 수 있도록 문서화하는 것이 매우 중요하다. 그리고 모든 계정은 직접 만들어서 관리한다. 예를 들어 개발사의 Github 계정이 아니라 내가 직접 Github 계정을 만들고, 여기에 개발자들을 초대한다면 개발사가 변경되더라도 소스 코드의 히스토리를 그대로 보존할 수 있다.

그리고 기획안을 변경하지 않아야하는 이유도 몇 가지가 있는데, 가장 큰 이유는 문서화다. 기획안 = 디자인 = 코드가 유지되어야 의미가 있다. 다른 개발사가 개발하던 프로젝트를 넘겨받은 경우가 몇 번 있었지만 위에서 언급한 일관성이 유지된 케이스는 단 한번도 없었다. 이 경우, 개발자가 코드와 DB 구조를 파악하는데 엄청난 시간이 소요된다.

.

[2018.11.10 추가]

#6

첫 번째 단락에서 한 얘기와 유사하다. 꽤 많은 고객사의 대표, 담당자는 ‘난 개발을 모른다.’고 얘기한다. 그리고 ‘그렇기 때문에 난 사업에만 신경쓰고 싶다’고 한다. 이 말에는 많은 모순이 있다. 식당 주인이 ‘난 음식도 모르고, 요리도 모른다.’고 얘기하는 모습을 상상할 수 있을까? 요리를 못하는 식당 주인이 있을 수는 있다. 하지만 훌륭한 음식을 좋은 구성으로 패키징하고, 이를 적정 가격에 파는 행위가 결국 음식 장사의 기본일 것이다. ‘기가 막히게 아름다운’ 음식을 주방장에게 알아서 해달라고 주문하는 것만큼 무책임한 일이 또 있을까? 개발도 동일하다. 개발을 맡긴다는 것은 그 결과물로 나오게될 웹, 모바일 기반의 서비스가 사업의 밑천이 되는 것이다. 판매해야할 음식이자 제품이다. 그렇기 때문에 사업의 최종 책임자는 서비스 개발이 완전히 종료되는 시점까지는 개발 자체에 집중해야한다. 그 정도의 시간과 노력을 할애할 여력이 없고, 개발을 이해할 의지가 없다면 IT와는 전혀 관계없는 사업을 해야 맞다고 본다.

.

#7

직장 생활을 해본 사람이라면 모두가 안다. 동일한 업무를 수행할 때 외부 인력을 사용하면 단위 기간당 비용은 두 배 이상 높아진다. 하지만 그만한 전문성을 지닌 직원을 채용하기 어렵거나, 그들을 일년 내내 유지할 계획이 없을 때 외부 전문가에게 일을 맡긴다. ‘내부 개발자를 채용하면 좋겠지만 비용도 그렇고, 관리도 그렇고 해서…’ 라는 이유는 사실 적절하지 않다. 여기서 특히나 ‘내부 인력으로 채용할 경우 비용이 높아지기 때문에…’라는 얘기를 조용히 흘리는 클라이언트도 자주 만난다. 이들은 IT 개발을 ‘대학에서 컴퓨터공학을 전공하는 조카에게 용돈주고 홈페이지 하나 만드는’ 정도로 인식한다는 것이다. 노력해서 만들어도 홈페이지 만드는 노력으로 이해하는 클라이언트와 함께하고 싶은 개발자는 없다.

.

#8

첫 단락과는 좀 배치되는 얘기다. 사람들은 개발자를 좀 오해한다. 어두컴컴한 골방에 앉아 컴퓨터 화면을 바라보며 키보드를 미친듯이 두드릴뿐, 연애도 취미 생활도, 운동도 안한다는 이미지를 은연 중에 가지고 있다. 즉, 개발자와의 대화를 어려워하고, 어떤 경우에는 개발자와의 대화 자체를 꺼리는 경우가 간혹 있다. 이 경우에는 클라이언트 > 개발팀 PM > 개발자의 경로로 의사를 전달한다. 개발팀의 PM은 선임 개발자일수도, 개발사의 대표일수도 있다.

이 경우 커뮤니케이션은 깔끔하다. 서로 익숙한 단어와 문장으로 대화할 수 있고, 문서화해서 공유하는 능력도 뛰어나다. 하지만 이들은 대화에 익숙한만큼 1) 요구사항에 대해 지나치게 방어적이어서 새로운 기능이 논의될 때마다 기간 연장이나 추가 비용을 요구할 수 있다. 이들은 이러한 대화에 익숙하고, 잘 한다. 2) 또는 지나치게 클라이언트 친화적이어서 모든 질문과 요청에 ‘긍정적’으로 답한다. 이 두가지 모두 정상적이지 않다.

클라이언트가 담당 개발자와 직접 대화를 한다는 것은 여러모로 좋다. 즉, 클라이언트 > 개발자 > 개발팀 PM 형태로 의사가 전달되는 것이다. 즉, 세부적인 사항들은 클라이언트가 개발자와 직접 논의하고 요청한다. 이 경우 (우리팀의 경우) 개발자가 듣고, 합리적이고 필요한 요청이면 직접 이를 받아서 처리한다. 간혹 일정에 무리가 있거나 합리적이지 않다면 직접 거절하거나 개발팀 PM에게 일정 조율, 업무 조율을 요청한다. 이 경우, 클라이언트는 원래의 기획보다 디테일한 부분에서 더 많은 것들을 얻어갈 수 있다.

.

[2019.07.02 추가]

#9

올해들어 진행하는 몇 개의 프로젝트 중에 가장 ‘수월하게’ 또는 ‘상호 만족도가 높은’ 프로젝트가 있다. 즉, 논의를 위한 회의가 간결해지고, 결론이 명확하며, 계획한 일정이 아주 아름답게 지켜지고 있는 프로젝트이다. 이 프로젝트의 특징이 있다면,

• 클라이언트가 기획 전문 회사(또는 전문 기획자)와 기획을 완료한 상태다.
• 이 과정에서 생각이 이미 정리되어 있고, 메뉴 구성 및 동작 방식에 대해 이해도가 높다.
• 디자인 UI에 대한 피드백보다는 기능이 동작하는 UX에 대한 피드백이 중심이다.

결론적으로, 초기 2~3번의 미팅을 통해서 확정할 수 있는 것과 논의해서 정해야할 것, 잘못 기획되어 처음부터 다시 생각해야하는 것을 구분할 수 있었다. 그 결과 엑셀로 정의하는 디테일한 문서보다는 확정된 페이지를 기반으로 디자인을 바로 진행하였고, 완성된 디자인은 퍼블리싱으로, 퍼블리싱된 페이지는 개발로 이어졌다.

몇 가지 부분에 있어서는 여느 프로젝트와 유사하게 논의가 길어졌고, 클라이언트의 고민 시간과 의사결정도 늦어졌다. 하지만 전체 프로젝트 범위에 비하면 크지 않은 정도의 수준이라, 전체 일정에 영향을 주지는 않았다. 더 좋은 점은 참여하는 디자이너, 퍼블리셔, 웹 개발자, 백엔드 개발자가 초반에 받은 문서를 리뷰하면서 이해한 프로젝트의 기능과 성격이 크게 바뀌지 않았다는 점이다. 즉, 모두가 하나의 문서를 보고, 변경된 부분만 추적하면서 개발을 진행할 수 있었다.

위에서 한번 언급했던 내용과 유사하다. 클라이언트가 기획자와 초기 기획을 완료한 후에 개발사를 만나면, 또는 디자인이 완료된 상태로 개발사를 만나게되면 아무래도 프로젝트가 난항을 겪을 가능성은 현저하게 줄어든다.