자주 하는 실수와 그에 대한 대안

백오피스 화면설계를 하다 보면 반복적으로 발생하는 실수들이 있습니다. 이 실수들은 단순한 문서 정리의 문제가 아니라, 개발 지연과 커뮤니케이션 비용 증가로 이어지는 구조적인 문제를 만들어냅니다. 특히 백오피스는 프론트와 달리 내부 운영을 위한 시스템이기 때문에, 작은 설계 누락 하나가 실무 전체에 영향을 줄 수 있습니다. 이 글에서는 실무에서 실제로 자주 발생하는 문제와 그에 대한 현실적인 대안을 정리하겠습니다.

 

버전, 개정 이력 관리

가장 먼저 짚어야 할 부분은 버전과 개정 이력 관리입니다. 화면설계서를 작성하면서 버전 번호만 올려두고, 무엇이 변경되었는지를 명확히 기록하지 않는 경우가 많습니다. 변경 내용이 문서 곳곳에 흩어져 있거나, 최신본이 무엇인지 한눈에 파악되지 않는 경우도 자주 발생합니다. 그 결과 작업자마다 서로 다른 버전을 기준으로 작업하게 되고, 이미 수정된 내용을 다시 구현하거나 “이거 언제 바뀐 거예요?”라는 질문이 반복됩니다. 책임 소재도 불명확해지고, 불필요한 커뮤니케이션 비용이 계속 쌓이게 됩니다.

이 문제를 방지하기 위해서는 버전 규칙을 명확하게 고정해야 합니다. v0.1, v0.2, v1.0과 같이 일관된 체계를 사용하고, 개정 이력에는 반드시 버전, 변경일, 변경자, 변경 요약을 포함해야 합니다. 무엇보다 중요한 것은 검색 가능성입니다. 특정 키워드를 Ctrl + F로 검색했을 때 바로 해당 변경 이력이 발견되어야 합니다. 또한 내부 작업 중 수정과 외부 공유 이후 수정은 구분되어야 합니다. 공식 배포 이후 변경된 사항만 이력 카드로 관리하는 원칙을 명확히 하면, 문서 신뢰도는 자연스럽게 올라갑니다. 핵심은 단 하나입니다. 이 버전에서 무엇이 바뀌었는지 문서만 보고도 바로 알 수 있어야 합니다.

 

FO - BO 간 데이터 연계 설명의 누락

두 번째로 많이 발생하는 문제는 프론트와 백오피스 간 데이터 연계 설명의 누락입니다. 백오피스 화면만 설명하고 끝내는 경우가 많습니다. 이 데이터가 프론트 어디에 쓰이는지, 프론트에서 입력된 값이 백오피스 어디로 이어지는지에 대한 설명이 빠지는 것입니다. 이런 부분은 특히 개발자가 프론트와 백오피스를 동시에 구현해야 하는 상황이나, 외부 어드민과 연동이 있는 경우에 문제가 됩니다. “이 값은 왜 필요한가요?”라는 질문이 나오는 순간, 설계의 연결성이 부족하다는 신호가 됩니다.

모든 페이지에 연계 설명을 넣을 필요는 없습니다. 그러나 주요 기능이거나 개발 측에서 요청이 있는 경우에는 연계성을 명시해 두는 것이 좋습니다. 예를 들어 “해당 정보는 프론트 메인 배너 영역에 노출됩니다.” 또는 “프론트 입력값은 BO 전시 > 배너 관리에 저장됩니다.”와 같은 간단한 문장만 있어도 개발자는 맥락을 빠르게 이해할 수 있습니다. 이는 설계의 의무라기보다 협업을 위한 배려에 가깝습니다. 그러나 이 작은 배려 하나로 개발 효율은 크게 향상됩니다.

 

화면 목록을 대충 작성한다

세 번째는 화면 목록을 대충 작성하는 실수입니다. 화면 목록이 없거나, 메뉴 범위가 한눈에 보이지 않거나, 페이지 ID가 체계 없이 흩어져 있는 경우가 있습니다. 이런 문서는 신입 개발자가 단독으로 이해하기 어렵습니다. 판단 기준은 간단합니다. 어제 입사한 개발자가 설명 없이 이 문서만 보고 작업을 시작할 수 있는가를 스스로에게 물어보시면 됩니다. 만약 그렇지 않다면 화면 목록이 부족한 것입니다.

화면 목록은 단순한 목차가 아닙니다. 해당 메뉴에 어떤 페이지들이 포함되어 있는지 전체 범위를 한 번에 인식하게 해주는 장치입니다. 정보 구조도에서 정의한 페이지를 그대로 복사해 메뉴 단위로 정리하고, 페이지 ID와 페이지명을 명확히 표기해야 합니다. 이것이 설계 범위의 기준점이 됩니다.

 

Flow Chart를 생략하거나 잘못 작성한다

다음으로 자주 발생하는 문제는 플로우 차트를 생략하거나 잘못 작성하는 경우입니다. 플로우 차트가 없으면 개발자는 구조를 추론해야 합니다. 반대로 플로우 차트에 과도한 로직을 넣으면 기획과 개발의 영역이 혼재됩니다. 기획자가 만드는 플로우 차트는 페이지 간의 관계를 보여주는 문서입니다. 로직 상세나 조건문 구현은 개발자의 영역입니다. 기획자는 화면 ID 기준으로 페이지 이동 흐름과 분기 구조만 명확히 제공하면 충분합니다.

플로우 차트에도 레벨이 있습니다. 시스템 로직과 상세 로직은 개발자가 다루고, 기획자는 페이지 단위 흐름만 다룹니다. 작성 순서 역시 중요합니다. 먼저 해당 메뉴에 포함된 모든 페이지를 박스로 배치하고, 페이지 ID를 입력합니다. 메뉴, 페이지, 분기점을 구분하고, 페이지 간 연결을 화살표로 표현합니다. 분기점은 다이아몬드로 표시하여 Yes/No 또는 확인/취소 흐름을 명확히 보여주면 됩니다. 중요한 것은 도형의 완성도가 아니라 관계가 명확하게 보이는지 여부입니다.

마지막으로 반드시 강조해야 할 점은 플로우 차트는 설계 초기에 만드는 문서가 아니라는 점입니다. 화면 설계를 시작하기 전에 플로우부터 그리는 경우가 있는데, 이는 권장되지 않습니다. 올바른 순서는 정보 구조를 정리하고, 화면 목록을 확정하고, 상세 화면 설계를 완료한 뒤, 존재하는 페이지 기준으로 흐름을 정리하는 것입니다. 플로우 차트는 설계 결과를 요약하는 문서입니다. 전체 구조를 한눈에 보여주는 정리 문서라고 이해하시는 것이 정확합니다.