기획전 구성 시 화면설계 원칙 정리

기획전 화면은 백오피스 설계에서 자주 등장하지만, 생각보다 오해가 많이 발생하는 영역입니다. 특히 “상품을 불러오는 방식”과 “화면을 어디까지 설계해야 하는지”에 대한 기준이 명확하지 않으면, 설계서가 불필요하게 비대해지거나 중복 정의가 발생하기 쉽습니다. 그래서 기획전 화면설계는 기능 자체보다도 설계 태도와 표현 원칙이 더 중요합니다. 아래에서는 기획전 구성 시 반드시 정리해 두어야 할 핵심 원칙들을 단계별로 설명합니다.

 

1. 기획전 상품 호출 구조의 기본 전제: 기획전은 ‘조합’이지 ‘생성’이 아니다

가장 먼저 분명히 해야 할 점은, 기획전은 새로운 상품을 만드는 기능이 아니라는 것입니다. 기획전은 이미 존재하는 상품 데이터를 불러와 조합하고, 배치하고, 노출 순서를 구성하는 기능입니다. 이 전제를 놓치면 설계가 잘못된 방향으로 흘러가기 시작합니다. 기획전 생성의 기본 흐름은 매우 단순합니다. 먼저 기획전 생성 페이지에 진입하고, 상품 추가 버튼을 클릭합니다. 그러면 기존의 상품 목록 페이지가 호출되고, 그 안에서 원하는 상품을 체크하여 등록합니다. 이렇게 체크 → 체크 → 등록 과정을 거쳐 기획전 구성이 완료됩니다. 이 구조를 이해하면, 기획전 설계는 “상품 생성”이 아니라 “상품 선택 및 배치”라는 점이 명확해집니다.

 

2. 중복 설계는 설계가 아니다. 하지 않는다.

기획전 설계에서 반드시 지켜야 할 핵심 원칙이 하나 있습니다. 이미 존재하는 페이지는 화면설계서에서 다시 그리지 않는다는 것입니다. 상품 목록 페이지는 이미 상품 관리 메뉴에 존재하고 있습니다. UI 구조, 검색 조건, 테이블 컬럼, 상태값 등 모든 것이 정의되어 있습니다. 그런데 기획전에서 상품을 불러온다고 해서 그 상품 목록 페이지를 다시 설계서에 통째로 그려 넣는다면, 이는 명백한 중복 설계가 됩니다.

중복 설계는 단순히 문서가 길어지는 문제가 아닙니다. 이후 상품 목록 페이지가 변경되었을 때, 기획전 설계서에 그려놓은 화면과 실제 화면이 달라질 가능성이 생깁니다. 즉, 설계 문서의 신뢰도가 떨어집니다. 그래서 원칙은 분명합니다. 이미 존재하는 화면은 “참조”하고, 다시 설계하지 않습니다.

 

3. 페이지 ID와 호출 방식만 명시한다

그렇다면 기획전 생성 화면에서 상품을 불러오는 구조는 어떻게 표현해야 할까요? 정답은 매우 간단합니다. 기존 페이지 ID를 명시하고, 호출 방식만 명확히 적어주면 됩니다.
예를 들어, 설계서에는 다음과 같이 표현하면 충분합니다. “상품 추가 버튼 클릭 시 상품 목록 페이지 (PAGE_ID: PRD-01) 팝업 호출”

이 한 줄이면 기능 설명은 완료됩니다. 상품 목록 페이지를 다시 그릴 필요도 없고, 팝업용 목록 화면을 새로 설계할 필요도 없습니다. UI는 기존 페이지를 그대로 사용하고, 기능은 선택 후 반환이라는 점만 명확히 하면 됩니다.
잘못된 방식은 팝업 전용 목록 화면을 새로 그리고, 동일한 UI를 두 번 정의하는 것입니다. 올바른 방식은 기존 페이지를 참조하고, 호출 관계만 명시하는 것입니다. 이 차이가 설계 품질을 결정합니다.

 

4. “팝업으로 불러옴”이라는 표현이 의미하는 것

설계서에 “팝업으로 불러온다”라고 적는 순간, 그 안에는 몇 가지 중요한 의미가 포함됩니다.

