Reddit, X, Hacker News에서 제품 피드백 및 기능 요청을 수집하는 방법

일반적인 피드백 채널에서 이를 놓치는 이유

대부분의 팀은 고객지원 티켓, 인앱 위젯, 세일즈 통화의 세 곳에서 피드백을 수집합니다. 세 곳 모두 동일한 편향을 가지고 있습니다. 이미 여러분과 대화를 나누고 있는 사람들의 이야기만 들을 수 있다는 점입니다.

공개 스레드는 다릅니다. 지난달 서비스를 해지한 고객은 설문조사에 응하지 않겠지만, Reddit에서는 왜 떠났는지 기꺼이 설명합니다. 여러 도구를 비교 중인 잠재 고객은 "어떤 것을 선택해야 할까요?"라는 게시글에서 귀사 제품에 빠져 있는 기능을 나열합니다. 이는 다른 방법으로는 결코 얻을 수 없는 피드백이며, 종종 다른 사용자들의 동의나 반대 댓글이 함께 달려 문제가 얼마나 보편적인지 파악할 수 있게 해줍니다.

문제는 정보의 양입니다. 일주일에 한 번 제품 이름을 검색하면 몇 안 되는 스레드만 발견하게 되고, 대개는 답변하기에 너무 늦은 시점입니다. 반대로 제품 이름으로 단순 알림을 설정하면 제품과 전혀 무관한 언급까지 모든 멘션이 잡히게 됩니다. 핵심은 피드백만을 구체적으로 찾아내는 알림을 작성하는 것입니다.

피드백을 감지하는 알림 작성법

KWatch 알림은 목록에 있는 모든 키워드와 일치하므로 쉼표는 AND 조건으로 작동합니다. 이것이 바로 피드백 알림이 효과적인 이유입니다. 제품 이름으로 단일 알림을 설정하는 대신, 사람들이 무언가 개선되길 원할 때 사용하는 단어와 제품 이름을 조합하는 것입니다.

제품 이름을 "acme"라고 가정했을 때 시작하기 좋은 기본 설정 예시는 다음과 같습니다:

1. acme, wish 및 acme, would be nice 기능 요청용
2. acme, bug 및 acme, broken 버그 신고용
3. acme, switched 및 acme, cancelled 이탈 사유용
4. acme, missing 및 acme, doesn't support 도입 검토 중 사용자들이 부딪힌 기능 공백용

각 줄은 별도의 알림입니다. 이 모든 단어를 하나의 알림에 넣으면 한 게시글에 모든 단어가 다 들어가 있어야 감지되기 때문입니다. 일주일 정도 운영하면서 실제 사용자들이 어떻게 말하는지 파악한 뒤 문구를 조정하는 것이 좋습니다. 사용자가 "기능 요청"이라는 단어를 직접 입력하는 경우는 드물기 때문에, "would be great if(~라면 정말 좋을 텐데)"와 같이 실제로 사용하는 표현을 찾아야 합니다.

몇 가지 필터를 활용하면 대부분의 노이즈를 걸러낼 수 있습니다. Reddit과 Hacker News에서는 제품 이름이 짧거나 흔한 단어인 경우 Whole Words Only를 켜서 "acme"가 "acmeplex"와 매칭되지 않도록 하세요. 팀원들의 계정을 Excluded Users로 추가하면 팀의 답변이나 출시 관련 게시글로 인해 알림이 울리는 것을 방지할 수 있습니다. 제품 전용 서브레딧이 있다면 Included Subreddits로 범위를 지정한 별도의 알림을 만들고 두 번째 키워드를 완전히 생략할 수도 있습니다. 그곳에 올라오는 거의 모든 글이 이미 피드백이기 때문입니다.

제외 키워드는 포함 키워드와 정반대로 작동합니다. 포함 키워드는 모두 일치해야 하지만, 제외 키워드는 그중 하나라도 나타나면 해당 게시글이 즉시 제외됩니다. 이 목록은 짧고 구체적으로 유지하세요. 그렇지 않으면 노이즈와 함께 실제 유용한 피드백까지 걸러낼 수 있습니다. 저희의 키워드 알림에서 노이즈 줄이기 가이드 에서 각 필터를 더욱 자세히 살펴봅니다.

어디서부터 모니터링해야 할까

모든 플랫폼에서 동일한 유형의 피드백이 나오는 것은 아닙니다. 제 경험상 Reddit과 Hacker News는 사람들이 길고 구체적인 불만을 남기는 곳입니다. X는 글이 더 짧고 직설적이어서 문제가 발생한 릴리스를 빠르게 파악하는 데 유용합니다. Linkedin은 대부분 칭찬과 소식 공유 위주이므로, 업무에 사용하는 도구에 대해 자주 글을 올리는 사람들을 대상으로 판매하는 경우가 아니라면 이 목록에서는 우선순위가 낮습니다.

