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

BO 디스크립션(Description) 작성 가이드

“디자인 설명이 아닌, 구현 설명 문서”

 

 

1. BO 디스크립션의 본질

✔️ 프론트 설명과의 근본적 차이

• 프론트
  • 디자인 설명 많음
  • 배너 사이즈, 여백, 색상, UI 표현 방식
• 백오피스
  • ❌ 디자인 설명 거의 없음
  • ⭕ 데이터, 로직, 기본값, 제약 조건 중심

BO 설명의 80%는 ‘개발자에게 하는 설명’이다

• PM: 거의 안 봄
• 디자이너: 안 봄
• 개발자: 이 문서로 구현함

 

2. BO는 “레고 블록 조립”이다

백오피스는 보통:

• 조회 모듈
• 컨트롤 모듈
• 테이블 모듈
• 폼 모듈

👉 이미 개발팀이 가진 컴포넌트로 조합

그래서:

• “이 버튼은 둥글고 파란색입니다” ❌
• “조회 버튼 클릭 시 아래 조건으로 데이터 호출” ⭕

 

3. 목록 페이지 디스크립션 핵심 ①

조회 기본값(Default Value)

왜 중요한가?

• 무심코 조회 버튼 클릭
• 결과가:
  • 너무 많아도 ❌
  • 아무것도 안 나와도 ❌

👉 기본값 설계 = 시스템 성능 + 사용성

 

기본값 정의 시 반드시 써야 할 것

기본 조회 기간

• 최근 7일 / 14일 / 30일

기본 상태값

• 전체 / 활성 / 비활성

필수 입력 조건 여부

• 코드 입력 필수인지
• 조건 없으면 조회 불가인지

 

실제 사례 (여행사 프로젝트)

• 상품 수: 1만 개 이상
• 모상품 + 자상품(일자별)

👉 조건 없이 조회하면

• 데이터 폭발
• 시스템 느려짐
• 서버 부하

그래서

• 상품 코드 입력 필수
• 기본값에서는 조회 안 함
• 입력 후에만 조회

📌 이런 제약은 반드시 디스크립션에 명시

 

4. 목록 페이지 디스크립션 핵심 ②

페이징 / 정렬 기본값

일반적인 기준

• 기본 노출 개수: 30개
  • (상황에 따라 15 / 20도 가능)
• 변경 가능 옵션 제공:
  • 10 / 30 / 50 / 100

👉 중요한 건:

• 기본값이 무엇인지
• 변경 시 어떤 동작이 일어나는지

 

정렬 기준도 판단 영역

• 기본: 최신순
• 추가 가능:
  • 인기순
  • 작성자별
  • 상태별

📌 “관리자 역할 놀이”를 해보며 판단
📌 디스크립션에 “왜 이 정렬이 있는지”까지는 안 써도 됨
→ 무엇이 있고 기본이 무엇인지만 명확히

 

 

5. 상세/수정 페이지 디스크립션 핵심 ①

수정 가능 / 불가 항목 구분

이걸 안 적으면 사고 난다

 

예시: 회원 정보

수정 가능

• 이메일
• 휴대폰 번호
• 주소

수정 불가

• 아이디
• 생년월일

👉 CS 목적상 필요한 것만 수정 가능

📌 “수정 불가”는 UI가 아니라 정책
📌 반드시 디스크립션에 명시

 

6. 등록 페이지 디스크립션 핵심

기본값(Default) & 필수값(Required)

기본값(Default)

• 활성 / 비활성
  • 대부분: 비활성
  • 이유
    • 활성 리스크 큼
    • 임시 저장 니즈 많음

 

필수값(Required) 정의 예시

• 필수
  • 상품명
  • 가격
• 선택
  • 옵션
  • 상품 설명
  • 규격 정보

📌 이 구분이 있어야

• 프론트 검증
• 백오피스 검증
• 에러 메시지 명확

 

7. 권한 관리 설명의 핵심 개념

왜 필요한가?

BO는 ‘사고를 막기 위한 시스템’

실제 사고 사례

• MD가 쿠폰 설정
• 프로모션 비용 회사 부담
• 의도 없음
• 권한이 있었기 때문에 가능

👉 권한 분리가 안 돼서 생긴 사고

 

BO 권한의 기본 분류 (표준)

• 보기(View)
• 쓰기(Create)
• 수정(Update)
• 삭제(Delete)
• 다운로드(Download)
• 승인(Approve)

 

각 권한의 의미

• 보기: 진입 가능 여부
• 쓰기: 신규 등록 가능 여부
• 수정: 값 변경 가능 여부
• 삭제: 데이터 제거 가능 여부
• 다운로드: 엑셀/데이터 추출
• 승인: 프로모션/정책 실행 승인

📌 특히 다운로드 / 승인은 매우 민감

 

권한 설계 원칙

• 개인 기준 ❌
• 권한 그룹 기준 ⭕
• 직원은 그룹에 매핑

📌 화면 설계서에 “권한 테이블”까지 만드는 건 비추천
→ 정보구조 + 권한 그룹 매핑으로 해결

 

8. 디스크립션 작성 방식 (실전)

✔️ 넘버링 기법

• 영역 + 항목 분리
• 예
  • 1. 조회 영역
    • 1.1 노출 상태
    • 1.2 노출 위치
    1. 데이터 테이블
    • 2.1 고유 코드
    • 2.2 노출 상태

👉 목적:

질문 안 오게 하기

 

✔️ 기본적으로 써야 하는 내용 포맷

① 이것이 무엇인지

• “노출 상태를 설정하는 필드”

② 값의 종류

• 전체 / 노출 / 미노출

③ 디폴트 값

• DF: 전체

④ 동작 설명

• 변경 시 목록 데이터 필터링

 

9. 데이터 테이블 설명 시 체크리스트

각 컬럼 정의

• 번호: 순번
• 고유 코드: 시스템 식별자
• 상태: 현재 노출 상태

페이징 동작

• 숫자 클릭
• 양 끝 이동

• 페이지당 노출 개수 변경 시 동작

📌 “다 아는 거” 같아도
📌 어제 입사한 개발자 기준으로 작성

 

10. 현실적인 작성 전략

• 모든 걸 다 쓰려고 하지 말 것
• 하루에 쓸 수 있는 시간 계산
• 우선:
  • 기본값
  • 정책
  • 제약
  • 위험 요소
• 이후:
  • 개발 피드백 받고 보완

핵심 요약

• BO 디스크립션은 디자인 문서가 아니다
• 설명 대상은 개발자
• 기본값 / 필수값 / 제약 조건이 핵심
• 수정 가능 / 불가 구분 필수
• 권한은 사고 방지 장치
• 넘버링으로 질문을 차단하라