💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며 — 왜 지금 데모인가

최근 PostHog 뉴스레터의 "How to demo" 글이 Hacker News와 GeekNews에서 크게 화제가 됐습니다. 요지는 단순합니다. "좋은 제품을 만드는 능력과 좋은 데모를 하는 능력은 별개이고, 후자가 없으면 전자는 세상에 존재하지 않는 것과 같다"는 것입니다.

이 글이 특히 2026년에 공감을 얻은 데는 이유가 있습니다. AI 코딩 에이전트가 보편화되면서 "만드는 것" 자체의 비용이 급격히 낮아졌습니다. Claude Code나 Codex 같은 도구로 주말 사이에 프로토타입을 만드는 일이 흔해졌고, 사내 해커톤이나 demo day에 올라오는 결과물의 수는 몇 배로 늘었습니다. 결과물이 흔해질수록 희소해지는 것은 "이게 왜 중요한지 3분 안에 납득시키는 능력"입니다.

저도 비슷한 경험이 있습니다. 몇 달을 들인 내부 플랫폼 개선 작업이 경영진 리뷰에서 "그래서 뭐가 좋아진 거죠?"라는 한 마디에 무너지는 걸 본 적이 있고, 반대로 기술적으로는 평범한 프로젝트가 잘 짜인 5분 데모 하나로 분기 로드맵의 중심에 올라가는 것도 봤습니다. 데모는 공정하지 않습니다. 하지만 게임의 규칙이 그렇다면, 규칙을 배우는 게 합리적입니다.

이 글은 PostHog의 논지를 출발점으로 삼아, 데모를 "재능"이 아니라 "엔지니어링 가능한 절차"로 다룹니다. 구조, 스크립트, 리허설, 환경 준비, 청중 조정, 실패 복구까지 — 코드 예제와 체크리스트 중심으로 정리했습니다.

데모가 채택, 투자, 승진을 가르는 이유

먼저 냉정한 현실 인식부터 하겠습니다. 데모가 중요한 이유는 세 가지 비대칭 때문입니다.

1. 정보의 비대칭

여러분은 그 프로젝트를 몇 주에서 몇 달 동안 생각했습니다. 청중은 처음 듣습니다. 여러분 머릿속에서 자명한 맥락이 청중에게는 존재하지 않습니다. 데모는 이 간극을 몇 분 안에 메우는 압축 행위입니다. 압축에 실패하면, 청중은 프로젝트가 아니라 자신의 혼란을 기억합니다.

2. 시간의 비대칭

의사결정자의 시간은 항상 부족합니다. 분기 리뷰에서 한 프로젝트에 할당되는 시간은 보통 5분에서 10분입니다. 6개월의 작업이 5분으로 평가되는 것은 부조리하지만, 그 5분을 설계할 수 있다는 것은 기회이기도 합니다.

3. 기억의 비대칭

사람은 논리가 아니라 장면을 기억합니다. "API 응답 속도를 40퍼센트 개선했습니다"라는 문장은 잊히지만, 느린 화면과 빠른 화면을 나란히 보여주는 10초는 회의가 끝난 뒤에도 남습니다. 승진 심사에서 "아, 그 데모 했던 사람"으로 기억되는 것의 가치는 생각보다 큽니다.

PostHog 글의 핵심 통찰도 여기에 있습니다. 데모는 정보 전달이 아니라 "확신의 전이(transfer of conviction)"입니다. 여러분이 가진 확신을 청중에게 옮기는 데 성공하면 채택과 투자가 따라오고, 실패하면 아무리 좋은 코드도 머지되지 않은 브랜치처럼 사라집니다.

S급 데모의 구조 — 훅 15초, 문제, 시연, 임팩트

좋은 데모는 거의 항상 같은 골격을 가집니다. 4막 구조로 정리하면 이렇습니다.

+-----------+----------------+---------------------+----------------+

| 1. 훅 | 2. 문제 | 3. 시연 | 4. 임팩트 |

| (15초) | (30~60초) | (2~4분) | (30초) |

+-----------+----------------+---------------------+----------------+

+-----------+----------------+---------------------+----------------+

1막: 훅 — 처음 15초에 결과를 보여줘라

