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

최초 시작은 정보구조부터

1. 정보구조부터 시작해야 하는 이유

백오피스(BO) 화면설계를 시작하기 전에 반드시 선행되어야 하는 작업은 정보구조 정의다.
화면을 먼저 그리는 것이 아니라, 어떤 정보들이 어떤 단위로 존재하는지를 먼저 정리해야 한다.

 

정보구조가 없는 상태에서 화면 설계를 시작하면

• 화면 범위가 계속 늘어나고
• 메뉴가 뒤엉키며
• 작업 공수 산정이 불가능해진다

그래서 BO 설계의 출발점은 항상 정보구조다.

 

2. 정보구조를 만드는 첫 번째 방법: 마인드맵

정보구조를 만드는 방법은 여러 가지가 있지만,
그중 초기 설계 단계에서 가장 효율적인 도구는 마인드맵이다.

 

마인드맵은 아이디어 발산용 도구로 많이 알려져 있지만, 실제로는 정보를 덩어리 단위로 구조화하는 데 매우 적합하다.

 

예시

• 전시 관리
  • 배너 관리
    • 목록 페이지
    • 등록 / 수정 페이지
  • 기획전 관리
• 상품 관리
• 공지사항 관리

이렇게 메뉴 → 하위 메뉴 → 페이지 단위로 자연스럽게 확장해 나갈 수 있다.

 

3. 정보구조의 핵심 단위는 ‘페이지’

정보구조에서 가장 중요한 개념은 페이지 단위다.

• 페이지는 독립된 정보의 덩어리
• 웹에서는 보통 하나의 페이지 = 하나의 URL
• 앱에서는 하나의 액티비티 / 화면 단위

즉, 정보구조는
👉 “우리가 몇 개의 독립된 페이지를 만들 것인가”를 정의하는 작업이다.

4. 메뉴는 페이지가 아니다

여기서 반드시 구분해야 할 개념이 있다.

메뉴란?

• 페이지들을 묶는 폴더 개념
• 탐색을 쉽게 하기 위한 구조물
• 페이지가 아니기 때문에 설계 대상이 아니다

그래서 정보구조를 만들 때

• 메뉴는 0번
• 실제 페이지는 1번부터

이렇게 구분하는 방식을 많이 쓴다.

 

예시

• 전시 관리 (0)
  • 배너 목록 (1)
  • 배너 등록 (1)
  • 배너 상세/수정 (1)

이렇게 해야 실제 작업 페이지 수를 정확히 파악할 수 있다.

 

5. 정보구조 + 화면 ID는 반드시 함께 간다

To-be 백오피스의 정보구조가 만들어지면,
이 구조는 반드시 화면 ID 체계와 함께 정의되어야 한다.

• 정보구조 → 페이지 목록
• 화면 ID → 실제 설계/개발 참조 기준

그래서 이후 화면설계서에서 사용하는:

• 화면 목록
• 로케이션 정보

는 정보구조를 그대로 복사해서 사용하는 것이 가장 효율적이다.

 

6. FO 담당자와의 연계성을 고려한 메뉴 설계

백오피스 메뉴 구조는 FO(프론트) 업무 구조와 강하게 연결된다.

기본 원칙

• 전시 담당자 → 전시 관리 / 상품 관리
• 주문 담당자 → 주문 / 결제 관리
• CS 담당자 → 회원 / 고객 관리

회원 관리하던 사람이 전시 관리하는 구조는 비효율적이다.
그래서 업무 연계성 기준으로 메뉴를 묶는 것이 중요하다.

 

7. FO 변화가 BO에 미치는 영향

프론트에서 기능이 하나 추가되면, 백오피스에는 연쇄적인 영향이 발생한다.

예시

• FO에 ‘정기 구매’ 기능 추가
  • BO 주문 관리에 주문 구분 값 필요
  • 통계 / 정산 / 회원 등급에도 영향

FO에서는 작은 변화처럼 보여도,
BO에서는 여러 메뉴에 걸친 구조적 변화가 생길 수 있다.

