---
manual_id: M00-02
module_id: G00
title: 아이디어를 서비스 구조로 분해하는 법
slug: decompose-idea-into-service-structure
content_version: 0.1.0
status: self-reviewed
last_reviewed: 2026-07-18
estimated_minutes: 90
summary: 한 문장 아이디어를 사용자 여정·화면·API·데이터·규칙·오류·운영으로 분해해 개발 가능한 서비스 구조 지도를 만듭니다.
---

# 아이디어를 서비스 구조로 분해하는 법

> **한 줄 목표:** 한 문장 아이디어를 사용자 여정·화면·API·데이터·규칙·오류·운영으로 분해해 개발 가능한 서비스 구조 지도를 만듭니다.

## 1. 왜 지금 아이디어를 서비스 구조로 분해하는 법인가

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/01-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 배우는 이유 구조도"><figcaption>그림 1. 배우는 이유을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

아이디어를 화면 몇 장으로만 표현하면 뒤에서 필요한 API·데이터·권한·오류·운영 조건이 빠져 일정과 비용이 뒤늦게 흔들립니다.
| 지금 상태 | 문제 | 학습 뒤 변화 |
|---|---|---|
| 아이디어·도구 중심 | 화면만 그리고 backend를 생략함 | 서비스 분해표 |
| 느낌으로 완료 | 재현 evidence 없음 | 다른 사람이 확인 가능한 기준 |
| AI 결과 의존 | 사람 판단 경계 없음 | 원문·실행·승인 분리 |

## 2. 학습 전 확인과 완료 계약

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/02-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 학습 계약 구조도"><figcaption>그림 2. 학습 계약을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

| 항목 | 계약 |
|---|---|
| 대상 | IT 비전공 성인 학습자 |
| 선수지식 | M00-01 기발자는 무엇을 만드는 사람인가 |
| 예상시간 | 그림 학습 30분 + 실습 45분 + 복습 15분 |
| 산출물 | 서비스 분해표 |
| 완료 | 실습 영수증 + 셀프 테스트 + 자기 설명 |
> 실습에는 실제 개인정보·비밀번호·API key를 넣지 않습니다.

## 3. 전체 구조 한눈에 보기

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/03-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 전체 개념 지도 구조도"><figcaption>그림 3. 전체 개념 지도을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

그림의 화살표를 먼저 따라가고, 각 단계에서 어떤 evidence가 남는지 찾습니다.
| 핵심 요소 | 학습 질문 |
|---|---|
| 사용자 여정 | 핵심 사용자 여정은 무엇인가 |
| 접점·화면 | 어느 단계가 수동인가 |
| API·처리 | 어떤 시스템과 연결하는가 |
| 데이터·규칙 | 무엇을 저장하고 언제 지우는가 |
| 상태·오류 | 실패 때 어떤 대안이 있는가 |
| 운영·책임 | 핵심 사용자 여정은 무엇인가 |

## 4. 실생활 비유에서 정확한 구조로

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/04-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 실생활 비유 구조도"><figcaption>그림 4. 실생활 비유을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

서비스 분해는 여행 계획을 목적지 사진 한 장이 아니라 이동·예약·결제·예외·지원 절차로 나누는 일과 비슷합니다.
비유는 시작점일 뿐입니다. 정확한 구조는 역할·입력·처리·상태·실패·책임으로 다시 분리합니다.

## 5. 핵심 요소 여섯 가지

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/05-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 핵심 요소 구조도"><figcaption>그림 5. 핵심 요소을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

| # | 핵심 요소 | 확인 행동 |
|---|---|---|
| 1 | 사용자 여정 | 아이디어를 문제 문장으로 변환 |
| 2 | 접점·화면 | 5단계 사용자 여정 작성 |
| 3 | API·처리 | 화면·API·데이터 열 연결 |
| 4 | 데이터·규칙 | 권한·오류·운영 행 추가 |
| 5 | 상태·오류 | 누락 질문 세 개 기록 |
| 6 | 운영·책임 | 아이디어를 문제 문장으로 변환 |

## 6. 입력에서 산출물까지

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/06-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 입력과 출력 구조도"><figcaption>그림 6. 입력과 출력을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

