앱기획 챕터(F1~F7)의 마무리. 만든 것을 '어떻게 보여줘야 사람을 끄는가'를 6단계 논증으로 풀고, 마지막에 F1~F8 전체 여정을 회수합니다. 강사가 읽고 그대로 말할 수 있는 설명 산문 중심. 슬라이드 높이는 가변(최소 16:9).
이 장은 발표 팁을 흩어 나열한 게 아니라 한 질문을 끝까지 따라가는 하나의 논증이다. 본론에 들어가기 전, 우리가 지나갈 길을 먼저 펼친다. 윗줄은 '발표를 어떻게 짜야 하는가'를 6단계로 논증하고, 아랫줄은 그 결론을 실제 발표 카드 만들기와 F1~F8 전체 회수로 잇는다.
힘들게 앱을 만든 학생일수록 발표 때 모든 기능을 빠짐없이 보여주고 싶어 한다. 로그인도, 알림도, 메뉴 다섯 개도 전부 클릭해 가며 "이것도 돼요, 이것도 돼요"를 늘어놓는다. 기능이 많을수록 잘한 발표라고 믿는 것이다. 이 통념을 깨는 데서 발표 수업이 시작된다.
기능 목록이 줄줄이 흐르는 동안 청중은 끝까지 "그래서 무슨 문제를 푸는 건데?"를 모른다. 다 보여주려다 시간을 다 쓰면 정작 왜 만들었는지·무엇을 배웠는지가 묻힌다 — 인상은 흐려지고 박수는 식는다.
이 장이 증명하려는 한 문장은 이것이다 — 좋은 발표는 '영화 예고편' 같다. 예고편은 영화의 모든 장면을 보여주지 않는다. 2~3분 안에 ①어떤 긴장이 있었고 ②어떻게 풀렸으며 ③무엇이 남는지만 압축해 보여주고, 그것만으로 사람을 극장으로 끈다. 발표도 똑같다. 기능의 나열이 아니라 문제→해결→배운 점이라는 이야기의 흐름으로 짠다.
"이것도 되고, 저것도 되고…" — 만든 사람 입장에서 가진 것을 죽 늘어놓는다. 청중에게는 남는 장면이 없다. 평평하고 기억에 안 남는다.
"누가 어떤 불편을 겪었고(긴장) → 이렇게 풀었고(시연) → 무엇을 깨달았나(여운)." 청중 입장의 한 장면으로 흐른다. 감정이 실려 기억에 남는다.
이야기가 더 잘 통하는 건 말솜씨가 아니라 인간의 작동 방식 때문이다. 사람은 "메타포로 생각하고 이야기로 배우는" 종이다. 표·기능 목록 같은 정보는 평평하고 생기가 없다가, 누군가의 이야기로 바뀌는 순간 공감이 일어난다. '정보를 아는 것'과 '사람의 처지를 느끼는 것'은 다르고, 마음을 움직이는 건 후자다.
이야기엔 겪는 사람이 있어야 한다. "13살 지민이는 아침마다…"처럼 한 사람의 장면으로 열면 추상적인 '사용자'가 구체적이고 공감되는 대상이 된다. 숫자보다 한 사람이 먼저다.
지금의 답답함(긴장)과 바라는 모습(해소) 사이의 간격이 이야기를 끈다. 이 곡선이 있어야 청중이 "그래서 어떻게 됐어?" 하며 끝까지 따라온다.
'이야기로 짜라'는 추상적인 말을 실제로 손에 쥘 수 있는 틀로 떨군 것이 3슬롯이다. 발표를 세 칸으로 나누고 각 칸에 1분이라는 시간을 못박는다. 시간 칸이 정해져 있어야 한 슬롯에 시간을 다 써버리는 사고를 막고, 학생이 자연스럽게 핵심만 추리게 된다.
누가 어떤 불편을 겪었나. "○○살 △△는 매일…" 한 사람의 장면으로 연다. 여기서 청중을 이야기 안으로 끌어들인다.
앱을 보여주며 그 문제를 푸는 핵심 기능 '하나'만 실제로 눌러 보인다. 나머지는 말로 한 줄. 보여줄수록 흐려진다.
무엇을 고쳤고 무엇을 깨달았나. "가장 고치기 힘들었던 것"을 꼭 한 가지 넣는다. 여운이 남는 자리.
"기능이 많은데 하나만 보여주면 아깝다"는 반론은 자연스럽다. 하지만 발표의 목적은 '내가 가진 걸 다 증명하는 것'이 아니라 '청중의 마음에 한 장면을 남기는 것'이다. 이 관점에서 보면 두 가지 직관을 뒤집어야 한다 — 시연은 하나만, 그리고 실패도 자랑거리다.
'우리 앱을 한 줄로 말하면?'에 해당하는 그 기능 하나만 실제로 눌러 보인다. 모든 화면을 클릭하다 시간을 넘기면 ①문제·③배운 점이 묻혀 인상이 흐려진다. 적게 보여주는 게 더 또렷하다.
"처음엔 이게 안 됐는데 이렇게 고쳤어요"가 가장 인상적이다. 발표는 완성품 자랑이 아니라 '고생담 한 편'이다. "가장 고치기 힘들었던 것" 한 가지가 오히려 더 큰 박수를 받는다.
지금까지의 논증을 한 장면으로 합치면 이렇다 — 발표의 첫 문장은 통계도 기능도 아닌 "○○살 △△는 매일…"이라는 한 사람의 이야기여야 한다. 아래 두 예가 같은 앱을 발표하는 정반대 방식이다. 무엇이 청중을 끄는지 직접 비교해 보라.
"우리 앱은 로그인도 되고, 알림도 있고, 메뉴가 다섯 개고, 색도 예쁘고, 버튼도 많아요."
→ 기능 목록만 줄줄이라 청중이 '그래서 무슨 문제를 푸는 건데?'를 끝까지 모른다.
"13살 지민이는 아침마다 급식을 몰라 헛걸음했어요(문제). 그래서 첫 화면에 오늘 메뉴만 크게 띄웠죠(시연). 처음엔 글씨가 작아 친구가 못 봤는데, 두 배로 키우니 3초 만에 확인하더라고요(배운 점)."
→ 문제→해결→깨달음이 한 사람의 이야기로 흐른다.
발표를 잘하는 비결은 말솜씨가 아니라 준비된 구조다. 이야기를 머리로만 갖고 있으면 무대에서 흩어진다. 그래서 발표 전에 이야기를 손에 잡히는 카드 3장으로 옮긴다 — 각 카드에 2~3문장만. 분량 제한이 핵심이다(슬라이드 빼곡 금지). 특히 1번 카드 첫 문장을 "○○살 △△는 매일…" 형식의 한 사람 이야기로 쓴다.
누가 어떤 불편을 겪었나. 첫 문장 = 한 사람 이야기.
예: "13살 지민이는 아침마다 급식을 몰라 헛걸음했다."
핵심 기능 하나를 어떻게 눌러 보일지.
예: "첫 화면에서 '오늘 급식'을 3초 만에 확인하는 장면."
무엇을 고쳤나 + 가장 힘들었던 것 한 가지.
예: "글씨가 작아 안 보였는데, 두 배로 키우니 해결됐다."
이 챕터에서 손으로 쓴 카드 3장은 추상적 연습이 아니라, 교실 도구 sprint의 Step8 발표 단계에 그대로 들어맞는다. sprint Step8은 발표를 3슬롯(문제·시연·배운 점)으로 구성하고, 모둠원에게 역할을 배정하며, 화면에 띄우는 발표 모드까지 제공한다 — 즉 F8에서 배운 구조가 바로 작동하는 무대다.
발표(F8)는 따로 떨어진 기술이 아니라, 앱기획 전체가 도착하는 출구다. 우리가 F1에서 사용자의 불편(문제)을 찾는 데서 출발했기에, F8의 발표도 그 '문제'로 다시 연다. 앱기획은 처음부터 끝까지 한 사람의 불편을 풀어 가는 하나의 이야기였던 셈이다.