[창업] 창업 초기, 팀 내 화합과 효율을 높이는 개발자 협업 전략

시작하며

  창업을 하고 있는 친구가 있습니다. 그 친구는 비개발자이고 현재 팀에 개발자가 1명 있다고 합니다. 앞으로를 생각해서 개발자를 추가로 모집하기로 했는데, 창업 초기에 서비스를 개발할 때 개발자들 간에 의사소통 스타일이나 협업 방식에서 어떤 것을 중점으로 봐야 하는지 조언을 달라고 했습니다. 그래서 저의 과거 창업 경험, 창업을 준비하는 친구들, 창업팀에 개발자로 합류한 친구들을 보면서 느꼈던 부분들에 대해 아래와 같이 생각해봤습니다.

소통 방식

• 소통 채널: 개발자와 비개발자들 사이에 소통은 계속 이루어지는 것은 매우 중요. 기획/디자인된 것을 개발하다 보면, 개발자들도 '이건 좀 개선이 필요한데'라는 생각을 할 수 있음. 그런 부분들에 대해 바로바로 공유해줄 수 있어야 함. 따라서 적절한 소통 채널 선정은 필수. 각 팀원의 선호도와 업무 효율성을 고려하여 카카오톡, 디스코드, 슬랙, 게더타운 중에서 선택해야 함. 단, 너무 많은 채널은 관리 부담을 초래할 수 있으므로, 팀 규모와 업무 특성에 맞는 채널을 하나 또는 두 개 정도로 한정하는 것이 좋음.
• 회의: 정기적이고 구조화된 회의는 팀의 진행 상황을 점검하고 목표를 재조정하는 데 매우 중요. 당연하지만 항상 많은 회의를 하게 될 것임. 어쩌면 거의 매일 할 수도 있음. 매일 하든 아니든 가능하면 '고정 회의 시간'을 정해두는 것이 좋음. 왜냐하면, 팀원들도 지인들과 약속이 생길 수도 있고, 개인 업무(학교, 회사 등)를 봐야하기 때문에 고정된 회의 시간이 있으면 일정을 짜는데 큰 도움이 될 것임. 그리고 회의록을 작성하여 팀원 모두가 접근할 수 있는 공간에 저장하는 것이 좋음
• 비동기 소통: 팀원이 많아질수록 모든 팀원들이 함께 회의할 수 있는 시간을 잡기는 어려워짐. 그리고 업무가 세분화될수록 모든 팀원들이 회의를 참여할 필요는 없음. 하지만, 초기 스타트업에서는 모든 팀원이 프로젝트의 상태와 결정 사항에 대해 잘 알고 있어야 함. 이를 위해서 비동기적으로 소통할 방법을 마련해야 함. 여러 방법이 있겠지만, 노션을 사용하는 것을 제일 추천함.

체계적인 프로세스

• 일정 관리, 업무 분배, 우선순위 설정: 초기 스타트업에서 영입할 수 있는 개발자는 높은 확률로 개발 공부를 하고 있는 학생이거나 회사에 재직 중이어서 토이 프로젝트를 하고 싶은 사람일 것임. 이들에게 너무 과도한 업무를 줘서 본업에 지장을 주거나, 너무 적은 업무를 줘서 영입하지 못하느니 하면 안 됨. 과도한 업무를 줄 경우 스트레스를 받고 이탈할 가능성이 높을 거 같음.
• 프로젝트 진행 방식: 많은 스타트업에서 Agile, Scrum 등의 방법론을 사용하려고 함. 그런데 초기 스타트업에서는 이 방법론이 맞지 않는 경우도 있음. 사용자가 많이 모이지 않았다면, waterfall 방법론을 사용해서 출시 단계까지 진행하고, 팀원들이 모두 팀의 문화와 업무 방식에 익숙해졌을 때 전환하는 것이 좋다고 생각됨.

충분한 보상