| 구간 | 입력 | 처리 | 출력 |
|---|---|---|---|
| 시작 | 사용자·문제·현재 상태 | 아이디어를 문제로 다시 쓴다 | 서비스 한 줄 정의 |
| 중간 | 가정·범위·도구 | 각 행동의 화면·처리를 연결한다 | 구조 분해표 |
| 완료 | 검증 결과·한계 | 운영과 완료 기준을 확인한다 | 서비스 분해표 |

> **30초 확인:** 핵심 사용자 여정은 무엇인가? 답을 말한 뒤 다음 장으로 이동하세요.

## 7. 누가 무엇을 책임하는가

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/07-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 사람과 역할 구조도"><figcaption>그림 7. 사람과 역할을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

| 역할 | 책임 | 하면 안 되는 일 |
|---|---|---|
| 학습자 | 관찰·실행·기록 | 모르는 결과를 성공으로 표시 |
| 기발자 | 문제·범위·완료 기준 | 기술·법률 승인을 대신함 |
| 개발자·AI | 구현·설명·검사 보조 | 최종 결정 자동 확정 |
| Owner | 승인·위험·운영 책임 | evidence 없는 승인 |
| 사용자 | 실제 과업과 피드백 | 합성 persona로 대체 |

## 8. 헷갈리는 경계 분리하기

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/08-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 경계와 책임 구조도"><figcaption>그림 8. 경계와 책임을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

| 구분할 경계 | 왜 분리하나 |
|---|---|
| 사용자 행동과 시스템 처리 | 같아 보이지만 책임·검증·실패 영향이 다르기 때문 |
| 화면 상태와 database 상태 | 같아 보이지만 책임·검증·실패 영향이 다르기 때문 |
| 내부 기능과 외부 연계 | 같아 보이지만 책임·검증·실패 영향이 다르기 때문 |
| 자동화와 사람 승인 | 같아 보이지만 책임·검증·실패 영향이 다르기 때문 |
| 현재 범위와 다음 version | 같아 보이지만 책임·검증·실패 영향이 다르기 때문 |

## 9. 정상 workflow 다섯 단계

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/09-workflow.svg" alt="아이디어를 서비스 구조로 분해하는 법의 정상 workflow 구조도"><figcaption>그림 9. 정상 workflow을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

| 순서 | 행동 | 남길 evidence |
|---|---|---|
| 1 | 아이디어를 문제로 다시 쓴다 | 서비스 한 줄 정의 |
| 2 | 사용자 행동을 시간순으로 놓는다 | 사용자 여정 |
| 3 | 각 행동의 화면·처리를 연결한다 | 구조 분해표 |
| 4 | 데이터·권한·오류를 붙인다 | 오류·대안 |
| 5 | 운영과 완료 기준을 확인한다 | scope·TBR |

## 10. 기발자가 결정할 다섯 질문

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/10-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 판단 기준 구조도"><figcaption>그림 10. 판단 기준을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

| 질문 | 선택 evidence |
|---|---|
| 핵심 사용자 여정은 무엇인가 | 서비스 한 줄 정의 |
| 어느 단계가 수동인가 | 사용자 여정 |
| 어떤 시스템과 연결하는가 | 구조 분해표 |
| 무엇을 저장하고 언제 지우는가 | 오류·대안 |
| 실패 때 어떤 대안이 있는가 | scope·TBR |

## 11. 좋은 예: 작은 evidence가 이어지는 경우

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/11-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 좋은 예 구조도"><figcaption>그림 11. 좋은 예을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

좋은 예는 완벽한 문서가 아니라 질문·행동·결과·한계가 이어지는 작은 기록입니다.
| 행동 | 좋은 기록 |
|---|---|
| 아이디어를 문제 문장으로 변환 | 서비스 한 줄 정의 |
| 5단계 사용자 여정 작성 | 사용자 여정 |
| 화면·API·데이터 열 연결 | 구조 분해표 |
| 권한·오류·운영 행 추가 | 오류·대안 |
| 누락 질문 세 개 기록 | scope·TBR |

## 12. 나쁜 예: 그럴듯하지만 재현되지 않는 경우

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/12-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 나쁜 예 구조도"><figcaption>그림 12. 나쁜 예을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

| 나쁜 예 | 왜 위험한가 | 바꿀 행동 |
|---|---|---|
| 화면만 그리고 backend를 생략함 | 원인·범위·책임을 잃음 | 아이디어를 문제 문장으로 변환 |
| 모든 사용자를 한 흐름으로 가정함 | 원인·범위·책임을 잃음 | 5단계 사용자 여정 작성 |
| 정상 경로만 작성함 | 원인·범위·책임을 잃음 | 화면·API·데이터 열 연결 |
| 데이터 owner와 삭제 조건이 없음 | 원인·범위·책임을 잃음 | 권한·오류·운영 행 추가 |
| 외부 연계 실패를 고려하지 않음 | 원인·범위·책임을 잃음 | 누락 질문 세 개 기록 |

