Game Quality Assurance
작동 여부를 확인하는 데서 멈추지 않고, 플레이어가 겪을 불편과 운영 과정에서 반복될 문제까지 살핍니다. 6년 이상의 라이브 QA 경험으로 테스트를 설계하고, 반복 검수는 줄여 게임을 직접 확인할 시간을 확보해 왔습니다.
자동화는 QA의 판단을 대신하지 않습니다. 판단 전에 반복되는 일을 덜어내는 도구로 사용합니다.
기획 의도, 플레이 흐름, 업데이트 이후의 영향 범위까지 확인해야 합니다.
기능이 명세대로 동작하는지 확인하고, 상태 변화와 연계 기능까지 범위를 넓혀 봅니다. 출시를 막을 문제와 이후 추적할 문제를 나누어 일정 안에서 우선순위를 정합니다.
반복 작업은 자동화하지만, 확보한 시간은 다시 게임을 직접 플레이하고 판단하는 데 사용합니다.
대규모 테스트와 이슈를 단순 처리량으로 보지 않았습니다. 변경 범위, 일정, 담당자의 숙련도와 출시 위험을 함께 판단했습니다.
개발과 라이브 QAPC MMORPG와 모바일 게임에서 기능·개발·FUN·리그레션 QA를 수행했습니다.
업데이트 단위 테스트 운영고정 회귀 범위와 변경 사양 범위를 나누고 담당자와 일정을 배정했습니다.
업데이트 단위 이슈 추적재현 조건과 영향 범위를 확인하고 수정 빌드와 연관 기능까지 이어서 검증했습니다.
양국 라이브 서비스공통 기능과 국가별 데이터, 일정, 빌드 차이를 구분해 확인했습니다.
테스트 실행뿐 아니라 기획서 검토, 범위 도출, 일정 산정, 인원 배분, 이슈 추적과 결과 보고까지 업데이트 사이클을 운영했습니다.
QA · 대리
Game QA · Project Management
Game QA
사용한 기술보다 먼저, 어떤 상황에서 무엇을 문제로 보고 어떻게 범위를 나눴는지 정리했습니다.
업데이트 직전까지 바뀌는 사양에서도 검증 범위와 우선순위를 유지한 방식
Workflow
라이브 업데이트 직전까지 기획 수치와 사양이 변경되는 경우가 있었습니다.
전체 테스트 케이스를 매번 다시 수정하면 변경을 놓치기 쉽고 일정도 예측하기 어려웠습니다.
항상 확인해야 하는 범위와 계속 변하는 범위를 분리해야 했습니다.
고정 회귀 체크리스트와 변경 사양용 테스트 케이스를 나누고, 변경 이력을 별도 추적했습니다. 영향 범위가 큰 항목부터 검증했습니다.
업데이트 직전 변경에도 범위를 다시 정리하기 쉬워졌고, 누락 가능성과 일정 혼선을 줄일 수 있었습니다.
좋은 테스트 케이스는 많이 작성된 문서가 아니라, 변경 상황에서도 무엇을 먼저 확인해야 하는지 알려주는 문서라고 생각합니다.
반복 비교는 도구에 맡기고 불일치 후보와 최종 판단에 집중한 검수 흐름
Automation Workflow
다수의 인게임 아이템 이름, 수치, 옵션, 태그를 기준 데이터와 반복 비교해야 했습니다.
화면과 데이터 시트를 계속 번갈아 확인하면 시간이 오래 걸리고 비슷한 항목에서 실수가 생길 수 있었습니다.
모든 판단을 자동화하기보다 반복 비교만 도구에 맡기고 최종 판단은 QA가 해야 했습니다.
스크린샷의 텍스트와 수치를 추출해 기준 데이터와 비교하고 Pass·Fail 후보를 나눴습니다. OCR 결과는 교차 비교하고 인식이 불확실한 항목을 따로 모았습니다.
모든 항목을 처음부터 읽는 대신 불일치 항목과 인식이 불확실한 항목을 중심으로 확인할 수 있었습니다.
자동화는 QA의 판단을 대신할 때보다, 판단하기 전의 반복 작업을 줄일 때 더 안전하고 실용적이었습니다.
팀이 이미 사용하는 업무 흐름 안에서 문서 탐색 단계를 줄인 사례
Search Workflow
사양서, 테스트 케이스, 이전 이슈가 여러 문서와 저장소에 나뉘어 있었습니다.
간단한 확인에도 여러 파일을 열어야 했고 오래된 내용과 최신 내용을 구분하는 데 시간이 들었습니다.
새 문서 시스템보다 팀이 이미 쓰는 Slack에서 필요한 자료를 찾게 하는 편이 실제 사용성이 높다고 봤습니다.
Slack 명령으로 사양서와 QA 자료를 검색하고 관련 근거와 요약을 함께 보여주는 보조 도구를 구성했습니다.
반복 질문과 문서 탐색 단계를 줄이고 QA 시작 전에 참고 자료를 빠르게 모을 수 있었습니다.
도구의 기능 수보다 실제 업무 흐름 안에 자연스럽게 들어가는지가 더 중요했습니다.
결과물은 문서의 양보다 다음 업데이트에서 다시 사용할 수 있는지를 기준으로 정리했습니다. 공개 가능한 샘플만 제공합니다.
PUBLIC SAMPLE · TOOL
아이템 소환, 착용, 전투, 해제를 반복하는 수동 조작을 줄이기 위해 만든 AutoHotkey 샘플입니다. 공개 전 실제 아이템 정보는 샘플 값으로 치환했습니다.
WORKING METHOD · DOCUMENTATION
테스트 케이스, 체크리스트, 버그 리포트, 일정표, 결과 보고서가 같은 기준으로 이어지도록 템플릿과 작성 규칙을 정리했습니다.
회사 고유 데이터와 내부 문서는 공개하지 않습니다. 공개 파일은 식별 가능한 값을 제거한 샘플입니다.
숙련도를 별점으로 표시하지 않았습니다. 실제 업무에서 어떤 목적으로 사용했는지 적었습니다.
기능 QA, 개발 QA, FUN QA, 리그레션 QA. 정상·예외 흐름, 경계값, 상태 변화, 데이터 저장, 연계 기능과 악용 가능성을 확인합니다.
기획서와 개발 일정을 바탕으로 범위를 도출하고 일정·난이도·담당자 숙련도에 맞춰 인원을 배분합니다. 출시 차단 이슈와 잔여 위험을 구분합니다.
Redmine · Mantis · Notion · Trello
테스트 케이스, 고정 체크리스트, 버그 리포트, QA 결과 보고서의 형식과 상태값을 통일하고 변경 이력을 추적합니다.
Excel · Google Sheets · MS Office · Notion
프로젝트별로 달랐던 문서와 보고 기준을 공통 규격으로 정리하고, 반복되는 검증 항목을 다음 업데이트에 다시 쓸 수 있는 자산으로 남깁니다.
기준이 명확한 반복 비교와 자료 검색을 자동화합니다. 결과는 불일치 후보와 근거를 중심으로 보여주고 최종 판단은 QA가 수행합니다.
Python · OCR · n8n · Gemini · Claude · Codex
빌드 확인, 이슈 추적, 데이터 검수, 프로젝트 협업에 필요한 도구를 업무 흐름에 맞춰 사용했습니다.
Unity · SVN · Gamepot · Slack · Figma · Google Workspace
게임 수를 나열하기보다 얼마나 깊게 플레이했는지를 보여주는 것이 중요합니다. 장기 라이브 서비스, 고난도 도전, 다회차와 수집 완료 경험을 중심으로 정리했습니다.
2026년 8월 기준 자체 기록 113개. 동일 타이틀의 플랫폼별 기록은 각각 포함했습니다.
라이브 게임 QA 운영, 테스트 설계, 프로세스 개선 경험에 관해 이야기 나눌 수 있습니다.
김진영 · Game QA Engineerssun0749a@naver.com