[IT 비즈니스 : 서비스 기획 & PM & UX] 프로덕트 기획 과정에서 작성해야 할 문서들.

안다미로 | App & Data_Scientist & Business·2025년 7월 5일

비즈니스/솔로 프리너 : IT 비즈니스

목록 보기

2/3

[IT 비즈니스 : 서비스 기획 & PM & UX] 프로덕트 기획 과정에서 작성해야 할 문서들.

▽ [IT 비즈니스 : 서비스 기획 & PM & UX] 프로덕트 기획 과정에서 작성해야 할 문서들.

목  차


1. 아이데이션 & 콘셉트 단계 문서

2. 서비스 전체 구조 설계 문서

3. 상세 화면 / 기능 정의 문서

4. 개발/디자인 전달용 문서

5. 정책 및 QA 문서

프로덕트를 개발하기 전 기획 단계에서 어떤 문서들을 작성하여, 프로덕트의 뼈대를 만들어야 할까?

프로덕트 기획 단계에서는 수없이 많은 문서들을 작성하게 됩니다.

프로덕트 매니저(PM) 혹은 개발자의 Roll을 수행하는 사람이거나, 1인 앱개발을 할 때
기획 단계에서 주로 작성하게 될 문서 종류와
각 문서의 목적, 담겨야 하는 주요 내용들을 정리해보겠습니다.

✅ 기획 단계에서 작성되는 문서들의 큰 흐름.

구분	문서 종류	주요 목적
① 아이데이션/콘셉트	서비스 제안서, 벤치마킹, 시장분석	아이디어를 설득, 프로젝트 승인 받기
② 구조 설계	IA, Flowchart	서비스 전체 틀을 잡기
③ 화면/기능 상세	와이어프레임, 스토리보드, 기능정의서	상세한 화면/기능 설계
④ 개발·디자인 전달	정책 정의서, 화면 정의서	개발자·디자이너 협업용
⑤ QA/검증	QA 시나리오, 버그 리포트	품질 검증, 배포 준비

단계	문서군
0 → 아이데이션	기획안, 벤치마킹, 리서치
1 → 전체 설계	IA, Flow Chart, User Process
2 → 화면/기능 상세	Wireframe, Storyboard, 기능 정의서
3 → 개발/디자인 전달	Policy, API Spec, Design System
4 → QA & 운영	QA 시나리오, Bug Report, Release Note

1. 아이데이션 & 콘셉트 단계 문서

문서명	정의	주요 목적	주요 내용
서비스 기획안 (Proposal)	서비스의 배경과 필요성, 콘셉트 제안 문서	프로젝트 승인, 설득	- Why/What/How - 시장/경쟁 분석 - 타깃 유저 - 기능 요약 - 수익모델(BM)
벤치마킹 리포트	유사 서비스 조사 및 비교 분석	차별화 포인트 도출	- 경쟁사 기능/UX 분석 - 스크린샷 - 개선 아이디어
시장/트렌드 리서치	시장 규모, 트렌드 분석	시장성, 리스크 판단	- 시장 데이터 - 성장 트렌드 - 위협 요소
Persona / 유저 시나리오	가상 사용자 모델과 스토리	사용자 공감대 확보	- Persona 속성 - 사용자 스토리
User Journey Map (여정 지도)	사용자의 행동·감정 흐름 시각화	Pain Point 도출	- 단계별 행동 - 감정 곡선 - 터치포인트

√서비스 기획안 (Service Proposal)

✅ 정의
- 서비스 기획안은 서비스의 전체 콘셉트와 추진 배경을 설명하고, 프로젝트 필요성을 설득하는 문서입니다.
✅ 왜 중요한가?
- 새로운 아이디어를 팀과 경영진에게 설득
- 예산/리소스 승인 받는 근거
- 프로젝트 방향성 확립.
✅ 목적
- 프로덕트 서비스 아이디어를 개념적으로 제시.
- 프로젝트 추진을 위한 초석
- 의사결정권자 설득용
✅ 주요 항목
- 서비스 개요 및 콘셉트 ( Why this Service? / What Service?)
- 시장 / 트렌드 현황 분석
- 경쟁 서비스 벤치마킹
- 문제 정의 & Solution
- 타깃 유저 정의
- 주요 기능 및 경쟁력(차별화 포인트)
- 수익모델(BM)
- 일정 및 리소스 예측
- 기대 효과
✅ 포인트
- " 왜 이 서비스를 해야 하는가? 에 집중하기.

√벤치마킹 & 경쟁사 분석

✅ 정의
- 유사 서비스와 경쟁사를 분석하여, 자사 서비스의 개선점과 차별화를 찾는 문서입니다.
✅ 왜 중요한가?
- 경쟁사의 강 & 약점 파악
- UX/UI 개선 아이디어 도출
- 설득력 있는 기획 근거 확보
✅ 목적
- 시장 이해, 차별화 포인트를 도출
✅ 주요 항목
- 유사 서비스 리스트업
- UI/UX 비교
- 각 서비스별 핵심 기능 비교
- 비즈니스 모델 비교
- 자사 서비스 개선 포인트.

✅ 포인트
- " 우리 서비스만이 할 수 있는 것 "을 명확히 추출하자.

√시장/트렌드 분석