• 돈: 가장 큰 보상은 돈. 돈만 충분하다면 괜찮은 인력을 수월하게 구할 확률이 올라감. 하지만, 회사는 항상 돈이 모자람. 특히, 초기 스타트업은 돈을 아예 주지 못할 확률도 높음. 그래서 아래와 같은 보상들을 적절하게 주는 것이 중요
• 성장할 수 있다는 느낌: 나의 시간을 스타트업에 투자해서 충분히 성장할 수 있다는 생각이 들 수 있게 해야 함. 개발자라면 매일 똑같은 것만 반복적으로 코딩하는 것이 아니라, 새로운 것을 코딩할 수 있도록 과제를 줘야 함. 여기서 주의할 점은 '새로운 과제'가 기존에는 한 번도 하지 않았던 것, 난이도가 갑자기 확 올라간 것이 아니어야 한다고 생각함. 게임에서 난이도가 천천히 올라가듯이 과제도 적절한 난이도, 너무 새로운 것이 아니어야 좋은 거 같음.
• 스펙: 성장하는 스타트업에서 초기부터 일한 경험을 아주 소중하다고 생각함. 아주 높은 확률로 초기 스타트업에 있던 사람은 취업 준비를 하고 회사에 들어갈 것임. 스타트업에 합류해도 올인할 생각을 가지고 하는 사람은 거의 보지 못함. 따라서 이들에게 취업 준비를 할 때 스펙으로 쓸 수 있을 만한 것들을 제공해 줄 수 있다면 충분히 시간을 투자할 거라고 생각함. 만약 스타트업이 이미 공모전, 대외활동, 창업 프로그램에서 어떤 성과를 거뒀다면 이는 미래에 제공할 스펙에 대한 근거가 되지 않을까.

문화 및 가치

• 자유로운 문화: 위에서 충분한 보상이 중요하다고 했지만, 사실 뭘 주려고 하든 초기 스타트업은 충분한 보상을 주지 못할 확률이 높다고 생각함. 따라서 스타트업이 가진 문화와 가치, 목표에 공감할 수 있도록 해야 함. 예를 들어서 어떤 사람이 안 그러겠냐마는 개발자 같은 경우에는 자유로운 문화를 추구하는 경우가 정말 많음. 따라서 어떻게 제공해 줄 수 있을지를 고민해야 함.
• 개발에 집중할 수 있는 환경: 개발자는 개발에 전념하게 하는 게 좋음! 기획을 좋아하는 개발자도 있고, 사람을 만나는 것도 좋아하는 개발자가 있음. 그런데 개발에 집중할 수 있는 문화를 제공해줘야 개발자도 덜 피로하고 생산성을 높일 수 있음. 그렇다고 또 개발자에게 소외감을 느끼지 않게 하는 것이 중요하다고 생각함. 이를 위해서는 기획/디자이너팀이 회의한 것들을 빠르고 간결하게 수시로 공유해서 함께 한다는 느낌을 줘야 함.
• 회고 및 피드백: 정기적인 회고를 통해 프로젝트와 팀의 업무 방식에 대해 지속적으로 개선할 수 있어야 함. 피드백은 서로의 감정이 상하지 않도록 팀만의 규칙을 세우면 좋음. OKR이나 KPI를 사용해서 목표를 설정하면 더 수월하게 할 수 있음.

개발자를 위한 문화

• 기슬 스택 정하기: 셀 수도 없은 만큼 많은 기술 스택이 중요함. 프론트엔드의 웹 분야만 해도 React, Next.js, Angluar.js 등이 있고, 백엔드도 FastAPI, Django, Flask, Spring, Spring Boot, Node.js 등이 있음. 팀의 니즈와 트렌드를 고려해서 적절한 기술 스택을 고르는 것은 매우 매우 매우 중요함. 예를 들어서, 빠른 개발을 위해 FastAPI를 고를 수 있지만, Spring을 사용할 줄 아는 사람이 FastAPI를 잘 사용할 수 있는 사람보다 시장에 훨씬 많음. 그렇지만 FastAPI는 빠르게 배울 수 있기 때문에 Spring을 사용하는 사람들에게 배우라고 할 수 있음. 한편으로는 나중에 취업/이직을 고려한다면 FastAPI를 배우고 능숙하게 사용하는 것보다 Spring을 잘 사용할 줄 아는 게 유용해서 팀원들의 반발이 있음. 적절하게 잘 고를 수 있는 것이 중요.
• 코드 리뷰: 코드의 품질과 일관성을 유지할 수 있음. 그리고 한 명의 개발자에게 너무 많은 무게가 쏠리는 것을 방지할 수 있음. 만약 5명의 개발자가 있는데 한 명의 개발자가 90퍼센트의 코딩을 했는데, 어느 날 팀에서 나갔다고 가정하겠음. 코드 리뷰를 했었다면 나머지 개발자가 빠르게 기존의 코드를 이해하고 개발을 이어나갈 수 있음. 하지만, 코드 리뷰를 하지 않았다면 코드를 이해하는 데만 엄청 오래 걸릴 거임.
• 깃 사용: 진짜 진짜 매우 중요... 버전 관리를 하는데도 중요하고 협업에도 아주 큰 도움이 됨. 깃을 사용하게 해주는 여러 서비스가 있지만, 깃허브를 추천함. 왜냐하면, 협업을 위한 정말 다양한 기능들이 있기 때문. 그리고 최악의 상황에서 코드가 있는 노트북(또는 컴퓨터)를 도난당하거나 망가져도 코드가 깃에 있기 때문에 바로 복구해서 코딩을 이어  나갈 수 있음.
• 문서화: 프로젝트의 진행 상황, 결정 사항, 코드의 이해 등을 위해 충분한 문서화가 필요. 이는 팀원 간의 정보 공유를 돕고, 새로운 팀원이 팀에 빠르게 적응할 수 있게 도와줄 수 있음.
• 정지적인 기술 세미나: 팀원들이 서로의 전문 지식을 공유하고 새로운 기술을 배울 기회를 제공. 다른 사람들에게 내용을 공유하기 위해 각자 맡은 분야에 대해 더 자세히 공부할 수 있고, 내용을 공유하는 과정에서도 스스로 배우는 게 있음. 따라서, 계속해서 공부해야 함.

