“리뷰를 확인해야겠다”에서 SaaS로

발행: 3일 전 (2025년 12월 15일 오후 07:49 GMT+9)

10 min read

Source: Dev.to

Introduction

이것은 제가 SaaS AppReviews를 만들기 위한 여정의 첫 번째 파트입니다.

The Problem

오랫동안 앱 리뷰는 저에게 이상한 위치에 있었습니다. 리뷰가 중요하고 의미 있다는 건 알았지만, 10년 넘게 Android 앱을 만들면서 제품 품질과 사용자 경험에 큰 신경을 쓰게 되었고, 리뷰는 사용자가 직접적으로 생각을 말해주는 드문 장소 중 하나였습니다.

그럼에도 불구하고 리뷰는 일상 업무에 거의 포함되지 않았습니다. 직장에서 리뷰는 “가끔씩” 확인하거나, 뭔가 문제가 생겼을 때, 혹은 누군가가 기억해낼 때 확인하는 것이었습니다. 보통은 App Store Connect나 Google Play Console을 열고, 로그인하고, 클릭하고, 스크롤하면서 마지막으로 확인한 이후에 무슨 일이 있었는지 파악하려는 것이었죠. 대부분의 경우, 이것은 귀찮은 일처럼 느껴졌습니다.

The Trigger

AppReviews의 실제 동기는 업무에서 매우 실용적인 필요에서 시작되었습니다: 사용자 리뷰에 대한 기본적인 체크를 넣고 싶었습니다. 대시보드, 차트, 주간 보고서 같은 화려한 것은 필요 없고, 새로운 리뷰가 들어올 때마다 Slack에 배포 알림, CI 메시지, 경고와 함께 표시되길 원했습니다.

기존 도구들을 살펴보니, 모든 것이 너무 과하거나 너무 비쌌습니다. 일부 솔루션은 전담 팀이 리뷰와 고객 피드백을 관리하는 대기업을 위해 만들어진 것이 분명했습니다. 강력하지만, 단순한 신호만 원한다면 과잉이었습니다. 우리가 필요로 한 것에 비해 비용과 복잡성이 맞지 않아, 대안은 수동 확인이었습니다.

Manual Checking Breaks Down

수동으로 확인하는 것은 귀찮을 뿐 아니라, 쉽게 잊어버리게 됩니다. “나중에 확인하자”는 금세 내일이 되고, 다음 주가 되고, 어느새 일주일 전 리뷰를 읽게 됩니다. 그때는 순간이 사라진 뒤입니다.

나쁜 리뷰를 남긴 사용자는 아직도 활동 중일 가능성이 높습니다. 빠르게 답변하면 상황을 명확히 하고, 질문을 하고, 설명하거나 문제를 해결해 더 큰 문제가 되기 전에 막을 수 있습니다. 며칠 뒤에 답변하면 같은 효과를 얻기 어렵고, 멀게 느껴지며 때로는 의미 없게 보입니다.

답변을 놓치는 것은 평점만 놓치는 것이 아니라, 실제 무슨 일이 있었는지 이해할 기회를 놓치는 것이고, 맥락을 놓치는 것이며, 다음 사용자를 위해 같은 문제를 방지할 수 있는 피드백을 놓치는 것입니다.

The First Hack

이 패턴이 반복되는 것을 보고, 저는 보통 뭔가가 충분히 귀찮을 때 하는 일을 했습니다: 스크립트를 급조했습니다. 첫 번째 버전은 못생겼고 UI도, 설정 화면도 없었습니다. 단순히 리뷰를 가져와서 새 리뷰가 나타날 때마다 Slack에 메시지를 보냈습니다.

효과는 즉각적이었습니다. 리뷰는 이제 기억해 두고 확인해야 할 것이 아니라 자동으로 나타났습니다. 누군가 Slack 메시지를 보고 “아, 그거 봤어” 혹은 “어제 받은 지원 티켓이 이거 때문이구나” 라고 말했습니다. 때로는 대화가 시작되고, 때로는 빠른 답변으로 이어졌으며, 때로는 그냥 놓여 있었지만 최소한 눈에 보이게 되었습니다. 느낌이… 더 건강해졌습니다.

