개발자 주도 접근법
팀 먼저 꾸리지 마세요.
IT 업계에서는 아직도 맨먼스라는 단위로 개발할 수 있는 양을 측정하고는 한다. 맨먼스는 작업량을 사람으로 계산하는 작업량 측정법으로 한 명이 특정 기간 동안에 작업할 수 있는 양이 있다고 믿는다. '맨먼스 미신'이라는 유명한 책에서 이 신화가 거짓이라는 것을 밝혔음에도 불구하고 아직도 이 생각은 IT업계에서 흔하게 통용되는 듯하다. 이름만 말하면 누구나 아는 큰 회사에서도 어떤 프로젝트를 완료하기 위해 개발자를 더 '투입' 해서 일정을 앞당기려는 시도들도 있다.
맨먼스 접근법은 현실에서 큰 도움이 되지 않는다. 아니 오히려 방해가 된다. 새로운 개발자가 프로젝트에 적응해서 한 사람 몫을 해 내기 위해서 얼마나 노력이 필요한가. 누구나 와서 개발할 수 있을 정도로 비즈니스 로직과 예외사항이 잘 정리되어 있고 한 회사 내에서 컨벤션과 개발 스택을 동일하게 유지해 왔으며 유의해야 할 히스토리도 잘 정리되어 공유가 가능한 상황인가? 백번 양보해서 커뮤니케이션 비용은 제쳐두고라도, 마치 오픈 소스처럼 개발할 수 있는 프로젝트라면 또 모르겠다. 하지만 나는 한 번도 그런 수준의 프로젝트를 경험한 일이 없다.
사이드 프로젝트도 마찬가지다. 왜 처음부터 팀을 꾸리고 프로젝트 참여 인원을 늘리려고 하는가? 단순히 회사에서의 경험을 사이드 프로젝트에도 적용하려는 시도는 아닐까 생각해보자. 앞서 개발자의 로망을 실현하려면 어려운 일은 제쳐두고 오픈부터 하기를 이야기했다. 이 이야기로 사이드 프로젝트에 대한 이야기를 시작했던 까닭은 현실의 사이드 프로젝트는 어려운 일부터 시작하기 때문이다. 사이트 프로젝트의 후기를 찾아보면 함께 뜻이 맞는 기획자, 개발자, 디자이너를 찾고 팀이 꾸려지고서야 사이드 프로젝트를 시작하는 경우가 많다. 마치 RPG 게임의 파티를 꾸리듯이 "IOS 개발자 한 명 구해요"라는 글도 심심치 않게 보인다. 파티 구성이 다 되지 않으면 사냥이 불가능한 것처럼. 하지만 마음 맞는 팀 원 한 명 늘리기는 정말 어려운 일이다.
사이드 프로젝트에서 가장 중요한 것 한 가지를 꼽으라면 '가볍게'를 꼽고 싶다. 프로젝트는 가능한 가볍게 유지해야 한다. 아키텍처도, 개발 스택도, 심지어 기능마저도 유지 관리가 쉬운지 여부가 중요한 판단 기준이 되어야 한다. 그리고 무엇보다 팀을 가볍게 유지해야 한다. 구성원들의 몸무게 관리가 필요하다는 이야기가 아니다. 팀원들의 의견을 맞추는 데만도 많은 시간이 필요하다. '뜻이 맞는 사람'을 구할 수 있다는 것은 환상이다. 마음 맞는 애인 만들기도 힘들 텐데 어디서 뜻이 맞는 기획자와 디자이너를 찾는다는 말인가.
사이드 프로젝트의 어려움 대부분은 사람 관계에서 발생한다. 더욱이 팀을 처음 꾸린다면 확실히 그렇다. 그래서 사람이 많으면 많을수록 많은 일을 하지 못한다. 사이드 프로젝트 특성상 회사와 달리 투입할 수 있는 시간 자체가 한정되어 있다는 것도 원인이다. 퇴근한 후의 피곤한 저녁 시간이나 주말 밖에 낼 수 없는 소중한 사이드 프로젝트의 시간을 커뮤니케이션에 다 써버리고 나면 정작 개발할 시간은 없다. 에너지를 아껴서 빠르게 결과물을 내지 못하면 팀원들은 계속해서 지쳐갈 거고 프로젝트는 실패로 가는 추월차선을 타게 된다. 사람을 늘리는 이유는 원하는 품질이 확보가 되지 않기 때문이어야 한다. 품질을 더 높이기 위해서 내가 하지 못하는 일을 대신해 줄 사람이 필요하다고 판단될 때 마지막으로 고려할 수 있는 선택지다.
품질에 대한 이야기는 사이드 프로젝트의 목표에 관한 이야기이기도 하다. 당신의 목표는 무엇인가. 한 번의 시도로 처음부터 시장에서 성공하는 프로덕트를 기대하고 있는가? 혹은 좋은 동료를 만나서 기획이나 디자인은 고민하지 않고 코딩만 해서 성공하는 프로젝트의 구성원이 되고 싶은가? 나는 기본적으로 사이드 프로젝트를 시작하는 사람이라면 내 서비스를 만들면서 개발의 즐거움을 느끼고 서비스적으로도 개발적으로도 성장하고 싶은 사람이라고 생각한다. 때문에 개발의 즐거움을 되찾고 싶은 사람이라면 기획도, 디자인도, 코딩도 모두 놓아버리지 않았으면 좋겠다.
물론 사이드 프로젝트의 목표를 이 책에서 한정할 수는 없다. 하지만 회사일이 아니라 잃어버렸던 창작욕구를 되찾고 내 서비스를 만들고 싶다면. 어느 분야든 일정 수준의 소양을 가지고 주도적으로 개발 전반에 참여하기를 바란다. 그렇다고 높은 수준의 능력이 필요하지는 않다. 찌그러진 육각형 인재라도 좋으니 새로운 분야라도 며칠 배우고 고민해서 결과물을 낼 수 있다면, 그래서 부끄럽지 않을 수준이라면. 그걸로 충분하다.
개발자 주도 개발법
그렇다면 기획자나 디자이너 없이 어떻게 프로덕트를 만들어낼까? 운 좋게 뜻이 맞는 기획자나 디자이너가 팀에 있거나, 육각형이 균형 잡힌 개발자라면 직접 디자인과 기획을 정리해도 좋다. 하지만 디자인, 기획이 어려운 개발자라면 머릿속에 있는 첫 번째 모델을 바탕으로 코드먼저 작성하자. 거부감이 드는가? 아마 당신은 그동안 큰 회사에서 적응해 개발을 잘해왔던 사람일 거다. 가장 피해야 할 일 중 하나가 요구사항이 정리되기 이전에 코드 작성하기일 텐데. 다른 것보다 코드 먼저 작성하라니?
정석대로 기획과 디자인부터 시작하는 경우 개발 난이도가 높아지는 경우가 많다. 이미 있는 라이브러리로 표현 가능한 수준을 벗어나 커스텀한 코드 작성이 필요하거나, 클라이언트만으로 구현이 불가능해 필수적으로 서버가 필요한 기능이 있을 수도 있다. 이런 경우 빠른 개발을 위해 스펙에서 제외할 수 있겠지만 스펙에서 제외하기 위한 커뮤니케이션 비용이 다시 필요하다. 반대로 개발부터 시작하면 합리적인 비용으로 구현 가능하도록 스펙을 선택할 수 있고, 이를 통해 빠른 길로 서비스를 오픈할 수 있다.
욕심이 생기는 기능이라면 디자인과 기획을 가다듬기 위해 여러 번 작업하게 될 것이다. 하지만 괜찮다. 나중에 바꿀 수 있기 때문에 소프트웨어인 법이다. 개발자에게는 제대로 기획과 디자인을 하는 비용보다 실패를 겪고 여러 번 개발을 하게 되는 비용이 더 적다. 개발자에게는 코딩이 가장 쉽다. 문제가 있을 때 코드로 먼저 문제에 접근하고 점진적으로 개선해 나가는 방법이 바로 개발자 주도 접근법이다. 코딩이 가장 좋은 문제 해결 방법이라서가 아니라 개발자에게 가장 쉽게 접근할 수 있는 방법이기 때문이다.
우리 '딸깍 공방'에는 아직도 개발자밖에 없다. 물론 디자인에 소양이 있는 친구가 있고 기획에 관심 있는 친구가 있지만 언제나 기획과 디자인은 엉성하다. 그래서 제대로 된 기획서도 디자인 가이드도 없다. 하지만 우리가 기대하는 수준의 프로덕트를 만들어내는 데는 문제가 없다. 필요하다면 디자인을 공부하고 기획을 공부한다. 이 과정에서 기획과 디자인에 대해서 얻어가게 되는 인사이트도 많다. 기획 없이 디자인 없이 코딩 먼저하면 왜 기획자와 디자이너가 따로 있는지 절실히 느끼게 될 것이다.
다른 분야에 발을 담가보는 것이 두려울 수 있다. 코딩도 잘 못하는 것 같은데 디자인도 해보라고? 이도저도 아니게 되지 않을까. 다른 사람에게 보여줄 만한 서비스를 만들 수나 있는건가 하고 말이다. 다행히 최근에는 AI가 많은 부분을 대체할 수 있게 되었다. 정말 빠르게 발전하고 있어서 무서울 정도다. 물론 AI가 만들어주는 70점짜리 프레임이 만족스럽지는 않을 거다. 하지만 팀원이 하나 늘어나는 것보다는 훨씬 가성비가 좋다. 그러니 자신감을 가지고 개발 먼저 시작하자. 사이드 프로젝트의 세계에서 살아남기 위해서는 야생의 개발이 필요하다.
