사용자 피드백 프롬프트는 이런 상황에서 필요합니다. 앱스토어 리뷰, 설문 주관식 답변, 고객 문의, 커뮤니티 댓글까지 수백 개가 쌓였는데, 상사가 사용자가 무엇에 가장 불만인지 물으면 팀은 가격이었던 것 같다, 오류였던 것 같다고 인상만으로 답합니다. 아래 프롬프트는 원본 피드백을 분류표, 빈출 문제, 처리 우선순위로 한 번에 바꿔 줍니다. 복사해서 변수를 바꾸고 마지막에 피드백을 붙여 넣기만 하면 됩니다.
AI에게 요약만 시키는 것과는 다릅니다. 요약은 느낌만 주지만, 이 프롬프트는 모든 결론에 건수와 원문 인용을 요구하므로 결과를 그대로 요구사항 우선순위나 주간 회의 자료로 쓸 수 있습니다. 스무 개 미만이면 직접 읽는 편이 빠릅니다. 수백 개부터, 채널별이나 버전별 비교가 필요할 때 진가를 발휘합니다.
프롬프트 본문 (복사해서 사용)
당신은 사용자 리서치를 하는 프로덕트 분석가입니다. 아래 사용자 피드백을 규칙대로 처리해 주세요.
1. 분류: ［분류 기준, 기본값: 기능 문제 / 사용성 / 가격·요금 / 성능·장애 / 콘텐츠·서비스 / 기타］로 항목마다 하나의 주 카테고리만 정하세요. 두 카테고리에 걸치면 감정이 더 강한 쪽으로 넣고, 부 카테고리는 비고에 적어 주세요.
2. 집계와 감정: 카테고리별 건수와 비율을 세고, 긍정·중립·부정을 따로 세세요. 추정은 금지입니다. 한 번에 세기 어려우면 각 항목의 분류 결과를 먼저 나열한 뒤 합산하세요.
3. 빈출 문제: 카테고리마다 가장 자주 등장하는 구체적 문제 3개를 뽑고, 문제마다 가장 대표적인 사용자 원문 1개를 고치지 말고 그대로 인용하세요.
4. 우선순위: 건수, 부정 감정의 강도, 결제나 갱신에 미치는 영향을 종합해 각 문제에 P0, P1, P2를 매기고, 이유를 한 문장으로 설명하세요.
5. 출력 형식: 먼저 집계표(카테고리｜건수｜비율｜부정 건수｜대표 원문)를 제시하고, 이어서 빈출 문제 목록을 제시한 뒤, 분류할 수 없거나 정보가 부족한 항목이 몇 개인지 따로 밝히세요. 제품 개선을 약속하지 말고, 피드백에 없는 원인을 지어내지 마세요.
제 제품은 ［제품명과 한 줄 소개］입니다. 이 배치는 ［채널, 예: 앱스토어 / 고객 문의 / 설문］에서 왔고, 기간은 ［시작일과 종료일］입니다.
피드백 원문(한 줄에 하나씩):
［피드백 원문을 한 줄씩 붙여 넣으세요］변수 바꾸는 법
| 변수 | 채울 내용 | 예시 |
|---|---|---|
| ［분류 기준］ | 사업에 맞게 카테고리를 조정. 기본 여섯 가지는 대부분의 소비자 제품에 맞습니다 | 교육 제품이라면: 강의 내용 / 강사 답변 / 라이브 끊김 / 환불 / 숙제 채점 / 기타 |
| ［제품명과 소개］ | 어떤 제품과 서비스에 대한 피드백인지 | 개인의 일상 지출을 기록하는 가계부 앱 |
| ［채널］ | 이 배치의 출처. 채널을 섞지 마세요 | 앱스토어 리뷰와 고객 문의를 나눠 실행해야 결과를 비교할 수 있습니다 |
| ［시작일과 종료일］ | 피드백이 발생한 기간 | 출시 전후로 한 배치씩 돌리면 새 버전이 문제를 해결했는지 알 수 있습니다 |
| ［피드백 원문］ | 원문 그대로, 한 줄에 하나, 미리 다듬지 않기 | 오타와 감탄사까지 그대로 두세요. 감정 판단은 그 디테일에 달려 있습니다 |
결과를 받은 뒤 추가로 물을 두 가지
첫째는 오분류 점검입니다. "분류하면서 가장 확신이 없었던 항목 10개를 원문, 넣은 카테고리, 망설인 이유와 함께 알려 주세요." 분류 정확도가 집계의 신뢰도를 결정합니다. 수백 개를 다시 읽는 것보다 이 10개를 확인하는 편이 훨씬 수월합니다.
둘째는 상황 파고들기입니다. "P0 문제에서 언급된 사용 상황을 더 쪼개 주세요. 어떤 조작 단계, 어떤 기기나 버전에서 발생했나요? 피드백에 없는 내용은 정보 부족으로 표시하고 추측하지 마세요." 그래야 목록이 개발자가 재현할 조건이 되고, "사용자가 느리다고 한다"에서 멈추지 않습니다.
자주 하는 실수 세 가지
첫째, 붙여 넣기 전에 개인정보를 지우세요. 원문에는 전화번호, 주문번호, 실명이 섞여 있기 쉽습니다. "사용자 A" 같은 대칭으로 바꾼 뒤 붙이고, 사내 데이터 규정이 있으면 승인된 AI 도구를 쓰세요.
둘째, 한 번에 수천 개를 붙이지 마세요. 모델이 꼼꼼히 읽을 수 있는 양을 넘으면 뒷부분 분류가 대충 처리되어 건수가 어긋납니다. 200개 안팎으로 나눠 실행하고, 마지막에 각 배치의 집계표를 다시 붙여 합치게 하면서 숫자를 하나씩 맞추세요.
셋째, 건수가 많다고 가장 중요한 것은 아닙니다. 가격 불만은 목소리가 커지기 쉽지만, 실제로 이탈을 만드는 것은 몇 번만 등장한 결제 실패일 수 있습니다. 프롬프트가 결제 영향을 반영해 순위를 매기는 이유가 바로 이것입니다. 최종 우선순위는 이탈·갱신 데이터와 함께 보세요.
한 번 잘 돌아가면 분류 기준을 고정하고 다음 배치에도 같은 카테고리를 쓰세요. 두 달 치 건수를 나란히 놓으면 어떤 문제가 좋아지고 어떤 문제가 나빠지는지 한눈에 보입니다.
