백오피스 화면설계서, 구조로 승부하는 문서의 기술

백오피스 화면설계서는 단순히 “관리자 화면을 그려놓은 문서”가 아닙니다. 그것은 프로젝트의 구조를 설명하고, 화면 간의 관계를 정리하며, 개발자·기획자·신규 투입 인력이 빠르게 전체 맥락을 이해하도록 돕는 설계 문서입니다. 이번 글은 로디 선생님의 백오피스 화면설계 원데이 클래스 내용을 기반으로, 백오피스 화면설계서가 어떤 구조로 구성되어야 하며, 왜 그렇게 구성해야 하는지를 정리한 내용입니다.

특히 백오피스 설계서는 대부분 PPT로 작성됩니다. 모바일 앱과 달리 백오피스는 주로 PC 환경에서 사용되며, 실제 화면 실측 비율에 집착하기보다는 설명의 정확성과 디테일, 그리고 UI 누락 여부가 더 중요하기 때문입니다. 스크롤 기반 화면을 표현하기에도 PPT가 적합하며, 무엇보다 설명과 설계를 함께 담기 좋은 형식입니다. 결국 중요한 것은 화면이 얼마나 “그럴듯해 보이느냐”가 아니라, 화면에 필요한 요소가 빠짐없이 정의되어 있고, 그 동작과 역할이 명확하게 설명되어 있느냐입니다.

 

화면설계서의 기본 구성

백오피스 화면설계서는 일반적으로 일정한 순서를 따릅니다. 표지, 개정 이력, 화면 목록, 플로우 차트, 컴포넌트 정의, 그리고 개별 화면 설계로 이어지는 구조입니다. 이 순서는 단순한 관습이 아니라, 문서를 처음 보는 사람이 점진적으로 이해하도록 설계된 흐름입니다.

표지에서는 프로젝트명, 문서명, 작성자, 작성일 정도만 명확히 제시하면 충분합니다. 과도한 디자인 요소는 필요하지 않습니다. 문서의 목적은 꾸미는 것이 아니라 설명하는 것이기 때문입니다.

개정 이력은 v0.1부터 시작해 버전이 올라갈 때마다 변경된 내용을 기록합니다. 버전, 변경 일자, 변경 내용, 필요하다면 변경 사유까지 남겨두면 문서의 신뢰도가 높아집니다. 화면설계서는 한 번 작성하고 끝나는 문서가 아니라, 수정과 보완이 반복되는 산출물이기 때문에 개정 이력은 매우 중요합니다.

화면 목록은 정보 구조도를 그대로 복사해 붙여 넣은 영역입니다. 새로 만드는 문서가 아닙니다. 이미 엑셀이나 스프레드시트로 정리된 메뉴–화면 구조를 그대로 가져와 사용하면 됩니다. 이 화면 목록의 목적은 단 하나입니다. “이 프로젝트에 어떤 메뉴와 화면이 있는가?”를 한눈에 보여주는 것입니다. 어제 합류한 개발자라도 이 문서를 통해 전체 범위를 즉시 파악할 수 있어야 합니다.

 

플로우 차트

플로우 차트는 반드시 포함하는 것이 좋습니다. 다만, 기획자가 만드는 플로우 차트의 역할을 명확히 이해해야 합니다. 기획자의 플로우 차트는 로직을 설명하는 도구가 아닙니다. 화면 간 연계성을 보여주는 도구입니다.

예를 들어 로그인 페이지에서 회원가입 페이지로 이동할 수 있고, 아이디/비밀번호 찾기로 이동할 수 있으며, 로그인 성공 시 메인 페이지로 이동하는 흐름을 표현하는 것입니다. 이것이 화면 간의 연계성입니다. 자주 발생하는 실수는 로그인 실패 조건이나 내부 예외 처리, 분기 로직까지 플로우 차트에 넣는 것입니다. 그것은 개발자의 설계 영역입니다. 기획자는 페이지 간의 연결 구조를 보여주면 충분합니다. 화면 목록과 플로우 차트를 함께 보면, 문서를 보는 사람의 머릿속에 전체 동작 흐름이 먼저 그려집니다. 그 다음에 개별 화면 설명을 읽으면 이해도가 훨씬 높아집니다.

 

컴포넌트 정의

컴포넌트 정의 영역은 필수는 아니지만, 포함하면 설계 품질이 크게 올라갑니다. 컴포넌트 정의의 목적은 화면 표현 방식을 통일하는 것입니다. 여러 명이 함께 작업하더라도 동일한 UI 요소를 동일한 방식으로 사용하도록 기준을 세워두는 것입니다.