가장 흔한 실수는 배경 설명으로 시작하는 것입니다. "이 프로젝트는 작년 Q3에 시작됐는데요, 당시 아키텍처가..."로 시작하면 15초 안에 청중의 절반이 슬랙을 봅니다.

S급 데모는 결론부터 보여줍니다. 영화 예고편이 가장 좋은 장면으로 시작하는 것과 같은 원리입니다.

나쁜 시작: "오늘은 배포 파이프라인 개선 작업을 공유드리겠습니다. 먼저 기존 구조를 설명드리면..."

좋은 시작: "어제까지 배포에 40분 걸렸습니다. 지금부터 90초 만에 배포하는 걸 실시간으로 보여드리겠습니다. 타이머 시작합니다."

2막: 문제 — 청중의 고통과 연결하라

훅으로 주의를 끌었으면, 이게 왜 청중의 문제인지 30초에서 60초 안에 연결합니다. 핵심은 "내 고생"이 아니라 "당신의 고통"을 말하는 것입니다. 기술 부채를 갚은 이야기가 아니라, 그 부채 때문에 청중이 겪던 불편(릴리즈 지연, 온콜 알람, 고객 이탈)을 말해야 합니다.

3막: 시연 — 해피 패스 하나만, 그러나 완벽하게

시연 파트의 황금률은 "하나의 경로를 끝까지"입니다. 기능 10개를 1분씩 보여주는 것보다, 가장 인상적인 시나리오 하나를 4분 동안 막힘없이 보여주는 게 압도적으로 효과적입니다. 곁가지 기능은 "이것 말고도 X, Y도 됩니다"라고 한 문장으로 처리하면 됩니다.

4막: 임팩트 — 숫자로 닫고, 요청으로 끝내라

마지막 30초에는 두 가지를 합니다. 첫째, 정량적 임팩트를 한 문장으로: "이 변경으로 주당 배포 횟수가 3회에서 25회가 됐습니다." 둘째, 명확한 요청(Call to Action): "다음 분기에 전사 롤아웃을 하려면 인프라팀 1명의 2주가 필요합니다. 승인 부탁드립니다." 요청 없는 데모는 박수받고 잊힙니다.

라이브 데모 vs 녹화 — 선택 기준

"라이브로 할까, 녹화로 할까"는 데모 준비에서 가장 먼저 결정할 사항입니다. 판단 기준을 표로 정리하면 다음과 같습니다.

| 기준 | 라이브 데모 | 녹화 데모 |

| --- | --- | --- |

| 신뢰감, 임팩트 | 최고 (진짜라는 증거) | 중간 (편집 의심 가능) |

| 실패 리스크 | 높음 | 없음 |

| 외부 의존성(네트워크, 서드파티 API) | 치명적 약점 | 무관 |

| 질의응답 중 즉석 시연 | 가능 | 불가능 |

| 타이밍, 페이스 제어 | 어려움 | 완벽 |

| 준비 비용 | 리허설 다회 필요 | 편집 시간 필요 |

| 비동기 공유, 재사용 | 어려움 | 탁월 |

실무 권장 기준은 이렇습니다.

1. **라이브를 기본값으로** 하되, 다음 중 하나라도 해당하면 녹화를 섞습니다.

2. 시연 경로에 외부 API, 결제, 메일 발송 등 **제어 불가능한 의존성**이 있다 → 해당 구간만 녹화

3. 한 번의 시연이 **3분 이상 걸리는 비동기 작업**(빌드, 학습, 마이그레이션)을 포함한다 → 시작은 라이브, 결과는 미리 돌려둔 화면으로 전환 (요리 방송의 "미리 구워둔 빵" 기법)

4. 청중이 **외부 투자자나 대형 고객**이고 실패 비용이 회복 불가능하다 → 녹화 본편 + 라이브 질의응답

5. 어떤 경우든 **백업 녹화는 반드시 준비**합니다. 라이브가 무너졌을 때 "녹화해 둔 게 있으니 이걸로 보시죠"라고 전환하는 것과 데모가 그냥 끝나는 것의 차이는 큽니다.

데모 시나리오 스크립트 작성법

