몇 달 전, 나는 웹사이트에 관한 기막힌 아이디어를 떠올렸다. 그러고는 훨씬 더 기막힌 아이디어를 냈다. 웹사이트는 만들되, 일은 전부 외주를 맡기는 거였다.

훌륭한 웹사이트는 모두 MVP, 즉 최소 기능 제품에서 시작한다. 아이디어를 가장 단순한 형태로 구현해 사람들이 관심을 보이는지 시험하는 것이다. Twitter가 MVP를 출시했을 때는 러셋 감자 사진만 트윗할 수 있었다. Slack은 처음 출시했을 때 언어 지원이 피그 라틴어로 제한되어 있었던 것으로 유명하다. 지금은 Netflix 하면 즉시 스트리밍이 떠오르지만, 첫 버전은 영화를 고른 뒤 며칠을 기다리면 리드 헤이스팅스가 집에 찾아와 직접 줄거리를 연기해 주는 서비스였다는 사실은 아마 잊었을 것이다.

내가 세운 MVP 제작 계획은 간단했다.

1. 간단한 설계 명세를 작성한다.
2. 가장 유행하고 최첨단인 웹 프레임워크를 10년간 다뤄 온, 실력 끝내주는 프리랜서 개발자를 찾는다.
3. 사이트 수익을 극대화할 수 있도록 그 프리랜서에게 시간당 4달러를 제시한다.
4. MVP가 번창하는 웹 서비스로 자라나 수백만 명의 열성 사용자가 몰려들고, 내가 돈을 받아 달라고 요구하는 모습을 지켜본다.

이 계획이 실패했다는 사실을 알면 놀랄지도 모르겠다. 나는 2억 달러짜리 실리콘밸리의 호화로운 방 2개짜리 아파트에서 이 글을 쓰고 있지 않다. Facebook의 파격적인 인수 제안으로 헤드라인을 장식하지도 못했다. 대신 평범한 방 하나짜리 아파트에서, 반쯤 완성된 제품을 넘겨받고 어쩌다 보니 내 프리랜서의 프리랜서가 된 뒤 이 글을 쓰고 있다.

아이디어

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

내 아이디어는 키토 레시피 디렉터리인 KetoHub였다. 웹 곳곳에 흩어진 레시피를 한데 모아 사용하기 쉬운 웹사이트로 만드는 것이다.

프리랜서 찾기

KetoHub에서 가장 손이 많이 가는 작업은 웹 스크래핑, 즉 레시피 블로그를 돌아다니며 관련 데이터를 가져오는 일이었다. Upwork나 Fiverr 같은 프리랜서 개발자 사이트에서는 흔히 볼 수 있는 작업이다. 아마 저렴한 가격에 누군가를 구할 수 있겠지만, MVP를 넘어 계속 개선하려고 하면 코드가 산산이 부서질 수도 있다.

아, 잠깐! 이건 내 친구 Fern­gully에게 딱 맞는 일이었다. (내가 그녀에 대해 글을 쓰되 우스꽝스러운 가명을 쓰는 조건으로 허락을 받았다.) 그녀는 최근 직장을 그만두고 여행을 떠났지만, 며칠 뒤 돌아와 정규직을 구할 예정이었다. 그동안에는 프리랜서 일을 할 시간이 있을 것 같았다. 우리는 예전에 함께 일한 적이 있어서, 그녀가 실력 좋은 개발자이고 서로 호흡도 잘 맞는다는 걸 알고 있었다.

나는 그녀에게 연락했고, 그녀는 곧바로 함께하겠다고 했다. 예전에 같이 일해 본 덕분에 내 코드 리뷰가 꼬투리 잡고 징징대는 엄격하다는 것도 알고 있었다. 그녀는 내 까다로운 기준을 충족하는 일이 도전적이라 기대된다고 말했다.

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

그런데 왜 아직 서비스가 시작되지 않았지?

처음 Ferngully와 프로젝트 이야기를 나눌 때, 그녀는 마감 기한이 있느냐고 물었다. “마감 기한은 없어. 좋은 코드 작성에만 집중해 줘.”

나와 사이드 프로젝트를 함께하는 개발자라면 누구에게나 하는 말이다. 월요일에 급하게 대충 짜인 코드보다 목요일에 완성도 높은 코드를 받는 편이 낫다. Ferngully가 맡은 부분은 구현에 30~50시간 정도 걸릴 거라고 예상했다. 일주일이면 끝날 일이었다. 내 예상이 빗나가거나 그녀가 주 40시간보다 적게 일한다면 두세 주 정도 걸릴 수도 있었다.

