원티드 | 최초의 개발자에서, 50명 개발 조직의 CTO로!
원티드 | 최초의 개발자에서, 50명 개발 조직의 CTO로!
일자
상시
유형
아티클태그
이 아티클은 <이 시대의 개발자로 일하기> 시리즈의 8화입니다.
원티드의 개발 팀은 아무것도 없는 상태에서 시작해서 50명이 넘는 개발자가 일하는 조직으로 성장했다. 그동안 원티드의 개발 팀이 어떻게 성장해왔고 어떤 시행착오를 겪으면서 지금까지 왔는지 이야기해 보려고 한다.
디테일이나 정도의 차이는 있을 수 있겠지만, 주변의 스타트업들과 이야기해 보면 스타트업의 개발 조직이 성장하는 과정에서 겪는 성장통이나 어려움은 대게 비슷했다.
이번 아티클을 통해 초기 스타트업 조직을 여러 단계로 나누어 보고 각 단계 별로 고려 사항을 하나씩 살펴보자. 여러분이 어느 특정 단계에 있는 조직이라면 해당 부분을 참고해도 좋고, 아직 해당하는 사항이 없다면 현재 개발 조직이나 향후에 경험하게 될 조직 운영에 참고해도 좋다.
이야기를 시작하기에 앞서서 강조하고 싶은 것이 있다. 정답이 없다는 것이다. 물론 조언을 참고해서 시행착오를 줄였으면 좋겠지만, 만약 현재 상황이 여의치 않으면 이 방법만 고집하지 않고 유연하게 대처하길 바란다.
원티드의 개발 팀은 아무것도 없는 상태에서 시작해서 50명이 넘는 개발자가 일하는 조직으로 성장했다. 그동안 원티드의 개발 팀이 어떻게 성장해왔고 어떤 시행착오를 겪으면서 지금까지 왔는지 이야기해 보려고 한다.
디테일이나 정도의 차이는 있을 수 있겠지만, 주변의 스타트업들과 이야기해 보면 스타트업의 개발 조직이 성장하는 과정에서 겪는 성장통이나 어려움은 대게 비슷했다.
이번 아티클을 통해 초기 스타트업 조직을 여러 단계로 나누어 보고 각 단계 별로 고려 사항을 하나씩 살펴보자. 여러분이 어느 특정 단계에 있는 조직이라면 해당 부분을 참고해도 좋고, 아직 해당하는 사항이 없다면 현재 개발 조직이나 향후에 경험하게 될 조직 운영에 참고해도 좋다.
이야기를 시작하기에 앞서서 강조하고 싶은 것이 있다. 정답이 없다는 것이다. 물론 조언을 참고해서 시행착오를 줄였으면 좋겠지만, 만약 현재 상황이 여의치 않으면 이 방법만 고집하지 않고 유연하게 대처하길 바란다.
원티드 페이스북 페이지 ⓒ 황리건
최초의 개발자들
IT 분야의 스타트업이라면 초기부터 개발자의 도움이 필요하다. 그러니 이왕이면 공동창업자 중에 개발자가 있는 것이 좋다. 첫 번째 개발자를 채용하는 것이 가장 어렵다. (개발자가 한 명이라도 있으면 두 번째 개발자를 뽑는 것은 더 쉽다.) 만약 도저히 구할 수 없다면 파트타임이나 상담이라도 할 수 있는 사람을 찾아야 한다.
이 단계에 개발자는 최소 2명 이상을 추천한다. 개발자가 1명뿐인데 그 개발자가 팀에서 이탈하게 되면 사업을 지속하기 어려운 상황에 처할 수 있기 때문이다. 2명의 개발자를 페어로 만든다는 개념은 이후로도 계속 중요한 원칙이니까 꼭 유념하면 좋다. (애자일에서는 이를 ‘트럭 팩터’라고도 한다.) 스타트업에서 예상치 못한 상황은 생각보다 자주 생긴다. 결국 살아남는 것이 가장 중요하기 때문에 항상 최악의 상황을 대비하는 것이 필요하다.
개발자 입장에서도 혼자 하는 것보다는 2명이서 같이하는 것이 훨씬 좋다. 보통 초기 창업 팀에서 항상 업무가 많이 쌓이는 것은 개발 쪽이기 때문에 혼자 개발하는 경우에 번아웃이 되기 쉽다. 그래서 2명의 개발자가 업무 역할이나 영역을 나눠서 한다면 이 부담을 줄여줄 수 있다. 또한, 개발을 하면서 기술적인 부분에서 같이 논의할 수 있기 때문에 퀄리티와 기술 역량을 높이는 데도 도움이 된다.
최초 한두 명의 개발자는 제품의 코어를 직접 만들 수 있고, 잘 모르는 건 배워서라도 직접 만들 수 있어야 한다. 그리고, 무엇을 어떻게 만들어야 하는지 정하고, 다음 단계로 빨리 가기 위해 초기 팀을 빌딩할 수 있어야 한다.
하나의 온전한 개발 팀 만들기
다음 단계에서 가장 최우선이 될 과제는 ‘하나의 완전한 제품 팀’을 만드는 것이다. 서비스를 만드는 데 다양한 개발 분야가 있는데, 한두 사람이 모든 영역을 다 커버하고 잘 하기는 어렵기 때문에 중요 영역별로 전문가를 갖춘 팀을 만들어야 한다.
다만 이 단계에서는 개발자 한 명을 더 채용하는 것이 상당히 부담이 될 수 있다. 그래서 2~3개 영역을 한 사람이 맡는 상황은 어쩔 수 없이 생기게 된다. 다만, 개발자를 뽑을 때부터 2~3가지 기술을 하는 사람을 뽑으려고 채용 공고를 쓰지는 말자. 회사에 대한 좋지 않은 인상을 개발자에게 심어줄 수 있고 실제 채용도 잘 안된다.
채용할 때는 더 중요한 하나의 영역을 정해서 채용을 하되, 다른 영역에도 기술이 있는 사람이 있으면 우선적으로 채용을 하면 된다. 한 사람이 여러 가지를 하는 상태가 오래 지속되면 각 영역의 기술 부채가 쌓인다. 향후에 갚아야 하는 기술 부채 비용이 커지고 난이도는 점점 높아진다. 그래서 해당 분야를 잘 아는 사람이 있고, 각자 한 가지에 집중할 수 있는 온전한 제품 팀을 만들어야 한다.
최초의 개발자들
IT 분야의 스타트업이라면 초기부터 개발자의 도움이 필요하다. 그러니 이왕이면 공동창업자 중에 개발자가 있는 것이 좋다. 첫 번째 개발자를 채용하는 것이 가장 어렵다. (개발자가 한 명이라도 있으면 두 번째 개발자를 뽑는 것은 더 쉽다.) 만약 도저히 구할 수 없다면 파트타임이나 상담이라도 할 수 있는 사람을 찾아야 한다.
이 단계에 개발자는 최소 2명 이상을 추천한다. 개발자가 1명뿐인데 그 개발자가 팀에서 이탈하게 되면 사업을 지속하기 어려운 상황에 처할 수 있기 때문이다. 2명의 개발자를 페어로 만든다는 개념은 이후로도 계속 중요한 원칙이니까 꼭 유념하면 좋다. (애자일에서는 이를 ‘트럭 팩터’라고도 한다.) 스타트업에서 예상치 못한 상황은 생각보다 자주 생긴다. 결국 살아남는 것이 가장 중요하기 때문에 항상 최악의 상황을 대비하는 것이 필요하다.
개발자 입장에서도 혼자 하는 것보다는 2명이서 같이하는 것이 훨씬 좋다. 보통 초기 창업 팀에서 항상 업무가 많이 쌓이는 것은 개발 쪽이기 때문에 혼자 개발하는 경우에 번아웃이 되기 쉽다. 그래서 2명의 개발자가 업무 역할이나 영역을 나눠서 한다면 이 부담을 줄여줄 수 있다. 또한, 개발을 하면서 기술적인 부분에서 같이 논의할 수 있기 때문에 퀄리티와 기술 역량을 높이는 데도 도움이 된다.
최초 한두 명의 개발자는 제품의 코어를 직접 만들 수 있고, 잘 모르는 건 배워서라도 직접 만들 수 있어야 한다. 그리고, 무엇을 어떻게 만들어야 하는지 정하고, 다음 단계로 빨리 가기 위해 초기 팀을 빌딩할 수 있어야 한다.
하나의 온전한 개발 팀 만들기
다음 단계에서 가장 최우선이 될 과제는 ‘하나의 완전한 제품 팀’을 만드는 것이다. 서비스를 만드는 데 다양한 개발 분야가 있는데, 한두 사람이 모든 영역을 다 커버하고 잘 하기는 어렵기 때문에 중요 영역별로 전문가를 갖춘 팀을 만들어야 한다.
다만 이 단계에서는 개발자 한 명을 더 채용하는 것이 상당히 부담이 될 수 있다. 그래서 2~3개 영역을 한 사람이 맡는 상황은 어쩔 수 없이 생기게 된다. 다만, 개발자를 뽑을 때부터 2~3가지 기술을 하는 사람을 뽑으려고 채용 공고를 쓰지는 말자. 회사에 대한 좋지 않은 인상을 개발자에게 심어줄 수 있고 실제 채용도 잘 안된다.
채용할 때는 더 중요한 하나의 영역을 정해서 채용을 하되, 다른 영역에도 기술이 있는 사람이 있으면 우선적으로 채용을 하면 된다. 한 사람이 여러 가지를 하는 상태가 오래 지속되면 각 영역의 기술 부채가 쌓인다. 향후에 갚아야 하는 기술 부채 비용이 커지고 난이도는 점점 높아진다. 그래서 해당 분야를 잘 아는 사람이 있고, 각자 한 가지에 집중할 수 있는 온전한 제품 팀을 만들어야 한다.
ⓒ 셔터스톡
case study : 원티드
초기부터 펀딩을 여유 있게 받았고 팀이 이미 갖춰진 경우에는 처음부터 이 단계가 될 수 있지만, 원티드는 그렇지 않았기 때문에 단계적으로 개발과 팀 빌딩을 진행해야 했다. 고생은 많이 했지만 아무것도 없는 상태에서 빌드업을 하는 경험은 무엇을 하든 최소한으로 빠르게 시작할 수 있는 마인드셋을 가지는 데 도움이 되었다. 이러한 경험은 원티드뿐만 아니라 대다수의 스타트업들이 겪는 문제이기에 자세히 다뤄보려고 한다.
웹과 앱을 모두 서비스하는 원티드는 프론트/서버/iOS/안드로이드가 최소한의 개발 팀이 갖춰져야 하는 영역이었다. 다만 처음부터 온전한 개발 팀을 가질 수 없었기 때문에, 제품 영역과 기능을 나눠서 조금씩 단계적으로 진행을 했다. 예를 들면, 웹사이트를 먼저 만들고 안드로이드, 그 다음에 iOS 식으로 하나씩 진행했다. 웹사이트도 가장 필요한 채용공고 목록과 디테일을 보는 2가지 페이지만 먼저 만들었다. 관리자 페이지도 곧 필요했는데 내부에서 다 만들기에 시간이 오래 걸려서 이 부분은 지인에게 외주를 줬다.
보통 회사는 안드로이드/iOS 둘 다 개발하지만, 원티드는 안드로이드 한 쪽만 최소 스펙으로 개발했다. 안드로이드를 출시하고 사용자 반응을 보면서, iOS 개발자를 채용해 iOS 앱을 만들었다. 당시에는 양대 마켓 중에 어느 한 쪽만 정해서 개발을 한다는 결정이 매우 어려웠는데, 어느 한 쪽을 할지 결정하는 것도 쉽지 않았다. 지나고 보면 이 결정은 그렇게 중요하지 않기 때문에 익숙한 것부터 진행하는 게 좋다. (오디오 채팅 SNS 앱 ‘클럽하우스’도 아주 성공했을 시점까지 iOS 앱만 있었다.) 원티드 서비스가 초기에 어떻게 만들어졌는지 이야기는 원티드 제품 팀 블로그 로 확인할 수 있다.
온전한 한 팀을 만들 때는 복수로 담당하는 영역을 더 잘 하는 사람을 뽑아서 나눠주는 게 유효했다. 예를 들면, 초기에 필자가 프론트엔드와 안드로이드 개발을 병행했는데, 프론트엔드 개발을 잘하는 사람을 채용해서 일을 넘겨주었다. 이때 어느 정도 수준의 개발자를 채용하는지도 매우 중요한데, 최소한 나보다 잘하는 사람을 뽑아야 하고, 되도록이면 해당 분야에서 충분한 경험을 쌓아서 알아서 잘 이끌어 줄 수 있는 개발자를 뽑아야 한다. 선택하는 기술 스택, 작성된 코드가 아주 오랫동안 회사에 영향을 미치게 된다.
안타깝게도 초기 스타트업들은 신입이나 주니어로 일손을 채우는 경우가 많은 것 같다. 물론 잘 하는 개발자를 채용한다는 게 그만큼 더 어려운 일이기는 하다. 우리도 채용 기준을 낮춰야 하는지 오랫동안 고민을 많이 했었다. 그러나 완전한 제품 팀을 만든다는 목표를 달성하기 위해서는 각 파트를 맡아줄 수 있는 사람으로 뽑아야 한다. 이 사람이 나중에 해당 분야의 리더가 될 수 있는지 정도의 기준을 가지고 뽑을 수 있으면 더 좋다. 만약 누군가 키워야 한다거나 봐줘야 하는 사람을 뽑는다면, 적어도 하나의 온전한 제품 팀을 구성하고 난 이후가 되어야 한다.
우리도 어느 정도 팀이 신입 개발자를 잘 키워줄 수 있다는 확신과 여유가 되기 전까지는 되도록 신입은 채용하지 않는다는 정책을 정하고, 되도록 이미 충분한 역량을 갖춘 사람들을 채용하는 데 집중을 하였다.
여러 프로젝트를 동시 진행할 수 있는 팀으로
이전 단계를 제대로 하는 게 초기 스타트업에서 매우 어렵고 고된 과정이다. 만약 복수 프로젝트 팀을 구성할 수 있는 이 단계까지 왔다면, 여러분의 스타트업은 이미 어느 정도 충분한 펀딩을 받았을 것이다. 그래서 회사가 망하는 것은 덜 걱정해도 되는 상황일 것이다.
앞서 최초 개발자 단계에서 2명 이상의 개발자를 구성한다는 기본 개념을 강조했는데 다시 한번 이 개념을 꺼내야 할 때가 되었다. 하나의 개발 팀이 완성된 상태라면 이 개발 팀은 각 분야 별로 전문가 1명씩이 있는 상태일 것이다. 이 상태는 완전하게 안심할 수 있는 상태는 아니다. 여전히 한 명만 이탈하더라도 불완전한 개발 팀이 될 것이기 때문이다. 더군다나 만약 여러분이 정말 잘 하는 개발자들로 팀을 구성했다면 남아 있는 사람들이 커버해 주기가 매우 어렵다. 따라서, 앞서 만든 온전한 개발 팀을 각 파트 별로 2명씩 만들어 주어야 한다. 이쯤 되면 해야 할 프로젝트도 많을 것이기 때문에 2명씩 채용을 하더라도 일이 없어서 걱정하진 않을 것이다.
각 파트가 2명씩의 페어로 구성이 된다면, 이제는 동시에 2개 이상의 프로젝트를 병렬로 진행할 수 있게 된다. 2명이 3명이 되고, 3명이 4명이 될 수 있다. 그러면 프로젝트 관리에 어려움이 생긴다. 원래는 하나의 프로젝트만 잘 챙기면 됐는데 동시에 두 개의 프로젝트를 관리해야 하기 때문이다. 그러니 관리자는 복수의 프로젝트가 잘 돌아가게끔 문제가 생기지 않도록 잘 챙겨야 한다. 2~3개 까지는 어느 정도의 개인기로 프로젝트를 관리할 수 있겠지만 팀은 계속 커질 거기 때문에 지속 가능한 방법은 아니다. 그래서 이 단계에서부터는 여러 팀이 스스로 프로젝트를 관리하고 잘 할 수 있도록 조직화하는 노력이 필요하다.
개발 팀이 2개 이상의 프로젝트를 진행하는 정도까지 커지고, 3개 이상의 프로젝트를 동시에 진행하는 단계까지 커지면 매니저가 감당하기가 어려운 상황이 된다. 때마침 스타트업은 25~30명 규모에서 조직적으로 성장통이 크게 온다. 이 정도 규모가 되면 소통이 생각보다 더 중요하고, 오버 커뮤니케이션이 필요한 시기이다. 이전처럼 한 팀으로 커뮤니케이션을 하는 것이 아니라 복수 팀으로 커뮤니케이션을 해야 하기 때문에, 커뮤니케이션에 계층과 단계가 생기기 때문이다.
원티드는 이 단계에서 각 기능별 팀을 만들게 되었다. 프론트엔드 팀, 서버 팀, 앱 팀 등으로 팀을 구성하였다. 만약 여러분이 이 단계에 있다면 처음부터 목적 팀을 만드는 것도 생각해 보면 좋겠다. 원티드는 기능 팀을 다시 목적 팀으로 전환해 나가고 있다. 보통 목적 팀으로 아직 분화되지 않았거나 기능 팀으로 조직이 운영되는 경우에 많은 회사들이 TF 방식을 도입하게 된다. 그리고 이때쯤에 전문적인 프로덕트 매니저가 필요한지 고민을 하기도 한다.
원티드 역시 비슷한 고민을 하다가 전문적인 역할을 만들고 채용을 하게 되었다. 프로젝트 별로 TF를 만들고 전문적인 프로덕트 매니저가 있다면 프로젝트는 비교적 잘 진행된다. 조직 설문도 진행하면서 조직 체계에 대한 만족도와 피드백을 받아보는 것도 좋다.
원티드는 TF 방식을 1년 정도 진행해 보면서 피드백을 받아보니 개선할 점을 찾았다. 하나는 팀원들이 프로젝트에 따라 이리저리 옮겨 다니면서 코드를 만지게 되니 하나의 영역에서 전문성을 쌓거나 연속성을 가지기 어려운 점이었다. 그리고 여전히 프로젝트 규모가 큰 경우에 실패의 가능성이 있고, 프로젝트 결과가 성과와 잘 연결되지 않는 경우가 생기기도 했다. 그래서 다음 단계로는 구성원들이 하나의 목적으로 지속성을 가지고 일할 수 있는 보다 체계적인 조직 운영 시스템이 필요하게 된다.
case study : 원티드
초기부터 펀딩을 여유 있게 받았고 팀이 이미 갖춰진 경우에는 처음부터 이 단계가 될 수 있지만, 원티드는 그렇지 않았기 때문에 단계적으로 개발과 팀 빌딩을 진행해야 했다. 고생은 많이 했지만 아무것도 없는 상태에서 빌드업을 하는 경험은 무엇을 하든 최소한으로 빠르게 시작할 수 있는 마인드셋을 가지는 데 도움이 되었다. 이러한 경험은 원티드뿐만 아니라 대다수의 스타트업들이 겪는 문제이기에 자세히 다뤄보려고 한다.
웹과 앱을 모두 서비스하는 원티드는 프론트/서버/iOS/안드로이드가 최소한의 개발 팀이 갖춰져야 하는 영역이었다. 다만 처음부터 온전한 개발 팀을 가질 수 없었기 때문에, 제품 영역과 기능을 나눠서 조금씩 단계적으로 진행을 했다. 예를 들면, 웹사이트를 먼저 만들고 안드로이드, 그 다음에 iOS 식으로 하나씩 진행했다. 웹사이트도 가장 필요한 채용공고 목록과 디테일을 보는 2가지 페이지만 먼저 만들었다. 관리자 페이지도 곧 필요했는데 내부에서 다 만들기에 시간이 오래 걸려서 이 부분은 지인에게 외주를 줬다.
보통 회사는 안드로이드/iOS 둘 다 개발하지만, 원티드는 안드로이드 한 쪽만 최소 스펙으로 개발했다. 안드로이드를 출시하고 사용자 반응을 보면서, iOS 개발자를 채용해 iOS 앱을 만들었다. 당시에는 양대 마켓 중에 어느 한 쪽만 정해서 개발을 한다는 결정이 매우 어려웠는데, 어느 한 쪽을 할지 결정하는 것도 쉽지 않았다. 지나고 보면 이 결정은 그렇게 중요하지 않기 때문에 익숙한 것부터 진행하는 게 좋다. (오디오 채팅 SNS 앱 ‘클럽하우스’도 아주 성공했을 시점까지 iOS 앱만 있었다.) 원티드 서비스가 초기에 어떻게 만들어졌는지 이야기는 원티드 제품 팀 블로그 로 확인할 수 있다.
온전한 한 팀을 만들 때는 복수로 담당하는 영역을 더 잘 하는 사람을 뽑아서 나눠주는 게 유효했다. 예를 들면, 초기에 필자가 프론트엔드와 안드로이드 개발을 병행했는데, 프론트엔드 개발을 잘하는 사람을 채용해서 일을 넘겨주었다. 이때 어느 정도 수준의 개발자를 채용하는지도 매우 중요한데, 최소한 나보다 잘하는 사람을 뽑아야 하고, 되도록이면 해당 분야에서 충분한 경험을 쌓아서 알아서 잘 이끌어 줄 수 있는 개발자를 뽑아야 한다. 선택하는 기술 스택, 작성된 코드가 아주 오랫동안 회사에 영향을 미치게 된다.
안타깝게도 초기 스타트업들은 신입이나 주니어로 일손을 채우는 경우가 많은 것 같다. 물론 잘 하는 개발자를 채용한다는 게 그만큼 더 어려운 일이기는 하다. 우리도 채용 기준을 낮춰야 하는지 오랫동안 고민을 많이 했었다. 그러나 완전한 제품 팀을 만든다는 목표를 달성하기 위해서는 각 파트를 맡아줄 수 있는 사람으로 뽑아야 한다. 이 사람이 나중에 해당 분야의 리더가 될 수 있는지 정도의 기준을 가지고 뽑을 수 있으면 더 좋다. 만약 누군가 키워야 한다거나 봐줘야 하는 사람을 뽑는다면, 적어도 하나의 온전한 제품 팀을 구성하고 난 이후가 되어야 한다.
우리도 어느 정도 팀이 신입 개발자를 잘 키워줄 수 있다는 확신과 여유가 되기 전까지는 되도록 신입은 채용하지 않는다는 정책을 정하고, 되도록 이미 충분한 역량을 갖춘 사람들을 채용하는 데 집중을 하였다.
여러 프로젝트를 동시 진행할 수 있는 팀으로
이전 단계를 제대로 하는 게 초기 스타트업에서 매우 어렵고 고된 과정이다. 만약 복수 프로젝트 팀을 구성할 수 있는 이 단계까지 왔다면, 여러분의 스타트업은 이미 어느 정도 충분한 펀딩을 받았을 것이다. 그래서 회사가 망하는 것은 덜 걱정해도 되는 상황일 것이다.
앞서 최초 개발자 단계에서 2명 이상의 개발자를 구성한다는 기본 개념을 강조했는데 다시 한번 이 개념을 꺼내야 할 때가 되었다. 하나의 개발 팀이 완성된 상태라면 이 개발 팀은 각 분야 별로 전문가 1명씩이 있는 상태일 것이다. 이 상태는 완전하게 안심할 수 있는 상태는 아니다. 여전히 한 명만 이탈하더라도 불완전한 개발 팀이 될 것이기 때문이다. 더군다나 만약 여러분이 정말 잘 하는 개발자들로 팀을 구성했다면 남아 있는 사람들이 커버해 주기가 매우 어렵다. 따라서, 앞서 만든 온전한 개발 팀을 각 파트 별로 2명씩 만들어 주어야 한다. 이쯤 되면 해야 할 프로젝트도 많을 것이기 때문에 2명씩 채용을 하더라도 일이 없어서 걱정하진 않을 것이다.
각 파트가 2명씩의 페어로 구성이 된다면, 이제는 동시에 2개 이상의 프로젝트를 병렬로 진행할 수 있게 된다. 2명이 3명이 되고, 3명이 4명이 될 수 있다. 그러면 프로젝트 관리에 어려움이 생긴다. 원래는 하나의 프로젝트만 잘 챙기면 됐는데 동시에 두 개의 프로젝트를 관리해야 하기 때문이다. 그러니 관리자는 복수의 프로젝트가 잘 돌아가게끔 문제가 생기지 않도록 잘 챙겨야 한다. 2~3개 까지는 어느 정도의 개인기로 프로젝트를 관리할 수 있겠지만 팀은 계속 커질 거기 때문에 지속 가능한 방법은 아니다. 그래서 이 단계에서부터는 여러 팀이 스스로 프로젝트를 관리하고 잘 할 수 있도록 조직화하는 노력이 필요하다.
개발 팀이 2개 이상의 프로젝트를 진행하는 정도까지 커지고, 3개 이상의 프로젝트를 동시에 진행하는 단계까지 커지면 매니저가 감당하기가 어려운 상황이 된다. 때마침 스타트업은 25~30명 규모에서 조직적으로 성장통이 크게 온다. 이 정도 규모가 되면 소통이 생각보다 더 중요하고, 오버 커뮤니케이션이 필요한 시기이다. 이전처럼 한 팀으로 커뮤니케이션을 하는 것이 아니라 복수 팀으로 커뮤니케이션을 해야 하기 때문에, 커뮤니케이션에 계층과 단계가 생기기 때문이다.
원티드는 이 단계에서 각 기능별 팀을 만들게 되었다. 프론트엔드 팀, 서버 팀, 앱 팀 등으로 팀을 구성하였다. 만약 여러분이 이 단계에 있다면 처음부터 목적 팀을 만드는 것도 생각해 보면 좋겠다. 원티드는 기능 팀을 다시 목적 팀으로 전환해 나가고 있다. 보통 목적 팀으로 아직 분화되지 않았거나 기능 팀으로 조직이 운영되는 경우에 많은 회사들이 TF 방식을 도입하게 된다. 그리고 이때쯤에 전문적인 프로덕트 매니저가 필요한지 고민을 하기도 한다.
원티드 역시 비슷한 고민을 하다가 전문적인 역할을 만들고 채용을 하게 되었다. 프로젝트 별로 TF를 만들고 전문적인 프로덕트 매니저가 있다면 프로젝트는 비교적 잘 진행된다. 조직 설문도 진행하면서 조직 체계에 대한 만족도와 피드백을 받아보는 것도 좋다.
원티드는 TF 방식을 1년 정도 진행해 보면서 피드백을 받아보니 개선할 점을 찾았다. 하나는 팀원들이 프로젝트에 따라 이리저리 옮겨 다니면서 코드를 만지게 되니 하나의 영역에서 전문성을 쌓거나 연속성을 가지기 어려운 점이었다. 그리고 여전히 프로젝트 규모가 큰 경우에 실패의 가능성이 있고, 프로젝트 결과가 성과와 잘 연결되지 않는 경우가 생기기도 했다. 그래서 다음 단계로는 구성원들이 하나의 목적으로 지속성을 가지고 일할 수 있는 보다 체계적인 조직 운영 시스템이 필요하게 된다.
구글 AI Week에서 채용에의 머신러닝 활용 사례 발표 ⓒ 황리건
목적 조직과 개발 문화의 체계화
여러 프로젝트를 연속성 있게 실행하기 위해서는 명확한 목적을 가진 다기능 조직이 필요하다. 우리는 이런 조직을 스쿼드라고 부르고 있다. 스쿼드를 운영하는 데 있어서 핵심은 분명한 목적을 갖고 일하는 문화를 체계화하는 것이다. 목적 팀을 만들어 놓고 영역만 정해주게 되면, 목적을 스스로 정해야 하는데 이것이 쉽지 않다. 또한, 일하는 방식의 체계를 갖추어서 목적 팀이 많아져도 이들이 공유하는 일하는 방식이 있어야 한다.
원티드는 2주 단위로 개발을 하자는 목표 수준을 정하고 애자일 스크럼을 도입하였다. 애자일을 하는 것은 생각보다 깊이 있는 공부가 필요하다. 고객에게 더 자주 가치를 전달한다는 핵심 목표를 달성하기 위해 구성원들이 더 많이 소통해야 한다는 것을 진심으로 깨우쳐야 한다. 또한 유저 스토리를 작성하는 방법이나 백로그 관리, 스프린트 운영 방법 등 하나하나 체계적으로 교육을 받고 배울 필요가 있다. 따라서 원티드는 전문 애자일 코치로부터 컨설팅을 받으면서 교육과 코칭을 받았다. (애자일 도입 시 전문가나 경험자의 도움을 받는 것은 꼭 필요하다.)
스스로도 애자일 문화를 도입하면서 이것이 정말 우리 조직에 도움이 되는 것일까 개발 생산성 향상을 가져올 수 있을까 많이 의문을 가졌었다. 그러면서도 스스로 납득을 했던 부분은 이 과정이 더 나은 문화를 만들기 위한 시작이라는 것이었다. 체계적인 개발 문화가 무엇인지 정의하고 그것을 구체화하고 측정하고 개선해 나가기 위한 첫 단계인 것이다.
사실 애자일을 도입하는 과정이 쉽지는 않았는데 생각을 바꾸게 된 순간이 있었다. 바로 구성원들이 다르게 받아들이고 있는 개념들을 동일하게 맞춰야 한다는 것이었다. 비포장도로처럼 생각의 토대가 울퉁불퉁한 상태였기 때문에 앞으로 나갈 수가 없어서, 먼저 그 토대를 평평하게 만들어야 했다. 고객에게 더 자주 가치를 전달하자는 목표에 맞는 지표를 설정하고, 서로 맞추었으면 하는 일 하는 방식이 무엇인지 등을 구체화해서 하나씩 해결하는 게 도움이 되었다.
애자일 문화를 제대로 도입하려면 개발보다도 오히려 앞뒤의 프로세스가 많이 바뀌어야 한다. PO 대상으로 유저 스토리 작성 방법, 스펙을 작게 쪼개는 방법, 스크럼을 진행하는 방법 등에 대한 교육과 코칭을 진행하고, 더 자주 안정적으로 릴리즈하기 위해서는 QA의 방식도 바꾸어야 한다. 개발 완료 후 QA를 진행하는 방법으로는 제품 주기를 단축시키는 데 한계가 있기 때문에, 우리는 스프린트 내 테스트라는 콘셉트를 만들고 오류 발견율 등을 측정해서 지속 개선을 하게 되었다. 이 과정에서 퀄리티에 대한 각 구성원들의 역할과 책임도 변화해야 하고, 테스트 코드와 자동화 테스트에도 관심을 갖게 되었다.
목적 팀이 많아지면 플랫폼 팀의 필요성이 부각된다. 여러 팀들이 일을 잘 하게 도와주는 팀이 필요하기 때문이다. 목적 팀들은 주어진 목적 달성을 위해 달리기 때문에 업무 생산성이나 환경 개선에 많은 시간을 쓰기 어렵고 팀 간에 공통적으로 발행하는 문제나 어느 팀에서도 나서기 어려운 일에 대해 커버를 해줄 전담팀이 필요해진다. 우리는 이걸 플랫폼 팀으로 만들었고, 제품과 기술의 영역에서 플랫폼 팀이 필요하다는 것을 실감하여 만들어 나가고 있다.
또한, 조직이 커지면 채용 계획에 매니저도 포함시키고 내부에서도 적극 키워야 한다. 앞에서 다뤘지만 개발 조직이 빠르게 커지면 매니징에 문제가 생긴다. 따라서, 매니저의 적정 비율을 정해놓고 매니저를 채용하거나 키우거나 하는 노력이 필요하다. 원티드는 8명의 개발자에 1명의 개발 팀장, 5개의 개발 팀에 한 명의 부문장 등으로 가이드를 정해놓고 있는데, 이를 기반으로 채용 계획과 조직 계획을 세우는 데 도움이 된다.
빠른 성장 과정의 고민들
초기 팀부터 50명 규모의 조직에 이르기까지 어떻게 조직을 키워야 하는지에 대해 원티드 경험을 참고로 공유해 보았다. 누구나 하는 얘기지만, 그럼에도 중요한 것은 우리 조직에 맞는 방식을 찾아가는 것이다. 어느 정도 시행착오는 있겠지만 치명적인 시행착오를 피하기 위해서 역시 조금씩 신중하게 변화해나가는 것도 매우 중요하다. (초반의 단계는 과거의 이야기이기 때문에 어느 정도 원칙 중심으로 정리해서 적었다면, 후반부로 갈수록 우리 조직도 현재 진행형의 이야기이기 때문에 사례와 경험을 공유하는 식으로 쓰게 되었다.)
원티드는 이제 겨우 50명 규모까지 왔다. 앞으로도 더 조직이 커져가면 무엇을 해야 할까? 이보다 더 큰 조직의 협업은, 개인이나 개발 문화만으로는 해결이 안 되는 규모가 될 것이다. 그래서 개발 플랫폼을 만들거나, 개발 환경을 잘 구축하는 등 기술적으로 생산성을 높이는 과제들을 정해서 진행해 나가고 있다.
원티드는 계속해서 변화하고 더 나은 것을 함께 찾아가는 조직이다. 아직 다음 단계는 우리 조직도 가보지 않았기 때문에 만약 이 글을 읽는 분 중에 경험이 있거나 도전해 보고 싶다면 원티드에 합류해 주시면 좋겠다. 원티드가 하고자 하는 기술 도전이 궁금하다면 원티드 유튜브 영상(원티드가 그리는 일의 미래)을 참고하자.
끝으로 이와 비슷한 고민과 어려움을 겪고 있는데 해결이 안 돼서 힘들어 하는 분도 많을 거 같다. 원티드 커뮤니티에서 고민들을 함께 나누어 봐도 좋을 것 같고, 주변에 창업자나 같은 포지션에 있는 분에게 연락해서 상담을 적극 요청해 보자. 그동안 고민되는 일이 있을 때 주변에 물어봐서 큰 도움을 얻었다. 마지막으로 원티드가 그동안 성장하는 데 있어서 함께 고생했던 동료들과, 그 과정에서 고민이 되는 순간마다 조언을 아끼지 않고 주셨던 다른 회사의 많은 리더분들에게 감사를 드리고 싶다.
▶ <이 시대의 개발자로 일하기> 시리즈 보러 가기
글ㅣ황리건
필자는 스타트업과 대기업, 외국계 회사, SI 등 다양한 직장에서 엔지니어이자 제품을 만드는 조직의 관리자로 일을 해왔다. 300명 규모의 성장기 네이버에 개발자로 합류하여 2000명까지 성장을 함께 했으며, 이후에는 마이크로소프트로 이직하여 윈도우와 인터넷 익스플로러 개발 플랫폼 출시를 담당하며 국내 다양한 기업 및 개발자 커뮤니티와 협업을 해왔다. 현재는 원티드랩의 공동 창업자로서 채용 및 커리어 플랫폼을 만드는 제품 조직을 이끌고 있다.
발행일 2022.03.23
목적 조직과 개발 문화의 체계화
여러 프로젝트를 연속성 있게 실행하기 위해서는 명확한 목적을 가진 다기능 조직이 필요하다. 우리는 이런 조직을 스쿼드라고 부르고 있다. 스쿼드를 운영하는 데 있어서 핵심은 분명한 목적을 갖고 일하는 문화를 체계화하는 것이다. 목적 팀을 만들어 놓고 영역만 정해주게 되면, 목적을 스스로 정해야 하는데 이것이 쉽지 않다. 또한, 일하는 방식의 체계를 갖추어서 목적 팀이 많아져도 이들이 공유하는 일하는 방식이 있어야 한다.
원티드는 2주 단위로 개발을 하자는 목표 수준을 정하고 애자일 스크럼을 도입하였다. 애자일을 하는 것은 생각보다 깊이 있는 공부가 필요하다. 고객에게 더 자주 가치를 전달한다는 핵심 목표를 달성하기 위해 구성원들이 더 많이 소통해야 한다는 것을 진심으로 깨우쳐야 한다. 또한 유저 스토리를 작성하는 방법이나 백로그 관리, 스프린트 운영 방법 등 하나하나 체계적으로 교육을 받고 배울 필요가 있다. 따라서 원티드는 전문 애자일 코치로부터 컨설팅을 받으면서 교육과 코칭을 받았다. (애자일 도입 시 전문가나 경험자의 도움을 받는 것은 꼭 필요하다.)
스스로도 애자일 문화를 도입하면서 이것이 정말 우리 조직에 도움이 되는 것일까 개발 생산성 향상을 가져올 수 있을까 많이 의문을 가졌었다. 그러면서도 스스로 납득을 했던 부분은 이 과정이 더 나은 문화를 만들기 위한 시작이라는 것이었다. 체계적인 개발 문화가 무엇인지 정의하고 그것을 구체화하고 측정하고 개선해 나가기 위한 첫 단계인 것이다.
사실 애자일을 도입하는 과정이 쉽지는 않았는데 생각을 바꾸게 된 순간이 있었다. 바로 구성원들이 다르게 받아들이고 있는 개념들을 동일하게 맞춰야 한다는 것이었다. 비포장도로처럼 생각의 토대가 울퉁불퉁한 상태였기 때문에 앞으로 나갈 수가 없어서, 먼저 그 토대를 평평하게 만들어야 했다. 고객에게 더 자주 가치를 전달하자는 목표에 맞는 지표를 설정하고, 서로 맞추었으면 하는 일 하는 방식이 무엇인지 등을 구체화해서 하나씩 해결하는 게 도움이 되었다.
애자일 문화를 제대로 도입하려면 개발보다도 오히려 앞뒤의 프로세스가 많이 바뀌어야 한다. PO 대상으로 유저 스토리 작성 방법, 스펙을 작게 쪼개는 방법, 스크럼을 진행하는 방법 등에 대한 교육과 코칭을 진행하고, 더 자주 안정적으로 릴리즈하기 위해서는 QA의 방식도 바꾸어야 한다. 개발 완료 후 QA를 진행하는 방법으로는 제품 주기를 단축시키는 데 한계가 있기 때문에, 우리는 스프린트 내 테스트라는 콘셉트를 만들고 오류 발견율 등을 측정해서 지속 개선을 하게 되었다. 이 과정에서 퀄리티에 대한 각 구성원들의 역할과 책임도 변화해야 하고, 테스트 코드와 자동화 테스트에도 관심을 갖게 되었다.
목적 팀이 많아지면 플랫폼 팀의 필요성이 부각된다. 여러 팀들이 일을 잘 하게 도와주는 팀이 필요하기 때문이다. 목적 팀들은 주어진 목적 달성을 위해 달리기 때문에 업무 생산성이나 환경 개선에 많은 시간을 쓰기 어렵고 팀 간에 공통적으로 발행하는 문제나 어느 팀에서도 나서기 어려운 일에 대해 커버를 해줄 전담팀이 필요해진다. 우리는 이걸 플랫폼 팀으로 만들었고, 제품과 기술의 영역에서 플랫폼 팀이 필요하다는 것을 실감하여 만들어 나가고 있다.
또한, 조직이 커지면 채용 계획에 매니저도 포함시키고 내부에서도 적극 키워야 한다. 앞에서 다뤘지만 개발 조직이 빠르게 커지면 매니징에 문제가 생긴다. 따라서, 매니저의 적정 비율을 정해놓고 매니저를 채용하거나 키우거나 하는 노력이 필요하다. 원티드는 8명의 개발자에 1명의 개발 팀장, 5개의 개발 팀에 한 명의 부문장 등으로 가이드를 정해놓고 있는데, 이를 기반으로 채용 계획과 조직 계획을 세우는 데 도움이 된다.
빠른 성장 과정의 고민들
초기 팀부터 50명 규모의 조직에 이르기까지 어떻게 조직을 키워야 하는지에 대해 원티드 경험을 참고로 공유해 보았다. 누구나 하는 얘기지만, 그럼에도 중요한 것은 우리 조직에 맞는 방식을 찾아가는 것이다. 어느 정도 시행착오는 있겠지만 치명적인 시행착오를 피하기 위해서 역시 조금씩 신중하게 변화해나가는 것도 매우 중요하다. (초반의 단계는 과거의 이야기이기 때문에 어느 정도 원칙 중심으로 정리해서 적었다면, 후반부로 갈수록 우리 조직도 현재 진행형의 이야기이기 때문에 사례와 경험을 공유하는 식으로 쓰게 되었다.)
원티드는 이제 겨우 50명 규모까지 왔다. 앞으로도 더 조직이 커져가면 무엇을 해야 할까? 이보다 더 큰 조직의 협업은, 개인이나 개발 문화만으로는 해결이 안 되는 규모가 될 것이다. 그래서 개발 플랫폼을 만들거나, 개발 환경을 잘 구축하는 등 기술적으로 생산성을 높이는 과제들을 정해서 진행해 나가고 있다.
원티드는 계속해서 변화하고 더 나은 것을 함께 찾아가는 조직이다. 아직 다음 단계는 우리 조직도 가보지 않았기 때문에 만약 이 글을 읽는 분 중에 경험이 있거나 도전해 보고 싶다면 원티드에 합류해 주시면 좋겠다. 원티드가 하고자 하는 기술 도전이 궁금하다면 원티드 유튜브 영상(원티드가 그리는 일의 미래)을 참고하자.
끝으로 이와 비슷한 고민과 어려움을 겪고 있는데 해결이 안 돼서 힘들어 하는 분도 많을 거 같다. 원티드 커뮤니티에서 고민들을 함께 나누어 봐도 좋을 것 같고, 주변에 창업자나 같은 포지션에 있는 분에게 연락해서 상담을 적극 요청해 보자. 그동안 고민되는 일이 있을 때 주변에 물어봐서 큰 도움을 얻었다. 마지막으로 원티드가 그동안 성장하는 데 있어서 함께 고생했던 동료들과, 그 과정에서 고민이 되는 순간마다 조언을 아끼지 않고 주셨던 다른 회사의 많은 리더분들에게 감사를 드리고 싶다.
▶ <이 시대의 개발자로 일하기> 시리즈 보러 가기
글ㅣ황리건
필자는 스타트업과 대기업, 외국계 회사, SI 등 다양한 직장에서 엔지니어이자 제품을 만드는 조직의 관리자로 일을 해왔다. 300명 규모의 성장기 네이버에 개발자로 합류하여 2000명까지 성장을 함께 했으며, 이후에는 마이크로소프트로 이직하여 윈도우와 인터넷 익스플로러 개발 플랫폼 출시를 담당하며 국내 다양한 기업 및 개발자 커뮤니티와 협업을 해왔다. 현재는 원티드랩의 공동 창업자로서 채용 및 커리어 플랫폼을 만드는 제품 조직을 이끌고 있다.
발행일 2022.03.23