최초 시작은 정보구조부터

백오피스 화면설계를 시작할 때 가장 많이 하는 실수가 있습니다. 화면부터 그리기 시작하는 것입니다. 버튼 배치, 테이블 구성, 탭 구조 같은 시각적 설계로 바로 들어가 버리는 순간, 설계는 방향을 잃기 시작합니다. 백오피스 설계의 출발점은 화면이 아니라 정보구조입니다. 어떤 정보가 존재하고, 그 정보가 어떤 단위로 나뉘며, 몇 개의 독립된 페이지로 구성되는지를 먼저 정의해야만 이후의 모든 설계가 안정적으로 이어질 수 있습니다.

정보구조가 정리되지 않은 상태에서 화면을 그리기 시작하면 문제가 연쇄적으로 발생합니다. 화면 범위는 계속 늘어나고, 메뉴는 뒤엉키며, 작업 공수 산정은 불가능해집니다. “이게 몇 페이지인지”, “이게 얼마나 걸리는지”를 말할 수 없게 됩니다. 그래서 백오피스 설계의 출발점은 언제나 정보구조 정의입니다. 

 

정보구조를 만드는 첫 단계는 마인드맵이다

정보구조를 만드는 방법은 다양하지만, 초기 설계 단계에서 가장 효율적인 도구는 마인드맵입니다. 마인드맵은 흔히 아이디어 발산 도구로 알려져 있지만, 실제로는 정보를 덩어리 단위로 묶고 확장해 나가기에 매우 적합합니다.
예를 들어 전시 관리라는 큰 그룹을 놓고 그 아래에 배너 관리, 기획전 관리, 팝업 관리 등을 확장해 나갑니다. 배너 관리 아래에는 다시 목록 페이지, 등록/수정 페이지, 상세 페이지처럼 실제 페이지 단위가 파생됩니다. 이런 식으로 메뉴 → 하위 기능 → 페이지 단위로 자연스럽게 구조가 확장됩니다.

이 단계에서는 정교함보다 빠른 구조화가 중요합니다. 무엇이 존재해야 하는지를 빠르게 덩어리 단위로 나누고, 그 안에서 실제 페이지를 도출하는 것이 핵심입니다.

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

정보구조에서 가장 중요한 개념은 페이지입니다. 페이지는 독립된 정보의 덩어리이며, 웹에서는 보통 하나의 URL, 앱에서는 하나의 액티비티 또는 화면 단위에 해당합니다. 정보구조를 만든다는 것은 결국 “우리가 몇 개의 독립된 페이지를 만들 것인가”를 정의하는 작업입니다. 페이지 수가 곧 작업 범위이고, 페이지 수가 곧 일정 산정의 기준이 됩니다. 이 지점에서 반드시 구분해야 할 개념이 있습니다. 바로 메뉴와 페이지의 차이입니다.

메뉴는 페이지가 아니다

메뉴는 페이지를 묶는 폴더 개념입니다. 탐색을 쉽게 하기 위한 구조물일 뿐, 설계 대상이 아닙니다. 반면 페이지는 실제로 설계하고 구현해야 하는 대상입니다.
그래서 정보구조를 만들 때는 메뉴를 0번으로 두고, 실제 페이지를 1번부터 카운팅하는 방식을 많이 사용합니다. 예를 들어 전시 관리라는 메뉴는 0번이고, 그 아래의 배너 목록, 배너 등록, 배너 상세/수정은 각각 1페이지로 계산합니다. 이렇게 구분해야 실제 작업 페이지 수를 정확히 파악할 수 있습니다. 메뉴를 페이지로 착각하는 순간 공수 산정은 왜곡됩니다. 페이지와 메뉴를 구분하는 것, 이것이 정보구조 설계에서 가장 중요한 핵심입니다. 

 

정보구조와 화면 ID는 반드시 함께 간다

To-Be 백오피스 정보구조가 완성되면, 그 구조는 화면 ID 체계와 반드시 연결되어야 합니다. 정보구조는 페이지 목록이고, 화면 ID는 실제 설계와 개발에서 참조하는 기준입니다.

이후 화면설계서에서 사용하는 화면 목록과 로케이션 정보는 정보구조를 그대로 복사해서 사용하는 것이 가장 효율적입니다. 정보구조가 흔들리면 화면설계서도 흔들리고, 화면 ID 체계도 무너집니다. 그래서 정보구조는 단순한 참고 문서가 아니라 설계 전체의 기준 문서입니다.

백오피스 메뉴는 업무 구조와 연결되어야 한다

백오피스 메뉴 구조는 프론트 구조와도 연결되지만, 무엇보다 운영자의 업무 구조와 강하게 연결됩니다. 전시 담당자는 전시 관리와 상품 관리를 중심으로 작업하고, 주문 담당자는 주문과 결제 관리 중심으로 작업합니다. CS 담당자는 회원과 고객 관리 중심으로 움직입니다.

회원 관리하던 사람이 갑자기 전시 관리까지 맡는 구조는 비효율적입니다. 메뉴를 묶을 때는 정보의 성격뿐 아니라 실제 업무 흐름도 함께 고려해야 합니다. 정보구조는 시스템 구조이면서 동시에 조직 구조와도 연결되는 설계입니다.

 

프론트 변화는 백오피스에 연쇄 영향을 준다

