Step 332. 세미나 발표 자료 제작 — 청중이 가져갈 것의 설계

Level 4 — 전문가 | 난이도 ★★★☆☆ | 예상 소요 시간 2일 (주제 선정 반나절 + 슬라이드 제작 1일 + 리허설 2회 반나절)

전제: Step 331의 멘토링 세션 자료(재료 창고), Step 329~330의 노트 습관. 내 주력 트랙에서 대표 기술 하나를 꺼낼 수 있어야 합니다.

준비물: 슬라이드 도구(파워포인트, 구글 슬라이드, 마크다운 슬라이드 도구 무엇이든), 초시계 또는 휴대폰 타이머(리허설 시간 측정용), 데모 녹화 도구(화면 녹화 프로그램). 이 챕터는 문서 제작 과제라 모든 산출물 예시는 화면 예시입니다.
주의: 발표 자료에 실제 제보·CVE 분석 내용을 담을 때는 공개 승인(embargo 해제) 여부를 반드시 확인합니다.
⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다. 발표 데모도 내 랩 환경에서만 진행합니다.

좋은 기술 발표는 "내가 아는 것의 나열"이 아니라 "청중이 가져갈 것의 설계"입니다. 같은 지식을 담아도, 청중의 머리에 남는 발표와 남지 않는 발표가 갈리는 것은 지식의 양이 아니라 구조 때문입니다.

오늘은 30분짜리 세미나 발표 자료를 처음부터 완성합니다. 기본 구조는 정해져 있습니다 — 문제 제기(왜 이 주제가 중요한가) → 배경(청중이 모를 것) → 핵심 내용(데모 포함) → 정리(가져갈 한 문장). 내 주력 분야의 대표 기술 하나를 주제로 정해, 이 구조 위에 15~20장의 슬라이드를 얹고, 리허설로 다듬는 것까지가 오늘의 과제입니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

"내가 잘하는 것 중 청중에게 유용한 것"의 기준으로 발표 주제를 선정한다
청중 수준(초보/중급)을 정의하고 그에 맞춰 깊이를 조절한다
30분 발표의 4단 구조(도입 3분 → 배경 5분 → 핵심+데모 17분 → 정리 5분)를 설계한다
"장당 메시지 하나" 원칙으로 15~20장의 슬라이드를 제작한다
리허설 2회(시간 측정 포함)로 초과 분량을 잘라내 발표를 완성한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분	내용
언어·환경	슬라이드 도구(무엇이든), 화면 녹화 프로그램(데모 백업용), 타이머
오늘의 명령	명령어 대신 설계 도구입니다 — 주제 선정표, 4단 구조, 슬라이드 목차, 리허설 기록표
필요한 개념	청중 중심 설계, 장당 메시지 하나, 라이브 데모의 실패 변수, 리허설 컷 편집
오늘의 산출물	30분 발표 슬라이드 15~20장 + 데모 녹화 백업 + 리허설 기록 2회

2-1. 청중 중심 설계 — 나열과 설계의 차이

발표 준비의 첫 번째 실수는 "내가 아는 것을 다 넣는 것"입니다. 청중이 30분 발표에서 기억하는 것은 3가지를 넘지 않습니다 — 그러니 다 넣어도 3가지만 남습니다. 문제는 어느 3가지가 남는지가 무작위라는 것입니다.

설계는 그 선택을 발표자가 대신하는 것입니다. "이 발표에서 꼭 전할 한 문장"을 먼저 정하고, 그 문장과 무관한 내용은 과감히 버립니다. 소재 원문의 문장 그대로, 이 한 문장이 발표 전체의 설계도이자 편집 기준입니다.

2-2. 4단 구조 — 30분의 배분

단계	시간	하는 일
도입(문제 제기)	3분	왜 이 주제가 중요한가 — 청중의 문제로 제시
배경	5분	청중이 모를 것만 — 다 아는 것을 다시 설명하지 않음
핵심 + 데모	17분	본론. 데모가 5분 이상이어야 지루하지 않음
정리 + Q&A	5분	가져갈 한 문장을 반복하고 질문을 받음

