백오피스는 고객이 보는 화면이 아니다 보니 기획 단계에서 상대적으로 가볍게 여겨지는 경향이 있다. 하지만 실제 사례들을 찾아보면 디테일이 생각보다 훨씬 많이 들어가는 영역이라는 걸 알 수 있다. 회원 관리·팝업 관리 백오피스 기획을 훈련해보면서 배운 것들과, 토스뱅크·배민·우아한형제들의 사례를 참고하며 정리한 주의사항들을 공유해본다.
백오피스의 고객은 '운영자'다
서비스 기획을 공부하다 보면 항상 "고객 관점에서 생각하라"는 말을 듣는다. 백오피스도 마찬가지인데, 여기서 고객은 일반 유저가 아니라 운영팀, CS팀, 마케터 같은 내부 운영자다.
그런데 여기서 중요한 포인트가 있다. 운영자는 매일 같은 툴을 쓰다 보면 불편함에 익숙해진다. 토스뱅크 헬프데스크 개선 사례에서도 비슷한 이야기가 나온다. 상담원들에게 불편한 점을 인터뷰하면 "원래 이렇게 해요", "이 정보는 여기서 봐야 해요"라는 답이 돌아왔다고 한다. 수십 개의 거래 내역이 뒤섞인 화면에서 송금 내역 3개를 찾는 일도, 매일 반복하다 보니 당연하게 느껴졌던 것이다.
배민의 SCM 사례에서도 비슷하다. 사용성이 고려되지 않은 백오피스에서 운영자들은 불편한 기능을 잘 활용하는 방법을 서로 공유하며 버텨왔다고 한다. 일반 고객용 서비스라면 불편하면 이탈하겠지만, 백오피스 사용자는 어쩔 수 없이 하루 종일 그 불편함을 감수하며 일한다.
운영자가 "괜찮다"고 해도, 워크플로우를 처음부터 끝까지 직접 따라가보는 시선이 기획에 필요하다.
용어 하나도 정확하게 정의하라
기획서를 쓰다 보면 튜터님들에게 가장 흔하게 들어오는 질문이 바로 용어의 모호함에 대한 질문들이다.
백오피스에서는 특히나 용어정의를 할 때 '사용자 입장'과 '서비스 제공대상(고객) 입장'을 고려해야 한다. 예를 들어 기획서에 "팝업명"이라고만 적혀 있다면, 개발자는 이것이 백오피스 화면에서 보이는 관리용 명칭인지, 실제 고객 화면에 뜨는 팝업 창의 제목인지 헷갈릴 수 있다. 실제로 이 둘은 명확히 다르다. '팝업명'은 운영자가 내부 구분을 위해 입력하는 값으로, 유저 화면에는 노출되지 않는다.
이런 차이를 기획서에 한 줄이라도 명시하지 않으면 개발과 기획 사이에 인식 차이가 생기고, 결국 재작업으로 이어진다. 기능 명세를 작성할 때는 "이 항목이 누구에게, 어떻게 보이는가"를 반드시 함께 적는 습관을 들이자.
"절대 안 바뀐다"는 말을 믿지 말 것
강의나 컨퍼런스를 보다 보니 백오피스 기획에서 운영자 인터뷰를 하면 "우리 서비스는 PC만 써요, 모바일은 절대 필요 없어요."나 "이 메뉴 하위에 더 이상 추가될 항목은 없어요." 같은, 기획 범위를 좁혀주는 말들을 듣게 될 수 있다고 하더라.
그런데 실제 운영에 들어가면 이런 전제들이 꽤 자주 뒤집히기 때문에 철썩같이 믿으면 안 된다. 처음엔 PC 전용으로 만들었다가 어느 순간 모바일 접근이 필요해지고, 계층이 없다고 했던 메뉴 구조에 하위 메뉴가 생기기도 한다. 우아한형제들은 200개 이상의 백오피스를 운영하고 있다.1 애초에 하나로 시작했던 시스템이 서비스와 기능이 늘어나면서 각 목적에 맞게 분화된 결과다.
어드민은 서비스가 성장하고 운영 방식이 바뀌면서 예상보다 훨씬 빠르게 변경 요구가 생기는 영역이다. 현재 스펙만 보고 딱 맞게 설계하면, 나중에 구조 자체를 뜯어고치는 상황이 올 수 있다. 처음부터 확장을 염두에 둔 유연한 구조로 기획해야 하는 것이다.
정보가 많으면 구조화가 필수다
서비스 규모가 커질수록 백오피스에서 관리해야 할 화면도 많아진다. 회원 관리, 팝업 관리, 콘텐츠 관리, 정산 관리 등 기능이 쌓이면 운영자가 원하는 화면을 찾는 것 자체가 일이 된다.
이럴 때는 메뉴를 단순 나열하는 것이 아니라 서비스 특성에 맞게 계층화하고 그룹핑해야 한다. 마케팅 관련 기능들을 하나의 대메뉴 하위에 묶거나, 자주 쓰는 기능을 상단에 배치하는 식이다.
토스뱅크 사례에서도 이 원칙이 잘 드러난다. 착오 송금 업무를 처리하려면 기존에는 거래 제한 화면, 계좌 상태 화면, 업무 화면을 4~5번 왔다 갔다 해야 했다. 하나의 접수 건에 필요한 정보가 여기저기 흩어져 있었기 때문이다. 이를 하나의 화면에서 모두 볼 수 있도록 재구성했더니, 같은 시간에 처리할 수 있는 업무량이 2.5배 이상 늘었다고 한다.
<아무도 눈치채지 못한 문제까지 해결해야 할까?> 백오피스 개선 사례
<아무도 눈치채지 못한 문제까지 해결해야 할까?> 토스 심플리시티 박성경 님 백오피스 개선 사례 | Simplicity24
Product Designer (Tools) 특별편 - Simple Questions, Big Wins
toss.im
배민 SCM에서는 여러 페이지를 오가며 작업해야 하는 상황을 탭 UI로 해결했다. 메뉴를 클릭할 때마다 페이지가 바뀌는 대신 탭이 새로 열리고, 각 탭은 독립적인 상태를 유지한다. 운영자가 여러 작업을 동시에 열어두고 오갈 수 있게 된 것이다. 기획 단계에서 "운영자가 동시에 몇 가지 작업을 병행하는가"를 고려했다면 자연스럽게 나올 수 있는 설계다. (책 <요즘 우아한 개발>의 "만드는 사람이 수고로운 UX 개발기" 파트)
필요한 정보만 보여주는 것도 설계다
정보를 많이 보여주는 것이 좋은 게 아니다. 상황에 맞는 정보만 보여주는 것이 진짜 설계다.
토스뱅크 헬프데스크에서는 착오 송금 접수를 위해 전체 거래 내역 화면에서 특정 건을 찾아야 했다. 카드 결제, 캐시백, 입금 등 수십 개의 내역이 뒤섞인 화면에서 타인에게 송금한 내역 3개를 골라내는 구조였다. 개선 후에는 접수 가능한 조건에 맞는 내역만 걸러서 보여주고 날짜·금액·수취인 기반 검색까지 붙였다. 결과적으로 건당 상담 시간을 평균 70초 단축했다고 한다.
배민 SCM에서는 유효성 검증을 시각화해서 운영자가 필수 입력값을 빠뜨렸을 때 실시간으로 피드백을 받을 수 있게 했다. 또한 데이터를 입력하다가 실수로 화면을 닫거나 새로고침하면 입력 내용이 날아가는 문제를 방지하기 위해, 편집 중인 상태를 감지해 "정말 닫겠냐"고 확인하는 장치도 넣었다.
기획할 때 "이 화면에서 운영자가 실제로 필요한 정보가 무엇인가", "어떤 실수가 생길 수 있는가"를 계속 물어야 한다. 없어도 되는 정보는 과감히 빼고, 실수를 줄이는 안전장치를 어디에 넣을지도 함께 고민하는 것이 좋은 기획이다.
조건 설정은 운영자 입장에서 다시 생각하라
팝업 노출 대상을 설정할 때 "모든 사용자 / 비회원 / 첫 방문자" 같은 선택지를 제공하게 된다. 이때 단순히 선택지를 나열하는 데서 그치면 안 되는 이유가 생각보다 다양한 조건이 있기 때문이다. 운영자는 종종 이런 요구를 한다. "첫 방문자이면서 비회원인 경우에만 보여주고 싶어요." 또는 "iOS와 Android 사용자 모두에게 보여주고 싶어요."
AND / OR 조건을 어떻게 설정할 수 있는지, 복수 조건 조합이 가능한지를 기획 단계에서 미리 정의해두어야 한다. 이걸 애매하게 넘어가면 개발자가 임의로 해석해서 구현하거나, 운영팀이 원하는 기능이 실제로 안 되는 상황이 생긴다.
부트캠프에서 MVP프로젝트 중 프레이머 쪽을 주도적으로 진행하면서 또 느꼈던 점이 이거였다. 우리는 필터링을 주력으로 하는 서비스를 기획했는데, 필터링의 대상이나 범위의 계층이 명확하지 않으면 그룹핑하여 AND/OR 조건을 설정할 때 크나큰 애로사항이 생겼다. 기획자는 개발자가 아니니 어차피 진짜 그룹핑은 개발자가 한다손 치더라도, 필터링 선택지를 제시할 때 그 계층화를 고민했느냐 하지 않았느냐는 천지차이라고 생각한다.
같은 MVP프로젝트 과제에서 타 팀이 사진촬영 업체 이커머스 플랫폼을 기획하면서 '분위기'에 대한 키워드들을 필터링 키워드로 채택하셨는데 튜터님들이 일관되게 이 부분에 메타데이터 운영효율을 고려해보자는 피드백을 주셨었다. 백오피스 기획이 아니라 백오피스를 고려한 기획이라는 점에서 다른 얘기긴 하지만, 어쨌거나 조건 설정은 결국 운영자가 관리하는 영역이니 이 부분을 반드시 고려하고 기획해야 한다는 것이다. 실무를 경험해보지 않으면 반영하기 정말 어려운 부분인 것 같은데, 튜터님들은 보자마자 운영 효율과 운영 가능성을 따져보시는 걸 보고 실제로 중요한 영역일수록 신입은 경험이 어렵구나 싶기도 했다.
권한 관리와 보안도 기획 범위다
백오피스는 고객 개인정보, 거래 내역, 운영 설정 등 민감한 데이터를 다루는 공간이다.우아한형제들은 200개 이상의 백오피스를 운영하면서 권한 관리의 복잡함을 직접 경험했다. 백오피스마다 인증을 따로 만들다 보니 중복 개발이 발생하고, 운영자 경험도 제각각이 됐다. 결국 인증과 권한을 중앙화된 플랫폼으로 통합했다.
PM 입장에서 챙겨야 할 권한 관리 기획 포인트를 정리하면 이렇다.
- 역할별 접근 권한 설계. 모든 운영자가 모든 기능에 접근할 수 있으면 안 된다. CS팀은 회원 정보 조회는 가능하지만 계정 삭제는 불가능하게, 마케터는 팝업 등록은 가능하지만 회원 정보는 볼 수 없게 하는 식으로, 역할에 따라 기능 접근 범위를 기획 단계에서 정의해야 한다.
- 권한 변경 시나리오 고려. 인사이동, 퇴사, 업무 변경이 생겼을 때 권한을 어떻게 처리할지도 미리 생각해야 한다. 퇴사한 직원의 계정이 그대로 남아있거나, 부서를 옮긴 운영자가 예전 권한을 그대로 갖고 있으면 보안 문제가 생긴다.
- 개인정보 접근에 대한 로깅. 민감한 데이터에 누가, 언제 접근했는지 기록이 남아야 한다. 이는 컴플라이언스 요건이기도 하고, 내부 감사나 사고 발생 시 추적을 위해서도 필요하다. "이 기능은 접근 로그를 남겨야 한다"는 요건을 기획서에 명시해두는 것이 좋다.
백오피스 기획에서 보안과 권한은 개발팀이 알아서 해줄 거라 생각하기 쉽다. 하지만 어떤 역할이 어떤 기능에 접근할 수 있어야 하는지는 서비스 운영 구조를 가장 잘 아는 기획 단계에서 먼저 정의해야 한다.
마무리하며
백오피스 기획을 공부하면서 느낀 건, 결국 운영자의 업무 흐름을 얼마나 깊게 이해하느냐가 기획의 완성도를 결정한다는 점이다.
용어를 정확히 정의하고, 변경 가능성을 열어두고, 필요한 정보만 적절히 구성하고, 조건 설정과 권한 관리까지 운영자 입장에서 설계하는 것. 어떻게 보면 당연한 이야기지만, 운영자 입장을 경험해보거나 심도있는 관찰, 인터뷰를 하지 않았다면 놓치기 쉬울 것 같다.
토스뱅크 사례가 인상적이었던 이유도 거기 있다. "원래 이렇게 해요"라는 말에서 멈추지 않고, 업무 플로우를 끝까지 따라가며 숨겨진 비효율을 찾아낸 것. 백오피스 기획도 결국 그 태도에서 시작하는 것 같다.