IT 서비스 창업은 처음이니까

저는 python backend 개발자입니다.

운이 좋게도 지난 10년간 여러 스타트업을 경험했습니다. 그중 극 소수는 KPI 가 나이키 그래프를 그리며 성장했습니다. 나머지 대부분은 안타깝게도 손익분기점에 다가가지 못하고 정리해야 했습니다. 조직을 떠날 때마다 원망과 아쉬움의 감정을 어깨에 짊어집니다. 특히 대표님들에 대한 안타까움은 시간이 지나도 여전히 남습니다. 언젠가 제 가진 꿈을 이루려면 저도 대표의 역할을 해야만 합니다. 그때 저를 위해서 몇 가지 당부를 적어둡니다.

 

대표의 열정을 직원들에게 강요하지 않는다.

직원들이 회사에 남는 이유는 월급과 개인의 성장입니다. 돌이켜 보니 조직이 경제적으로 풍요로워지더라도 제 월급과는 큰 상관이 없었습니다. 다만 경제적으로 어려워지면 급여에 영향을 주었습니다. 대표는 24시간 7일 내내 회사만 생각하지만, 직원은 9시에서 6시까지 그중에서 점심시간을 뺀 시간만 회사일에 대해서 생각하고 고민합니다. 회사가 망하더라도 그들은 새로운 직장을 구할 수 있고, 많은 타격을 입을 가능성이 큰 사람을 회사와 물아일체인 대표입니다. 태생적으로 서로 다른 입장을 가지고 있습니다. 바람과 태양의 싸움이라는 이솝우화에서 처럼 나그네의 웃옷을 벗기기 위해서는 외부적인 힘이 아니라 스스로의 동기입니다. 직원들의 동기를 잘 이해하고 가려운 곳을 긁어주어 회사의 방향과 연결하는 것이 대표의 역할입니다.

일정 조율은 개발자와 함께 한다.

기능의 구현 가능성 및 일정은 개발자가 가장 잘 알고 있습니다. 소프트웨어 특성상 난이도가 눈에 보이지 않아 체감할 수 없습니다. 단순히 버튼을 하나 붙이는 것과 같은 기능이라도, 내부적으로 여러 의존관계가 있다면 생각보다 많은 시간이 필요합니다. 특히 db 스키마 변경같이 단순해 보이는 작업이라도 영향도가 큰 경우는 개발 일정과 더불어서 배포과정에서도 많은 어려움을 포함합니다. 그렇다고 필수 기능 작업을 피할 수는 없습니다. 다만 각 담당자와 함께 논의하는 모습을 보여주어, 그들의 역할이 아주 중요하고 존중받는다는 태도를 보여주어 그들의 능동적인 태도를 이끄는 노력이 필요합니다.

기능이 많다고 좋은 제품이 아니다.

출시전에 기능이 많아지면 두 가지중 하나였습니다. 일정이 길어지거나, 버그가 많은 제품이 만들어진다는 것입니다. 경험 있는 시니어 개발자의 숫자와는 상관이 없었습니다. 이 상황도 문제겠지만, 제가 생각하는 더 큰 문제는 고객이 원치 않는 기능을 만드느라 많은 시간을 허비하는 상황입니다. 제한된 자원으로 결과를 내야 하는 상황에서 시간과 개발자의 자원을 낭비하는 것은 조직 자체의 존재를 위협하니까요. 아쉽고, 부끄럽겠지만 MVP를 명확히 정의하고 단기간에 결과물을 출시해야 합니다. 고객에게 피드백을 들을 수 있을 정도면 훌륭한 시작이 됩니다.

What is a Minimum Viable Product (MVP)?