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

자주 하는 실수와 대안

> BO 화면설계 실무 기준 정리 

 

1. 버전 / 규정 이력 관리 미흡

❌ 자주 하는 실수

• 버전 번호만 있고 변경 내용이 불명확
• 수정 이력이 문서 어딘가에 흩어져 있음
• “최신본”이 무엇인지 한눈에 알 수 없음
• 작업자마다 다른 버전을 보고 작업

⚠️ 발생하는 문제

• 잘못된 화면 기준으로 개발
• 이미 수정된 내용을 다시 구현
• “이거 언제 바뀐 거예요?” 반복 질문
• 책임 소재 불명확

⭕ 대안 (필수 원칙)

버전 규칙 고정

• v0.1 / v0.2 / v1.0 처럼 명확하게

이력 카드 필수

• 버전 / 변경일 / 변경자 / 변경 요약

검색 가능해야 함

• 변경 키워드로 Ctrl + F 시 바로 발견

배포 기준 명확화

• 내부 작업 중 변경 ❌
• 외부 공유 / 공식 배포 이후 변경 ⭕ 이력 기록

✔️ “이 버전에서 무엇이 바뀌었는지
문서만 봐도 바로 알 수 있어야 한다”

 

 모두 다 그렇지는 않지만 백오피스에서의 어떤 정보들이 프론트에 노출되는지
반대로 프론트에서 입력받은 정보가 백오피스 어디로 이어지는지
이러한 연결성을 하나의 참고 자료로 넣어주기도 합니다.

 

2. 프론트 ↔ 백오피스 데이터 연계 설명 누락

❌ 자주 하는 실수

• BO 화면만 설명하고 끝
• 이 데이터가 프론트 어디에 쓰이는지 없음
• 프론트 입력값이 BO 어디로 가는지 불명확

언제 문제가 되나?

• 개발자가 프론트·백오피스를 동시에 구현할 때
• 외부 어드민 / 외부 시스템 연동이 있을 때
• “이 값 왜 필요해요?” 질문이 나올 때

 

⭕ 대안 (선택 사항이지만 강력 추천)

연계성 표기 예시

• “해당 정보는 프론트 메인 배너 영역에 노출”
• “프론트 입력값 → BO [전시 > 배너 관리] 저장”
• “외부 어드민에서 가져오는 데이터”

✔️ 모든 페이지에 필요 없음
✔️ 중요한 페이지 / 요청 받은 페이지만

이건 설계가 아니라 배려다
하지만 이 배려 하나로 개발 효율이 크게 올라간다

 

모든 페이지가 이럴 필요는 없겠지만 어떤 주요한 페이지나 개발 쪽에서 요청이 오는 페이지들은
이런 식의 어떤 연계성 표시를 해 주시면 개발 쪽에서도 효율적으로 기획자를 대해줄 수 있어서
서로 호흡을 잘 맞출 수 있는 토대가 됩니다.

보통 그냥 써주는 것으로 끝나는데 설명을 쓰는 것을 넘어서 좀 중요한 점을 짚어서 기재를 해놓으면
이제 개발적으로도 놓치지 않을 수 있겠죠.

 

3. 화면 목록을 대충 만드는 실수

❌ 자주 하는 실수

• 화면 목록이 없거나 부실
• 메뉴 범위가 한눈에 안 보임
• 페이지 ID가 흩어져 있음

⚠️ 판단 기준

“어제 입사한 개발자가
설명 없이 이 문서만 보고 개발할 수 있는가?”

 

NO라면 → 화면 목록이 부족한 것

 

⭕ 대안 (화면 목록의 역할)

화면 목록은

• 이 메뉴에 어떤 페이지들이 포함되는지
• 전체 범위를 한 번에 인식하게 해주는 장치

✔️ 정보 구조도에서 그대로 복사
✔️ 메뉴 단위로 정리
✔️ 페이지 ID / 페이지명 명확히

 

4. 플로우 차트를 생략하거나 잘못 만드는 경우

❌ 자주 하는 실수

• 플로우 차트 없음
• 로직을 과도하게 넣음
• 페이지 관계가 안 보임

⚠️ 결과

• 개발자가 “플로우 차트 주세요” 요청
• 기획 의도 파악 불가
• 개발자가 역으로 구조를 추론해야 함

 

