론칭을 준비하며.

QA 론칭 준비 가이드

1. 서론 — ‘시작의 끝’을 준비하는 일

1️⃣ 론칭, ‘시작의 끝’을 준비하는 일

론칭은 단순히 빌드를 마켓에 업로드하는 절차가 아니다.
그동안의 개발, QA, 기획, 아트, 사업의 모든 결과가 **“유저가 실제로 경험하는 첫 순간”**으로 이어지는 지점이다.
이 시점에서 QA는 단순한 검수자가 아닌, 프로젝트 전체의 마감 품질을 책임지는 마지막 라인이 된다.

따라서 론칭 QA의 본질은 **‘빨리 끝내는 것’이 아니라 ‘안정적이고 정확하게 마무리하는 것’**이다.
이를 위해서는 사전에 체계적인 준비, 명확한 기준, 그리고 일관된 프로세스가 필수적이다.

---

2️⃣ QA 프로세스는 ‘효율’이 아니라 ‘기준’이다

많은 QA가 론칭 시점에서 ‘어떻게 하면 빠르게 테스트를 끝낼까’를 고민하지만,
진정한 효율은 속도에서 비롯되지 않는다.
“누가, 언제, 무엇을, 왜 테스트하는가” — 이 네 가지가 명확해지는 순간부터 효율은 자연스럽게 생긴다.

이 기준이 문서화되지 않으면,
모든 판단이 구두 협의나 기억에 의존하게 되고,
그 결과 “왜 이슈가 발생했는가”를 추적하기 어려운 QA 환경이 만들어진다.

QA 프로세스의 출발점은 ‘문서화’이며,
문서화의 목적은 단순히 ‘기억을 남기는 것’이 아니라,
‘판단의 기준’을 확립하고 팀 전체의 방향성을 일치시키는 것이다

 

---

2. 테스트 전 단계 점검 항목

---

1️⃣ 프로젝트 환경 준비

✔️ 1. 테스트 환경 분리

• 목적: 운영 환경과 QA 환경이 분리되어야 데이터 꼬임, 계정 충돌 방지
• 체크리스트:
  • QA 서버 / 운영 서버 완전 분리 여부 확인 (보통 real환경, qa환경으로 언급) / (stage관련 내용 아래 서술)
  • QA 빌드와 운영 빌드의 버전 넘버 구분 규칙 정립
  • QA용 계정, 결제 키, 테스트 APIKey 분리 적용
  • 내부 DB 초기화 기능 및 계정 리셋 프로세스 확인 (운영툴)

💡 실무 팁:
빌드 버전 관리가 느슨하면 QA 결과를 복구하기 어렵다.
→ 빌드 명명 규칙 예: qa_20251014_v1.03_pre

---

2️⃣ 빌드 수령 및 검증 프로세스 설정

✔️ 1. 빌드 전달 경로 명확화

• 빌드 담당자(개발자/PM) 지정
• 빌드 전달 경로(메일/드라이브/정확한 명칭은 기억안나지만 url통해서 전달) 통일
• 전달 시 “체크리스트 + 커밋 내역” 함께 제공 (현실적으로 어려운 부분이 있겠지만 노력해야된다고 생각함)

✔️ 2. 빌드 검증용 항목

• 실행 여부 (크래시/로딩 확인)
• 버전 정보 표기 정상
• 주요 기능 ON/OFF 여부
• DB / 로그인 / 인앱결제 연동 정상
• 테스트 로그 기능 작동 여부

💡 실무 팁:
처음 받은 빌드는 “테스트용 빌드”가 아닌 “QA 환경 셋업용 빌드”로 생각하자.
→ 실제 QA 돌리기 전에 환경 안정성부터 본다.

---

3️⃣ QA 문서/툴 세팅

✔️ 1. 문서 템플릿 준비

• 테스트케이스 (TC) 문서 기본 템플릿 생성
• 이슈리포트 폼 (Issue ID, Title, Repro Step, 환경 등)
• QA 일정표 및 우선순위 관리표

✔️ 2. 협업 툴 준비

• 공유 문서: Google Sheet / Notion / Jira / Trello 등 > 보통 사용하는 메신저 + 전달 방식을 선정
• 공통 태그 규칙 (ex. [UI], [Server], [Crash])
• QA 로그/스크린샷 저장 폴더 구조 확립

💡 실무 팁:
초기엔 한 시트에 다 적어도 상관없지만,
“결과와 수정 이력”은 반드시 분리해야 한다. (TC와 이슈 리포트는 별도)