✅ 정의
- 서비스가 진입할 시장 규모, 트렌드, 사용자 행태를 파악하는 리서치 문서입니다.
✅ 왜 중요한가?
- 시장성 및 리스크 파악
- 서비스 성공 가능성 타진
- 투자/사업 결정의 근거
✅ 목적
- 시장 크기, 성장성, 위험요소 파악
✅ 주요 항목
- 전체 시장 규모
- 성장률/ 트렌드
- 사용자 행동 데이터
- 신기술 동향
- 위협요인
포인트
- 신뢰도 높은 레퍼런스(보고서, 통계)를 인용하자.

√Persona / 유저 시나리오.

✅ 정의
- Persona란?
  - 가상의 대표 사용자 모델, 실제 데이터를 바탕으로 나이, 직업, 목표 ,행동 패턴 등을
    구체적으로 만든 사용자 프로필
- "유저 시나리오(User Scenario)" 란?
  - Persona가 서비스 내에서 어떤 목적을 이루기 위해 겪는 '구체적 스토리'를 서술한 시나리오

✅ 왜 중요한가?
- 사용자 관점으로 기획할 수 있도록 함.
- 기능, 정책, UI 설계의 기준이 됨.
- 개발자 & 디자이너 & 마케터 모두 '같은 유저'를 떠올리도록 해줌
- 실제 고객처럼 공감대를 형성해 '서비스 성공 확률'을 높임.
✅ 목적(Purpose)
- 사용자 입장에서 생각하게 함
- 팀 내 커뮤니케이션 도구
- Pain Point 파악 및 개선 아이디어 발굴
- 유저 여정 지도(User Journey Map) 작성의 기반
✅ 주요 항목 (Key Contents)
- ① Persona 속성
  - 이름(가상 이름)
  - 나이 / 성별
  - 직업
  - 생활 패턴(하루일과)
  - 디지털 이용 성향(주 사용 디바이스, 앱)
  - Needs/ Pain Point
  - 서비스 이용 목적
  - 구매/이용 결정 요인
- ② 유저 시나리오
  - 사용자 Context(언제, 어디서, 왜?)
  - 사용자의 목표
  - 서비스 이용 상황
  - 단계별 행동
  - Pain Point
  - 기대 결과
✅ 예시 (Example)
- Persona 예시.

항목	내용
이름	박지은 (가상)
나이	32세
직업	마케팅 매니저
특징	출퇴근 시간에 모바일로 정보 탐색, 빠른 UI 선호
Needs	퇴근 전 퀵하게 쇼핑 가능, 가격 비교가 쉽길 원함
Pain Point	웹사이트 로딩 느림, 회원가입 귀찮음

유저 시나리오 예시.

“박지은은 저녁 퇴근길 지하철에서 핸드폰으로 여름 원피스를 검색한다.
마음에 드는 제품을 발견했지만 회원가입이 필수라 포기한다.
소셜 로그인 기능만 있었다면 2분 안에 결제를 끝낼 수 있었을 것이다.”

√User Journey Map (여정 지도).

✅ 정의.
- 사용자가 서비스 이용 과정에서 겪는
  '행동 & 생각 & 감정의 흐름을 시간축으로 시각화' 한 다이어그램 혹은 표입니다.
✅ 왜 중요한가? ( Why important?)
- 고객 경험을 '단계별로 심층적으로 파악'할 수 있음
- Pain Point를 구체적으로 발견
- 개선 아이디어 발굴 가능
- 이해관계자 설득에 매우 효과적
✅ 목적(Purpose)
- 사용자의 실제 여정을 그대로 그려냄
- 어떤 단계에서 이탈하거나 불편을 느끼는지 파악
- "사용자 관점"으로 서비스 개선

✅ 주요 항목 (Key Contents)
- ① Persona
  - 여정 지도는 반드시 페르소나 기반으로 작성
  - 어떤 유저인지 명시
- ② 단계(Stage)
  - 서비스 이용 단계(인지 -> 탐색 -> 구매 -> 사용 -> 이탈)
- ③ 사용자 행동 (Action)
  - 해당 단계에서 유저가 실제로 하는 행동
- ④ 터치포인트 (Touch Point)
  - 유저가 서비스와 만나는 접점
    - ex) 앱 화면, 전화상담, 이메일, SNS DM 등등
- ⑤ 생각/느낌 (Thoughts / Feelings)
  - 유저가 느끼는 감정 (긍정/ 부정)
  - 걱정, 기대, 불편 등등
- ⑥ Pain Point
  - 단계별로 발견되는 문제점
- ⑦ 개선 아이디어
  - Pain Point를 해결할 수 있는 방안.

✅ 예시 (Example)

▷ User Journey Map 예시 (표 형태)

단계	행동	Touch Point	감정	Pain Point	개선 아이디어
탐색	“여름 원피스 검색”	모바일 웹	기대감 ↑	검색 느림	검색 속도 개선
상품 상세	상품 클릭	상세 페이지	흥미 ↑	로그인 유도 창 불편	소셜 로그인 추가
결제	결제 시도	결제 페이지	짜증 ↑	입력 항목 많음	간편 결제 도입

▷ 간단 스토리형 예시

“지은은 여름 원피스를 찾으려 검색한다.
마음에 드는 상품을 발견했지만 회원가입 창에 가로막혀 이탈한다.
이 순간 지은은 ‘왜 또 회원가입이야…’ 하며 불편함을 느낀다.”

2. 서비스 전체 구조 설계 문서

