발표 덱 만들기 (pitch-deck-build)
문장부호: 출력에
(em-dash)를 쓰지 않는다. 쉼표나 마침표로 끊는다.
목적
팀의 솔루션을
발표 슬라이드(
)로 만든다.
데모와 이어지게 한다.
대본·예상 질문·리허설은 이 스킬이 아니라 가 맡는다. 여기서는
슬라이드를 만든다.
이 단계의 역할
주도: Red · 찌르는 사람: Green · Blue는 덱 위의 숫자를 지킨다
화면을 아는 사람이 짜고, 이야기가 되는지 Green이 본다.
의
에서
이름을 읽어 세 명 다 부른다. 시작할 때 소리내어 배분한다.
🔴 Red: 주도. 제일 보여주고 싶은 한 장면에서 덱을 짠다. "데모데이에서 제일 보여주고 싶은 한 장면이 뭐예요?"
🟢 Green: 장과 장이 이야기로 이어지는지 본다. "이 장 다음에 왜 저 장이에요?"
🔵 Blue: 덱에 올라간 숫자마다 출처·기준시점이 붙었는지 지킨다. 여기 빠진 게 Q&A에서 그대로 터진다. "이 숫자, 물으면 답할 수 있어요?"
한 명에게 쏠리면 찌르는 사람을 이름으로 호명한다. 2인 팀이면 Red는 공동이다.
시작 전
덱은
시연을 감싸는 포장이지 시연을 대체하지 않는다. 데모 구간은 슬라이드 한 장으로 비워둬라.
시연 시나리오는 다음 단계(
)에서 짠다. 시연에서 보여줄 걸 슬라이드로 미리 다 설명하지 마라.
⚠ 그 빈 장에
같은
작업 라벨을 그대로 띄우지 않는다. 화면에 뜨는 건 관객이 읽는
글자다. 서비스 이름 한 줄이면 충분하고, 말은
"이제 직접 보여드리겠습니다" 로 넘어간다.
- 의 ····(prototype.html)을 읽는다.
../design-setup/references/레이아웃-패턴.md
- : HTML·CSS·JS 복붙용 골격. 이동·진행바·편집을 새로 짜지 않는다.
★ 디자인부터 정한다: 반드시 묻는다
(프로토타입에 쓴 디자인)를 보여주고
팀에게 고르게 한다.
"프로토타입은 이 색·이 느낌으로 만들었어요. 발표 슬라이드도 똑같이 갈까요, 아니면 발표용으로 좀 손볼까요?"
| 선택 | 언제 좋나 | 어떻게 |
|---|
| 그대로 간다 (기본) | 대부분. 화면과 슬라이드가 한 몸으로 보인다. 가장 안전하다 | 토큰을 그대로 |
| 발표용으로 손본다 | 프로토타입 색이 화면에선 예쁜데 빔프로젝터에선 흐릴 때 | 아래 조정 |
발표용으로 손볼 때 (자주 필요하다)
빔프로젝터는 색이 날아가고 대비가 약해진다. 노트북에서 예쁜 파스텔이 스크린에선 안 보인다.
- 배경을 더 어둡거나 더 밝게: 중간 회색은 최악이다
- 글자를 키운다. 본문 16px → 슬라이드는 20~24px 이상. 뒷자리에서도 읽혀야 한다
- 대비를 올린다. 연한 색 글자 금지
- 메인 색은 유지한다 ← 이건 바꾸지 않는다. 바꾸면 프로토타입과 남남이 된다
팀이 "몰라요"라고 하면
그대로 간다. 시간이 아깝다. 고른 결과는
에 한 줄 덧붙인다.
★ 구성도 팀이 짠다: 반드시 묻는다
디자인만 묻고 내용은 AI가 채우면, 팀은 자기 발표를 남의 것처럼 읽게 된다.
슬라이드를 뽑기 전에 팀에게서 받는다. 순서를 먼저 정하고, 그다음에 각 장을 채운다. 한 번에 한 질문.
순서를 거꾸로 하지 마라. 내용부터 물으면 재료만 잔뜩 쌓이고 어디에 놓을지 몰라 결국 AI가
배치하게 된다. 뼈대가 먼저다.
시간을 꺼내놓고 시작한다. 의
을 읽어 그대로 말한다:
"우리 발표 6분이에요. 6분이면 생각보다 짧아요."
1단계: 어떻게 구성할지 정한다
여기서 정하는 건 방식뿐이다. 내용도, 장 수도 아직 묻지 않는다.
아래 셋을 보여주고 팀이 고르게 한다. AI가 하나로 몰지 않는다.
| 방법 | 언제 | 어떻게 |
|---|
| A. 기본형 (권장 출발점) | 대부분. 처음 발표하거나 시간이 없을 때 | 아래 6비트 그대로 쓰고, 내용만 우리 걸로 채운다 |
| B. 기본형 + 얹기 | 우리 팀만의 강점이 6비트에 안 담길 때 | 6비트를 두고 선택 요소(뒤에 목록)를 골라 끼운다 |
| C. 처음부터 | 이야기가 이미 뚜렷하거나 6비트가 안 맞을 때 | 뒤의 역산 4문항으로 우리 뼈대를 직접 짠다 |
"세 가지 길이 있어요. 검증된 기본 뼈대로 갈까요, 거기에 우리 것만 얹을까요, 아니면 아예 처음부터 짜볼까요?"
C를 고른다고 말리지 않는다. 다만 다 짜고 나서 뒤의 점검 4개는 같이 돌린다.
어느 길로 가든 장 수는 6이 아니어도 된다. 합쳐도, 쪼개도, 빼도 된다.
A. 기본형: YC 데모데이 6비트
마지막 날은 발표회가 아니라 데모데이다. 뼈대도 거기에 맞춘다. Y Combinator 데모데이 덱이 쓰는
여섯 비트다. 세계에서 제일 많이 검증된 순서이고, 마침 팀이 3일 동안 실제로 겪은 순서와 같다.
없는 이야기를 지어내는 게 아니라 이미 한 일을 순서대로 꺼내는 것이라, 팀이 자기 말로 할 수 있고
질문이 들어와도 안 무너진다.
| 비트 | 이 장이 하는 일 | 팀에게 던질 질문 |
|---|
| ① One-liner<br>한 문장 | "저희는 ○○를 위한 △△입니다." 첫 15초 안에 뭘 만들었는지 말한다. 목차·인사·자기소개로 열지 않는다(넣고 싶으면 B의 선택 요소를 본다). YC가 가장 많이 지적하는 게 이거다. 1분이 지나도 뭐 하는 팀인지 모르겠는 발표 | "이 발표를 한 문장으로 줄이면요?" |
| ② Problem<br>문제 | 우리 페르소나가 언제·어디서 막히는 장면 하나. "통영 도착한 반려인이 저녁 먹을 데를 40분 검색하다 결국 편의점으로 간다" 이름·시간·장소가 있어야 남는다. "관광객이 불편하다"는 아무 팀이나 쓸 수 있는 문장이라 아무것도 아니다 | "그 사람이 포기하는 순간이 정확히 언제예요?" |
| ③ Insight<br>알아낸 것 ★ | 이 덱의 심장. "다들 이럴 거라 생각하는데, 데이터를 보니 아니었습니다." 우리 가설 → 받은 수치 → 거기서 뒤집힌 것. 비교 대상을 같이 두고(숫자 하나만으론 크고 작은지 모른다), 차트 1개, 기준시점 각주. 왜 이 지역인지도 여기서 답한다 | "데이터 보기 전에 뭐라고 예상했었죠?" |
| ④ Product<br>만든 것 | 그 인사이트에서 곧바로 따라 나오는 물건. 기능 목록이 아니라 선택과 버린 것. 사람이 정한 것과 AI에 맡긴 판단이 어디서 갈리는지 한 줄, 3일 내내 한 게 그거다 | "③을 알았으니 이게 나오는 거예요? 뭘 버렸어요?" |
| ⑤ Demo<br>돌아가는 화면 | 말 대신 실제로 눌러서 되는 것. 슬라이드는 거의 비우고 로 넘어간다. ④에서 말한 AI의 판단이 여기서 눈에 보여야 한다. 시나리오는 에서 초 단위로 | "1분 안에 뭘 보여주면 믿을까요?" |
| ⑥ The Ask<br>필요한 것 | YC 덱은 "저희에게 필요한 건 이겁니다" 로 끝난다. "3일로 여기까지 왔고, ○○시 관광재단과 한 달만 붙여주시면 실제 이용 데이터를 받아보고 싶습니다." 가장 많이 빠뜨리는 장이다. 데모에서 끝내면 심사위원 머릿속에 "잘 만든 습작"으로 남는다. 마지막 문장은 팀이 직접 쓴다 | "이거 진짜 굴리려면 뭐가 있어야 해요?" |
③ Insight가 이 캠프의 무기다. YC가 말하는 인사이트는
"우리만 아는 것" 이다. 다들 아는 사실을 다시 말하면 인사이트가 아니다.
그리고 이 부트캠프는 그걸 만들 수 있는 유일한 자리다. 팀이 4단계에서
숫자를 보기 전에 예상을
적어뒀고, 그게
의
·
에 남아 있다. 빗나갔다면 그 얘기를 시킨다:
"저희도 처음엔 잘 곳이 없어서 안 자고 가는 줄 알았어요. 그런데 숙박 비중은 오히려 높더라고요.
문제는 다른 데 있었습니다."
아무 팀도 못 베끼는 문장이고, 데이터를 진짜로 봤다는 걸 한 번에 증명한다. 3일 중 하루를 데이터에
썼는데 덱에서 한 장으로 스쳐가는 팀이 매년 나온다. ③은 줄이지 않는다.
B. 기본형에 얹기: 선택 요소 메뉴
얹는 건 추가가 아니라 교환이다. 6비트 기본형이 이미 6분 중 5분 40초를 쓴다(여유 20초).
남는 20초에 새 장을 넣을 수 없다. 하나를 얹으면 6비트 중 하나에서 그만큼 뺀다.
고르게 하기 전에 이 말을 먼저 하고, "넣으면 어디서 뺄까요?" 를 같은 질문 안에서 묻는다.
"'왜 우리 팀인가' 20초를 넣으면, Problem을 60초에서 40초로 줄이거나 Demo를 15초 깎아야 해요.
어느 쪽이 나을까요?"
이 교환을 안 시키면 리허설에서 시간이 터지고, 그때는 대본을 통째로 다시 짜야 한다.
| 얹을 것 | 언제 값을 하나 | 값 | 어디에 |
|---|
| Why us<br>왜 우리 팀인가 | 전공이 갈리는 팀은 거의 항상. 의 가 이미 있다. "저희 중 둘이 의료 전공이라 이 동선이 보였습니다" 심사위원이 기억하는 건 대개 이거다 | 20초 | ⑥ 앞 또는 ① 뒤 |
| Why now<br>왜 지금인가 | 데이터에 최근 변화가 잡혔을 때. "펫 동반 시설이 2년 새 3배 늘었는데 정보는 그대로입니다" | 20초 | ② 뒤 |
| 기존 대안<br>지금은 어떻게 하나 | 심사위원이 "그거 네이버로 되지 않나요?" 할 것 같을 때. ③(지금의 대안)에 이미 답이 있다. 선제 방어 | 25초 | ② 뒤 또는 ④ 안 |
| How it works<br>구조 한 장 | 서비스가 여러 데이터를 엮을 때. 입력→AI 판단→출력 흐름도 하나. 말로 설명하면 안 들리는 걸 그림이 3초에 끝낸다 | 30초 | ④ 안 |
| 규모<br>얼마나 큰 문제인가 | 지역 방문객 수처럼 받아둔 숫자가 있을 때. 없으면 넣지 마라, 추정치는 바로 질문을 부른다 | 15초 | ② 안 |
| 로드맵<br>3일 → 3개월 | ⑥ The Ask를 구체적으로 만들 때. 단계 3개까지만 | 20초 | ⑥ 안 |
| 팀 소개<br>이름·전공 | 얼굴을 알리고 싶을 때. 다만 앞에 두지 않는다. 앞에 두면 "뭐 하는 팀"이 15초 늦어진다 | 15초 | ⑥ 뒤 |
| 목차 | "흐름을 먼저 알려주고 싶다" 할 때. 6분에는 대개 손해다. 안 듣고, 15초를 먹고, 다음 장에서 또 말하게 된다. 팀이 원하면 넣되 이 손익을 말해준다 | 15초 | ① 뒤 |
| 감사 / Q&A | 마지막 장. Ask를 말한 뒤에 띄운다. 이 장에 내용을 담지 않는다 | 0초 | 맨 뒤 |
"이 중에 우리 발표를 더 세게 만들 것 같은 게 있어요? 하나씩만 골라볼까요. 넣으면 어디서 빼야 하는지도 같이 봐요."
두 개까지가 현실적이다. 셋을 얹으면 6비트에서 60초 넘게 빼야 하는데, 그러면 Insight나 Demo가
반토막 난다. 제일 센 두 장을 깎아 곁가지를 늘리는 셈이다.
"셋 다 좋은데 6분이에요. 이 중 하나만 남긴다면 뭘까요?"
C. 처음부터 짜기: 역산 4문항
6비트가 안 맞는 팀도 있다. 어떤 모양으로 갈지부터 고르고, 그다음 순서를 뽑는다. 한 번에 한 질문.
1. 어떤 식으로 풀고 싶은지 고르게 한다.
"6분을 어떤 모양으로 쓰고 싶어요? 흔한 게 이 넷인데, 우리한테 맞는 게 있어요?"
| 모양 | 이렇게 흘러간다 | 어울리는 팀 |
|---|
| 데모 선공 | 화면부터 보여주고 → 왜 이게 필요한지 되짚는다 | 데모가 3초 만에 먹히는 팀 |
| 반전 | 다들 아는 통념을 깔고 → 데이터로 뒤집는다 | 이 뚜렷한 팀 |
| 한 사람 따라가기 | 페르소나 하루를 처음부터 끝까지 따라간다 | 페르소나가 선명한 팀 |
| 비교 | 지금 이렇게 한다 ↔ 우리 걸로는 이렇게 된다 | 기존 대안이 명확한 팀 |
고른 모양이 곧 뼈대의 성격이다. 여기서 안 고르면 2번으로 넘어가도 순서가 안 나온다.
2. 그 모양대로 순서를 뽑는다. 결론에서 거꾸로 짚는 게 제일 빠르다.
- "그 흐름의 마지막에 심사위원이 뭘 알고 있어야 해요?" → 도착점
- "그걸 알려면 그 전에 뭐가 먼저 나와야 해요?" → 안 나올 때까지 반복한다.
답이 3~5개 쌓이면 그게 뒤에서부터 짜인 순서다.
- "그중에 우리가 증거를 가진 건 뭐예요?" → 증거 있는 항목은 한 장씩, 없는 항목은 한 줄로 줄인다.
- "이 순서를 소리 내어 이어서 말해볼래요?" → 말로 안 이어지면 슬라이드로도 안 이어진다.
받아적은 순서를 그대로 보여주고 "이게 우리 뼈대 맞죠?" 확인한다.
짜고 나면 반드시 이 넷을 같이 점검한다. 어느 길(A·B·C)로 갔든 동일하다:
2단계: 그 뼈대에 내용을 채운다
뼈대가 정해진 다음에 묻는다. 한 장씩, 한 번에 하나.
- "이 발표에서 심사위원이 딱 하나만 기억한다면 뭐였으면 좋겠어요?" → 핵심 메시지
(뼈대의 어느 장에 놓을지도 같이 정한다. 대개 ① 아니면 ③)
- "제일 세게 밀 장면은 어디예요?" → 클라이맥스
- "거기에 6분 중 몇 분을 쓰고 싶어요?" → 여기부터 시간을 떼어둔다.
- 장마다 "○○장, 여기서 뭘 말하고 싶어요? 한 문장으로요."
- "그거 뒷받침할 게 에 이런 게 있는데, 이거 쓸까요, 다른 거 있어요?"
- 재료를 꺼내 보여주는 것까지가 AI 몫이다. 뭘 고르고 뭐라고 말할지는 팀 몫이다.
- 다 채우면 같이 센다. "이러면 ○장이고 장당 ○○초쯤이에요. 넉넉해요, 빠듯해요?"
- 빠듯하다고 하면 합칠 장을 팀이 고르게 한다. AI가 잘라내지 않는다.
"둘 중에 어느 걸 한 장으로 합칠까요?"
- 10장을 넘어가면 장당 30초대다. 그 숫자를 보여주고 팀이 판단하게 한다.
장마다 주장을 편다: 이게 설명과 피칭을 가른다 ★
대부분의 팀이 만드는 건 과제 보고서다. "주제는 이거고요, 데이터는 이랬고요, 이런 걸 만들었습니다."
전부 사실이지만 아무도 기억하지 않는다. 설명은 정보를 전달하고, 피칭은 판단을 요구한다.
한 장의 골격은 이렇다:
[섹션 라벨] ← 지금 어디쯤인지
큰 제목 ← 명사형. "펫 동반 필터" (○) / "저희는 필터를 만들었습니다" (×)
2~3문장 ← 여기가 주장이다. 긴장 → 우리 결정 → 그렇게 한 이유
본문/차트/화면 ← 위 주장을 뒷받침하는 것 하나만
가운데 2~3문장이 핵심이다. "무엇을 했다"가 아니라 "왜 그게 맞다" 를 쓴다.
✗ "펫 동반 가능한 장소를 필터링하는 기능을 만들었습니다."
○ "동반 가능 여부는 블로그 후기에 흩어져 있어 확인에 30분이 걸립니다. 저희는 검색이 아니라
필터로 풀었습니다. 찾는 수고를 줄이는 게 아니라 아예 없애야 여행 계획이 바뀌기 때문입니다."
한 급 더 올리는 방법: 기각한 대안을 쓴다. "지도에 다 찍어주는 것도 봤지만, 그러면 다시 고르는 일이
사용자에게 남습니다." 검토한 흔적이 보이는 순간 심사위원의 질문이 절반으로 준다.
YC식 문장 규칙 세 가지
- 형용사 말고 숫자. "많은 관광객이 방문하지만" → "연 1,817만 명이 오는데". 형용사는 아무 근거가 없다.
- ④는 ③에서 따라 나와야 한다. 인사이트와 상관없는 제품이 나오면 심사위원은 "그럼 그 데이터는
왜 봤나" 를 생각한다. ④를 쓴 뒤 되짚어 묻는다: "③이 없어도 이 제품 나왔을까요?" → 나왔다면 둘 중 하나가 틀렸다.
- ⑥은 구체적으로. "열심히 하겠습니다 · 발전시키고 싶습니다" 는 Ask가 아니다.
누구에게 · 무엇을 · 얼마 동안 이 들어가야 Ask다.
⚠
점수 얘기를 팀 앞에서 하지 않는다. 이 뼈대는 100점 평가표
(
../bootcamp-start/references/guides/bootcamp-context.md §1
: 문제정의25·기획력25·실현발전30·기술활용20)
위에 세운 것이고, Problem·Insight가 문제정의를, Insight·Product가 기술 활용을,
Demo·The Ask가 최고 배점인 실현·발전을 받는다.
그 대응은 내가 알고 있으면 되는 것이지 팀에게 브리핑할 게 아니다. "이 장은 25점짜리예요" 라고
말하는 순간 팀은 채점표를 채우러 간다. 점수를 노린 티가 나는 발표가 실제로 점수를 못 받는다.
대신
빠뜨렸을 때만 짚는다:
"⑥이 없는데, 이거 3일 뒤에 어떻게 되는 건지 궁금하지 않을까요?"
발표 화면: 골격은 이미 있다 ★
이동·진행바·편집 로직을 새로 짜지 마라. 의 HTML·CSS·JS를 그대로 복붙하고
색은
토큰으로, 내용은 팀이 정한 슬라이드로 채운다. 여기에 시간 쓰면 정작 내용이 빈다.
골격이 주는 것:
- 화면에 상시로 뜨는 컨트롤 UI가 없다. 하단 4px 진행바 하나뿐. 화살표 버튼도, 같은
키보드 안내문도 두지 않는다. 발표 중에 심사위원 눈이 거기로 간다. 조작법은 발표자만 알면 된다.
페이지 번호는 슬라이드 안 우상단()에 있다.
- 이동: 키보드(←→↑↓ Space PgUp/PgDn Home/End) · 마우스 휠 · 터치 스와이프 · 해시로 바로 열기.
- 1920×1080 고정 캔버스를 뷰포트에 맞춰 한다. 리플로우가 없으니 노트북에서 짠 게
빔프로젝터에서 그대로 나온다. 반응형으로 짜면 화면 비율마다 다르게 깨진다.
- 인쇄하면 슬라이드 1장 = 1페이지. → PDF. 노트북이 죽었을 때의 백업이 공짜로 생긴다.
리허설 때 한 번 뽑아두라고 팀에 권한다.
- 발표장 네트워크 없이 뜨는 단일 파일. 데이터 슬라이드는 인라인 SVG 또는 CSS 막대로 그린다.
차트 라이브러리를 불러오지 않는다. wifi가 끊기면 하필 데이터 근거 슬라이드만 빈다.
나중에 고칠 수 있게 (골격이 지키는 계약)
발표 직전에 FT나 팀이 "이 문장만 바꿔주세요" 한다. 그때 5분 안에 고쳐져야 한다.
- 슬라이드 1장 = 1개.
- 슬라이드 텍스트는 마크업 안에 직접 쓴다. JS 배열·객체에 넣고 렌더링하지 않는다. 그러면
화면에서 찾은 문장을 소스에서 못 찾고, 편집 모드도 무의미해진다.
- 색·글자 크기는 파일 상단 한 블록. 첫 줄에 주석.
- ✏️ 편집 모드: 좌상단 구석에 마우스를 올리거나 키. 켜지면 텍스트가 이 되고
라벨이 으로 바뀐다. 저장 기능이 아니다. 리허설 중 즉석
다듬기용이고, 영구 반영은 소스를 직접 고친다. 팀에게 이걸 꼭 말해준다.
스피커노트 (발표 대본)
각 슬라이드에
말할 대사 2~4줄을 함께 만든다. 별도 파일
또는 덱 하단 토글로.
- AI가 초안을 쓰고 끝내지 않는다. 장마다 "이 장에서 뭐라고 말할 거예요?" 를 먼저 묻고, 팀 말을
받아적은 뒤 다듬는다. 팀이 안 나오면 초안을 보여주되 소리 내어 읽어보게 하고 고치게 한다.
"읽어보니 우리 말투 같아요?"
- 슬라이드당 배분은 의 에서 계산한다.
- 첫 문장(훅)·마지막 문장(임팩트)은 반드시 팀이 직접 쓴다. AI가 채우지 않는다.
리허설 가이드
- 시간 배분: 의 에서 계산한다. 비어 있으면 FT에게 확인하고 채운다.
세부 배분은 ①의 비율표를 쓴다. 여기서 다른 기준을 만들지 않는다.
- 데모 리허설: prototype.html을 실제로 눌러보며 말 맞추기. 안 되는 경우 대비(스크린 캡처 백업).
- 예상 질문(Q&A) 3개를 팀이 뽑아 답 준비: "데이터 근거는?", "왜 이 지역?", "실제로 되나요?"
심화 (시간 있으면: 2박3일 깊이)
- 모의 발표 2회 이상: 타 팀·FT 앞에서 시간 재며 → 피드백 반영.
- Q&A 정교화: 예상 질문 5개로 늘리고 답을 데이터로 뒷받침.
- 훅·클로징 다듬기: 첫 15초와 마지막 한 문장을 여러 버전으로 써보고 고른다.
context.md 갱신
- 에 (+ ) 경로, .
- 로그에 "발표 덱 vN" 기록.
끝맺음
- 요약: 슬라이드 몇 장, 핵심 메시지 한 줄.
- 다음은 : 프로토타입과 이 덱을 바탕으로 피칭 전체를 준비한다: 시연 시나리오, 슬라이드별 대본, 시간 배분, 예상 질문, 그리고 통합 리허설. 덱만 좋고 발표가 무너지는 팀이 매년 나온다.
- 시간이 남으면:
- "이 덱, 우리가 없어도 심사위원이 혼자 넘겨보면 이해될까요?"
- "제일 약한 슬라이드가 어디예요? 거기를 고칠까요, 아예 뺄까요?"
톤
- 한 턴 = 맥락·이유 1문단 + 질문 1개. 질문만 툭 던지지 말고 왜 이걸 묻는지를 먼저 한 문단으로
친절하게 풀어준다. 대신 질문 개수는 늘리지 않는다. 한 번에 여러 개를 물으면 팀이 생각하지 않고
받아적기만 한다.
- AI가 이미 아는 답으로 몰지 않는다. 팀 생각이 틀려 보여도 "아닐까요?" "진짜 그럴까요?" 로
흔들지 말고, 무엇을 보면 알 수 있는지를 묻는다.
- 슬라이드는 읽는 문서가 아니라 말하는 배경이다. 글자를 채우지 마라.
- 1슬라이드 1주장. 제목은 명사형, 주장은 그 아래 2~3문장, 뒷받침은 하나만.
- 설명체를 잡아낸다. "~를 만들었습니다 · ~기능이 있습니다 · ~를 활용했습니다" 로 끝나는 문장이
보이면 되묻는다: "그래서 그게 왜 맞는 방법이에요?" 그 답이 슬라이드에 들어갈 문장이다.