데모는 애드리브가 아니라 대본이 있는 공연입니다. 스크립트는 "말할 내용"과 "조작할 내용"을 분리해서 적는 게 핵심입니다. 실제 사용하는 형식을 예시로 보여드리겠습니다.

데모 스크립트: 배포 파이프라인 v2 (총 6분, 청중: 엔지니어링 리더십)

[0:00-0:15] 훅

말: "어제까지 배포에 40분 걸렸습니다. 지금부터 90초 만에

배포하는 걸 보여드리겠습니다. 타이머 켭니다."

손: 스톱워치 앱 시작. 터미널 탭 1로 전환.

[0:15-1:00] 문제

말: "지난 분기 우리 팀 릴리즈가 평균 이틀씩 밀렸습니다.

원인의 70퍼센트가 배포 대기열이었습니다.

금요일 오후마다 배포 슬롯 잡으려고 슬랙에서

눈치 게임 하시던 것, 다들 기억하실 겁니다."

손: 아무것도 안 함 (화면 전환 금지, 얼굴/슬라이드 유지)

[1:00-4:30] 시연 (해피 패스)

말: "방금 버그 수정 PR이 머지됐다고 가정하겠습니다."

손: 터미널에서 deploy 명령 실행 → CI 대시보드 탭으로 전환

말: "카나리에 자동 배포되고, 에러율을 5분간 관찰합니다.

데모를 위해 관찰 구간은 30초로 줄여뒀습니다."

손: 대시보드에서 카나리 트래픽 그래프 확대 (줌 200퍼센트)

말: "에러율 정상. 자동으로 전체 롤아웃됩니다."

손: 프로덕션 URL 새로고침 → 변경 사항 확인

말: "타이머 확인하시죠. 87초입니다."

[4:30-5:00] 임팩트

말: "파일럿 2주간 배포 횟수 주 3회에서 25회,

롤백 평균 시간 22분에서 40초가 됐습니다."

[5:00-5:30] 요청

말: "전사 롤아웃에 인프라팀 1명 2주가 필요합니다.

이번 스프린트에 승인 부탁드립니다."

[예비] 질문 예상 3개와 답변 한 줄씩 별도 카드에 준비

스크립트 작성 시 지킬 규칙은 다음과 같습니다.

1. **"말"과 "손"을 분리해서 적는다.** 말하면서 조작하다 둘 다 망치는 게 가장 흔한 사고입니다. 조작하는 동안은 침묵하거나, 조작과 무관한 멘트(미리 외운 것)를 합니다.

2. **시간 박스를 명시한다.** 구간별 타임스탬프가 없으면 시연이 늘어지고 임팩트와 요청이 잘립니다. 가장 중요한 마지막 1분을 지키기 위해 앞을 자릅니다.

3. **숫자는 미리 박아둔다.** "꽤 빨라졌습니다"가 아니라 "40분에서 87초"입니다. 정확한 숫자는 스크립트에 적어두지 않으면 현장에서 증발합니다.

4. **첫 문장과 끝 문장은 통째로 외운다.** 중간은 키워드만 보고 말해도 되지만, 시작과 끝이 더듬거리면 전체 인상이 무너집니다.

리허설 — 3회 법칙과 실패 지점 목록

PostHog 글에서도 강조하듯, 데모를 잘하는 사람들의 공통점은 재능이 아니라 리허설 횟수입니다. 실무적으로는 "3회 법칙"을 권합니다.

1. **1회차 — 혼자, 끊지 않고.** 처음부터 끝까지 실제로 말하고 실제로 조작합니다. 머릿속 시뮬레이션은 리허설이 아닙니다. 이 단계에서 시간이 항상 예상보다 30~50퍼센트 초과한다는 걸 발견하게 됩니다. 잘라내십시오.

2. **2회차 — 동료 1명 앞에서.** 맥락이 없는 동료에게 보여주고 "어디서 헷갈렸는지"만 묻습니다. 칭찬은 듣지 마십시오. 혼란 지점만 수집합니다.

3. **3회차 — 실제 환경, 실제 장비로.** 발표할 그 회의실(또는 그 화상회의 툴), 그 노트북, 그 네트워크로 합니다. 사무실 모니터에서는 잘 보이던 글씨가 프로젝터에서 안 보이는 문제, 회사 VPN에서만 접근되는 대시보드 문제는 이 단계에서만 발견됩니다.