문서명	정의	주요 목적	주요 내용
IA (Information Architecture)	전체 메뉴/화면 구조 설계	전체 구조 한눈에 파악	- 메뉴 트리 - Depth 구분 - 각 메뉴 기능 요약
서비스 플로우 차트 (Flow Chart)	기능·화면 간 이동 흐름도	화면/기능 간 연결 이해	- 시작 조건 - 단계별 행동 - 분기 조건
유저 프로세스 (User Process)	유저의 목적 달성 단계별 흐름	UX 설계 기반	- 시작 조건 - 단계별 액션 - 예외 흐름

√IA ( Information Architecture, 정보 구조도 )

✅ 정의
- IA는 서비스 전체의 메뉴, 화면 구조를 계층적으로 정리한 설계 문서입니다.
✅ 왜 중요한가?
- 서비스 전체 구조를 한눈에 파악
- 메뉴 간 관계 명확화
- 개발/디자인 협업의 기준

✅ 목적
- 서비스 전반의 정보 구조와 메뉴 체계를 정리.
- 서비스 전략과 방향을 반영한 구조로 서비스 용어 및 운영 프로세스 구조를 정의합니다.
✅ 작성 팁.
- 너무 세분화하면 복잡해짐 -> 레벨 조절 중요
- 협업 툴(Figma, Miro 등)로 시각화하면 좋음
✅ 주요 내용
- 전체 메뉴 트리
- Depth별 페이지 정리.
- AS-IS의 문제점들을 정리
- 정보구조가 비체계적으로 구성된 서비스를 사용할 시 사용자는 혼란을 느낍니다.
  (논리적이고 체계적 구조를 가져야 하는 이유.)
- 개선 방향을 포함한 목적, 방향 설정
  - 서비스가 복잡할수록, 목적과 방향을 명확하게 설정하는 것이 필요합니다.
- 벤치마킹을 통해 타사의 정보구조 참고
  - 동종업계, 리더그룹이 어떤 정보구조를 가져가고 있는가를 파악하는 것이 중요.
- 서비스의 전략과 방향을 반영한 구조
- 서비스 용어 및 운영 프로세스 구조 정의
  - 큰 프로젝트는 다양한 팀이 모듈별로 업무를 담당하여 같은 기능을 다른 용어로 사용하기도 함.
  - 이것은 사용자를 혼란스럽게 할 수 있기 때문에, 서비스 용어 정리한 용어집 제공 등의 방식으로 용어 통일을 권장.
ex)

홈
  ├─ 마이페이지
  │     ├─ 주문내역
  │     ├─ 내 정보 수정
  └─ 상품 카테고리
         ├─ 의류
         └─ 잡화

✅ 카카오 홈페이지 예시.

그룹핑을 하기 때문에 one-depth가 기준입니다.
two-depth까지 가는 동안은 화면 아이디를 내리지 않습니다.
depth 사이에 여백을 두어 위치 변경 시에 대비합니다.
다크모드, 언어 변경, 관련 사이트 연동 등은 IA가 아니니 주의.

√플로우 차트 ( Flow Chart )

✅ 정의
- 플로우차트는 사용자 혹은 시스템의 흐름을 순서도 형태로 시각화한 문서입니다.
✅ 왜 중요한가?
- 서비스 흐름을 직관적으로 이해
- 조건별 분기, 예외처리 확인
- 개발/디자인 동선 설계의 기준.

✅ 목적
- 기능이나 서비스 흐름을 시각화(사용자 여정과 시스템 흐름을 시각화)
- 전체적인 서비스의 흐름에 대한 이해 후 이에 맞게 작성합니다.
- User Process를 도식화해서 보여주는 것입니다.
✅ 주요 내용
- 시작 조건.
- 단계별 사용자 행동.
- 조건 분기 ( Yes/ No )
- 각 단계의 화면 혹은 기능
- 예외 흐름
✅ 작성 팁
- 한눈에 이해 가능한 심플함이 핵심
- 페이지 번호(ID)와 연계.
ex)

로그인 → (성공?) → 메인 화면
            ↓
        로그인 실패 → 에러 팝업

기능 흐름(Logic Flow)예시.

프로세스별로 나눈 Flow Chcart 예시

√ 유저 프로세스 (User Process)

✅ 정의
- 유저 프로세스는 사용자가 서비스 내에서 특정 목적을 달성하기까지 거치는
  모든 단계의 상세 흐름을 정리한 문서입니다.
✅ 왜 중요한가?
- 사용자 시점에서 UX 설계.
- 퍼널 분석 및 개선 기준 제공.
- 개발/디자인/QA 협업의 기준.
✅ 주요 작성 내용
- 프로세스 명
- 시작 조건
- 단계별 행동, 화면 이동
- 각 단계 입력/출력 값
- 예외 사항
- 완료 조건

서비스를 이용하는 사용자의 프로세스
- ex) 사이트에 회원가입을 수행하는 경우
  - 회원가입 클릭 -> 본인 인증, 개인정보 작성 -> 가입 완료.
IA를 기준으로, 행동하는 사용자의 흐름
데이터의 이동 흐름과 저장/호출 프로세스
사용자의 특정 작업을 위한 경로
사용자 시나리오 보다 구체적으로 정의
UI(화면), 행동, 판단으로 표현
- 유저 플로우 구조.
- 유저 플로우 예시.

User Process를 정의할 때 장점.

