게임 기획 / 제작 가이드
플레이테스트 리포트 작성, 감상과 행동 기록의 구분
플레이테스트 리포트는 제작 결정을 관찰 근거에 연결하는 문서다. Valve의 조사 방법과 Portal 제작 회고를 읽고, 조사 질문에서 진행 대본·사건 기록·집계·재검증까지 이어지는 작성 절차를 정리했다.
기사 요약
- 조사 질문에 맞춰 관찰·질문·지표와 조건 비교를 고른다.
- 발화와 도움, 출력 환경이 플레이에 미친 조건을 함께 적는다.
- 참가자와 노트의 집계 단위를 나누고 다음 수정에 근거를 붙인다.

CAT BEAT : 비트를 깨워 · 개발 중 실제 화면
챕터 3 권투 배경의 실제 개발 화면. 다가오는 대상의 방향과 시점에 맞춰 받아치는 장면이다.
제작사가 플레이테스트에서 읽는 것
Valve의 Mike Ambinder는 2009년 발표에서 설계 가설을 세우고 플레이를 관찰한 뒤 결과를 평가해 다음 설계로 연결하는 과정을 소개했다. 직접 관찰, 참가자의 말, 질문지, 행동 통계와 조건 비교는 각기 다른 질문에 답하는 수단으로 다뤄진다.
《Portal》의 Kim Swift와 Erik Wolpaw가 공개한 제작 회고에서도 플레이테스트는 개발 과정에 들어 있다. 발표는 실제 플레이를 지켜보며 진행 이해와 이야기 전달을 확인하는 과정을 소개한다. 제작 중인 장면을 일찍 보여 주고 관찰 결과로 다음 수정을 정하는 접근이다.
이 글은 공개 발표와 게임 사용자 조사 실무 자료를 바탕으로 기록과 보고의 절차를 정리한다. 뒤의 다섯 세션과 인용 발언, 수치는 편집부가 작성한 가상 학습 자료다.
관련 원자료: Valve · Mike Ambinder · Valve’s Approach to Playtesting · GDC 2009 ↗ · Valve · Kim Swift & Erik Wolpaw · Portal Post-Mortem · GDC 2008 ↗
이번 결정에 필요한 조사 질문을 세운다
테스트 계획에는 바꾸려는 화면과 이번에 내릴 결정을 먼저 적는다. “첫 목표가 나타났을 때 입력할 위치와 시점을 알아차리는가”라는 질문은 첫 행동을 관찰할 과제를 만든다. “수정한 예고가 입력 오차를 줄이는가”라는 질문은 비교 조건과 측정 방법을 요구한다.
게임 사용자 조사자 Steve Bromley는 목표에 맞춰 관찰, 인터뷰, 설문, 행동 데이터를 선택하는 절차를 설명한다. 조작하는 과정은 관찰로, 그 행동에서 무엇을 예상했는지는 후속 질문으로 확인할 수 있다. 선택 이유를 듣고 싶다면 참가자가 방금 본 장면과 행동을 구체적으로 되짚는다.
보고서의 첫 페이지에는 질문, 대상 빌드, 참가 조건, 과제, 이번에 결정할 항목을 함께 둔다. 짧은 사전 실행으로 과제 문장이 전달되는지, 필요한 사건이 기록되는지 확인하고 진행 대본을 고정한다.
관련 원자료: Steve Bromley · Choose the right playtest method ↗
보고서를 구성하는 근거
| 항목 | 기록할 내용 | 다음 결정과의 연결 |
|---|---|---|
| 질문 | 대상 빌드·과제·관찰할 행동 | 이번에 선택할 수정 |
| 방법 | 참가 조건·환경·진행 대본 | 어떤 상황에서 얻은 기록인가 |
| 관찰 | 시각·입력·도움·발언 | 다시 찾아볼 근거 |
| 집계 | 사람·세션·노트·포함 범위 | 수치가 답하는 질문 |
| 후속 | 수정·새 빌드·재검증 과제 | 같은 질문으로 확인할 행동 |

