---
type: knowledge
domain: business
status: active
last-reviewed: 2026-07-17
tags:
  - ppt
  - presentation
  - template
  - dev
  - storyboard
---

# 개발 발표 장표 구조 (스토리보드)

> 한 줄 정의
> 개발·기술 발표의 **내용 뼈대** — "이 장에 뭘 넣나 / 어떤 다이어그램을 쓰나"까지 정한 슬라이드별 스토리보드. 비주얼 셸은 [[업무별 PPT 템플릿]]의 `.pptx`, 다이어그램은 [[10_지식/08_인프라/_설계_키트/템플릿/Mermaid/개발/00_개발_다이어그램_인덱스|개발 다이어그램 인덱스]]와 함께 쓴다.

## 왜 필요한가

pptx 템플릿은 **모양**을 주고, 이 문서는 **순서와 내용**을 준다. 개발 발표가 무너지는 지점은 디자인이 아니라 서사다 — 코드부터 보여주거나(맥락 없음), 다 만든 걸 나열하거나(핵심 없음), 결과 없이 과정만 말한다(그래서 뭐?). 아래 골격은 **청중이 이해하는 순서**로 짜여 있다: 문제 → 접근 → 구조 → 구현 → 증거 → 다음.

## 고르기 — 발표 성격별 골격