그래서 BO 설계 시에는 항상:

“이 변화가 다른 메뉴에 어떤 영향을 주는가?”

를 함께 검토해야 한다.

 

8. As-Is 유지의 중요성

관리자 시스템에서 가장 중요한 특성 중 하나는 익숙함이다.

• 관리자는 기존 시스템에 이미 적응되어 있다
• 무조건 새롭게 바꾸는 것이 항상 좋은 것은 아니다

그래서 원칙은 다음과 같다.

• As-Is 유지가 기본
• 사용성 개선이 명확한 경우에만 변경

“혁신적이다”라는 이유만으로 바꾸는 것은
BO에서는 오히려 리스크가 된다.

 

9. 공통 코드 관리의 위치

보통 커머스 BO에서는 역할이 이렇게 나뉜다.

• 상품/전시 담당
• 주문/결제 담당
• 회원/CS 담당
• 공통 코드 관리 담당 (보통 기획 리더)

공통 코드 관리에는 예를 들어:

• 분류 체계
• 프로모션 코드
• 기획전 코드
• 도시 / 국가 / 항공 코드 등

여러 메뉴에서 공통으로 쓰이는 값들이 들어간다.

이 공통 코드를 다른 메뉴들이 불러다 쓰는 구조를 만드는 것이 이상적이다.

 

10. 정보구조 설계의 3단계

① 정보 그룹 정의

모든 정보는 크게 5가지 그룹으로 나뉜다.

 

메인 그룹

• 백오피스에서는 로그인
• 권한 진입의 기준

프로덕트 그룹

• 전시, 상품, 주문, 회원 등 핵심 기능

서치 그룹

• BO에서는 ‘메뉴 검색’ 기능

유틸리티 그룹

• 알림, 현황, 로그 등 보조 정보

컴퍼니 그룹

• 관리자 정보 정도만 제공
• 프론트처럼 법적 정보 제공 필요 없음

 

② 메뉴와 페이지 정의

• 페이지: 독립된 정보 단위 (작업 공수 산정 기준)
• 메뉴: 페이지를 묶는 폴더 (탐색용)

페이지 수를 알아야:

• 일정 산정 가능
• 리소스 협의 가능
• “이거 며칠 걸려요?”에 답할 수 있다

 

③ 공수 산정 기준으로서의 정보구조

예를 들어:

• 총 128페이지
• 하루 3페이지 설계 가능

→ 약 40일 소요

이 기준 없이 “한 달이면 되겠죠?”라고 말하는 순간, 프로젝트는 위험해진다.

정보구조는 기획자의 방어막이기도 하다.

 

11. 정보구조에 포함하지 않는 것들

알럿 / 시스템 메시지

• 페이지 아님
• 정보구조에 포함하지 않음
• 화면설계서에서만 언급

페이지 내 섹션

• 메인 페이지 내 여러 영역(베스트, 신상품 등)
• 정보구조가 아닌 화면 설계 단계에서 다룬다

 

12. 정보구조 vs 메뉴구조도 vs 사이트맵

 

구분	목적	특징
정보구조도	구축/운영	페이지 단위, 구현 기준
메뉴구조도	설명/보고	폴더 중심, 추상적
사이트맵	사용자 안내	서비스 소개용

 

13. 정보구조와 내비게이션의 차이

• 정보구조: 정보의 성격과 분류
• 내비게이션: UI 표현 방식

정보구조는 같아도

• PC
• 모바일

에서 내비게이션은 달라질 수 있다.

 

마켓컬리 사례처럼

• 같은 정보
• 다른 내비게이션 배치

이것이 정상이다.

 

핵심 요약

• BO 설계는 정보구조 → 화면설계 순서로 간다
• 정보구조의 단위는 페이지
• 메뉴는 폴더이며 설계 대상이 아니다
• 정보구조는 공수·일정·범위의 기준
• 정보구조와 내비게이션은 완전히 다른 개념이다