---

4️⃣ 테스트 범위 정의 및 우선순위 설정

✔️ 1. 테스트 범위 명시

• 기능 테스트 범위
• 퍼포먼스(프레임, 로딩 등)
• UI/UX 검수
• 네트워크 / 서버 검증
• 호환성 (기기별/OS별)

✔️ 2. 우선순위 규칙

분류설명예시

P1	론칭 지연 유발급	크래시, 결제 불가, 로그인 오류
P2	유저 체감 불편	UI 깨짐, 번역 누락, 진행 불가 퀘스트
P3	사소한 오류	텍스트 오타, 경미한 애니매이션 끊김

💡 실무 팁:
‘모든 오류를 잡는다’는 발상보다,
“유저가 게임을 시작할 수 있는지” → “유저가 끝까지 진행 가능한지”
이 두 단계 중심으로 잡아라.

---

5️⃣ 커뮤니케이션 라인 구축

✔️ 1. 담당자 라인 명확화

구분담당자역할

기획	OOO	기능 의도 / 버그 판단
개발	OOO	수정 및 빌드 반영
서버	OOO	API/DB 확인
QA	나 / 팀원들	검증 및 재확인

✔️ 2. 보고 체계

• 일일 테스트 진행 상황 공유 (하루 1회 이상) > 개인적인 생각으로 일정이 긴 론칭 진행 중에는 1일 1회 결과전달이 필요하다고 생각함
• 이슈 상태: 신규 → 확인중 → 수정요청 → 수정완료 → 재검증완료
• 수정 확인 시, 동일 항목 중복보고 금지 룰 설정

💡 실무 팁:
QA는 결국 “이슈를 빠르게 닫는 구조”가 중요하다.
이슈가 계속 열려있으면 일정이 지연된다.
→ “담당자 지정 + 상태 업데이트 시간”을 루틴화하라. + 중요도에 따른 우선순위 선정이 중요하다!

---

6️⃣ 일정 및 마일스톤 관리

• 론칭 목표일 기준 T-일 단위로 QA 스케줄 작성
• 기능 동결일(Code Freeze) 명시
• 리그레션(Regression) 일정 확보 (최소 2일)
• 긴급 수정 대비 “핫픽스 QA 시간” 확보

💡 실무 팁:
개발 일정(개발도 QA도 어쩔수 없는 부분이지만..)에 끌려다니지 않으려면,
QA 마감일이 아니라 QA 시작일을 먼저 명시해야 경험상 유용했다.

---

7️⃣ 보안 및 외부 검수 대응 준비

• 외부 검수(스토어 심사/보안 테스트) 일정 확인
• 개인정보 처리/결제 모듈 점검
• 로그 서버 접근 권한 관리
• 경험 기반으로 이 프로세스는 1차 개발빌드가 나왔을때 하는것이 좋다고 생각한다.
  -1차 개발빌드가 진행 위주의 기능에 추가 이슈가 없을때, 크로스로 진행하는것

💡 실무 팁:
스토어 반려는 QA의 영역 밖이라 생각하기 쉽지만,
“QA가 미리 체크한 보안/심사 항목”이 반려율을 낮춘다.

---

✅ 마지막 점검

항목상태

QA 서버 접근 가능 여부	☐
QA 빌드 실행 및 로그인 정상	☐
테스트 계정/결제키 세팅 완료	☐
문서·툴 세팅 완료	☐
이슈 관리 프로세스 확립	☐
일정표 및 마일스톤 공유 완료	☐

---

📘 결론

QA의 시작은 테스트가 아니다.
‘테스트할 준비가 완벽히 되어 있는지 점검하는 것’, 그게 론칭 QA의 첫 단계라고 생각한다.

이 시점에서 중요한 건 버그를 얼마나 빨리 찾느냐가 아니라, 테스트 환경과 기준이 얼마나 ‘확실히’ 세팅되어 있느냐다.
'빌드 전달 체계, 문서화 기준, 커뮤니케이션 라인'  이 세 가지가 정리되지 않으면 QA는 시작부터 흔들린다.

준비단계를 정확히 잡아두면 QA팀의 하루는 우왕좌왕하는 반복이 아니라, 명확한 기준 위에서 움직이는 확신의 사이클이 된다.

론칭을 준비한다는 건, 테스트를 빨리 돌릴 준비가 아니라 흔들리지 않는 구조를 세우는 일이다.
이 준비가 끝나는 순간, 비로소 QA는 “테스트를 시작할 자격”을 갖게 된다.