세균무기가 알려주는 서비스 기획의 모든 것(6)
뛰어난 제품을 만들기 위해 서비스 기획자 및 PM/PO가 알아야할 가이드
06. 관리자 사이트 기획
백오피스 또는 어드민이라 불리는 관리자 사이트를 기획하는 방법을 살펴보자.
6-1. 관리자 사이트 기획 시 고려사항
UI Gride 설계 ⇢ 인증 ⇢ 권한(View, Setting) ⇢ 보안(2단계 인증 등) ⇢ 준법 ⇢ 개인정보보호 ⇢ 요구사항 분석 및 정의 ⇢ 우선순위 ⇢ 사용성(편의성&불편함) ⇢ 통계(대시보드)
UI 구조(Gride) 설계
관리자 사이트는 단일한 UI 구조로 수많은 관리자 메뉴 페이지를 기획한다.
따라서 대다수 메뉴 페이지에 동일하게 적용할 수 있는 하나의 UI 구조를 제대로 설계하는 것이 중요하다.
메뉴 구조가 1 depth 일 때는 사이드 메뉴 바(SNB, Side Navigation Bar)만 사용하고, 상단 내비게이션 바(GNB, Global Navigation Bar)는 사용하지 않는다.
메뉴 구조가 2 depth 일 때는 GNB와 SNB를 모두 사용한다.
관리자 메뉴가 많아 3 depth 메뉴 구조가 필요할 때는 GNB와 SNB를 모두 사용하면서 SNB에서 메뉴를 클릭했을 때 드롭다운 메뉴 리스트를 적용해 3 depth 메뉴를 표시한다.
대다수 관리자는 웹사이트로 제공된다.
따라서 모니터의 크기나 운영자의 사용 방법에 따라 관리자 화면의 크기가 유동적으로 바뀔 수 있다.
따라서 변경되는 화면의 높이와 너비에 관리자가 대응할 수 있도록 기획해야 한다. 결국 가로 스크롤과 세로 스크롤이 생성될 수밖에 없다.
테이블 칼럼의 너비를 줄이다가 최소 너비보다 작아지면 가로 스크롤을 생성해야 한다.
세로를 기준으로는 어떤 라인이 세로 스크롤에 포함되거나 그렇지 않으면 스티키 처리를 통해 스크롤 액션에도 불구하고 화면 밖으로 밀려 사라지지 않게 할지 등을 결정해야 한다.
테이블의 칼럼 너비가 줄어들더라도 리스트 제목과 같은 주요 정보나 버튼이 위치한 칼럼은
너비가 줄면 안 되므로 고정된 너비를 사용하거나 최소 너비를 지정해야 한다.
관리자를 사용하는 운영자들의 편의성을 고려하며 UI 구조를 설계해야 한다.
그러나, 관리자는 무조건 편의성만 고려할 수는 없다.
관리자의 특성으로 인해 의도적으로 불편한 사용성을 갖도록 기획하게 된다.
이런 점이 사용자가 사용하는 클라이언트 기획과 운영자가 사용하는 관리자 기획의 차이라고 할 수 있다.
관리자는 회원의 정보 확인과 관리, 콘텐츠의 등록과 삭제는 물론 포인트와 쿠폰의 지급 등 서비스를 관리하고 운영하는 데 필요한 중요한 메뉴와 기능을 제공한다.
따라서 단순히 편한 것만 고려하며 기획할 수는 없다.
그래서 관리자는 UI는 무조건 편해야 하지만, UX는 때로는 불편할 수도 있다.
인증 처리와 권한 부여
이용자의 회원가입 시에는 사업자의 통지 의무를 수행하기 위해 이메일 인증이나 모바일 인증 등을 요구했다.
관리자도 해당 운영자가 관리자에 대한 접근 권한이 있는 사람인지 확인하고 특정 메뉴나 기능에 권한 있는 운영자만 접근할 수 있게 제한하기 위한 목적으로 인증을 요구한다.
이는 운영자가 관리자를 통해 부정한 관리 및 운영 활동을 하지 않도록 막고, 이를 모니터링하기 위한 기본 절차다.
따라서 어떤 수단과 방식으로 인증할지 결정해야 한다.
이메일 인증을 했다고 해서 관리자에 바로 접속이 가능한 것은 아니다.
이메일을 통해 임직원 여부를 확인했다면, 이제 관리자 권한 설정이 가능한 운영자 개발자를 통해서 해당 운영자에 대한 권한 설정이 이뤄져야 한다.
따라서 이메일 인증을 완료하더라도 권한 설정 전까지 대기가 필요하다.
그래서 권한 설정이 완료됐을 때 가입한 이메일 주소로 이제 로그인이 가능하다는 안내 메일을 발송하게 된다.
운영자마다 권한에 따라 보기 권한과 설정 권한을 제공하거나 제한할 수 있도록 권한 설정 기능을 지원한다.
보안
특정 IP나 GPS 위치 반경 내에서만 관리자의 접근을 지원하거나 아예 외부 인터넷망과 업무망을 분리하는 망분리를 하기도 한다.
자리를 비운 상황에서 제3자에 의한 입력을 막기 위해 주요 액션 버튼 클릭 시 2단계 인증 번호의 입력을 요구하거나 짧은 세션 유지 기간을 적용하여 자주 로그인을 유도하는 등 보안을 위해 의도적으로 불편한 기획을 한다.
개인정보보호
관리자를 개발하는 이유는 서비스의 운영을 위해 모든 운영자가 서버에 직접 접근하여 회원의 개인정보를 포함한 민감한 정보에 무분별하게 접근하는 것을 막고, 운영 중 발생하는 문제나 관리자의 권한 오남용 또는 부정행위를 방지하거나 발생 시 이를 추적하기 위함이다.
기획자는 현재의 상황이 잘못됐다는 인식과 함께 회사와 서비스가 성장하면서 올바른 방향으로 나아갈 수 있도록 현재 무엇을 못하고 있고, 향후 어떤 부분을 개선해야 하는지 알고 있어야 한다.
요구사항 분석 및 우선순위 결정
작업의 우선순위는 보통 인력 리소스가 가장 많이 투입되고 있는 업무와 관련된 기능이나 메뉴부터 구현해야 한다.
그런데 조직이란 특성 때문에 힘없는 운영자나 CS 담당자의 요구보다는 경영진이나 상급자에게 필요한 대시보드나 통계 등의 기능을 먼저 개발하는 경우가 많다.
기획자는 고객의 요구사항을 잘 파악하고, 업무의 우선순위를 잘 조절해야 하며, 자원과 시간을 효율적으로 배분하고 사용할 수 있어야 한다.
6-2. 기간과 상태값
관리자에서 캠페인, 콘텐츠, 상품 등을 등록하고 관리하려면 기간과 상태값을 설정할 수 있는 기능을 제공해야 한다. 이를 기획하려면 시작 일시와 종료 일시, 그리고 상태값에 대한 이해와 함께 정의가 필요하다.
필자는 시작 일시에 등록 페이지의 진입 시점을 표시하고, 종료 일시에는 캠페인에 따라 운영자가 자주 설정하는 기간을 표시한다. 즉 종료 일시에는 시작 일시로부터 7일이나 30일 등이 경과한 날짜의 23시 59분으로 표시한다.
관리자에서 필수 입력값인 인풋 박스에 디폴트 값이 필요한 이유는 인풋 박스에 값을 입력하지 않은 null 상태인데, 이때 [등록] 버튼을 클릭하면 인풋 박스 아래에 유효성 메시지를 표시하거나 다이얼로그 팝업을 띄워야 하기 때문이다.
입력값이 많은 등록 페이지에서 상황에 따른 유효성 메시지를 모두 정의하기가 쉽지 않다. 그래서 가급적 디폴트 값을 표시하거나 필수 입력값을 입력하지 않은 상태에서는 [등록] 버튼을 비활성화 처리해서 유효성 메시지의 표시를 최소화한다.
상태값을 기획할 때 특정 상태값에 따라 어느 상태까지 변경할 수 있는지 정의해 주는 것이 좋다.
그림 6.6과 같이 상태값에 따른 상태 변경 가능 경로를 명확하게 표시해 주면 운영자가 워크플로를 쉽게 이해하고 상태값을 사용할 수 있다.
6-3. 고유 아이디 생성
고유 아이디의 예시: 회원 ID(userId), 상품고유번호(productId), 주문번호(orderId), 결제번호(purchaseId), 쿠폰 번호(couponId), Etc.
고유 아이디를 생성하는 것이 생각보다 까다롭다. 중복되지 않으면서 짧게 만들어야 한다.
일부 고유 아이디는 아이디에 특정한 의미를 담으려고 하는데, 의미를 담다 보면 각 의미에 따라 자릿수가 정해지게 된다.
그런데 그 자릿수를 초과하는 아이디 생성의 요청이 들어오면 장애가 발생하게 된다.
6-4. 서버와 DB 테이블
최근에는 대다수 기업이 IDC(Internet Data Center)의 서버를 임대하기보다는 AWS나 GCP, Azure 등의 클라우드 서버를 사용한다.
기획자가 서버의 구성이나 구조를 이해할 필요는 없지만, 기획이나 데이터 분석을 위해 서버의 DB 아키텍처, DB 테이블, 데이터에 대한 이해는 필요하다.
기획자가 데이터 분석을 위한 데이터 웨어하우스(DW, Data Warehouse)를 구축하거나 분석 솔루션을 도입하지 않은 상황에서 운영 서버에 직접 접근하여 쿼리를 날리며 데이터를 들여다보는 행위는 개인정보보호를 위해서도 바람직하지 않고, 불법일 가능성이 크다.
DB를 공부하고 싶다면 구글 빅쿼리 무료 평가판 등을 활용해 학습해 보자.
기획자로서 클라이언트 및 관리자 사이트를 제대로 기획했다면 DB 테이블과 그 테이블의 칼럼을 읽고 이해할 수 있어야 한다.
나아가 개인적으로는 자신이 기획한 서비스의 ERD(Entity Relationship Diagram)는 보고 이해할 수 있어야 한다고 생각한다.
이렇게 입력된 정보는 하나 또는 여러 개의 테이블에 저장되는데, 회원과 관련된 주요 개인 정보는 보통 유저 테이블에 저장한다(물론 개발자들이 정한 코드 컨벤션에 따라 다를 수 있다).
코드 컨벤션: 여러 개발자들이 협업해야 하다 보니 읽고 관리하기 쉬운 코드를 작성하기 위해 네이밍이나 변수명, 코드 작성 스타일 등을 규정한 코드 작성 규칙
유저 테이블을 열어보면 기획자가 회원가입을 위해 입력받을 필요가 있다고 기획한 인풋 박스의 입력값들이 저장돼 있기 때문에 해당 칼럼을 이해할 수 있어야 한다.
칼럼의 데이터는 기획 시 정한 입력 형식 및 자릿수에 따라 문자열(varchar), 수치형(int), 날짜 타입(datetime) 등의 데이터 타입과 저장 가능한 자릿수에 따라 저장되고 있을 것이다.