> **30초 확인:** 어느 단계가 수동인가? 답을 말한 뒤 다음 장으로 이동하세요.

## 13. 오류·오해·실패 위치 지도

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/13-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 실패 위치 지도 구조도"><figcaption>그림 13. 실패 위치 지도을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

| 실패 신호 | 먼저 확인 | 복구 |
|---|---|---|
| 화면만 그리고 backend를 생략함 | 사용자 행동과 시스템 처리 | 아이디어를 문제 문장으로 변환 |
| 모든 사용자를 한 흐름으로 가정함 | 화면 상태와 database 상태 | 5단계 사용자 여정 작성 |
| 정상 경로만 작성함 | 내부 기능과 외부 연계 | 화면·API·데이터 열 연결 |
| 데이터 owner와 삭제 조건이 없음 | 자동화와 사람 승인 | 권한·오류·운영 행 추가 |
| 외부 연계 실패를 고려하지 않음 | 현재 범위와 다음 version | 누락 질문 세 개 기록 |

## 14. 보안·개인정보·변경 안전

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/14-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 안전·개인정보 구조도"><figcaption>그림 14. 안전·개인정보을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

| 안전 질문 | 최소 통제 |
|---|---|
| 실제 정보인가 | 합성 값·redaction |
| 변경 command인가 | 목적·대상·backup |
| 권한이 필요한가 | 최소 권한·사람 승인 |
| 외부로 전송되는가 | destination·보존·비용 확인 |
| 실패 뒤 돌아갈 수 있는가 | diff·history·restore |

## 15. 도구와 기록에서 무엇을 볼 것인가

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/15-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 도구에서 찾기 구조도"><figcaption>그림 15. 도구에서 찾기을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

도구 화면에서는 큰 성공 문구보다 현재 위치·대상·version·output·exit 상태를 먼저 찾습니다.
```text
사용자 행동 → 화면
화면 → API 처리
API → data·rule
실패 → 대안·운영
```

## 16. 실습 1: 관찰하고 표시하기

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/16-1.svg" alt="아이디어를 서비스 구조로 분해하는 법의 실습 1 · 관찰 구조도"><figcaption>그림 16. 실습 1 · 관찰을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

| 실습 순서 | 행동 | 완료 표시 |
|---|---|---|
| 1 | 아이디어를 문제 문장으로 변환 | □ 관찰 · □ 기록 · □ 확인 |
| 2 | 5단계 사용자 여정 작성 | □ 관찰 · □ 기록 · □ 확인 |
| 3 | 화면·API·데이터 열 연결 | □ 관찰 · □ 기록 · □ 확인 |
| 4 | 권한·오류·운영 행 추가 | □ 관찰 · □ 기록 · □ 확인 |
| 5 | 누락 질문 세 개 기록 | □ 관찰 · □ 기록 · □ 확인 |

## 17. 실습 2: 내 사례 작성하기

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/17-2.svg" alt="아이디어를 서비스 구조로 분해하는 법의 실습 2 · 작성 구조도"><figcaption>그림 17. 실습 2 · 작성을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

`02_Labs/G00_Orientation/L00-02_service-decomposition-canvas.html`을 열고 02 수행 화면에서 내 사례를 작성합니다.
정답처럼 보이는 문장보다 선택 이유와 남은 질문을 적습니다.

## 18. Evidence package 만들기

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/18-evidence.svg" alt="아이디어를 서비스 구조로 분해하는 법의 Evidence 남기기 구조도"><figcaption>그림 18. Evidence 남기기을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

| Evidence | 필수 내용 | 검수 질문 |
|---|---|---|
| 서비스 한 줄 정의 | 아이디어를 문제 문장으로 변환 | 다른 사람이 같은 판단을 재현하는가 |
| 사용자 여정 | 5단계 사용자 여정 작성 | 다른 사람이 같은 판단을 재현하는가 |
| 구조 분해표 | 화면·API·데이터 열 연결 | 다른 사람이 같은 판단을 재현하는가 |
| 오류·대안 | 권한·오류·운영 행 추가 | 다른 사람이 같은 판단을 재현하는가 |
| scope·TBR | 누락 질문 세 개 기록 | 다른 사람이 같은 판단을 재현하는가 |

