국내 B2B Legal 스타트업인 '법틀'이 실재로 겪은 경험
스타트업 기업들의 프로세스 개발에 관한 생생한 이야기
스타트업엔은 실제 스타트업기업에서 프로세스 개발과정에서 일어난 생생한 이야기를 시리즈로 다루고자 한다.
스타트업 개발 프로세스의 비화는 국내 B2B Legal 스타트업인 법틀이 실제로 겪은 경험을 바탕으로 작성된 글이다. 학자들이나 대기업 프로세스 담당자의 이론적인 접근이 아니라, 거친 생존에 직면한 S/W 스타트업이 어떻게 개발 프로세스를 실제로 적용하고 살아남을 수 있는지에 대한 처절한 경험의 고백이고 리얼한 고민의 흔적이다.
법틀은 개발툴이나 API를 파는 회사는 아니어서 개발자 마케팅이 필요한 회사는 아니다.(기업 법무팀이 쓰는 클라우드 솔루션을 제공한다.) 하지만 다른 여타 중소 S/W 스타트업처럼 좋은 개발자를 구하기 위한 노력을 지속해서 하고 있다.
처음에는 이 글도 그런 의도로 제작되었으나 몇 번의 수정을 거치면서 실재 개발 프로세스 공개를 포함하는 소위 말하는 소프트웨어의 개발 방법론에 대한 한 방향을 제시하고자 하는 방향으로 글의 방향을 바꿨다.
소프트웨어 스타트업 극초기에 MVP (Minimum Viable Product)나 초기 버전을 제작할 때 해결해야 할 문제점을 논의하고 있지는 않다. 혹시 그 지점에 있는 스타트업 관계자라면 이 글은 조금 후에 접해도 무관하다.
또한 SI 성이나 요구사항 기반 제품을 만드는 기업관계자 역시 이 글을 볼 필요가 없을 듯하다. 죄송한 말씀이지만 그런 식으로는 정말 유저가 사랑할 수 있는 제품을 만들 수 없고, 스타트업은 살아남을 수 없다.
MVP에 성공했고 초기 고객이 조금 왔다. 그리고 개발자가 3~4명 생겼다. 그 다음은 무엇인가? 지금도 개발자를 구인하고 있는데 이 3~4명은 제대로 일을 할 수 있나? 앞으로 개발자들을 어떻게 꾸려나가야 하고 회사 개발팀의 체계를 어떻게 세워야 하지? 라는 고민이 있다면 이글을 계속 본다면 큰 도움이 될 것이라 확신한다.
법틀을 창업한지 6개월쯤 되었을 때, 운 좋게도 누구나 아는 2개 대기업의 법무팀에서 제품에 관심이 있다는 연락을 받았다. B2B 제품의 판매가 모두 그렇지만 엄청난 폭풍과 논의 그리고 끝날 것 같지 않던 승인 절차를 거쳐서 계약이 완료되었다. 사실 박수를 칠 일이었지만 그때는 겁이 덜컥 났다. 지금까지 이분들에게 보여준 것은 MVP였고 PPT였는데 이제 진짜 수천명이 써야 하는 제품이 된 것이다. 막상 연동을 시작하니 대기업 시스템 사이에 '착' 들어간 다는 것이 엄청난 양의 일을 요구했다.
매주 진행 상황을 체크하지만 매주 프로젝트를 부러뜨릴 만한 이슈들이 줄줄이 나왔다. 제품의 진화 단계를 2단계 정도 넘어서서 개발을 진행하면서 또 시스템 연동까지 해야 하니 정말 매일 새벽마다 덥수룩한 수염을 보며 퇴근을 했고 모든 개발팀 및 임직원들이 미친듯이 녹초가 되었다. 그 때 노트에 쓴 글이 하나 있어서 인용한다.
"Never Never 어떠한 일이 있어도 그리고 무슨 압박을 받아도 절대로 제대로 검증되지 않은 소프트웨어를 고객에게 전달하지 말자 -- 새벽 3시 30분에 XXX기업에 신규 버전 전달 후" 원시적인 고민이다. 너무 일정이 빡세고 또 너무 고생을 하다 보니까 그 때 한 번은 그냥 검증되지도 않은 소프트웨어를 고객에게 제공한 적이 있었고 고객은 당연히 수준 이하의 결과를 보고 난리를 쳤다. 쓰디쓴 경험이다. 그 때는 무언가를 제대로 하기에는 체력과 정신력이 고갈되는 느낌이었다.
사람이 일을 해도 한계가 있다. 주니어 개발자 시절에 진짜 고생을 한 적이 있다고 생각했는데 창업을 해서 더 쓴 체력적 고생을 할 줄은 몰랐다.(정신적 압박은 기대했었고 기대한 대로 들어왔다.)
한 번은 고객사 담당자와 싸운 적도 있다. 아무것도 없는 스타트업의 첫 제품을 사준 고객에게 소리를 지른 것이다. 지금 보면 정말 부끄러운 일이지만 그 때 법틀에서는 모두들 체력적으로 정신적으로 몇달을 고생하다 보니 평소에 당연히 하던 일도 못 하고 또 평소에 당연히 하지 않아야 하는 일도 하게 되었다.
스타트업이 마음이 끌리는 목표를 가지고 자유롭게 일하는 곳이라고? 그때는 아니었다. 그냥 산불이 났고 그 산불을 끄기 위해서 몇달을 고생했다. 다행히 포기하지 않고 노력해서, 늦어졌지만, 프로젝트를 성공적으로 마무리했다. 그 후에 우리를 돌아봤다. 다시는 그런 경험을 하기 싫었다. 우리는 소프트웨어를 사랑해서 SAAS 기업을 만들고 이 일을 천직으로 생각하고 평생하고 싶은 사람들이었다. 근데 우리는 '개 고생'을 하고 고객이 봤을 때도 우리는 프로가 아니었다.
"만드는 사람이 편하고 체계적으로 일해야 유저도 편하고 체계적으로 쓸 수 있다."
개똥철학이라면 철학이지만 그 때 난 이렇게 생각했다. 용역 프로젝트 진행할 때 개발자들 얼굴이 노랗지 않으면 자신의 마음이 편하지 않다는 관리자의 말을 들은 적이 있다. 기가 턱 하니 막혔다. 왜 회사에서 쓰는 소프트웨어 중에 소위 쓰레기 수준의 소프트웨어가 많고 발전이 더딘지가 느낌이 오기도 했다. 얼굴이 노래서 6개월간 만든 제품을 유저가 편하고 체계적으로 쓸까? 그걸 넘어서 정말 유저가 사랑하는 제품을 만들 수 있을까? 우리나라 B2B 소프트웨어 체계는 근본적으로 재편되어야 한다.
만드는 사람이 편하고 체계적으로 일할 수 있는 환경을 만들어 보자는 것이 핵심으로 다가왔다. 다음 글에서는 이런 목표 하에 첫 번째 개발 프로세스 점검을 어떻게 했는지에 대해서 논할 예정이다.