[심화] UX 기획 3원칙 : 기획서가 견고한 시스템 아키텍처가 되기까지

💡알게 되는 것

• 컨셉스키마 (feat. Glossary)
• List, Form, Detail (feat. Hard Coding or Data Binding)
• CRUD (feat. Policy & RBAC)

---

3단계 프로세스

좋은 UX 기획은 단순히 ‘예쁜 화면’을 그리는 것이 아닙니다. 서비스의 뼈대가되는 컨셉 스키마를 세우고, 사용자가 만나는 화면을 설계하며, 그 화면이 동작하는 규칙을 정의하는 일련의 과정입니다.

 

STEP 1. What ⇒ 컨셉 스키마

STEP 2. Where ⇒ List, Form, Detail

STEP 3. How ⇒ CRUD & Policy

 

이 3단계 프로세스는 아이디어를 제대로 작동 가능한 서비스로 발전시키는 가장 논리적이고 효율적인 방법이라 할 수 있습니다.

---

STEP 1

WHAT : 컨셉스키마

서비스가 무엇으로 되어 있는지 뼈대를 잡는 첫 단계 입니다. 서비스의 핵심 ‘개념(명사)’과 그들 간의 ‘관계’를 명확하게 정의해야하는 중요 과정입니다.

 

핵심 구성 요소

객체 안에 속성이 있고, 각 객체 간의 연결 관계를 표현합니다.

• 객체(Entity) : 서비스의 핵심 ‘명사’입니다. (예: 회원, 게시물, 댓글, 상품, 주문)
• 속성(Attribute) : 각 객체가 가지는 ‘정보’입니다. (예: ‘회원’은 ‘아이디’, ‘이름’, ‘이메일’을 가짐)
• 관계(Relationship) : 객체 간의 ‘연결’입니다. (예: ‘회원’이 ‘게시물’을 작성한다. ‘상품’이 ‘주문’에 포함)
  
  

용어 정리

컨셉 스키마가 확정되었다면 용어 정리(Glossary)가 필요합니다. 기획, 디자인, 개발팀이 모두 동일한 용어를 사용하게 하여 커뮤니케이션 오류를 막는 일입니다. 예를 들면, ‘회원’, ‘유저’, ‘사용자’, ‘고객’이라는 말을 모두 ‘회원’으로 통일는 과정입니다.

💬 Tech Connection : 용어 정리는 단순 커뮤니케이션인가요?

용어 정리는 단순한 소통 규칙이 아닌, '시스템 네이밍 컨벤션(Naming Convention)'의 핵심입니다. 기획서에서 '회원'으로 통일했다면, 개발에서는 DB 테이블명 users, API 엔드포인트 /users, 코드 내 모델  UserModel 등으로 일관되게 사용되게 됩니다.

문서화

정의한 모든 객체와 주요 속성의 정의와 용어를 명확히 문서화해서 다같이 공유해야 합니다.

💬 Tech Connection : 컨셉스키마는 어떻게 사용되나요?

STEP 1에서 정의한 컨셉 스키마는 개발팀의 ERD(Entity-Relationship Diagram, 개체-관계 다이어그램)로 1:1 변환됩니다.

1. 객체(Entity) → DB 테이블(Table)
2. 속성(Attribute) → 테이블의 컬럼(Column)
3. 관계(Relationship) → 외래 키(Foreign Key) 및 조인 관계

---

STEP 2

WHERE : 뼈대에 살 붙이기

1단계의 '개념'을 사용자가 만나는 '화면'으로 구체화합니다.

와이어프레임 3종세트

객체 안에 속성이 있고, 각 객체 간의 연결 관계를 표현합니다.

대부분의 웹/앱 서비스 화면은 이 세 가지 기본 패턴의 조합으로 이루어집니다.

STEP 1에서 정의한 ‘객체’ 하나당 기본적으로 List, Form, Detail 3종 세트가 나온다고 생각하면 쉽습니다.

예를 들어보겠습니다.

