백오피스 화면설계 심화 (3)

상품 관리 사례

1. 상품 관리 화면의 전제

백오피스 상품 관리 화면은
관리자가 상품을 조회하고, 등록하고, 수정하기 위한 핵심 관리 영역이다.

전시 영역이 “노출을 제어하는 영역”이라면,
상품 관리는 “데이터의 원본을 관리하는 영역”에 해당한다.

따라서 설계의 기준은 다음과 같다.

1. 빠른 조회
2. 안전한 수정
3. 실수 방지
4. 최소한의 페이지 수로 최대 효율

 

2. 상품 관리 화면의 기본 구조

상품 관리 역시 백오피스의 표준 구조를 따른다.

1. 화면 목록
2. 플로우 차트
3. 컴포넌트 정의
4. 네비게이션 위치 표시
5. 목록 페이지
6. 상세/수정 페이지
7. 등록 페이지

이 구조는 전시, 상품, 주문, 회원 관리 등
대부분의 관리자 영역에 동일하게 적용된다.

 

3. 상품 관리 도메인 이해 (리조트 사례)

이 샘플은 리조트 상품을 판매하는 관리자 페이지를 기준으로 설계된 사례다.

상품 유형은 다음과 같이 구성되어 있었다.

• 숙박
• 골프
• 차량
• 마사지
• 기타 상품

이 문서는 그중에서도 숙박 상품 관리를 중심으로 설명된 화면설계다.

---

4. 상품 목록 페이지 설계

4.1 목록 페이지의 핵심 역할

모든 관리자 페이지의 기본은 조회다.

관리자는 다음 흐름으로 작업한다.

조회 → 선택 → 상세 확인 → 수정 또는 추가

따라서 조회 영역은 항상 상단에 배치된다.

 

4.2 조회(검색) 영역 구성

상품 관리 조회 영역에는 다음 필터들이 포함된다.

• 법인 선택
• 지역 선택
• 숙박 유형 선택
• 등록일 기간 설정

특히 등록일 필터는 반드시 포함되어야 한다.
이는 데이터가 많아질수록 조회 성능과 작업 효율에 직접적인 영향을 준다.

 

4.3 조회 기간 기본값 설정

조회 기간은 기본값을 설정하는 것이 좋다.

일반적인 기준은 다음과 같다.

• 상품 등록이 잦은 서비스: 최근 7일
• 상품 등록 빈도가 낮은 서비스: 최근 30일

기본값을 설정해 두면
관리자가 불필요하게 전체 데이터를 조회하지 않아도 된다.

 

4.4 데이터 테이블 구성 원칙

목록 페이지의 데이터 테이블에는
최소한의 핵심 정보만 노출한다.

이유는 명확하다.

• 상세 정보는 결국 상세 페이지에서 확인한다.
• 목록에서 너무 많은 정보를 보여주면 가독성이 떨어진다.

목록에서는 다음 정도면 충분하다.

• 상품명
• 상품 유형
• 상태
• 등록일
• 주요 고유 식별 값

 

5. 상세 페이지와 수정 페이지 통합 설계

5.1 과거 방식과 현재 방식의 차이

과거에는 다음과 같이 페이지를 분리하는 경우가 많았다.

• 상세 페이지
• 수정 페이지

하지만 현재는 상세 + 수정 통합 방식이 일반적이다.

 

5.2 상세/수정 통합의 장점

이 방식의 장점은 명확하다.

1. 페이지 수 감소 → 개발 공수 감소
2. 수정 시 대응 범위 축소
3. 일정 단축
4. 기획–개발 커뮤니케이션 단순화

결과적으로 납품 기간이 줄어든다.

 

5.3 운영자 관점에서의 수용성

관리자 입장에서도
“상세를 본다”는 행위는 대부분 “수정을 하기 위해 들어온다”는 의미다.

따라서 상세 페이지에서 바로 수정이 가능해도
운영 측에서는 큰 거부감이 없다.

 

6. 수정 가능 항목과 불가 항목의 구분