개발자의 소통

• 디자이너와 소통: Figma를 통해 소통하는 것이 좋음. Figma는 언제 어디서든 쉽게 접속할 수 있고, 한눈에 볼 수 있음. 이때 디자이너가 Figma로 단순히 UI, UX만 만드는 것을 넘어서 구현된 UI, UX를 코드로 쉽게 변환할 수 있도록 신경써줘야 함. 이를 위해서는 디자이너도 간단한 프론트엔드 지식이 필요함.
• 기획자와 소통: 개발자가 어느정도 걸린다고 알려주겠지만, 아주 높은 확률로 그 일정보다 더 오래 걸릴 가능성이 있음. 개발 경험이 부족하다면(한 번도 프로젝트의 사이클을 돌려보지 않았더라면) 진짜 시간이 오래 걸릴 거임. 그래서 가능하면 최소한 프로젝트 경험을 한 번이라도 가진 개발자가 한 명은 필요함. 개발 경험이 많더라도, 실제 사용자가 있을 거라고 산정하고 출시하지 않는 경우에도 마찬가지. 실제 출시를 위해서는 보안과 여러 가지 부분을 더 신경 써줘야하기 때문에 오래 걸림. 실제 서비스를 출시해본 경험이 있다면 위의 경우보다 시간이 덜 들겠지만, (개발을 위한) 인프라 구축 등으로 초기에는 생각보다 시간이 오래 걸림.
• 프론트엔드와 백엔드: 굳이 웹 개발에 한정짓지 않아도 거의 모든 개발에는 프론트엔드와 백엔드가 구분되어 있다고 생각함. 이 두 분야의 개발자 간에 소통하기 위해서는 서로에 대한 이해가 필요함. 그래서 가능하면 백엔드 개발자를 구하더라도 프론트엔드에 대한 지식이 있는 사람, 프론트엔드 개발자도 백엔드에 대한 소통이 있는 사람을 뽑는 것이 좋음. 그리고 API로 통신하는 것이 가장 일반적이기 때문에 RestAPI에 대한 이해가 있어야 하고, JSON을 다룰 줄 아는 사람이 필요함. 이 부분은 잘 몰라도 교육을 통해서 알려줄 수 있음.

마치며

  과거에 제가 개발자로서 팀에 합류한 경험, 팀장으로서 개발자를 모집한 경험들을 모두 고려하여 글을 써봤습니다. 예전에 몇몇 스타트업의 피플팀 직원분들과 이야기를 해 본 적이 있는데 한 명을 뽑더라도 정말 많은 시간과 비용을 투자하고 고민해서 뽑는다고 했습니다. 왜냐하면, 한 명이라도 잘 못 뽑을 경우에는 팀 전체의 분위기를 해칠 수 있기 때문이라고 합니다. 그리고 아무리 좋은 개발자를 뽑더라도 팀의 문화가 좋지 않을 경우에는 개발자가 충분한 실력을 발휘하기도 힘들고 업무 만족도도 낮을 것입니다. 따라서 많은 것을 고려해서 좋은 개발자를 뽑을 수 있으면 좋겠습니다.