- 게스트 수요를 미리 알 수 없음
- 매주 반복되는 모집 업무
- 채널마다 흩어진 모집 현황
- 직전 취소로 인한 높은 부담
- No visibility into guest demand
- Weekly repetitive recruitment tasks
- Recruitment status scattered across channels
- High burden from last-minute dropouts
[ 01 — Overview ]
모집은 짧게,
농구는 길게
Spend less time recruiting,
more time playing
수년간 아마추어 농구 경기의 게스트 모집은 메신저, 커뮤니티 카페 게시글, 댓글, 문자, 수기 입금 확인으로 흩어진 과정에 의존해 왔습니다. Shoot Shoot Penguin은 이 반복적인 업무를 하나의 시스템으로 묶어, 운영자는 경기를 더 효율적으로 운영하고 플레이어는 참여할 경기를 쉽게 찾을 수 있게 합니다.
For years, recruiting guest players for amateur basketball games relied on a fragmented process — Messenger, community cafe posts, comments, texts, and manual payment checks. Shoot Shoot Penguin ties this repetitive workflow into one system, so organizers run games more efficiently and players find games to join with ease.
Shoot Shoot Penguin
TWO-SIDED PLATFORM
PREDICTION UX
MOBILE APP
IN DEVELOPMENT
ROLE
Product Designer
SCOPE
프로덕트 기획 · IA · UX/UI · 프로토타입 · 개발 핸드오프
Product planning · IA · UX/UI · Prototype · Developer handoff
DURATION
24주 · 개발 진행 중
24 weeks · in development
TEAM
1 Designer · 1 Developer
[ 02 — The Problem ]
경기는 매주 정해져 있었지만,
참가 인원은 정해져 있지 않았습니다.
Games were fixed every week.
The players weren't.
함께한 개발자가 농구팀을 운영하며 매주 겪던 문제였습니다. 정기 팀에는 정해진 체육관과 일정이 있지만, 농구는 팀 스포츠라 인원이 채워져야 비로소 경기가 성사됩니다. 그래서 경기 전마다 같은 사이클이 반복됐습니다. 참석 인원을 조사하고, 부족한 인원을 계산하고, 카카오톡 채팅방과 커뮤니티에 게스트 모집글을 올리고, 입금을 하나하나 확인하는 일. 이미 잡혀 있는 경기를 지키기 위해 매주 일곱 단계의 수작업을 거쳐야 했습니다.
This was a problem my developer teammate lived every week while running his basketball team. Regular teams have fixed gyms and schedules — but basketball is a team sport, and a game only happens when the roster is filled. So the same cycle repeated before every game: polling attendance, counting the shortfall, posting guest recruits to KakaoTalk chats and forums, and checking payments by hand. Seven manual steps, every week, just to protect a game that was already scheduled.
기존 워크플로 — 7단계
Existing workflow — 7 steps
- 01참석 인원 체크Attendance check
- 02플레이어 부족Player shortfall
- 03게스트 모집 공고Guest recruiting post
- 04댓글·메시지로 참가 받기Sign-ups via comments & DMs
- 05게스트비 입금 안내Payment guide
- 06입금 확인Payment check
- 07경기 관리Game management
모든 경기는 매주 이 일곱 단계를 거치고 있었습니다. Every game went through these seven steps, every week.
- 주변 경기를 찾기 어려움
- 실력에 맞는 경기를 찾기 어려움
- 지금 모집 중인 경기를 실시간으로 알기 어려움
- Difficult to find nearby games
- Difficult to find games that match their skill level
- Difficult to see which games were actively recruiting in real time
[ 03 — The Core Question ]
경기 출석 데이터로, 게스트가
몇 명 필요할지 미리 알 수 있다면?
What if attendance data could
predict how many guests we'd need?
진짜 과제는 모집 과정을 단순화하는 것이 아니었습니다. 운영자는 경기 전마다 부족한 인원을 손으로 계산했고, 그동안 출석 데이터는 조용히 쌓이기만 할 뿐 수요를 예측하거나 판단을 돕는 데 한 번도 쓰이지 않았습니다. 이 질문이 Shoot Shoot Penguin의 출발점이 되었습니다.
The real challenge wasn't simplifying recruitment. Organizers calculated the shortfall by hand before every game — while attendance data quietly piled up, never once used to predict demand or support the decision. That question became the starting point for Shoot Shoot Penguin.
출석 패턴
Attendance Patterns
누적 데이터
Historical Data
게스트 수요 예측
Guest Demand Prediction
[ 04 — System Architecture ]
출석 데이터가 필요한 게스트 수를 예측하고, 예측 결과는 모집글을 자동으로 생성합니다. 모집 중인 경기는 게스트 지도에 노출되어 쉽게 발견되고, 신청 데이터는 다시 시스템으로 돌아와 다음 예측을 개선합니다.
Attendance data predicts how many guests are needed, and predictions auto-generate recruitment posts. Open games surface on the guest map for easy discovery, and applications flow back in — improving the next prediction.
출석 데이터Attendance Data
수요 예측Demand Prediction
자동 모집Auto Recruiting
지도 노출Map Exposure
신청Application
예측 개선Prediction Improvement
[ 05 — Side A · For Team Leads ]
한 번만 설정하면,
시스템이 다음 경기를 준비합니다.
Set it up once.
The system prepares the next game.
경기마다 운영자는 같은 일을 반복해야 했습니다. 출석 투표를 만들고, 부족한 인원을 계산하고, 모집 공고를 올리는 일. 이 반복되는 과정을 자동화했습니다.
Every game required organizers to repeat the same workflow — creating attendance polls, calculating missing players, and posting recruitment notices. Our solution automated this recurring process.
-
01.
일정 등록Schedule정기 일정 등록Recurring Game Schedule팀을 만들 때 정기 경기 일정을 등록합니다.Register recurring game schedules when creating a team.
-
02.
자동 투표Auto Poll자동 출석 투표Automatic Attendance Polls경기 일정에 맞춰 출석 투표가 자동으로 생성됩니다.Attendance polls are generated automatically from the game schedule.
-
03.
예측 결과Prediction게스트 수요 예측Guest Demand Prediction누적된 출석 데이터로 필요한 게스트 수를 예측합니다.Predict how many guests are needed from historical attendance data.
-
04.
자동 모집Auto Post모집글 자동 생성Automatic Recruitment Posts예측 결과를 바탕으로 모집글이 자동 생성됩니다.Recruitment posts are generated automatically from the prediction results.
-
05.
지도 노출Map게스트 지도 노출Guest Map Visibility모집 중인 경기가 주변 플레이어의 지도에 자동으로 노출됩니다.Open games are displayed on the guest map for nearby players.
경기가 쌓일수록 시스템은 누적된 출석 데이터를 학습해 예측 정확도를 계속 높여갑니다.
As more games are played, the system learns from accumulated attendance data, continuously improving its prediction accuracy.
[ 06 — Side B · For Players ]
지금 바로 뛸 수 있는
경기를 찾습니다.
Find games you can join
right now.
게스트 플레이어가 원한 것은 경기 목록이 아니었습니다. "오늘 어디서 뛸 수 있지?"라는 질문에 대한 빠른 답이었습니다. 그래서 지도 중심의 경험을 선택했습니다.
Guest players didn't want a list of games — they wanted a fast answer to one question: "Where can I play today?" So we chose a map-first experience.
-
01.
지도 탐색Map Discovery주변 경기 발견Discover Nearby Games지금 모집 중인 주변 경기를 지도에서 한눈에 확인합니다.See games recruiting near you at a glance, right on the map.
-
02.
조건 필터Filters조건 필터Filter by Conditions위치·시간·경기 유형으로 원하는 경기만 걸러냅니다.Narrow games down by location, time, and game type.
-
03.
즉시 신청Instant Apply즉시 신청Instant Application마음에 드는 경기에 바로 신청하고 확정 여부를 확인합니다.Apply to a game right away and track your confirmation.
예전에는 커뮤니티 글을 뒤져 경기를 찾았습니다. 이제는 지도 위에서 참여 가능한 주변 경기를 바로 발견합니다.
Players used to dig through community posts to find a game. Now they discover joinable games nearby, right on the map.
[ 07 — Key Decisions & Collaboration ]
제품을 만들 때 내린 네 가지 결정
Four decisions that shaped the product
두 사용자를 하나의 시스템으로One system, two sides
팀 리드와 플레이어를 각각의 앱으로 나누지 않고 하나의 시스템으로 묶었습니다. 두 니즈가 서로 다른 문제가 아니라 같은 데이터 흐름의 양쪽 끝이라고 판단했기 때문입니다.
We judged that team leads and players belonged in one system rather than two separate apps, because their needs aren't different problems — they're two ends of the same data loop.
목록이 아니라 지도 먼저Map before list
플레이어 화면의 기본을 목록이 아닌 지도로 정했습니다. "오늘 어디서 뛸 수 있지?"는 결국 위치에 대한 질문이라고 판단했기 때문입니다.
We judged the player's default view should be a map rather than a list, because "where can I play today?" is fundamentally a question about location.
예측은 확정이 아니라 제안으로Prediction as a suggestion, not a decision
예측 결과를 자동으로 확정하지 않고, 운영자가 조정할 수 있는 제안으로 설계했습니다. 초기에는 데이터가 적어 예측이 빗나갈 수 있고, 경기에 대한 최종 책임은 운영자에게 있다고 판단했기 때문입니다.
We judged predictions should arrive as an editable suggestion rather than an automatic decision, because early data is sparse and the organizer still owns the final call on the game.
기존 채널을 대체하지 않기Don't replace the channels people already use
카카오톡과 커뮤니티를 대체하는 대신, 생성된 모집글을 그대로 내보낼 수 있게 했습니다. 사용자의 습관을 바꾸는 것보다 기존 흐름 위에 얹는 편이 실제로 쓰일 가능성이 높다고 판단했기 때문입니다.
We judged the product should export recruitment posts into KakaoTalk and forums rather than replace them, because riding an existing habit gets adopted faster than asking people to change one.
개발자와 함께 제품 방향과 핵심 기능을 정의하고, 유저 플로우부터 디자인 시스템, 개발 핸드오프까지 디자인 전 과정을 단독으로 리드했습니다.
Collaborated with a developer to define product direction and core features, while independently leading the end-to-end design process — from user flows to design system to developer handoff.
[ 08 — Where It Stands ]
개발 진행 중 — 측정할 준비까지 설계했습니다
In development — designed to be measured
백엔드 개발이 진행 중이며, 핵심 플로우와 디자인 시스템은 핸드오프를 마쳤습니다. 첫 클로즈드 베타는 개발자가 소속된 회사에서 시작할 예정입니다.
Backend development is in progress; core flows and the design system are handed off. The first closed beta will start at the developer's company.
↑
수동 모집 없이 성사된 경기 비율Games filled without manual recruiting
↓
모집 소요 시간Time to recruit
↓
노쇼율No-show rate
↑
게스트 재신청률Guest re-application rate
베타에서 검증할 지표 — 아직 측정 전입니다. Metrics to validate in beta — not yet measured.
이 프로젝트는 화면이 아니라 시스템을 설계하는 법을 가르쳐줬습니다. 두 사용자의 니즈를 하나의 흐름으로 연결하는 일 — 그리고 그것을 첫날부터 개발자와 함께 하는 일은 디자인 방식 자체를 바꿨습니다. 모든 결정이 구현 가능성의 검증을 통과해야 했기 때문입니다. 검증은 다음 챕터이고, 제품은 측정될 준비가 되어 있습니다.
This project taught me to design a system, not screens. Connecting two users' needs into a single flow — and doing it alongside a developer from day one — changed how I design, because every decision had to survive a feasibility check. Validation is the next chapter; the product is ready to be measured.