개인 개발 SaaS에서 '사용자 피드백이 분산되는 문제'를 어떻게 설계할 것인가

개인 개발이나 작은 SaaS를 만들다 보면, 처음에는 사용자로부터 feedback을 받는 것만으로도 상당히 기쁩니다.

"이 부분이 이해하기 어렵습니다"

"이 기능이 필요합니다"

"이 화면에서 버그가 발생했습니다"

와 같은 목소리가 들려오면, 제대로 사용해 주고 있는 사람이 있구나 하는 실감이 납니다.

하지만 사용자가 조금씩 늘어나면, feedback은 점점 관리하기 어려워집니다.

처음에는 Notion이나 스프레드시트(Spreadsheet)로 충분했는데, 어느샌가 Discord, 이메일, 문의 양식, GitHub Issue, X(구 Twitter)의 답글 등 다양한 곳에 사용자의 목소리가 흩어져 있게 됩니다.

그리고 어떤 것이 중요한지 알 수 없게 됩니다.

이 기사에서는 개인 개발 SaaS나 작은 팀에서 '사용자 피드백이 분산되는 문제'를 어떻게 설계하면 좋을지 나름대로 정리해 보겠습니다.

사용자가 적을 때는 feedback 관리가 상당히 허술해도 돌아갑니다.

예를 들어, 다음과 같습니다.

• Discord의 게시물을 보고 대응한다
• 이메일로 온 요구사항을 Notion에 붙여넣는다
• 버그 보고를 GitHub Issue로 만든다
• 신경 쓰이는 것만 스프레드시트에 남긴다
• 중요해 보이는 요구사항은 Slack에 메모한다

이 단계에서는 아직 큰 문제가 되지 않습니다.

개발자 본인이 전부 기억할 수 있고, 사용자와의 거리도 가깝기 때문에 "그 사람이 말했던 요구사항이었지"라고 떠올릴 수 있습니다.

하지만 이것은 사용자 수가 적을 때뿐입니다.

사용자가 조금 늘어나면, feedback은 단순히 "수가 늘어나는" 것뿐만 아니라 질도 제각각이 됩니다.

예를 들어, 다음과 같은 상태가 됩니다.

어떤 사용자는 "CSV 내보내기 기능이 필요하다"라고 말하고, 다른 사용자는 "데이터를 외부에서 분석하고 싶다"라고 말합니다.

표현은 다르지만, 실제로는 상당히 유사한 요구사항일 수 있습니다.

다만, 수작업으로 보고 있으면 이것들이 같은 니즈인지, 별개의 니즈인지 판단하기 어려워집니다.

사용자로부터 오는 목소리는 깔끔하게 분류되어 있지 않습니다.

• 버그 보고 (Bug Report)
• 기능 요구 (Feature Request)
• 사용법 질문 (Question)
• UI에 대한 불만
• 요금에 대한 불만
• 경쟁 서비스와의 비교
• 단순한 감상

이것들이 같은 곳으로 흘러 들어오면 무엇부터 봐야 할지 알 수 없게 됩니다.

이는 작은 팀일수록 일어나기 쉽다고 생각합니다.

강하게 요구하는 사용자의 요구사항을 먼저 대응해 버린다.

여러 번 재촉받는 것을 중요하다고 생각하게 된다.

최근에 본 feedback을 우선시하게 된다.

물론 목소리가 큰 사용자의 의견이 중요한 경우도 있습니다.

다만, 그것만으로 우선순위를 결정하면 정말 많은 사용자가 겪고 있는 문제를 놓칠 수 있습니다.

개발 측은 제대로 개선하고 있다고 생각해도, 사용자에게는 그것이 전달되지 않는 경우가 있습니다.

예를 들어, 백엔드에서 버그를 수정하거나 세세한 UX 개선을 하고 있더라도, 사용자 입장에서는 "최근에 아무것도 변하지 않았다"라고 보일 수 있습니다.

이것은 상당히 아까운 일입니다.

프로덕트는 움직이고 있는데, 사용자에게는 "멈춰 있는" 것처럼 보이기 때문입니다.

feedback 관리라고 하면, 처음에는 "사용자의 목소리를 모으는 장소"를 만드는 것만 생각하기 쉽습니다.