페이지의 주요 프로세스들을 이해 가능
인터페이스의 효율적인 설계
개선이 필요한 영역 정의
전체적인 흐름 이해 가능 -> 개선이 요구되는 부분에 대한 보완 가능
서비스의 주요 흐름을 빠르게 파악 가능
- 상대적으로 긴 스토리보드/와이어프레임을 확인하지 않더라도 서비스의 주요 흐름 파악 가능
각 파트와의 커뮤니테이션 용이
Flow Chart 또는 User Task로 도식화시키기도 합니다.
- User Flow Chart 예시.
- User Task 예시.

3. 상세 화면 / 기능 정의 문서

문서명	정의	주요 목적	주요 내용
와이어프레임 (Wireframe)	화면 뼈대 설계	레이아웃 설계	- 화면 구획 - 컴포넌트 배치
스토리보드 (Storyboard)	화면 단위 상세 설계	화면/기능 정의	- 화면 캡처/스케치 - 기능 설명 - 이동 규칙
기능 정의서	단위 기능 상세 명세	개발/QA 기준	- 기능 설명 - Input/Output - 예외 처리
화면 정의서 (Screen Spec)	각 화면의 UI/동작/데이터 정의	개발/디자인 명세	- 화면 ID - 컴포넌트 설명 - API 연동 규칙

와이어 프레임(Wireframe)

✅ 정의(Definition)
- 와이어프레임은 '서비스의 각 화면을 저해상도(low fidelity)로 스케치한 설계도' 입니다.
- UI 디자인의 전 단계로, 색상 및 디자인 요소는 생략하고 레이아웃과 기능 배치에만 집중합니다.
- 보통 흑백으로 선 & 박스 & 간단한 텍스트만 활용하며,
  개발 및 디자인팀과 커뮤니케이션을 원활히 하기 위한 '의사소통 수단'입니다.

✅ 왜 중요한가? ( Why important?)
- 개발 및 디자인 전에 빠르게 아이디어를 시각화 가능
- 실제 디자인보다 제작 비용과 시간이 훨씬 적데 듦.
- 기능 배치나 화면 흐름 문제를 초기에 발견 가능
- 팀원 간 서비스 UI의 공통 이해도를 높여서 커뮤니케이션 비용 감소시킴
- 이해관계자(PO, 클라이언트 등)에게 빠른 피드백 가능

✅ 목적 (Purpose)
- 서비스 기획자가 전체 레이아웃의 논리적 구조를 설계.
- 기획의 방향성이 디자인, 개발로 넘어가기 전 팀 간 정합성 맞추기
- 각 화면의 중요도나 정보 우선순위를 명확히 합니다.
- UI/UX 설계의 뼈대 자료로 사용.

✅ 주요 항목 (Key Contents)
- 페이지명/ 화면 ID
- 레이아웃 구성
  - 주요 영역 구획
  - UI 컴포넌트 배치
- 버튼 및 입력 필드 위치
- 텍스트 영역
- 간단한 흐름 설명(이동 방향 등)
- 인터렉션 설명
✅ 예시 (Example)

예) “로그인 화면 와이어프레임”

좌측 상단: 로고
중앙:
- 이메일 입력 필드
- 비밀번호 입력 필드
- 로그인 버튼
하단:
- “비밀번호 찾기” 링크
- “회원가입” 버튼

→ 이때 스타일링 없음, 단순 선과 박스로 구획만 나눔

스토리보드 (Storyboard)

✅ 정의(Definition)
- 스토리보드는 화면 설계의 시각적 설명서로, 각 화면에 어떤 기능이 배치되며,
  어떤 규칙과 흐름으로 작동하는지를 상세히 기록합니다.
- 와이어프레임보다 상세하며, 디자인 시안보다 추상적인 단계.
- 단순 배치도가 아니라, 실제 사용 시나리오를 반영한 동작/이동/상태 변화를 설명.

✅ 왜 중요한가? ( Why important?)
- 개발자, 디자이너, QA, PO 모두가 '같은 이해도'를 공유 가능.
- 사용자 입장에서 UX를 설계해 '불필요한 동선이나 비효율을 사전에 방지' 가능 !
- 개발 & 디자인 단계에서 해석의 차이가 발생하지 않도록 함.
- 추후 정책 문서나 QA 시나리오 작성 시 '기준 문서'가 됨.

✅ 목적 (Purpose)
- 각 화면별로 기능과 역할을 명확히 규정.!
- 사용자 플로우와 예외 상황을 모두 설명해, '시나리오 기반 개발'을 가능하게 합니다.
- 개발 & 디자인 전달 시, '구체적 명세서' 역할을 합니다.

✅ 주요 항목 (Key Contents)
- 화면 이름
- 화면 ID
- 와이어프레임 이미지 혹은 디자인 캡처
- 컴포넌트 설명
- 기능 설명
- 이동 흐름(다음 화면, 뒤로 가기 등)
- 동작 조건
- 예외 처리
- 메시지 규칙( ex : 오류 메시지 )

✅ 예시 (Example)

예) “상품 상세 화면 스토리보드”

화면명: 상품 상세
화면 ID: PD-002
와이어프레임 이미지 포함
컴포넌트
- 상품 이미지 영역
- 상품명
- 가격
- ‘장바구니 담기’ 버튼
- ‘구매하기’ 버튼
기능 설명
- ‘장바구니 담기’ 클릭 시 장바구니 페이지 이동
- 재고가 0일 경우 ‘구매하기’ 버튼 비활성화
예외 처리
- 네트워크 오류 시 에러 메시지 “네트워크 오류가 발생했습니다.”