도입의 기준은 "청중의 문제"입니다. "오늘은 IDOR에 대해 말하겠습니다"가 아니라, "여러분이 만든 API의 번호만 바꿔도 남의 데이터가 보인다면?"처럼 청중의 자리에서 시작합니다. 배경의 기준은 "청중이 모를 것만" — 초보 청중에게 HTTP 기초를 다시 설명하는 5분은 양쪽 모두의 시간 낭비입니다.

2-3. 슬라이드의 규칙 — 장당 메시지 하나, 코드는 크게

슬라이드 규칙은 세 가지입니다.

규칙	내용	위반의 증상
장당 메시지 하나	한 장에 하나의 주장만	청중이 읽느라 듣지 않음
코드는 크게	맨 뒷줄에서 읽히는 크기(24pt 이상)	"안 보여요"라는 중간 질문
데모는 녹화 백업	라이브 + 사전 녹화 병행	데모 실패 시 발표 전체의 정지

특히 셋째 — 라이브 데모는 반드시 실패 변수가 있습니다. 네트워크, 환경, 긴장된 손. 프로 발표자들도 녹화 백업을 준비하는 이유는 실력 부족이 아니라 확률 관리입니다. 녹화가 있으면 라이브를 과감히 시도할 수 있습니다 — 실패해도 전환하면 되니까요.

2-4. 리허설 — 발표는 쓰는 것이 아니라 깎는 것

초고의 발표는 대부분 깁니다 — 아는 것을 다 넣은 결과이기 때문입니다. 리허설의 목적은 연습이 아니라 편집입니다. 소리 내어 혼자 2회, 시간을 재고, 초과 부분을 잘라냅니다.

컷 편집의 기준은 2-1의 "한 문장"입니다. 그 문장으로 가는 길에 없는 슬라이드는 아무리 멋져도 버립니다. 그리고 Step 331의 멘토링 세션에서 예비 발표를 해 보는 것이 최고의 리허설입니다 — 실제 청중의 표정이 "여기서 지루해하는가"를 알려 주니까요.

3. 따라 하기

3-1. 주제 선정 — 세 조건의 교집합

주제는 세 조건의 교집합에서 고릅니다.

주제 선정표 (화면 예시):
조건 1. 내가 가장 잘하는 것 — 내 트랙에서 반복해서 성공한 기술
조건 2. 청중에게 유용한 것 — 듣는 사람이 다음 주에 써먹을 수 있는가
조건 3. 30분에 담기는 것 — 하나의 완결된 이야기인가

[후보 평가 예시]
- "실전 IDOR 찾기"            : 1 O / 2 O (입문자도 바로 시도 가능) / 3 O  <- 선정
- "커널 익스플로잇 입문"       : 1 O / 2 △ (청중이 중급이어야) / 3 X (30분 초과)
- "내 버그바운티 총결산"       : 1 O / 2 X (구경은 재미있으나 가져갈 것이 없음) / 3 O

읽는 법: 조건 2를 통과 못 하는 주제가 가장 흔한 함정입니다 — "내가 열심히 한 것"과 "청중이 가져갈 것"은 다릅니다. 소재 원문의 예시처럼 "CTF 포너블 입문", "패치 diff로 취약점 분석하기" 같은 주제가 좋은 이유는 듣는 사람의 다음 행동이 명확하기 때문입니다.

3-2. 청중 정의와 "한 문장"

주제가 정해지면 청중을 문장으로 정의하고, 발표의 한 문장을 씁니다.

청중 정의와 한 문장 (화면 예시):
- 청중: 보안 입문 6개월~1년 차. 웹 기초(HTTP, 세션)는 알고,
  취약점 진단은 해 본 적 없는 사람 20명.
