베타 테스트를 하면 의견이 한꺼번에 들어와요. 이때 같은 의견을 묶어서 세고, 핵심 기능을 막는 문제부터 고치는 게 가장 안전해요. 항목이 많으면 MoSCoW로 "이번에 할 것"을 자르고, 남은 후보를 RICE 점수로 줄 세우면 돼요. 이 글은 처음 서비스를 만든 개발자가 어려운 용어 없이 따라 할 수 있는 순서를 알려드려요.
1단계: 의견을 한 표에 모으세요
먼저 흩어진 의견을 한 곳에 모아요. 스프레드시트면 충분해요.
| 열 | 내용 |
|---|---|
| 의견 | 테스터가 쓴 말 그대로 한 줄 |
| 종류 | 버그 / 불편 / 기능 요청 / 칭찬 |
| 같은 의견 수 | 같은 말을 한 사람이 몇 명인지 |
| 막힘 여부 | 핵심 기능을 못 쓰게 만드나요? |
같은 뜻의 말은 한 줄로 합치고 사람 수만 올려요. 테스터에게 쓰는 요령은 베타 테스트 설문 질문 예시 15개를 참고하면 같은 형식으로 답을 받기 쉬워요.
2단계: 먼저 "막는 문제"를 골라내세요
점수 계산 전에, 아래는 항상 맨 앞줄에 세워요.
- 앱이 꺼지거나 로그인·결제가 안 되는 문제
- 핵심 기능을 시작조차 못 하게 하는 문제
- 개인정보나 보안에 관한 문제
이런 문제는 한 명이 말했어도 먼저 고쳐요. 나머지를 점수로 나눠요.
3단계: MoSCoW로 이번 범위 자르기
MoSCoW는 항목을 4칸으로 나누는 방법이에요. 검색해 본 설명을 기준으로 정리하면 이래요.
| 분류 | 뜻 | 예시 |
|---|---|---|
| Must | 없으면 제품이 제대로 안 돌아가거나 핵심 가치를 못 전해요 | 로그인, 결제 |
| Should | 없어도 돌아가지만 경험이 떨어져요 | 불편한 화면 흐름 |
| Could | 여유가 있을 때 넣는 부가 기능 | 색상 옵션 |
| Won't (이번엔) | 이번 출시에서는 빼요 | 큰 기능 추가 |
Won't는 "영원히 안 한다"가 아니라 "이번엔 안 한다"예요. 항목을 이렇게 나누면 목록이 바로 짧아져요.
4단계: 남은 후보를 RICE로 줄 세우기
RICE는 네 가지를 매겨 점수를 내는 방법이에요. Reach(도달 범위), Impact(영향력), Confidence(신뢰도), Effort(노력)의 앞 글자예요. 보통 (도달 × 영향 × 신뢰도) ÷ 노력으로 계산해요. 참고로 영향력은 0.25~3 정도의 척도로 매기는 설명이 있어요. 도구는 Miro나 ONES 같은 템플릿을 쓸 수 있어요.
베타 피드백에 맞게 이렇게 바꿔 쓰면 쉬워요.
- 도달: 같은 의견을 말한 테스터 수
- 영향: 고치면 쓰기가 얼마나 좋아지나
- 신뢰도: 의견이 믿을 만한가 (여러 명이 말했나, 내가 직접 재현했나)
- 노력: 고치는 데 며칠 걸리나
점수를 믿기 전에 알아둘 점
- 점수는 참고 자료예요. 서비스 방향, 약속한 일정, 다른 기능과의 연결은 점수에 안 나와요.
- 테스터가 적으면 숫자가 흔들려요. 5명이 말한 것과 50명이 말한 것은 무게가 달라요.
- 테스터가 말한 해결책보다 불편에 집중하세요. "버튼을 크게 해주세요"의 진짜 뜻은 "누르기 어려워요"일 수 있어요.
- 한 번에 많이 고치지 말고, 고친 뒤 같은 테스터에게 다시 물어보세요.
피드백은 어디서 모을까요
처음 만든 서비스는 의견을 받을 테스터를 먼저 모아야 해요. Oriber에서는 개발자용 화면에서 스토어 링크로 서비스를 등록하고, 캠페인을 열어 자리·기간·할 일·혜택을 정해요. 할 일에 질문 답변이나 외부 설문 링크를 넣으면, 결과 화면에 추천 지수·의견·기능 사용률이 정리돼요. 등록비와 수수료는 없어요. 혜택(사례비나 유료 기능)은 개발자가 직접 정하고 직접 보내요.
피드백을 받기 전에 테스터를 먼저 모으는 방법은 새 앱 첫 유저 100명 모으는 법에서 이어서 볼 수 있어요. 리뷰나 별점을 혜택 조건으로 걸면 스토어 정책에 걸릴 수 있으니 피하세요.
정리
- 흩어진 의견을 한 표에 모으고, 같은 의견은 합쳐 사람 수를 세요.
- 앱이 막히는 문제는 점수 없이 먼저 고쳐요.
- 항목이 많으면 MoSCoW로 이번 범위를 자르고, 남은 것을 RICE로 줄 세워요.
- 점수는 참고일 뿐, 최종 판단은 개발자가 해요.