1. UI는 기존 페이지를 그대로 사용한다는 의미입니다.
2. 기능은 선택 후 반환 구조라는 의미입니다.
3. 신규 설계 대상이 아니라 참조 호출이라는 의미입니다.

그래서 팝업 전용 별도 화면 ID를 만들 필요도 없고, 팝업 전용 레이아웃을 새로 정의할 필요도 없습니다. 기획전 화면에서 할 일은 “상품을 선택해서 가져온다”는 흐름을 명확히 보여주는 것 뿐입니다.

 

5. 정보가 많을 때의 처리 방식 - 스크롤이나 페이지 분할이 아닌, 탭

기획전 상세 화면은 생각보다 많은 정보를 포함하게 됩니다. 기본 정보, 전시 상품 목록, 노출 설정, 이력 관리 등 성격이 다른 정보들이 한 화면에 모이게 됩니다. 이때 자주 발생하는 실수는 스크롤을 길게 늘리거나, 페이지를 억지로 분리하는 것입니다.

하지만 백오피스 설계의 일반적인 원칙은 다릅니다. 정보가 많을 때는 스크롤로 해결하지도 않고, 페이지를 쪼개지도 않습니다. 대신 탭(Tab) 구조로 구분합니다.
예를 들어, 기획전 상세에서는 다음과 같은 탭 구성이 자연스럽습니다.
기본 정보, 전시 상품 목록, 노출 설정, 이력/관리 정보.
이렇게 성격이 다른 정보 묶음을 탭으로 분리하면, 화면은 명확해지고 사용자는 필요한 정보에 빠르게 접근할 수 있습니다.

 

6. 탭은 정보 구조 관점에서는 ‘페이지’다

많은 분들이 놓치는 부분이 바로 이 지점입니다. 탭은 UI 컴포넌트일 뿐이라고 생각하지만, 정보 구조 관점에서는 탭 하나하나가 독립적인 페이지입니다. 
왜 페이지로 보아야 할까요? 각 탭마다 정보 구조가 다르고, 입력 항목이 다르며, 검증 로직이 다르고, 상태값이 다릅니다. 작업 공수도 다르고, 난이도도 다릅니다. 단순히 화면 안에서 버튼을 눌러 전환된다고 해서 동일한 작업량이 되는 것은 아닙니다.

그래서 정보 구조도에서는 기획전 상세라는 부모 페이지 아래에 각 탭을 별도의 PAGE로 정의해야 합니다. 예를 들어, 기획전 상세 아래에 기본 정보 탭, 상품 구성 탭, 노출 설정 탭, 이력 탭을 각각 PAGE 단위로 명시합니다. UI에서는 탭이지만, 설계와 공수 산정에서는 각각 1페이지로 계산하는 것이 원칙입니다.

탭을 페이지로 카운팅하지 않으면 반드시 문제가 발생합니다. 대표적인 문제가 “이거 한 페이지 아니었어요?”라는 논쟁입니다. 기획자는 한 화면이라고 생각했지만, 실제로는 네 개의 탭이 각각 다른 작업을 요구하고 있었다면, 공수 산정이 틀어지고 일정이 지연됩니다. 결국 책임 소재가 기획으로 돌아오는 상황이 생길 수 있습니다.
그래서 탭도 페이지로 센다는 원칙은 설계 초반에 반드시 명확히 해 두어야 합니다. 이는 단순한 표현상의 문제가 아니라, 프로젝트 일정과 비용을 좌우하는 기준입니다.

 

정리

기획전은 상품을 새로 만드는 기능이 아니라 이미 존재하는 상품을 불러와 조합하는 기능입니다. 이미 존재하는 페이지는 다시 설계하지 않고, 페이지 ID와 팝업 호출 표현으로 충분합니다. 정보가 많을 때는 탭을 사용하고, 탭은 UI 요소이지만 정보 구조상에서는 각각 페이지로 카운팅해야 합니다.

이 원칙들을 일관되게 적용하면, 기획전 설계는 훨씬 간결해지고, 문서는 중복 없이 정돈되며, 공수 산정과 일정 관리에서도 불필요한 논쟁을 줄일 수 있습니다. 결국 기획전 설계의 핵심은 기능을 얼마나 많이 그리느냐가 아니라, 무엇을 그리지 않아도 되는지를 정확히 아는 데 있습니다.