- 이 발표에서 꼭 전할 한 문장:
  "IDOR는 번호만 바꿔 보는 것에서 시작한다 — 오늘 당장 내 랩에서 확인할 수 있다."
- 청중이 가져갈 3가지:
  1. IDOR가 뭔지 한 문장으로 설명할 수 있다
  2. 내 랩에서 재현하는 절차를 안다
  3. 합법 연습처(내 랩·버그바운티 scope)를 안다

읽는 법: "가져갈 3가지"가 슬라이드의 챕터가 됩니다. 이 목록에 없는 내용은 이후 제작 과정에서 전부 버려질 후보입니다.

3-3. 슬라이드 목차 설계 — 15~20장의 배치

목차를 먼저 완성하고, 슬라이드는 나중에 채웁니다. 30분 발표의 목차 예시입니다.

슬라이드 목차 (화면 예시) — "실전 IDOR 찾기" 30분, 총 17장:
 1. 표지 — 제목, 이름, 소속
 2. [도입] 문제 제기: "주소창의 숫자를 하나 바꿨더니 남의 주문 내역이 보였다"
 3. [도입] 이것이 실제로 얼마나 흔한가 — 통계와 사례 한 장
 4. [배경] IDOR의 정의 한 장 — "인가(authorization) 검사의 부재"
 5. [배경] 인증과 인가의 차이 — 그림 하나
 6. [배경] 어디에 숨어 있는가 — URL, 파라미터, API 경로
 7. [핵심] 찾는 절차 개요 — 4단계 그림 (관찰 → 변조 → 비교 → 확인)
 8. [핵심] 1단계: 관찰 — 내 계정의 요청에서 식별자 찾기
 9. [핵심] 2단계: 변조 — 숫자 바꾸기, UUID라면?
10. [핵심] 3단계: 비교 — 계정 두 개로 교차 확인하는 법
11. [핵심] 4단계: 확인 — 진짜 취약인지, 의도된 공개인지
12. [데모] 내 랩에서의 재현 — 화면 녹화 5분 (라이브 + 백업)
13. [핵심] 실전에서의 주의 — 합법 범위(scope)와 윤리
14. [핵심] 막는 법 — 서버 측 인가 검사 한 장
15. [정리] 오늘의 한 문장 (반복)
16. [정리] 가져갈 3가지 + 연습처 안내
17. Q&A — 연락처와 자료 공개 주소

읽는 법: 배치의 법칙 두 가지. ① 데모(12번)가 발표의 중앙에 옵니다 — 청중의 집중력은 중반에 꺾이므로, 꺾이는 지점에 가장 강한 콘텐츠(실연)를 놓는 것입니다. ② "막는 법"(14번)이 들어갑니다 — 공격만 다루는 발표는 입문 청중에게 반쪽짜리이고, 방어 관점이 있어야 "왜 이것이 취약인가"의 이해가 완성됩니다.

3-4. 슬라이드 제작 — 두 장의 완성 예시

목차의 각 장을 "장당 메시지 하나"로 채웁니다. 4번 슬라이드(정의)의 완성 예시입니다.

[슬라이드 4 완성 예시 — 화면 예시]
┌─────────────────────────────────────────────┐
│                                             │
│   IDOR = 서버가 "이 데이터가 네 것인지"      │
│          확인하지 않는 것                    │
│                                             │
│   (아래에 작은 그림: 브라우저 → /order/1001  │
│    → 서버 → "1001의 주인인지 묻지 않고" 응답) │
│                                             │
└─────────────────────────────────────────────┘
발표자 노트: "IDOR의 학명은 Insecure Direct Object Reference이지만,
학명은 잊으셔도 됩니다. 기억할 것은 이 한 줄입니다 — 서버가 묻지 않는다.
로그인은 했는지(인증)가 아니라, 이 데이터가 당신 것인지(인가)를요."