상세/수정 통합 방식에서 가장 중요한 설계 포인트는 다음이다.

수정 가능한 항목과 수정 불가능한 항목을 명확히 구분하는 것

예를 들어,

• 가격
• 계약 조건
• 기준 요금

과 같은 항목은
임의 수정이 불가능하도록 처리해야 한다.

만약 수정이 필요하다면,

• “수정”이 아니라
• “재등록” 절차를 타도록 설계한다.

이 구분이 없으면
관리자 실수로 인해 치명적인 데이터 오류가 발생할 수 있다.

상태 값에서 수정할 수 있는 것과 없는 것을 구분해 줘야 돼요.
예를 들어서 특정 상세에서 가격을 임의로 변동할 수 있게 하면 안 되는데 변동을 시킨다 이러면
이제 관리자가 실수를 유발할 수 있는 거죠.
그러니까 수정할 수 있는 것과 없는 것을 구분시켜서 
만약에 그것을 수정하려면 다시 등록해야 돼 이러한 주제를 주는 거죠.

 

7. 숙박 상품의 특성 반영 (룸 타입)

숙박 상품의 경우 룸 타입이라는 구조적 특성이 있다.

따라서 상세 페이지는 다음을 고려해 설계된다.

• 룸 타입별 정보 입력
• 룸 타입별 페이지 분할

이 과정에서 화면 설계서는
실제 화면은 이어져 있지만, 문서상에서는 페이지를 분할해 표현한다.

 

8. Next / Previous 모듈 사용

여러 단계로 이어지는 등록·수정 과정에서는
Next / Previous 모듈을 사용한다.

• Next: 다음 단계로 이동
• Previous: 이전 단계로 이동

화면 설계서에서는 이 흐름을 명확히 표현하기 위해
NEXT, PREVIOUS 같은 기호를 사용한다.

• Header: 공통 헤더 영역
• Next / Footer: 다음 단계 또는 하단 영역

이는 실제 UI와 설계 문서를 연결하기 위한 표현 방식이다.

 

9. 수정 이력 관리 설계

9.1 수정 이력의 중요성

상품 관리 페이지는 수정 빈도가 높은 영역이다.
따라서 수정 이력 관리가 매우 중요하다.

 

9.2 수정 이력 카드 방식

가장 효율적인 방식은
수정 이력을 카드 형태로 관리하는 방식이다.

• 버전 번호 표시
• 변경 내용 요약
• 수정 일시

특히 버전 번호를 기준으로 빠르게 찾을 수 있어야 한다.

 

9.3 버전 검색의 필요성

버전 번호를 Ctrl + F로 검색했을 때
해당 수정 이력이 바로 걸리도록 설계한다.

이 구조가 없으면 다음 문제가 발생한다.

• 개발자 또는 구현자가
  • “어디가 바뀐 거예요?”
  • “이 수정은 언제 반영된 거죠?”

와 같은 질문을 반복하게 된다.

이는 협업 비용을 크게 증가시킨다.

특별한 거는 이제 이러한 수정 이력 같은 것들에 대한 표시인데
이 페이지는 좀 수정이 많았던 특성을 지니고 있고요.
수정을 가장 나이스하게 표현을 할 수 있는 방법이
이 넘버 버전을  ctrl +  f 로 찾을 수 있게 만들어주는 방법이 채택된다.
입력했을 때 엔터를 치게 되면 이게 딱딱 걸려질 수 있게끔 만들어줘야 돼요.

 

10. 상품 관리 화면설계 핵심 요약

상품 관리 화면설계의 핵심은 다음과 같다.

1. 목록은 조회 중심으로 설계한다.
2. 조회 영역은 항상 상단에 배치한다.
3. 기본 조회 기간을 설정한다.
4. 목록에서는 최소 정보만 노출한다.
5. 상세와 수정을 통합해 공수를 줄인다.
6. 수정 가능/불가 항목을 명확히 구분한다.
7. 도메인 특성(룸 타입 등)을 설계에 반영한다.
8. 수정 이력은 반드시 관리 가능하게 만든다.