공동창업자와 역할 나누기, 팀 빌딩에서 정리한 기준

 

창업을 준비하면서 가장 자주 읽게 되는 주제 중 하나가 "누구와 함께할 것인가"였어요.
아이템이나 시장은 공부하면 어느 정도 감이 오는데, 사람 문제는 책을 읽어도 사례를 읽어도 정답이 없다는 느낌이 들었습니다.
그래서 이번 글은 제가 실제로 팀을 꾸렸다는 이야기가 아니라, 읽은 책과 사례에서 정리한 기준을 제 상황에 빗대어본 기록입니다.

 

초기 팀이 흔들리는 이유를 다룬 글이나 인터뷰를 보면, 기술이나 시장 때문이 아니라 사람 사이의 문제가 이유로 꼽히는 경우가 많았습니다.
역할이 겹치거나, 서로 기대한 책임이 달랐거나, 힘들 때 의견이 갈리는 식이죠.
물론 이건 읽은 이야기들에서 받은 인상이고, 통계로 확인한 건 아닙니다.

저는 기획을 해온 사람이라서, 혼자서는 만들 수 없는 부분이 분명히 있습니다.
그래서 누군가와 함께해야 한다면 어떤 사람이 필요하고 어떻게 합의해야 하는지를 미리 적어두고 싶었어요.
사람을 만나기 전에 기준부터 쓰는 게 순서라고 생각했습니다.

 

처음에는 "나에게 없는 능력을 가진 사람"만 찾으면 된다고 생각했어요.
기획자라면 개발자, 거기에 디자인을 할 줄 아는 사람 정도로요.
역량 보완이 팀 구성의 출발점인 건 맞다고 봅니다.

그런데 읽다 보니 역량이 보완되는 것만으로는 부족하다는 이야기가 계속 나왔습니다.
가치관이 맞지 않으면, 예를 들어 한 명은 빨리 키우고 싶고 다른 한 명은 천천히 단단하게 가고 싶다면, 작은 결정마다 부딪힌다는 거예요.
그래서 저는 두 가지를 따로 점검하기로 했습니다.

역량 쪽은 "이 사람이 있으면 내가 못 하는 어떤 일이 가능해지는가"를 묻습니다.
가치관 쪽은 "일이 잘 안 풀릴 때 이 사람은 어떻게 반응할 것 같은가", "돈과 시간 중 무엇을 더 양보할 수 있는가" 같은 질문을 던져봅니다.
이 질문들은 대화로 확인해야 하고, 한두 번 만나서는 알기 어렵다는 것도 같이 적어뒀어요.

 

사례를 읽으면서 가장 공감한 부분은 "좋은 관계일 때 어려운 이야기를 미리 해두라"는 조언이었습니다.
친한 사이일수록 지분이나 역할 이야기를 꺼내기가 어색해서 미루게 되고, 그게 나중에 가장 큰 문제가 된다는 거예요.

그래서 제가 정리한 문서 항목은 이렇습니다.
첫째는 역할입니다.
각자 무엇을 책임지고, 무엇은 같이 정하는지.
둘째는 지분입니다.
어떤 기준으로 나누고, 중간에 한 사람이 빠지면 어떻게 하는지.
이 부분은 법적, 세무적 사항이 얽혀 있어서 전문가에게 확인이 필요하다는 점도 같이 적었습니다.
셋째는 의사결정 규칙입니다.
의견이 갈릴 때 누가 최종 결정을 하는지, 분야별로 나누는지.
넷째는 헤어질 때의 규칙입니다.
만나기도 전에 헤어질 때를 적는 게 이상하지만, 오히려 그래서 더 필요하다고 생각했어요.

가정 예시를 하나 들어보면, 기획자인 저와 개발자인 사람이 함께한다고 할 때 "제품 방향은 제가, 기술 선택은 개발자가 최종 결정한다"고 적어두는 식입니다.
그러면 방향 때문에 기술 선택이 크게 바뀌어야 할 때는 어떻게 하는지도 한 줄 더 쓰게 됩니다.
이 한 줄을 쓰다가 "아, 이건 내가 아직 생각을 안 했네" 싶은 부분이 꽤 많이 나왔어요.

 

기준을 적다 보니 상대에게 묻는 질문만큼 저 자신에게 던져야 할 질문도 많았습니다.
저는 의견이 갈릴 때 끝까지 설득하려는 편인지, 아니면 갈등이 싫어서 먼저 물러나는 편인지.
하루에 얼마나 시간을 쓸 수 있고, 생활비는 얼마나 버틸 수 있는지.
이 일이 안 됐을 때 어디까지 감수할 수 있는지.

가정 예시를 하나 들어보면, 저는 주 40시간을 쓸 수 있는데 상대는 본업이 있어서 주 10시간밖에 쓰지 못한다고 해볼게요.
시간이 이렇게 다르면 역할과 지분, 의사결정 속도에 대한 기대가 어긋나기 쉽습니다.
그래서 이런 조건은 감정이 상하기 전에, 처음 대화에서 솔직하게 꺼내야 한다고 적어두었습니다.

 

저는 기획 쪽이고, 직접 서비스를 만들 수 있는 개발 역량은 아직 부족합니다.
그래서 필요한 사람을 적어보니, 단순히 "개발을 해줄 사람"이 아니라 "제 기획에 이견을 낼 수 있는 사람"이라는 문장이 먼저 나왔습니다.
기획자가 쓴 문서를 그대로 구현해주는 관계는 오래 가기 어렵고, 오히려 위험하다고 생각했어요.

또 하나는 모르는 영역을 서로 존중하는 태도입니다.
기획자가 기술을 쉽게 말하거나, 개발자가 기획을 가볍게 보면 신뢰가 빨리 무너진다는 이야기를 사례에서 여러 번 봤습니다.
저는 그 부분에서 제 말투부터 조심해야겠다고 메모해뒀어요.

또 하나, 사람을 평가할 때 "이 사람은 일을 잘한다"와 "이 사람과 함께 일하기 좋다"를 구분해서 적기로 했습니다.
실력이 좋은 사람이어도 소통 방식이 맞지 않으면 작은 팀에서는 금방 지치게 된다는 사례를 여러 번 읽었기 때문이에요.
가정 예시로, 연락이 하루에 한 번만 되는 사람과 바로바로 답을 주고받는 사람은 일하는 리듬이 다릅니다.
어느 쪽이 옳다는 이야기가 아니라, 서로의 리듬을 미리 알고 맞추는 것이 중요하다는 뜻이에요.

 

기준은 적어뒀지만, 정작 사람을 찾는 방법은 아직 정리하지 못했습니다.
아는 사람 중에서 찾는 게 좋은지, 일단 작게 같이 프로젝트를 해보면서 판단하는 게 좋은지 책마다 조금씩 말이 달라요.
지금 생각으로는 짧은 프로젝트를 같이 해보는 쪽이 가장 정보가 많을 것 같습니다.

그리고 팀이 꼭 있어야만 시작할 수 있는 건 아니라는 생각도 같이 듭니다.

혼자서 먼저 작게 만들어보고, 그 과정에서 필요한 사람이 선명해질 수도 있으니까요.

이 문서는 정답이라기보다, 나중에 사람을 만났을 때 꺼내서 같이 읽어볼 출발점으로 남겨두려고 합니다.