읽는 법: 슬라이드 본문에는 메시지 한 줄과 그림 하나만 있고, 설명은 발표자 노트에 있습니다. 이 분리가 "장당 메시지 하나"의 구현입니다 — 청중에게 보여 주는 것(슬라이드)과 들려주는 것(노트)이 다른 채널이어야, 청중이 읽느라 듣지 않는 사고가 없습니다. 코드가 들어가는 장(9번 슬라이드 등)은 5~7줄을 넘기지 말고, 글꼴은 24pt 이상으로 합니다.

3-5. 데모 준비 — 라이브와 녹화의 이중화

데모(12번 슬라이드)는 두 벌을 준비합니다.

데모 준비 체크리스트 (화면 예시):
[ ] 라이브 데모 환경 — 내 랩을 발표 전날 최종 점검 (스냅샷/백업 상태로)
[ ] 라이브 데모 대본 — 입력할 것을 미리 텍스트 파일에 (긴장 시 오타 방지)
[ ] 사전 녹화 영상 — 같은 시연을 화면 녹화한 mp4 (5분 이내, 자막·확대 포함)
[ ] 전환 큐 — 발표자 노트에 "데모 실패 시: '환경이 협조하지 않네요.
    녹화로 보여 드리겠습니다' 한 마디 + 영상 재생" 문구를 미리 기록

읽는 법: "전환 큐"가 프로와 아마추어의 차이입니다 — 실패는 확률의 문제이고, 실패 후의 매끄러운 전환은 준비의 문제입니다. 청중은 데모 실패를 용서하지만, 당황한 30초의 침묵은 기억합니다.

3-6. 리허설 2회 — 시간 측정과 컷 편집

완성된 자료로 혼자 소리 내어 2회 발표하고 기록합니다.

리허설 기록 (화면 예시):
[1회차] 총 38분 — 초과 8분. 구간별: 도입 4 / 배경 9(초과 4) / 핵심+데모 19 / 정리 6
        관찰: 배경에서 인증·인가 설명이 길어짐, 9번 슬라이드(UUID)에서 횡설수설
        조치: 배경 5번 슬라이드 삭제(청중이 아는 내용), 9번은 슬라이드에 키워드 추가
[2회차] 총 29분 — 도입 3 / 배경 5 / 핵심+데모 17 / 정리 4
        관찰: 2회차에도 막힌 10번 슬라이드(교차 확인) — 멘토링 세션에서 예비 발표 예정

읽는 법: 구간별 시간이 보이면 컷 편집의 대상이 과학적으로 정해집니다 — "어딘가 길다"가 아니라 "배경이 4분 초과다"로. 그리고 1회차 38분 → 2회차 29분이 정상 궤적입니다. 처음부터 30분이면 그것은 운이 아니라 분량이 부족한 것일 수 있습니다.

4. 미션과 연습문제

미션 — 30분 세미나 발표 자료 완성

3-1의 선정표로 주제를 고르고, 세 조건의 통과 여부를 기록합니다.
3-2의 양식으로 청중 정의와 "한 문장", "가져갈 3가지"를 씁니다.
3-3처럼 15~20장의 슬라이드 목차를 설계합니다 — 4단 구조와 시간 배분 표기.
슬라이드를 제작합니다 — 장당 메시지 하나, 코드 24pt 이상, 발표자 노트 포함.
3-5의 체크리스트로 데모를 이중화(라이브+녹화)하고, 리허설 2회를 시간 측정과 함께 수행해 기록합니다.

연습문제

문제 1. "청중이 기억하는 것은 3가지를 넘지 않는다"는 사실이 발표 준비에 주는 함의를, "다 넣는 발표"와 "설계된 발표"의 차이로 설명해 보세요.

문제 2. 4단 구조에서 데모가 발표의 중앙(중반부)에 배치되는 이유를 청중 집중력 곡선과 연결해 설명해 보세요.

문제 3. 슬라이드 본문과 발표자 노트를 분리하는 것이 "장당 메시지 하나" 원칙의 구현인 이유를 설명해 보세요.

