사용자 종류부터 나눠야 하는 이유

한 운동 센터 대표님이 회원용 예약 앱을 기획했습니다. 회원이 수업을 고르고 예약하는 화면은 꼼꼼하게 정했습니다. 개발도 순조롭게 진행됐습니다.

오픈을 한 달 앞두고 강사님들이 물었습니다. 「저희는 제 수업 예약자를 어디서 보나요」. 지점 매니저는 「우리 지점 매출만 보고 싶다」고 했습니다. 앱에는 회원과 관리자 두 종류만 있었습니다. 강사와 지점 매니저를 넣으려면 로그인 방식부터 다시 손봐야 했습니다.

사용자 종류는 기능 하나가 아니라 서비스의 뼈대에 가깝습니다. 늦게 정할수록 고칠 곳이 많아집니다.

핵심은 화면을 그리기 전에 서비스를 쓰는 사람의 종류와 각자 할 수 있는 일을 먼저 나누는 것입니다. 사용자 종류가 정해져야 화면 수, 메뉴 구조, 권한이 정해집니다. 개발사도 이 구분을 보고 로그인과 데이터 구조를 설계합니다.

사용자 종류는 생각보다 많습니다

처음에는 「회원」과 「관리자」만 떠올리기 쉽습니다. 하지만 실제 운영을 따라가 보면 다른 사람들이 보입니다.

• 비회원. 가입 전에 둘러보는 사람. 어디까지 보여 줄지 정해야 합니다.
• 일반 회원. 서비스를 이용하는 사람. 등급이 나뉘기도 합니다.
• 파트너. 강사, 판매자, 기사님처럼 서비스를 함께 제공하는 사람.
• 운영자. 문의 답변, 게시물 관리처럼 일부만 맡는 직원.
• 최고 관리자. 모든 것을 보고 권한을 나눠 주는 사람.

모든 서비스에 다섯 종류가 다 필요하지는 않습니다. 중요한 것은 빠뜨린 사람이 없는지 한 번 따져 보는 것입니다.

빠뜨린 사람을 찾는 쉬운 방법이 있습니다. 서비스가 하루 동안 돌아가는 모습을 떠올리고, 그 하루에 손을 대는 사람을 모두 적어 보는 것입니다. 전화로 예약을 받는 직원, 정산을 맡은 직원이 여기서 자주 나옵니다.

권한표로 할 수 있는 일을 정합니다

사용자 종류를 정했다면 표 한 장으로 누가 무엇을 할 수 있는지 적습니다. 기획자는 이것을 권한표라고 부릅니다.

「우리 지점만」「내 수업만」 같은 칸이 중요합니다. 같은 화면이라도 누가 보느냐에 따라 보이는 범위가 달라진다는 뜻이고, 개발 방식이 달라집니다.

사용자 종류마다 화면 묶음을 따로 둡니다

권한표가 정해지면 사용자 종류별로 메뉴 구조를 나눕니다. 회원 앱, 파트너 화면, 관리자 화면처럼 묶음을 따로 두는 것입니다. 한 화면에 모든 사람을 위한 버튼을 몰아 넣으면 화면이 복잡해지고 실수로 권한이 새는 일도 생깁니다.

나눠 놓고 보면 파트너 쪽 화면이 생각보다 많다는 것을 알게 됩니다. 이것이 견적이 처음 예상과 달라지는 흔한 이유입니다. 미리 알면 1차 오픈 때 파트너 화면을 최소로 줄이는 결정도 할 수 있습니다.

정할 때 확인할 질문

1. 한 사람이 두 종류를 겸할 수 있나요? 예를 들어 강사가 회원으로 수업을 들을 수도 있나요?
2. 새 사용자 종류는 누가 만들어 주나요? 스스로 가입하나요, 관리자가 등록하나요?
3. 권한이 바뀌면 이미 있던 데이터는 어떻게 되나요?

사용자 종류와 권한은 메뉴 구조를 짜기 전에 정해 두는 것이 가장 쌉니다. 기획서에 권한표와 사용자별 화면 묶음이 들어 있으면 개발사도, 직접 개발하는 분도 같은 그림을 보고 시작할 수 있습니다.

자주 묻는 질문

관리자 권한을 여러 단계로 나눠야 하나요?

직원이 한 명이면 한 단계로 충분합니다. 다만 앞으로 문의 답변만 맡는 직원이 생길 수 있다면, 처음부터 권한을 나눌 수 있게 해 달라고 기획서에 적어 두는 것이 좋습니다.

회원과 파트너가 같은 앱을 써도 되나요?

됩니다. 로그인한 사람의 종류에 따라 다른 메뉴를 보여 주는 방식이 흔합니다. 다만 파트너 기능이 많다면 앱을 따로 두는 편이 관리하기 쉬울 수 있으니 화면 수를 보고 정합니다.

사용자 종류를 나중에 추가하면 비용이 많이 드나요?

추가하는 종류와 이미 만든 구조에 따라 다릅니다. 로그인과 데이터 구조를 함께 고쳐야 하는 경우가 많아 처음에 정할 때보다 일이 커지기 쉽습니다. 당장 만들지 않더라도 생길 가능성은 기획서에 적어 두시기를 권합니다.