어떤 사용자 피드백을 만들고 어떤 것을 흘려보낼지 정하는 법
사람들이 앱을 쓰기 시작하면 요청이 쏟아집니다. AI 앱 빌더로 만들 가치가 있는 피드백, 잠시 보류할 피드백, 정중히 거절할 피드백을 가르는 간단한 방법을 알려 드립니다.
사람들이 앱을 쓰기 시작한 첫 몇 주는 조용합니다. 그러다 메시지가 시작됩니다. “다크 모드 추가해 주실 수 있나요?” “PDF로 내보낼 수 있으면 정말 좋겠어요.” “버튼을 파란색으로 만들어 주실래요?” “저희가 이미 쓰는 도구와 연동이 꼭 필요해요.” 한 달도 안 돼 마흔 가지 항목의 목록이 생기고, 그중 무엇이든 오후 한나절이면 기꺼이 만들어 줄 AI 앱 빌더가 손에 있습니다.
바로 그 마지막 부분이 함정입니다. 각 기능을 만드는 게 싸고 빠를 때, 어려운 질문은 더 이상 “이걸 만들 수 있나?”가 아니라 “만들어야 하나?”가 됩니다. 병목은 당신의 손에서 당신의 판단으로 옮겨 가는데, 그 판단을 위한 안내서는 아무도 건네주지 않습니다.
이 글은 들어오는 피드백을 세 더미로 — 만들 것, 보류할 것, 흘려보낼 것 — 가르는 간단한 방법입니다. 프로덕트 매니지먼트 경력이 없어도 됩니다. 목표는 사람들에게 거절하는 게 아닙니다. 당신이 실제로 만드는 것들이 앱을 정말 앞으로 나아가게 하는 것들이 되도록 하는 것이죠.
왜 “그냥 만들어”가 더 이상 통하지 않는가
처음 열 개의 기능까지는 “누가 요청하든 그냥 만들어”가 괜찮은 전략입니다. 의견이 충돌할 만큼 사용자가 많지도 않고, 모든 기능이 지난주의 텅 빈 상태보다 앱을 더 유용하게 만들어 주니까요.
이게 통하지 않게 되는 건 진짜로, 서로 다른 사용자가 생길 무렵입니다. 프리랜서는 이걸 원하고, 작은 에이전시는 그 반대를 원하고, 한 번 들렀던 방문자는 그 둘 다 절대 쓰지 않을 무언가를 원합니다. 셋 다 만들면 앱은 잡동사니 서랍이 됩니다 — 물건은 가득한데, 뭘 찾기 어렵고, 들고 다니기 무거운. 당신이 추가하는 모든 기능은 영원히 작동하게 유지하고, 새 사용자에게 설명하고, 근처의 무언가를 바꿀 때 망가뜨리지 않아야 할 기능입니다.
AI 앱 빌더는 좋아지기 전에 먼저 이걸 더 나쁘게 만듭니다. 자연스러운 제동 장치를 없애 버리기 때문이죠. 기능 하나에 개발자 2주가 걸릴 때는, 그게 2주를 들일 가치가 있는지 진지하게 고민했습니다. 빌더가 20분이면 만들 때는, 전혀 고민하지 않습니다 — 그냥 예라고 하죠. 비용이 사라진 게 아닙니다. “만드는 시간”에서 “짊어질 무게”로 옮겨 갔을 뿐이고, 무게는 눈에 잘 보이지 않습니다.
거의 모든 것을 가르는 세 가지 질문
요청이 들어오면, 순서대로 세 질문을 통과시키세요. 대부분은 처음 두 질문만으로 알아서 정리됩니다.
1. 이게 내가 이 앱을 만든 대상에게 도움이 되는가? 당신은 특정한 누군가를 위해 앱을 만들었습니다 — 웨딩 사진작가, 유소년 축구 코치, 인디 팟캐스트 진행자. 그런 사람의 요청은 우연히 들어왔다가 다시는 안 올 사람의 요청보다 더 가치가 큽니다. 어떤 기능이 핵심 사용자가 찾아온 주된 일을 하는 데 도움이 된다면, 그건 맨 위로 갑니다. 진짜 사용자가 아닌 방문자에게 도움이 되는 거라면, 아무리 큰 소리로 요청했더라도 맨 아래로 갑니다.
2. 실제로 몇 명이 쓸 것인가? “누가 요청했는가”가 아니라 — 누가 쓸 것인가입니다. 한 사람이 큰 소리로 요청하는 것은 조용히 혜택을 볼 열 명과 같지 않습니다. 여기서 정직해지세요. 큰 소리의 요청은 큰 요청처럼 느껴지지만, 대개는 아니니까요. 좋은 단서: 그 사람에게 지금은 대신 무엇을 하고 있는지 물어보세요. 매일 쓰는 어설픈 우회 방법이 있다면, 그건 진짜 필요입니다. “아마 가끔은 쓸 것 같아요”라면, 있으면 좋은 것이 변장을 한 것이죠.
3. 이걸 영원히 짊어지는 데 드는 비용은 얼마인가? 어떤 기능은 가볍습니다. 새 색상 옵션, 다시 쓴 라벨, 폼에 추가한 항목 하나 — 만들고 잊으면 됩니다. 어떤 기능은 무겁습니다: 결제를 건드리는 모든 것, 실제 사람에게 이메일을 보내는 모든 것, 자체 규칙을 가진 완전히 새로운 섹션을 추가하는 모든 것. 무거운 기능이 나쁜 건 아닙니다. 다만 앞의 두 질문을 여유 있게 통과해서 그 무게를 정당화해야 합니다.
세 더미
그 질문들을 돌려 보면 거의 모든 것이 세 곳 중 하나에 떨어집니다.
만들 것. 핵심 사용자에게 도움이 되고, 여럿이 쓸 것이며, 짊어질 비용이 합리적입니다. 이건 쉽습니다. 만들고, 요청한 사람에게 알려 주세요 — 자기 아이디어가 출시되는 걸 본 사람은 당신의 가장 충성스러운 사용자이자 다음 좋은 아이디어의 최고 원천이 됩니다.
보류할 것. 좋은 아이디어지만, 아직 이르거나, 한 사람만 원하거나, 무거운데 아직 확신이 안 섭니다. 거절하지도 말고 만들지도 마세요. 실제로 들여다볼 곳에 적어 두세요 — 간단한 목록, 메모, 보드. 다음 한 달 동안 같은 것을 세 사람이 더 요청하면, 그건 스스로 만들 더미로 승격하면서 당신에게 그렇다고 알려 주는 겁니다. 보류는 무덤이 아닙니다. 대기실입니다.
흘려보낼 것. 앱의 용도에 맞지 않거나, 영원히 한 사람만 위할 것이거나, 다른 모두에게 앱을 더 나쁘게 만들 겁니다. 이런 건 정중하고 정직한 거절이 필요합니다. “사려 깊은 아이디어네요, 하지만 추가할 계획이 있는 건 아니에요 — 대신 이렇게 해 보시는 걸 권할게요”는 관계를 지키고 앱을 보호합니다. 거절은 하나의 기능입니다. 모든 거절은 사람들이 이해할 만큼 앱을 단순하게 유지하겠다는 동의이기도 합니다.
작은 예시
저희가 아는 어떤 분은 AI 앱 빌더로 전부 만든, 음악 교사용 예약 앱을 운영합니다. 어느 한 주에 그녀는 세 가지 요청을 받았습니다: 한 교사는 학생에게 가는 자동 알림 문자를 원했고, 한 학부모는 자기 아이들의 수업을 한 화면에서 보는 방법을 원했고, 한 사람은 “재미로” 앱을 라틴어로 번역해 달라고 했죠.
알림은 세 질문을 모두 통과했습니다 — 핵심 사용자이고, 노쇼 문제를 겪는 사람이 많고, 문자는 무겁지만 그럴 가치가 있죠. 만들었습니다. 학부모용 화면은 한 사람의 좋은 아이디어여서 보류했는데, 3주 안에 두 명의 학부모가 더 요청해서 스스로 승격했습니다. 라틴어 번역은 따뜻한 거절을 받았고요. 이 결정들 중 어느 것에도 스프레드시트는 필요 없었습니다. 세 가지 질문과, 세 번째 질문에 정직하게 답하려는 의지가 필요했을 뿐이죠.
아무도 말해 주지 않는 부분
다루기 가장 어려운 피드백은 나쁜 아이디어가 아닙니다. 당신이 좋아하는 사람들이 내놓은, 모든 것이 될 수는 없는 앱을 위한 좋은 아이디어입니다. 그것들을 흘려보내는 건 그 사람을 실망시키는 것처럼 느껴집니다. 그렇지 않습니다. 당신의 앱을 쓰는 사람들에게 해 줄 수 있는 가장 친절한 일은, 그들이 찾아온 그 한 가지에 계속 잘하도록 앱을 충분히 집중된 상태로 유지하는 것입니다.
다음에 요청이 쌓이면, AI 앱 빌더를 먼저 열지 마세요. 당신의 목록을 열고, 각 항목을 세 질문에 통과시켜, 더미로 분류하세요. 이제 만드는 건 쉬운 부분입니다. 무엇을 만들 가치가 있는지 정하는 게 진짜 일이고요 — 그건 코드 한 줄 쓰지 않고도 할 수 있는 일입니다.