발표용 덱(talk.html, 21장) 기준의 발화 스크립트. 슬라이드 문구는 개조식이지만 스크립트는 실제 발화용 구어체.
결론: 낭독만으로는 50분이 나오지 않음. 상호작용 블록을 포함해야 50분 구성 가능.
- 기준 발화 속도: 강의체 약 250음절/분 (뉴스 낭독 300~350음절/분보다 느리게 — 화면 가리키기·청중 반응 여백 포함)
- 초안 검증: 슬라이드 요지만 낭독하는 스크립트는 한글 약 4,700음절 ≈ 19분에 그침 → 낭독형 50분은 슬라이드 21장 대비 과잉 (장당 2.4분 낭독 필요, 청중 이탈 위험)
- 결론 구성: 슬라이드 발화 배정 37분 + 실습·시연 11.5분 + 여유 1.5분 = 50분
- 발화 배정 37분의 내역: 요지 낭독 약 20분(5,000음절) + 화면 지시·즉흥 부연·청중 확인 여백 약 17분 (배정 = 낭독의 약 1.9배 — 실강의 통상 배율)
- 리스크: 여백 없이 낭독만 하면 약 33분에 종료 → 리허설 실측으로 배정 조정 필수, 부족 시 확장 옵션은 4장 진행 메모 참조
- 실습 3개는 덱의 메시지("조작해야 생기는 배움")와 일치하는 구성 — 듣기만 하는 강의가 아니라 그 자리에서 1단계·3단계를 직접 밟게 함
50분을 Medina의 10분 규칙(주의력은 약 10분 주기로 급락 — 10분 단위로 나누고 각 단위 첫머리에 감정 훅)에 따라 5막으로 분할. 각 막은 개념 하나만 다루고, 막의 시작마다 훅을 배치.
| 막 | 시간 | 한 문장 컨셉 | 시작 훅 |
|---|---|---|---|
| 1막 왜 | 0:00 |
심사장 10초가 목적지 | 담백한 인사 → S3 '좋은 결과물' 기준 → S5 데모 팀 실화로 몰입 |
| 2막 사용자 | 8:00 |
김하늘을 알기 | "주인공 한 명을 소개합니다" — 인물 등장 |
| 3막 핵심 하나 | 19:00 |
한 줄기만 끝까지 | 마감 전날 밤 두 팀의 대비 장면 |
| 4막 만들기 | 26:30 |
계획과 사용자를 지키는 개발 | 프롬프트 두 개의 결과 비교(미니 리빌) |
| 5막 약속 | 36:30 |
계획서가 화면이 된다 | 데모 라이브 시연 = STAR 모먼트 |
적용한 기법과 근거:
- 스루라인 한 문장 — "사용자를 알고 만들었는가"를 로드맵(S4)·요약(S16)·클로징(S21)에 반복. 강연은 하나의 관통 아이디어로 수렴 (Chris Anderson, 『TED Talks』)
- 담백한 오프닝·클로징 — 당초 콜드 오픈(심사장 10초 상상)+데모 15초 티저로 '열린 고리'를 걸 계획이었으나, 반말 명령조가 건방지게 읽힌다는 판단으로 S1을 평범한 존댓말 인사로 교체. 이에 맞춰 S21 클로징도 심사장 콜백을 걷어내고 다섯 단계 요약+Q&A로 담백하게 정리. 초반 몰입은 S5 데모 팀 실화가 담당하고, 데모 티저는 복원하지 않음(시연은 S19 직후 그 자리에서 회수) (Anderson — 담백해도 하나의 관통 아이디어로 수렴)
- 청중이 주인공, 강사는 조력자 — 심사장 장면의 주어는 늘 "여러분". 데모 팀 사례(S5)는 자랑이 아니라 동행 증거로만 (Nancy Duarte, 『Resonate』 — audience as hero)
- 대비의 반복 — 현재(기능 욕심·겉도는 회의) ↔ 가능한 미래(끝까지 도는 한 줄기)를 본문에서 오감. 클로징은 극적 장면 대신 다섯 단계 요약으로 담백하게 닫음 (Duarte sparkline — what is ↔ what could be)
- STAR 모먼트 — 데모 라이브 시연(물이 차오르고 별점이 뜨는 순간)을 43:00 배치, 종료 직전 정점 후 Call to Action으로 마무리 (Duarte 『Resonate』 — Something They'll Always Remember + 두 번째 전환점 = Call to Action)
- 반복 등장인물 — "김하늘"(주최기관과 무관한 가상 인물, 고1 학생)을 S6에서 만들고 S9·S13·S21에서 재호출 (추상 원칙 대신 구체 인물로 기억 고정)
- 10분 간격 상호작용 — 실습 1(14:00)·실습 2(23:30)·시연(43:00)으로 주의 곡선 리셋 (Medina 10분 규칙과 일치)
- 강사 실제 화법 반영 — 발화 녹취 분석 기반: 결론 먼저 짧게, "근데/그니까/어쨌든"으로 잇기, 자기 얘기는 겸손하게(성과 나열 대신 "좀 오래 하긴 했어요" 식 완곡), 즉석 셈("30 더하기 25면 벌써 55점"), 비유는 말로만(나무와 숲·게임 세이브), 실제 어록 활용("중요한 건 계획을 완벽하게 세우는 게 아니라 지키는 것", "질문이 곧 돈")
리서치 출처: 세바시 스토리 공식(실패담 먼저 → 극복), Ken Robinson·Brené Brown 등 명강연의 대화체 오프닝·자기비하 유머. 단, 외국 강연 번역투는 배제하고 한국어 구어 관행(짧은 호흡·청중 호명·"-거든요/-잖아요/-더라고요" 종결·출처는 화면에)을 우선 적용.
발표 순서 변경 검토 결론: 슬라이드 순서는 그대로 두는 것이 맞음. 유일한 주의 저점(5막 초입 S17S18 심사·계획서, 37:3041:00)은 직후 시연이 정점으로 회복시키는 구조이며, 시연을 앞당기는 대안은 S19 대조표(계획서↔화면)의 증거라는 서사 의존성 때문에 기각. 시연의 사전 예고(1막 티저)는 복원하지 않기로 결정 — S1을 담백하게 유지하는 편을 택했고, 시연은 S19 직후 그 자리에서 자연스럽게 등장하므로 사전 예고 없이도 성립.
| 구간 | 내용 | 시간 | 누적 |
|---|---|---|---|
| S1 | 표지 — 오프닝 | 1:00 | 1:00 |
| S2 | 강사 소개 | 1:00 | 2:00 |
| S3 | 좋은 결과물 | 2:00 | 4:00 |
| S4 | 로드맵 | 1:30 | 5:30 |
| S5 | 저희 팀 사례 | 2:30 | 8:00 |
| S6 | 페르소나 | 2:30 | 10:30 |
| S7 | 지식의 저주 | 1:00 | 11:30 |
| S8 | 5명 인터뷰 | 2:00 | 13:30 |
| 실습 1 | 즉석 Mom Test (옆 사람과 2인 1조) | 5:00 | 18:30 |
| S9 | 문제 정의 (HMW) | 1:30 | 20:00 |
| S10 | 핵심 경험 | 2:30 | 22:30 |
| 실습 2 | 우리 팀 핵심 경험 한 문장 쓰기 | 3:00 | 25:30 |
| S11 | 체험 설계 점검 | 2:00 | 27:30 |
| S12 | 프롬프트 | 2:30 | 30:00 |
| S13 | 만들기 루프 | 1:30 | 31:30 |
| S14 | CLAUDE.md·GitHub | 2:30 | 34:00 |
| S15 | 동료 검증 | 1:30 | 35:30 |
| S16 | 요약 (바퀴) | 1:00 | 36:30 |
| S17 | 심사 기준 | 1:30 | 38:00 |
| S18 | 개발계획서 | 2:00 | 40:00 |
| S19 | 계획서 ↔ 데모 실물 | 2:00 | 42:00 |
| 시연 | 데모 라이브 플레이 (대비 → 폭우 → 결과) | 3:30 | 45:30 |
| S20 | 최종 제출물 체크리스트 | 1:00 | 46:30 |
| S21 | 마무리 | 1:00 | 47:30 |
| — | 여유 (전환·기기 문제 대비) | 2:30 | 50:00 |
Q&A는 50분 뒤 별도 진행(운영 일정에 따라 5~10분).
이 스크립트는 "다듬은 녹취록"입니다. 매끄러운 글이 아니라, 실제로 말할 때 나오는 텍스처를 일부러 남겼어요. "어 / 뭐 / 그 / 아니" 같은 군더더기, 말 고치기, 토막 문장이 들어 있는데 — 이거 지우지 말고 그냥 그 리듬대로 말하시면 됩니다. 대본 읽지 마세요. 눈으로 요지 보고 말로 푸는 용도예요.
왜 이렇게 썼는지 (리서치 근거): 사람 말이 AI 글이랑 다른 건 (1) 대칭 구문을 안 쓰고("A가 아니라 B" 같은 거), (2) 문장 길이가 들쭉날쭉하고(두 단어 토막 + 긴 횡설수설), (3) 매번 리듬이 다르고, (4) 군더더기·되돌아감·말 고침이 있어서예요. 그래서 일부러 안 매끄럽게 썼습니다. 출처(Freeman·NN/g 등)는 화면 각주에 있으니 입으로 읽지 마세요.
슬라이드 연결: 장마다 새로 시작하지 않고, 앞 장 끝을 받아서 "그래서 / 그럼 이제 / 근데 여기서 / 아 참" 같은 걸로 이어집니다. 끊지 말고 흐름 타세요.
종결 어투 (영욱님 실제 녹취 그대로): "몰라요"가 아니라 "모르겠어요", 단정보다 "-겠네요/-겠죠?"로 살짝 누그러뜨리기, 반말 "-지/-거지/-야지"는 존댓말에서 "-죠/-거예요/-야죠"로. 발표자가 실제로 쓰는 말끝이 있으면 그걸로 바꿔서 말하세요 — 여기 적힌 게 정답은 아니에요.
안녕하세요, 저는 서비스 개발 사전 강의를 맡은 김영욱이라고 합니다. 오늘은 크게 다섯 단계로 나눠서 서비스 개발 방법에 대해서 말씀드리려고 하고, 이번에 실제로도 저희가 데모를 만들면서 겪은 것들을 바탕으로 한번 이야기해보겠습니다. 시작하겠습니다.
제 소개는 화면에 적힌 대로 참고해주시면 될 것 같고, 넘어가도록 하겠습니다.
좋은 결과물이 뭐냐. 두 개예요. 하나는 끝까지 돌아가느냐. 또 하나는 사용자가 직접 만져보느냐. 이 둘이 다 있어야 돼요. 하나만 있으면 안 되고요. 아무리 멋있어도 안 돌아가면 소용없고, 반대로 잘 돌아가는데 그냥 읽기만 하는 거면 그것도 교육 콘텐츠로는 부족해요. 두 번째, 직접 만져야 배운다는 거. 이거 제 취향 얘기 아니에요. (화면 각주 가리키며) 연구가 꽤 있어요. 그냥 들은 거보다 직접 해본 게 오래 가거든요. 다들 아시잖아요 이거. 이 대회 배점 한번 봐요. 실현 가능성 30, 체험형 25. 위에 두 개가 딱 이거랑 같아요. 뭐, 우연은 아니겠죠.
그럼 이 두 개를 어떻게 만드냐. 순서가 있어요. 그래서 이래요. 사용자, 문제 정의, 핵심 경험, 개발, 검증. 이거 저희가 발명한 거 아니고요. 디자인 씽킹이라고 원래 있어요. 그거를 해커톤 맞게 좀 손본 거예요. 중요한 건, 단계마다 뭐가 하나씩 나와요 결과물이. 페르소나, 질문 한 문장, 핵심 경험 하나, 돌아가는 링크, 동료 테스트 기록. 이 다섯 개가 오늘 목차고, 여러분이 한 달 동안 만들 것들이에요. 단계 하나하나는 뭐 나무고. 근데 나무만 보면 안 되고 숲도 봐야 되잖아요. 오늘 그 숲이 아까 그 문장이에요. 사용자를 알고 만들었나.
근데 이게 말로만 들으면 좀 뜬구름이잖아요. 그래서 저희 얘기부터 할게요. 데모 만들 때 초반에 회의가 계속 겉돌았어요. 온실효과 하자, 재난 게임 하자, 예보관 체험 하자... 아이디어만 막 쌓이고 결론이 안 나. 이런 거 다들 겪어보셨죠. 근데 누가 그러더라고요. 주제 그만 얘기하고 타겟이랑 학습 목표부터 정하자고. 그거 정하니까, 신기하게 풀렸어요. 표에 있는 게 그때 그거예요. 타겟 정해지니까 주제 정해지고, 형식 정해지고, 데이터도 정해지고. 막 취향 싸움하던 게 그냥 착착 정해지더라고. ...근데 이거 미리 말씀드려요. 저희 팀 하나 겪은 거예요 이건. 무슨 법칙이다 그런 거 절대 아니고. 여러분 팀에서도 그런지는 오늘 밤에 직접 해보시라는 거예요.
자, 그래서 그 타겟을 어떻게 잡느냐. 그게 1단계, 사용자예요. 오늘 주인공 한 명 소개할게요. 왼쪽 봐요. "20에서 50대 일반 시민." 이렇게 잡으면요, 화면 하나를 못 만들어요. 아무것도 못 정해. 오른쪽. "김하늘, 지구과학 첫 학기 고1." 태풍 단원 막 배웠고, 태풍 예측이 왜 자꾸 바뀌는지 궁금하고, 교과서 설명만 봐서는 하나도 안 남는 학생이에요. 이 셋 중에 제일 중요한 게 목표고. 나머지 둘은 그 목표를 좀 선명하게 해주는 거예요. 아, 그리고 이거는 미리 말씀드리는데. 김하늘은 제가 지어낸 인물이에요. 여러분 기준은 계획서에 이미 적어낸 그 사용자고, 오늘 할 일은 그 사람을 이 수준까지 구체화하는 거예요. 근데 이걸 그냥 문서로 딱 만들어놓고 끝내면, 아무 소용 없어요. 회의하다 보면 이 기능 넣을까 말까 싸우잖아요. 그때 이렇게 물어봐요. "김하늘이 이거 보면 바로 알아?" 아니다 싶으면 빼요. 그게 끝이에요. 이 질문 하나가, 팀원들 각자 자기 맘대로 만드는 걸 딱 막아줘요.
근데 사용자 잡을 때 함정이 하나 있어요. "내가 써보면 되지 뭐." 안 돼요 이거. 이게 지식의 저주예요 — 화면 그대로, 한번 알면 모를 때가 기억이 안 나요. "이 정도면 다 알겠지" 싶을 때가 제일 위험해요. 그러니까 만들기 전에 물어봐야 돼요. 어떻게 물어보냐, 다음 장에서.
그래서 물어봐야 된다 그랬잖아요. 어떻게 물어보냐. 사용자 조사, 말은 거창한데 두 개만 알면 돼요. 첫째, 다섯 명이면 돼요. 무슨 대단한 표본 이런 거 필요 없어요. 다섯 명만 시켜봐도 큰 문제는 거의 다 나와요. 점심시간 한 번이면 되고, 옆 팀이 그냥 사용자예요. 둘째, 이게 중요한데. 물어보는 법이 있어요. "이런 기능 있으면 쓰실래요?" 이거 하지 마세요. 다 좋다 그래요. 예의상. 그거 믿고 만들면 큰일 나요. 대신 과거를 물어봐요. "날씨 때문에 곤란했던 적 언제였어요? 그때 어떻게 하셨어요?" 앞으로 어쩔 거냐 말고, 예전에 어땠냐. ...자, 말로 하면 안 와닿으니까 그냥 해볼게요 지금.
진행: 옆 사람과 2인 1조. 역할 정하기 30초 → 인터뷰 2분 → 역할 교대 2분 → 정리 30초.
"5분만 해볼게요. 옆 분이랑 짝 지으세요. 한 분이 먼저 물어보는 사람. 질문 두 개만 하면 돼요. '날씨 때문에 곤란했던 적, 언제였어요?' 그리고 '그때 어떻게 하셨어요?' 앞으로 어쩔 거냐, 그런 미래 질문은 하지 마시고. 2분 있다 바꿀게요. 자, 시작." (2분 후) "네, 바꾸세요." (2분 후) "자 그만. 방금 들은 것 중에, '어 이건 몰랐네' 싶은 거 하나라도 나온 분? ...그게 시작점이에요. 오늘 저녁에 다섯 명한테 그대로 물어보면, 1단계 끝이에요."
자, 방금 실습에서 뭐 하나씩 건졌죠. 그 불편한 거를 질문 한 문장으로 바꿔요. "어떻게 하면 ~할 수 있을까." 두 개만 지키면 돼요. 하나, 사용자랑 상황을 문장에 넣기 — 화면에 나쁜 예·좋은 예 있죠, 그 차이예요. 둘, 답을 미리 넣지 않기. "앱 만들자"는 이미 답이지 문제가 아니에요. 이 문장 하나 있으면, 나중에 기능 얘기 나올 때마다 걸러져요. "이게 이 질문에 답하는 기능이야?" 아니면 빼고.
질문까지 정했어요. 그럼 이제. 이게 오늘 제일 중요한 장이에요. 해커톤 왜 망하냐. 실력 없어서 아니에요. 기능 욕심 때문에 망해요. 화면 숫자는 그냥 예시고요. 일곱 개를 60%씩 만든 팀. 지도도 있고 퀴즈도 있고 다 있는데, 제대로 되는 게 하나도 없어요. 하나를 100% 만든 팀. 그 하나는 확실히 돌아가요. 이거 마감 전날 밤에 딱 갈려요. 일곱 개 팀은 뭐부터 고칠지 회의하고 있고. 한 개 팀은 그거 문구 다듬고 있고. 근데 여기서 '하나'가 화면 하나가 아니에요. 저희 데모로 예를 들면, 지형 고도 데이터에서, 물 차는 계산 거쳐서, 방재 배치까지. 이게 쭉 이어진 한 줄기. 이게 하나예요. 팀에서 이거 한번 물어보세요. "우리 사용자가 딱 하나만 경험한다면 뭘까." 그게 핵심이에요. 나머진 버려요. 버린 건 발표할 때 '다음 계획'에 쓰면 되고.
진행: 각자 메모 1분 → 팀 내 공유·합의 2분. (팀 착석이 아니면 개인 메모로 대체)
"방금 그 질문, 지금 바로 해봅시다. 1분 줄게요. 각자 적어봐요. '우리 사용자가 딱 하나만 경험한다면 뭘까.' 한 문장. (1분 후) 자, 이제 팀원끼리 보여주세요. ...다르죠? 서로. 그게 오늘 회의 안건이에요. 팀원마다 생각하는 핵심이 다르면, 그게 기능 일곱 개짜리 프로젝트 되는 거거든요."
자, 핵심 하나 정했으면. 이제 그걸 어떻게 체험으로 만드냐. 4단계, 체험 설계예요. 만져봐야 배워요. 방금 실습 생각해봐요. 제가 5분 떠든 거보다 직접 2분 해본 게 더 남았을걸요. 그냥 보기만 하는 차트, 영상. 그건 자료지 체험이 아니에요. 이건 무슨 방법론은 아니고요, 제가 데모 만들면서 쓴 점검 목록인데. 세 군데만 봐요. 첫 화면 — 10초 안에 뭘 눌러야 될지 보여요? 화면 안 — 직접 만지는 데가 있어요? 끝난 뒤 — 뭘 배웠는지 남아요? 밑에 실패 신호 그대로 쓰시면 되고. 설명문부터 주르륵 나오면 실패. 손댈 데가 없으면 그건 자료고. "그래서 내가 뭘 배운 거지?" 하고 끝나면 그것도 실패예요.
체험 설계까지 됐으면, 이제 진짜 만들어야죠. 개발. 프롬프트에 사용자부터 넣어요. 왼쪽처럼 "태풍 정보 웹페이지 만들어줘." 이러면 어디서 본 것 같은 게 나와요. 오른쪽 봐요. 사용자가 누군지, 뭘 알고 뭘 모르는지, 뭘 하게 할지가 다 들어 있어요. 1단계부터 3단계까지 만든 게 그대로 재료가 되는 거예요. 제가 자주 하는 말인데. 질문이 곧 돈이에요. 대충 물어보면, 토큰 쓰고, 이상한 거 받고, 또 물어보고. 그게 다 돈이거든요. 한 번에 제대로 묻는 게 제일 싸요. 근데 솔직히 말하면, 이게 얼마나 효과 있는지는 저도 잘 모르겠어요. 연구도 아직 갈리고. 그러니까 제 말 믿지 말고, 두 개 다 던져보세요. 5분이면 알아요, 여러분 과제에서 차이 나는지.
프롬프트 넣고 나면, 그다음은 반복이에요. 만들 때는 세 박자. 작게 시키고, 사용자 눈으로 보고, 구체적으로 고친다. "전부 다 만들어줘." 이건 디버깅 지옥이에요. 고쳐달랄 때도. "더 좋게 해줘" 이러지 말고. "학생은 앙상블이란 말을 몰라, 버튼 옆에 설명 한 줄 붙여줘." 이렇게. 계속 기준이 사용자인 거예요. 그리고 배포 자주 하세요. 내 노트북에서 되는 거랑, 심사위원이 링크 열었을 때 되는 거. 이거 완전 다른 얘기예요.
아 참, 근데 만들기 시작하기 전에. 세팅 두 개만 더 알려드릴게요. 10분이면 돼요. 하나, CLAUDE.md라는 파일. 프로젝트 폴더에 넣어두면요, AI가 대화 시작할 때마다 이걸 먼저 읽어요. 일종의 규칙 파일이에요. 화면에 있는 거, 이거 제가 지어낸 예시 아니에요. 저희 데모에 진짜 들어 있는 파일이에요. 계획서부터 읽어라, 계획이랑 달라지면 계획서부터 고쳐라, API 키는 코드에 넣지 마라. 이렇게 적어두면, 매번 설명 안 해도 되고. AI가 딴 길로 안 새요. 이거 참가자용 템플릿으로 드릴 거예요. 둘, 이건 시간 되면. GitHub. 커밋해두면, 뭐 망가져도 잘 되던 데로 돌아가요. 게임에서 세이브 하는 거랑 똑같아요. 명령어 몰라도 돼요. AI한테 "커밋해줘" 하면 되니까. 근데 이 장에서 진짜 하고 싶은 말은. 코딩 잘하고 못하고 차이, 이런 세팅이 많이 줄여줘요. AI가 코드 쓰는 동안, 사람이 할 일은 사용자랑 계획 지키는 거예요. 이건 전공 상관없어요. 누구나 해요.
자, 그렇게 다 만들었어요. 이제 마지막. 5단계, 검증이에요. 심사장에서는 여러분이 옆에서 설명을 못 해줘요. 그러니까 미리 연습을 해보는 거예요. 규칙 세 개. 하나, 설명하지 마세요. 링크만 줘요. 설명하고 싶어서 입 근질거리는 데. 거기가 고칠 데예요. 둘, 5분 그냥 봐요. 어디서 멈추고 어디서 헤매는지. 셋, 끝나고 딱 한마디만 물어봐요. "뭐 배웠어요?" 이 대답 들어보면 알아요. 전달이 됐는지 안 됐는지. 고치고, 또 5분 시켜보고. 이 반복이 다예요.
그래서 이 다섯 단계가요. 한 번 쭉 하고 끝나는 거 아니에요. 바퀴예요 이게. 검증하다 나온 게 다시 사용자 이해로 돌아가거든요. 사전개발이 7월 23일부터 8월 20일까지. 한 달이에요. 이 바퀴 여러 번 돌릴 수 있는 시간이에요. 크게 한 바퀴 도는 거보다, 작게 여러 번 도는 게 낫죠. 그니까 나무만 보지 말고요. 이 바퀴가 도는 축, 그게 숲이에요. 사용자를 알고 만들었나.
그리고 이 순서가, 심사 기준이랑도 딱 붙어요. 공고에 다섯 항목 있어요. 실현 가능성 30점, 이건 3단계에서 5단계. 체험형 25점은 4단계고. 이 둘만 더하면... 30 더하기 25니까 55점이죠. 벌써 절반 넘어요. 나머지 주제, 독창성, 학습 효과도 다 이 단계들에 걸려 있고. 그러니까 심사 대비를 따로 안 해도 돼요. 순서대로 하면 그냥 채워져요.
근데 심사에서 하나 더 챙길 게 있어요. 이건 진짜 하고 싶은 얘긴데. 서류 때 낸 개발계획서. 그거 내고 끝나는 문서 아니에요. 본선에서 결과물이랑 나란히 놓고 맞춰봐요. 공고에 실현 가능성 4요소가 있는데, 그게 그대로 체크리스트예요. 적은 기능이 진짜 돌아가나, 데이터가 화면까지 이어지나, 핵심 기능 하나가 100% 됐나, 적어놓은 기술 스택 그대로 했나. 제가 평소에 하는 말이 있는데. 중요한 건 계획을 완벽하게 세우는 게 아니라, 지키는 거예요. 이 중에 딱 하나만 꼽으라면. 기능 하나라도 완성하세요. 계획서에 적은 그 핵심 기능 하나가, 심사위원 링크에서 끝까지 돌아가는 거. 그게 최우선이에요. 그리고 이거 하나만 더. 계획서는 이미 제출돼서 확정된 문서예요. 지금 고칠 수 있는 게 아니에요. 그러니까 스택이든 기능이든 계획이랑 다르게 가는 거는요, 실현 가능성 점수에서 불이익을 감수하겠다는 선택이에요. 하지 말라는 게 아니라, 그걸 알고 결정하시라는 거예요.
그래서 말로만 하면 좀 붕 뜨잖아요. 저희 걸로 맞춰볼게요. 아 먼저, 이 데모는 저희 운영진이 만든 예시고, 본선 팀 아이디어랑은 상관없어요. 교육 효과부터. 계획서에 시간 제한 없애고, 점수 대신 별점 주고, 예산은 학습용 제약으로 쓴다고 적었어요. 화면에 그대로 있죠. 로직. 계획서에 침수 판정이 딱 한 줄 있어요. 고도에 시설 높이 더한 게 물 높이보다 낮으면 잠긴다. 이 한 줄이, 진짜 지형 데이터를 게임 엔진으로 만들어요. 디자인. 지형색이랑 위험색 나누는 거, 이건 됐고. 색약 아이콘은 계획엔 있는데 아직 못 했어요. 못 한 건 못 했다고 적어놨어요. 그것까지가 계획서 지키는 거예요. 자, 직접 볼게요.
진행: 데모 URL 접속 → 대비 단계에서 시설 2~3개 배치(모래주머니·저류조) → 폭우 시작 → 침수 결과·별점 확인. 사전 점검: 현장 네트워크 불안 대비 화면 녹화본 준비.
"이게 방금 그 표의 실물이에요. 색깔이 고도예요. 파란 데가 낮은 데, 위험한 데고. 여기 낮은 집에 모래주머니 하나 놓을게요. 봐요, 예산 줄죠. 이게 아까 말한 학습용 제약이에요. 자, 비 내릴게요. 물 차오르면서, 대비 안 한 집은 잠기고, 별점 나오고. 방금 제가 누른 거 하나하나가, 계획서 문장 하나하나예요. 여러분 것도 이렇게 계획서랑 화면이 딱 맞아떨어지면 돼요."
자, 방금 본 게 잘된 예예요. 그럼 여러분은. 제출 전에 이거 한번 봐요. 사용자 한 문장, 질문 한 문장, 핵심 경험 하나에 버린 기능 목록, 프롬프트에 페르소나, 그리고 팀 밖 사람 한 명이 설명 없이 끝까지 써봤나. 이 다섯 개가 오늘 다섯 단계랑 하나씩 짝이에요. 제출 전날 밤에, 이 장만 다시 열어보세요.
끝내며 정리해보면, 좋은 결과물은 결국 2가지라고 생각합니다. 처음부터 끝까지 제대로 동작하는 것, 그리고 사용자가 직접 경험할 수 있는 것. 그걸 만드는 순서가 오늘 말씀드린 다섯 단계이고, 여기에서 마무리하도록 하겠습니다. 혹시 궁금한 점 있으시면 질문 받겠습니다. 감사합니다.
- S5·S19·시연에서 데모 언급 시 "운영진 예시, 본선 팀과 무관" 문구 누락 금지
- 실습 1·2는 타이머를 화면이나 휴대폰으로 공개 표시 (초과 방지)
- 시연은 네트워크 불안 대비 화면 녹화본 백업 필수, 실패 시 녹화본으로 즉시 전환
- 시간 초과 시 축소 순서: 실습 2(3분) → 시연을 녹화본 1분 요약으로 → S16
- 시간 여유 시 확장(순서대로): ① 실습 1 발견 공유 1~2명 발표 ② 시연에서 청중 1명에게 시설 배치 맡기기 ③ Q&A 앞당겨 시작
- Q&A는 50분 종료 후 별도 (운영 일정 5~10분)
- S21 클로징 콜백 재작성 (완료): 옛 S1 콜드 오픈을 콜백하던 결말을, 담백한 다섯 단계 요약+Q&A 마무리로 교체함. 심사장 장면 콜백·'곱하기' 표현 제거.
- 시연 사전 예고(열린 고리) 복원 여부 (결정: 복원 안 함): S1을 담백하게 유지하기로 한 결정에 맞춰 티저는 되살리지 않음. 시연은 S19(계획서↔데모 대조) 직후 그 자리에서 등장하므로 사전 예고 없이도 성립.
- STEP 1·2 시간 압축 (완료, 부록 방식): S6
S9(+실습1) 블록 13:00 vs S11S15 블록 10:00 — 이미 개발계획서에 제출된 사용자·문제 정의를 '검증'하는 STEP 1·2가 '새로 정하는' STEP 4보다 길다는 지적(ywkim 리뷰, 검증됨). ywkim 제안(이슈 #6, 5033229464)대로 삭제 대신 "부록 방식" 적용 — S7·S9은 화면(index.html·talk.html)에 이미 결론·예시가 카드/각주로 떠 있으므로, 라이브 구술에서 화면과 겹치는 부연만 덜어냈다(S7 1:30→1:00, S9 2:00→1:30, 합계 −1:00). 화면 콘텐츠는 그대로라 별도 부록 슬라이드는 추가하지 않음 — 정보 손실 없이 구술만 압축. STEP 1·2 블록은 13:00→12:00, STEP 4(S11~S15) 10:00과의 격차는 3:00→2:00으로 줄었으나 완전히 역전되진 않음(남은 과제로 열어둠). 절약된 1:00은 여유(1:30→2:30)로 흡수, 총합 50:00 유지.