수백 건의 사용자 문의를 PM이 직접 분류하기까지

PM 일을 하면서 유저 피드백은 묘한 위치에 있다. 중요하다는 건 누구나 안다. 그런데 매일매일 들여다보는 사람은 의외로 적다. (나만 그럴수도 있다..)

CS 인입, 파트너사 리뷰, 파트너사 질의응답, 인터뷰 메모, 피드백 등 종류는 많고 양은 더 많다. 한 번에 다 보기에는 너무 많고, 데이터팀에 부탁하기에는 너무 사소하고, 그렇다고 안 보면 영영 안 본다.

이 글은 그 “너무 많고 너무 사소한” 영역의 자료들을 PM이 직접 분류해서 데이터 지표로 만들어 어떻게 프로젝트를 착수하게 되었는지를 작성해보려고한다.

그 데이터는 늘 쌓이는데 보는 사람은 없었다

실제 새롭게 팀을 운영하고있는데 우리 팀이 운영하는 슬랙 채널에 사용자 문의가 일 년 사이에 300건 가까이 쌓여있다. 외부 파트너사에서 흘러들어오는 문의가 대부분이었고, 일부는 다른 유관부서 채널에서 옮겨진 것들이었다. 양은 적지 않은데 세심하게 들여다볼 시간은 없었고, 한 건 한 건 빠르게 해결하기 바쁘다. 모든 구성원들이 빠르게 질문에 답변을 하려고 노력하고있지만, 같은 질문이 계속 반복되거나, 해결해야하는 방법이 같을 때도 많다.

사실 문제는 명확했다. “데이터팀에 부탁할 정도는 아니고, 내가 직접 보기엔 너무 많고, 그렇다고 안 보면 영영 안 본다.”

ChatGPT 창에 한 건씩 붙여넣어 보긴 했다. 그런데 한 건씩 보는 건 결과가 일관성이 없었다. 어떤 건 “기능 요청”으로, 어떤 건 “버그 리포트”로, 어떤 건 “UX 불만”으로 분류됐는데, 같은 종류의 문의인데도 표현이 약간 다르면 다른 카테고리로 잡혔다. 그래서 분류 결과를 모아도 그 위에서 다시 의사결정을 하기엔 신뢰가 가지 않았다.

일단 한 폴더로 모았다

첫 단계는 데이터를 한 형식으로 모으는 거였다. 슬랙 채널의 메시지를 CSV로 export하고, 인앱 피드백 폼의 답변을 같은 포맷으로 정리하고, 인터뷰 메모는 마크다운으로. 모두 user-feedback/{이번분기}/raw/ 폴더에 던졌다.

각 파일에는 최소한의 메타데이터만 넣었다. 날짜, 유입 채널, 익명화된 식별자.

회사 정보가 들어간 부분은 이 단계에서 다 제거했다. 파트너사 이름, 담당자 이름, 매출 정보 같은 건 마스킹 처리했다.

폴더에 데이터가 모이고 나니까, 그 다음부터는 분류 작업이 가능해졌다.

분류 기준을 먼저 한 파일로 적었다

가장 결정적이었던 단계는 사실 이거였다. 분류 기준을 한 파일로 적어두는 일.

user-feedback/CLAUDE.md에 분류 카테고리를 미리 정의했다. 6개 카테고리, 각 카테고리의 정의, 경계 케이스 처리 규칙. 예를 들어 “기능 요청”과 “정보부족”의 차이는 뭔지, 둘 다에 해당하는 경우는 어디로 분류할지를 명문화했다. 약 한 페이지짜리 문서였다.

이 한 페이지가 일관성의 핵심이었던 것 같다. ChatGPT에서 분류했을 때 결과가 들쭉날쭉했던 이유는, 매번 분류 기준이 머릿속에 있는 채로 다른 단어로 설명했기 때문이었다. 분류 기준을 파일로 만들어두니 다음 100건도, 그 다음 100건도 같은 기준으로 분류됐다.

분류 자체는 그 다음에 슬래시 커맨드 하나로 해결됐다. /cluster-feedback 같은 형태로, raw 폴더의 전체 데이터를 읽고 카테고리별로 묶어서 정량적 우선순위(언급 빈도 × 영향 추정)와 함께 정리해주는 워크플로우였다.

결과를 의사결정에 어떻게 썼나

분류 결과만으로는 의사결정이 안 된다. 분류된 결과를 들고 이걸 어떻게 읽을지가 PM의 영역이라고 생각한다.