하지만 실제로는 feedback만으로는 완결되지 않습니다.

개인적으로는 다음의 3가지를 세트로 생각하는 것이 좋다고 생각합니다.

요소	역할
Feedback	사용자의 목소리를 모으는 입구
...	...

Feedback은 입구입니다.

하지만 사용자 입장에서 "보낸 feedback이 어떻게 되었는지"가 보이지 않으면, 점점 보낼 의미를 느끼지 못하게 됩니다.

여기서 Roadmap이 필요해집니다.

Roadmap이 있으면 사용자는 "이 요구사항은 검토되고 있구나", "이 기능은 개발 중이구나"라는 것을 알 수 있습니다.

나아가 Changelog가 있으면 "제대로 개선되고 있다", "프로덕트가 살아있다"라는 것이 전달됩니다.

즉, feedback 관리는 단순한 문의 관리가 아니라, 사용자와의 커뮤니케이션 설계에 가깝다고 생각합니다.

최근에는 AI를 사용하여 feedback을 정리하는 것도 현실적이 되었습니다.

AI가 적합한 것은 예를 들어 다음과 같은 처리입니다.

• feedback의 분류
• 중복되는 요구사항의 검출
• 긴 게시물의 요약
• Bug / Feature Request / Question의 구분
• 유사 feedback의 그룹화
• 다국어 feedback의 정리

특히 Discord나 이메일 등으로부터 잡다한 feedback이 들어오는 경우, AI를 이용한 1차 정리 (First-pass organization)는 궁합이 매우 좋다고 생각합니다.

반면, AI에게 모든 것을 맡기는 것은 조금 위험합니다.

예를 들어, 우선순위의 최종 판단은 사람이 확인해야 한다고 생각합니다.

왜냐하면 우선순위에는 다음과 같은 요소들이 포함되기 때문입니다.

• 얼마나 많은 사용자에게 영향을 미치는가
• 어떤 사용자층으로부터 왔는가
• 사업상 얼마나 중요한가
• 개발 비용 (Development cost)은 어느 정도인가
• 현재의 제품 방침 (Product policy)과 일치하는가
• 일시적인 불만인가, 구조적인 문제인가

AI는 정리에 적합하지만, 제품 판단 그 자체를 완전히 맡기기에는 아직 인간 측의 설계가 필요하다고 생각합니다.

작은 SaaS에서 feedback loop를 만든다면, 개인적으로는 다음과 같은 구성이 다루기 쉬워 보입니다.

User Feedback
↓
Feedback Board
...

포인트는 feedback을 모으는 것으로 끝내지 않는 것입니다.

모은 feedback을 정리하고, 우선순위를 판단하고, Roadmap에 반영하고, 실제로 출시하면 Changelog로서 전달하는 것.

이러한 흐름이 있으면 사용자도 "자신의 목소리가 제대로 전달되고 있다"라고 느끼기 쉬워집니다.

실제로 만들 경우, 최소한으로 필요한 기능은 이 정도입니다.

사용자가 요구사항이나 버그 보고를 작성할 수 있는 장소입니다.

가능하다면 다른 사용자가 동일한 요구사항에 리액션(Reaction)할 수 있으면 좋을 것 같습니다.

feedback에는 상태(Status)가 필요합니다.

예를 들어, 다음과 같은 status입니다.

• New
• Under Review
• Planned
• In Progress
• Shipped
• Closed

상태가 보이는 것만으로도 사용자 측의 불안은 상당히 줄어듭니다.

feedback이 늘어나면 수동으로 태그를 다는 것은 힘듭니다.

AI로 어느 정도 자동 분류(Automatic classification)를 할 수 있다면 개발자나 PM의 부담이 상당히 줄어듭니다.

단, 최종적인 판단은 사람이 할 수 있도록 해두는 것이 좋아 보입니다.

Roadmap은 사용자에 대한 약속이라기보다 방향성의 공유라고 생각합니다.

모든 것을 세세하게 공개할 필요는 없지만, "지금 어느 방향으로 나아가고 있는가"가 보이는 것만으로도 제품에 대한 신뢰감이 달라집니다.

