본문 바로가기

QA노하우

[QA 실전 노하우] 3편. 쏟아지는 빌드와 결함 속에서 중심 잡기: 실시간 빌드 검수와 결함 통제

계획(QA Plan)이 완벽하더라도, 라이브 배포 직전의 실전 빌드 검수 단계는 늘 예측 불가능한 변수로 가득하다.
최적화 및 유니티 버전 업데이트가 동시에 진행되던 당시, 하루에도 몇 개씩 빌드(Dev_0.1.38_614, 615, 618, 629 등)가 쏟아졌고 현장은 혼란 그 자체였다.

인력과 시간이 한정된 중소기업 환경에서, 쏟아지는 버그와 불안정한 빌드를 통제하며 프로젝트를 라이브까지 이끌었던 실시간 결함 관리 노하우를 공유한다.

 

1. 무너진 빌드 퀄리티 앞에서의 결단: TC 중단과 애드혹(Ad-hoc) 전환
ex)

 

당시 수령한 초기 빌드들은 최적화 여파로 인해 진행 불가(Blocking) 이슈와 정합성 의심 결함이 다수 발견되는 등 퀄리티가 매우 낮았다. 이로 인해 정상적인 QA 진행 자체가 불가능한 상황이었다.

이때 내린 결단은 '전수 조사(TC 수행) 중지 및 애드혹(게릴라성) 테스트 전환'이었다.

내가 세운 판단의 기준은 단호했다. "기존에 잘 작동하던 핵심 기능(1뎁스)이 작동하지 않으면 전수 조사를 진행하지 않는다." 최소한 Medium 등급 이상의 크리티컬한 이슈들이 모두 조치되고 빌드가 안정화된 상태여야만 촘촘한 TC 수행이 의미가 있기 때문이다. 빌드가 망가진 상태에서 고정된 TC만 고집하는 것은 리소스 낭비다.
과감히 전수 조사를 멈추고, 애드혹 테스트를 통해 치명적인 버그들을 먼저 솎아내며 빌드 안정성을 확보하는 데 집중했다.

 

2. 커뮤니케이션 비용 최소화: DM 지양 및 전체 채널 기반의 진행 상황 투명화

실시간 QA의 또 다른 복병은 시스템의 누락이었다. 아사나(Asana) 내에서 개발팀의 작업 현황 업데이트가 누락되다 보니, 이 이슈가 실제 작업이 완료되어 발생한 버그인지 아니면 아직 개발 중인 미완성 상태인지 QA 파트에서 확인하기가 어려웠다.

이때 개별적인 구두 확인이나 1:1 DM(다이렉트 메시지)을 통한 소통은 철저히 지양했다.
실무자 간의 파편화된 소통은 히스토리 추적을 어렵게 만들고, 동일한 질문을 반복하게 해 커뮤니케이션 비용을 가중시키기 때문이다.

대신 사내 전사 메신저 채널을 통해 관련 담당자들을 함께 멘션하고, "현재 이 작업의 업데이트가 누락되어 QA 진행이 어렵다"는 상황을 투명하게 공유했다.
공유 관련 업무를 단 한 번으로 일원화함으로써 모든 유관 부서가 실시간 빌드 상태와 병목 구간을 동시에 인지하게 만들었고, 결과적으로 개발팀의 피드백과 프로세스 준수 속도를 획기적으로 끌어올렸다.

 

 

3. 개발팀과의 결함 관리 밀당: 우선순위 선별의 4가지 원칙

애드혹과 전수 조사를 거쳐 발견된 결함들은 아사나 버그 프로젝트에 독자 티켓으로 등록했다.

라이브 점검 및 배포 일정이 코앞인 상황에서 개발팀장 및 유관 부서와 "High 이상 크리티컬 이슈 우선 수정"과 "마이너 이슈 차수 이월"을 협의해야 했다.

이때 덤덤하게 개발팀을 설득하고 합의를 이끌어낸 나만의 결함 우선순위 선별 원칙 4가지는 다음과 같다.

  1. 발생 빈도: 유저들에게 얼마나 자주 노출되는 결함인가?
  2. 플레이 진행 가능 여부: 게임 진행을 막는 치명적인 블로킹 이슈인가?
  3. 불편함의 정도: 플레이 흐름이나 UX를 얼마나 심각하게 해치는가?
  4. 전체 퀄리티 저하 판단: 마이너한 버그일지라도 유저가 보기에 게임의 전반적인 완성도가 낮아 보이게 만드는 요소인가?

이 4가지 기준을 바탕으로 결함의 경중을 날카롭게 발라내어 개발팀에 전달했다.

덕분에 개발 리소스를 오롯이 치명적인 결함 수정에만 집중시킬 수 있었고, 사소한 이슈로 일정이 밀리는 리스크를 방어했다.

마치며 실시간 QA 단계는 빌드를 검증하는 것을 넘어, 무너지는 빌드 퀄리티의 제동을 걸고 흩어진 개발 상황을 정렬하는 통제 센터의 역할을 해야 한다.

단호한 TC 중단 결정, 전체 공유를 통한 커뮤니케이션 일원화, 명확한 기준 기반의 결함 관리가 시너지를 낸 덕분에, 혼란스러웠던 업데이트 빌드를 빠르게 안정화 단계로 끌어올릴 수 있었다.

다음 4편에서는 이렇게 걸러진 최종 빌드를 바탕으로 유관 부서 및 경영진에게 어떻게 데일리 상황을 보고하고 리스크를 투명하게 소통했는지 다루어 보겠다.