가장 명확한 사례 하나만 적자면, 그 300여 건 분류 결과에서 한 카테고리가 압도적으로 많았다. “특정 기능에 대한 반복적인 질문들이 있었다”는 기능에 대한 API문서나 별도 안내되는 정책서의 설명이 부족했고, 그 외에도 별도로 물어보지 않고도 파트너사가 자체적으로 답변 받을 수 있는 것이 있었다. 그래서 그 다음 스프린트에 작업이 잡혔다. **“API 문서를 업데이트하자” 그리고 그 다음 단계로는 “파트너사가 자주 묻는 질문을 LLM 으로 챗봇화 해보자” 는 프로젝트 구상까지도 발전했다.

이게 단순 시간 절약이 아니라 PM이 1차 분석을 직접 할 수 있게 된 것의 의미였다. 데이터팀에 부탁했다면 우선순위에 밀려서 2~3주 뒤에 받았을 결과를, 그 주 안에 의사결정에 썼다는 점이 가장 컸다.

내가 만든 skill 파일

분류 작업의 핵심은 사실 슬래시 커맨드 자체보다 분류 기준을 적어둔 파일이다. 두 파일을 같이 둬야 동작한다.

user-feedback/CLAUDE.md (분류 기준 정의):

# 사용자 문의 분류 기준

이 폴더의 raw/ 데이터를 분류할 때 사용하는 기준 문서.
새 분류를 임의로 추가하지 말고, 필요하면 이 파일을 먼저 수정한다.

## 카테고리 (총 6개)

1. **버그 리포트**: 의도된 동작과 다르게 나타나는 현상에 대한 보고.
   "안 된다", "오류가 났다" 같은 표현이 핵심.
2. **기능 요청**: 현재 없는 기능을 만들어달라는 요청.
   "이런 게 있으면 좋겠다", "왜 X 기능이 없냐"가 핵심.
3. **문서 제공 안됨**: API 문서나 기능적인 설명이 없어 기능은 동작하는데 사용성, 발견성에 대한 불만.
   "어디 있는지 모르겠다", "이게 왜 이래야 하나"가 핵심.
4. **성능, 속도**: 동작은 되는데 느리거나 무거움.
5. **기타**: 위 5개에 안 들어가는 것. 자주 보이면 카테고리 신설 검토.

## 경계 케이스 처리

- 버그 + 문서 제공안됨과 같이 있는 경우: 사용자가 "안 된다"고 명시하면 버그, "확인하기 어렵다"면 문서제공 안됨 불만.
- 기능 요청 : 기존 기능 개선이면 UX 불만, 아예 새 기능이면 기능 요청.
- 분류 불가능한 경우: "기타"으로 두고 사유를 한 줄 적는다.

## 임의 분류 금지

- 새 카테고리를 임의로 추가하지 않는다.
- 정의에 안 맞으면 "기타"으로 둔다.
- 카테고리 추가가 필요해 보이면 분류 결과 끝에 제안만 남긴다.

~/.claude/commands/cluster-feedback.md (분류 워크플로우):

---
name: cluster-feedback
description: user-feedback/raw 폴더의 데이터를 CLAUDE.md 기준으로 클러스터링
---

1. `user-feedback/CLAUDE.md`를 먼저 읽고 카테고리 정의를 메모리에 둔다.
2. `user-feedback/{이번분기}/raw/` 폴더의 모든 데이터를 읽는다.
3. 각 건을 6개 카테고리 중 하나로 분류한다. 정의에 정확히 맞지 않으면 "기타, 잡담"으로.
4. 카테고리별로 묶고, 각 묶음 안에서 표현이 유사한 것끼리 sub-cluster를 만든다.
5. 정량 우선순위를 계산한다. (언급 빈도 × 영향 추정 가중치)
6. 결과를 `user-feedback/{이번분기}/clustered.md`에 저장한다.

규칙:
- 비식별화 검증: 분류 결과에 파트너사 이름, 실명, 매출이 남아 있으면 작업 중단.
- 환각 방지: 데이터에 명시되지 않은 영향 추정은 "추정"임을 표시.
- 분류 신뢰도가 낮은 건은 별도 `low-confidence.md`에 모아 사람 검수.

이 두 파일이 같이 있어야 분류가 일관성 있게 결과가 되었다. 슬래시 커맨드 한 줄로 끝나는 작업처럼 보이지만, 사실은 CLAUDE.md의 한 페이지를 잘 적어두는 작업이 90% 정도 되는 것 같다. 그리고 한 번 적어둔 분류 기준이라도, 새로운 문의가 들어오면 한두 줄씩 다시 손보게 된다. 이것도 지속적으로 우리가 수집하는 질문에 대해서 업데이트 해야 원하는 결과가 나오게 된다.