몇 달 전, 웹사이트에 대한 근사한 아이디어가 떠올랐다. 그리고 더 근사한—근사함을 넘어선—아이디어가 뒤따랐다. 웹사이트는 만들되, 모든 작업은 외주로 맡기는 것이다.

모든 위대한 웹사이트는 MVP, 즉 최소 기능 제품(Minimum Viable Product)에서 시작한다. 아이디어를 가장 단순한 형태로 구현해 과연 사람들이 관심을 가질지 시험해 보는 것이다. 트위터가 MVP를 출시했을 때는 러셋 감자 사진만 트윗할 수 있었다. 슬랙은 피그 라틴만 지원하는 것으로 유명하게 출발했다. 넷플릭스는 이제 즉각적인 스트리밍과 동의어가 되었지만, 첫 버전에서는 영화를 고른 뒤 며칠을 기다렸다가 리드 헤이스팅스가 직접 집으로 찾아와 줄거리를 연기해 줘야 했다는 사실을 잊었을지도 모른다.

MVP를 만들기 위한 내 계획은 단순했다.

1. 간단한 설계 문서를 작성한다.
2. 가장 유행하고 가장 앞서나가는 웹 프레임워크에 대해 10년 경력을 가진 록스타 프리랜서 개발자를 찾는다.
3. 해당 프리랜서에게 시간당 4달러를 제안해 사이트 수익을 극대화한다.
4. MVP가 수백만 명의 열정적인 사용자들이 찾아와 제발 돈을 받으라고 아우성치는 번창하는 웹 서비스로 피어나는 모습을 지켜본다.

놀랍게도 이 계획은 통하지 않았다. 나는 지금 2억 달러짜리 실리콘밸리 투베드 아파트에서 이 글을 쓰고 있지 않다. 페이스북의 파격적인 인수 제안으로 헤드라인을 장식하지도 못했다. 대신 평범한 원베드 아파트에서 반쯤 완성된 결과물을 받아 들고, 어쩌다 보니 내 프리랜서의 프리랜서가 되어 이 글을 쓰고 있다.

아이디어

나는 키토 다이어트를 하고 있고 새로운 레시피를 시도하는 걸 좋아한다. 온라인에는 좋은 레시피가 많지만 수십 개의 블로그에 흩어져 있고 구조도 제각각이다. 이런 블로그들은 대개 느리고 탐색하기 어렵다. 키토 블로거들은 웹 개발 경험이 거의 없기 때문이다.

내 아이디어는 키토 레시피 디렉터리인 KetoHub였다. 웹 곳곳에 흩어진 레시피를 모아 하나의 쓰기 편한 웹사이트로 만드는 것이었다.

프리랜서 찾기

KetoHub에서 가장 힘든 작업은 웹 스크래핑이었다. 레시피 블로그를 크롤링해 관련 데이터를 추출하는 일이다. Upwork나 Fiverr 같은 프리랜서 개발자 사이트에서는 흔한 일감이다. 아마 저렴한 가격에 사람을 구할 수 있을 것이다. 하지만 MVP 이후로 계속 개선하려고 할 때 코드가 와르르 무너질 수도 있다.

아, 잠깐! 이 일은 친구 Ferngully에게 딱 맞겠다(그녀는 유치한 가명을 붙이는 조건으로 이 글에 등장하는 것을 허락했다). 그녀는 최근 여행을 위해 직장을 그만뒀지만 며칠 뒤 돌아와 정규직을 찾을 예정이었다. 그 전까지는 프리랜서로 일할 시간이 있을 것이다. 예전에 함께 일해 본 적이 있어 그녀가 실력 있는 개발자이며 우리 호흡이 잘 맞는다는 걸 알고 있었다.

그녀에게 연락했더니 바로 하겠다고 했다. 그녀는 과거에 함께 일하며 내 코드 리뷰가 꼬투리 잡고 징징대는 엄격하다는 걸 알고 있었다. 그녀는 내 까다로운 기준을 맞추는 도전이 기대된다고 말했다.

나는 웹사이트의 구성 요소를 큰 틀에서 정리한 설계 문서를 작성했다. Ferngully는 백엔드 스크래핑 작업을 맡고, 나는 레시피를 보여주는 간단한 웹 프론트엔드를 만들기로 했다.

왜 아직 출시하지 못했나?

처음 Ferngully와 프로젝트를 논의할 때 그녀는 마감 기한이 있는지 물었다. “마감 없음. 그냥 좋은 코드를 작성하는 데 집중해.”

나와 사이드 프로젝트를 하는 모든 개발자에게 늘 하는 말이다. 대충 끼워 맞춘 코드를 월요일에 받는 것보다 목요일에 고품질 코드를 받는 편이 낫다. Ferngully가 맡은 부분은 구현하는 데 30~50시간 정도 걸릴 것으로 예상했다. 일주일이면 끝날 것이다. 내 예상이 빗나가거나 그녀가 주 40시간 미만으로 일한다 해도 두세 주면 될 터였다.