‘게시물’이라는 객체가 있습니다.
- List : 여러 ‘게시물’을 모아 보여주는 화면 (예: 게시판 목록)
- Detail : ‘게시물’ 1개의 내용을 자세히 보여주는 화면 (예: 게시물 본문 읽기)
- Form : ‘게시물’을 생성하거나 수정하는 화면 (예: 글쓰기, 글 수정)

데이터 출처 정의

기획자가 개발자는 아니지만, ‘데이터가 어떻게 화면에 표시되어야 하는지’는 꼭 알아야 합니다.

화면(와이어프레임) 설계 시,“이 영역은 정적인가?”(Hard Coding),
“이 영역은 어떤 객체의 어떤 속성 값이 들어와야 하는가?”(Data Binding)를 명시해야 합니다.

데이터가 화면에 표시되는 방식은 크게 두 가지로 구분할 수 있습니다.

 

하드 코딩 (정적)

하드 코딩은 인쇄된 포스터나 벽에 붙은 안내문과 같습니다. 내용이 고정되어 있고, 누가 언제 접속하든 항상 똑같은 내용이 보입니다. 만약 내용을 바꾸려면, 개발자가 코드를 직접 수정해서 새로 배포(업데이트)해야 합니다.

• 예시: '회사 소개' 페이지, '이용 약관', '개인정보 처리방침' 등

데이터 바인딩 (동적)

데이터 바인딩은 내용물이 수시로 바뀌는 '틀'이라고 생각하면 쉽습니다. 마치 구글 폼과 같습니다.

화면은 '틀'만 가지고 있고, 데이터는 DB에서 실시간으로 가져와 빈칸을 채웁니다(결합 = Binding). 보는 사람, 시간, 상황에 따라 다른 내용이 보입니다.

• 마이페이지 : '내 이름', '내 포인트'가 보이는 공간(틀)은 같지만, 로그인한 사람에 따라 A 회원 정보가 보이거나 B 회원 정보가 보입니다.
• 상품 목록 : 어제는 A 상품이 보였지만, 오늘 품절되면(데이터 변경) 목록에서 사라지고 B 상품이 보입니다.
• 메인 배너 : 관리자 페이지에서 '오늘의 특가' 배너를 등록하면(데이터 추가), 모든 사용자에게 그 배너가 보입니다.

구분	하드코딩	데이터 바인딩
유연성	낮음	높음
코드형태	text="고정값"	text="user.name" 또는 {{user.name}}
값의 위치	소스 코드 내부	변수, DB, API 등 외부 소스
값 변경 방법	코드 수정 후 배포	데이터 소스(DB, 변수)만 변경

---

STEP 3

HOW : 움직이게 만들기

누가(Role), 무엇을(Concept), 어떻게(CRUD) 할 수 있는지 정의

화면설계가 끝났다면, 이제 그 화면이 ‘어떻게 동작해야 하는지’ 구체적인 규칙을 정할 차례입니다.

CRUD : 모든 데이터의 4가지 생명주기

CRUD는 STEP 1의 ‘컨셉스키마’ 중 객체를 다루는 4가지 기본 행동이며, STEP 2의 와이어프레임과 직접 연결됩니다. 아래 4가지에 따라 전반적인 와이어프레임이 구성됩니다.

• Create (생성) : 새로운 데이터를 만듭니다. (주로 Form 화면 사용)
• Read (읽기) : 데이터를 조회합니다. (주로 List, Detail 화면 사용)
• Update (수정) : 기존 데이터를 변경합니다. (주로 Form 화면 사용)
• Delete (삭제) : 기존 데이터를 삭제합니다. (주로 List나 Detail의 버튼 사용)
  
  

정책과 역할 기반 접근 제어

CRUD는 ‘기능’일 뿐, UX 기획의 핵심은 “누가 이 기능을 쓸 수 있는가?”를 정의하는 정책(Policy)입니다. 정의한 모든 기능(CRUD)에 대해, 어떤 Role이 어떤 조건에서 수행할 수 있는지 정책을 빠짐없이 상세 기획을 정의합니다. 예를 들면 다음과 같습니다.

 