기능 정의서 (Functional Specification)

✅ 정의(Definition)
- 기능 정의서는 '각 개별 기능이 어떻게 동작해야 하는지 상세히 정의'한 문서.
- 개발자에게는 개발 기준서, QA에게는 검수-체크리스트가 됩니다.
- 기능 단위로 작성하며, UI가 아닌 '비즈니스 로직 중심'으로 기술합니다.

✅ 왜 중요한가? ( Why important?)
- 개발자에게 "어떻게 구현해야 하는지"를 명확히 전달합니다.
- QA팀의 '테스트 케이스 작성 기준'이 됩니다.
- 서비스가 복잡해질수록, 팀 간 오해 없이 동작 규칙을 통일 가능합니다.
- 정책 변경 시, 영향도를 쉽게 파악 가능합니다.

✅ 목적 (Purpose)
- 기능별 개발 기준 정의
- 서비스 품질 표준화
- 장애 대응 시 참고 문서
- 유지보수 시 명확한 기준 제공

✅ 주요 항목 (Key Contents)
- 기능 명칭
- 목적/설명
- Trigger(어떤 상황에서 작동하는지)
- Input 값
- Output 값
- 동작 규칙( Business Logic)
- 예외 처리
- 상태 변화(ON/OFF 등)
- Error 코드 정의

✅ 예시 (Example)

예) “검색 기능 정의서”

기능 명칭: 통합 검색
목적: 사이트 내 상품/카테고리 검색
Trigger: 사용자가 검색창에 키워드 입력 후 Enter
Input: 검색어 (최대 50자)
Output:
- 검색결과 리스트
- 결과 수 표시
동작 규칙:
- 검색어 1자 미만이면 검색 불가
- 특수문자는 제거 후 검색
예외 처리:
- 검색결과가 없을 시 “검색결과가 없습니다.” 출력

화면 정의서 (Screen Specification)

✅ 정의(Definition)
- 화면 정의서는 각 화면의 UI 구성, 컴포넌트의 상세 속성, 데이터 연동 규칙 등을
  '구체적으로 명시'한 문서입니다.
- 스토리보드가 "스토리 중심"이라면, 화면 정의서는 '화면 단위로 '규격서'처럼 작성'됩니다.
- UI 설계와 개발 간 '디테일 미스매치 방지'가 목적입니다.

✅ 왜 중요한가? ( Why important?)
- 디자이너에게는 UI 스타일 가이드의 기준.
- 개발자에게는 컴포넌트의 동작, 데이터 요구사항의 기준이 됩니다.
- QA에게는 화면별 체크 리스트.
- API 명세와 연결해, 작업 순서를 효율적으로 관리할 수 있습니다.

✅ 목적 (Purpose)
- 각 화면의 컴포넌트 속성과 동작 규칙을 명확히 규정.
- 개발/디자인 공수 산정에 활용
- UI/UX 일관성 유지
- 유지보수 시 신속한 이해 자료 제공.

✅ 주요 항목 (Key Contents)
- 화면 ID / 화면 명
- 화면 설명
- 컴포넌트 명칭
- 각 컴포넌트 속성
  - Label
  - Default value
  - Editable 여부
  - Validation 규칙
  - Placeholder
- 동작 규칙
- API 연동 규칙
- 상태 변화(Visible/ Invisible/ Disabled 등)
- 메시지 규칙
- 예외 처리

✅ 예시 (Example)

예) “회원가입 화면 정의서”

화면 ID: UI-REG-001
화면명: 회원가입
컴포넌트:
- 이름 입력 필드
  - Placeholder: “이름을 입력하세요”
  - Validation: 최대 20자
  - 필수 입력
- 이메일 입력 필드
  - Placeholder: “이메일 입력”
  - Validation: 이메일 형식 체크
- 비밀번호 입력 필드
  - Validation: 영문+숫자 8자 이상
  - 비밀번호 표시 여부 토글 버튼
- 가입하기 버튼
  - 활성화 조건: 모든 필수 입력값이 유효할 때
동작 규칙:
- 가입하기 버튼 클릭 시 API 호출
- 가입 성공 → 로그인 화면 이동
- 가입 실패 → 오류 메시지 출력

문서 간 관계 정리.

와이어프레임 → 스토리보드 → 화면 정의서
                      ↘
                 기능 정의서

와이어프레임 -> UI 레이아웃 뼈대
스토리보드 -> 뼈대 위에 기능, 동선 설명
화면 정의서 -> 실제 개발을 위한 '화면 규격서'
기능 정의서 -> UI가 아닌 '로직 중심' 규격서.

4. 개발/디자인 전달용 문서

문서명	정의	주요 목적	주요 내용
정책 정의서 (Policy Spec)	공통 규칙과 정책 정리	일관된 서비스 운영	- 가입 정책 - 인증/보안 - 오류 코드 정의
API 정의서	프론트-백엔드 연동 규격 문서	개발 협업	- API Endpoint - Request/Response 스펙
Design System	UI 컴포넌트 규칙 집합	UI 일관성 유지	- 컬러 시스템 - 타이포그래피 - 컴포넌트 가이드

✅ 정책 정의서 (Policy Specification)

✅ 정의(Definition)
- '정책 정의서'는 서비스 내에서 발생할 수 있는
  { '비즈니스 규칙' & '운영 규정' & '예외 처리' & '정책 로직' } 등을 정리한 문서입니다.
