사이드 프로젝트가 제품이 된 순간

모든 사이드 프로젝트가 제품이 되길 바라는 건 아니다. 그냥 배우고 싶어서, 혹은 불편한 것을 직접 해결하고 싶어서 만드는 경우도 많다. 우리가 운영하는 서비스 중 일부도 처음엔 그런 동기로 시작했다.

”이거 써도 되냐”는 질문

전환점은 생각보다 조용하게 왔다. 팀 내부에서만 쓰던 도구를 지인에게 보여줬을 때, 돌아온 반응이 “이거 우리도 써도 되냐”였다. 그 한 마디가 분기점이었다.

그때까지 해당 도구는 에러 처리도 허술하고, 설정 파일을 직접 수정해야 하고, 배포는 로컬에서만 가능했다. 내부에서만 쓸 때는 이런 불편함이 문제가 아니었다. 그러나 외부에 내보내는 순간, 코드보다 운영 가능성을 먼저 생각하게 됐다.

사이드 프로젝트와 제품의 차이

사이드 프로젝트는 만드는 사람이 맥락을 다 알고 있다. 뭔가 이상하면 직접 들어가서 고치면 된다. 그러나 제품은 만드는 사람이 없는 시간에도 돌아가야 한다. 이 차이가 생각보다 크다.

우리가 전환 과정에서 가장 먼저 손댄 것은 에러 메시지였다. “NullPointerException”이 그대로 화면에 뜨는 걸 사용자에게 보여줄 수는 없었다. 그 다음은 로그였다. 문제가 생겼을 때 원인을 추적할 수 있어야 했다. 그러고 나서야 기능 추가 이야기가 나왔다.

기능보다 안정성이 먼저라는 순서는 당연해 보이지만, 사이드 프로젝트 감각으로 움직이다 보면 자꾸 기능 먼저 손이 간다. 우리도 예외가 아니었다.

전환 과정에서 배운 것

첫째, 의존성을 정리해야 한다. 사이드 프로젝트는 “일단 되면 된다” 식으로 라이브러리를 추가하는 경우가 많다. 제품으로 만들기 전에 실제로 쓰이는 것과 그냥 남아있는 것을 구분해서 걷어냈다.

둘째, 데이터 모델이 확정되어야 한다. 초기에는 스키마를 여러 번 바꿔도 문제없었지만, 외부 사용자가 생기는 순간 마이그레이션이 조심스러워진다. 모델을 일찍 안정화하는 것이 나중에 훨씬 편하다.

셋째, 운영 비용을 계산해야 한다. 사이드 프로젝트는 서버 비용이 조금 나와도 “실험이니까” 하고 넘어갈 수 있다. 제품은 그렇지 않다. 어느 시점에 수익이 생기거나, 아니면 운영을 멈추거나, 둘 중 하나를 선택해야 한다.

전환은 한 번에 이루어지지 않는다. 코드 한 줄 바꾼다고 제품이 되는 것도 아니다. 사용자가 생기고, 그 사용자가 기대를 갖기 시작할 때부터 조금씩 제품으로 바뀐다. 우리 팀은 그 변화를 느리게, 하지만 분명하게 경험했다.

— by slecs