프론트에서 작은 기능 하나가 추가되면, 백오피스에서는 구조적 변화가 연쇄적으로 발생합니다. 예를 들어 프론트에 정기 구매 기능이 추가되면, 백오피스 주문 관리에는 주문 구분 값이 필요해지고, 통계와 정산, 회원 등급에도 영향이 생깁니다.

프론트에서는 작은 버튼 하나의 추가처럼 보일 수 있지만, 백오피스에서는 여러 메뉴에 걸친 구조 변경이 발생할 수 있습니다. 그래서 백오피스를 설계할 때는 항상 “이 변화가 다른 메뉴에 어떤 영향을 주는가”를 함께 검토해야 합니다.

 

As-Is 유지는 백오피스에서 중요한 원칙이다

관리자 시스템에서 가장 중요한 특성 중 하나는 익숙함입니다. 관리자는 기존 시스템에 이미 적응되어 있습니다. 그래서 무조건 새롭게 바꾸는 것이 항상 좋은 선택은 아닙니다. 기본 원칙은 As-Is 유지입니다. 사용성 개선이 명확한 경우에만 변경합니다. 혁신적이라는 이유만으로 바꾸는 것은 백오피스에서는 오히려 리스크가 됩니다. 정보구조를 설계할 때도 기존 구조를 존중하면서 필요한 부분만 개선하는 태도가 중요합니다. 

 

공통 코드 관리는 별도의 책임 영역이다

커머스 백오피스에서는 보통 상품/전시, 주문/결제, 회원/CS로 역할이 나뉘고, 공통 코드 관리는 별도의 책임 영역으로 둡니다. 분류 체계, 프로모션 코드, 기획전 코드, 도시/국가 코드 등 여러 메뉴에서 공통으로 사용하는 값들은 공통 코드 관리에서 정의하고, 다른 메뉴는 이를 불러다 쓰는 구조를 만드는 것이 이상적입니다.
이 구조를 지키지 않으면 같은 값을 여러 화면에서 중복 정의하게 되고, 정책 충돌과 유지보수 문제로 이어집니다.

정보구조 설계의 3단계

첫 번째 단계는 정보 그룹 정의입니다. 백오피스 정보는 크게 메인 그룹, 프로덕트 그룹, 서치 그룹, 유틸리티 그룹, 컴퍼니 그룹으로 나눌 수 있습니다. 로그인과 권한 진입은 메인 그룹, 전시·상품·주문·회원은 프로덕트 그룹에 해당합니다.

두 번째 단계는 메뉴와 페이지 정의입니다. 여기서 다시 한 번 강조해야 할 점은 페이지가 독립된 정보 단위이며 공수 산정 기준이라는 점입니다. 메뉴는 폴더일 뿐입니다. 페이지 수를 알아야 일정 산정과 리소스 협의가 가능합니다.

세 번째 단계는 공수 산정 기준으로서의 정보구조 활용입니다. 예를 들어 총 128페이지이고 하루 3페이지 설계 가능하다면 약 40일이 필요하다는 계산이 가능합니다. 이 기준 없이 일정이 정해지면 프로젝트는 위험해집니다. 정보구조는 기획자의 방어막입니다.

 

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

알럿이나 시스템 메시지는 페이지가 아닙니다. 정보구조에 포함하지 않고 화면설계 단계에서만 다룹니다. 또한 메인 페이지 내 여러 섹션, 예를 들어 베스트 상품 영역이나 신상품 영역은 페이지가 아니라 화면 내 영역이므로 정보구조 단계에서 다루지 않습니다. 이 구분이 명확하지 않으면 정보구조가 과도하게 비대해집니다.

정보구조와 메뉴구조도, 사이트맵의 차이

정보구조도는 구축과 운영을 위한 문서입니다. 페이지 단위이며 구현 기준입니다. 메뉴구조도는 설명이나 보고를 위한 문서로, 폴더 중심이며 상대적으로 추상적입니다. 사이트맵은 사용자 안내용으로, 서비스 소개에 가깝습니다. 이 세 가지는 목적이 완전히 다릅니다. 특히 백오피스 설계에서는 메뉴구조도가 아니라 정보구조도가 기준이 됩니다.

정보구조와 내비게이션은 다른 개념이다

정보구조는 정보의 성격과 분류를 정의하는 것이고, 내비게이션은 그것을 어떻게 UI로 표현할지에 대한 문제입니다. 정보구조는 같아도 PC와 모바일에서 내비게이션 배치는 달라질 수 있습니다. 같은 정보를 다른 방식으로 배치하는 것은 정상입니다. 중요한 것은 UI 표현이 아니라 정보의 분류 기준입니다.

핵심 정리

백오피스 설계는 정보구조에서 시작해 화면설계로 이어집니다. 정보구조의 단위는 페이지이며, 메뉴는 폴더입니다. 페이지와 메뉴를 구분하지 못하면 공수 산정도, 일정 계획도 불가능합니다. 정보구조는 범위와 일정의 기준이자 기획자의 방어 장치입니다. 또한 정보구조와 내비게이션은 완전히 다른 개념입니다.
이 기준이 흔들리지 않아야 이후에 등장할 권한 관리, 화면 연결 구조, 기능 확장 설계가 안정적으로 이어질 수 있습니다. 다음 단계인 권한 관리 역시 이 정보구조 위에서 정의되어야 합니다.