사용자 피드백을 백로그로 전환하는 프로세스

 

앱스토어 리뷰, CS 문의, 슬랙에 올라오는 영업팀의 "고객이 이런 걸 원한대요" 같은 이야기들.
사용자 피드백은 사방에서 쏟아지는데, 이걸 실제로 백로그에 반영하는 과정이 없으면 결국 다 흩어지고 사라집니다.
저희 팀도 예전엔 피드백을 받으면 그때그때 슬랙에서 반응만 하고, 정리해서 백로그로 만드는 절차가 없었어요.
같은 요청이 세 달 뒤에 또 올라오는 걸 보고서야, 이건 프로세스로 만들어야 한다는 걸 깨달았습니다.

 

가장 먼저 한 일은 피드백이 들어오는 채널을 파악하고, 이걸 한 곳으로 모으는 구조를 만드는 것이었습니다.
저희는 앱스토어 리뷰, CS 문의, 영업팀 슬랙 채널, 사용자 인터뷰 노트까지 네 개 채널에서 피드백이 들어오고 있었어요.
채널마다 형식이 다 달라서, 이걸 노션 데이터베이스 하나로 모으는 작업부터 했습니다.
CS팀에는 주 1회 문의 로그를 태그와 함께 넘겨달라고 요청했고, 영업팀에는 슬랙 채널에 특정 이모지를 반응으로 남기면 자동으로 노션에 수집되는 간단한 자동화를 붙였어요.
처음엔 다들 "또 새로운 걸 해야 하냐"고 귀찮아했지만, 몇 주 지나니 오히려 "이거 어디에 적어야 하죠"라고 먼저 물어보는 분위기로 바뀌었습니다.

 

여기서 저희가 실수했던 부분이 있어요.
초반에는 피드백이 들어오면 거의 그대로 백로그 티켓으로 만들었습니다.
"장바구니에 담긴 상품을 나중에 다시 보고 싶어요"라는 리뷰가 오면 그걸 그대로 티켓 제목으로 썼는데, 나중에 보니 이 요청 뒤에 숨은 진짜 문제는 사용자마다 다 달랐어요.
어떤 사용자는 재고가 없어져서 다시 사고 싶은 상품을 놓친 게 문제였고, 다른 사용자는 가격이 떨어졌는지 확인하고 싶은 게 목적이었습니다.
그래서 지금은 피드백을 받으면 바로 티켓화하지 않고, 먼저 "이 사용자가 진짜로 해결하려는 문제가 뭔가"를 한 줄로 다시 정리하는 단계를 넣었습니다.
이 단계가 생긴 뒤로, 같은 표면적 요청이라도 실제로는 서로 다른 솔루션이 필요하다는 걸 구분해낼 수 있게 됐어요.

 

모든 피드백을 다 반영할 수는 없습니다.
저희는 매주 금요일에 "피드백 트리아지" 시간을 30분 잡아두고, 그 주에 들어온 피드백을 빈도와 임팩트 두 축으로 분류합니다.
빈도는 같은 취지의 피드백이 몇 건 들어왔는지, 임팩트는 이 문제가 핵심 사용 흐름에 얼마나 가까운지로 판단해요.
빈도도 낮고 임팩트도 낮은 피드백은 "보류" 태그를 달아두고, 대신 같은 태그가 쌓이는 걸 추적합니다.
한동안 보류였던 "다크모드 지원해달라"는 요청이 누적 건수가 어느 시점에 확 늘어난 걸 보고, 그다음 분기 로드맵에 정식으로 올린 적도 있었어요.

 

트리아지를 거쳐 백로그 티켓으로 만들 때, 저희는 반드시 원본 피드백 링크나 인용문을 같이 붙여둡니다.
개발자나 디자이너가 나중에 "이 기능을 왜 이렇게 만들었더라"를 다시 확인할 때, 추상화된 티켓 설명만 보면 맥락을 잃어버리기 쉬워요.
"장바구니 가격 변동 알림"이라는 티켓 제목 밑에, 실제 사용자가 남긴 "세일할 때 담아뒀던 옷이 있었는데 놓쳤어요"라는 원문을 같이 적어두면, 개발 중에 애매한 판단이 생겼을 때 이 원문을 다시 보고 방향을 잡을 수 있었습니다.

 

이 부분은 저희가 한참 뒤에야 추가한 단계인데, 지금은 가장 중요하게 여기는 단계입니다.
피드백을 준 사용자가 있다면, 그 기능이 실제로 반영됐을 때 알려주는 루프를 만들었어요.
CS를 통해 들어온 피드백이라면 CS팀이 해당 문의자에게 짧게 안내 메시지를 보내고, 앱스토어 리뷰라면 답글로 반영 사실을 남깁니다.
이 루프를 만든 뒤로 신기하게 재구매/재방문 사용자 중에 다시 피드백을 남기는 비율이 늘었어요.
"내 의견이 반영되는구나"라는 경험이 사용자와의 관계를 다르게 만든다는 걸 체감했습니다.

 

매달 한 번은 이 피드백-백로그 전환 프로세스 자체를 점검합니다.
이번 달에 들어온 피드백이 몇 건이었는지, 그중 몇 건이 백로그로 전환됐는지, 실제로 개발까지 이어진 비율은 얼마였는지를 숫자로 봐요.
이 숫자가 계속 떨어지면 트리아지 기준이 너무 빡빡하거나, 팀 리소스 자체가 부족하다는 신호로 받아들이고 다음 분기 계획에 반영합니다.

피드백을 흘려보내지 않고 프로세스로 만드는 일은 처음엔 번거롭게 느껴지지만, 몇 달 쌓이고 나면 이게 사실 로드맵을 짜는 가장 확실한 근거 자료가 됩니다.

저희는 이제 신규 분기 로드맵을 짤 때, 이 피드백 데이터베이스를 가장 먼저 열어봅니다.

사용자가 이미 말해준 것들을 놓치지 않는 것부터가 좋은 기획의 시작이라는 걸, 이 프로세스를 만들면서 다시 배웠어요.