BO 화면설계 심화 (3) - 상품 관리
이번 글에서는 백오피스 상품 관리 화면설계를 깊이 있게 정리해 보겠습니다. 앞선 글에서 전시 영역이 ‘노출을 제어하는 영역’이었다면, 상품 관리는 그보다 한 단계 더 본질적인 영역입니다. 상품 관리는 데이터의 원본을 다루는 공간입니다. 여기서 잘못 설계하면 이후 전시, 주문, 정산, 통계까지 모든 영역에 영향을 미치게 됩니다.
따라서 상품 관리 화면은 단순히 “등록하고 수정하는 페이지”가 아니라, 운영의 안전성과 효율을 동시에 확보해야 하는 핵심 관리자 도메인입니다. 이번 글에서는 리조트 상품 관리 사례를 기준으로, 실제 화면설계 시 어떤 사고를 해야 하는지, 어떤 구조로 설계해야 하는지를 적어보겠습니다.
상품 관리 화면의 전제 – 데이터 원본을 다루는 영역
상품 관리 화면은 관리자가 상품을 조회하고, 등록하고, 수정하기 위한 핵심 관리 영역입니다. 전시 영역이 사용자에게 무엇을 보여줄지를 통제하는 영역이라면, 상품 관리는 그 ‘보여줄 대상’ 자체를 정의하고 관리하는 영역입니다. 이 영역의 설계 기준은 네 가지로 정리할 수 있습니다.
첫째, 빠른 조회가 가능해야 합니다. 관리자는 수백, 수천 개의 상품 중 특정 상품을 빠르게 찾아야 합니다.
둘째, 안전한 수정이 가능해야 합니다. 데이터는 원본이기 때문에 실수로 인한 변경은 치명적입니다.
셋째, 실수를 구조적으로 방지해야 합니다. 관리자의 숙련도에 기대는 설계는 위험합니다.
넷째, 최소한의 페이지 수로 최대 효율을 내야 합니다. 페이지가 많아질수록 개발 공수와 유지 비용이 증가합니다.
이 네 가지 기준을 염두에 두고 설계를 시작해야 합니다.
기본 구조
상품 관리 역시 백오피스의 표준 구조를 따릅니다. 화면 목록, 플로우 차트, 컴포넌트 정의, 네비게이션 위치 표시, 그리고 실제로 사용하는 목록 페이지, 상세/수정 페이지, 등록 페이지로 구성됩니다.
이 구조는 상품 관리뿐 아니라 전시, 주문, 회원 관리 등 거의 모든 관리자 영역에 동일하게 적용됩니다. 즉, 상품 관리라고 해서 특별히 다른 구조를 쓰는 것이 아니라, 동일한 설계 틀 위에서 도메인 특성을 반영하는 것입니다.
리조트 사례
예를 들어, 리조트 상품을 판매하는 관리자 페이지를 기준으로 설계된 화면이 있습니다.. 상품 유형은 숙박, 골프, 차량, 마사지, 기타 상품 등으로 구성되어 있습니다. 이 문서에서는 그중 숙박 상품을 중심으로 설명됩니다. 여기서 중요한 점은, 도메인 특성을 이해하지 못하면 화면설계가 피상적으로 흐를 수 있다는 것입니다. 숙박 상품은 일반 단일 상품과 달리 룸 타입, 시즌 요금, 기준 인원 등의 복합 구조를 가집니다. 따라서 화면 설계에서도 이 구조를 반영해야 합니다.
상품 목록 페이지 설계
1) 목록 페이지의 핵심 역할
모든 관리자 페이지의 출발점은 조회입니다. 관리자의 작업 흐름은 대체로 조회 → 선택 → 상세 확인 → 수정 또는 추가의 순서로 진행됩니다. 따라서 조회 영역은 항상 상단에 배치합니다. 이 원칙은 거의 예외가 없습니다. 조회 기능이 아래에 있거나 숨겨져 있으면, 운영 효율이 급격히 떨어집니다.
2) 조회(검색) 영역 구성
상품 관리 조회 영역에는 법인 선택, 지역 선택, 숙박 유형 선택, 등록일 기간 설정과 같은 필터가 포함됩니다. 특히 등록일 필터는 반드시 포함해야 합니다. 데이터가 많아질수록 전체 조회는 서버 부하와 작업 지연을 유발합니다. 등록일 기준 필터는 성능과 직결되는 요소입니다. 이것은 단순 UX 문제가 아니라 시스템 안정성과도 연결된 설계 포인트입니다.
3) 조회 기간 기본값 설정
조회 기간은 기본값을 설정하는 것이 바람직합니다. 상품 등록이 잦은 서비스라면 최근 7일, 등록 빈도가 낮다면 최근 30일이 일반적인 기준입니다. 기본값을 설정하지 않으면 관리자는 매번 전체 데이터를 조회하게 됩니다. 이는 불필요한 트래픽과 대기 시간을 초래합니다. 기본값 설정은 사소해 보이지만 운영 효율을 크게 좌우합니다.
4) 데이터 테이블 구성 원칙
목록 페이지에서는 최소한의 핵심 정보만 노출해야 합니다. 상품명, 상품 유형, 상태, 등록일, 주요 식별 값 정도면 충분합니다.
상세 정보는 상세 페이지에서 확인하면 됩니다. 목록에서 과도한 정보를 보여주면 가독성이 떨어지고, 핵심 판단이 어려워집니다. 목록은 “찾기 위한 화면”이지 “읽기 위한 화면”이 아닙니다.
상세 페이지와 수정 페이지 통합 설계
1) 과거 방식과 현재 방식
과거에는 상세 페이지와 수정 페이지를 분리하는 경우가 많았습니다. 상세는 보기 전용, 수정은 별도 진입 방식이었습니다. 그러나 현재는 상세와 수정을 통합하는 방식이 일반적입니다.
2) 통합 설계의 장점
상세/수정 통합의 가장 큰 장점은 페이지 수 감소입니다. 페이지가 줄어들면 개발 공수가 줄어들고, 테스트 범위가 줄어들며, 일정이 단축됩니다. 기획자와 개발자 간 커뮤니케이션도 단순해집니다. “이 화면에서 바로 수정 가능”이라는 구조는 명확하고 효율적입니다.
5.3 운영자 관점에서의 수용성
관리자는 대부분 상세를 보기 위해 들어오는 것이 아니라, 수정을 위해 들어옵니다. 따라서 상세 화면에서 바로 수정이 가능해도 운영자는 거부감을 느끼지 않습니다. 오히려 작업 동선이 짧아져 편리합니다.
수정 가능 항목과 불가 항목의 구분
상세/수정 통합 방식에서 가장 중요한 설계 포인트는 수정 가능한 항목과 수정 불가능한 항목을 명확히 구분하는 것입니다. 예를 들어 가격, 계약 조건, 기준 요금과 같은 항목을 임의 수정 가능하게 두면 관리자의 실수로 치명적인 오류가 발생할 수 있습니다. 이 경우 수정 버튼을 허용하는 것이 아니라, “재등록” 절차를 타도록 설계해야 합니다. 즉, 일부 항목은 변경이 아니라 신규 생성으로 처리되도록 구조를 설계하는 것입니다.
이 구분이 없으면 데이터 무결성이 무너집니다.
숙박 상품의 특성 반영 – 룸 타입 구조
숙박 상품은 룸 타입이라는 하위 구조를 가집니다. 따라서 상세 페이지에서는 룸 타입별 정보 입력이 가능해야 하며, 설계 문서에서는 이를 페이지 분할 형태로 표현할 수 있습니다. 실제 화면은 하나로 이어질 수 있지만, 설계 문서상에서는 단계별로 나누어 설명하는 것이 이해에 도움이 됩니다.
Next / Previous 모듈 활용
여러 단계로 이어지는 등록·수정 과정에서는 Next / Previous 모듈을 사용합니다. 이는 사용자의 진행 흐름을 명확히 보여주기 위함입니다. 설계 문서에서는 NEXT, PREVIOUS와 같은 표기를 통해 화면 흐름을 명확히 연결합니다. 또한 Header, Footer와 같은 공통 영역을 표시하여 실제 UI 구조와 문서를 일치시킵니다.
수정 이력 관리 설계
9.1 수정 이력의 중요성
상품 관리 페이지는 수정이 빈번합니다. 따라서 수정 이력 관리가 필수입니다. 누가, 언제, 무엇을 변경했는지 추적할 수 있어야 합니다.
9.2 카드형 수정 이력 관리
수정 이력은 카드 형태로 관리하는 것이 효율적입니다. 버전 번호, 변경 내용 요약, 수정 일시를 함께 표시합니다. 특히 버전 번호는 검색이 용이하도록 설계해야 합니다.
9.3 Ctrl + F 기반 검색 설계
버전 번호를 Ctrl + F로 검색했을 때 바로 찾을 수 있도록 설계해야 합니다. 이 구조가 없으면 개발자나 구현자는 반복적으로 “어디가 바뀌었나요?”라는 질문을 하게 됩니다. 수정 이력 관리 구조는 협업 비용을 줄이는 설계 장치입니다.
상품 관리 설계의 본질
상품 관리 화면설계의 핵심은 조회 중심 설계, 기본 조회 기간 설정, 최소 정보 노출, 상세/수정 통합, 수정 가능/불가 구분, 도메인 특성 반영, 그리고 수정 이력 관리입니다. 상품 관리 화면은 단순 입력 화면이 아닙니다. 그것은 원본 데이터를 안전하게 다루기 위한 통제 장치이며, 운영의 안정성을 확보하는 구조입니다. 이 영역을 얼마나 정교하게 설계하느냐에 따라 전체 서비스 품질이 결정됩니다.
상품 관리는 곧 서비스의 기반입니다. 따라서 설계는 반드시 구조적으로, 그리고 책임감 있게 이루어져야 합니다.