> **30초 확인:** 어떤 시스템과 연결하는가? 답을 말한 뒤 다음 장으로 이동하세요.

## 19. 개발자·외주사에게 확인할 질문

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/19-visual.svg" alt="아이디어를 서비스 구조로 분해하는 법의 개발자에게 물을 질문 구조도"><figcaption>그림 19. 개발자에게 물을 질문을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

| 확인 질문 | 좋은 답의 증거 |
|---|---|
| 이 화면 뒤에서 어떤 처리가 일어나는가 | 서비스 한 줄 정의 |
| 어떤 상태가 저장되는가 | 사용자 여정 |
| 누가 이 데이터에 접근하는가 | 구조 분해표 |
| 외부 API 실패 때 무엇을 보여 주는가 | 오류·대안 |
| 운영자가 확인할 evidence는 무엇인가 | scope·TBR |

## 20. AI에 안전하게 작업 요청하기

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/20-ai.svg" alt="아이디어를 서비스 구조로 분해하는 법의 AI에 작업 요청하기 구조도"><figcaption>그림 20. AI에 작업 요청하기을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

AI 요청은 다음 구조로 씁니다.
```text
목적: 서비스 분해표 초안을 만든다.
맥락: 한 문장 아이디어를 사용자 여정·화면·API·데이터·규칙·오류·운영으로 분해해 개발 가능한 서비스 구조 지도를 만듭니다.
입력: 아래 합성 사례와 확인된 사실만 사용한다.
완료 기준: 표의 모든 field, 정상·실패·한계, TBR를 포함한다.
금지: 실제 정보 추정, 확인하지 않은 성공 단정, 위험한 command 자동 실행.
출력 뒤: 누락·가정·검증 방법을 별도 목록으로 적는다.
```

## 21. AI 결과를 사람이 검수하기

<figure class="visual diagram"><img src="../../07_Assets/M00-02/diagrams/21-ai.svg" alt="아이디어를 서비스 구조로 분해하는 법의 AI 결과 검수 구조도"><figcaption>그림 21. AI 결과 검수을 하나의 핵심 메시지로 정리합니다.</figcaption></figure>

| 검수 | 질문 | 실패 시 |
|---|---|---|
| 원문 | 입력에 실제 존재하는가 | 삭제·수정 |
| 범위 | 이번 manual의 경계 안인가 | TBR로 이동 |
| 정상 | expected를 재현했는가 | 실행 evidence |
| 실패 | 거부·오류·복구가 있는가 | case 추가 |
| 승인 | 사람 owner가 이유를 남겼는가 | 확정 금지 |

## 22. 실습 화면에서 전체 지도 찾기

<figure class="visual screenshot"><img src="../../07_Assets/M00-02/lab/01-lab-learn-desktop.png" alt="서비스 분해 캔버스의 전체 구조 이해 화면"><figcaption>실습 화면 1. 핵심 요소와 경계를 desktop에서 찾습니다.</figcaption></figure>


## 23. 실습 화면에서 단계별 수행하기

<figure class="visual screenshot"><img src="../../07_Assets/M00-02/lab/02-lab-practice-desktop.png" alt="서비스 분해 캔버스의 단계별 수행 화면"><figcaption>실습 화면 2. 다섯 단계를 체크하고 내 사례 evidence를 작성합니다.</figcaption></figure>


## 24. 모바일에서 복습 영수증 읽기

<figure class="visual screenshot"><img src="../../07_Assets/M00-02/lab/03-lab-review-mobile.png" alt="서비스 분해 캔버스의 모바일 학습 영수증"><figcaption>실습 화면 3. 390×844에서 완료 단계·기록·다음 매뉴얼을 복습합니다.</figcaption></figure>


> **30초 확인:** 무엇을 저장하고 언제 지우는가? 답을 말한 뒤 다음 장으로 이동하세요.

## 25. 90분 실습 워크북

| 시간 | 행동 | 산출물 |
|---|---|---|
| 0~10분 | 전체 그림·경계 읽기 | 한 문장 설명 |
| 10~25분 | 핵심 요소·정상 흐름 | 표시된 concept map |
| 25~45분 | 실습 화면 01·02 | 5단계 수행 |
| 45~60분 | 실패·안전·질문 | 오류·TBR |
| 60~75분 | 템플릿 완성 | 서비스 분해표 |
| 75~90분 | 셀프 테스트·영수증 | 오답 복습 |