수집 속도 또한 플랫폼마다 다르며, 이는 각 알림을 활용하는 방식에도 영향을 줍니다. 다음은 공식 문서에 명시된 업데이트 주기입니다:

피드백 수집의 관점에서 보면 이 중 어느 것도 느리지 않습니다. 이 표가 보여주는 핵심은 Hacker News 스레드가 프론트 페이지에 머물러 있는 동안 알림을 받을 수 있다는 점이며, 바로 그 순간 팀원의 답변이 가장 큰 영향력을 발휘합니다.

제품 팀에 피드백 전달하기

아무도 읽지 않는 알림은 그저 조금 더 편한 검색 기능에 불과합니다. 팀들이 대개 간과하는 부분은 피드백이 어디로 전달되고 누가 이를 확인할지 결정하는 일입니다.

가장 간단한 설정은 전용 Slack 채널을 활용하는 것입니다. KWatch에서는 알림별로 Slack 웹훅을 설정할 수 있으며, 개별 알림 웹훅이 계정 전체 웹훅보다 우선 적용됩니다. 따라서 세일즈 알림은 계속 세일즈 채널로 전송하면서 피드백 알림은 #product-feedback 같은 전용 채널로 보낼 수 있습니다. 열람만 하면 되는 제품 관리자나 엔지니어는 알림을 수신할 수는 있지만 알림 생성이나 삭제는 할 수 없는 Reader 역할로 KWatch 팀에 합류할 수 있습니다.

시간이 지남에 따라 들어오는 요청 수를 집계하고 싶다면 동일한 알림을 API 웹훅으로 전송하세요. 일치하는 각 항목은 JSON 페이로드 형태로 전달됩니다. 다음은 공식 문서에 나와 있는 예시입니다:

{
  "platform": "reddit",
  "query": "Keywords: vllm",
  "datetime": "19 Jan 24 05:52 UTC",
  "link": "https://www.reddit.com/r/LocalLLaMA/comments/19934kd/sglang_new/kijvtk5/",
  "author": "lmzoo",
  "content": "sglang runtime has a different architecture on the higher-level part with vllm.",
  "sentiment": "neutral"
}

이를 Zapier 또는 n8n 웹훅으로 전달하여 필드당 열 하나씩 스프레드시트에 행을 추가하도록 구성할 수 있습니다. query 필드는 어떤 알림이 트리거되었는지 알려주므로 기능 요청 알림과 버그 알림이 자동으로 분류됩니다. sentiment 필드(positive, negative, neutral)를 활용하면 부정적인 감정이 담긴 게시물을 빠르게 골라낼 수 있습니다. 이전에 연동해 본 적이 없다면 Zapier 및 n8n 설정 방법 을 단계별로 자세히 정리해 두었으니 참고하시기 바랍니다.

이메일 알림도 작동하지만, 긴 게시글은 이메일에서 잘려서 표시될 수 있습니다. 기능 요청은 대개 내용이 긴 편이므로 Slack이나 웹훅을 사용하는 것이 훨씬 적합합니다.

수집한 피드백을 활용하는 방법

피드백이 들어오기 시작하면 모든 글에 답변하고 싶은 유혹이 생깁니다. 하지만 조금은 신중할 필요가 있습니다. 해당 제품을 만드는 사람이 남긴 짧고 유용한 답변("해당 기능은 개발 목록에 포함되어 있으며, 현재로서는 다음 임시 해결책을 사용하실 수 있습니다")은 큰 도움이 됩니다. 반면 모든 댓글 끝에 회원가입 링크가 달린 일련의 답변은 비추천을 받거나, 일부 서브레딧에서는 활동 정지(차단)를 당할 수 있습니다.

더 가치 있는 습관은 주간 검토입니다. 일주일에 한 번씩 제품 팀의 누군가가 채널이나 스프레드시트를 검토하며 각 항목에 요청, 버그, 이탈 사유, 무관함과 같은 태그를 지정합니다. 한 달이 지나면 티켓을 통해 요청된 항목과 공개된 공간에서 사람들이 요구하는 항목의 대략적인 수치를 비교할 수 있게 됩니다. 두 목록이 서로 다를 때, 대개 그곳에서 가장 흥미로운 인사이트를 발견할 수 있습니다.

가장 유용한 피드백 중 일부가 키워드보다는 소수의 특정 인물(파워 유저, 애널리스트, 경쟁사 창업자 등)에게서 나오는 경우, 저희의 자매 제품인 MultiFollow 를 사용하면 특정 Linkedin 및 X 계정을 모니터링하여 새 게시물이 올라올 때 알림을 받을 수 있으며, 이는 키워드 알림을 훌륭하게 보완해 줍니다.