QA에서 받은 목록에는 버튼 간격, 빈 상태 문구, 로그인 복귀, 날짜 표시처럼 서로 달라 보이는 항목이 많았다. 처음에는 위에서부터 하나씩 고치면 된다고 생각했다. 몇 건을 처리하자 같은 원인이 다른 화면에서 반복되고 있다는 게 보였다.
버그 목록은 실패 사례의 모음이면서 문서에 적히지 않은 제품 규칙을 보여주는 자료였다.
증상 이전의 기대 규칙
“화면 A에서 버튼이 보인다”를 그대로 수정하면 화면 B에서 같은 문제가 남았다. 각 항목을 현재 동작, 기대 동작, 적용 범위로 바꿔 적었다.
증상: 계좌가 없는데 주문 버튼이 활성화됨
규칙: 주문 가능한 계좌가 없으면 모든 진입점 비활성
범위: 메인, 차트, 빠른 주문 팝업
규칙으로 바꾸니 함께 확인해야 할 화면과 코드 경계가 생겼다.
공통 원인과 개별 예외의 구분
다국어 레이아웃 문제 여러 건은 공통 버튼 컴포넌트에서 해결할 수 있었다. 반면 같은 빈 상태라도 계좌 없음과 조회 결과 없음은 다음 행동이 달랐다. 무리하게 한 문구와 동작으로 합치지 않았다.
수정 전에는 관련 항목을 묶고, 공통 파일을 바꿀 때는 목록에 없던 기존 화면 회귀도 확인했다.
같은 증상이더라도 원인이 다른 항목은 억지로 한 수정에 넣지 않았다. 예를 들어 버튼 비활성은 권한 규칙 문제일 수도 있고 화면 초기화 순서 문제일 수도 있었다. 재현 조건과 로그가 다른 경우에는 별도 원인으로 남겼다. 목록을 예쁘게 묶는 것보다 수정 범위를 정확히 잡는 편이 중요했다.
재현 조건의 회귀 테스트
환경, 계정 상태, 화면 진입 경로, 동작 순서, 기대 결과를 짧게 정리했다.
조건: 활성 계좌 0개
경로: 로그인 -> 메인 -> 빠른 주문
기대: 주문 버튼 비활성, 계좌 생성 안내
확인: 재로그인·언어 변경 뒤에도 동일
수정 직후 한 번 성공하는 것보다 상태가 바뀐 뒤에도 규칙이 유지되는지 봤다.
검증 결과에는 통과 여부만 쓰지 않고 어떤 빌드와 조건에서 확인했는지를 남겼다. 자동화하기 쉬운 데이터 변환은 테스트로 옮기고, 화면 크기나 문구 균형처럼 사람이 봐야 하는 부분은 대표 조합을 정했다. 같은 항목이 다시 들어왔을 때 과거 수정의 증거를 찾을 수 있었다.
개발 명세로서의 QA
예전에는 구현이 끝난 뒤 잘못된 부분을 찾는 단계로만 생각했다. 여러 항목을 분석하면서 QA 사례가 요구사항의 빈틈과 코드 경계의 약한 부분을 알려준다는 걸 배웠다.
그 뒤 버그를 고칠 때 해당 줄만 바꾸지 않고 어떤 규칙이 깨졌는지 먼저 말로 적는다. 규칙을 이해하면 비슷한 문제를 한꺼번에 막을 수 있고, 예외가 필요한 곳도 더 분명해졌다.
후속 확인 항목
나중에 같은 증상을 다시 만나지 않으려고 문서에 적힌 기준으로 구현을 한 번 더 정리했다.
V8의 WasmGC 설명에서 중요한 점은 구조체와 배열을 호스트의 garbage collector가 관리할 수 있게 하는 실행 모델 변화다. 하지만 명세와 브라우저 지원이 생겼다고 Unity 빌드가 곧바로 그 이점을 얻는 것은 아니다. 언어 toolchain과 엔진이 해당 기능을 내보내야 한다.
Wasm의 CPU 실행·메모리 층과 WebGPU의 그래픽 제출 층을 나누면 같은 끊김도 parsing·allocation 문제인지 shader·pipeline 문제인지 다른 증거를 모을 수 있다.
다음에 QA 목록에서 발견한 숨은 명세 같은 문제를 보면 아래 순서부터 확인하려고 한다.
- 재현 조건을 상태와 데이터로 분리
- 테스트 종료 뒤 정리할 저장 값
- 기대 결과의 근거 문서
- 재현되지 않을 때 남길 환경 정보
브라우저 지원, 빌드 산출물 feature, 엔진 공식 지원을 각각 확인하고 하나의 지원 여부로 합치지 않아야 한다.
공식 참고 자료
- V8 WasmGC 포팅 안내 — WasmGC의 구조체·배열과 툴체인 경계
- Chrome 113 WebGPU 공개 문서 — 초기 WebGPU 지원 범위와 런타임 기능 감지