당시 나는 본업이 바쁜 시기를 보내고 있었다. 프런트엔드를 만들 시간이 나려면 몇 달이 걸릴 수도 있었다. 병목은 분명 나일 터였다.

설계 문서를 작성하고 나니, Ferngully가 스크래핑 코드를 완성해 줘도 그 코드가 몇 달 동안 서랍 속에 처박혀 있게 된다면 얼마나 김빠질지 생각하게 됐다. 그래서 며칠 저녁을 투자해 기본적인 프런트엔드를 만들었다. 손으로 직접 스크래핑한 샘플 레시피를 보여 주는 정도였다. Ferngully가 작업을 끝내는 즉시 전체 레시피 데이터를 추가하고 출시할 수 있는 상태가 될 터였다.

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

웹 부분을 완성하는 데는 일주일이 걸렸지만, Ferngully의 코드는 아직 하나도 보지 못했다. 대체 뭘 하고 있는 걸까?

프런트엔드를 만들기 전까지는 프로젝트가 아무런 부담 없이 진행됐다. 그런데 더미 데이터가 들어간 사이트를 완성하고 나니, 살아 있는 무언가를 만들어 놓고 우리 손으로 우리 안에 가둬 둔 기분이 들었다. 하루하루 지날수록 내 코드는 낡아 쓸모없어져 가고 있었다. 나는 그저 KetoHub를 세상에 공개해, 마크 저커버그가 개인 정보 수집용 초대형 호화 요트에서 샴페인을 대접하는 이 과정의 다음 단계로 빨리 넘어가고 싶었다.

가용 시간이 부족한 상태에서 일하기

두 번째 주가 끝날 무렵, Ferngully가 첫 코드 리뷰를 보냈다. 백엔드 첫 번째 구성 요소를 일부 구현한 코드였다. 그녀는 주당 평균 15시간을 투자했지만, 다음 월요일부터 정규직으로 일하기 시작할 예정이었다. 그 뒤로는 작업 시간이 확실히 더 줄어들 터였다.

나는 설계 문서를 다시 살펴보며 뺄 수 있는 부분이 있는지 확인했다. 백엔드가 프로그래밍 방식으로 레시피 데이터를 웹사이트의 데이터 저장소에 올리도록 되어 있었다. Ferngully가 데이터를 로컬 파일 시스템에만 기록하게 하면 그녀가 할 일을 줄일 수 있었다. 그러면 내가 기존 명령줄 도구를 사용해 그 데이터를 웹사이트에 올리면 된다.

좋아, 어쩌면 시간이 제한된 게 잘된 일일지도 몰랐다. MVP에서 일부 요소를 덜어 내고도 같은 결과를 얻을 수 있다면, 애초에 가장 최소한의 형태로 만든 게 아니었던 셈이니까.

몇 주만 더 지나면 마무리할 수 있으리라는 낙관적인 생각이 들었다.

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

안타깝게도 Ferngully의 직장은 내가 예상했던 것보다 그녀의 시간을 훨씬 더 많이 빼앗았다. 그다음 한 달 동안 그녀가 KetoHub에 투자한 시간은 주당 평균 5시간도 되지 않았다. 이 속도라면 완성까지 몇 달은 걸릴 터였다.

다른 프리랜서였다면 작업해 준 것에 감사하다고 말하고 새 개발자를 찾았을 것이다. 하지만 Ferngully는 내 친구였고, 새 직장 때문에 스트레스를 받고 있는 친구였다. 더 많은 시간을 내 달라고 압박하거나 프로젝트 계획을 전면 수정해서 그녀의 부담을 늘리고 싶지 않았다. 그래도 마감 기한을 물었을 때 내가 처음에 너무 느슨하게 대응했던 건 계속 후회스러웠다.

그녀가 하던 일 일부를 내가 맡으면 될까? 아니, 누군가가 나를 고용해 놓고 그 일을 직접 해 버린다면 나라도 짜증 날 것이다. 설계 문서를 다시 살펴보며 더 단순화할 방법을 찾아봤지만, 더 뺄 수 있는 부분은 없었다. 그러다 개발 프로세스를 조정해 시간 부담 일부를 그녀에게서 나에게 옮길 수 있을지 생각하기 시작했다.

잠깐만. 지금 무슨 일이 벌어지고 있는 거지? 시간을 아끼려고 KetoHub를 외주 맡겼는데, 이제는 내 시간이 아니라 Ferngully의 시간을 최적화하는 방향으로 프로젝트를 재구성하고 있었다. 내가 어떻게 내 프리랜서의 프리랜서가 된 걸까?

코드 리뷰 간소화하기