문제 4. 리허설의 목적이 "연습"이 아니라 "편집"이라는 관점에서, 구간별 시간 측정이 왜 컷 편집의 전제 조건인지 설명해 보세요.

5. 모범 답안과 완료 기준

미션 모범 답안

검증 기준으로 확인하세요.

주제의 근거: 세 조건(잘함·유용함·완결성) 평가가 기록됐는가 — "재미있을 것 같아서"는 근거가 아닙니다.
한 문장의 존재: "꼭 전할 한 문장"과 "가져갈 3가지"가 자료 제작 전에 쓰였는가.
목차의 구조: 4단 구조(도입·배경·핵심+데모·정리)와 시간 배분이 목차에 표기됐고, 데모가 중반부에 있는가.
슬라이드의 규율: 임의의 장을 뽑아 메시지가 하나인지, 코드 장의 글꼴이 큰지, 발표자 노트가 있는지.
리허설의 증거: 2회의 구간별 시간 기록과 그에 따른 조치(삭제·수정)가 있는가.

연습문제 해답

문제 1 해답. 다 넣는 발표는 기억에 남는 3가지를 청중이 무작위로 선택하게 방치합니다 — 발표자가 가장 전하고 싶은 것이 남을 보장이 없고, 정보가 많을수록 각 항목의 각인은 얕아집니다. 설계된 발표는 발표자가 그 3가지를 미리 정하고, 모든 슬라이드가 그 3가지로 수렴하도록 배치합니다 — 반복과 구조로 각인을 깊게 만듭니다. 함의는 편집의 방향입니다 — 추가의 기술이 아니라 삭제의 기술이 발표의 품질을 결정하고, 삭제의 기준은 "꼭 전할 한 문장"입니다. 자료에 다 넣고 싶어지는 욕심은 모든 발표자가 겪는 정상적 충동이고, 그 충동을 한 문장으로 절제하는 것이 설계입니다.

문제 2 해답. 청중의 집중력은 발표 시작 후 15~20분 지점에서 가장 깊게 꺾입니다 — 도입의 새로움이 사라지고 본론의 밀도가 올라가는 지점입니다. 이 지점에 텍스트 슬라이드가 이어지면 꺾인 집중력이 회복되지 않지만, 데모(실연)는 채널 전환 효과 — 보는 것에서 관찰하는 것으로 — 를 일으켜 집중력을 다시 끌어올립니다. 그래서 데모는 앞쪽(아직 집중력이 높을 때라 낭비)도 뒤쪽(이미 흩어진 뒤라 회복 불가)도 아닌 중앙에 놓습니다. "데모가 5분 이상이어야 지루하지 않다"는 규칙은 이 곡선 관리의 구체적 구현입니다.

문제 3 해답. 슬라이드에 문장이 많으면 청중은 읽기 시작하고, 읽는 동안 발표자의 말을 듣지 않습니다 — 시각 채널과 청각 채널이 같은 내용을 두고 경쟁하는 상태입니다. 본문(메시지 한 줄+그림)과 노트(상세 설명)의 분리는 두 채널의 역할을 나눕니다 — 슬라이드는 "무엇에 관한 이야기인가"의 닻이고, 발표자의 말이 그 닻에 실리는 설명입니다. 이렇게 분리해야 "장당 메시지 하나"가 슬로건이 아니라 물리적 제약으로 작동합니다 — 메시지가 두 개면 한 장에 안 들어가기 때문입니다.

문제 4 해답. 초고의 발표는 거의 항상 시간 초과이므로, 리허설의 본질은 "무엇을 뺄 것인가"의 결정입니다. 그런데 총 시간만 알면(38분) 어디를 뺄지 감에 의존하게 되고, 감으로 자르면 애착이 있는 부분(대개 핵심이 아니라 노력이 들어간 부분)을 남기는 실수를 합니다. 구간별 시간은 초과의 위치를 드러냅니다 — "배경이 4분 초과"라고 알면, 자르는 대상이 4단 구조의 어느 칸인지가 명확해지고, "한 문장" 기준의 절제가 그 칸에 집중됩니다. 측정 없는 편집은 감상이고, 측정 있는 편집만이 재현 가능한 기술입니다.

