Cover · Issue 023
"모든 물줄기는 결국 가장 좁은 목을 통과한다. 그 전까지 강은 넓고 조용하다."
TSTF MAG · 2026
게임 개발 후반부, QA는 여전히 "검수자"로 불려 들어온다. AI가 테스트 케이스를 자동으로 뽑아주는 지금도, 그 호출 타이밍은 바뀌지 않았다. 품질을 보는 눈이 마지막 관문에만 놓인 구조 — 그 관성 안에 더 오래된 질문이 숨어 있다.
QA는 게임 개발의 마지막 문 앞에 선다. 기획이 완성되고, 개발이 마무리되고, 아트가 붙은 뒤 — 그때 처음 불린다.
"품질을 보는 눈이 마지막 관문에만 놓여 있다면 — 그 눈은 항상 늦게 뜬다."
— 편집부 관찰 · 2026.05이 순서는 게임 산업이 생겨난 이래 거의 바뀐 적이 없다. AI가 테스트 케이스를 자동으로 뽑고, 버그 재현 시나리오를 생성해주는 지금도 — 그 타이밍은 그대로다. 도구가 바뀌었는데, 구조는 그대로다.
이번 호는 그 "마지막"이라는 배치 안에 담긴 것을 들여다본다. 타이밍 문제처럼 보이는 것이, 사실은 더 오래된 질문을 감추고 있다. 품질을 누가 소유하는가.
QA를 마지막에 부르는 일은, 많은 팀에서 여전히 당연하게 받아들여진다. 이상하게 느끼는 사람이 드물다는 것이 오히려 이상하다. 이 순서가 굳어온 이유, 그 안에서 QA가 알고 있던 것, AI가 바꾼 것과 바꾸지 못한 것 — 그리고 그 안에 숨어 있는 진짜 문제. 네 조각으로 나눠 본다.
"만들고 나서 검사한다"는 흐름은, 게임보다 훨씬 오래된 관성이다. 설계하고, 개발하고, 테스트하고, 배포하는 순서가 표준처럼 자리 잡으면서 게임 개발도 같은 틀 위에서 자랐다. 거기에 현실적인 이유가 더해진다. QA를 처음부터 두는 건 비용이다. 아직 아무것도 없는데 뭘 테스트하겠느냐고.
그래서 QA는 항상 "나중에" 부르는 직군이 됐다. 그 "나중에"가 개발 후반 두 달이고, 어떤 팀에선 출시 직전 3주다. 아무도 이상하다고 말하지 않았기 때문에, 이 구조는 계속 굳어졌다.
QA는 그 게임을 가장 이상한 방식으로 해본 사람들이다. 기획서에 없는 경계를 밟고, 플레이어가 절대 하지 않을 것 같은 조합을 시도해본다. 이 경험은 개발 초반에도 똑같이 유효하다.
"이 동선은 플레이어가 헷갈릴 것 같다." "이 UI는 실제로 쓰면 이 시점에서 막힌다." 이런 관찰은 기획 단계에서 가장 저렴하게 고칠 수 있는 것들이다. 그런데 QA는 기획이 끝나고 나서야 온다. 오래 이 자리에 있었던 사람들이 알고 있었던 것들 — 그것이 마지막에 부르는 구조 안에서 어떻게 쓰이지 못하고 있는지가 이 주제의 핵심이다.
AI는 반복 테스트를 잘한다. 케이스를 자동으로 뽑고, 리그레션을 혼자 돌리고, 버그 재현 시나리오를 생성한다. QA의 반복 작업 상당 부분이 줄었다.
그런데 AI는 이 판단을 하지 않는다. "이 기능 자체가 처음부터 잘못 기획됐다." 버그를 재현하는 것과, 기획의 전제가 틀렸다는 것을 보는 것은 다른 능력이다. AI가 반복 작업을 가져간 자리에, 그 판단 역할이 더 중요해졌다. 그런데 그 판단은 마지막에 와서는 이미 늦다.
"마지막에 부른다"는 타이밍을 파고들면, 여기에 닿는다. 품질 검증이 QA의 일이라는 암묵적 합의. 개발팀은 만들고, QA는 확인한다 — 이 역할 분리가 굳어지면서, 품질에 대한 소유권도 자연스럽게 나뉘었다.
그 결과 — "QA가 잡아낸 버그"가 되지, "개발이 심어놓은 버그"가 되지 않는다. 책임의 언어가 다르다. QA는 자신이 만들지 않은 문제를 혼자 들고 서 있는 셈이다.
Note 발견 비용은 시점이 늦을수록 급격히 커진다. 기획 단계에서 발견된 문제와, 개발이 완료된 뒤 발견된 문제는 수정에 드는 비용이 같을 수 없다. 이 사실이 잘 알려져 있어도 구조는 좀처럼 바뀌지 않는다 — 타이밍 문제로 보는 한, 해결책이 "더 일찍 부른다"에서 끝나고 마는 이유가 여기 있다.
이 문제를 타이밍의 문제로 보면, 해결책은 단순해 보인다. "QA를 더 일찍 불러라." 그런데 타이밍을 바꿔도, 역할 구조가 그대로라면 QA는 여전히 "검수자"로 온다. 위치가 앞으로 당겨졌을 뿐이다.
렌즈를 바꾸면 다른 것이 보인다. 타이밍이 아니라 소유권의 문제로 보는 것이다. 품질이 누구의 것인가 — 이 질문이 달라지면, QA가 어디에 있어야 하는지도 달라진다.
| 타이밍 문제로 보면 | 소유권 문제로 보면 | |
|---|---|---|
| 핵심 질문 | 언제 부르는가 | 누가 책임지는가 |
| 해결책 | 더 일찍 불러라 | 소유 구조를 바꿔라 |
| QA의 역할 | 검수자 | 품질 판단 참여자 |
| AI 도입 후 | 반복 작업 효율화 | 판단 역할 더 중요해짐 |
| 남는 문제 | 타이밍 최적화 | 책임 소재의 재정의 |
표의 오른쪽 열이 더 어려운 이유는 분명하다. 타이밍은 일정표에서 조정할 수 있지만, 소유 구조는 팀 문화 안에 깊이 박혀 있다. 바꾸려면 여러 직군이 함께 동의해야 하고, 그게 쉽지 않다. 그래서 많은 팀이 "더 일찍 부른다"에서 멈춘다 — 더 근본적인 질문에 닿지 않은 채로.
소유 구조가 바뀌지 않으면, 몇 가지가 계속해서 반복된다.
이 이야기는 멀리 있지 않다. 지금 당신이 있는 팀에서, QA는 언제 처음 들어오는가. 첫 기획 회의부터인가, 개발이 한창 진행된 뒤부터인가.
AI 테스트 자동화가 팀 안으로 들어오면서 이 질문은 더 날카로워졌다. 반복 작업이 줄어든 자리에서, QA가 진짜 해야 할 일이 무엇인지가 더 선명하게 드러나기 때문이다. 케이스를 천 개 뽑는 것은 이제 도구가 한다. "이 기능이 처음부터 옳은 방향인가"를 묻는 일은 아직 사람이 해야 한다.
그 사람이 마지막에만 온다면 — 그 물음은 언제나 늦게 도착한다.
몇 가지를 같이 생각해볼 만하다.
이번 호의 결론을 당신에게 미룬다. 답은 정해두지 않았다. 점심 자리에서 한 번쯤 꺼내보길 바라는 질문들이다.
기획 단계부터인가, 개발 후반부터인가. 그 타이밍이 지금의 것이 된 이유가 있는가 — 아니면 그냥 그렇게 돼왔는가?
있다면 — 그때 팀이 배운 것은 무엇인가. 그 경험이 다음 프로젝트의 구조를 바꿨는가, 아니면 그냥 넘어갔는가?
QA의 것인가, 팀 전체의 것인가. 그것이 명시적으로 정해진 적 있는가 — 아니면 암묵적으로 어딘가에 올려져 있는가?
이번 호의 출발점은 간단한 관찰이었다. AI가 테스트 자동화를 가져왔는데, QA가 참여하는 시점이 달라지지 않았다는 것. 도구는 바뀌는데 구조는 그대로인 상황이 흥미로웠다.
파고들수록 타이밍 문제가 아니라는 생각이 강해졌다. 타이밍을 바꿔봤자 역할 구조가 그대로라면, QA는 여전히 마지막 관문에 서 있는 사람이 된다. 위치는 앞으로 당겨지지만, 하는 일의 성격은 그대로다.
진짜 질문은 "언제 부르느냐"가 아니라 "품질을 누가 소유하는가"라는 것 — 이게 이번 호의 중심이었다. 쉬운 해결책은 아니다. 소유권 구조는 일정표 안에서 고치기 어렵고, 팀의 문화 안에 깊이 박혀 있다. 그래도 질문을 정확하게 갖고 있는 것이, 잘못된 해결책을 빠르게 반복하는 것보다는 낫다.
이 글이 어떤 자리에서든 그 질문을 꺼내는 계기가 되길 바란다.
— Desk γ팀 안에서 조용히 사라지는 판단의 흔적에 대하여.