밥이 보약이다

개밥 먹기 - 제품 체질을 바꾸는 보약 챙겨 먹기

우리는 왜 자꾸 유저가 원하지 않는 걸 만들까

몇 달을 공들여 만든 기능이 출시와 동시에 고민거리가 됩니다.

유저 반응은 냉담합니다. “이게 뭐죠?” “굳이 왜 필요한가요?”

데이터도 기대에 못 미칩니다. 재사용률은 바닥이고, 기대했던 매출은 나오지 않습니다.

분명히 열심히 기획했는데, 대체 어디서부터 잘못된 걸까요?

유저 인터뷰로 목소리를 듣기까지, 시간이 너무 오래 걸렸다. 더 빨리 알았다면 좋았을 텐데

돌아보면 대부분 같은 패턴입니다. 출발은 유저 관점이었는데, 솔루션을 구체화하면서 조금씩 미끄러집니다. 회의를 거듭할수록 "이 정도면 괜찮지 않아?"라는 공급자의 자기만족이 끼어들고요. 어느새 유저가 원하지 않는, 이해하기 어려운 제품이 되고 맙니다.

심지어 기능은 다 잘 만들어놓고 마지막 카피에서 발목이 잡히기도 합니다. '동기화', '갱신', '게스트 모드' 같은 표현들. 만드는 사람은 익숙하지만, 쓰는 사람은 무슨 말인지 모릅니다. "이 정도는 알겠지"라고 생각하는 순간, 이미 유저와 멀어진 겁니다.

유저가 이해하기 쉬운 카피로 재작성된 예시 (좌 -> 우)

그래서 "지금 유저 관점인가?"를 계속 점검하는 장치가 필요합니다. 기획 싱크에서 서로 크로스체크를 하기도 하고, 잘 만들어진 타사 제품과 비교해보기도 하죠. 그중에서 가장 직관적이고 강력한 방법이 하나 있습니다.

개밥 먹기입니다.

개밥 먹기: 가장 빠르게 유저가 되는 법

개밥 먹기는 단순합니다. 우리가 만든 제품을 우리가 직접 써보는 것. 잠시 공급자 뱃지를 내려놓고, 유저의 자리에 앉아보는 겁니다.

제품 사이클 어느 시점에서든 효과가 있습니다. 이미 출시된 기능에서 개선점을 찾을 때. 배포 직전에 마지막으로 훑어볼 때. 아직 프로토타입밖에 없을 때. 심지어 기획 단계에서 타사 서비스를 경험해 보는 것도 넓은 의미의 개밥 먹기입니다.

출처 : 코어스쿼드, 찬의 AI 미션 출시 발표자료

다만 한 가지는 분명합니다. 빨리 먹을수록 좋습니다.

배포 후에 문제를 발견하면 수습이 필요합니다. 개발 완료 후에 발견하면 일정이 틀어집니다. 하지만 기획 단계에서 발견하면? 방향을 바로잡는 데 드는 비용이 훨씬 적습니다. 늦게 먹는 개밥은 약이 되지만, 일찍 먹는 개밥은 예방주사가 됩니다.

어떻게 먹나: 밥 리스트와 개밥 모임

"그냥 자주 써보면 되는 거 아냐?"라고 생각할 수 있습니다. 맞는 말인데, 그게 잘 안 되니까 문제입니다. 독서가 좋은 줄 알면서도 책을 안 펴고, 운동이 좋은 줄 알면서도 헬스장을 안 가는 것처럼요.

저희 팀은 이걸 시스템으로 만들었습니다.

첫째, 밥 리스트를 운영합니다. 주기적으로 써봄직한 타사 제품이나 우리 제품의 특정 플로우를 리스트업 해둡니다. "이번 주는 OO 기능 플로우", "이번 주는 경쟁사 A의 결제 경험" 같은 식으로요.

둘째, 함께 먹습니다. 혼자 먹으면 대충 먹게 됩니다. 같이 먹으면 꼼꼼히 씹게 되고, 서로 다른 관점이 부딪히면서 혼자서는 못 보던 게 보입니다.

셋째, 제품 개선에 반영합니다. 먹으면서 느낀 불편함, 의문, 아이디어를 그 자리에서 남기고, 기획 시드로 활용합니다.

실제로 효과를 본 사례가 많습니다.

미니 게임 형태의 이벤트 기능을 만들 때였어요. 제한 시간 안에 미션을 성공하면 추첨 대상이 되는, 단순한 구조였습니다. 어떤 형태의 게임이 재밌을지, 난이도는 어느 정도가 적당히 짜릿한지, 시간이 얼마 안 남았을 때 경고가 뜨면 더 몰입되는지 — 전부 직접 해보면서 정했습니다. 회의실에서 "이 정도면 되지 않을까?"라고 넘어갔던 부분들이, 직접 해보니까 전혀 다르게 느껴졌거든요.

캐릭터 육성 기능을 만들 때도 마찬가지였습니다. 직접 플레이해 보니까 보이는 것들이 있었어요. "왜 여기서 갑자기 광고가 나오지?", "이 버튼 눌러도 되는 건가?", "기다리는 시간이 왜 이렇게 길게 느껴지지?"

기획서에서는 문제가 없어 보였던 것들이, 유저 자리에 앉으니까 바로 드러났습니다.

완벽하진 않아도, 방향은 맞습니다

솔직히 개밥 먹기에는 한계가 있습니다. 아무리 유저인 척해도, 우리는 기획 의도를 알고 있고 전체 맥락을 이해하고 있습니다. 진짜 유저의 첫인상을 완벽히 재현할 수는 없어요. 그래서 VoC, 유저 인터뷰, 서베이 같은 방법들을 병행해야 합니다. 유저의 목소리를 직접 듣는 건 대체 불가능한 가치가 있으니까요.

그럼에도 개밥 먹기만의 쓸모가 분명히 있습니다.

일단 빠릅니다. 인터뷰 섭외하고 질문지 만들고 일정 잡는 사이에, 개밥은 열 번도 더 먹을 수 있습니다. 별도의 리소스 없이, 지금 당장 시작할 수 있어요.

그리고 이게 쌓이면 체질이 바뀝니다. 기능을 설계할 때 "유저가 이걸 어떻게 느낄까?"가 먼저 떠오르게 됩니다. 나만 그렇게 되는 게 아니라, 같이 먹는 동료들 — 기획자, 디자이너, 개발자 — 전부 같은 방향을 보게 됩니다. 좋은 개선 아이디어를 발굴하기도 하고, 출시 전에 치명적인 문제를 잡기도 합니다. 당장의 성과도 있지만, 팀 전체가 유저를 향해 정렬되는 것 — 그게 더 큰 수확입니다.

다음 주 팀 미팅에서 밥 리스트 하나만 정해 보세요. 거기서 시작하면 됩니다.

처음엔 어색해도 괜찮습니다. 한 번 맛보면 자꾸 손이 가거든요..!