서평: 큰 문제는 작은 문제로 쪼개고 단계별로 해결한다. 컴퓨터공학의 분할 정복 알고리즘이다. 이 알고리즘은 현실의 문제를 해결하는데 많은 도움이 된다. 특히 내가 개발할 때도 이를 많이 사용한다.

개발을 시작하기 전에 요구사항을 확인하고 테크스펙을 작성한다. 이는 최초의 검증이다. 몇일 혹은 몇주 동안 개발하기 전에 최초의 검증을 시작한 것이다.

아이디어는 정말 유용한건지(고객이 원하는지, ROI가 나오는지 등), 구현 가능한 개발인건지, 요구사항에 맞게 설계를 했는지 등등 문서를 작성한다.

그 다음으로 지라로 업무 티켓을 만든다. 사용자 입장에서 기능을 정의하고 스토리 타입의 티켓을 만들고 하위에 여러 개발 티켓을 만든다.

API 인터페이스, Table 설계, 세부 개발 사항등 여러 티켓을 쪼갠다. 쪼개면 일찍 그리고 자주 검증할 수 있다. 2주간 개발한 10,000줄의 코드 리뷰를 요청 받는 것 만큼 황당한 일도 없을 것이다.

코드가 몇줄인지가 중요하기 보단, 리뷰에는 중요한 하나의 목적이 있어야 한다. 이렇게 API 인터페이스를 만들었을 때 변화에 유연한지 혹은 명확한지 (일주일 지나고 프론트엔드에서 다시 봤을 때 헷갈리는 부분이 없을지) 등을 본다. 왜 좋은 코드 리뷰를 요청해야하고, 어떻게 코드 리뷰를 만들 수 있는지는 여기서 말하면 길어지니까 생략한다.

책에 내 생각과 다른 부분도 있었다. A/B 테스트 대상을 정할 땐 시간이 가장 제한적인 자원이라는 점을 기억해야하기 때문에, 실제로 중요한 차이를 내는지 파악해야한다. 트레이드오프를 고려해야한다는 말이다.

구글이라면 아주 사소한 세부사항도 테스트할 여유가 있다. 검색 결과 링크에 41가지 파란색 중 어떤 색을 쓸지 분석하여 가장 적합한 색상을 골랐고 그결과 광고 수익이 연간 2억 달러가 증가했다.

또한 구글은 유의미한 차이를 알아낼 정도로 충분한 트래픽이 있는 회사이고, 2024년 3분기 기준 약 105조 4천억의 매출이 발생했는데 여기서 0.01%의 추가 수익을 만들어낸다면 4백억의 수익 개선이 가능한 회사다. 하지만 대부분의 스타트업은 시간과 트래픽 면에서 엄두도 못 낼 만큼 큰 비용이 든다.

일찍 그리고 자주 검증하기의 중요성을 고려할 때 주의해야 할 일반적인 안티패턴은 1인 팀인데, 이런 측면에서도 좋지 않고 다른 위험도 존재한다. 나도 느끼지만 혼자 일할 때 나쁜 점이 많다. 어려움이 생기면 사기가 저하되고, 추진력과 사기를 유지하기 어렵다.

실천 사항

  • 노력을 일부 할애해서 지금 내가 하는 작업이 효과가 있을지 데이터를 모으고 검증할 수 있을지 생각해보자. 아래 예시처럼 다양한 방법이 있다.

드롭박스: MVP로 4분 짜리 짧은 비디오를 제작해서 베타 메일링 리스트 등록자가 5,000명에서 75,000명으로 늘어났다.

42플로어: 8개의 포토샵 목업을 HTML로 변환한 뒤 가짜 페이지로 보내는 광고를 통해 사무실 투어를 요청한 방문자 비율 측정 후 가장 우수한 버전을 구현했다. 결국 원하던 수준의 전환율을 달성했다.

아사나: ‘구글로 가입하기’ 가짜 버튼을 만들어 클릭률을 측정하여 작업에 착수했다.

책 내용

1인 프로젝트의 성공 가능성을 높이는 몇 가지 전략을 소개한다.

  • 피드백을 개방적으로 수용하라
  • 코드를 일찍, 자주 커밋하라.
  • 코드 리뷰를 철저한 비평가에게 부탁하라.
  • 팀원들에게 아이디어에 대한 반응을 요청하라
  • 새로운 시스템의 인터페이스나 API부터 설계하라
  • 코드에 에너지를 쏟기 전에 설계 문서를 공유하라
  • 최대한 팀원들과 맥락을 공유할 수 있게 프로젝트를 구조화하라
  • 논란의 여지가 있는 기능이라면 너무 많은 시간을 투자하기 전에 승인을 요청하라.

핵심 요약

  • 반복적인 방식으로 문제에 접근하여 노력의 낭비를 줄여라.

매 개발 주기는 새로운 아이디어를 검증할 기회다. 빠르게 반복하고 빠르게 배워라.

  • 소규모 검증으로 대규모 구현의 위험을 줄여라.

노력의 일부를 투자해서 계획의 나머지 부분이 실행할 가치가 있는지 알아내라.

  • A/B 테스트를 활용해서 제품 가설을 끊임없이 검증하라.

제품을 점진적으로 개발하고 효과가 없는 요소를 구별해 나가다 보면 여러분의 노력이 사용자가 실제로 원하는 결과로 이어질 가능성이 커진다.

  • 1인 프로젝트를 할 때는 정기적으로 피드백을 구할 방법을 찾아라.

고립된 상태에서 일하는 것이 쉽고 편할 수 있지만, 미리 발견했더라면 엄청난 노력의 낭비를 막을 수 있었을 무언가를 간과할 위험이 크다.

  • 자신의 의사 결정을 검증하는 자세를 갖춰라.

중요한 의사 결정을 내린 후 그냥 넘어가지 말고 데이터를 수집하고 작업의 가치와 효과를 평가할 피드백 과정을 만들어라.