Realizing the Core Issue

놀라운 점은 변화가 작았음에도 불구하고 효과가 컸다는 것입니다. 우리는 아무것도 분석하거나 최적화하지 않았고, 단지 마찰을 없앴을 뿐입니다. 핵심 문제는 리뷰에 접근할 수 없다는 것이 아니라, 리뷰가 직접 가야 하는 곳에 있었고, 반복되는 수동 작업은 결국 지연된다는 것이었습니다.

같은 시기에, 저는 제 개인 프로젝트에서도 똑같은 일을 하고 있다는 것을 깨달았습니다. 뭔가를 배포하고 기분이 좋으면 “리뷰를 확인해야겠다”라고 생각했습니다. 가끔은 확인했고, 가끔은 안 했으며, 가끔은 피드백을 너무 늦게 발견하고 “좀 더 일찍 봤으면 좋았을 텐데”라고 생각했습니다. 같은 패턴, 다른 상황이었습니다.

Turning the Script into a Product

그때 스크립트를 좀 더 진지한 제품으로 바꾸자는 생각이 자연스럽게 떠올랐습니다. 처음엔 이것을 제품이라고 생각하지 않았고, “이건 있어야 한다”는 느낌이었습니다. 간단하고, 저렴하며, 한 가지 일을 잘 하는 것: 리뷰가 별다른 노력 없이 당신에게 도착하도록 하는 것.

본격적으로 만들기 시작하니 새로운 질문들이 생겼습니다:

리뷰를 중앙화하면 사람들이 또 다른 확인하지 않는 장소를 만들게 되지는 않을까?
수십 개의 리뷰가 있다면 모든 내용을 읽지 않고도 상황을 빠르게 파악하려면 어떻게 해야 할까?

저는 항상 기능을 추가하기보다 잡음을 줄이는 데 더 관심이 있었습니다. 대부분의 도구는 충분히 하지 못해서가 아니라, 너무 많은 일을 하려고 해서 실패합니다. 저는 AppReviews가 사람들이 한 번 열고 잊어버리는 또 다른 대시보드가 되길 원하지 않았습니다.

Design Principles

초점은 매우 좁게 유지되었습니다:

Visibility – 리뷰가 이미 보는 곳에 나타난다.
Timeliness – 게시되는 즉시 확인한다.
Context – 콘솔을 뒤져볼 필요 없이 행동할 수 있을 정도의 정보 제공.

그 외의 모든 것은 부차적이었습니다.

Changing the Relationship with Reviews

흥미로운 점은 리뷰가 항상 보이게 되면 리뷰와의 관계가 바뀐다는 것입니다. 리뷰는 이제 약간 스트레스를 주는 회피 대상이 아니라 제품 피드백 루프의 일부분이 됩니다. 이제 “리뷰를 확인한다”가 아니라 “리뷰에 반응한다”. 이 작은 변화가 큰 차이를 만듭니다.

Building the Side Project

어느 순간 이 사이드 프로젝트는 형태를 갖추기 시작했습니다: 밤, 주말, 작은 반복, 구축하지 않을 것에 대한 많은 결정, 그리고 기능을 추가하고 싶은 유혹을 억제하는 많은 노력. 저는 궁극적인 리뷰 플랫폼을 만들려는 것이 아니라, 제가 계속 겪던 아주 구체적이고 인간적인 문제—“리뷰를 확인해야겠다”는 순간—를 해결하려고 했습니다.

Next Steps

다음 글에서는 AppReviews가 어떤 부분에 집중해야 할지 결정한 과정과, 기능을 줄이는 것이 프로젝트에서 가장 중요한 부분 중 하나였던 이유에 대해 이야기하겠습니다.