확장하지 않는 제품 만들기

최근 우리가 잘 아는 성공한 프로덕트들이 초기에 기술적으로 어떻게 “확장하지 않는 일”을 하면서 제품 문제를 해결했는지에 대한 영상을 봤는데, 흥미로운 내용이 많아 한번 정리해봤다.

Gmail

• 문제: 서버 용량이 부족했음
• 해결책: 한명의 지메일 가입자에게 4명 더 초대할 수 있는 invite을 주는 식으로 확장함(요즘 생각하는 바이럴을 위한 growth hack이 아니라 가입자 폭증을 방지하기 위한 장치였음)

Facebook

• 문제: 처음에 대학 소셜네트워크로 시작했을 때, 유저 증가 속도가 너무 빨라서 하나의 유저 테이블을 계속 확장하는게 불가능했음
• 해결책: 새로운 학교로 런칭할 때마다 기존 코드를 복붙하면서 웹서버, DB서버를 학교마다 따로 셋업하는 식으로 확장함(하버드/예일/스탠포드 서버가 다 따로 있는 식). 그러다 나중에 유저들이 다른 학교끼리 왔다갔다 할 수 있는 기능을 만들었고, 그 후 몇 년이 지나서야 하나의 테이블에 전체 유저 데이터를 통합할 수 있었음

Twitch

• 문제: 유명 연예인이 스트리밍을 할 때면 평소 20x 정도의 트래픽에 대비해야 했는데, 스트리밍에 접속한 유저들 이름이나 조회수 같은 정보를 실시간으로 가져오려면 서버가 죽는 상황이었음.
• 해결책: 영상은 실시간으로 보여주고, 유저네임이나 조회수 정보는 임의의 값을 사용하는 페이지를 만들어서 전부 실시간인 것처럼 보이게 함

Myspace

• 문제: 로그인했을때 내 친구의 친구인 사람들 목록을 보여주려고 함
• 해결책: 당시 비슷한 소셜네트워크였던 Friendster에서는 엔지니어들을 고용해서 이를 기술적으로 해결하려고 애쓴 반면, Myspace는 친구목록에 있으면 친구라고, 아니면 “your extended network”에 있다는 문구를 띄우는 걸로 대체

Instagram(다른데서 본 일화인데 비슷한 맥락이라 추가)

• 문제: DB서버를 하나만 띄웠는데 가입자가 폭증하면서 터져버림
• 해결책: 처음엔 멋있는 최신 기술을 이용해 데이터를 여러 DB로 자동 분산하려고 몇 달동안 시도해봤지만 잘 안됨. 결국 DB서버 하나를 새로 띄우고 유저ID가 짝수면 첫번째 서버로, 홀수면 두번째 서버로 보내는 식으로 작업했더니 2시간 만에 해결됨

우리도 디스콰이엇을 만드는 과정에서 비슷한 고민을 계속 하고 있다. 특히 새로운 기능을 개발할 때 ‘어디까지 끊어서 만들어야 하지?’, ‘다른 서비스는 어디까지 고려했지?’ 등을 고민하면서 제품 완성도와 개발 속도 사이에서 적절한 균형을 찾아나가는 중인데, 이 과정에서 딜레마가 자주 발생한다. 크게 두 가지 이유에서인것 같다.

1) ‘어디까지 막 만들어도 괜찮은지’에 대한 기준이 모호함

이전에 프로덕트를 만들 때 ‘일단 만들고 나중에 수습하자'는 식으로 했다가 다 갈아엎어야 했던 적이 있어서, 이번에 디스콰이엇은 처음부터 확장 시나리오를 어느 정도 그려가면서 체계적으로 만들려고 노력했었다. 결과적으로 예상대로 확장한 부분도 있지만 그렇지 못한 부분도 많은데, 다시 생각해봐도 1년 전에 이런 것들을 미리 예측할 수는 없었다. 결국 제품이 커가면서 기술 부채가 생기는 건 어느 정도 필연적이란 얘기다.

그래서 최근엔 새로운 기능을 만들기 전에 미리 확장성을 걱정하기보다는, 일단 빨리 만들어보고 중간중간 어떻게 다듬을지에 대한 고민을 더 많이 하게 되었다. 어차피 처음부터 모든걸 완벽히 설계하는건 불가능하고, 문제를 풀어나가면서 해결책이 계속 바뀔 수밖에 없다고 생각하니 해결책 하나하나를 완성도있게 만들어야 한다는 부담이 많이 적어진 것 같다.

2) 직접 만들다 보면 애착이 생겨서 자꾸 정성을 들이게 됨

몇 달 만들고 버릴 프로덕트가 아닌 이상 오래 키울 생각으로 만들다 보면 보통 애정이 생기기 마련이다. 애정을 갖는 것 자체가 나쁜건 아니지만, 이런 감정에 빠질수록 당장 중요하지 않은 것에까지 정성을 쏟기가 쉽고 자주 런칭하기 어려워지는 경우가 많았다.

이럴 때 우리가 썼던 방법 중 하나는 기능 단위가 아닌 기간 단위로 끊어서 런칭하는 거였다. 예를 들어 2주 안에 신규 기능을 런칭하려고 했는데 중간에 다 못 만들겠다 싶으면 기능이 돌아가는데 정말 필수적인 부분을 제외하고 다 잘라버린 버전으로라도 2주 안에 런칭하는 식이었다. 흥미로운건 처음에 잘라낼 때는 마음이 좀 아픈데 일단 런칭하고 나면 잘라낸 부분에 대해 요청이 들어오는 경우는 별로 없어서 자연스럽게 최소 버전으로 개발이 가능했다는 점이다.

성공한 프로덕트들은 처음부터 철저한 기술적 설계를 통해 차근차근 만들어졌을 것 같았는데 저렇게 허술하게 만든 때도 있었다는게 인상적이었다. 아래는 영상에서 제일 공감갔던 quote:

“A lot of the best product decisions are made fast and under duress”