정책 (Policy)

서비스의 모든 ‘예외 사항’과 ‘조건’을 정의합니다. 예를 들면, ‘본인만 본인의 글을 수정(Update)하고 삭제(Delete)할 수 있다', ‘로그인한 회원만 글을 생성(Create)할 수 있다', ‘관리자는 모든 글을 수정(Update)하고 삭제(Delete)할 수 있다’ 등이 이에 해당합니다.

 

RBAC (Role-Based Access Control / 역할 기반 접근 제어) 

정책을 효율적으로 관리하기 위해 사용자를 ‘역할(Role)’로 묶는 방식입니다. 여기서 Role이란 게스트, 일반회원, 유료회원, 관리자 처럼 정책별 권한을 가지는 역할을 말합니다. 이런 역할 마다 권한을 부여하는 것이 RBAC입니다. 예시는 다음과 같습니다.

• 게스트 : Read만 가능
• 일반회원 : Create, Read, (본인 글) Update/Delete 가능
• 관리자 : 모든 CRUD 가능

이렇듯 각각의 역할이 어떤 권한을 가지는지까지 정의하는 것이 상세기획의 핵심입니다.

---

응용하기

배달 플랫폼으로 생각해보기

배표적인 배달플랫폼에서는 위에서 배운 항목들이 어떻게 응용되는지 알아보겠습니다.

• STEP 1 : 식당 데이터의 구성 (개념 스키마)
  • 식당명 : 가게 이름 (예: 김철수 족발집)
  • 위치 : 주소 및 좌표 정보
  • 오픈 / 마감 시간 : 영업 시간
  • 메뉴 : 메뉴명, 가격, 상세 설명, 메뉴사진
  • 리뷰 및 평점 : 사용자 피드백
• STEP 2 : List, Form, Detail 3종 세트
  • 사장님 플로우
    • List : 주문 목록 화면, 메뉴 관리 목록
    • Form : 신규 메뉴 등록 화면, 식당 정보 수정 화면
    • Detail : 개별 주문 상세 화면
  • 사용자 플로우
    • List : 식당 카테고리 목록
    • Form : 주문하기 최종 단계, 리뷰 작성/수정 화면
    • Detail : 식당 상세 페이지
  • 라이더 플로우
    • List : 가용 콜 목록, 운행 및 정산 내역 목록
    • Form : 배달 상태 변경 화면, 운행 시작/종료 설정 화면, 배달 완료 인증 화면
    • Detail : 배달 주문 상세 정보 화면, 프로필 및 평점 상세 화면
• STEP 3 : CRUD

  플로우	역할	주요 CRUD	주요 활동
  사장님 플로우	데이터 관리자	C, U, D	가게 정보를 플랫폼에 등록 및 운영
  사용자 플로우	데이터 소비자	C, R, D	앱을 통해 검색, 주문, 리뷰작성
  라이더 플로우	데이터 운영자/공급자	R, U	플랫폼을 통해 주문 배정, 실시간 배달 과정 운영, 위치 데이터 플랫폼에 제공

위에서 STEP 1~3 까지 제시된 플로우 이외에도 더 많은 이해관계자들에 대한 정의도 필요합니다.

예를 들면, 직원과 알바생 별 권한에 따른 화면과 주요 활동이 달라지게 될텐데요, 가게 상세 정보를 수정하는 권한을 직원에게도 부여할 것인지, 주문 수락 권한을 알바생에게도 부여할 것인지 등 이해관계자들의 모든 케이스를 정의하는 것이 필요합니다.

---

깜짝퀴즈

배달 예상시간은 어떻게 정의할까?

서비스의 신뢰도를 결정하는 핵심요소이기 때문에 배달 플랫폼에서 가장 고도화된 영역 중 하나입니다. 단순한 조리시간+이동시간이 아닌, 복합적인 실시간 데이터를 기반으로 예측하는 방식으로 정의됩니다.

 