완료 기준 체크리스트

[ ] 주제 선정표로 세 조건(잘함·유용함·완결성)을 통과한 주제를 골랐다
[ ] 청중 정의와 "꼭 전할 한 문장", "가져갈 3가지"를 문서화했다
[ ] 4단 구조와 시간 배분이 표기된 15~20장의 목차를 완성했다
[ ] 모든 슬라이드에 메시지 하나와 발표자 노트가 있다
[ ] 코드 슬라이드의 글꼴이 24pt 이상이고 5~7줄 이내다
[ ] 데모가 라이브 + 사전 녹화로 이중화됐고 전환 큐가 노트에 있다
[ ] 공개 승인이 필요한 내용(제보·CVE)의 게재 여부를 확인했다
[ ] 리허설 2회를 구간별 시간 측정과 함께 수행하고 조치를 기록했다

6. 흔한 실수와 해결

벽 1. 자료에 다 넣고 싶어서 슬라이드가 40장이 됐어요

증상: 30분 발표인데 목차를 짜다 보니 40장, 예상 시간은 1시간이 넘습니다.

원인: 2-1의 함정 그대로입니다 — "내가 아는 것의 나열"로 설계가 시작된 것입니다.

해결: 절차를 거꾸로 하세요. ① "꼭 전할 한 문장"과 "가져갈 3가지"를 먼저 확정(3-2). ② 3가지 각각에 슬라이드 4~5장만 배정. ③ 나머지 내용은 "부록(appendix)" 슬라이드로 밀어 둡니다 — Q&A에서 관련 질문이 나오면 꺼내 보여 주는 자료로 씁니다. 부록은 버리는 것이 아니라 대기시키는 것이라, 삭제의 심리적 저항이 줄어듭니다. 그리고 기억하세요 — 청중이 기억하는 건 어차피 3가지입니다. 40장의 발표는 3가지를 청중이 고르고, 17장의 발표는 발표자가 골라 줍니다.

벽 2. 리허설인데 슬라이드마다 말이 막혀요 — 자료가 잘못된 건가요?

증상: 소리 내어 발표하려니 슬라이드 사이의 연결이 끊기고, 어떤 장에서는 할 말이 안 떠오릅니다.

원인: 두 가지 중 하나입니다 — 슬라이드의 순서가 이야기의 인과와 안 맞거나(구조 문제), 발표자 노트가 비어 있거나(준비 문제).

해결: 구분법 — 노트를 채운 뒤에도 막히는 장이 구조 문제입니다. 그 장은 "왜 이 다음에 이 장이 오는가"에 답이 없는 곳입니다. 장 사이의 연결 문장("~를 봤으니, 이제 ~의 문제가 남습니다")을 노트에 쓰고, 연결 문장이 안 써지는 장은 순서를 바꾸거나 버립니다. 막힘은 발표 연습 부족이 아니라 자료가 알려 주는 구조의 신호입니다.

벽 3. 데모 녹화를 하는데 화면 글씨가 너무 작아요

증상: 터미널 시연을 녹화했더니 영상에서 명령어가 읽히지 않습니다.

원인: 내 모니터 기준으로 편한 글꼴은 영상·프로젝터 기준으로는 너무 작습니다 — 해상도 압축과 시청 거리 때문입니다.

해결: 녹화 전에 터미널 글꼴을 평소의 두 배로 올리고(보통 24pt 이상), 창을 전체 화면이 아니라 절반 크기로 녹화합니다 — 창이 작을수록 상대적으로 글자가 커 보입니다. 핵심 입력 부분은 화면 확대 또는 자막으로 보강합니다. 마지막으로 검증 — 녹화 영상을 휴대폰으로 옮겨 보세요. 휴대폰 화면에서 읽히면 강의실 맨 뒷줄에서도 읽힙니다.

