by
Mar 29. 2020
스타트업에서 제품 개발하기 (2)
제품을 개발하는 과정에서 팀은 성장한다
걔 머글 아니야 말포이...나는 100% 순수 개발자가 아닌, 소위 '머글', 그러니까 비전공 개발자다.
'소프트웨어 공학'이라는 학문을 공부한 것은 아니었다. 내가 개발 비슷한 것을 하고 있는 최초의 기억은 16진수 숫자가 잔뜩 쓰여있는 파란색 화면이다.
어린 나는 영 게임에 소질이 없었는지, 어떤 게임이든 금방 게임오버를 당하곤 했다. 보통 또래 친구들은 포기하던지, 게임 실력을 올리던지했을텐데, 나는 둘 다 아닌 게임 데이터나 세이브 데이터를 고치는 쪽을 선택했다. 고등학교를 졸업할 무렵, 정신을 차리고 보니 나는 소프트웨어 개발, 소위 말하는 '게임핵'을 만들고 있었다. 별도로 공부를 한 것도, 누가 가르쳐준 것도 아니었다. 그저 좋아했기에 자연스럽게 다다른 결과였다. 유년기에 내가 좋아하는 게 무엇인지, 잘할 수 있는 게 무엇인지 그렇게 잘 찾아놓곤, 컴퓨터 공학과는 전혀 무관한 전공을 공부했고, 다른 전문 기술을 필요로 하는 필드에서 일을 해왔다.
HE(HEX EDITOR). 게임 데이터를 수정하기 위해서 반드시 사용해야 했었다. 이렇게 다시 보니, 이미 어렸을 때부터 나는 '평범하게' 살 생각이 없었던 것 같다.이 회사에서 나는 최고경영자(CEO)이자 동시에 최고기술자(CTO) 역할을 수행하고 있는데, 개발 지식을 갖추고 다른 분야에서 업무를 해왔던 '머글' 개발자라는 출신 성분 덕을 톡톡히 보고 있다. 기술을 개발하는 스타트업에서 대표자가 개발을 알고 있다는 것은 굉장히 큰 강점이다. 하지만, 모든 대표자가 반드시 개발을 이해할 필요는 없다. 일단은 개발자의 특성을 파악하는 것 정도로 충분하다: 개발자는 항상 리팩토링 하고 싶다.
이런 사람들이 읽어볼 만합니다:
· IT 제품을 개발해야 하는 비개발자 출신 스타트업 대표자
· 스타트업에서 일하는 신입 개발자
· 대기업에서 일하다가 스타트업으로 넘어온 중견 개발자
· IT 스타트업을 창업하고 싶은 예비 지옥 탐험가
지난글: 스타트업에서 제품 개발하기- 린개발
https://brunch.co.kr/@nooong/37
스타트업 대표는 토니 스타크를 꿈꾸는가
나는 마블 유니버스 영화 중에서 아이언맨 1편을 가장 재밌게 봤다. 초기 토니 스타크가 피랍돼서, 마크 1 모델을 만들어 탈출하고, 마크 2 모델을 만들기까지의 과정을 좋아한다. 공돌이 감성을 자극한다고 해야 하나.
극 중에서 토니 스타크는 열악한 환경에서 최소 기능을 갖춘 마크 1 모델과 초소형 원자력 융합로를 만들어 감옥에서 탈출한다. 그렇게 전투 수트의 가능성을 확인하고는 개량 버전들을 개발하기 시작한다. 앗, 어디선가 본 모양새다. 스타트업이 제품의 MVP를 만들고 시장 가능성을 확인하고 실제품을 개발하는 것과 크게 다르지 않다. 극 중 토니 스타크 설정이 '세계 제일가는 공돌이', '세계 제일가는 군수업체 부자'라는 것만 빼고.
MK 1은 하늘을 날지도 못하고, 총을 쏘는데 MK 2는 하늘도 날고 빔도 나가고, HUD도, 보조 인공지능도 있다.MVP 혹은 프로토타입 모델과 우리가 이상적으로 만들고자 하는 제품의 차이는 굉장히 크다. 차이가 굉장히 크다는 것은 한 번에 짠- 하고 만들어내기 어렵다는 이야기다. 물론, 가끔 MVP를 통해서 시장성만 확인하고, 완전에 가까운 실제품이 나오는 경우도 없지는 않다. 아이언맨 마크 1에서 마크 2를 개발한 것처럼 드라마틱한 경우는 없지만.
MVP 모델이 한 번에 완성도를 갖추려면 크게 두 가지가 필요하다:
· 창업자 혹은 창업팀이 개발 쪽으로 매우 유능해야 한다.
· 창업팀에게 돈 혹은 시간이 많아야 한다.
아이언맨과 스타크래프트는 동일한 조건을 갖추고 있다. 아이언맨을 만든 토니 스타크에게는 천재적인 기술력과 세계 최대 군수 회사에서 나오는 자본력이, 스타크래프트를 만든 블리자드 사에는 천재적인 개발자 '마이크 모하임'과 함께, 전작 '워크래프트', '디아블로'의 히트를 통한 탄탄한 자본이 있었다.
그렇다면 막대한 자본력도 없는, 범재들이 모인 창업팀은 MVP를 만든 이후 어떤 식으로 개발을 해야 할까?
지난 글을 통해서 이야기한 것처럼 '볼트론'과 같은 변신합체 로봇을 구축하는 것이 이상적이지만, 만들고자 하는 제품에 따라서는 내가 만들고자 하는 최종 제품의 일부이지만, 단독으로 구동 가능한 형태의 제품 단위로 떼어내는 것이 어렵거나 불가능할 수도 있다.
얼기설기 만들어놓고 조금씩 바꾸면서 나아간다.만들고자 하는 제품의 기획이 명확하다면, MVP에서 조금씩 발전시켜나가는 형태로 개발해나가는 것도 방법이다. 모든 기능들을 최소 서비스 제공만 가능한 형태로 구현해놓고, 이상적인 형태로 만들어 나가는 방법이다.
이런 형태로 개발해서 얻을 수 있는 장점은 다양하다:
일단 서비스가 동작되기 때문에, 제품을 시장에 팔아볼 수 있다.
즉, 제품 개발 비용 회수 시기가 빨라진다.
시장의 반응을 보면서 개발 우선순위를 고려할 수 있다.
비개발자/개발자 모두 전체적인 개발 완성 일정을 가늠해볼 수 있다.
우리 팀 대표자 혹은 우리 팀 개발자가 천재인 것 같다면, 블리자드 전 대표이사 마이크 모하임의 기록을 한 번 확인해보자. 우리가 천재일지도 모른다는 생각은 앞서간 천재들의 기록을 확인해본 이후에 해봐도 늦지 않다.
야생의 초기 기획과 다른 서비스가 나타났다?
제대로 가고 있다고 생각했었는데, 어느 날 정신 차려보니 기획 의도에서 벗어나 있었다. 어떻게 할 것인가?제품을 개발하다 보면 다양한 상황을 경험하게 된다. 예를 들어, 원래 의도와 다른 형태로 서비스가 개발되고 있다는 것을 알게 되었을 때. 기획자로서 혹은 개발자로서 초기 기획과 다른 형태로 제품이 개발되는 것을 발견했다면, 어떤 조치를 취해야 할까?
나는 지금까지 많은 개발자/비개발자에게 이 질문을 던져보았는데, 많은 사람들, 심지어 개발자까지도 '엎는다/다시 한다'라는 선택지를 고르는 것을 발견했다. 그 이유를 물었을 때 이유는 다양했지만, 개발자와 비개발자 공통으로 '처음 기획이 중요하니까.'라는 이유가 가장 많이 나왔다.
하지만, 나는 제품이 초기 기획과 다른 형태로 개발되고 있는 것을 발견하게 되는 것은 대체로 스타트업 입장에서 좋은 일이며, 그대로 두는 편이 현명하다고 생각한다.
경로를 이탈하고 있다는 것은 우리가 잘하고 있다는 증거일 수도 있다이전 글에도 이야기했지만, 초기 스타트업은 자금적, 인적 문제로 인해서 초기 기획을 정교하게 만들기가 어렵다. 대기업은 전문가로 이루어진 집단이 적지 않은 시간을 투입하여 시장을 조사하고, 계획을 세운다. 하지만, 대부분의 스타트업은 철저한 계획 기반이 아닌 '아이디어'로 시작되는 경우가 많다. 실제 이 시장에 빠져보기 전까지는 미지의 영역이 많다는 것이고, 그것은 조직이 추가로 성장할 여지가 크다는 뜻이다.
만들고 있는 제품이 초기 기획했던 청사진과 많이 달라졌다는 것은, 곧 대표자 혹은 조직의 제품이 속한 시장 및 관련된 시장에 대한 이해도가 증가했다는 뜻일 수 있다.
개발자 역시 마찬가지다. 돈이 아주 많은 스타트업이거나 대표자가 명문대학교 컴퓨터 공학과 출신이 아니라면, 대부분 스타트업은 신입에서 3년 경력 사이의 개발자와 일을 시작했을 텐데, 이 시기의 개발자들은 빠르게 성장한다.
MVP를 만들 때는 뼝아리였던 대표와 조직, 그리고 개발자가 제품을 개발하다 보니 닭과 뼝아리 사이의 어딘가에 있게 된 상황일 수 있다.
시장에 대한 이해도가 높아졌다는 것, 그리고 대표자로서, 개발자로서 성장했다는 것은 모두 팀이 잘하고 있다는 증거다. 초기 기획했던 청사진과 많이 달라지는 것은 어떻게 보면 당연한 일이나, 많은 초기 스타트업 창업팀은 이 시기에 '내가 지금 길을 잃고 헤매고 있는 것이 아닌가?' 걱정한다. 잘하고 있는 것이니 걱정하지 않아도 괜찮다.
리팩토링 하고 싶은 개발자
한참 제품을 만들고 있는 와중, 어느 날 개발자가 말한다.
"리팩토링 하고 싶습니다."
리팩토링은 개발이 완료된 코드를 보기 좋은 형태로 최적화하거나, 기능적으로 최적화하는 것을 뜻한다. 개발자는 '난개발 된 코드를 다시 써서, 개발의 효율성을 제고할 수 있다.'라고 대표를 설득할 것이다. 과연 개발자에게 리팩토링 할 시간을 만들어주는 것이 괜찮은 일일까?
날게 해 주세요: 날긴 하네요.. 방법이 어찌 되었던 어쨌든... 이럴 때 개발자는 "이게 왜 되지?"라는 의문을 갖는다.리팩토링을 하고 싶다는 것은, 이미 기능이 동작하고 있다는 것을 의미한다. 단, 그것이 '제대로' 동작하고 있지 않을 확률이 높다. 어쨌든 동작은 하는데, 개발자가 생각하는 이상적인 형태는 아닌 것이다. 때로는 동작은 하는데, 왜 동작하는지 개발자도 모르는 경우가 있다. "이게 왜 되지?"라는 말을 하는 개발자가 불안하다면, 굉장히 흔하게 발견되는 사례이니 불안해하지 않아도 괜찮다.
개발하고 있는 제품이 초기 기획과 달라졌다는 것은 조직에게 있어서 긍정적인 일이라고 이야기했다.
하지만, 그것이 긍정적이든 부정적이든, 개발자 입장에서는 지옥을 보고 있을 확률이 높다.
개발 과정 중에서 기획이 변경되었다는 것은, 그 기획이 정교하지 못할 확률이 높다는 것이고, 곧 현재 개발자가 보고 있는 코드의 상태가 엉망진창일 확률이 매우 높다는 것이다. 개발자가 쓴 코드들은 모여서 기능이 되고, 각 기능이 유기적으로 연결되어 하나의 제품이 된다. 스타트업의 기획이 변경되었다면 십중팔구는 확장 형태로 변경된다. 초기에 염두하지 않았던 기능들을 개발하기 위해서 임시로 작성한 코드들이 많아지고 파편화되며, 유지보수가 어려워지는 형태가 된다. 개발자는 이런 형태의 코드를 스파게티 코드라고 부른다.
개발을 하면서 개발자가 성장했을 확률 또한 높다. 중학생이 되었을 때, 초등학생 때 썼던 일기장을 보면 부끄럽고 고치고 싶은 것처럼, 개발자 역시 마찬가지다. 스타트업 소속 개발자는 빠르게 성장하는데, 빠른 성장만큼 자신의 코드가 부끄러워지는 순간이 금방 찾아온다. 과거 코드를 보면 더 좋은 해결 방법이 보일뿐더러, 과거 작성하는 것보다 더 깔끔하게 작성할 수 있을 것처럼 보인다. 다만 그 순간이 너무 빠른 주기로 찾아온다는 것이 문제다.
조금 배운 개발자는 '기술 부채'라는 것이 쌓인다는 이유로 리팩토링 하고 싶다고 대표자를 설득할 것이다. 아직 초기 스타트업이라면, 개발자의 리팩토링 요청을 거절하는 것이 좋다고 생각한다. 리팩토링을 하지 않는 이유는 이렇다:
· 개발자는 성장한 만큼 리팩토링 하고 싶다.
· 리팩토링 하는 것, 즉 기술 부채를 상환하는 데에는 시간이 필요하다.
· 리팩토링 할 시간에 필요한 더 많은 기능을 개발할 수 있다.
· 스타트업의 최우선 목표는 생존이다.
이렇다고 리팩토링이 무조건 나쁜 것은 아니다. 기술 부채를 해소하는 것이 신규 기능 개발을 통해 비즈니스 문제를 해결하는 것보다 더 도움이 되는 시기가 있다. 이미 스타트업에 비즈니스 기회가 충분히 많은데, 기술 부채로 인하여 비즈니스 기회를 다 살리지 못하는 경우에는 리팩토링을 고려하는 것이 좋겠다. (이 정도 수준으로 사업을 진행한 스타트업이 이 글을 보고 고민하고 있을 거라고는 생각되지 않지만….)
하지만 아직 서비스가 론치도 되지 않았는데, 무작정 리팩토링을 해야 한다고 주장하는 개발자라면 기회 발굴, 생존이 우선이라고 설득하자. 물론 개발자 입장에서 스파게티 코드와 과거 자신이 쓴 코드를 보는 것은 무척이나 괴로운 일이겠지만.
앗 우리 제품의 상태가?
스타트업의 피봇은 예술적인 감각이 필요하다.제품을 개발하는 과정에서는 정말 다양한 일이 발생한다. A라는 시장에 팔기 위해서 제품을 만들고 있었는데, 알고 보니 A보다 더 큰 B시장에서 더 잘 팔릴 것 같은 확신이 들 때가 있다. 혹은 원래 생각했던 방향성에서 큰 틀에서 벗어나서 개발을 해야 할 때가 있다.
이미지에는 다리가 세 개지만, 우리 서비스를 예시로 들면.... 다리가 8개 정도 되는 것 같다.높아진 이해도에서 도출된 다양한 신규 기능들을 개발하다 보면, 기존에 구현한 기능들의 한계를 임시로 극복하기 위해 짜 놓은 코드들이 얼기설기 엉켜서 레거시 코드를 쳐내지도 못하고 방치해야 되는 상황이 오기도 한다. 이즈음 되면 리팩토링 하는 것도 엄두가 안 난다. 기술 부채를 쌓으면서 온 스타트업의 개발자가 진심으로 고통받기 시작하는 순간이다. 뭐만 개발하려고 하면, 과거 자신의 흔적 때문에 괴롭다.
얼리슬로스의 제품인 '포켓서베이'도 비슷한 형태인데, '포켓서베이'는 구글 폼을 이용해서 서비스의 코어를 만들었기에, 다양한 제약 사항들이 아직도 남아있어서, 신규 기능을 하나 만들려면 많은 공수와 꼼수가 필요하다.
이족보행 로봇을 만들고자 했으면, 이족보행 로봇이기만 하면 된다...나는 현재 개발 중인 우리 제품이 상태가, 그리고 앞으로 보게 될 우리 제품의 상태가 원래 기획한 제품의 형태에서 크게 변했어도, 큰 틀에서만 유지되면 괜찮다고 생각한다. 이족보행 로봇을 만들고자 했다면, 이족보행 로봇의 형태만 갖추고 있으면 상관없다.
우리 제품의 상태가 이렇게 된 것은 잘못된 것이 아니다. 오히려 잘못된 것은 처음 기획을 했던 때일 것이다. 최종적인 제품을 만들어나가는 과정에서, 고객의 의견을 듣고 수용하는 과정에서, 그리고 기술적으로 구현하고자 하는 이상과 현실을 타협해나가는 과정에서 당연하게 있을 수 있는 일이다. 대표자와 개발자 입장에서 웃긴 형태로 구현되어 있는 서비스를 보는 것과, 쌓여있는 기술 부채, 스파게티 코드를 보는 것은 무척이나 괴로운 일이지만, 기업이 생존하지 못하면 처음 상상했던 무언가를 완성하는 것은 불가능하다.
설득할 수 있는, 설득될 수 있는
꿈과 희망우리 제품을 통해서 보여주고자 하는 비전이 있는 것은 좋다. 그리고 비전까지 가는 과정 중에 시장에 보여줄 수 있는 제품들이 모두 군더더기 없이 예쁘게 세련되면 더할 나위 없겠다. 하지만, MVP에서 프로토타입을 만드는 과정에서, 혹은 프로토타입에서 첫 번째 출시 제품을 만드는 과정에서 자금 조달에 실패한다면? 스타트업이 갖고 있는 비전은 '유니콘'과 같은 환상의 생물이 돼버린다. 만약 만들고자 하는 제품이 마지막 완성품인, '비전'에 가까운 무언가가 아니면 시장에서 받아들여지지 않을 것 같다고 생각된다면, 그리고 비전을 린하게 만들어갈 자신이 없다면 제품 개발이 필요한 스타트업을 창업하지 않는 것을 추천하고 싶다.
그리고 모든 기획이 정교하게 구성되어 있어서, 기획만 쫓아가면 되는 형태의 개발을 원한다면 스타트업에서 개발자로 일하지 않는 것을 추천하고 싶다. 대다수의 스타트업은 완벽주의자 개발자에게 긍정적인 경험을 주지 못한다.
제품 때문에 고민하고 있는 초기 스타트업의 대표자라면, 그리고 초기 스타트업 개발자라면 조직을 잘 설득해야 한다.
· 잘하고 있는 중이니 걱정하지 말자.
· 리팩토링은 최대한 지양한다.
· 상상 속의 제품은 한 번에 개발할 수 없다. 조금씩 고치면서 나아간다.
· 제품이 초기 기획 의도와 달라진 것은 정상이다. 고치지 않는다.
· 살아남자. 레거시 코드를 통으로 버리고 새로 만들 수 있는 시기가 올수도있다.