조리 시간 : 식당에서 음식을 만드는 데 걸리는 시간

구분	데이터 소스	예상 시간 산출 기여
기본 조리 시간	메뉴별 표준 조리 시간 (사장님이 설정하거나 플랫폼의 빅데이터 기반 표준값 사용)	메뉴 조합에 따른 기본값
실시간 주방 부하	동적 데이터를 이용한 예측. 현재 식당의 주문 대기 수와 조리 난이도 반영.	주문이 많을수록 조리시간 증가
사장님 설정값	사장님이 직접 설정한 ‘오늘 예상 조리 시간’ (예 : 주문 폭주로 인한 10분 추가)	상황 반영의 즉시성

 

배달 시간 : 음식 포장 후, 라이더가 픽업하여 사용자에게 전달하는데 걸리는 시간

구분	데이터 소스	예상 시간 산출 기여
라이더 도착시간 (ETA)	현재 식당으로 오고있는 라이더의 위치, 속도, 경로를 기반으로 계산된 예상 도착 시간	픽업까지 걸리는 시간
이동 시간 (Travel Time)	최적의 교통 거리에 실시간 교통 상황 및 라이더 운행 데이터를 적용하여 계산	배달 거리가 멀 수록, 교통 체증이 높을 수록 시간 증가
묶음 배달 (Batching)	라이더가 여러 주문을 동시에 배달하는 경우, 경로와 순서를 재계산 하여 추가되는 경유 시간을 반영	묶음 배달이 많을수록 시간 증가

 

시스템 및 기타 요인 : 시스템의 안정성 및 돌발상황을 대비하여 추가되는 시간 (버퍼 타임)

구분	데이터 소스	예상 시간 산출 기여
날씨/교통상황	악천후나 퇴근 시간대 교통 체증 시, 안전 운행을 위해 자동으로 추가되는 시간	악천후, 피크 타임에 시간 추가
배차 상태	현재 해당 지역에 대기 중인 라이더 수(공급)와 주문 수(수요)를 비교하여, 라이더를 배정받는 데 걸리는 예상 시간.	라이더가 부족 시 배차 대기 시간 증가

 

결국, 최종 배달 예상 시간을 이렇게 산출됩니다.

최종 배달 예상 시간 =  조리 시간 + 배달 시간 + 상황 시스템 및 기타요인

이처럼 배달 예상 시간은 다수의 시스템이 실시간으로 통신하는 예측 모델의 결과물 입니다.

---

실무기획

기획자는 어떤 의사결정을 해야할까?

기획자는 단순히 시간을 예측하는 알고리즘을 만드는 것이 아니라, 그 알고리즘이 사용자에게 어떻게 보이고, 서비스의 목표 달성에 어떻게 기여할지 정의합니다.

 

목표 정의 : 신뢰성 vs 속도

기획자는 신뢰성 또는 속도 중에서 현 서비스가 더 강조해야할 가치를 우선적으로 선택하여 최종 배달 예상 시간에서 어떤 버퍼타임을 얼마나 넣을지 결정해야합니다.

• 신뢰성 : 예상 시간을 조금 넉넉하게 잡아, 실제 배달 시간이 예측 시간보다 늦어지는 경우(지연)를 최소화하여 고객 만족도와 신뢰를 높이는 것에 중점을 둡니다. (예: 30분~40분 제시)
• 속도 : 지연 위험이 있더라도 경쟁 서비스 대비 빠른 시간을 제시하여 사용자의 즉각적인 주문을 유도하는 것에 중점을 둡니다. (예: 25분~35분 제시)

데이터 기반 요소 정의

예상 시간 산출에 필요한 데이터 소스를 정의하고, 시스템 내에서 어떻게 CRUD 될지 설계해야 합니다.

