실패를 통해 깨달은 서비스 개발의 교훈

핵심가치 검증이 최우선이 돼야 한다.

완전히 실패한 서비스도 만들어 보고 어느 정도 규모가 있는 서비스도 만들어 봤지만 서비스 성공의 원칙, 방정식 같은 것은 여전히 모호하고 정의할 수 없는 것 같다. A라는 이유로 성공한 서비스가 있다면 마찬가지로 A라는 이유로 서비스가 실패하기도 했다. 가끔은 서비스 성공은 실력, 노력과 별개인 운의 영역인 것 같다는 생각도 든다. 하지만 큰 실패와 소소한 성공을 해보며 서비스 초창기는 무엇을 해야 하는지, 어떤 것을 집중해야 하는지는 개인적으로 윤곽이 잡히는 것 같다. 앞으로 새로운 서비스를 만들 때 적어도 이것만큼은 확실히 해두며 만들고 싶다.

핵심가치 검증이 최우선이 돼야 한다.

핵심 가치란 현재 만들고 있는 서비스가 유저에게 전달하고 싶은 가치다. 네이버는 차별화된 한글 검색 서비스, 카카오톡은 데이터 네트워크를 이용한 무료 메시지 전송 서비스, 토스는 편리한 증권 서비스가 초창기에 전달하고자 했던 핵심 가치였을 것이다.

네이버와 카카오톡, 토스 모두 이미 널리 쓰이는 성공한 서비스이기 때문에 출시 전부터 이들이 제공하는 가치가 당연하고 이미 검증됐을 것이라고 생각하기 쉽다. 그러나 서비스를 출시하기 전까진 전달하려는 핵심 가치가 시장에서 통용할지 아무도 모른다. 그래서 서비스 초창기의 목표는 제공하려는 가치가 시장에서 통하는지 아닌지 확인하는 일을 최우선으로 한다. MVP(Minimum Value Product)라는 개념도 여기서 등장한다. 풀네임 그대로 핵심 가치만 담은 제품이다. 실제 프로덕트로 사용할 수도 있지만 그것보다는 시장에서 핵심 가치를 원하고 있는지 그렇지 않은지 확인하려는 용도로 주로 쓰인다. MVP를 내고 나서 시장의 반응이 충분하다면 여기에 기능을 덧붙여 실제 프로덕트까지 이어지고 그렇지 않다면 핵심가치를 다시 찾거나 수정한다.

MVP에서 디자인은 핵심가치가 전달되는 선에서 최소화해서 만드는 것이 좋다고 생각한다. 특히 독특한 애니메이션이나 차별화된 UX는 후순위로 미뤄두는 것이 좋다. 실패한 서비스를 만들었을 때 초창기 프로덕트에 디자인에 너무 많은 힘을 실었던 것이 문제였다. 물론 외형이 훌륭하면 좋은 앱이 되는 것은 맞다. 그러나 현재 세운 가설이 시장에서 통하는지 아닌지 검증되지 않은 상황에서 지나치게 겉모습에 신경 쓸수록 가설 검증은 후순위로 밀려났다. 돌아와서 생각해보면 어떤 가치를 전달할지 그리고 어떻게 가치를 전달해야 할지, 미미한 반응을 토대로 어떤 결정을 내려야 할지 분석하고 고민하는 것에 올인해도 시간은 부족했는데 ‘어떻게 퀄리티 있고 이쁜 앱을 만들 수 있는 것일까’라는 질문도 같이 하다 보니 필요한 일에 집중하기 어려웠다.

디자인에 힘을 실을수록 팀 차원에서 리소스도 많이 소요됐다. 특히 개발자로서 고생을 많이 했다. 개발자가 몇 명 되지 않은 소규모 팀에선 핵심 가치를 전달하는 기능을 만드는 것만으로도 시간이 오래 소요된다. 그런데 독특한 애니메이션이나 차별화된 UX 요구사항이 더해질수록 작업 소요 시간은 기하급수적으로 늘어났고 코드는 관리하기 어려워졌다. 기능 추가로 유저에게 미치는 이점은 미미한데 개발하는데 소요되는 비용은 컸다. 시기와 팀에 주어진 리소스를 고려했을 때 비용 효율적이지 못했던 선택이었다. 어느 정도 규모가 있는 서비스라면 필요한 작업이지만 서비스 초창기에 내릴 결정은 아니었다. 가설 검증 후 발 빠르게 다음 스텝으로 넘어가야 했는데 앱 개발자 2명은 이미 과부하에 걸려버렸다. 그렇게 서비스 개발 속도는 지지부진해져만 갔다.

