해외 퍼블리셔 피칭을 위한 Pitch Deck 작성법과 게임 데모 전달 기준
해외 게임 퍼블리셔 피칭에서 검토받는 Pitch Deck 구성, 시장성 지표, 빌드 품질, 데모 링크와 데이터룸 전달 기준을 실무적으로 정리합니다.
해외 퍼블리셔 피칭의 핵심은 ‘좋아 보이는 소개 자료’가 아니라 누구에게 어떤 이유로 팔릴 게임인지와 팀이 출시까지 실행할 수 있는지를 짧은 시간에 검증 가능하게 만드는 것이다. Pitch Deck은 시장·제품·팀·요청 사항을 한 문서에서 연결하고 데모는 그 주장 가운데 재미와 제작 역량을 실제 플레이로 증명해야 한다.
해외 퍼블리셔 Pitch Deck에 무엇을 담아야 할까?
퍼블리셔는 일반적으로 다음 질문에 빠르게 답을 얻고 싶어 한다.
- 이 게임의 핵심 재미와 차별점은 무엇인가?
- 누가 구매하며 비슷한 게임과 비교해 시장 진입 가능성이 있는가?
- 현재 제작 단계와 출시까지의 위험은 어느 정도인가?
- 팀은 약속한 범위를 완성할 수 있는가?
- 퍼블리셔에게 필요한 지원과 그 대가가 명확한가?
따라서 덱은 10~15장 안팎을 목표로 잡는 편이 좋다. 슬라이드 수가 절대 기준은 아니지만 한 장에 하나의 판단만 가능하도록 구성해야 검토 속도가 올라간다.
| 슬라이드 | 퍼블리셔가 확인하는 내용 | 작성 기준 |
|---|---|---|
| 1. 표지 | 게임명, 장르, 한 줄 가치 제안 | 게임플레이 화면과 짧은 로그라인을 함께 제시 |
| 2. 엘리베이터 피치 | 게임을 한 문장으로 설명할 수 있는가 | 타깃 + 장르 + 핵심 판타지 + 차별점 구조 사용 |
| 3. 플레이 경험 | 플레이어가 반복할 행동은 무엇인가 | 코어 루프와 세션 길이, 보상 구조를 설명 |
| 4. 차별점 | 경쟁작 대신 이 게임을 선택할 이유 | 비교 가능한 기능과 감각을 구체적으로 제시 |
| 5. 시장과 타깃 | 예상 구매자와 판매 맥락 | Steam 태그, 유사작, 지역·플랫폼을 명시 |
| 6. 경쟁작 비교 | 가격과 품질 기대치 | 출시일, 가격, 리뷰 수 등 검증 가능한 정보 사용 |
| 7. 현재 빌드 | 실제 개발 진척도 | 플레이 가능 범위와 미구현 위험을 분리 |
| 8. 트랙션 | 외부 반응과 수요 신호 | 위시리스트, 플레이테스트, 커뮤니티 지표를 날짜와 함께 표기 |
| 9. 제작 계획 | 출시 가능 시점과 마일스톤 | 알파, 베타, 콘텐츠 락, 출시 후보 빌드를 구분 |
| 10. 팀 | 완성 역량 | 담당 역할, 출시 경험, 외주 의존도를 명시 |
| 11. 요청 사항 | 퍼블리셔가 제공할 역할 | 자금, QA, 현지화, 마케팅, 콘솔 이식 등을 구체화 |
| 12. 연락처 | 다음 행동 | 데모 링크, 연락처, NDA 필요 여부를 표시 |
게임 Pitch Deck의 한 줄 피치는 어떻게 쓰는가?
한 줄 피치는 장르명만 나열하지 말고 플레이어가 수행하는 행동과 얻는 감정을 포함해야 한다. 예를 들어 2D 로그라이크 액션은 장르 분류일 뿐 구매 이유가 아니다.
다음 구조를 사용하면 검토자가 게임을 빠르게 분류할 수 있다.
[타깃 플레이어]를 위한 [장르] 게임으로 [핵심 행동]을 통해 [판타지 또는 감정]을 제공하며 [대표 차별점]으로 기존 게임과 구분된다.
예시는 다음과 같다.
빠른 의사결정과 빌드 최적화를 좋아하는 플레이어를 위한 싱글플레이 덱빌딩 로그라이크로 전투 중 획득한 모듈을 즉시 조합해 함선을 개조하는 재미를 제공하며 실시간 전장 위치 선정이 카드 선택만으로 진행되는 경쟁작과 구분된다.
이 문장은 스토어 설명을 대신하지 않는다. 덱의 표지와 첫 2~3장에 같은 핵심 문장을 일관되게 사용해 제품의 정체성을 고정하는 용도다.
시장성 슬라이드에는 어떤 데이터를 넣어야 하는가?
시장 규모를 과장한 거대한 TAM(Total Addressable Market) 수치보다 해당 게임이 Steam에서 어떤 기대치와 경쟁하는지를 보여주는 데이터가 더 실용적이다. 특히 PC 인디 게임이라면 유사작 비교표가 설득력을 높인다.
유사작 비교표 작성 기준
유사작은 ‘비슷해 보이는 게임’이 아니라 구매자가 실제로 비교할 가능성이 높은 게임을 고른다. 장르, 시점, 세션 길이, 그래픽 톤, 가격, 플레이 동기가 가까운 작품을 5~8개 정도 선정한다.
| 항목 | 확인 방법 | 덱에서의 활용 |
|---|---|---|
| 출시 시점 | Steam 스토어 페이지 | 시장 포화도와 최신 수요 맥락 판단 |
| 정가와 할인 이력 | SteamDB 등 공개 서비스 | 가격 포지셔닝과 출시 할인 전략 검토 |
| 사용자 평가 | Steam 최근/전체 평가 | 구매자 만족도와 품질 기준 파악 |
| 리뷰 수 | Steam 스토어 페이지 | 수요 신호의 대략적인 규모 비교 |
| Steam 태그 | Steam 스토어 페이지 | 검색·추천 노출 맥락 확인 |
| 핵심 차별점 | 실제 플레이 및 공식 소개 | 우리 게임의 빈자리 정의 |
공개 자료의 수치는 수집 날짜를 함께 적는다. 예를 들어 Steam 데이터 확인일: 2026-08-09처럼 표시하면 수치가 고정된 사실이 아니라 시점 데이터임을 분명히 할 수 있다.
예상 매출을 제시해야 한다면 가정을 분리한다. 단순 매출 모델은 다음처럼 쓸 수 있다.
여기서 Average Selling Price는 정가가 아니라 출시 할인, 지역 가격, 플랫폼 수수료 전 가격 여부를 구분한 값이어야 한다. 퍼블리셔에 제출하는 손익 추정에는 환불률, 세금, 플랫폼 수수료, 번들·키 판매 조건 등 계약과 채널별 변수가 들어갈 수 있으므로 덱에서는 확정값처럼 제시하지 않는 편이 안전하다.
게임 데모는 어느 수준까지 준비해야 하는가?
피칭용 데모는 전체 게임의 축소판이 아니라 게임의 구매 이유를 검증하는 짧고 안정적인 수직 슬라이스(vertical slice) 다. 보통 10~20분 안에 코어 루프, 대표 콘텐츠, 진행 보상, 게임의 시청각 방향성을 경험할 수 있어야 한다.
데모에 반드시 포함할 요소
- 시작 후 1분 이내에 핵심 행동을 수행할 수 있는 온보딩
- 대표 전투·퍼즐·탐험 등 코어 루프의 완결된 한 사이클
- 플레이 결과에 따른 보상 또는 성장 선택
- 게임의 목표와 다음 행동을 알려 주는 UI
- 크래시 없이 종료 또는 재시작할 수 있는 흐름
- 보고하고 싶은 버그를 재현할 수 있는 버전 번호와 빌드 정보
반대로 핵심 재미를 설명하지 못하는 넓은 맵이나 미완성 콘텐츠를 많이 넣는 것은 피하는 편이 좋다. 검토자는 제작량보다 제품 판단에 필요한 신뢰도 높은 경험을 원한다.
Unity와 Unreal Engine 빌드 전달 체크리스트
| 항목 | Unity | Unreal Engine | 공통 기준 |
|---|---|---|---|
| Windows 배포물 | .exe와 *_Data 폴더를 함께 압축 | .exe, Content, Engine 등 패키징 결과 전체 압축 | 압축 해제 후 별도 설치 없이 실행 가능해야 함 |
| 권장 출력 | Windows x86_64 | Windows Shipping | Development 빌드는 로그 노출과 성능 저하 가능성을 검토 |
| 버전 표기 | 화면 또는 README에 Unity 버전·빌드 번호 | 화면 또는 README에 UE 버전·빌드 번호 | 예: Demo v0.3.1, build 20260809 |
| 입력 장치 | 키보드·마우스와 패드 지원 여부 명시 | 키보드·마우스와 패드 지원 여부 명시 | 지원하지 않는 장치는 미리 적기 |
| 초기 설정 | 해상도·전체 화면 기본값 검증 | 셰이더 컴파일·첫 실행 시간 검증 | 첫 실행부터 플레이까지의 시간을 짧게 유지 |
데모가 Windows 전용이라면 macOS 지원처럼 오해할 수 있는 표기를 넣지 않는다. 플랫폼별 제공 범위는 이메일과 README 모두에 명시한다.
해외 퍼블리셔에 게임 데모를 어떻게 전달할까?
다운로드 링크만 보내기보다 검토에 필요한 정보가 한 번에 들어 있는 데이터룸 형태로 전달하는 것이 좋다. Google Drive, Dropbox, OneDrive, itch.io의 비공개 링크처럼 접근 권한과 다운로드 상태를 관리할 수 있는 도구를 사용한다.
Step 1. 파일 구조를 단순하게 만든다
압축 파일 최상위에는 실행 파일, 필요한 폴더, README만 둔다. 폴더가 여러 단계로 중첩되면 검토자가 실행을 포기할 가능성이 높다.
ProjectName_Demo_v0.3.1_Win64.zip
└── ProjectName_Demo_v0.3.1_Win64/
├── ProjectName.exe
├── ProjectName_Data/
└── README.mdStep 2. README에 실행·검토 정보를 쓴다
README는 길 필요가 없다. 실행 방법, 조작법, 데모 예상 시간, 알려진 문제, 담당자 연락처만 명확하면 된다.
# Project Name — Publisher Demo
- Build: v0.3.1 (2026-08-09)
- Platform: Windows 10/11 64-bit
- Engine: Unity 6.0.0f1
- Expected playtime: 15 minutes
## Run
1. 압축을 해제합니다.
2. `ProjectName.exe`를 실행합니다.
## Controls
- Move: WASD
- Interact: E
- Attack: Left Mouse Button
- Pause: Esc
## Known issues
- 첫 실행에서 셰이더 캐시 생성으로 로딩이 길어질 수 있습니다.
## Contact
- [email protected]엔진 버전은 실제 프로젝트에 사용한 값을 넣는다. Unity 6.0.0f1이나 Unreal Engine 5.4처럼 구체적인 버전은 호환성 문제를 분석할 때 도움이 되지만 사용하지 않은 버전을 예시 그대로 유지해서는 안 된다.
Step 3. 링크와 접근 조건을 검증한다
시크릿 브라우저 창 또는 팀원 계정으로 링크를 열어 다음을 확인한다.
- 로그인 요청 없이 권한이 의도대로 작동하는가
- 다운로드와 압축 해제가 정상인가
- 새 PC에서 실행되는가
- 파일명이 현재 버전과 일치하는가
- 링크 만료일과 NDA 요구 여부가 메일 내용과 일치하는가
flowchart LR
A[피치 이메일] --> B[Pitch Deck]
B --> C[비공개 데모 링크]
C --> D[README와 조작법]
D --> E[10~20분 수직 슬라이스]
E --> F[후속 미팅 또는 피드백]Pitch Deck에서 트랙션은 어떻게 제시해야 하는가?
트랙션은 숫자가 크냐보다 수집 방식과 의미가 분명하냐가 중요하다. 출시 전 게임이라면 Steam 위시리스트, 공개 플레이테스트 참가자 수, 데모 완주율, Discord 활성 사용자, 행사 체험자 피드백 등을 활용할 수 있다.
다만 서로 다른 지표를 같은 성과처럼 섞지 않는다. 예를 들어 위시리스트는 구매 의향에 가까운 신호이고 TikTok 조회 수는 도달 범위를 나타내는 지표다. 각각의 측정 기간과 출처를 함께 쓴다.
| 지표 | 제시 예시 | 함께 적을 정보 |
|---|---|---|
| Steam 위시리스트 | 12,400 | 기준일, 스토어 공개일, 주요 유입 이벤트 |
| 데모 플레이테스트 | 684명 참여 | 모집 채널, 기간, 중복 참여 처리 방식 |
| 완주율 | 첫 보스 도달률 41% | 이벤트 정의, 표본 수, 분석 도구 |
| 설문 결과 | 재플레이 의향 78% | 질문 문구, 응답자 수, 편향 가능성 |
| 커뮤니티 | Discord 월간 활성 사용자 530명 | 기간, 활동의 정의, 봇 제외 여부 |
정량 데이터가 아직 없다면 그 사실을 숨기기보다 플레이테스트 계획과 측정할 이벤트를 제시하는 편이 낫다. 예를 들어 튜토리얼 완료, 첫 세션 종료, 상점 진입, 첫 보스 처치 같은 이벤트를 정의하고 다음 테스트에서 무엇을 검증할지 적을 수 있다.
퍼블리셔에게 무엇을 요청해야 하는가?
‘퍼블리싱을 원한다’는 요청만으로는 조건을 검토하기 어렵다. 필요한 자원과 이미 팀이 확보한 자원을 나누어 써야 한다.
| 지원 영역 | 요청을 구체화하는 질문 |
|---|---|
| 개발 자금 | 콘텐츠 완성과 QA에 필요한 기간·예산은 얼마인가? |
| 마케팅 | Steam 페이지, 크리에이터 캠페인, 이벤트 출품 중 무엇이 필요한가? |
| QA | 지원 언어와 플랫폼별 테스트 범위는 어디까지인가? |
| 현지화 | 번역만 필요한가, 문화권별 LQA(Localization QA)도 필요한가? |
| 콘솔 이식 | 대상 플랫폼과 인증 대응을 누가 맡는가? |
| 출시 운영 | 가격, 할인, 패치, 커뮤니티 대응의 의사결정권은 어떻게 나뉘는가? |
계약 협상 전에는 최소보장금(MG, Minimum Guarantee), 회수 우선순위(recoupment), 순매출 정의, 플랫폼 수수료·마케팅 비용 공제 범위, IP 소유권, 계약 기간, 해지 조건을 법률 전문가와 검토하는 것이 안전하다. 덱에는 희망 조건을 간단히 적을 수 있지만 법적 문서의 해석을 덱 한 장으로 확정하려 해서는 안 된다.
자주 묻는 질문 (FAQ)
데모가 없어도 해외 퍼블리셔 피칭을 할 수 있나?
초기 콘셉트 단계의 미팅은 가능하지만 계약 검토를 진전시키려면 코어 루프를 확인할 수 있는 플레이 가능한 빌드가 매우 중요하다. 데모가 없다면 플레이 영상, 프로토타입, 제작 계획을 제공하되 현재 단계와 위험을 명확히 밝혀야 한다.
Pitch Deck은 몇 장이 적당한가?
일반적으로 10~15장 안에서 핵심을 전달하는 구성이 읽기 쉽다. 다만 장수보다 중요한 것은 게임성, 시장성, 제작 계획, 팀, 요청 사항을 빠르게 판단할 수 있는가다.
Steam 위시리스트가 적으면 피칭하면 안 되나?
그렇지 않다. 위시리스트는 유용한 수요 신호지만 유일한 기준은 아니다. 재미가 검증된 데모, 명확한 장르 포지션, 현실적인 제작 범위, 신뢰할 수 있는 팀 역량도 함께 평가된다.
정리
해외 퍼블리셔 피칭용 Pitch Deck은 게임의 매력을 설명하는 자료이면서 동시에 리스크를 관리하는 문서다. 한 줄 피치와 실제 데모의 경험을 일치시키고 시장·트랙션 수치에는 출처와 기준일을 붙이며 퍼블리셔에게 요청하는 역할을 구체적으로 정의하자. 마지막으로 외부 환경에서 데모 링크와 실행 파일을 직접 검증하면 좋은 첫인상을 기술적인 실수로 잃을 가능성을 크게 줄일 수 있다.