데이터 요소	기획자 결정 사항
조리 시간	사장님 앱에 Form을 제공하여 메뉴별 기본 조리 시간을 Update하도록 할지, 아니면 과거 주문 기록을 Read하여 플랫폼이 평균값을 자동으로 산출할지 결정합니다.
주방 부하	현재 List에 있는 대기 주문이 몇 개 이상일 때 조리 시간을 자동으로 N분 추가(Update)할지 그 기준을 설정합니다.
이동 시간	지도 API의 단순 경로 시간이 아닌, 실제 라이더의 과거 운행 기록을 Read하여 실제 평균 이동 속도를 반영할지 결정합니다.
배차 시간	실시간 라이더 공급/수요(Read)를 기반으로 배차 대기 시간이 몇 분 이상일 때 고객에게 '배달 지연 가능성' 메시지를 Form으로 보여줄지 결정합니다.

예측 로직 설계

개발자와 협력하여 예상 시간을 어떻게 계산할지 알고리즘을 정의해야 합니다.

• 단일 시간 vs. 범위 시간
• 업데이트 주기: 예상 시간을 몇 분 간격으로 Update하여 사용자 앱에 반영할지 결정
  
  

예외 플로우 정의

예상 시간 로직은 정상 플로우(음식이 정시에 준비되고 라이더가 바로 배차되는 경우)보다 예외 플로우가 훨씬 더 빈도가 높기 때문에, 예외를 빠짐없이 정의해야 합니다.

• 라이더 배차 지연 시 : 라이더가 10분 이상 배차되지 않을 경우, 예상 시간을 자동으로 N분 증가시키고 사용자에게 경고 알림을 전송
• 사장님 조리 지연 시 : 사장님이 '조리 완료' 버튼을 예상 시간보다 늦게 눌렀을 경우, 최종 예상 시간을 어떻게 Update할지
• 악천후 시 : 비/눈 예보가 있을 때, 버퍼 타임 자동으로 20% 증가

실시간 데이터의 연동 및 업데이트 주기

‘실시간’의 정의를 명확히 해야합니다.

• 데이터 연동 시스템: 배달 예상 시간 산출에 사용되는 데이터(교통 정보, 라이더 위치, 주방 부하 등)가 어느 시스템(GIS, 주문 관리 DB 등)에서 Read되어야 하는지 명시해야 합니다.
• 갱신 주기 (Update Frequency): ’주문이 들어온 직후 예상 시간은 1분 간격으로 갱신되어야 하며, 라이더가 배차된 후에는 30초 간격으로 갱신되어야 한다.’와 같이 구체적인 주기를 알려줘야 합니다. 이때 서버 부하도 고려해야하는데, 이건 다음에 알려드리겠습니다.
  
  

실패 및 롤백 정책

예측 시스템이 제대로 작동하지 않을 때의 대안을 정의해야합니다.

• 예측 실패 시의 기본값 : 예측 알고리즘이 오류를 내거나 데이터를 Read하지 못했을 때, 사용자에게 보여줄 '최소한의 안전한 시간(Default)'을 정의해야 합니다.
• 과거 데이터 활용 : 실시간 데이터가 끊겼을 때, 직전 N분 동안의 평균 데이터를 사용하여 예측을 Update하도록 할지 정책을 명시해야 합니다.
  
  

API 정의

예상 시간을 정의하는 로직이 사장님/라이더 앱의 어떤 CRUD 기능과 연결되어야하는지 정의해야합니다.

• 핵심 로직 : 사장님이 '주문 수락(U)' 버튼을 누르는 순간, API를 호출하여 실시간 주방 부하 데이터를 시스템 예상 시간 계산 로직에 전달(Create)해야 한다.
• 데이터 모델: 예상 시간 계산에 필요한 모든 변수의 형태와 단위를 사전에 정의해야 합니다. (예: 조리 시간은 정수 형태의 분 단위)

---

요약정리

UX 기획 실무 3원칙 연결하기

• STEP 1. 컨셉스키마
• STEP 2. List, Form, Detail
• STEP 3. CRUD & Policy