내 서비스 직접 만들기
J2S 컨퍼런스 슬라이드 공유
17년도 코드스테이츠 주관 J2S 컨퍼런스에서 발표한 제 슬라이드 내용입니다.
기존 슬라이드에 너무 그림만 있어 대신 블로그 글로 공유드립니다. 실제 발표 내용보다는 아무래도 2배 정도 글이 더 깁니다.
자기소개:
이름: 구일모 (Johnny Koo)
회사: kooslab
- 밸브 컨트롤러 하드웨어 엔지니어 @YTC
- UAV 비행제어 컴퓨터 신호 설계 엔지니어 @대한항공
- 자동차 통신 임베디드 소프트웨어 tecnical sales @벡터코리아
대학생활
대학교에선 항공기계공학을 전공했다. 기계공학 베이스에 3학년부턴 항공 쪽 내용 수업이 더 있다고 보면 된다. 학부 커리큘럼에 프로그래밍 수업이 없었던 것은 아니다. 기본 C / C++ 수업이 있었고 임베디드 프로그래밍 기초 수업도 들었다. 그때만 해도 나는 프로그래밍이 너무 싫었다. 컴퓨터도 싫고 전자회로도 싫었다. 내가 더 관심 있어했던 분야는 기계 실험과 센서/액츄에이터 신소재 실험이었다. 그래서 대학원 때도 스마트 재료를 이용한 센서/액츄에이터 실험일을 했다. 오히려 프로그래밍 비스무리 한 것은 기계 실험을 위한 MATLAB 스크립트 언어와 역시 실험 자동화 및 data 수집을 위한 LABView 프로그램이 전부였다.
프로그래밍이 재미없던 이유는 이걸 배워서 실생활 어디에 쓰이는지를 몰랐기 때문이다. 사용자가 누구고, 도대체 무슨 세상을 이롭게 하길래 까만 터미널에 아무런 도움말/부가기능 없는 emacs / vi 코드 에디터를 이용해서 프로그래밍을 해야 하는걸까. (요즘은 플러그인들이 많아진 것으로 보인다) 코딩을 처음 하는 학생에게 multi thread 니 real time이니 이런 개념을 가르쳤는데 아, 도무지 이해하기가 너무 어려웠다. 절대로 프로그래밍 근처에는 가지도 않겠다고 컴퓨터실에서 인상을 찌푸린 채로 다짐도 했었다 (응?)
직장생활
(어쩌다 보니) 공장에 들어가는 밸브 제어 회사에 하드웨어 엔지니어로 취업하게 되었다. 내 역할은 개선된 전자회로를 바탕으로 PCB에 부품을 납땜하고 전원이 잘 들어오는지 테스트, 이후 펌웨어 엔지니어가 만든 프로그램이 잘 다운로드되는지 확인하는 것이었다. 그래서 간접적으로나마 프로그래밍이라는 것이 근처에? 있었다.
개인적으론 그때부터 다시 프로그래밍에 관심을 가지기 시작했다. 단 몇 줄의 코드만으로 모터가 돌아가고, 센서가 동작하고, LED 불이 켜지는 게 신기했다. 그래서 8비트 MCU 등을 가지고 놀면서 독학을 시작했지만 성과는 그리 인상적이지 않았다.
이후 항공사로 이직을 했는데 이유는 항공과 출신이기도 했고, 무인비행기를 개발할 수 있다는 것에 매료되어 대전으로 내려갔다. 거기선 비행제어 컴퓨터가 어떤 신호를 주변 센서/액츄에이터로부터 어떤 데이터 포맷으로 받아야 하며, 또 어떤 신호들을 주어야 하는지에 대한 설계 일이었다. 내 쪽 설계가 완성되면 뒤 쪽에 계시던 임베디드 프로그래머 동료분께서 프로그램화? 시켜서 무인비행기 안에 있는 비행제어 컴퓨터에 다운로드하는 것이었다. 또 영상 인식 쪽 프로젝트도 맡겨주셔서 흥미로운 일이었으나, 역량이 부족했는지, 더 열심히 못했는지 결과들이 그리 좋지 않았다. 자동차와 비슷한, 비행기를 만드는 일이라 수없이 많은 부서와 협력업체, 그리고 국과연(ADD)과 엮여있다 보니 개발 일에서의 자유도가 크지 않았다.
지금은 정치인으로서 지지하지 않지만 당시 안철수 전 안랩 대표가 쓴 몇 권의 자서전을 인상 깊게 읽었다. 그리고 나도 창업을 해보고 싶었다. 그래서 팀장님께 창업을 하고 싶다고 말씀드린 후 퇴사를 했다. 또 대전이라는 연구단지안에 갇혀있는 게 생각보다 답답했던 것 같기도 하다. 퇴사 후 생각보다 또 겁이 많이 났다. 무얼 해야 할지 정말 앞이 깜깜했기 때문이다. 창업은 하겠다고 나왔는데 도대체 정보가 없었다. 카페에 사용되는 종이쿠폰을 전자화시켜보고 싶었는데 엄두가 나지 않아 주변에 입만 털다가 끝났다.
영업직 경험
사업을 하기 전, 난 계속 엔지니어로만 일했으니까 영업을 사업 전에 해 보면 어떨까 하는 생각이 들었다. 그냥 영업보다는, 기술영업, 또한 가능하면 자동차와 소프트웨어 관련 일을 해보고 싶었다. 그래서 자동차 전자 관련 잡지를 구독하고 가장 좋아 보이는 회사에 지원을 했다. 며칠이 지나도 연락이 없자 나는 전화를 했다. 내 서류가 자동차 소프트웨어와 직접적인 관련이 없겠지만, 면접의 기회를 주면 좋겠다고 부탁했다. 또 연락이 없자 서류가 탈락될 것 같아 다시 전화를 했다. 당시 인사 담당자분께서 아마도 약간 미친놈이라고 생각이 되었는지 감사하게도 3번의 연락 끝에 면접 기회가 주어졌다. 실제로 지원했던 엔지니어 쪽에선 떨어지고 신기하게도 관심 있던 기술 영업직으로 합격을 했다.
이후로 3년여간 자동차 제어기에 들어가는 임베디드 통신 소프트웨어를 팔았다. 독일 회사의 제품이 너무 좋아 거의 반독점 시장을 형성하고 있었고, 가장 중요한 것은 고객들의 프로젝트 기간 안에 고객의 요구사항에 잘 맞는 구성을 하여 공급하는 것이었다. 역시 주변 임베디드 프로그래머들과, 또 프로그래머 고객들과 긴밀하게 일을 했지만, 직접 개발을 하지 않기 때문에, 코드 내무 동작에 대해 알기 어려웠다. 아무리 API manual을 읽어봐도 어떻게 돌아가는지, 콜백 함수가 어떻게 동작되는지 알 길이 없었다. 지금 생각해보면 API들은 한두 번 써보는 게 제일 좋은 방법인데 난 하드웨어조차 가지고 있지 않은 기술영업을 하고 있었기 때문에 테스트하기 어려웠다. 뭐, 그럴 시간도 없었다. 10분에 한 번 꼴로 고객과 전화하고, 미팅 가고 해야 했다. 덕분에 평소 사람 만나는 것을 좀 무서워하고 쑥스러워했던 나는, 새로운 사람에게 연락하고 만나고 전화하고 하는 부분에 꽤나 용감해졌다. 나 나름대로 사람과 사람 사이에서의 미팅, 발표, 및 커뮤니케이션에 적성도 있고 흥미도 있다는 것 역시 알게 되었다.
여행 서비스 시작
회사에 적응하고 일하다 보면 많은 것들이 익숙해지기 마련이다. 독일 본사에서의 회사 프로세스가 너무 잘 갖춰져 있었기 때문에, 프로세스에 적응만 잘하면 꽤나 많은 것들이 잘 돌아갔기 때문이다. 그래서 난 약간 지루해졌다. 다시 예전에 생각했던, 내 거를 만들어보고 싶은 생각이 스멀스멀 올라왔다.
난 여행을 좋아하지 않는데, 여행을 몇 번 가보니까 사람들이 왜 여행을 좋아하는지 알게 되었다. 확실히 영상이나 책으로 배우는 것보다 직접 가보는 게 달랐다. 다른 이유는, 바로 '사람'이었다. 유명한 관광지는 영상으로도 볼 수 있고, 외국 역사를 공부하기엔 다큐멘터리 만한 게 없고, 여행기는 글을 통해 읽을 수 있다. 그러나 '사람'을 만날 수는 없었다. 여행 가서 현지 사람을 만나고, 그의 의야기를 듣고, 그의 집에 놀러 가고, 그와 함께 밥을 먹으며 이런 여행은 돈으로 살 수 없는 경험이란 생각이 들었다. 특히 현지인 집에 놀러 가는 게 제일 특별했다. 각 나라의 문화가 다 다르지만, 가장 경계심을 풀고, 많은 이야기를 자유롭게, 깊게 할 수 있는 환경은 바로 저녁 식사 테이블이었다. 그래서 친구와 함께 '모두 테이블'이란 이름으로 현지인 가정집에 쳐들어가 저녁을 같이 먹는 서비스를 기획했다.
우리가 한국에 살고 있기 때문에, 한국에 놀러 오는 외국인들이 한국 가정집에 놀러 가서 밥 먹을 수 있도록 영업을 했다. 각종 외국인들이 유입되는 채널을 조사해서 잠복하고 있다가 심심하고 할 일 없어 보이는 애들을 공략했다. 모두가 하듯 관광지 가서 사진 찍고 인증하고 남산타워 가고 롯데월드 가는 것도 좋지만, 여행에서 잊을 수 없는 경험을 선물하겠다고 꼬셨다. 처음엔 같이 시작한 친구 집, 그리고 우리 집에서 먼저 저녁 이벤트를 열었다. 그리고 주변 친구들을 꼬셔서 호스트로 영업했고, 그다음부턴 블로그에 찾아오셔서 관심을 보이는 분들을 또 호스트로 영입했다.
처음엔 게스트를 무료로 받고, 호스트에겐 식사비를 우리 자비로 드렸다. 이벤트를 하면 할수록 게스트들도 너무 재밌어하고 호스트들 역시 굳이 비행기 타고 세계를 나가지 않아도 한 번의 저녁식사로 아르헨티나, 싱가포르, 베트남, 프랑스, 등등등 세계여행을 할 수 있다는 피드백이 우리를 더욱 신나게 했다. 이후부턴 게스트에게 소정의 돈을 받고, 그 돈을 호스트에게 모두 드렸다. 역시 크지 않은 금액이었다.
https://www.youtube.com/watch?v=biAyLcX9Ep0
웹사이트 하나 없이 페이스북 그룹과 개인 메신저 등을 사용해 계속 서비스를 진행했다. 그러나 한 번의 이벤트를 여는데 우리의 시간을 너무 많이 빼앗겼다. 그래서 이벤트 수를 늘리는데 어렵다는 생각이 들었다.
팀빌딩
우리도 airbnb와 같은 플랫폼이 있으면 게스트, 호스트들도 편하고 우리도 편할 것 같았다. 무엇보다 이벤트를 더 여는 데 있어 우리의 수고가 줄어들 것 같았다. 처음엔 워드프레스 등을 사용해서 만들어보려 했는데 생각보다 배우는데 시간도 들었고, 막상 만들고 나니 customize가 쉽지 않았다. 그래서 우리 플랫폼을 직접 만들기로 했다.
친구는 상사 일을, 나는 기술 쪽이지만 결국 영업직이었다. 개발 능력이 있을 리 없었다. 그래서 개발자 동료를 구해야겠다는 결론을 내렸다. 아는 지인이 있을 리가 없었다. 나는 알고 있던 인터넷 게시판을 돌아다니며 우리 서비스의 스토리와 얼마나 재미있고 특별한지를 주구장창 설명했다. 사정이 넉넉지 않아 월급을 드릴 순 없고, 각자 다 직장을 가지고 있으면서 퇴근 후에 모여 함께 서비스를 만들어보자고 했다. 밥과 술, 간식은 많이 사겠다고 했다. 술값이 나오면 얼마나 많이 나오겠는가.
이해할 수 없지만, 게시판 글을 보시고 한 분의 안드로이드 개발자, 한 분의 프런트/백엔드가 가능한 웹 개발자 분이 오셨다. 재밌어 보이고 여행을 좋아한다고 해서 오셨다. 두 분 다 우리만큼 특이한 분들이었다.
아는 디자이너 지인이 있어 같이 하자고 했더니 다른 친구분까지 데려왔다. 또, 온라인 게시글을 읽고 투자회사에서 한 분, 그리고 로켓펀치를 보고 한 분이 더 왔다. 우리는 어쩌다 보니 7명의 팀이 되었다. 그때까지만 해도 무조건 팀원이 많으면 일을 많이 할 수 있을 줄 알았다.
사무실을 구하고 구하고 구하다가 (여러분 부동산은 내는 만큼의 퀄리티가 나옵니다. 부동산은 거짓말하지 않습니다. 싸고 좋은 사무실은 없습니다.) 결국 아는 형님네 집 위에 있는 창고를 개조해서 만들었다. 사무실엔 화장실도 없었다. 화장실을 가기 위해선 아래 형님네 부탁을 하거나, 아니면 주변 카페에 가서 구걸을 해야 했다. 나는 팀 미팅 때 일부러 물을 마시지 않았다.
플랫폼 개발
본격적으로 개발을 시작했다. 첫 미팅 때부터 개발팀에선 백엔드, 프런트엔드에서 어떤 언어를, 어떤 프레임 워크를 쓸 것인지 결정했다. (지나고 나서 아는 거지, 그때는 뭐 하는 건지 아무것도 몰랐다.) 정확히 기억은 안 나지만, 아마 DB: mySQL, Backend: PHP, Frontend: Angular.JS를 썼던 것 같다. 개발에 참여하고 싶어서 개발자 동료에게 물었던 어처구니없는 대화가 아직도 생각이 난다.
나: "나도 개발 참여하고 싶은데, 뭐부터 공부하면 돼?"
개발팀: "글쎄..... angular 해 줄 수 있나?"
나: "앵귤러? 공부하면 되는 건가?"
개발팀: "javascript 할 줄 알아?"
나: "javascript? angular 만 하면 안 돼? 왜 두 개나 하라고 그래"
개발팀 "..."
난 웹 개발에 문외한이었지만 개발팀 미팅에 꼭 껴서 들어갔다. 개발팀에서 오가는 대화를 거의 이해하지 못했지만 괜히 참견도 하고 의견도 내고 그랬다. 종종 내가 그들의 미팅을 방해하는 것 같은 상황이 연출되었다. 난 호기심 천국이어서 궁금한 건 자주 물어보곤 해서였을까. 시간일 갈수록, 개발팀 쪽 일에선 내가 도움이 되지 않았다. 괜히 분해서 집에서 잠이 잘 안 왔다. 뭔가 배제되는 느낌. 내가 할 줄 몰라서 참여하기 어려운 상황이 싫었다. 개발팀에선 종종 디테일한 결정 부분에 대해 물어보곤 했는데, 나와 내 친구는 대답해주기가 어려웠다. 우리는 계속 추상적으로 답변하고, 개발팀은 정확한 결정을 해주길 바랬다. 개발팀에 도움은 안 되면서 간섭만 했던 나를 용서해주시길 바란다. 또 혹시라도 개발 직군에 있으시면서, 개발을 모르시는 기획자 분들이나 대표님과 마찰이 있다면, 가능하다면 너그러이 그분들을 용서해주시기 바란다. 잘 몰라서 그러는 경우도 있기 때문이다. 어렵다면 오히려 크게 싸우길 권해드린다. 싸우지도 않고 용서해주지도 않으면 그 대표는 죽을 때까지 모를 수도 있다. 대표를 불쌍히 여기고 도와주시면 좋겠다. (대표 키우려고 회사 다니나요? ㅋ)
우리는 플랫폼 없이 계속 서비스를 해 나갔으나, 아무래도 플랫폼 개발에 조금 더 신경을 쓰다 보니 실제 서비스 돌아가는 횟수가 줄어들기 시작했다. 개발팀에서 정말 많이 수고해주었으나, 아쉽게도 우린 플랫폼 런칭을 하지 못한 채, 중간에 수익모델에 대해 고민을 하다가 서비스를 접게 되었다. 게스트 & 호스트 모두에게 그 어디에서도 경험할 수 없는 특별한 가치를 주었다고 지금도 확신하고 있지만, 그 가치를 위해 들여야 할 노력의 대가가 너무 컸다. 게스트에겐 당연히 그 어디에서도 경험할 수 없는 여행 경험이기 때문에 나쁠 게 없었다. 그런데 호스트는 호스트대로 요리, 집 청소, 저녁 같이 먹어주기, 설거지 등에 비해 얻는 금액적 대가가 적었다. 물론 집에서 세계여행을 할 수 있다는 가치가 있었지만 그것은 특정 소수만이 찾던 것이었다. 즉, 확장에 어려움이 있었다.
망함
확실하게 확장할 수 있는 방법은, 디너 서비스의 금액을 확 올려버리는 것이었다. 즉 프리미엄으로 가는 것인데, 그것은 우리가 하고자 하는 철학과 맞지 않았다. 우리는 그냥 평범한 가정집의 된장국과 밥 한 그릇, 지극히 평범한 현지의 삶을 전하길 원했다. 결국 나의 고집으로 서비스를 접고, 팀원들에게 사과했다. 서비스가 안 되는 것은, 플랫폼이 만들어지지 않아서도, 팀원들이 더 열심히 하지 않아서도 아니다. 다 내 잘못이었다. 대표가 무서울 정도로 깔끔한 수익모델을 만들지 못했던 게 잘못이고, 호스트를 더 영업할 수 없던 게 잘못이었다. 단순하게 말해서 돈을 못 벌어오는 게 가장 큰 잘못이었다. 우린 자선단체가 아니었기 때문이다. 다 내 잘못이었다. 책임지지 못한 것에 대해 팀원들께 아직도 죄송하다. 그렇게 우리는 팀 해체까지 가게 되었다.
개발 그냥 직접 배우기
다음번 서비스를 할 땐, 내가 기술을 가지고 있어 어느 정도의 자유도를 가지고 싶었다. 그래서 회사 휴직을 한 후 국내 부트캠프 프로그램을 통해 웹 개발을 배우게 되었다. 처음엔 독학을 생각했었으나, 수개월 간의 독학 경험으로 봤을 때, 처음에 아무것도 모르면, 무엇부터 해야 할지, 우선순위와 무엇을 공부해야 할지, 키워드를 모르기 때문에 어려움이 많았다. 그래서 부트캠프 프로그램을 알아본 것이었고, 뉴욕에 동생이 있어 뉴욕 풀 스택 아카데미라는 곳을 알아보았으나 교육비가 거의 중형차 차값이었다. 그래서 더 싼 곳을 알아보다가, 한국에서도 교육프로그램이 있다는 것을 알게 되었고, 수강을 하게 되었다.
퇴사
교육 프로그램 종료 후, 나는 퇴사 과정을 밟았다. 주변에서 말렸지만, 그냥 퇴사했다. 예전에 이직할 때도, 그렇게 주변에서 말렸었다. 그냥 내가 하고 싶은 것을 과감히 결정 후 열심히 성실히 해 보는 것을 충분히 믿었기에 주변의 조언을 듣지 않았다. 지금도 전혀 후회하지 않는다. (사실 일주일에 하루, 이틀은 조금..)
돌이켜보면, 처음 했던 여행 서비스는 이게 동아리인지 회사인지 구분이 가지 않을 정도로 어설펐다. 이번엔 달라야 했다. 처음부터 수익모델에 대해 냉정하게 접근을 해야 했으며, 트래픽을 발생시켜 돈을 벌겠다는 순진무구한 상상은 애초에 접고 시작했다. 구체적인 니즈를 먼저 발견하고 움직여야 했다. 예전부터 여러 아이디어들을 노트에 적어놓곤 했지만, 이제는 내가 만들어내는 아이디어가 아니고, 주변의 어려움과 불편함을 들어보기 시작했다.
절대로 '플랫폼'은 하지 않기로 했다. 플랫폼은 공급자와 소비자 두 그룹의 고객층을 모두 만족시켜야 한다. 어느 한쪽만 잘 모아도 어려운 곳이 그곳이다. 그리고 '플랫폼' 제품 자체도 좋아야 한다. 유저 인터페이스야 말할 것도 없고, 소비자에게 좋은 공급자가 매칭이 되도록 하는 '필터'기능도 좋아야 한다. 즉, 할 일이 진짜 많다. 정말 타이밍과 운이 좋거나, 돈을 수십억 투자받아서 쏟아붓거나, 등등 플랫폼은 덩치가 커야 승산이 있어 보였다.
그래서 '있어도 좋고 없어도 괜찮은' 서비스 말고, '없으면 불편한', 이미 '불편하 것을 해소하는' 그런 서비스를 만들기로 했다. 그러다 보니 자연스레 내가 일했던 경험들이 떠올랐고, 비효율적으로 돌아갔던 그런 업무들이 떠올랐다. 돈 많이 받고 일하는 고급 인력들이 은근히 정말 어처구니없는 일들에 하루 두세 시간씩 쓰는 게 비일비재했다. 그렇다고 우리나라가 근무 탄력성이 좋아서 필요할 때만 고용하는 문화도 아니었다. 그래서 업무 자동화, 업무효율 개선 관련 Tool SW에 좀 더 관심을 가지게 되었다.
마침 부트캠프를 하던 곳이 강남의 한 코워킹 스페이스였는데, 지점이 늘어나는 상황이었고, 멤버분들 지원하고 관리하는데 불편함을 호소하셨다. 이러한 니즈가 특정 한 곳이 아닌 다른 곳에서도 마찬가지인지 알아보기 위해 서울 및 서울 근교의 모든 코워킹 스페이스를 조사해서 연락하고 미팅을 요청했다. 그중 반은 답을 주셔서, 일주일에 2-3곳을 잡아서 공간주분들, 매니저분들과 미팅을 했다. 그중, 반은 니즈가 더 확실해 보였고, 반은 굳이 공간 관리하는 프로그램이 필요 없다는 피드백이었다. 니치 마켓 중에서도 니치 그룹이 있었다. 지금도 좋은 판단인지 모르겠지만, CRM기반의 공유공간에 특화된 관리 프로그램을 만들면 해 볼 수 있지 않을까 라는 생각으로 개발을 하고 있다. 결과는 프로토타입 개발 진행 중이다. (개발 속도를 더 높일 필요가 있다.)
내 서비스를 직접 개발하면서 느끼는 점 몇 가지를 공유해보려 한다.
커뮤니케이션에 들이는 오해를 줄일 수 있다.
우리가 일한다고 할 때, '일'의 반은 실질적인 task이며 (디자인, 웹 개발, 기획) 그 나머지 반은 사실 동료들과, 고객들과의 커뮤니케이션으로 이루어진다는 것을 발견했다. 그러면 커뮤니케이션 효율만 높여도 일을 잘할 수 있다고 본다. 아니 어떤 분은, 실질적 업무보다 이 커뮤니케이션 능력을 더 중요하게도 보신다.
지금은 고객을 직접 만나고, 고객의 불편함이 무엇인지 듣고, 그것을 해결할만한 솔루션을 제안해야 하는 입장이다. 내가 직접 개발을 하기 때문에, 고객과의 만남에서 허투루 이루어지는 이야기를 줄일 수 있다. 고객 쪽에 제안되는 내용은 웬만하면 기술적으로 가능한 것들을 제안하게 되고 뻥카는 칠 수도 없고 치지도 않게 된다. 이런 과정이 고객 만나는 사람 따로, 개발하는 사람 따로여서 중간에 내용 전달이 필요하다면, 분명 왜곡과 빠지는 내용들이 있기 마련이다. 소규모의 우리와 같은, 순발력 있게 솔루션을 제공해야 하는 입장에선 이런 부분이 치명적일 수 있다. (큰 기업에선 요구사항만 가지고 몇 개월 시간을 쓴다.) 물론 현재 베타 제품 릴리즈가 지연되고 있습니다만... 물론, 프로그래밍을 직접 한 다는 건, 앞으로 끝까지 모든 것을 나 혼자 다 하겠다는 말은 아니다.
언젠가 내게도 팀이 생길 것이고, 목적은 좀 더 좋은 커뮤니케이터가 되고자 하는 것이다. 결국 팀 안에서 싸우기도 하고, 오해도 하면서 팀 간 커뮤니케이션을 개선할 수밖에 없을 것이다. 우당탕탕 하면서 배우는 것들도 있게 마련이다.
또, 난 이게 더 중요하다고 생각되는데,
내가 직접 개발 능력을 가지게 되면, 실패해도 회복탄력성이 크다.
즉, 쉽게 말해 망해도 다시 도전하는데 출혈이 덜하다는 것이다. 우리같이 1인, 2인 등 작은 규모의 회사에서 스스로가 제품 개발에 참여하지 못하게 되면 다음과 같은 단점들이 생긴다.
- 코드 재사용성이 떨어진다. (보통 남의 코드 고치는 것보다, 바닥부터 다시 짜는 게 나을 때도 있다.) 개발팀에 변화라도 생긴다면, 사용하는 기술 스택에도 변화가 생기므로 재사용성은 더욱 떨어지게 된다.
- 노하우가 쌓이지 않는다. 특히 외주 개발을 할 경우, 그 노하우는 1도 쌓이지 않게 된다.
서비스란 수십 가지, 수백 가지 이유로 망할 수 있다.
따라서 망해도 다시 도전하는데 비용이 크지 않아야 한다. 즉, 앞으로 내가 수십 가지의 프로토타입을 만들어야 할지도 모른다는 것이다. 이런 상황에서 개발 능력을 가지고 있다는 것은 큰 무기가 된다. 설령, 이후에 팀원이 생기거나 혹은 아웃소싱이 되더라도, 내가 개발을 하기 때문에 디테일한 부분에 대해 더 꼼꼼히 체크가 되거나 제품 마감에 대해 더 자세히 확인할 수 있다는 장점도 있다. (예를 들어 error handling이 잘 되고 있는지, 안 된다면 어디서 안 되고 있는지를 스스로 확인해볼 수 있다든지)
물론 최근 깨달은 것은, 특정 부분은 시간 계산을 해서 아웃소싱을 고려해야 하는 부분도 있다는 것이다.
내가 돈을 아낀다고 해서 돈이 다 아껴지는 게 아니다. '시간'을 반드시 고려해야 한다. 시간도 돈이기 때문이다. 외주를 주어 빠르고 좋은 퀄리티로 일을 해결할 수 있는 부분이 있다면, 특히 외주의 시간당 비용이 내 시간당 비용보다 적다면 당연히 외주를 생각해야 한다. 예를 들어, 현재 나는 백엔드, 프런트엔드를 혼자 개발하고 있는데, 처음엔 CSS / styling까지 혼자 배워서 하려 했다. 그러데 스타일/디자인 같은 경우 외부 디자이너를 고용하지 않아도 전문가들이 만들어 놓은 템플릿을 4만 원이 채 되지 않는 가격에 판매하고 있었다. 모듈 하나하나를 디자인 처리하고 있던 나는 바로 유료 템플릿을 구매하여 적용 중에 있다. 나는 디자인할 시간에 기능 개발에 더 집중해야 하는 것이다.
적용 준비중인 google material 기반의 admin template개발은 재밌다.
순진한 생각일 수도 있다. 개발은 재밌지만, 제품 개발은 고통스러울 수도 있다. 왜냐면 제품 개발은 개발의 의미보다 고객 지원, 디버깅, 세일즈 채널 개척, 마케팅 등 더 많은 것들을 포함하기 때문이다. 그럼에도 불구하고 개발은 재밌다. 근본적으로 개발자들은 개발에 재미를 느끼고 있다고 생각한다. 물론 그것은 시키는 것만 개발하는 게 아니고, 내가 주도적으로 어느 정도 자율성을 가지고, 문제풀이에 접근할 수 있을 때 그렇다.
그래서 종종, 개발직군에 있는 분들이, 퇴근 후 따로 시간을 떼어 일부러 자기 서비스를 만드신다.
무엇보다 남의 것이 아닌 내 거를 개발할 때 훨씬 더 재밌기 때문이다.
회사에서 제품 개발의 일부분만 담당하여, 특정 기능만 잘 돌아가는 것을 책임져야 했다면, 내 꺼를 만들게 되면 보통 처음부터 큰 그림을 다 그려야 한다. 모든 기능에 내가 책임감을 가지고 설계학 만들어야 하기에, 숲을 볼 수 있게 된다. 아니 봐야만 한다.
재미를 넘어서서, 내가 만드는 소프트웨어가 누군가의 문제를 풀어준다면 더욱 의미가 생긴다.
제품 개발은 그냥 개발과 약간 다르다. 취미로의 개발은 나만 재밌거나 내가 배우는 점이 있으면 충분하다. 하지만 제품은, 나의 만족도와 상관없이 다른 누군가를 만족시켜야 한다. 즉, 누구도 쓰지 않는 고기술이 집약된 제품은 누가 그랬는데 "예쁜 쓰레기"라고 볼 수 있다. 반면, 기술적으로 봤을 때 누가 봐도 유치한 수준이지만, 많은 사람들이 사용하게 된다면, 그것은 '좋은 소프트웨어'라고 볼 수 있다.
영업직에서 일할 때, 우리는 발주가 들어가는 순간, 제품에 따라 10주, 혹은 16주 이후, 돌아오는 월요일에 제품이 고객에게 배송이 되도록 계획을 잡는다. 어떻게 영업팀에서 일하나 관찰했더니, 달력을 보고 직접 손으로 카운트하여 주문확인서에 텍스트로 적으셨다. 나도 해봤더니, 3-4주가 넘어가면 달력을 넘겨야 하므로, 한 번 카운트하고 제대로 카운트가 되었나 의심이 갈 정도였다. (제품 배송 시기는 고객 쪽에 굉장히 중요한 문제였기에 실수가 있어선 안됐다. 실제로 몇 번 실수가 있기도 했다.) 나의 아주 초보적인 javascript 코드로 Date method를 사용해서 간단한 html 입력을 받고 제품 배송 날짜를 출력하는 프로그램을 만들어봤다. 물론 윤달 같은 부분, 7,8월 같은 경우엔 격월로의 30일, 31일 규칙이 적용되지 않는 등의 문제도 해결해야 했다. 어쨌든 꽤 낮은 수준의 프로그램이었지만 나도 잘 쓰고, 영업팀 동료 매니저님들도 사용하게 되었다. 회사 서버가 있었으므로, 서버에 html 파일만 저장해 놓으면 내부에선 모두 접근이 가능한 스크립트 코드였다. 이런 낮은 수준의 코드도, 몇몇 사람들이 계속 쓴다면 좋은 소프트웨어라고 부를 수 있지 않을까?
개발자 직군으로 회사를 다니더라도 꼭 시간을 떼내어 자신만의 서비스를 만들어 보셨으면 좋겠다. 많은 개발자분들은 회사에서도 일하다 왔는데 집에 와서 또 일하라는 것이냐,라고 하실 수 있겠지만, 똑같은 일이 아니기 때문이다. 경우에 따라 소소한 부수입이 생길 수도 있고, 또 시장의 요구와 잘 맞게 되면 이후 사업화해볼 수 있는 좋은 기회도 생기기 때문이다. 자연스운 팀빌딩이 될 수 있는 기회는 더욱 귀하다. 가끔은 고객과 함께 팀빌딩을 하는 것도 봤다.
내 서비스를 직접 만든다는 것은, 전략적으로 작게 시작해서, 작음을 계속 유지해야 한다. 그것이 마이크로 비즈니스다.
투자를 받으면, 투자금을 써야 한다. 투자를 받는 이유는 빠르게 성장하기 위해서다. 내가 원하지 않아도 사람을 고용해야 하고, 덩치가 커지게 된다. 아무리 좋은 투자자라 할지라도, 투자자의 의견이 주주로서 인풋이 된다. 보고도 해야 한다. 나만 운전대를 잡고 있는 것이 아니다. 내가 원하는 실험들을 자유롭게 할 수 없는 것이다. 언젠가 개바에서 손을 떼고, 운영에 시간을 쏟게 된다. 모든 스타트업의 장점들이 마이크로 비즈니스에선 단점으로 변할 수 있다. 당연히 경쟁이 적은 니치마켓보다는 모두가 경쟁하는 경쟁시장으로 가야 할 수도 있다. 크게 덤비면 크게 다친다. 반면, 작게 시작하면 작게 여러 번 시도해 볼 수 있다. 한 사이클을 크게 다치지 않고도 돌아볼 수 있다. 여행서비스를 어처구니없이 어설프레 했어도, 한 번의 실패로 꽤 많은 것을 배웠다. 이런 실패의 사이클에도 비용이 크게 들지 않는다.
또한 니치마켓과 같은 내용인데, 좀 더 소수의, 구체적인 사람들의 불편을 해소할 수 있다. horizontal -> vertical 마켓으로 갈 수 있는 것이다. 버티컬로 간다는 것은, 더 특수한 상황에서 우리만이 프로가 될 가능성이 높다는 말이다. 큰 대기업이나 투자자들은 이런 시장에 관심을 덜 가지게 된다. 들어오고 싶어도 들어올 수 없다. 빠르게 성장해서 덩치를 키워 투자금을 회수해야 하는 스타트업 본질에서 벗어나기 때문이다.
결론
꼭 소규모 마이크로 비즈니스 대표가 개발을 해야 하는 것은 아니다. 그러나 우리같이 소규모 팀으로 이루어지는 조직에선 한 명이 명확한 하나의 기술을 가지고 있어야 한다는 것이다. 그것이 디자인 능력이 되었든, 엄청난 사업화 능력이 되었든, 누굴 만나도 제품을 팔아올 수 있는 영업능력이 되어도 좋을 것 같다.
그런데 소프트웨어 자체가 제품이어야 하는 업계에선 (Software as a Service), 나는 대표가 개발을 할 줄 아는 것이 필요하다고 본다. 내가 개발을 하지 않을 거면서 작게 소프트웨어 사업을 해본다는 것은, 약간 이상해 보인다. 무엇보다도 나한테 제일 중요한 것은, 해보고 싶은 일을 내가 해 볼 수 있다는 것이, 개발 능력의 가장 큰 장점인것 같기도 하다.
저는 한국에서 작은 소프트웨어를 만드어가는 커뮤니티가 있으면 좋겠습니다. 있으면 제가 가고 싶고 없으면 함께 만들어가고 싶습니다. 작은 서비스에 관심 있는 분들, 향후 정기적, 비정기적 소식과 정보공유에 관심 있는 분들은 아래 email로 연락 주시면 앞으로 작은 소프트웨어 사업에 관련한 내용들을 공유하도록 하겠습니다.
구일모
johnnykoo@kooslab.com
물론, 본 블로그를 구독하시면 향후 제가 계속해 나가는 삽질의 소식을 자주 들으실 수 있습니다.