CAT BEAT : 비트를 깨워 · 개발 중 실제 화면
연습 모드 실제 개발 화면. 들리는 리듬과 입력을 연결하는 장면의 사례다.
질문에 맞춰 고르는 기록 방법
| 알아볼 것 | 방법 | 함께 기록할 조건 |
|---|---|---|
| 처음 무엇을 하는가 | 플레이 관찰·사건 로그 | 시작 기준·도움·첫 노출 |
| 무엇을 예상했는가 | 장면을 되짚는 질문 | 질문 문장·장면과 응답 시각 |
| 어디에 입력이 몰리는가 | 목표·입력 시각 집계 | 음악 시계·기기·보정값 |
| 어느 조건에서 행동이 바뀌는가 | 조건 비교 | 변경 변수·순서·반복 노출 |
참가 조건과 실행 환경을 기록한다
처음 접하는 이용자의 안내 이해를 살핀다면 해당 빌드를 처음 보는 참가자의 세션을 별도로 모은다. 리듬게임 경험, 이전 버전 노출, 조작 기기와 입력 방식도 기록한다. 같은 참가자가 여러 조건을 플레이하면 순서와 반복 횟수를 남긴다.
Microsoft 개발자 사이트에 실린 Parsec 담당자의 Xbox Research 사례는 원격 환경에서 제작 중인 게임을 전달하고 연구를 진행한 과정을 소개한다. 원격 플레이에는 영상 전송과 입력 전달의 조건이 붙는다. 타이밍 과제는 로컬 실행과 스트리밍 실행을 구분하고, 연결·출력 조건을 보고서에 적는다.
빌드 식별자, 콘텐츠 버전, 화면 크기, 프레임 설정, 음량, 스피커·유선·무선 출력, 보정값과 입력 장치를 세션 단위로 묶는다. 참가자에게 조사와 기록 범위를 설명하고 동의한 항목을 확인한다. 공개 예제에는 P01 같은 식별자를 쓰며, 실제 자료의 접근 담당자와 보관·삭제 일정은 조사 계획에서 정한다.
관련 원자료: Microsoft Developer · Parsec 담당자의 Xbox Research 원격 플레이테스트 사례 ↗
진행 대본과 도움의 기준을 맞춘다
진행자는 목표만 전달하고 참가자가 화면을 읽고 행동할 시간을 둔다. 예시 과제는 “이 연습을 시작해 한 판을 마쳐 주세요”다. 입력 위치를 스스로 찾는 과제라면 손가락을 놓을 위치와 눌러야 할 순간은 화면이 전달하도록 둔다.
도움은 조건과 내용을 미리 정한다. 참가자가 중단 의사를 밝히거나 실행 오류가 생긴 경우의 처리, 도움을 요청했을 때 제공할 문장, 자력 진행을 관찰할 시간을 정한다. 도움 시각과 실제로 말한 내용을 기록하면 도움 전후의 행동을 나눠 읽을 수 있다.
NN/g의 조사 방법 글은 질문의 표현이 응답과 뒤의 행동에 영향을 줄 수 있음을 설명한다. “안내가 도움이 됐죠?”보다 “이 장면에서 무엇을 하려고 했나요?”처럼 경험을 풀어 말할 질문을 준비한다. 관찰한 사건과 참가자의 해석을 연결할 때에는 당시 화면이나 짧은 재생 구간을 함께 보여 줄 수 있다.
관련 원자료: NN/g · Amy Schade · Avoid Leading Questions to Get Better Insights from Participants ↗
입력 성능과 발화 관찰을 나눠 운영한다
Valve의 발표는 생각을 말하며 플레이하는 방식으로 판단 이유를 들을 수 있는 한편, 발화가 플레이 수행에도 영향을 준다고 설명한다. 빠른 타이밍 입력을 측정하는 구간은 조용히 플레이한 뒤 화면을 되짚는 절차를 따로 둘 수 있다.
예를 들어 첫 실행에서는 입력과 목표 시각을 기록하고, 종료 뒤 참가자가 멈췄던 장면을 보여 주며 당시 예상과 선택을 묻는다. 현장 발화를 받는 탐색 세션은 별도 방식으로 표시한다. 회상 발언은 질문한 시점과 되짚은 장면의 시점을 함께 적는다.
입력 기록은 음악 재생 위치와 같은 기준에서 목표 시각과 비교한다. 관찰자의 메모 시계와 게임의 음악 시계에는 기준점과 차이가 있으므로, 세션 시작 사건으로 연결하고 기록 정밀도를 표시한다. 영상의 프레임 위치만으로 밀리초 입력 성능을 확정하는 경우에는 캡처와 출력의 지연 조건까지 검토한다.
관련 원자료: Valve · Mike Ambinder · Valve’s Approach to Playtesting · GDC 2009 ↗
관찰·발언·해석을 서로 다른 칸에 둔다
관찰에는 화면과 로그에서 확인한 사건을 쓴다. “4.2초에 첫 목표의 판정 창이 닫혔으며 입력 기록이 없다”처럼 시각과 상태를 적는다. 발언에는 참가자가 실제로 한 말을 그대로 옮기고, 기록자의 요약은 요약이라고 표시한다.
편집부의 가상 P01 세션에서는 4.2초 첫 놓침, 4.6초 발언, 6.0초 도움, 7.0초 첫 입력을 순서대로 놓았다. “시작 안내인 줄 알았어요”라는 발언은 이 예제를 위해 작성한 가상 인용이다. 실제 조사에서는 녹화·로그·메모 위치로 원기록을 찾아갈 수 있게 한다.
해석 칸에는 “시작 안내와 플레이 목표를 구별하는 신호를 살펴볼 필요가 있다”는 가설을 적을 수 있다. 다음 수정은 예고 모양과 전환 신호를 정리하는 안으로 연결한다. 가설을 검토할 다음 과제와 확인할 행동까지 쓰면 수정 근거를 따라갈 수 있다.
관련 원자료: Valve · Mike Ambinder · Valve’s Approach to Playtesting · GDC 2009 ↗ · NN/g · Amy Schade · Avoid Leading Questions to Get Better Insights from Participants ↗
원기록에서 다음 빌드까지
편집부 작성 절차도. 사건과 발언을 보존하고 해석과 수정을 연결한다.
- 원기록영상·로그·메모 위치
- 사건과 발언발생 시각·행동·실제 표현
- 설명할 가설가능한 원인과 추가 확인
- 수정할 요소예고·안내·판정 반응
- 재검증새 빌드·같은 질문·관찰 결과
집계 전에 사건과 완료 상태를 정의한다
코드북에는 첫 목표 놓침, 입력 수, 성공 수, 자력 완료와 도움 후 완료의 정의를 적는다. 한 판의 종료 화면까지 도움 없이 도달하면 자력 완료, 진행자의 조작 안내를 받은 뒤 도달하면 도움 후 완료로 분류하는 식이다. 도움 이후에도 판 전체의 성공 수는 별도 열에 기록할 수 있다.
실행 오류나 중도 종료가 있으면 해당 세션의 상태와 이유를 남긴다. 기록이 누락된 항목은 누락값으로 관리하고, 계산에 포함할 세션과 대상의 기준을 표마다 밝힌다. 이번 예제의 다섯 세션은 모두 16개 목표를 끝까지 진행한 조건이다.
리듬 입력은 목표 하나가 판정 단위이고, 안내를 이해한 참가자 비율은 사람이 단위다. 같은 사람이 여러 노트를 누른 기록은 서로 연결된 반복 관측이다. 참가자 수준의 판단에는 사람별 값을 사용하고, 노트 수준의 요약에는 관측 구조를 함께 설명한다.
관련 원자료: Valve · Mike Ambinder · Valve’s Approach to Playtesting · GDC 2009 ↗
가상 예제의 집계 규칙
다운로드 파일과 같은 정의를 사용한다.
| 필드 | 정의 | 단위 |
|---|---|---|
| first_target_missed | 첫 목표의 유효 창 종료까지 성공 입력이 없음 | 세션당 0/1 |
| help_given | 진행자가 조작 안내를 제공함 | 세션당 0/1·제공 시각 |
| completed_unassisted | 조작 안내 없이 결과 화면 도달 | 세션 |
| completed_with_help | 조작 안내를 받은 뒤 결과 화면 도달 | 세션 |
| successes / targets | 성공 확정 목표 수 / 관측한 전체 목표 수 | 노트·세션별 요약 |
| technical_interruption | 실행 오류로 중단됨·원인과 처리 기록 | 세션 상태 |
가상 다섯 세션을 단위별로 읽는다
첨부 예제의 P01~P05는 첫 목표 놓침이 차례로 1·1·1·0·0이다. 따라서 첫 목표를 놓친 세션은 3/5, 60%다. P01과 P02는 조작 안내를 받은 뒤 완료했고, 나머지 세 세션은 자력 완료했다. 자력 완료 비율은 3/5, 60%다.
각 세션의 성공 수는 8·10·11·14·13이며 목표는 모두 16개다. 전체 관측 목표 80개 중 성공은 56개여서 노트 단위 성공 비율은 70%다. 사람별 성공 비율은 50%·62.5%·68.75%·87.5%·81.25%로 읽는다.
첫 목표 놓침, 자력 완료와 노트 성공 비율은 각각 다른 질문에 답한다. 두 세션에는 도중 안내가 제공됐다는 조건도 붙는다. 보고서에는 이번 다섯 가상 세션의 계산 예제로 제시하고, 실제 조사에서는 모집 조건과 관찰 범위에 맞춰 결과를 서술한다.
관련 원자료: Valve · Mike Ambinder · Valve’s Approach to Playtesting · GDC 2009 ↗
가상 다섯 세션의 계산
편집부 학습 예제. 모두 30초·16개 목표를 완료한 가상 기록이며 실제 이용자 수치는 별도 실측한다.
| 세션 | 첫 목표 놓침 | 조작 안내 시각 | 완료 방식 | 성공 / 전체 |
|---|---|---|---|---|
| P01 | 있음 | 6.0초 | 도움 후 완료 | 8 / 16 |
| P02 | 있음 | 5.5초 | 도움 후 완료 | 10 / 16 |
| P03 | 있음 | 없음 | 자력 완료 | 11 / 16 |
| P04 | 없음 | 없음 | 자력 완료 | 14 / 16 |
| P05 | 없음 | 없음 | 자력 완료 | 13 / 16 |
| 집계 | 3 / 5 =60% | 2개 세션 | 자력 3 / 5 =60% | 56 / 80 =70% |
빈도와 진행 영향으로 수정 순서를 정한다
발견 사항 한 건에는 관련 세션, 발생 지점, 진행 영향과 다음 결정을 묶는다. “첫 목표를 놓침”과 “조작을 찾는 데 도움을 요청함”은 같은 장면에서 나타나더라도 각각의 행동으로 기록할 수 있다. 반복 횟수와 실제로 진행을 막은 조건을 함께 보면 수정 순서를 정하기 쉽다.
가상 기록에서는 P01과 P02에 도움을 제공했다. 다음 수정 후보는 연습 시작 전 입력 영역을 미리 보여 주고, 안내에서 실제 플레이로 바뀌는 신호를 정리하는 것이다. P03의 같은 놓침까지 묶어 원기록을 다시 살핀 뒤, 어떤 단서를 본 시점에 차이가 있었는지 확인할 수 있다.
발견 사항에는 관찰 근거, 가능한 설명, 수정안과 재검증 과제를 차례로 적는다. 제작 비용과 영향 범위도 함께 기록한다. 처리 상태는 확인 중·수정 예정·반영·재검증 완료처럼 실제 작업 단계로 관리하며, 다음 빌드의 기록을 이전 근거에 연결한다.
관련 원자료: Valve · Mike Ambinder · Valve’s Approach to Playtesting · GDC 2009 ↗ · Steve Bromley · Choose the right playtest method ↗
발견 사항 한 건의 작성 예
아래 발언과 관찰은 편집부가 작성한 가상 예제다.
| 구분 | 기록 |
|---|---|
| 관찰 | P01·P02에 조작 안내를 제공했다. 첫 목표 놓침은 P01·P02·P03에서 기록했다. |
| 원기록 | P01:4.2초 놓침 / 4.6초 가상 발언 / 6.0초 안내 / 7.0초 첫 입력 |
| 발언 | P01 가상 인용: “시작 안내인 줄 알았어요.” |
| 검토할 설명 | 안내와 실제 플레이 목표를 구별하는 신호의 역할을 확인한다. |
| 수정과 재검증 | 입력 영역·시작 신호 정리 → 새 참가자의 첫 실행·도움·첫 입력 기록 |
조건 비교에서는 학습과 순서를 관리한다
안내 수정 전후를 비교할 때에는 빌드와 바뀐 항목, 음악과 목표 배열, 참가자의 이전 노출을 적는다. 처음 본 사람이 이해하는지를 확인하려면 새 참가자의 첫 실행을 관찰할 수 있다. 같은 사람의 조정 과정을 보려면 반복 실행의 순서와 연습량을 기록한다.
예고 조건 A와 B를 같은 참가자가 경험한다면 제시 순서를 나누고 각 순서를 남긴다. 익숙해짐과 피로가 조건과 함께 바뀔 수 있어 조건별 값과 순서별 값을 함께 검토한다. 입력 오차는 부호 있는 평균과 절대 오차, 놓침 수를 구분하고, 집단 비교에는 참가자별 요약을 준비한다.
Valve 자료의 통계 그림에는 설명용으로 구성한 수치라는 표시가 있다. 이 글의 예제도 계산과 작성 절차를 설명하는 자료다. 실제 보고서의 표에는 실행 환경, 포함 세션, 분석 단위와 관측 기간을 적어 독자가 수치의 범위를 읽을 수 있게 한다.
관련 원자료: Valve · Mike Ambinder · Valve’s Approach to Playtesting · GDC 2009 ↗
보고서의 첫 장에서 다음 결정을 보여 준다
첫 장에는 조사 질문과 주요 발견, 이번 변경과 확인할 다음 행동을 적는다. 본문에는 방법, 참가 조건, 환경, 과제와 도움 규칙, 발견 사항별 근거, 집계표를 배치한다. 부록에는 코드북과 로그 필드, 대본, 원기록 위치와 버전을 둔다.
발견 사항은 짧은 사실 문장 뒤에 근거를 붙여 쓴다. 가상 예제라면 “다섯 세션 중 두 세션에 조작 안내를 제공했다. 입력 영역과 시작 신호를 정리한 뒤 새 참가자의 첫 입력을 관찰한다”처럼 사건과 후속 작업을 연결한다.
첨부 기록표는 사건별 메모, 세션별 집계와 보고서 양식으로 나눴다. 실제 프로젝트에 사용할 때에는 예제 행을 비우고 조사 질문과 도움 규칙부터 확정한다. 같은 운영자가 제작 중인 CAT BEAT의 개발 기록에서도 빌드·조작·목표 시각을 연결하면 수정 이유를 구체적으로 설명할 수 있다.
관련 원자료: Valve · Mike Ambinder · Valve’s Approach to Playtesting · GDC 2009 ↗ · Valve · Kim Swift & Erik Wolpaw · Portal Post-Mortem · GDC 2008 ↗
직접 써보는 파일
오늘도 레벨업이 작성한 학습 예제다. 수정해 사용할 수 있으며, 실제 이용자 기록이나 게임 원본 데이터와는 구분된다.
출처·확인 범위
2026.10.17 확인. Valve 플레이테스트 발표의 PDF 4~25·30~39쪽과 Portal 회고의 13~15쪽, Bromley의 방법 선택 본문, Microsoft 개발자 사이트에 게재된 Parsec 담당자의 사례, NN/g의 질문 작성 본문을 읽었다. 제작사 공개 발표·전문가 방법론·공급사 사례의 성격을 구분해 활용했다. 공개된 내부 원본 리포트 대신 공개 발표에서 설명한 절차를 해석한 글이다. P01~P05와 인용 발언, 시간·집계 수치는 편집부가 작성한 가상 예제이며 CAT BEAT의 실제 이용자 조사 결과는 후속 실측 자료로 관리한다.
- Valve · Mike Ambinder · Valve’s Approach to Playtesting · GDC 2009 ↗
- Valve · Kim Swift & Erik Wolpaw · Portal Post-Mortem · GDC 2008 ↗
- Steve Bromley · Choose the right playtest method ↗
- Microsoft Developer · Parsec 담당자의 Xbox Research 원격 플레이테스트 사례 ↗
- NN/g · Amy Schade · Avoid Leading Questions to Get Better Insights from Participants ↗
- CAT BEAT : 비트를 깨워 · 개발 중 실제 화면 · 이미지 제공 ↗