[리뷰] UX와의 줄타기
백엔드 개발자도 UX를 고민해야 하는가?
나는 백엔드 개발자다. 보통 백엔드 개발자라고 하면 데이터베이스를 설계하고, API를 만들고, 서버의 안정성을 고민하는 사람이라고 생각한다. 물론 맞는 말이다. 하지만 나는 조금 더 나아가 백엔드 개발의 끝은 결국 사용자 경험(UX)과 맞닿아 있다고 믿는 편이다.
API 응답 속도가 0.1초 느려지면 사용자는 앱이 버벅댄다고 느낀다. 에러 처리가 불친절하면 사용자는 영문도 모른 채 이탈한다. 결국 내가 작성하는 코드 한 줄 한 줄이 모여 사용자가 느끼는 서비스의 쾌적함을 결정한다. 그래서 나는 항상 기획자나 디자이너 못지않게 UX를 중요하게 생각하고, 그에 맞는 개발 방향을 추구하려 노력해왔다.
그러던 중, 최근 토스 기술블로그(Toss tech)에서 꽤나 인상 깊은 글을 읽었다. 토스에서 가장 안 좋은 경험 만들기라는 도발적인 제목의 글이었다.
토스 사용자 입장에서도 상당히 공감되는 이야기이며 현재 혹은 미래에 B2C 서비스를 만들 수 있는 개발자 입장에서 꽤나 흥미롭게 읽었다.
또한, 후에도 많은 도움이 될 것 같아서 리뷰를 적는다.
없앨 수 없다면, 예측 가능하게
비즈니스 수익을 위해 광고를 노출해야 하는 회사의 입장과 앱 흐름이 끊기는 걸 싫어하는 사용자의 입장이 가장 예리하게 대립하는 곳이다. 보통 이런 상황에서 많은 서비스들은 사용자의 눈을 속이거나 강제로 광고를 보게 만드는 방식을 택한다. 하지만 토스는 달랐다.
1. 투명성으로 불쾌함 줄이기
사용자가 가장 싫어하는 건 광고 자체가 아니라 예상치 못하게 튀어나오는 광고였다. 토스는 버튼에 '광고 보고'라는 문구를 넣어, 사용자가 스스로 선택 해서 광고를 보게 만들었다. 클릭률이 떨어질 것이란 우려와 달리, 예측 가능한 경험은 사용자의 거부감을 낮췄다.
2. 광고를 가치로 치환하기
사용자의 시간을 뺏는다면 그에 합당한 보상을 줘야 한다. 토스는 1년 넘게 보상의 종류와 크기, 광고의 길이를 튜닝하며 사용자가 납득할 수 있는 교환비를 찾아냈다. 만보기를 통해 걷고, 광고를 보면 복권을 주는 시스템은 그렇게 탄생했다.
결국 비즈니스와 UX는 제로섬(Zero-sum) 게임이 아니라 그 사이의 교집합을 찾아가는 과정이라는 것이 핵심이었다.
개발자의 관점에서 본 교집합
이 글은 기획과 화면단 관점의 이야기였지만 나는 읽는 내내 백엔드 관점에서의 인사이트를 많이 얻었다.
1. 예측 가능한 경험을 위한 백엔드의 역할
글에서 강조한 투명성과 예측 가능성은 백엔드단에서 신뢰성으로 구현된다.
'광고를 보면 보상을 준다'는 약속은 화면에서 맺어지지만, 사실 그 약속을 실제로 이행하는 주체는 백엔드다. 폭발적인 트래픽 속에서도 광고 시청 이벤트는 유실되지 않아야 하고 보상 지급 트랜잭션은 한 치의 오차도 없어야 한다. UX가 정교해질수록 이를 지탱하는 백엔드 로직은 더욱 견고해야 함을 다시 한번 상기했다.
2. 데이터 기반의 끈기
토스는 적정한 보상을 찾기 위해 1년 넘게 실험했다고 한다. 이는 개발자가 A/B 테스트가 용이한 유연한 구조를 설계했기에 가능했을 것이다. 비즈니스 로직을 하드코딩하지 않고, 설정값 변경만으로 다양한 실험이 가능한 환경을 구축해 주는 것. 그것이 비즈니스와 UX의 교집합을 찾는 여정에서 개발자가 기여할 수 있는 가장 큰 부분일 것이다.
마치며
이 주제는 비단 Advertisement 도메인에만 국한되는 이야기가 아니다. 성능과 비용, 개발 효율과 사용자 편의성 등 개발자가 매일 마주하는 수많은 트레이드오프 상황에서도 반드시 필요한 마인드셋이다.
무엇보다 놀라웠던 건 그 과정에 담긴 '디테일'의 무게였다. 사용자들(개발을 하는 나 역시)은 별생각 없이 무의식적으로 버튼을 누르거나 창을 닫아버리지만, 그 단순한 행동 하나를 이끌어내기 위해 뒤단에서는 수백 번의 실험과 데이터 분석, 그리고 치열한 고민이 녹아 있었다. 우리가 무심코 지나치는 모든 UI/UX 요소 뒤에는 누군가의 이런 피땀 어린 노력이 숨어있음을 새삼 깨닫게 되었다.
앞으로 코드를 짤 때 이 코드가 목표를 달성하면서도 사용자에게 쾌적한 경험을 주고 있는지 끊임없이 되묻는 습관이 필요할 것 같다.