UI/UX에 투자한 시간이 길어지게 되자 매몰 오류에 빠지게 됐다. 최악의 상황이었다. 핵심 가치에 집중하기보다는 이만큼 비용을 쏟는 제품은 유저 규모가 이 정도는 돼야 한다는 보상심리가 은연중에 생겼다. 유저의 반응이 오지 않는 이유를 핵심 가치에서 찾지 않고 우리 앱의 디자인에서 찾게 됐다. ‘우리 앱 디자인이 별로다', ‘뎁스를 더 줄이면 유저가 더 많이 사용할 것이다'와 같은 UX 고민만 이어졌다. 한번 매몰 오류에 빠지자 회복하기 어려웠다. 기나긴 회의 시간에서 우리는 뫼비우스의 띠처럼 겉모습에만 집중하는 프로세스가 반복됐다. 시간이 지날수록 앱 퀄리티는 훌륭한데 사용하는 유저는 줄어만 갔다. 보기만 했던 이쁜 쓰레기가 되고 있었다. 지속적으로 반복되는 실패에 지친 팀원이 생기며 팀 분위기는 자연스레 어두워져 갔다.

이쁘긴 한데 사용할 수는 없는 포크다

뒤늦게 깨달은 사실이지만 유저들은 전달하려는 가치가 명확하면 UI, UX가 불편하더라도 사용한다. 토스처럼 혁신적인 UI를 가진 증권 앱이 나오기 전에도 사람들은 불편한 증권 앱을 사용했고 게임도 버그가 있더라도 심각한 것이 아니라면 해결될 때까지 참고 즐겼다. MZ세대가 하루에 한 번씩은 들어가는 인스타도 여전히 버그가 있다. 유저들은 필요하다면 사소한 불편을 감수하고라도 서비스를 사용한다. 사실 IT 서비스가 아니더라도 이미 생활 속에 익숙한 사례가 있다. 식당도 입지가 별 로거나 주차나 화장실이 불편하더라도 맛이 확실하거나 분위기가 좋다면 손님이 찾는다. 맛집이나 운치 있는 카페라면 몇 시간 차를 타고서라도 가지 않았던가? 만약 버그가 전달하려는 가치에 지장을 준다면 배포 전에 수정해야 하는 것이 맞지만 그렇지 않다면 나머지 문제는 부차적인 것 같다. 적어도 서비스 초창기엔 말이다.

중박은 거둔 서비스를 만들 때 접근 법은 달랐다. 전달하려는 가치를 최우선으로 했고 애니메이션이나 UI/UX는 후순위로 미뤘다. 휘황찬란한 애니메이션이 욕심이 나긴 했지만 서비스가 궤도에 오르기 전까진 과감히 포기했다. 오직 유저들이 사용하는지 그리고 핵심 가치가 유효한지에만 집중했다. 모든 버그를 완벽하게 잡을 수 없다는 점도 인정했다. 사용에 큰 지장을 주지 않을 정도로만 두고 나중에 고치자는 마인드로 배포했다. 개발자로서 아쉽기는 했다. 그러나 부족해도 세상에 필요한 제품을 만드는 것이 더 중요했다. 소요되는 시간과 에너지를 최소화하니 자연스레 투자 리스크도 줄었고 매몰 오류도 생기지 않았다. 유저의 반응을 보며 재빨리 서비스 방향을 수정할 수 있었고 목표로 했던 지표에 도달할 수 있었다.

물론 내 생각이 100% 정답이라고 확신 하긴 어렵다. 중박을 거둔 서비스가 운이 좋았을 수도 있고 실패한 서비스는 지지리도 운이 없었을지도 모르고 어쩌면 실패할 당시 집중했던 UI/UX가 훌륭하지 않았을 수도 있다. 토스처럼 기존 서비스의 불편함을 해결한 차별화된 UI/UX를 제공한다면 당연히 디자인에 총력을 쏟아야 한다. 이런 서비스를 만들게 된다면 지금껏 내가 해온 말을 모두 뒤집어야 할 것 같다. 하지만 현재 서비스의 규모, 전달하려는 가치에 따라서 적당히 포기하고 최선의 선택을 내려야 한다는 점은 배운 것 같다. 아무도 쓰지 않는 완벽한 제품보다는 조금 부족하더라도 사람들이 찾는 제품을 만드는 게 더 중요하다는 것.