9장. 개발 프로세스 속에서 QA의 위치

QA는 종종 개발의 마지막 단계에서 등장하는 역할로 오해받습니다. 모든 기능이 완성된 뒤, 문제를 찾아내는 사람이라는 이미지 때문입니다.

하지만 실제 개발 현장에서 QA는 그렇게 단순한 위치에 있지 않습니다. QA는 개발의 끝에 서 있는 존재가 아니라, 전 과정을 관통하는 역할입니다.

---

게임은 단계적으로 만들어진다

게임 개발은 한 번에 완성되지 않습니다. 기획, 프로토타입, 제작, 테스트, 출시, 운영이라는 여러 단계를 거칩니다.

각 단계마다 목표가 다르고, 발생하는 문제의 성격도 다릅니다. 이 흐름을 이해하지 못하면 QA는 항상 늦게 도착한 사람이 됩니다.

QA는 각 단계에서 다른 질문을 던져야 합니다.

• 기획 단계: 이 설계는 구현 가능한가
• 제작 단계: 의도한 대로 동작하는가
• 테스트 단계: 문제가 반복적으로 발생하는가
• 운영 단계: 실제 유저 환경에서도 유지되는가

---

QA는 언제부터 개입해야 하는가

이상적인 QA는 가장 이른 시점부터 프로젝트에 참여합니다.

프로토타입 단계에서의 QA는 버그를 찾지 않습니다. 대신 방향을 확인합니다. 재미의 가능성이 있는지, 구조적인 리스크는 없는지, 나중에 고치기 어려운 선택은 무엇인지 살펴봅니다.

QA가 초기에 던진 질문 하나는, 나중에 수십 개의 버그 리포트를 줄여줍니다.

---

개발자와 QA의 관계

QA는 개발자의 적이 아닙니다. 문제를 들추는 사람도 아닙니다.

QA의 목적은 동일합니다. 게임을 더 나은 상태로 완성하는 것. 다만 접근 방식이 다를 뿐입니다.

개발자는 만들고, QA는 검증합니다. 이 역할이 충돌하는 것처럼 보일 때는 대부분 목표가 아니라 타이밍의 문제입니다.

QA가 제 역할을 하기 위해서는, 비난이 아니라 설명의 언어를 사용해야 합니다.

---

일정과 품질 사이에서

모든 프로젝트에는 일정이라는 현실적인 제약이 존재합니다. 모든 문제를 고칠 수는 없습니다.

이때 QA의 역할은 ‘다 고쳐야 한다’고 주장하는 것이 아닙니다. 무엇을 포기하고, 무엇을 지켜야 하는지 판단할 근거를 제공하는 것입니다.

• 지금 고치지 않으면 치명적인 문제는 무엇인가
• 출시 이후로 미뤄도 되는 문제는 무엇인가
• 어떤 리스크를 감수하고 있는가

QA는 이 질문에 답할 수 있어야 합니다.

---

QA는 개발 언어와 유저 언어의 중간에 선다

개발자는 시스템의 언어를 사용하고, 유저는 경험의 언어를 사용합니다.

QA는 이 둘 사이에 서서 번역하는 역할을 합니다. 유저의 불만을 개발자가 이해할 수 있는 문제로 바꾸고, 개발의 선택을 유저 경험의 관점에서 설명합니다.

이 위치를 이해하지 못하면, QA는 항상 양쪽에서 불만을 듣게 됩니다.

---

이 장을 마치며

QA의 위치는 개발 프로세스 안에서 고정되어 있지 않습니다. 상황에 따라 앞에 서기도 하고, 뒤에서 받치기도 합니다.

중요한 것은 자리가 아니라 역할입니다. QA는 개발 흐름 전체를 바라보며, 품질이라는 기준을 지켜내는 사람입니다.