당시 나는 본업 때문에 바쁜 시기였다. 프론트엔드를 만들 시간이 생기려면 몇 달은 걸릴 것 같았다. 병목은 분명히 나였다.

설계 문서를 끝낸 뒤, Ferngully가 스크래핑 코드를 전달했는데 그 코드가 몇 달 동안 서랍 속에 처박혀 있을 모습을 상상하니 김이 샜다. 나는 몇 저녁을 투자해 기본적인 프론트엔드를 만들었다. 직접 손으로 스크래핑한 샘플 레시피를 보여주는 것이었다. Ferngully가 작업을 마치면 전체 레시피 데이터를 넣어 바로 출시할 수 있도록 준비해 둔 셈이었다.

그때부터 불안해지기 시작했다.

웹 부분을 완성하는 데 일주일이 걸렸는데, Ferngully에게서는 아직 코드 한 줄도 오지 않았다. 도대체 뭘 하고 있는 걸까?

프론트엔드를 만들기 전에는 프로젝트가 전혀 스트레스스럽지 않았다. 이제 더미 데이터로 채워진 사이트가 생기니 마치 살아 있는 무언가를 가둬 둔 기분이었다. 하루가 지날 때마다 내 코드는 쓸모를 잃고 낡아 갔다. 나는 어서 KetoHub를 세상에 공개해서 마크 저커버그가 개인정보 수집 슈퍼요트 위에서 샴페인을 대접하며 초대하는 그 단계로 넘어가고 싶었다.

가용 시간이 부족한 상황에서의 작업

Ferngully는 2주차 끝에 첫 번째 코드 리뷰를 보냈다. 첫 번째 백엔드 컴포넌트의 부분 구현이었다. 그녀는 주당 평균 15시간을 작업했지만, 다음 주 월요일부터는 정규직을 시작할 예정이었다. 그 이후로는 작업 시간이 더 줄어들 것이 분명했다.

나는 설계 문서를 다시 살펴보며 뭔가 빼낼 수 있는 게 있는지 확인했다. 원래 설계는 백엔드가 레시피 데이터를 웹사이트의 데이터 스토어에 프로그래밍 방식으로 업로드하도록 되어 있었다. 그녀가 그냥 로컬 파일 시스템에 데이터를 쓰도록 하면 그녀의 작업량을 줄일 수 있을 것 같았다. 그러면 기존 커맨드라인 도구를 이용해 내가 직접 그 데이터를 웹사이트에 업로드하면 되었다.

좋아, 어쩌면 시간이 부족한 게 오히려 잘된 일일지도 모른다. MVP에서 요소를 덜어내고도 같은 목적을 달성할 수 있다면 애초에 최소 형태가 아니었던 셈이니까.

나는 몇 주만 더 하면 마무리할 수 있을 거라 낙관했다.

내 프리랜서의 프리랜서가 되다

안타깝게도 Ferngully의 새 직장은 내가 예상했던 것보다 그녀의 가용 시간을 더 크게 줄였다. 그 다음 한 달 동안 그녀는 KetoHub에 주당 평균 5시간도 채 쓰지 못했다. 이 속도라면 끝내는 데 몇 달이 걸릴 것이었다.

다른 프리랜서였다면 그냥 지금까지의 작업에 감사 인사를 전하고 새로운 개발자를 찾았을 것이다. 하지만 Ferngully는 친구일 뿐만 아니라 새 직장의 스트레스에 적응 중인 친구였다. 더 많은 시간을 요구하거나 프로젝트 계획을 뒤엎어 그녀에게 부담을 주고 싶지 않았다. 그럼에도 마감 기한을 물었을 때 너무 느슨하게 대답했던 내 자신을 자책했다.

그녀의 일 중 일부를 내가 다시 가져올까? 아니, 누군가 나를 고용해 놓고는 직접 해 버리면 나라도 짜증 날 것이다. 설계 문서를 다시 살펴보며 더 단순화할 수 있는지 확인했지만 뺄 만한 게 없었다. 그러다 개발 프로세스를 조정해 시간 비용을 그녀에게서 나에게로 옮길 수 있을지 고민하기 시작했다.

잠깐, 지금 무슨 일이 일어나고 있는 거지? 나는 시간을 아끼려고 KetoHub를 외주했는데, 이제는 내 시간 대신 Ferngully의 시간을 최적화하도록 프로젝트를 재구성하고 있었다. 어떻게 내가 내 프리랜서의 프리랜서가 된 거지?

코드 리뷰 단순화하기