벽 4. 내용에 제보한 취약점 얘기를 넣고 싶은데, 공개해도 되는지 모르겠어요

증상: Step 318~319에서 제보한 건을 사례로 쓰고 싶지만, 대상 서비스명을 밝혀도 되는지 확신이 없습니다.

원인: 제보 내용의 공개는 프로그램의 공개 정책(disclosure policy)과 embargo 해제 여부에 달려 있습니다.

해결: 규칙은 단순합니다 — 명시적 공개 승인이 없으면 식별 정보를 뺍니다. 서비스명·도메인·화면 캡처의 식별 요소를 전부 제거하고, "모 커머스 서비스" 수준으로 일반화합니다. 패치가 완료됐고 프로그램이 공개를 허용한 건만 실명 사례로 씁니다. 불확실하면 익명화가 언제나 정답입니다 — 발표의 가치는 기법에 있지 서비스 이름에 있지 않습니다. 그리고 데모는 무조건 내 랩 환경에서만 합니다.

벽 5. 리허설을 2회 했는데도 35분이에요 — 더 자를 곳이 안 보여요

증상: 구간별 시간은 쟀지만, 어느 슬라이드도 빼기 아까워 보입니다.

원인: 발표자의 애착은 자기 관점에서 생깁니다 — 혼자 하는 리허설의 한계입니다.

해결: 청중을 빌리세요 — Step 331의 멘토링 세션에서 예비 발표를 합니다. 실제 청중 앞에서는 "지루해하는 표정"과 "고개를 끄덕이는 표정"이 슬라이드별로 기록됩니다. 청중의 반응이 없는 슬라이드가 자를 슬라이드입니다. 그래도 안 되면 질문을 바꾸세요 — "무엇을 뺄까"가 아니라 "한 장만 남긴다면 무엇인가". 이 극단적 질문이 애착의 순위를 드러냅니다.

7. 정리

오늘의 개념

개념	한 줄 설명
청중 중심 설계	아는 것의 나열 ✕, 가져갈 것의 설계 ○
꼭 전할 한 문장	발표의 설계도이자 삭제의 기준
4단 구조	도입 3 → 배경 5 → 핵심+데모 17 → 정리 5 (30분 기준)
장당 메시지 하나	본문(닻)과 발표자 노트(설명)의 분리
데모 이중화	라이브 + 녹화 백업 + 전환 큐 — 확률 관리
리허설 = 편집	구간별 시간 측정이 컷 편집의 전제

오늘의 도구·명령어

도구·양식	하는 일
주제 선정표	잘함·유용함·완결성의 세 조건 평가
청중 정의 + 한 문장	깊이 조절과 편집 기준의 확정
슬라이드 목차	4단 구조·시간 배분·데모 중앙 배치
발표자 노트	장당 메시지 하나의 물리적 구현
데모 준비 체크리스트	환경 점검·대본·녹화·전환 큐
리허설 기록표	구간별 시간 측정과 조치의 기록

명령어보다 중요한 감각

발표 자료를 다 만들고 나면 이상한 부산물이 남습니다 — 그 주제에 대한 내 이해가 발표 전보다 훨씬 정리돼 있다는 것. 한 문장으로 압축하고, 장당 메시지로 쪼개고, 막히는 연결을 고치는 과정이 Step 331의 파인만 기법을 대규모로 돌린 것과 같기 때문입니다. 발표 자료 제작은 지식의 출력이 아니라 마지막 정제입니다.

이제 자료는 완성됐고 리허설도 끝났습니다. 남은 것은 무대입니다 — 다음 Step 333에서 실제 청중 앞에 서고, 자료를 공개하고, 피드백을 받는 것으로 이 사이클을 닫습니다. 자료는 준비됐습니다. 나갈 일만 남았습니다.

전부 체크되면 Step 332 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.