# 테스터 운영 허브 실행계획

작성일: 2026-06-28  
작성 위치: `/Users/neo/Documents/제품관리`  
목적: Google Play 비공개/내부 테스트가 테스터 부족으로 정체되는 문제를 풀기 위해, 제품별 진행상태와 테스터 유입/소통을 하나의 운영 체계로 묶는다.

## 한 줄 결론

지금 필요한 것은 앱별 추가 개발보다 **테스터 모집, 안내, 피드백 회수, 진행상태 확인을 묶는 운영 허브**다. 우선은 Notion/Google Form/오픈채팅/정적 대시보드 조합으로 빠르게 시작하고, 이후 사용량이 생기면 별도 웹앱으로 전환한다.

## 현재 병목

| 병목 | 현재 영향 | 필요한 기능 |
| --- | --- | --- |
| 테스터 수 부족 | Play Console에 올려도 공개 출시 조건 충족이 늦어짐 | 자연 유입용 신청 페이지, 초대 링크, 제품별 테스트 미션 |
| 테스터와의 소통 부족 | 설치 실패, 계정 불일치, 피드백 누락이 반복됨 | 공지 채널, FAQ, 상태별 안내 메시지, 피드백 접수 |
| 제품 상태가 흩어짐 | 어떤 앱이 출시/검증/모집 단계인지 한눈에 보기 어려움 | 제품별 진행률, 다음 작업, 차단 이슈, 테스터 수 대시보드 |
| 피드백이 실행으로 연결되지 않음 | 테스트 참여가 제품 개선으로 이어지는 속도가 느림 | 이슈 분류, 우선순위, 반영 상태, 재테스트 요청 |

## 운영 허브 구성

### 1. 테스터 자연 유입 창구

목표는 “테스터가 왜 참여해야 하는지 이해하고, 바로 신청하고, 바로 설치까지 가는 것”이다.

필수 요소:

| 요소 | 내용 |
| --- | --- |
| 공개 소개 페이지 | 현재 테스트 중인 앱 목록, 앱별 한 줄 설명, 참여 보상/의미, 신청 버튼 |
| 신청 폼 | 이름/닉네임, 이메일, Android 사용 여부, 관심 앱, 연락 가능한 채널 |
| 앱별 테스트 링크 | Play 내부 테스트 링크 또는 준비 중 표시 |
| 참여 미션 | “설치해보기”, “첫 결과 만들기”, “친구에게 공유하기”처럼 3분 안에 이해되는 과제 |
| 공유 문구 | 카카오톡/문자/메일에 바로 붙여 넣을 짧은 모집 메시지 |

처음에는 별도 개발 없이 Google Form + 정적 HTML 소개 페이지로 충분하다.

### 2. 테스터 커뮤니케이션 창구

테스터는 설치 전후에 막히는 지점이 많으므로, 소통 창구는 “질문방”이 아니라 운영 흐름이어야 한다.

권장 채널:

| 채널 | 역할 |
| --- | --- |
| 카카오 오픈채팅 또는 Telegram | 공지, 설치 막힘 대응, 빠른 질문 |
| Google Form | 구조화된 피드백 수집 |
| Gmail 템플릿 | 부모님/지인/기존 테스터에게 앱별 초대 발송 |
| 제품관리 대시보드 | 모집 수, 설치 이슈, 피드백 반영 상태 확인 |

필수 메시지 템플릿:

| 상황 | 템플릿 목적 |
| --- | --- |
| 신규 초대 | 어떤 앱을 왜 테스트하는지, 링크와 첫 미션 안내 |
| 설치 실패 | Play 계정 확인, 기존 설치 앱 삭제, 테스트 링크 재접속 안내 |
| 피드백 요청 | 너무 길지 않은 3문항 회수 |
| 업데이트 공지 | 이번 버전에서 무엇을 다시 봐야 하는지 안내 |
| 감사/재참여 요청 | 반영된 피드백과 다음 테스트 미션 안내 |

### 3. 제품 진행상태 대시보드

대시보드는 “개발 상태표”가 아니라 “출시까지 무엇이 막혀 있는지 보는 표”여야 한다.

표시 항목:

