24 tips for giving S-tier demos — 엔지니어를 위한 데모 가이드
24 tips for giving S-tier demos — 풀 분석
작성자: Jina Yoon (PostHog) 게재일: 2026년 5월 29일 출처: Product for Engineers 뉴스레터 (PostHog)
이 글이 나온 배경
작자는 PostHog에서 지난주에 열린 오프사이트 해커톤에서 50개 이상의 데모를 연속으로 관람했습니다. 그렇게 많은 데모를 подряд 보면 어떤 패턴이 반복되는지 명확히 보입니다. 이 글은 그중에서 S등급(최고 수준) 데모를 나머지와 구분했던 공통점을 24개로 정리한 것입니다.
핵심 주장: "좋은 데모는 프로젝트가 출시될지 중단될지, 스타트업이 투자를 받을지 그렇지 않을지를 가르는 결정적 요인이다."
---
1. 기본 구조 (The basic structure)
팁 1: 사람들이 기억하게 하고 싶은 핵심 포인트 하나만 정하세요
데모 전체를 하나의 중심 메시지 주변에 배치합니다. 보통 "우리가 해결하는 문제"와 "그걸 어떻게 해결하는지"가 그 중심이 됩니다. 여러 가지를 동시에 강조하면 청중은 아무것도 기억하지 못합니다.
팁 2: 핵심 포인트에 가능한 빨리 도달하세요
아이디어가 어떻게 탄생했는지 긴 스토리를 펼칠 필요가 없습니다. 맥락이 필요하다면 1~2문장으로 끝내세요. 청중은 배경 이야기보다 결과물을 보고 싶어 합니다.
팁 3: 데모를 '기능 나열'이 아니라 '피치'로 다뤄야 합니다
목적은 "내가 만든 멋진 걸 보여줘야지"가 아니라 "사람들이 이걸 좋아하게 만들어야지"입니다. 제품 안내 영상처럼 기능 하나하나를 설명하는 게 아니라, 청중에게 설득하고 열정을 전하는 피치의 마인드로 접근해야 합니다.
팁 4: 즉시 행동할 수 있는 것으로 끝내세요
마지막 슬라이드에 QR 코드를 넣거나, 기여자를 모집하거나, 청중이 바로 참여할 수 있는 방법을 제시하세요.
실제 사례: PostHog을 어떤 메신저 앱에서도 사용할 수 있게 만든 팀은 마지막 슬라이드에 전화번호를 올렸습니다. 작자는 바로 그 번호로 문자를 보냈다고 합니다.
또 다른 사례: MCP Analytics 팀은 데모를 하기 전에 이미 프로젝트가 PostHog 사용자의 25%에게 롤아웃되었다고 발표했습니다. 데모를 하러 왔는데 이미 출시된 걸 보면 "와우"라는 반응이 자연스럽게 나옵니다. 실제 사용자 데이터가 흐르는 걸 보여주면 설득력이 완전히 달라집니다.
---
2. 스토리텔링 전술 (Storytelling tactics)
팁 5: 모두 공감하는 고통부터 시작하세요
청중이 "나도 그래"라고 고개를 끄덕일 만한 문제부터 시작합니다.
실제 사례: 디자이너 두 명이 일러스트를 자동으로 태그하고 색인하는 웹 앱을 만들었습니다. 데모를 시작하며 "혼란스러운 Figma 파일에서 특정 hedgehog(고슴도치) 일러스트를 못 찾은 적 있는 사람?"이라고 물었습니다. 모든 디자이너가 손을 들었습니다. 바로 그 순간 청중은 "이 사람들은 우리의 문제를 알고 있다"고 느꼈습니다.
팁 6: 낯선 개념을 설명할 때 익숙한 것에 빌려오세요
새로운 아이디어를 설명할 때, 사람들이 이미 알고 있는 개념에 비유하면 이해도가 확 올라갑니다.
실제 사례: 한 팀이 PostHog Code 안에 Claude Cowork 같은 기능을 만들어봤습니다. 프로젝트 이름을 "PostHog Work"라고 붙였습니다. Claude Cowork를 알고 있는 사람에게는 "아, 그거 PostHog 버전이구나"라고 바로 이해가 됩니다.
팁 7: 전용 데모 앱을 만들어서 보여주세요
특히 개발 도구를 데모할 때 중요합니다. 도구 자체만 보여주면 "이게 뭐지?"라고 생각할 수 있지만, 그 도구를 실제 앱에 적용한 걸 보여주면 "아, 이럴 때 쓰는 거구나"하고 이해가 됩니다.
실제 사례: UI를 자동으로 테스트하는 에이전트 도구를 만든 팀이 "OnlyHogs"라는 가짜 앱을 만들어서 그 위에서 도구가 어떻게 작동하는지 보여줬습니다. 아이디어가 확 클릭되는 순간이었습니다. (작자는 확인해봤는데 진짜 가짜 앱이었다고 합니다)
팁 8: 청중을 2인칭 '당신'의 관점으로 넣으세요
"우리가 지원 티켓을 관리하는 앱을 만들었어요"라고 말하는 대신, "당신이 당직 중이고 동시에 6개의 사고를 처리해야 하는 상황 상상해보세요"라고 시작합니다. 청중을 주인공으로 만들어서 이야기를 듣게 합니다.
팁 9: 대안과 비교해서 보여주세요
현재의 아픈 워크플로우를 6단계로 보여준 다음, 너희 솔루션이 1단계로 줄인 걸 나란히 비교하세요. 비교가 있어야 청중이 "이게 얼마나 나은 건지"를 느낄 수 있습니다. 비교가 없으면 청중은 "그래서 뭐가 좋은 거야?"라는 질문을 하게 됩니다.
팁 10: 어떻게 만들었는지는 나중에 알려주세요
마술사가 비법을 먼저 밝히지 않는 것처럼, 데모 초반에 기술적 구현을 설명하지 마세요. "우리는 X 프레임워크와 Y 알고리즘을 썼습니다" 같은 설명은 청중의 흥미를 떨어뜨립니다. 대신 블로그 글이나 영상 링크를 마지막에 제시해서 "더 알고 싶으면 여기 보세요"라고 유도하세요.
---
3. 준비와 전달 (Setup and delivery)
팁 11: 에너지를 높게 가져가세요
작자는 Steve Ballmer(전 마이크로소프트 CEO로 유명하게 에너지 넘치는 연설을 한 사람)를 언급했습니다. 좋은 데모의 절반은 내용이고另一半는 전달하는 사람의 에너지입니다. 무精打采하게 하면 내용 자체가 좋아도 지루해 보입니다.
팁 12: 사과하지 마세요
"죄송합니다, 아직 조잡한 부분이 있어요"라고 시작하면 청중은 "그래, 기대하지 말아야겠다"라고 마음을 준비합니다. 아직 보여주기 전에 기대치를 낮추는 건 최악의 전략입니다. 그냥 시작하세요.
팁 13: 끝났다는 걸 명확하게 알리세요
데모가 끝났는데 사람들이 박수 칠지 말지 모르는 그 어색한 순간을 피하세요. 마무리 문장을 명확하게 하거나, 목소리 톤을 낮추거나, 마지막에 축하하는 시각 효과를 넣으세요.
팁 14: 데모 신을 달래세요 — 체크리스트
PostHog에서 실제로 사용하는 데모 준비 체크리스트입니다:
- 데모 전용 프로젝트를 쓰고, 고객 데이터가 있는 라이브 계정은 쓰지 않기
- 노트북 알림 끄기
- 휴대폰 무음
- 데모 URL을 북마크하고, 현장에서 직접 타이핑하지 않기
- 와이파이 끊겼을 때 대비한 스크린샷 준비
- 브라우저 확대를 125~150%로 해서 뒷줄도 읽을 수 있게 하기
- 프로젝터 먼저 테스트하기
팁 15: 가능한 한 실제 데이터를 사용하세요
가짜 데이터는 한심해 보입니다.
실제 사례: 해커톤을 대여해주는 서비스 개념을 만든 HogNet 팀이 실제 가격표와 배송 로지스틱이 있는 웹사이트를 만들었습니다. lorem ipsum으로 채운 것보다 훨씬 현실적으로 느껴졌습니다.
팁 16: 미리 로드하고 캐싱하세요
TV 요리 프로그램에서 요리사가 재료를 미리 준비해두는 것처럼, 데모에서도 기다리는 시간을 없애야 합니다. 에이전트 응답, 긴 쿼리, 느린 빌드 같은 부분에서 청중이 "로딩 중…"을 지켜보게 하면 흥미가 떨어집니다. 가능한 한 미리 준비해두세요.
팁 17: 소리 내서 최소 한 번은 연습하세요
머릿속으로 생각하는 건 연습이 아닙니다. 실제로 목소리를 내면서 해봐야 말문이 막히는 부분이 어디인지 알게 됩니다. 자신감도 붙고 자연스러운 전달이 됩니다.
팁 18: 완벽주의에 데모를 멈추지 마세요
PostHog에서는 프로젝트가 어떤 상태이든 모든 팀이 데모를 합니다. 데모는 완성된 작업이 아니라 진행 중인 작업을 공유하는 자리입니다. "아직 덜 되었으니 다음 번에 하자"라고 미루면 기회 자체가 사라집니다.
---
4. 재미있게 (Make it fun)
팁 19: 코드만 보여주지 마세요
프로젝트에 UI가 없더라도 시각화를 건너뛸 이유는 없습니다. 아키텍처 다이어그램도 몇 초 만에 생성할 수 있는 시대입니다. 코드 스크린샷만 보여주는 건 청중이 따라오기 어렵습니다.
팁 20: 슬라이드만 보여주지도 마세요
슬라이드만 보여주는 건 데모가 아닙니다. 아이디어는 누구나 말할 수 있지만, 데모의 본질은 "만들어서 보여준다"는 점입니다. 실제로 동작하는 걸 보여주세요.
팁 21: 기본 화면 녹화 도구는 부족합니다
Screen Studio 같은 앱을 사용하면 줌인/줌아웃과 애니메이션을 추가해서 "지금 어디를 보고 있는지"가 명확해집니다. 기본 기록 도구로 찍은 영상은 지루합니다.
팁 22: 시각화가 예쁠 필요는 없지만, 중요한 걸 강조해야 합니다
예쁜 그래픽보다 "지금 이게 왜 중요한지"를 알려주는 콜아웃이 더 중요합니다. 간단한 그래픽이라도 유용한 정보를 제공하면 충분합니다.
팁 23: 오디오는 과소평가됩니다
소리를 활용하면 완전히 다른 차원의 데모가 됩니다.
실제 사례: 한 팀은 해적노래(sea shanty) 보이스오버를 만들었습니다. 다른 팀은 AI 기반 사용자 연구 도구를 데모했는데, 데모 자체가 완전히 오디오 전용으로 구성되었습니다. 시각만 의존하지 않는 접근이 기억에 남습니다.
팁 24: 이상한 걸 더 해보세요
누구도 Dylan이 파이나콜라 마시는 영상을 넣라고 하지 않았습니다. PostHog Code 모바일 앱 팀이 그냥 넣었는데, 그게 작자가 가장 기억에 남는 데모가 되었습니다. 🍹
예측 가능한 데모는 잊힙니다. 예측 불가능한 요소를 하나라도 넣으면 사람들이 "저 데모 뭐였지?"라고 기억하게 됩니다.
---
커뮤니티 반응
이 글은 PostHog의 Substack 뉴스레터에 게시되어 52개의 추천과 3개의 댓글을 받았습니다. X(트위터)에서도 PostHog 공식 계정이 이 글을 소개했습니다.
해커톤 데모 관련 글은 Reddit r/programming이나 r/salesengineers에서도 꾸준히 논의되는 주제입니다. 공통적으로 "스토리텔링", "실제 데이터", "대안 비교"가 좋은 데모의 핵심 요소로 꼽힙니다. 이 글이 특별히 다른 점은 50개 이상의 실제 데모를 직접 관찰한 경험에서 나온 구체적인 사례들이 풍부하다는 것입니다.
---
새로운 시각
이 글에서 다루지 않았지만 중요한 관점 3가지를 추가합니다.
1. 데모는 제품이 아니라 영화다
글에서 암시하지만 명확히 말하지 않은 부분입니다. 데모는 제품의 모든 기능을 보여주는 게 아닙니다. 영화가 2시간 안에 하나의 이야기를 전달하듯, 데모도 청중에게 하나의 '경험'을 설계하는 일입니다. 감독이 불필요한 장면을 자르듯, 데모도 핵심 메시지를 방해하는 부분은 과감히 빼야 합니다.
2. "사과하지 마라"의 반대편 — "과장도 하지 마라"
이 글은 사과의 위험만 강조합니다. 하지만 실제로 더 흔하고 더 위험한 실수는 아직 안 되는 기능을 되는 것처럼 포장하는 것입니다. 데모 중에 거짓이 발각되면 신뢰가 영구적으로 손상됩니다. "이 부분은 아직 구현 중입니다"라고 솔직히 말하는 게 장기적으로 더 신뢰를 만듭니다.
3. 가장 중요한 전제: 청중을 알라
24개 팁 모두 '누구에게' 보여주는지에 따라 적용도가 완전히 달라집니다. 투자자에게는 비즈니스 가치와 시장 규모가 핵심이고, 동료 개발자에게는 기술적 혁신이 핵심이고, 최종 사용자에게는 실제 사용 경험이 핵심입니다. 이 전제를 먼저 정하고 팁을 선택해야 합니다.
---
자녀와 미래에 대한 시사점
세 아이에게 적용할 수 있는 교훈:
발표는 기술이다
프로그래밍처럼 연습하면 나아지는 기술입니다. "나는 발표가 안 된다"는 말은 "나는 코딩을 안 한다"랑 똑같은 말입니다. 연습 안 했기 때문에 안 되는 것이지, 타고난 재능이 없는 게 아닙니다.
한 문장으로 요약할 수 있어야 한다
학교 발표 때도 적용됩니다. 10페이지짜리 발표문을 만드는 것보다 "오늘 기억해줬으면 하는 한 문장"을 먼저 정하는 게 훨씬 효과적입니다. 그 한 문장을 중심으로 나머지 내용을 배치합니다.
예상 밖의 요소를 하나 넣으세요
진지하게만 준비하는 발표는 잊힙니다. 청중이 웃거나 놀랄 요소를 하나라도 넣으세요. 기억에 남는 발표는 항상 '예상 밖'의 무언가를 포함합니다.
소리 내서 연습하는 게 진짜 연습이다
머릿속으로 생각하는 건 연습이 아닙니다. 실제로 목소리를 내면서 해봐야 말문이 막히는 부분이 어디인지, 시간이 얼마나 걸리는지 알게 됩니다.