누가 누구를 위해 프리랜서를 하고 있든, 나는 우리가 프로젝트를, 그것도 빨리 끝내기를 바랐다. 줄일 수 있는 가장 큰 시간 비용은 그 유명한 내 까다로운 코드 리뷰였다.

리뷰는 우리 둘 모두에게 비용이 컸다. 나는 코드 리뷰에 많은 공을 들이는 편이었고, Ferngully가 내 제안을 반영하는 데도 시간이 걸렸다. 리뷰 라운드 사이에 며칠, 몇 주가 비게 되니 우리가 어디까지 리뷰했는지 맥락을 기억하는 데만도 시간을 허비하고 있었다.

시간을 아끼기 위해 Ferngully에게 더 이상 코멘트를 달지 않기로 했다. 그녀가 다음 체인지리스트를 리뷰 요청으로 보내왔을 때 나는 그냥 머지한 뒤 내 기준에 맞게 조금 손봤다. 그러자 짠—첫 번째 백엔드 컴포넌트가 완성됐다. 이제 두 개 남았다!

이건 말이 안 된다

Ferngully는 내가 새로 고안한 영리한 시간 절약 기법에 별로 열광하지 않았다. 까다로운 리뷰가 그녀에게는 기술적 성장을 안겨 주었다. 그런 게 없으니 KetoHub는 그냥 일일 뿐이었고, 일은 직장에서 이미 충분히 하고 있었다.

나는 계속 코멘트를 달아야 할지 고민했다. 코멘트를 생략할 때조차 프리랜서를 쓰면서 과연 전체적으로 시간을 아끼고 있는지 확신이 서지 않았다. 다시 코멘트를 달기 시작하면 확실히 시간상 손해였다. 프리랜서에게 적지 않은 시간당 요금을 지불하면서 코드를 직접 작성하는 것보다 더 많은 시간이 드는 셈이었다.

우리는 상의 끝에 Ferngully가 더 이상 KetoHub에서 일하는 건 의미가 없다고 결론 내렸다. 첫 번째 컴포넌트가 완성된 참이라 그녀가 프로젝트에서 빠져나오기에 좋은 시점이었다.

직접 구현하기

Ferngully와 마무리한 뒤 그 주 토요일 밤, 나는 그녀가 멈춘 지점부터 이어서 MVP가 라이브될 때까지 계속하기로 마음먹었다. 새벽 2시까지 첫 버전이 완성됐다. 너무 밋밋해 보여서 부끄러웠지만 어쨌든 완성됐다.

나는 처음부터 혼자 했어야 했다는 걸 금방 깨달았다.

프로토타입은 상충 관계를 두고 내려야 할 수많은 사소한 결정들을 요구한다. 레시피의 10%에만 영향을 주는 버그를 고치는 데 한 시간을 더 쓸까? 어떤 모듈에 자동화된 테스트를 넣어야 할까? 이런 답을 프리랜서에게 미리 명세하는 건 불가능하다. 혼자 작업하면 그냥 직감을 따르면 된다.

직접 만들면 설계의 약점을 고치는 것도 훨씬 쉬워진다. 단 두 명으로 구성된 팀에서도 설계 결함은 높은 마찰 비용을 초래한다. Ferngully가 문제를 발견하면 나에게 확인해야 하고, 내가 설계 문서를 업데이트하면 그녀는 그걸 읽고, 일부 작업을 버린 뒤, 마침내 새로운 설계에 따라 다시 구현해야 한다. 혼자 작업하면 그 모든 과정이 거의 즉시 이루어진다.

마지막으로, 백엔드를 외주함으로써 나는 사업의 핵심 부분을 스스로에게서 가리고 있었다. 직접 웹 스크래핑에 손을 대 보니 KetoHub의 향후 버전에서 활용할 수 있는 레시피 데이터에 대한 아이디어가 떠올랐고, 사이트의 설계 제약에 대해서도 더 잘 이해하게 됐다.

교훈

문제가 있었음에도 이 과정은 새로운 웹사이트를 만들고 프리랜서와 일하는 것에 대해 중요한 교훈을 남겼다. 가장 큰 교훈은 이것이었다. 개발자라면 직접 MVP를 만들어라.

프리랜서와 함께 일하기로 했다면:

• 목표 완료일을 논의하라.
  • 엄격한 마감 기한을 정할 필요는 없지만, 애초에 비슷한 시간 감각을 공유하고 있는지 확인하라.
• 주간 가용 시간을 합의하라.
  • 프리랜서는 다른 클라이언트나 우선순위를 가지고 있을 수 있다. 당신의 프로젝트에 얼마나 많은 시간을 할애할 수 있을지 파악하라.

이 글은 Samantha Mason이 편집했습니다.

새로운 레시피를 찾는 데 관심 있는 키토 다이어터라면, 이 글 내내 이야기한 웹사이트인 KetoHub를 확인해 보세요.