라디오 버튼, 체크박스, 플러스/마이너스 버튼, 업/다운 버튼, 인풋 필드, 키워드 탭, 텍스트 에어리어 등 반복적으로 등장하는 요소를 정의해두면, 화면마다 표현이 달라지는 문제를 예방할 수 있습니다. 컴포넌트 관리가 되지 않은 팀은 같은 기능임에도 UI가 다르고, 설계자마다 표현 방식이 제각각입니다. 이는 단순한 디자인 문제가 아니라 기획 기본 개념의 부재를 보여주는 신호일 수 있습니다. 컴포넌트 정의는 설계의 표준을 만드는 작업입니다.

 

네비게이션 위치 표시 – 문서 내 ‘현재 위치’ 제공

개별 화면 설명에 들어가기 전, 현재 화면이 어디에 위치하는지를 시각적으로 표시하는 방식을 추천합니다. 예를 들어 좌측 메뉴에서 현재 위치를 빨간색 박스로 강조하는 방식입니다. 이 방식은 네이버 지도에서 ‘내 위치’를 표시해 주는 것과 같습니다. 문서를 보는 사람이 “내가 지금 어느 메뉴의 화면을 보고 있는지” 즉시 인지할 수 있게 해 줍니다. 화면 목록과의 연결도 자연스럽게 강화됩니다.

 

개별 화면 설계 – 페이지 단위 설명의 원칙

본격적인 설계 설명은 화면 ID 단위로 진행합니다. 각 화면에는 기본 정보 영역이 포함되어야 합니다. 화면 ID, 화면명, 로케이션 정보, 작성자 등은 정보 구조도에 이미 있는 내용을 그대로 가져옵니다. 새로 정의하는 것이 아닙니다.

레이아웃 영역에서는 와이어프레임 형태로 화면 구조를 표현합니다. 좌우 분할 구조인지, 테이블 영역은 어디에 위치하는지, 필터 영역과 버튼 위치는 어디인지 명확히 보여줍니다. 설명 영역에서는 넘버링 기법을 사용합니다. ①, ②, ③과 같은 번호를 부여하고, 각 영역 또는 요소를 설명합니다. 예를 들어 ② 데이터 테이블 영역, ②-1 선택 제외 버튼, ②-2 일괄 처리 버튼처럼 세분화합니다. 이 방식은 개발자와의 커뮤니케이션에서 매우 효과적입니다. 특정 번호를 기준으로 바로 대화할 수 있기 때문입니다.

 

공통 영역은 반드시 모듈화

헤더, 푸터, 공통 내비게이션은 모든 페이지에 반복해서 그리지 않습니다. 반복 영역이 본문을 압박하고, 변경 시 모든 페이지를 수정해야 하는 문제가 발생합니다. PPT 기반 설계서에서는 특히 치명적입니다.

올바른 방식은 헤더와 푸터를 별도 모듈 페이지로 관리하고, 개별 화면에서는 “공통 헤더 적용” 정도로만 표시하는 것입니다. 프론트 설계에서 공통 네비게이션을 모듈로 처리하는 것과 동일한 개념입니다. 변경에 유연한 설계가 되어야 합니다.

 

로케이션 정보 작성 시 주의점

로케이션 정보는 기본 정보 영역에 한 번만 작성합니다. 본문 설명에 반복해서 적지 않습니다. 화면 상단의 로케이션 영역만 참고하도록 유도해야 합니다. 본문에 다시 적으면 중복 정보가 발생하고, 공간이 낭비되며, 수정 시 불일치가 발생할 가능성이 높아집니다. 본문에서는 해당 화면에 표시되는 영역 설명에 집중하면 충분합니다.

 

구조를 증명하는 문서

백오피스 화면설계서는 단순한 UI 설명 문서가 아닙니다. 프로젝트 구조를 이해시키고, 화면 간 흐름을 인지하게 하며, 운영 관점의 사고를 담고, 팀 단위 협업을 고려한 설계를 증명하는 문서입니다. 문서의 완성도는 디자인이 아니라 구조에서 나옵니다. 표지에서 개정 이력으로, 화면 목록에서 플로우 차트로, 컴포넌트 정의에서 개별 화면 설계로 이어지는 흐름이 매끄럽다면, 그 설계서는 이미 절반은 성공한 것입니다.