최근 프로덕트를 운영하며 "유저를 위한 친절함이 때로는 우리 팀을 고통스럽게 만들 수 있다"는 교훈을 얻었습니다. 피드백 페이지의 높은 자유도가 팀에 어떤 부담을 주었는지, 그리고 UX 구조를 바꿔 이를 어떻게 해결했는지 공유합니다.
문제 상황: 높은 자유도가 만든 운영 부채
기존 피드백 페이지는 제약이 거의 없는 개방형 UI로 설계되어 있었습니다. 그 결과 전체 게시글의 약 절반이 버그 제보에 치중되었고, 공개 게시판에 오류가 노출되면서 팀원들은 실시간 해결에 대한 과도한 압박을 느끼고 있었습니다.
버그 게시판이 돼버린 느낌이라 아쉬워요
유저들과 활발하게 소통하는 공간이 되길 바랐는데...
버그가 모든 유저들이 보는 공간에 올라오니까
해결에 대한 압박감이 커졌고, 리소스가 과도하게 쏠려요
UX 구조적으로 해결할 수 있을 것 같아요, 한번 해볼게요 💪
이 이야기를 듣고, UX 구조를 바꿔서 해결할 수 있겠다고 판단해 직접 개선에 착수했습니다.
접근 방식: 포카요케(Poka-yoke)와 UX 프레이밍
문제의 본질은 명확했습니다. 개방형 UI가 유저에게 '버그 신고 창구'라는 잘못된 멘탈 모델을 형성하고 있었고, 이로 인해 팀은 비공개로 처리할 수 있는 오류까지 공개 게시판에서 실시간으로 대응해야 하는 상황이었습니다.
이 문제를 해결하기 위해 제조업의 '포카요케(Poka-yoke)' 개념을 참고했습니다. 포카요케란 일본어로 '실수를 방지한다'는 뜻으로, 토요타의 시게오 신고가 고안한 품질 관리 기법입니다. 사용자가 실수하려 해도 시스템이 올바른 방향으로 자연스럽게 유도하는 것이 핵심입니다.
이 원리를 피드백 페이지에 적용하면, 유저가 잘못된 채널에 버그를 제보하려 해도 시스템이 직관적으로 올바른 경로(채널톡)를 안내하고, 피드백 페이지 자체는 '아이디어 보드'로 프레이밍하여 기능 제안 중심의 행동을 자연스럽게 유도할 수 있습니다. 무조건적인 자유 대신 '적절한 제약'을 두어, 유저에게는 명확한 가이드를 제공하고 팀에게는 안정적인 운영 환경을 보장하는 것이 핵심 전략이었습니다.
세 가지 UX 장치
UX Engineer로서 유저의 행동 의도를 '제안'으로 가이드하고, 팀의 운영 리소스를 확보하기 위해 세 가지 장치를 도입했습니다.
태그 입력의 구조화
포카요케의 핵심인 '적절한 제약'을 가장 직접적으로 적용한 부분입니다. 자유로운 태그 입력 대신 '기능 요청', '개선 제안', '질문', '기타' 중 목적에 맞는 유형 선택을 필수화했습니다. 유저가 글을 작성하는 시점부터 제안 방향으로 프레이밍되도록 유도하여 데이터의 질을 개선했습니다.
공간의 재정의 + 채널 분리
페이지 명칭을 '아이디어 보드'로 변경하고, 제안이 실제 기능으로 이어진다는 점을 강조하여 공간의 목적성을 명확히 했습니다. 동시에 상단에 "버그 제보는 채널톡이 가장 빠릅니다"라는 안내와 함께 별도 이동 경로를 배치하여, 유저에게는 '빠른 해결'을, 팀에게는 '비공개 대응을 통한 운영 안정성'을 제공했습니다.
상태 Chip의 역할 변경
기존에는 '진행중', '미해결' 같은 버그 트래킹 목적의 상태 Chip이 게시글마다 표시되어, 피드백 페이지 전체가 오류 현황판처럼 보이는 문제가 있었습니다. 이를 '반영됨' Chip만 선택적으로 표시하는 방식으로 변경했습니다. 유저가 피드백 페이지에 들어왔을 때 가장 먼저 눈에 띄는 것이 '내 의견이 실제로 반영되었다'는 성공 경험이 되도록 의도한 것입니다. 부정적인 상태 대신 긍정적인 결과만 노출함으로써, 이 공간이 '문제를 제보하는 곳'이 아니라 '아이디어가 실현되는 곳'이라는 인상을 심어주고자 했습니다.
결과: 초기 데이터가 보여주는 방향성
개선 배포 후 3일간의 초기 데이터(10건)를 기존 29일간의 데이터(122건)와 비교했습니다. 표본이 적어 통계적 유의성을 논하기엔 이르지만, 방향성은 확인할 수 있었습니다.
BUG 비율은 47.5%에서 30.0%로 17.5%p 감소했고, FEATURE 비율은 49.2%에서 70.0%로 20.8%p 증가했습니다. 흥미로운 점은 개선 이전에도 BUG와 FEATURE 비율이 거의 1:1이었다는 사실입니다. 유저들은 이미 기능 제안의 욕구를 갖고 있었고, UI 프레이밍이 그 흐름을 더 명확하게 끌어낸 셈입니다.
아직 초기 수치인 만큼, 2~4주 후 충분한 표본이 쌓인 시점에서 재분석할 예정입니다. 채널톡을 통한 버그 제보 건수의 변화도 함께 추적하여, 채널 이원화가 실제로 유저의 행동 경로를 분리했는지 확인할 계획입니다.
UX Engineer의 역할은 유저와 팀 사이의 가교가 되는 것이라고 생각합니다. 이번 작업을 통해, 유저의 자유를 제한하는 것이 아니라 더 나은 방향으로 안내하는 것만으로도 유저 경험과 팀 운영 효율을 동시에 개선할 수 있다는 것을 배웠습니다. 좋은 UX는 유저만을 위한 것도, 팀만을 위한 것도 아닌, 양쪽 모두가 지속 가능하게 만드는 구조라고 믿습니다. 앞으로도 이 균형을 찾아가는 과정을 기록해보려 합니다.
'UX in Practice' 카테고리의 다른 글
| 구글이 무료로 풀어놓은 UX/UI 필독 문서 (0) | 2026.03.02 |
|---|