누가 누구의 프리랜서였든, 나는 프로젝트를 빨리 끝내고 싶었다. 내가 줄일 수 있는 가장 큰 시간 부담은 악명 높은 내 까다로운 코드 리뷰였다.

코드 리뷰는 우리 둘 모두에게 큰 부담이었다. 나는 코드 리뷰에 많은 생각을 쏟았고, Ferngully가 내 제안을 반영하는 데도 시간이 걸렸다. 리뷰 라운드 사이에 며칠 또는 몇 주씩 지연이 생기다 보니, 리뷰가 어디까지 진행됐는지 맥락을 다시 기억하는 데에도 시간이 들었다.

시간을 아끼기 위해 Ferngully에게 더는 피드백을 남기지 않기로 했다. 그녀가 다음 변경 목록을 리뷰용으로 보내 왔을 때, 나는 그대로 병합한 뒤 내 기준에 맞도록 조금 손봤다. 그러자 짠, 첫 번째 백엔드 구성 요소가 완성됐다. 이제 두 개만 남았다!

이건 말이 안 된다

Ferngully는 내가 고안한 영리한 새 시간 절약 기법을 그다지 반기지 않았다. 까다로운 리뷰를 받는 과정이 그녀의 기술적 성장에 도움이 됐기 때문이다. 그런 리뷰가 없다면 KetoHub는 그저 일이었고, 그녀는 직장에서 이미 일이라면 충분히 하고 있었다.

계속 피드백을 작성할 수 있을지 고민했다. 피드백을 건너뛰고 있을 때조차 프리랜서를 쓰는 것이 전체적으로 정말 시간을 아끼는 일인지 확신할 수 없었다. 다시 피드백을 쓰기 시작하면 시간 면에서는 확실히 손해였다. 프리랜서에게 적지 않은 시간당 비용을 지불하면서, 정작 내가 직접 코드를 작성하는 것보다 더 많은 시간을 들이게 될 터였다.

우리는 이야기를 나눈 끝에 Ferngully가 KetoHub를 계속 작업하는 것은 더 이상 합리적이지 않다고 결론 내렸다. 첫 번째 구성 요소가 완성된 시점이라 그녀가 프로젝트에서 빠지기에도 적절했다.

직접 구현하기

Ferngully와의 작업을 마무리한 그 토요일 밤, 나는 그녀가 멈춘 지점부터 이어서 작업하며 MVP가 출시될 때까지 계속하겠다고 마음먹었다. 새벽 2시가 되자 첫 번째 버전이 완성됐다. 너무 밋밋해 보여서 부끄러웠지만, 어쨌든 끝난 것이다.

처음부터 혼자 프로젝트를 진행했어야 했다는 사실을 곧 깨달았다.

프로토타입을 만들 때는 트레이드오프와 관련해 사소한 결정을 아주 많이 내려야 한다. 레시피의 10%에만 영향을 주는 버그를 고치는 데 한 시간을 더 쓸 것인가? 어떤 모듈에 자동화 테스트를 적용할 것인가? 이런 답을 미리 프리랜서에게 모두 명세하는 것은 불가능하다. 혼자 작업하면 그냥 직감에 따라 결정하면 된다.

직접 만들면서 설계의 약점을 고치는 일도 훨씬 쉬워졌다. 두 명뿐인 팀에서도 설계 결함은 큰 마찰 비용을 발생시킨다. Ferngully가 문제를 발견하면 나에게 확인해야 하고, 나는 설계 문서를 수정해야 하며, 그녀는 문서를 읽고 일부 작업을 버린 다음 새 설계에 맞춰 다시 구현해야 했다. 혼자 작업할 때는 이 모든 과정이 거의 즉시 끝난다.

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

배운 점

여러 문제가 있었지만, 이 과정에서 새로운 웹사이트를 만들고 프리랜서와 일하는 데 관한 중요한 교훈을 얻었다. 가장 큰 교훈은 이것이다. 개발자라면 자신의 MVP는 직접 만들어라.

프리랜서와 함께하기로 했다면 다음 사항을 지켜라.

• 목표 완료일을 논의하라.
  • 딱딱한 마감 기한을 정할 필요는 없지만, 처음부터 서로 비슷한 일정을 생각하고 있는지는 확인해야 한다.
• 주간 작업 가능 시간을 합의하라.
  • 프리랜서에게는 다른 고객이나 우선순위가 있을 수 있다. 프로젝트에 얼마나 많은 시간을 할애할 수 있는지 확인하라.

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

새로운 레시피를 찾고 있는 키토 다이어터라면, 이 글 전체에서 이야기한 웹사이트 KetoHub를 확인해 보세요.