## 26. 서비스 분해표 템플릿

재사용 템플릿: `03_Templates/T00-02_service-decomposition-canvas.md`
빈칸을 한 번에 채우지 말고 관찰한 사실 → 선택 이유 → 미정 사항 순서로 작성합니다.

## 27. 기초 통합 용어집 300

통합 기초 용어집 `04_Glossary/GLOSSARY_foundation_orientation_environment.md`의 2~4, 14~15 묶음을 먼저 봅니다.
용어를 외우는 대신 내 실습 화면과 산출물에서 실제 예를 찾습니다.

## 28. 공식 자료와 적용 경계

> 아래 링크는 현재 원리와 도구 동작을 확인하는 1차 자료입니다. 링크 사용은 적합성·인증·운영 승인을 뜻하지 않습니다. 확인 기준일은 2026-07-17입니다.
| 공식 자료 | 확인할 원리 | 적용 경계 |
|---|---|---|
| [GOV.UK Discovery phase](https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works) | 사용자 맥락과 더 넓은 서비스 여정을 이해하는 원리 | 학습용 요약이며 실제 환경·사용자 검증 추가 |
| [GOV.UK User research in discovery](https://www.gov.uk/service-manual/user-research/user-research-in-discovery) | 사용자·채널·지원 단계를 end-to-end로 보는 방식 | 학습용 요약이며 실제 환경·사용자 검증 추가 |
| [GOV.UK Making prototypes](https://www.gov.uk/service-manual/design/making-prototypes) | 구현 전 여러 구조를 낮은 위험으로 시험하는 원리 | 학습용 요약이며 실제 환경·사용자 검증 추가 |
| [W3C WCAG 2.2](https://www.w3.org/TR/WCAG22/) | 화면과 사용자 흐름을 다양한 사용 방식으로 검토하는 기준 | 학습용 요약이며 실제 환경·사용자 검증 추가 |

## 29. 셀프 테스트 30


### 1. 이 매뉴얼의 최종 산출물은 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 서비스 분해표입니다.</p>
</details>

### 2. 이 주제를 배우는 가장 직접적인 이유는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 아이디어를 화면 몇 장으로만 표현하면 뒤에서 필요한 API·데이터·권한·오류·운영 조건이 빠져 일정과 비용이 뒤늦게 흔들립니다.</p>
</details>

### 3. 전체 지도에서 구분할 여섯 핵심 요소는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 사용자 여정 · 접점·화면 · API·처리 · 데이터·규칙 · 상태·오류 · 운영·책임입니다.</p>
</details>

### 4. 정상 workflow의 첫 행동은 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 아이디어를 문제로 다시 쓴다입니다.</p>
</details>

### 5. 정상 workflow의 마지막 행동은 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 운영과 완료 기준을 확인한다입니다.</p>
</details>

### 6. 가장 먼저 답할 의사결정 질문은 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 핵심 사용자 여정은 무엇인가입니다.</p>
</details>

### 7. 완료 전에 확인할 마지막 결정은 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 실패 때 어떤 대안이 있는가입니다.</p>
</details>

### 8. 대표적인 실패 한 가지는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 화면만 그리고 backend를 생략함입니다.</p>
</details>

### 9. 또 다른 실패 신호는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 모든 사용자를 한 흐름으로 가정함입니다.</p>
</details>

### 10. 왜 정상 경로만 기록하면 부족한가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 정상 경로만 작성함 같은 실패와 대안을 놓치기 때문입니다.</p>
</details>

### 11. 첫 번째 책임 경계는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 사용자 행동과 시스템 처리를 구분하는 것입니다.</p>
</details>

### 12. 학습용 결과와 실제 승인을 왜 분리하나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 학습 evidence가 실제 사용자·데이터·보안·운영 책임까지 자동으로 승인하지 않기 때문입니다.</p>
</details>

### 13. 실습의 첫 단계는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 아이디어를 문제 문장으로 변환입니다.</p>
</details>

### 14. 실습의 마지막 단계는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 누락 질문 세 개 기록입니다.</p>
</details>

### 15. 첫 번째 evidence는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 서비스 한 줄 정의입니다.</p>
</details>

### 16. 마지막 evidence는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> scope·TBR입니다.</p>
</details>

### 17. 개발자에게 가장 먼저 물을 질문은 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 이 화면 뒤에서 어떤 처리가 일어나는가입니다.</p>
</details>

### 18. AI 요청에 반드시 포함할 다섯 요소는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 목적·맥락·입력·완료 기준·금지/한계입니다.</p>
</details>

### 19. AI 결과를 바로 확정하면 안 되는 이유는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> AI는 누락·과잉 단정·잘못된 경로·위험한 command를 만들 수 있으므로 원문과 실행 evidence로 사람이 검수해야 합니다.</p>
</details>

### 20. 좋은 검수는 정상 결과만 보나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 아닙니다. 정상·실패·권한·경계·되돌리기를 함께 확인합니다.</p>
</details>

### 21. 실습 기록에 command나 행동 전 목적을 쓰는 이유는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 결과가 예상과 다를 때 무엇을 시험했는지 되짚고 위험한 행동을 줄이기 위해서입니다.</p>
</details>

### 22. 색상만으로 PASS·FAIL을 구분하면 안 되는 이유는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 인쇄·저대비·색각 차이에서도 상태를 알 수 있도록 문자·아이콘·선으로 함께 표시해야 하기 때문입니다.</p>
</details>

### 23. 실제 개인정보나 secret을 실습에 넣어도 되나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 아닙니다. 합성 값과 placeholder를 사용하고 secret은 환경변수 등 분리된 경로로 다룹니다.</p>
</details>

### 24. 한 번에 여러 원인을 바꾸면 왜 안 되나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 어떤 변경이 결과를 바꿨는지 알 수 없으므로 가설 하나씩 시험해야 합니다.</p>
</details>

### 25. 완료 기준은 느낌으로 적어도 되나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 아닙니다. 다른 사람이 관찰·실행·비교할 수 있는 evidence로 적어야 합니다.</p>
</details>

### 26. 실패는 항상 학습 실패인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 아닙니다. 예상한 실패를 안전하게 재현하고 원인·대안·복구를 설명하면 중요한 학습 evidence입니다.</p>
</details>

### 27. 공식 출처를 남기는 이유는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 변동 가능한 도구·단계·명령의 현재 의미를 다시 확인하고 교육 설명의 적용 경계를 밝히기 위해서입니다.</p>
</details>

### 28. 모바일 화면에서도 확인할 핵심은 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 제목·입력·행동·상태·완료 evidence가 가로 넘침 없이 같은 순서로 읽히는지 확인합니다.</p>
</details>

### 29. 이 매뉴얼을 완료했다는 가장 좋은 증거는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 서비스 분해표와 실습 영수증을 다른 사람이 보고 같은 판단을 재현하는 것입니다.</p>
</details>

### 30. 다음 매뉴얼로 넘어가기 전 한 문장으로 무엇을 설명해야 하나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 아이디어를 서비스 구조로 분해하는 법의 핵심 구조와 한계를 자기 사례로 설명해야 합니다.</p>
</details>

## 30. 한 장 요약과 다음 매뉴얼 M00-03

| 기억할 것 | 한 문장 |
|---|---|
| 목적 | 한 문장 아이디어를 사용자 여정·화면·API·데이터·규칙·오류·운영으로 분해해 개발 가능한 서비스 구조 지도를 만듭니다. |
| 핵심 | 아이디어를 문제로 다시 쓴다 → 사용자 행동을 시간순으로 놓는다 → 각 행동의 화면·처리를 연결한다 → 데이터·권한·오류를 붙인다 → 운영과 완료 기준을 확인한다 |
| 산출물 | 서비스 분해표 |
| 이전 | M00-01 기발자는 무엇을 만드는 사람인가 |
| 다음 | M00-03 · PoC·프로토타입·MVP·운영 서비스 구분 |
> **완료 확인:** 서비스 분해표와 실습 영수증을 보지 않고 핵심 흐름·실패·경계를 설명한 뒤 다음 매뉴얼로 이동합니다.

---

## 배포본 안내

- 매뉴얼 ID: `M00-02`
- 콘텐츠 버전: `v0.1.0`
- [인쇄용 PDF](../M00-02/M00-02_decompose-idea-into-service-structure_v0.1.0.pdf)
- 그림·실습·템플릿·용어집 링크는 이 프로젝트 폴더 구조를 기준으로 합니다.