| 항목 | 의미 |
| --- | --- |
| 제품명 | 오늘의밥, Planet Merge, 밥크로스, MoodType, 로컬 밈보드 |
| 현재 단계 | 기획, 개발, 내부 테스트, 비공개 테스트, 출시 준비 |
| 테스터 상태 | 필요 인원, 현재 확보, 부족 인원 |
| 커뮤니케이션 상태 | 공지 채널, 신청 폼, FAQ, 피드백 폼 |
| 다음 작업 | 지금 가장 먼저 해야 할 1개 작업 |
| 차단 이슈 | 테스터 부족, 설치 실패, 스토어 문서, 서명, 제품 완성도 등 |
| 우선순위 | 이번 주 집중 여부 |

## 제품별 운영 방향

| 제품 | 운영 판단 | 이번 주 초점 |
| --- | --- | --- |
| 오늘의밥 | 주력 사업화 후보. 테스트 모집을 가장 먼저 붙일 앱 | 생활권/점심 문제로 테스터 모집 메시지 만들기 |
| Planet Merge | 게임이라 가벼운 테스트 유입이 쉬움. 광고 실험 후보 | 첫 판 이해도와 5분 플레이 피드백 회수 |
| 밥크로스 | 독립 수익화보다 그룹 의사결정 자산으로 관리 | 설치/권한/참여 마찰을 정리해 Todaybap 이식 후보 추출 |
| MoodType | 새 제품 기획/구현 준비 단계 | 관심 대기자 모집과 콘셉트 반응 확인 |
| 로컬 밈보드 | 초기 출시 준비 전 단계 | 보안/권한/스토어 문서 정리 전까지 낮은 우선순위 |

## 7일 실행 순서

| 일자 | 작업 | 산출물 |
| --- | --- | --- |
| 1일차 | 테스터 운영 허브 기본 구조 확정 | 이 문서, 정적 HTML 대시보드 |
| 2일차 | Google Form 1개 생성 | 공통 테스터 신청 폼 |
| 3일차 | 앱별 첫 미션 작성 | 오늘의밥/Planet Merge/밥크로스 미션 카드 |
| 4일차 | 공지 채널 개설 | 오픈채팅 또는 Telegram 링크 |
| 5일차 | 기존 지인/테스터에게 초대 발송 | 앱별 초대 메일/문자 |
| 6일차 | 첫 피드백 정리 | 설치 실패, 이해도, 재사용 의향 분류 |
| 7일차 | 대시보드 업데이트 | 제품별 상태/부족 테스터/다음 작업 갱신 |

## 바로 만들 기능 목록

우선순위 1:

| 기능 | 구현 방식 |
| --- | --- |
| 제품별 진행상태 대시보드 | 정적 HTML 파일로 시작 |
| 공통 테스터 신청 링크 자리 | Google Form URL을 나중에 삽입 |
| 앱별 테스트 미션 카드 | 문서/HTML에 고정 표시 |
| 피드백 수집 폼 자리 | Google Form URL을 나중에 삽입 |

우선순위 2:

| 기능 | 구현 방식 |
| --- | --- |
| 테스터 연락처 CSV 관리 | 로컬 Markdown/CSV |
| 초대 메시지 템플릿 | 제품별 문구 파일 |
| 피드백 반영 상태표 | 제품별 Done/Doing/Blocked 표 |

우선순위 3:

| 기능 | 구현 방식 |
| --- | --- |
| 실제 웹앱화 | 간단한 Next.js 또는 Firebase Hosting |
| 신청자 자동 분류 | Google Sheets 연동 |
| 테스트 미션 완료 체크 | 폼 응답 기반 수동/자동 집계 |

## 운영 원칙

1. 테스터에게는 “테스트해주세요”보다 “3분 안에 이것만 확인해주세요”라고 요청한다.
2. 앱별로 다른 신청 폼을 만들지 말고, 공통 신청 후 관심 제품을 선택하게 한다.
3. Play Console 상태, 테스터 수, 설치 실패, 피드백 반영 상태를 분리해서 본다.
4. 오늘의밥은 주력 유입 제품, Planet Merge는 가벼운 게임 테스트 제품, 밥크로스는 그룹 결정 기술 검증 제품으로 운영한다.
5. 대시보드는 매일 완벽하게 갱신하기보다, 이번 주 차단 이슈와 다음 작업이 틀리지 않게 유지한다.