어떻게 모이고 무엇을 만들 것인가, Part 1

김재석 shinvee@lunant.net 현재 Lunant 야간개발팀을 운영하며 취향 공유 서비스 VLAAH(http://vlaah.com/)를 만들고 있다. 좋은 서비스를 즐겁게 개발할 수 있게 도와주는 개발 방법론에 관심을 두고 있다. 2009년 11월 10일

독립개발팀을 만들겠다는 결심은 했는데, 이를 어떻게 구체적으로 실행에 옮길지도 역시 상당히 중요한 고민거리이며, 많은 사람이 이 부분에서 고민이 많을 것이다. 이번 칼럼에서는 초기 팀 모집부터 작업을 시작하는 데까지 필요한 구체적인 고민의 해결책을 소개하는 내용으로 채워보려고 한다.

몇 명으로 시작하면 좋을까?

가능하다면, 시작할 때는 프로젝트당 2명에서 3명 정도가 가장 적절하다고 생각한다. 팀원이 4명 이상이 되면 팀을 관리하는 데 드는 고민이 꽤 커지기 때문이다. 보통 한 애플리케이션을 개발할 때 작업 영역을 2~3개로 분리하기 쉬운 것도 그 이유 중 하나다. 많은 스타트업이 개발자 3명으로 창업하며, 미국의 초기 펀딩 업체로 유명한 YCombinator^[1]의 수장인 폴 그레이엄도 2명 이상, 4명 이하의 인원 구성을 추천한다.^[2] 물론 그렇다고 이미 들어온 사람을 자를 필요는 없지만, 참여 인원이 많다면 프로젝트를 여러 개로 분리하는 것으로 조정하는 편이 좋다.

팀원 중에 전문 기획자가 있는 것은 어떤가?

필자는 회사가 아닌 형태에서 전문 기획자가 소규모 팀에 있는 것을 별로 좋아하지 않는다. 첫째로, 팀이 크지 않은 이상 기획자가 만들어내는 기획의 양을 개발자가 따라가지 못한다. 그렇다고 개발자의 규모에 맞게 기획을 한다면 반대로 기획자가 할 일이 없어 개발 중엔 아무 일도 하지 않게 된다. 회사의 형태라면 조그만 기획이라도 비교적 엄격한 기준에서 개발되어야 하고, 투자 유치 등 다방면에서 서비스에 대한 기획 자료가 다량으로 필요하기 때문에 전문 업무가 필요하지만, 소규모 팀에서는 그럴 일이 별로 없기 때문이다.

기획에 비중을 많이 두고 싶어하는 팀원이 있거나 그래야 할 상황이라면, 팀에서 개발에 직접 참여할 수 있는 공부를 일부 겸해둘 것을 추천한다. 개발을 하다 보면 귀찮다거나, 오해가 생기거나 하는 일로 세세한 사항이 원래 의도와 다르게 만들어지는 경우가 있는데, 이런 것들 일부를 직접 수정할 수 있다면 어디서든 사랑받는 기획자가 될 것이다. 예를 들어, 웹 애플리케이션을 개발한다면 적어도 HTML 코딩 정도는 기획자가 해줄 수 있는 것이 여러모로 도움이 많이 되고, 게임 개발 쪽이라면, 루아(Lua)처럼 스크립트로 자주 쓰이는 언어의 문법을 알아두는 것이 되겠다.

조금 못하는 친구가 좋을까? 잘하지만 모르는 사람이 좋을까?

둘 다 장단점이 있다. 모르는 사람과 할 때는 아무래도 잘 아는 사람과 할 때보다 모임에 긴장이 있기 때문에, 모임 분위기가 평균 이상의 집중력을 가질 수 있다. 하지만, 필자는 친한 사람이나 주변에 잘 아는 사람들과 시작하는 것을 되도록 추천한다. 여러 사람과 함께 일할 때는 개개인의 능력보다 가치관이 맞는지 여부가 더 중요하기 때문이다. 당장 무엇을 만들 것인지를 결정하는 때부터 완전히 어긋나기 시작하면 제대로 된 활동을 진행하리란 기대는 접는 것이 좋다.

잘 모르는 사람과 일을 할 때 자주 난감해지는 부분이 바로 잠적이다. 많은 사람이 일이 좀 힘들어지면 도망치고 싶어하는데, 잘 모르는 사람이면 연락이 닿지 않을 때 이를 찾아내기가 어렵다. 반면 친한 사람이라면 서로 잠적하기가 쉽지 않으니 이런 면에선 전체적인 책임감이 더 높은 경향이 있다. 실제로, 모르는 사람과 팀을 결성할 때 잠적 때문에 팀이 와해되는 경우가 상당히 많으므로 연락 정보를 다양하게 교류해 놓을 필요가 있다.

여담이지만, 학교와 같은 공동체 안에서 팀을 조직하면 다양한 지원을 받을 수 있다. 동아리 지원, 세미나실 지원, 종종 스터디 모임 지원을 해주는 학교도 있다. 이러한 지원을 잘 활용하면 적은 돈으로 상당히 괜찮은 환경을 구축할 수 있는데, 특히 모임 장소나 그에 대한 비용 지원은 팀 활동에 있어서 대단히 큰 차이를 만들기 때문에 이 부분을 다방면으로 미리 알아두는 것이 좋다.

경험도 없고 부담도 되는데, 처음에 무엇을 만드는 것이 좋을까?

목적은 언제나 공부용 수준 애플리케이션보다는 실질적으로 많은 사람에게 도움을 줄 수 있는 애플리케이션을 만드는 것으로 설정하는 것이 더 좋다. 이는 과정상 조금 부담될 수 있으나 직접 이용함으로 얻는 보람이 훨씬 크기 때문이다. 공개하지 않는 단순 공부용 애플리케이션은 개발 부담은 좀 덜 수 있어도 난생 처음 프로그램을 만드는 것이 아니라면 대부분 큰 보람을 느끼지 못한다.

일단 처음이고 비교적 팀의 활동 계획이 장기적이라면, 가장 적절한 것은 팀원들이 사용할 그룹웨어다. 먼저 내부적으로만 이용하기 때문에 세세한 품질에 신경 쓰지 않아도 되어서 심리적인 부담이 적다. 또한, 스스로 사용할 애플리케이션을 개발하면서 위기지학(爲己之學)^[3]을 실천하니 다음 애플리케이션을 개발할 때 더 올바른 아이디어를 선택하는 데 있어 좋은 밑거름이 된다.

예를 들어, 할 일(TODO) 목록 서비스는 연습용으로 만들기도 아주 좋을 뿐더러 활용도도 매우 높은 애플리케이션이다. 또 팀마다 고유의 일정 관리 철학에 맞춰 쓰기 좋은 인터페이스를 꾸밀 수도 있을 것이다.

아이디어는 어떻게 선정하지?

사실 여러 사람과 만들면서 가장 어려울 수도, 가장 간단할 수도 있는 부분이 이 부분이다. 필자는 여기서 골치 아프지 않으려면 되도록 한 명이 중심 아이디어를 정하고 나머지 팀원이 이에 동의하는 방식으로 가는 것을 추천한다.

개발 중 생기는 세세한 이슈들은 여러 사람의 머리로 해결하는 것이 대체로 낫지만, 처음 방향은 한 명의 머리에서 정하는 것이 시간을 줄이고 괜한 자존심 싸움을 없앨 수 있기 때문이다. 아무것도 정해지지 않았거나 모두의 머리로 무언가를 정해야 한다면 너무 갈래의 범위가 넓어서 이를 수렴하기 난감하다. 할 수 있다면, 처음 팀원을 조직하는 사람이 미리 아이디어를 정해놓고 조직하는 것이 가장 이상적이다. 야간개발팀에서 개발한 VLAAH^[4]의 경우, 필자가 중심 아이디어로 한 명을 끌어들이고, 두 명이 함께 프로토타입을 만든 다음 이것으로 나머지 팀원을 모았다.

한 명에게 기본 아이디어의 선택권을 주었다면, 그 다음으로 중요한 것은 되도록 그 친구를 믿어주는 것이다. 정말 기발하고 멋진 아이디어가 여러 사람이 적극적으로 개입하는 바람에 '그저 그런' 물건이 되는 경우를 자주 보아왔다. 기획적으로 이상한 부분이 있다면, 애플리케이션 이용자가 직접 판단을 내려줄 것이다.

요약

팀원을 구성하는 데 있어서, 초기에는 되도록 3명을 넘지 않는 선에서 조직하는 것이 좋다. 이보다 크면 관리 비용이 커지기 때문이다. 회사의 형태가 아니라면 가급적 팀원은 개발자 위주로 구성하는 것이 효율적이다. 팀원은 되도록 실력이 미숙해도 가치관이 잘 맞는 열정 있는 친구들이 대개 모르는 사람보다 조직을 이끌어 나가는 데 있어 큰 도움을 주는 편이다. 가장 처음 만들기 좋은 것은 팀원들이 함께 사용할 그룹웨어인데, 이는 직접 사용하면서도 만들기가 비교적 쉽기 때문이다. 아이디어의 차이 때문에 생기는 어려움을 피하려면 기초 아이디어는 한 사람이 결정하는 것이 좋다.

다음 회에선 독립 개발팀에서 개발하기 좋은 애플리케이션 형태를 소개하겠다.

주

^[1]http://ycombinator.com
^[2]How to Start A Startup에서 People 섹션.
^[3]위기지학에 관련해서는 김창준 님이 쓴 글이 유명하다.
^[4]11월 중에 오픈하는 야간개발팀의 서비스.

mar.gar.in

naver

eolin

del.icio.us

위로

[지난 developerWorks Column 보기]