리허설을 하면서 **실패 지점 목록(failure inventory)**을 작성합니다. 형식은 단순합니다.

실패 지점 목록: 배포 파이프라인 데모

| 지점 | 증상 | 플랜 B |

|-----------------------|-------------------|----------------------------|

| CI 대시보드 로딩 | 첫 로드 8초 지연 | 미리 탭 열어두고 새로고침만 |

| 카나리 그래프 | 데이터 0건일 수 | 시드 스크립트 10분 전 실행 |

| 회의실 와이파이 | 사내망 끊김 잦음 | 휴대폰 테더링 사전 연결 |

| 프로덕션 URL | 캐시로 구버전 표시 | 시크릿 창 + 캐시 무효화 |

| 라이브 전체 실패 | 복구 불가 | 백업 녹화 영상 (탭 5번) |

이 목록의 가치는 사고를 막는 게 아니라, 사고가 났을 때 **당황하지 않게** 해준다는 데 있습니다. 플랜 B가 문서로 존재하면 복구가 3초면 됩니다.

데모 환경 준비 — 코드로 해결하기

데모의 신뢰성은 정신력이 아니라 엔지니어링으로 확보합니다. 세 가지 실전 기법을 코드와 함께 보겠습니다.

1. 데이터 시딩 — 빈 화면으로 데모하지 마라

빈 대시보드, 사용자 0명, 그래프 없음 상태로 하는 데모는 설득력이 없습니다. 데모용 데이터를 재현 가능하게 시딩하는 스크립트를 만들어 두십시오.

// scripts/seed-demo.ts

// 데모 직전 1회 실행: pnpm tsx scripts/seed-demo.ts

const DEMO_ORG = 'acme-demo'