Changelog는 경시되기 쉽지만, 상당히 중요하다고 생각합니다.

작은 개선이라도 제대로 전달함으로써 "이 제품은 제대로 업데이트되고 있다"라고 느끼게 할 수 있습니다.

특히 개인 개발이나 작은 팀에서는 개발 속도 그 자체보다 사용자에게 진척 상황이 전달되는 것이 중요한 상황이 있습니다.

이러한 사고방식과 유사한 OSS로서, 최근 FeedLog를 사용해 보았습니다.

FeedLog는 Feedback, Roadmap, Changelog를 통합하여 다룰 수 있는 open-source 사용자 피드백 관리 도구입니다.

특징으로는 다음과 같은 점들이 있습니다.

• feedback을 한곳에 모을 수 있음
• AI를 통한 분류 및 중복 정리 가능
• public roadmap을 만들 수 있음
• changelog를 공개할 수 있음
• OSS이므로 self-host도 선택 가능
• SaaS 버전도 있어 바로 테스트해 볼 수 있음

개인적으로 흥미롭다고 생각한 점은 단순한 feedback board가 아니라, "모은다 → 정리한다 → Roadmap으로 만든다 → Changelog로 전달한다"라는 흐름까지 의식하고 있다는 점입니다.

사용자의 목소리를 모으기만 한다면 Notion이나 Google Form으로도 할 수 있습니다.

다만, 그 이후에 "어떻게 정리하고 어떻게 사용자에게 돌려줄 것인가"까지 생각하면, Feedback / Roadmap / Changelog가 일체화되어 있는 의미는 크다고 생각했습니다.

GitHub은 여기 있습니다.

Canny와 같은 feedback management SaaS는 상당히 편리합니다.

반면, 작은 팀이나 개인 개발에서는 다음과 같은 점들을 고려해야 하는 상황이 있습니다.

• 아직 매출이 작아서 고정비를 늘리고 싶지 않다
• feedback 데이터를 직접 소유하고 싶다
• 필요한 기능만 심플하게 사용하고 싶다
• 향후 자신들의 워크플로우(Workflow)에 맞춰 조정하고 싶다
• 우선 self-hosted로 시도해 보고 싶다

물론 모든 팀에 OSS가 적합한 것은 아닙니다.

운영 비용을 부담하고 싶지 않다면 평범하게 SaaS를 사용하는 편이 더 편합니다.

다만, 개발자가 있는 작은 팀이라면 OSS (Open Source Software) 피드백 도구로 시작하는 것이 상당히 현실적인 선택지라고 생각합니다.

개인적으로는 사용자가 늘어난 뒤에 피드백 관리를 정비하기보다, 일찍 가벼운 메커니즘을 만들어 두는 편이 좋다고 생각합니다.

이유는 간단합니다. 피드백은 나중에 정리하려고 하면 상당히 힘들기 때문입니다.

처음부터 완벽한 운영을 할 필요는 없습니다.

우선은 아래 사항들만으로도 충분하다고 생각합니다.

• 피드백을 한곳으로 모으기
• 동일한 요구사항을 하나로 묶기
• 상태(Status) 부여하기
• 로드맵 (Roadmap)에 반영하기
• 릴리스하면 변경 사항 (Changelog)에 기록하기

이것만으로도 사용자와의 커뮤니케이션은 상당히 달라집니다.

사용자 피드백 관리는 단순히 "요구사항을 저장하는 장소"를 만드는 것만으로는 불충분하다고 느낍니다.

중요한 것은 사용자의 목소리를 제대로 받아들이고, 그것을 정리하여, 프로덕트의 방향성에 반영하고, 마지막으로 사용자에게 되돌려주는 것입니다.

즉, 피드백 관리라기보다 피드백 루프 (Feedback Loop)의 설계입니다.

특히 개인 개발 SaaS나 작은 팀에서는 사용자와의 거리가 가깝기 때문에, 이 루프가 프로덕트의 신뢰로 이어진다고 생각합니다.

저도 아직 시행착오를 겪는 중이지만, 마찬가지로 "피드백이 여러 곳에 흩어져 있어 곤란을 겪고 있는" 분들에게 참고가 된다면 좋겠습니다.