우테코 프로젝트에서 서비스 기획을 전면 수정했다. 원래 "커피 내기" 서비스였던 커피빵(CoffeeShout)을, "똥손도 즐기는 게임 기반 추첨 서비스" ZZOL(쫄)로 바꿨다. 왜 바꿨고, 뭘 바꿨는지 기록한다.
원래 기획: 커피빵(CoffeeShout)
커피빵의 출발점은 단순했다. "점심 먹고 커피 누가 살래?"라는 상황이다. 직장인이면 매일 한 번쯤 겪는 장면이고, 대부분 가위바위보로 정한다. 이걸 좀 더 재미있게 만들어보자는 게 기획 의도였다.
핵심 기능은 미니게임 기반 룰렛 시스템이었다. 참여자들이 미니게임을 하면 결과에 따라 룰렛 가중치가 조정되고, 그 확률로 당첨자를 뽑는 구조다. 게임을 잘하면 당첨 확률이 낮아지니까, "운"만이 아니라 "실력"도 개입할 수 있다.
페르소나도 커피에 초점이 맞춰져 있었다. "매일같이 아메리카노를 달고 사는 직장인"이 메인 타겟이었고, 서비스 이름부터 CoffeeShout(커피빵)이었다. 프로젝트 주제도 "똥손도 즐기는 커피빵 전쟁"이었다.
유저가 보여준 진짜 사용 패턴
배포 후 유저 피드백을 받으면서 예상과 다른 패턴이 보이기 시작했다.
유저들은 커피 내기에만 쓰지 않았다. 점심 메뉴 정할 때, 팀 내 잡일 담당 정할 때, 심지어 술자리에서 벌칙 당첨자 정할 때도 쓰고 있었다. "커피"라는 맥락은 우리가 상정한 것이지, 유저에게는 그냥 "누가 걸릴지 정하는 도구"였다.
이 시점에서 두 가지 문제가 보였다.
첫째, 서비스 이름이 사용 범위를 제한하고 있었다. "커피빵"이라는 이름은 커피 내기가 아닌 상황에서 쓰기에 어색하다. 술자리에서 "커피빵으로 정하자"라고 하면 맥락이 안 맞는다. 이름이 곧 서비스의 정체성인데, 그 정체성이 유저의 실제 사용 방식보다 좁았다.
둘째, 기능 세부사항에 불필요한 제약이 있었다. 기존 기획에는 "메뉴 선택"이라는 단계가 있었다. 참여자가 방에 입장한 뒤 자기가 마실 메뉴를 고르는 기능이다. 커피 내기라면 의미 있는 기능이지만, 범용 추첨 서비스에서는 오히려 흐름을 복잡하게 만드는 불필요한 단계였다.
바꾸기로 한 기준
기획을 바꾸는 건 비용이 크다. 이미 구현한 기능도 있고, 팀원들과 합의한 방향도 있다. 그래서 "바꿔야 하는가?"와 "어디까지 바꿀 것인가?"를 구분해서 판단했다.
바꿔야 하는가?
이건 명확했다. 유저의 실제 사용 패턴이 기획 의도와 다르면, 기획을 유저에게 맞추는 게 맞다. 우리가 "이건 커피 내기 서비스입니다"라고 주장해봤자, 유저가 술자리 벌칙용으로 쓰고 있으면 그게 현실이다.
핵심 기능인 "미니게임 → 가중치 조정 → 룰렛 추첨" 흐름 자체는 유저들이 잘 쓰고 있었다. 문제는 이 기능을 감싸고 있는 컨텍스트("커피")가 실제 사용과 안 맞다는 것이었다. 핵심을 버리는 게 아니라 껍데기를 바꾸는 거라면, 비용 대비 효과가 충분하다고 판단했다.
어디까지 바꿀 것인가?
바꾸는 범위를 세 가지로 나눴다.
첫째, 서비스 정체성이다. 이름, 주제, 설명 등 서비스가 뭔지 정의하는 부분. "커피 내기 서비스"에서 "게임 기반 추첨 서비스"로 바꿨다. 이름은 커피빵(CoffeeShout)에서 쫄(ZZOL)로 변경했다. "쫄릴 준비 됐어?"라는 태그라인은 추첨이라는 행위의 긴장감을 담고 있어서, 커피든 술자리든 벌칙이든 맥락을 가리지 않는다.
둘째, 사용자 흐름이다. 기존에 있던 "메뉴 선택" 단계를 제거했다. 대신 방 참여 방식을 강화했다. 초대 코드뿐 아니라 QR 코드와 초대 링크를 추가해서 원클릭 참여가 가능하도록 했다. 추첨 서비스에서 진입 허들을 낮추는 게 더 중요하다고 봤다.
셋째, 페르소나다. "커피 중독 직장인"에서 "팀 내에서 내기를 자주 하는 사용자"로 대전제를 넓혔다. 페르소나의 니즈도 "공짜로 커피를 먹고 싶음"에서 "재미있게 당첨자를 정하고 싶음"으로 바꿨다. 커피가 빠지니까 사용 시나리오가 자연스럽게 넓어진다.
Before vs After
+-------------------------------------------------------------------+
| CoffeeShout vs ZZOL |
+-------------------------------------------------------------------+
| |
| Aspect CoffeeShout ZZOL |
| -----------------------------------------------------------------|
| |
| Scope Coffee bet only Any kind of bet |
| |
| Core flow Join -> Menu select Join -> Mini game |
| -> Mini game -> Roulette |
| -> Roulette |
| |
| Entry method Invite code only Invite code + QR code |
| + Invite link |
| |
| Persona need "Free coffee" "Fun and fair drawing" |
| |
| Pain point "Boring same game" "Same person always |
| gets picked" |
| |
+-------------------------------------------------------------------+안 바꾼 것
바꾸지 않은 것도 명확히 해둔다.
미니게임 → 가중치 조정 → 룰렛 추첨 흐름은 그대로다. 이게 서비스의 핵심이고, 유저들이 실제로 재미있어하는 부분이다. 바꾼 건 이 흐름을 감싸는 맥락이지, 흐름 자체가 아니다.
기술 스택도 바꾸지 않았다. Redis 기반 세션 관리, WebSocket 실시간 통신, Oracle Object Storage QR 코드 저장 등 인프라는 그대로 유지했다. 기획 변경이 기술 부채를 만들지 않도록 범위를 통제한 것이다.
돌아보며
기획을 바꾸면서 느낀 건, 유저의 사용 패턴은 기획서보다 정직하다는 것이다. 우리가 "커피 내기 서비스"라고 정의해도, 유저는 자기한테 편한 방식으로 쓴다. 그 간극을 인지했을 때 기획에 맞춰달라고 할 수는 없다. 서비스가 유저에게 맞추는 게 맞다.
다만 무작정 바꾸는 건 아니다. 핵심 기능이 유효한지, 바꾸는 범위가 통제 가능한지, 기존 기술 자산을 유지할 수 있는지를 따져보고 결정해야 한다. 이번 경우에는 껍데기만 바꾸고 알맹이는 유지하는 전략이 가능했기 때문에 빠르게 전환할 수 있었다.