async function seedDemo() {

// 멱등성 보장: 기존 데모 데이터 삭제 후 재생성

await db.event.deleteMany({ where: { orgId: DEMO_ORG } })

// 그래프가 "보기 좋게" 나오도록 추세가 있는 데이터 생성

const events = []

for (let day = 30; day >= 0; day--) {

const base = 120 + (30 - day) * 18 // 우상향 추세

const count = base + Math.floor(Math.random() * 25)

for (let i = 0; i < count; i++) {

events.push({

orgId: DEMO_ORG,

type: 'deploy_completed',

durationSec: 60 + Math.floor(Math.random() * 40),

createdAt: subMinutes(subDays(new Date(), day), i * 3),

})

}

await db.event.createMany({ data: events })

console.log(`Seeded ${events.length} events for ${DEMO_ORG}`)

}

seedDemo()

포인트는 세 가지입니다. 멱등성(여러 번 돌려도 같은 상태), 추세(그래프가 우상향으로 "스토리"를 갖도록), 그리고 현실감(이름과 숫자가 그럴듯하게 — "test1, test2, asdf"가 화면에 보이는 순간 데모의 격이 떨어집니다).

2. 데모 모드 플래그 — 불확실성을 코드로 제거

라이브 데모에서 가장 무서운 것은 외부 의존성입니다. 결제 API 타임아웃, 메일 발송 지연, LLM 응답의 비결정성 같은 것들이죠. 데모 모드 플래그로 위험 구간만 결정적(deterministic)으로 바꿉니다.

// src/lib/demo-mode.ts

export const isDemoMode = (): boolean =>

process.env.DEMO_MODE === '1'

// src/services/payment.ts

export async function chargeCard(amountCents: number) {

if (isDemoMode()) {

// 외부 PG사 호출 대신 0.8초 후 성공을 반환

await new Promise((r) => setTimeout(r, 800))

return { status: 'succeeded', id: 'demo_ch_001' }

}

return await realPaymentGateway.charge(amountCents)

}

주의할 점도 있습니다. 첫째, 데모 모드는 **위험 구간에만 최소로** 적용합니다. 전부 목으로 바꾸면 그건 데모가 아니라 애니메이션입니다(그리고 질의응답에서 들통납니다). 둘째, 데모 모드 사용 사실을 숨기지 마십시오. "결제는 샌드박스 모드입니다"라고 한 문장 말하면 신뢰가 깎이지 않습니다. 들킨 거짓말만이 신뢰를 깎습니다. 셋째, 플래그가 프로덕션에 새어 나가지 않도록 배포 파이프라인에서 가드를 겁니다.

.github/workflows/deploy.yml 중 일부

- name: Guard against demo mode in production

run: |

if [ "$DEMO_MODE" = "1" ]; then

echo "DEMO_MODE must not be enabled in production"

exit 1

3. 네트워크 플랜 B

체크 항목 세 가지입니다. 휴대폰 테더링을 **데모 시작 전에 미리 연결**해 둘 것(사고 후 연결하면 2분 날아갑니다), 시연 대상이 로컬에서 돌 수 있다면 **로컬 폴백**을 준비할 것, 그리고 회의실의 게스트 와이파이가 사내 대시보드에 접근 가능한지 **사전에 확인**할 것. 세 번째가 의외로 가장 자주 터집니다.

청중별 조정 — 같은 데모, 다른 강조점

데모의 골격은 같아도, 강조점은 청중에 따라 바뀌어야 합니다.

| 항목 | 경영진 | 엔지니어 | 고객 |

| --- | --- | --- | --- |

| 적정 시간 | 5분 이내 | 10~15분 | 15~20분 |

특히 경영진 데모에서 기억할 것: 그들은 기술이 아니라 **의사결정**을 삽니다. "이 기술이 얼마나 우아한가"가 아니라 "승인하면 무엇이 좋아지고, 안 하면 무엇을 잃는가"가 전부입니다. 반대로 엔지니어 청중에게 과장된 마케팅 톤을 쓰면 즉시 신뢰를 잃습니다. 엔지니어에게는 한계와 트레이드오프를 먼저 말하는 게 오히려 설득력을 높입니다.

흔한 실패 10가지와 복구 멘트

실패는 막는 것보다 복구가 중요합니다. 현장에서 자주 보는 실패 10가지와, 그 순간 쓸 수 있는 복구 멘트입니다.

1. **앱이 죽었다** → "좋은 소식은 이런 상황을 대비해 녹화를 준비했다는 겁니다. 이어서 보시죠." (백업 녹화로 전환, 5초 이내)

2. **로딩이 한없이 길다** → 침묵하지 말 것. "로딩되는 동안 한 가지 짚자면..." 하고 준비된 한 문장(임팩트 숫자)을 말합니다. 10초 넘으면 "이건 돌려두고 다음 화면 먼저 보시죠."

3. **데모 데이터가 비어 있다** → "시드 데이터가 초기화됐네요. 준비된 스크린샷으로 보여드리고, 끝나고 라이브로 다시 보여드리겠습니다."

4. **잘못된 버튼을 눌렀다** → 당황한 티를 내지 말고 그냥 되돌아갑니다. 사과를 길게 하면 실수가 2배로 보입니다. "다시 가보죠." 한 마디면 충분합니다.

5. **예상 못 한 에러 토스트가 떴다** → 엔지니어 청중이라면 정직이 최선: "오, 실제 에러네요. 이슈로 등록해 두고 계속하겠습니다." 오히려 진짜 라이브라는 증거가 됩니다.

6. **질문이 시연 중간에 끼어든다** → "좋은 질문입니다. 2분 뒤 그 화면이 나오는데 그때 답하겠습니다." 흐름 통제권을 돌려받는 게 핵심입니다.

7. **시간이 반밖에 안 남았다고 통보받았다** → 시연을 자르고 임팩트와 요청으로 점프합니다. 스크립트에 "단축 경로"를 미리 표시해 두면 가능합니다.

8. **화면 공유가 안 된다** → "권한 설정을 보는 동안, 오늘 보여드릴 결론부터 말씀드리면..." 훅을 입으로 먼저 합니다. 기술 문제 해결과 발표를 병렬화합니다.

9. **숫자에 대한 도전적 질문** ("그 40퍼센트, 어떻게 잰 거죠?") → "측정 방법론은 부록에 정리해 뒀습니다. 끝나고 링크 공유드리겠습니다." 즉석에서 방어하다 시간을 다 쓰는 게 최악입니다. 단, 부록은 진짜 있어야 합니다.

10. **완전한 블랙아웃(노트북 사망 등)** → 장비 없이 말로 하는 60초 버전을 미리 준비해 두십시오. "장비가 협조를 안 하니, 핵심만 말씀드리겠습니다. 배포가 40분에서 90초가 됐고, 승인이 필요한 건 2주짜리 작업입니다." 이게 가능한 사람은 거의 없어서, 가능하면 오히려 강하게 기억됩니다.

사내 데모 문화 만들기 — Demo Day 운영

개인기를 넘어 팀의 역량으로 만들려면 정기적인 demo day가 효과적입니다. PostHog를 비롯한 여러 회사가 주간 데모를 제도화한 이유는 명확합니다. 데모가 일상이 되면 "보여줄 수 있는 단위로 일을 쪼개는" 습관이 생기고, 이는 그대로 작은 PR, 빠른 피드백 루프로 이어집니다.

운영 규칙 예시는 다음과 같습니다.

1. **주기와 길이 고정**: 격주 금요일 30분. 길어지면 죽습니다.

2. **1인당 5분 하드 리밋**: 타이머를 공개적으로 띄웁니다. 5분 안에 못 보여주는 건 데모가 아니라 발표입니다.

3. **슬라이드 금지, 화면만**: 데모 데이의 목적은 "움직이는 것"을 보는 겁니다. 슬라이드가 허용되는 순간 전부 슬라이드가 됩니다.

4. **미완성 환영 원칙 명문화**: "부끄러운 단계에서 보여주는 게 정상"이라는 규칙을 문서로 박아둡니다. 심리적 안전이 없으면 완성품만 올라오고, 그러면 demo day가 아니라 분기 보고가 됩니다.

5. **녹화와 아카이브**: 모든 데모를 녹화해 채널에 쌓습니다. 신규 입사자 온보딩 자료로, 그리고 승진 심사의 증거 자료로 재사용됩니다.

6. **반응 의무**: 발표마다 질문 1개 또는 칭찬 1개를 의무화합니다. 침묵 속에 끝나는 데모가 반복되면 아무도 올리지 않게 됩니다.

운영이 잘 되고 있는지 판단하는 지표도 정해두면 좋습니다.

1. **참여율**: 분기별 데모 데이당 평균 발표 수. 줄어들면 심리적 안전이나 시간 부담에 문제가 생긴 것입니다.

2. **미완성 비율**: 발표 중 "진행 중인 작업"의 비율. 이게 0에 수렴하면 demo day가 보고회로 변질된 신호입니다.

3. **후속 전환율**: 데모에서 시작된 협업, 채택, 이슈 제보의 수. demo day의 진짜 ROI는 박수가 아니라 이 숫자입니다.

마지막으로, demo day의 첫 발표자는 항상 리더가 맡는 것을 권합니다. 리더가 어설픈 프로토타입을 웃으면서 보여주는 모습 한 번이, "미완성 환영"이라는 문서 열 장보다 강력합니다.

원격 데모 팁

2026년의 데모 절반은 화상회의입니다. 원격 특화 팁을 정리합니다.

1. **줌 레벨을 200퍼센트로**: 여러분 화면은 청중에게 절반 크기로 보입니다. 브라우저는 200퍼센트 줌, 터미널과 에디터는 폰트 18pt 이상. "잘 보이시나요?"라고 묻지 말고 처음부터 크게 시작하십시오(묻는 순간 3명이 "조금만 크게요"라고 답하며 1분이 사라집니다).

2. **창 하나만 공유하지 말고 가상 데스크톱을 공유**: 단일 창 공유는 탭 전환 때마다 공유를 다시 잡아야 하는 사고를 만듭니다. 데모 전용 가상 데스크톱을 만들고 거기에 필요한 창만 배치한 뒤 데스크톱 전체를 공유하는 게 안전합니다. 슬랙과 알림은 반드시 방해 금지 모드로.

3. **마우스로 말하라**: 원격에서는 시선 유도가 안 되므로, 커서를 크게 하고(OS 설정) 클릭 전에 "여기 이 버튼을 누르면"이라고 위치를 입으로 짚어줍니다.

4. **침묵 구간을 없애라**: 대면에서는 5초 침묵이 괜찮지만 원격에서는 "끊겼나?"가 됩니다. 로딩 중에는 항상 입을 움직입니다.

5. **시작 직후 녹화 버튼**: 원격 데모는 공짜로 녹화 자산이 됩니다. 잘된 라이브 데모 녹화가 다음 데모의 백업 영상이 되는 선순환을 만드십시오.

상황별 변주 — 해커톤, 분기 리뷰, 채용 면접

같은 4막 구조라도 무대에 따라 시간 배분과 강조점이 달라집니다. 세 가지 대표 무대의 변주를 정리합니다.

시간 배분 가이드 (4막 구조의 변주)

훅 문제 시연 임팩트/요청

해커톤 10초 20초 2분 30초

분기 리뷰 15초 1분 3분 2분

채용 면접 15초 30초 4분 1분 (질문 유도)

해커톤 데모 (3분)

심사위원은 하루에 수십 개의 데모를 봅니다. 그들의 머릿속에는 "이건 뭐가 다르지?"라는 질문 하나만 있습니다. 차별점 한 가지에 전부를 거십시오. 기술 스택 나열은 최악의 시간 낭비입니다 — "React와 FastAPI로 만들었고요"는 심사위원이 기억하지 않습니다. 작동하는 순간 하나가 기억의 전부입니다. 그리고 해커톤은 네트워크가 가장 불안정한 환경이므로, 로컬 폴백과 백업 녹화는 선택이 아니라 의무입니다.

분기 리뷰 데모 (5~10분)

분기 리뷰의 특수성은 "지난번 약속"과의 연결입니다. 지난 분기에 말한 목표를 첫 슬라이드에 다시 띄우고, 이번 데모가 그 약속의 이행임을 보여주면 신뢰 잔고가 복리로 쌓입니다. 임팩트 파트의 비중을 두 배로 늘리고, 다음 분기의 약속(측정 가능한 형태로)으로 끝내십시오. 경영진은 데모 자체보다 "약속-이행 사이클이 돌아가는 팀"이라는 신호를 삽니다.

채용 면접의 포트폴리오 데모

면접에서 사이드 프로젝트를 보여줄 기회가 생기면, 시연 후에 반드시 **면접관이 직접 만져보게** 하십시오. 통제권을 넘기는 것은 자신감의 신호이고, 면접관의 손에서 살아남는 제품은 어떤 말보다 강합니다. 그리고 실패담 하나를 준비하십시오 — "이 부분은 처음에 X로 설계했다가 Y 문제로 갈아엎었습니다"는 완벽한 성공담보다 시니어다움을 더 잘 증명합니다.

데모 직전 멘탈 루틴

무대가 무엇이든 직전 5분은 같습니다. 첫 문장을 입 밖으로 세 번 소리 내어 말하고(머릿속 낭독은 효과가 절반입니다), 물을 한 모금 마시고, "데모가 죽어도 나는 복구 멘트가 있다"는 사실을 떠올리십시오. 준비된 사람의 여유는 청중에게 그대로 전염됩니다.

데모 후의 일 — 모멘텀을 자산으로

데모가 끝나는 순간이 진짜 시작입니다. 박수의 유효기간은 48시간이고, 그 안에 모멘텀을 자산으로 바꿔야 합니다.

1. **24시간 내 팔로업 메시지**: 녹화 링크, 핵심 숫자 3개, 그리고 데모에서 했던 요청(CTA)을 다시 적어 보냅니다. 결정권자의 받은편지함에 "결정해야 할 일"로 다시 등록시키는 행위입니다.

2. **질문 로그의 자산화**: 데모 중 받은 질문은 청중이 무엇을 우려하는지에 대한 무료 시장조사입니다. 질문 목록을 정리해 FAQ 문서로 만들면 다음 데모의 예상 질문 카드가 그대로 완성됩니다.

3. **거절도 데이터**: 요청이 거절됐다면 "무엇이 충족되면 다시 논의 가능한지"를 그 자리에서 물어 기록합니다. "지금은 아니다"와 "영원히 아니다"를 구분하는 것이 다음 분기의 전략을 결정합니다.

함정과 반론 — 데모 지상주의에 대한 경계

균형을 위해 반대편 논리도 다루겠습니다.

**"데모 잘하는 사람만 보상받으면, 조용한 빌더가 손해 본다"**는 비판은 타당합니다. 데모 능력과 엔지니어링 능력은 상관관계가 완벽하지 않고, 화려한 데모가 부실한 기반 작업을 가리는 "데모 주도 개발(demo-driven development)"의 폐해도 실재합니다. 인프라, 보안, 리팩토링처럼 본질적으로 "보여주기 어려운" 작업이 demo day 문화에서 체계적으로 저평가될 위험도 있습니다.

대응은 두 방향입니다. 조직 차원에서는 데모 외의 평가 채널(설계 문서, 운영 지표, 동료 평가)을 함께 유지해야 합니다. 개인 차원에서는, 보여주기 어려운 작업일수록 보여주는 기술이 더 필요하다는 역설을 받아들이는 게 현실적입니다. 레이턴시 그래프의 before/after, 온콜 알람 수의 감소 추이, 취약점 스캔 결과의 변화 — 인프라 작업도 "장면"으로 만들 수 있습니다.

또 하나의 함정은 **과최적화된 데모**입니다. 데모 모드와 시딩으로 너무 매끈하게 다듬으면, 실제 제품과의 간극이 채택 후에 드러나 신뢰를 크게 잃습니다. 데모는 제품의 최선의 모습이어야 하지, 제품에 없는 모습이어서는 안 됩니다.

데모 체크리스트

데모 전날과 직전에 쓰는 체크리스트입니다.

전날까지:

1. 스크립트 작성 완료 (말/손 분리, 타임박스, 첫/끝 문장 암기)

2. 리허설 3회 완료 (혼자 → 동료 → 실제 환경)

3. 실패 지점 목록과 플랜 B 작성

4. 백업 녹화 준비, 재생 위치 확인

5. 데모 데이터 시딩 스크립트 검증

6. 단축 버전(시간 절반) 경로 표시

직전 30분:

1. 시드 스크립트 실행, 화면 상태 확인

2. 알림 전부 차단 (OS 방해 금지 + 슬랙 + 메일)

3. 데모용 가상 데스크톱에 필요한 탭만 순서대로 배치

4. 브라우저 줌 200퍼센트, 터미널 폰트 확대

5. 테더링 사전 연결, 백업 녹화 탭 열어두기

6. 물 한 잔, 타이머 준비

끝난 후:

1. 질문 중 못 답한 것 24시간 내 팔로업

2. 요청(CTA)에 대한 결정권자의 답 확인

3. 녹화본 아카이브, 다음 데모의 백업으로 등록

마치며

데모는 재능이 아니라 절차입니다. 훅 15초, 해피 패스 하나, 숫자로 닫기, 요청으로 끝내기. 리허설 3회와 실패 지점 목록, 시딩 스크립트와 데모 모드 플래그. 이 글의 어떤 것도 화술 훈련이 아닙니다. 전부 엔지니어링입니다.

만드는 비용이 무너진 시대에, 보여주는 능력은 개발자의 두 번째 컴파일러입니다. 코드가 기계에게 의도를 전달하는 언어라면, 데모는 사람에게 가치를 전달하는 언어입니다. 둘 다 못 쓰면, 절반만 개발자인 셈입니다.

참고 자료

- PostHog Newsletter — How to demo: https://newsletter.posthog.com/p/how-to-demo

- GeekNews 토론 — 데모하는 방법: https://news.hada.io/topic?id=30265

- Hacker News — PostHog How to demo 토론: https://news.ycombinator.com/

- PostHog Handbook — 전사 핸드북 공개 문화: https://posthog.com/handbook

- Kapwing — 데모 영상 제작 가이드: https://www.kapwing.com/resources/

- Stripe Docs — 테스트 모드와 샌드박스 설계 사례: https://docs.stripe.com/testing

- GitHub Actions 공식 문서 — 환경 변수와 가드: https://docs.github.com/en/actions

- Zoom 공식 문서 — 화면 공유 모범 사례: https://support.zoom.com/hc/en

- date-fns 공식 문서 (시딩 스크립트 예제 라이브러리): https://date-fns.org/

- 37signals — Shape Up, 데모 가능한 단위로 일 쪼개기: https://basecamp.com/shapeup