- " 서비스가 어떤 상황에서 어떻게 동작해야 하는지 "를 결정하는 "룰북(Rule Book)" 같은 역할!
- 기능 정의서보다 상위 개념으로, 서비스 전체의 일관성과 운영 원칙을 규정합니다.

✅ 왜 중요한가? ( Why important?)
- 개발팀과 QA팀에게 '명확한 기준'을 제시합니다.
- 서비스 정책이 수시로 바뀌더라도 변경된 룰을 '한 곳에서 관리' 가능합니다.
- 기획자 개인의 머릿속에만 있던' 운영 규칙'을 문서로 공유하여, '팀 내 공통 인식'을 형성!
- 법적, 서비스적 리스크를 예방합니다.
- 이슈 발생 시, "어떤 규칙 때문에 이 동작이 일어났는가?"를 추적 가능합니다.

✅ 목적 (Purpose)
- 서비스 정책과 예외 상황을 '문서로 표준화'!
- 운영 효율성을 높이고, 커뮤니케이션 비용을 절감.
- QA, CS 대응 기준 수립
- 기획 & 개발 & 운영 간 '업무 단절 방지'

✅ 주요 항목 (Key Contents)
- 정책 명칭
- 정책 설명
- 대상 기능
- 적용 조건
- 처리 방식
- 예외 조건
- 법적 혹은 약관 관련 여부
- 상태 변화(On/Off , Visible/Hidden 등)
- 메시지 규칙
- 정책 Version 정보

✅ 예시 (Example)

정책 명칭: 회원 탈퇴 시 데이터 유지 정책
설명: 사용자가 회원 탈퇴 시 개인정보 삭제 여부 및 보관 기간 정의
적용 조건: 탈퇴 요청 시
처리 방식:

개인정보: 즉시 파기

구매 기록: 전자상거래법에 따라 5년 보관

CS 이력: 3년 보관
예외 조건:

법적 분쟁 중인 경우 삭제 불가
메시지 규칙:

탈퇴 화면에 “구매 기록은 전자상거래법에 따라 5년간 보관됩니다.” 안내 노출
Version: v1.2

API 정의서 (API Specification)

✅ 정의(Definition)
- 'API 정의서'는
  {프론트엔드 & 백엔드 & 외부 시스템 간 데이터 교환 규격}을 정의하는 문서입니다.
- 어떤 엔드포인트를 호출할 수 있고, 어떤 데이터를 주고받아야 하는지 "정확히 명시"
- 개발자에게는 '가장 필수적인 문서'이며, API 기반 아키텍처(MSA, SPA 등)에서 중요.

✅ 왜 중요한가? ( Why important?)
- 개발팀 간 역할 분리를 가능하게 해 '동시 개발 작업' 가능.
- 시스템 간 통신 문제를 줄여서 개발 효율을 극대화합니다.
- QA팀의 테스트 기준
- 문서화된 API가 있어야, 유지보수 시 새 개발자도 빠르게 투입 및 적응 가능.
- 오류 시 "어느 포인트가 잘못된 것일까"를 빠르게 추적 가능.

✅ 목적 (Purpose)
- API 규격 표준화.
- 프론트-백 간 개발 스케쥴 관리.
- 데이터 처리 로직의 일관성 확보.
- 오류 처리 표준 수립

✅ 주요 항목 (Key Contents)
- API 이름
- 설명
- Method(GET, POST, PUT, DELETE 등)
- Endpoint URL
- Request 파라미터
  - 파라미터명
  - 타입(string, int, etc...)
  - 필수 여부
  - 예시 값
- Response 스키마
  - 필드명
  - 타입
  - 설명
  - 예시 값
- Error Code
  - 에러 코드
  - 의미
  - 조치 사항

✅ 예시 (Example)

API 명: 회원 로그인 API
Method: POST
URL: /api/v1/login
Request:
{
"email": "user@test.com",
"password": "pass1234"
}
Response (성공):
{
"code": "200",
"message": "로그인 성공",
"data": {
"userId": 123,
"token": "eyJhbGci..."
}
}
Error Codes:

401: 이메일 혹은 비밀번호 오류

500: 서버 오류

Design System