⭕ 플로우 차트의 올바른 목적

기획자가 만드는 플로우 차트는
“페이지 간의 관계”를 보여주는 문서다

• 로직 상세 ❌
• 조건문 구현 ❌
• 페이지 이동 흐름 ⭕
• 분기 구조 ⭕

 

5. 플로우 차트 레벨 정리

플로우 차트에는 레벨이 있다.

레벨	담당
시스템 / 프로그램 로직	개발
상세 로직	개발
페이지 단위 흐름	기획자

기획자는

• 화면 ID 기준
• 페이지 간 이동
• 분기 구조만 제공

 

6. 플로우 차트 작성 실무 순서

Step 1

• 해당 메뉴에 포함된 모든 페이지 박스 배치
• 페이지 ID 표기

Step 2

• 메뉴 / 페이지 / 분기점 구분
  • 메뉴: 설명용
  • 페이지: 사각형
  • 분기: 다이아몬드

Step 3

• 페이지 간 연결 화살표
• 단방향 / 양방향 표시

Step 4

• 분기점은 반드시 다이아몬드
  • 예: 확인 / 취소
  • 조건에 따른 이동

✔️ 시작/끝 라운드는 선택
✔️ 중요한 건 관계가 보이는가

 

플로우 차트를 만들 때 주의하실 사항은 일단은 작성한 메뉴에 포함되어 있는 페이지들을 쭉 그냥 올려놔요.*

박스 채 올려놓고 거기에 이제 아이디를 입력하거나 이건 메뉴야 이건 페이지야 이거는 그냥 뭔가 분기를 하기 위한 장치야처럼 해당하는 각 단위에 대한 속성을 적어봅니다.

그리고 페이지끼리 이어지는 것도 있고 한 페이지에서 두 개가 갖는 것도 있죠.

이것 관계성을 화살표로 정리를 하고요. 이제 시작되는 시점이나 끝나는 시점은 보통 라운드로 표시를 해서 구분을 짓는데 이것도 좀 이제 개발적인 관점이고
그냥 그것을 이게 메뉴다 페이지다 혹은 분기점이다라고 표현하는 것으로 충분한 것 같아요.**

기획적인 입장에서는 다만 분기가 있는 경우에는 다이아몬드를 쓰는 게 훨씬 낫겠죠.

그래서 다이아몬드로 표시해 준다. 그 이유가 어떤 로직에 따라서  Yes/No 인지, 아니면 버튼에 따라서 확인 취소 때문에 돌아가는지 이런 것들을 설명해 주게 되면 흐름이 보이는 수준이 되겠죠.

 

7. 플로우 차트는 “마지막에” 만든다

❌ 흔한 실수

• 화면 설계 전에 플로우부터 그림

⭕ 권장 순서

1. 정보 구조 정리
2. 화면 목록 확정
3. 상세 화면 설계 완료
4. 존재하는 페이지 기준으로 플로우 작성

플로우 차트는 설계 결과를
“요약”하는 문서다

 

 

어떤 도식으로 프로세스나 로직을 설명하는 문서의 어떤 총칭을 플로우 차트라고 부르죠.
이 플로우 차트는 여러 가지 레벨이 있어요. 시스템 프로그램 일반 상세 이렇게 있는데
기획자가 하는 것은 이 프로그램의 대략적인 수준의 순서도가 필요한 겁니다.

 

이것을 기획자는 회의실 단위 즉 화면 아이디가 있는 페이지 단위로 제공해 줌으로써
구현자들이 이것보다 더 상세한 구현을 할 수 있도록 개발 설계를 할 수 있도록 돕는 역할로서 활용된다.

 

 

그래서 화면 설계서에 제공되는 플로우 차트는 저 같은 경우에 맨 마지막에 업데이트를 해요.
화면 목록을 구성하고 상세를 다 그린 다음에 최종적으로 이제 존재하는 것들만
어떻게 이어지는지를 보여주기 위해서 만드는 편이고요.

 

정리하자면,

 

• 버전과 이력은 검색 가능하게
• 프론트–BO 연계는 요청 시 명확히
• 화면 목록은 신입 기준
• 플로우 차트는 페이지 관계 설명용
• 로직은 개발자 영역
• 플로우는 설계 끝나고 만든다