| 발표 | 골격 | pptx 짝 |
|---|---|---|
| 기술 발표 / 아키텍처 공유 | [[#A. 기술 발표]] | 제안서-02-기술구현-Tech-Cyan, 스터디-03-기술비교선정-Dark-Lab |
| 설계 리뷰 | [[#B. 설계 리뷰]] | 화면설계서-02-화면상세명세, 컨설팅-03-운영모델-Blueprint |
| PoC / 결과 보고 | [[#C. PoC·결과 보고]] | PoC-02-결과보고-Dashboard-Light, 최종보고서-01-경영진요약 |

---

## A. 기술 발표

10장 기준. `▸`는 그 장에 넣을 다이어그램·아이콘.

| # | 장표 | 핵심 1문장 | 시각 요소 |
|---|------|-----------|----------|
| 1 | **표지** | 무엇을·누가·언제 | 제목 + 한 줄 요약 |
| 2 | **문제** | 지금 무엇이 안 되나 / 왜 아픈가 | 현상 수치·스크린샷 |
| 3 | **목표** | 이 작업이 끝나면 무엇이 달라지나 | 완료 조건 3개 (측정 가능하게) |
| 4 | **접근** | 왜 이 방법인가 (검토한 대안 포함) | ▸ 비교표 — [[TECHNOLOGY-DECISION-GUIDE]] 축 |
| 5 | **전체 구조** | 시스템이 무엇으로 구성되나 | ▸ [[05_C4_컨텍스트_컨테이너\|C4 컨테이너]] |
| 6 | **핵심 흐름** | 가장 중요한 경로 하나의 동작 | ▸ [[01_시퀀스_API인증흐름\|시퀀스]] 또는 [[02_상태머신\|상태머신]] |
| 7 | **데이터 모델** | 무엇을 저장하나 | ▸ [[03_ERD_데이터모델\|ERD]] |
| 8 | **구현 하이라이트** | 어려웠던 결정 1~2개 (전부 아님) | 코드 스니펫 최소 · 결정 이유 |
| 9 | **검증** | 정말 되는가 (주장 아니라 증거) | ▸ 테스트·성능 수치, 데모 |
| 10 | **다음** | 남은 것 / 리스크 / 요청 | ▸ [[10_Gantt_WBS일정\|Gantt]] |

**넣지 말 것**: 안 어려웠던 코드 전체, 폴더 구조 나열, 쓴 라이브러리 목록. 청중은 "무엇을 왜"를 궁금해하지 "어떻게 다"를 궁금해하지 않는다.

---

## B. 설계 리뷰

승인을 받는 자리다. 청중이 **이해하고 결정**할 수 있게 짠다.

| # | 장표 | 핵심 | 시각 요소 |
|---|------|------|----------|
| 1 | 표지 + 리뷰 요청 범위 | 무엇의 승인을 구하나 | — |
| 2 | 요구사항·제약 | 무엇을 만족해야 하나 | 완료 조건·비기능 요구 |
| 3 | 제안 구조 | 이렇게 만들겠다 | ▸ [[05_C4_컨텍스트_컨테이너\|C4]] / [[04_플로우차트_분기로직\|플로우차트]] |
| 4 | 도메인·데이터 | 경계와 저장 | ▸ [[08_도메인_클래스모델\|도메인]] / [[03_ERD_데이터모델\|ERD]] |
| 5 | 핵심 흐름·상태 | 동작과 실패 처리 | ▸ [[02_상태머신\|상태머신]] / [[01_시퀀스_API인증흐름\|시퀀스]] |
| 6 | 검토한 대안 | 왜 이걸 골랐나 (버린 것도) | ▸ 비교표 |
| 7 | 리스크·미결 | 모르는 것을 숨기지 않는다 | 리스크·`미수행` 목록 |
| 8 | 결정 요청 | 무엇을 지금 정해야 하나 | 결정 항목 리스트 |

체크리스트로 [[설계-리뷰-체크리스트]]를 발표 전에 자가 실행한다. **이해 없는 승인은 고무도장** — 리뷰어가 결정할 수 있을 만큼만 보여준다.

---

## C. PoC·결과 보고

과정이 아니라 **결과와 판단**이 주인공이다.

| # | 장표 | 핵심 | 시각 요소 |
|---|------|------|----------|
| 1 | 표지 + 한 줄 결론 | 됐다 / 조건부 / 안 됐다 | 결론 먼저 |
| 2 | 가설·성공 기준 | 무엇을 검증하려 했나 | 사전에 정한 KPI |
| 3 | 무엇을 만들었나 | 범위 (한 것 / 안 한 것) | ▸ [[05_C4_컨텍스트_컨테이너\|C4]] 간략 |
| 4 | 결과 지표 | 기준 대비 실측 | ▸ 대시보드·차트 (데이터 디자인) |
| 5 | 데모 | 실제 동작 | 스크린샷·영상 |
| 6 | 배운 것 | 예상과 달랐던 점 | 인사이트 3개 |
| 7 | 판단·제안 | 확대할까 / 접을까 / 바꿀까 | 근거 있는 권고 |
| 8 | 다음 단계·비용 | 확대 시 필요한 것 | ▸ [[10_Gantt_WBS일정\|일정]]·리소스 |

**결론을 1장에 먼저** 놓는다. 보고받는 사람은 결론부터 알고 싶어 하고, 근거는 그 다음이다.

---

## 공통 규칙

- **한 장 한 메시지.** 제목이 곧 그 장의 결론이 되게 쓴다("아키텍처" ✗ → "3계층으로 테넌트를 격리한다" ✓).
- **다이어그램은 발표용으로 단순화.** 설계 문서의 전체 다이어그램을 그대로 붙이지 말고, 그 장의 메시지에 필요한 노드만 남긴다.
- **코드는 증거로만.** 어려웠던 결정을 보여줄 때만 최소 스니펫. 스크롤되는 코드 = 아무도 안 읽음.
- **정직하게.** 안 한 검증은 `미수행: {이유}`로, 리스크는 숨기지 않는다 ([[AI-DEVELOPMENT-RULES]] E절). 발표에서의 은폐는 잘못된 승인을 부른다.
- **색·아이콘 일관성.** 다이어그램 색은 [[10_지식/08_인프라/_설계_키트/표기_규칙|표기 규칙]], 아이콘은 [[10_지식/08_인프라/_설계_키트/아이콘_인덱스|아이콘 인덱스]]의 개발 세트.

## 제작 흐름

1. 위에서 발표 성격에 맞는 골격(A/B/C)을 고른다.
2. [[업무별 PPT 템플릿]]에서 짝이 되는 `.pptx`를 복제한다.
3. 각 장에 표시된 `▸` 다이어그램을 [[10_지식/08_인프라/_설계_키트/템플릿/Mermaid/개발/00_개발_다이어그램_인덱스|개발 다이어그램 인덱스]]에서 복사해 채운다.
4. HTML 발표가 필요하면 `up-ppt` 스킬로 자급자족 HTML을 생성한다.

## 관련 문서

- [[업무별 PPT 템플릿]] — 비주얼 셸(.pptx)
- [[10_지식/08_인프라/_설계_키트/템플릿/Mermaid/개발/00_개발_다이어그램_인덱스|개발 다이어그램 인덱스]] — ▸ 다이어그램 소스
- [[기술 문서와 보고]] · [[설계-리뷰-체크리스트]]