✅ 정의(Definition)
- Design System은
  {'UI/UX 구성요소와 규칙, 가이드라인, 재사용 가능한 컴포넌트 } 등을 체계적으로 모은 라이브러리.
- 단순 디자인 가이드가 아니라, {디자인-개발 간 협업을 위한 통합 언어} 입니다.
- 스케일이 큰 프로젝트일수록 필수적 !

✅ 왜 중요한가? ( Why important?)
- UI의 일광성을 유지 가능!
- 신규 페이지, 신규 서비스 확장 시 '비용과 시간 절감' 가능.
- 디자인 시스템이 없는 경우, 개발자-디자이너 간 충돌이 자주 발생합니다.
- UI 수정 시 전체 영향도를 빠르게 파악 가능합니다.
- 접근성(Accessibility), 반응형 설계 등 기업의 UX 품질 유지에 필수적입니다.

✅ 목적 (Purpose)
- 디자인 규칙과 컴포넌트를 표준화.
- UI/UX 품질 유지.
- 빠른 프로토타이핑 지원.
- 개발/디자인 협업 효율 극대화.
✅ 주요 항목 (Key Contents)
- Design Principle (디자인 철학)
- 색상 팔레트
- 타이포그래피.
- 버튼 스타일.
- 입력 폼 스타일.
- 컴포넌트 라이브러리
  - Button, Modal, Dropdown, Tab 등
- 상태 규칙
  - 활성/비활성
  - Hover, Active, Focus
- Grid 시스템
- 아이콘 가이드
- Animation 규칙
- 접근성(Accesbility)가이드.

✅ 예시 (Example)

Button 컴포넌트 규격

Primary Button

배경색: #0066FF

폰트: 14px / Bold

Border Radius: 4px

Hover: #0055DD

Disabled: #CCCCCC

Secondary Button

배경색: #FFFFFF

테두리 색상: #0066FF

글자색: #0066FF

타이포그래피

H1: 24px / Bold / #333

Body: 16px / Regular / #666

Color Palette

Primary: #0066FF

Secondary: #FF6600

Text Default: #333333

✅ 세 문서의 관계.

문서	용도
정책 정의서	서비스의 규칙, 예외, 운영 원칙을 명시
API 정의서	시스템 간 데이터 교환 규격을 정의
Design System	UI/UX의 시각 규칙 및 컴포넌트 정의

정책 정의서 ->> "서비스 로직의 기준"
API 정의서 ->> "뎅터 통신의 기준"
Design System ->> "화면 구현의 기준"

5. 정책 및 QA 문서

문서명	정의	주요 목적	주요 내용
QA 시나리오 (Test Case)	테스트 케이스 정의	품질 검증	- 테스트 조건 - 예상 결과 - Pass/Fail
버그 리포트	발견된 문제 기록	빠른 이슈 공유	- 버그 설명 - 재현 방법 - 스크린샷
Release Note	배포 내용 정리	릴리즈 히스토리 공유	- 개선 사항 - 버그 수정 - 주요 변경점

QA 시나리오 (QA Scenario)

✅ 정의(Definition)
- QA 시나리오는 "테스트해야 할 기능과 그 수행 절차를 단계별로 명확히 정의한 문서"
- 개발된 서비스가 요구사항과 정책대로 정상 작동하는지를 검증하기 위해 작성합니다.
- 단순 기능 체크를 넘어서, 예외 상황, 경계값, 사용자 행동 패턴까지 포함합니다.
- QA팀만 작성하는 것이 아니라, "기획자와 개발자, QA가 함께 작성 및 검수" 하는 것이 이상적!

✅ 왜 중요한가? ( Why important?)
- 서비스의 '품질을 객관적으로 보증' 할 수 있습니다.
- 개발과 기획의 '해석 차이 및 디테일을 발견' 가능합니다.
- 테스트 누락을 방지해 QA 효율을 높입니다.
- 버그 리포트 시
  "어떤 절차에서 어떤 문제가 발생했는지"를 추적할 수 있는 "근거 자료"가 됩니다.
- 릴리즈 이후 사용자 클레임 발생 가능성을 크게 낮춥니다.

✅ 목적 (Purpose)
- 테스트 커버리지를 체계적으로 확보.
- 버그의 재현 절차 표준화.
- 팀 간 커뮤니케이션 기준 문서로 활용.
- QA 인력 교체 시에도 동일한 테스트 수행 가능.
✅ 주요 항목 (Key Contents)
- 기능명
- 테스트 목적
- 선행 조건(필요한 데이터 세팅 등)
- Test Case 번호
- 입력값/ 수행 절차
- 기대 결과
- 실제 결과 ( 테스트 진행 후 기록)
- Pass/Fail 여부
- 비고 / 코멘트
✅ 예시 (Example)

기능명: 로그인
목적: 올바른 계정으로 로그인 가능 여부 검증
선행 조건: 테스트 계정(user01 / password123) 존재
Test Case: TC-LOGIN-01
입력값/절차:

로그인 화면 접속

아이디 : user01 입력

비밀번호 : password123 입력

로그인 버튼 클릭

기대 결과 : 로그인 성공 메시지 노출 후 메인 페이지 이동

실제 결과 : 로그인 성공, 메인 페이지 이동됨

Pass/Fail : Pass

버그 리포트 (Bug Report)

✅ 정의(Definition)
- 버그 리포트는 "발생한 오류(버그)를 기록하고 공유하는 문서"
- 버그의 발생 조건, 재현 방법, 영향 범위 등을 정리해
  개발팀이 신속하게 수정할 수 있도록 돕습니다.
- 단순히 “이 기능 안 돼요”가 아니라, 누구나 똑같이 재현 가능하게 작성하는 것이 핵심
✅ 왜 중요한가? ( Why important?)
- 문제를 빠르게 공유하고 해결 가능.
- QA, 기획, 개발 간의 커뮤니케이션 효율을 높입니다.
- 서비스 장애로 이어질 수 있는 버그를 조기에 발견 가능합니다.
- 버그 발생 빈도와 심각도를 관리하여 '서비스 안정성'을 높입니다.
- 릴리즈 전 품질 보증을 위한 '근거 자료'가 됩니다.

✅ 목적 (Purpose)
- 버그의 '정확한 재현과 해결'을 돕습니다.
- 문제의 우선순위를 설정해, 리소스 배분을 효율화합니다.
- 프로젝트 이력 관리(어떤 문제가 몇 번 수정되었는지 기록)

✅ 주요 항목 (Key Contents)
- 버그 ID
- 작성자
- 작성일
- 발견 버전
- 기능명
- 발견 일시
- 발생 환경(OS, Browser, Device 등)
- 버그 내용 설명
- 재현 절차
- 기대 결과
- 실제 결과
- 심각도(Severity)
- 우선 순위(Priority)
- 첨부 스크린샷 or 영상
- 담당자
- 조치 내역
✅ 예시 (Example)

Bug ID: BUG-20240620-01
작성자: QA-김테스터
기능명: 상품 검색
발견 버전: v1.3.2
환경: Chrome 112 / Windows 10
내용: 검색창에 ‘@’ 입력 시 서버 오류 발생
재현 절차:
1. 메인 페이지 접속
2. 검색창에 @입력 후 Enter
- 기대 결과: 검색 결과가 없습니다 메시지 출력
- 실제 결과 : 500 Server Error 발생
- 심각도 : High
- 우선순위 : High
- 첨부 자료 : 에러 장면 스크린샷 첨부
- 조치 내역 : 백엔드 @ 특수문자 필터링 로직 추가 예정

Release Note (릴리즈 노트)

✅ 정의(Definition)
- Release Note는
  "서비스의 새로운 기능 추가, 수정, 버그 수정, 정책 변경 등을 기록한 공식 문서"
- 내부적으로는 개발팀, 기획팀, QA팀, 운영팀이 참고하고, 외부에는 고객 공지로도 활용됩니다.
- 사용자는 “이번 버전에 뭐가 달라졌는지”를 Release Note로 확인합니다.
✅ 왜 중요한가? ( Why important?)
- 유저(사용자)와의 '신뢰 구축 수단'
- 운영팀, CS팀 등 다른 부서에 업데이트 내용을 신속히 전달 가능.
- 추후 문제 발생 시 '버전별 변경 이력' 추적 가능.
- 릴리즈 이력을 관리함으로써 프로젝트의 '품질 관리 체계'를 구축 가능.

✅ 목적 (Purpose)
- 변경된 내용을 투명하게 기록 및 공유
- 사용자 혼선 방지
- 내부 팀 간 변경사항 공유
- 문제 발생 시 신속한 원인 붆석

✅ 주요 항목 (Key Contents)
- 릴리즈 버전
- 배포 일자
- 업데이트 유형
  - New Feature
  - Improvement
  - Bug Fix
  - Policy Change
- 상세 변경 내용
- 개발자/담당자
- 배포 서버/환경
- 영향 범위
- Known Issue
- 참고 링크
✅ 예시 (Example)

Version: v1.4.0
Release Date: 2025-06-24
New Feature:

마이페이지 → 회원등급제 도입

주문 내역 PDF 다운로드 기능 추가
Improvement:

로그인 속도 개선 (약 30% 빨라짐)
Bug Fix:

상품 리뷰 작성 시 특수문자 입력 불가 현상 수정

장바구니 삭제 시 UI 깜박임 현상 해결
Policy Change:

개인정보 보관 정책 변경 → 탈퇴 후 5년 보관 → 3년 보관으로 단축
Known Issue:

간헐적으로 리뷰 작성 후 페이지 새로고침 시 데이터 중복 노출
담당자: 김기획 / 이개발
배포 서버: Production

✅ 문서 간 관계

문서	용도
QA 시나리오	품질 검증 절차 수립
버그 리포트	문제 이력과 해결 관리
Release Note	최종 배포 결과 기록 및 공유

QA 시나리오 -> 테스트 실행 계획
버그 리포트 -> 문제 기록
Release Note -> 최종 배포 내용 공유.

안다미로 | App & Data_Scientist & Business

Roll with the punches

이전 포스트

[IT 비즈니스 : 서비스 기획 & PM & UX] UI & UX 기초 용어 모음집.

다음 포스트

[IT 비즈니스 : 서비스 기획 & PM & UX] 프로덕트 기획 과정에서 작성해야 할 문서들.

비즈니스/솔로 프리너 : IT 비즈니스

[IT 비즈니스 : 서비스 기획 & PM & UX] 프로덕트 기획 과정에서 작성해야 할 문서들.

▽ [IT 비즈니스 : 서비스 기획 & PM & UX] 프로덕트 기획 과정에서 작성해야 할 문서들.

✅ 기획 단계에서 작성되는 문서들의 큰 흐름.

1. 아이데이션 & 콘셉트 단계 문서

√서비스 기획안 (Service Proposal)

√벤치마킹 & 경쟁사 분석

√시장/트렌드 분석

√Persona / 유저 시나리오.

√User Journey Map (여정 지도).

2. 서비스 전체 구조 설계 문서

√IA ( Information Architecture, 정보 구조도 )

√플로우 차트 ( Flow Chart )

√ 유저 프로세스 (User Process)

User Process를 정의할 때 장점.

3. 상세 화면 / 기능 정의 문서

와이어 프레임(Wireframe)

스토리보드 (Storyboard)

기능 정의서 (Functional Specification)

화면 정의서 (Screen Specification)

문서 간 관계 정리.

4. 개발/디자인 전달용 문서

✅ 정책 정의서 (Policy Specification)

API 정의서 (API Specification)

Design System

✅ 세 문서의 관계.

5. 정책 및 QA 문서

QA 시나리오 (QA Scenario)

버그 리포트 (Bug Report)

Release Note (릴리즈 노트)

✅ 문서 간 관계

[IT 비즈니스 : 서비스 기획 & PM & UX] UI & UX 기초 용어 모음집.

[제로베이스_취업특강] 카카오 현직자 강의.

0개의 댓글