QA 요청이 완료 확인이 되지 못했을 때 — 검증 가능한 장면을 만들어 닫기

내부 private repo 작업을 바탕으로 썼다. 외부 접근이 불가한 저장소라 링크 없이, 조직·시스템·사람을 식별할 수 있는 정보는 걷어내고 구조만 남긴다.

QA 환경에 배포하고 기획자에게 확인을 요청했다. 이튿날 아침 “오늘은 다른 배포가 있어 오후에 확인하겠다” 는 답이 왔고, 같은 답글에 운영 배포는 3주 뒤 제휴사 일정에 맞춰야 한다는 말이 붙었다. 그걸로 이 건은 내 쪽에서 “요청 완료, 배포 대기” 가 됐다.

12일 뒤, 다른 조직의 QA 담당자가 이 티켓이 착수 전인지 배포 대기인지를 물었다. 배포 대기라고 답했고, 이어진 확인 결과 QA 는 아직 진행되지 않은 상태였다. 요청은 갔고 확인하겠다는 답도 받았지만, 검증은 시작되지 않은 채로 12일이 지나 있었다.

TL;DR

• “확인 요청” 과 “확인하겠다” 는 답이 오가도 검증이 시작됐다는 뜻은 아니다. 요청·착수·완료는 서로 다른 상태이고, 나는 요청 상태를 완료로 읽고 있었다.
• 다시 배포하자 43분 만에 구체적인 문제가 왔다. “브릿지의 버튼 동작을 확인할 수 없다. 화면이 너무 빨리 넘어간다.” 검증할 사람이 검증할 장면에 도달하지 못하는 상태였다.
• 그 장면을 만들어 보냈다. 통합회원 확인 응답만 붙잡아 브릿지를 멈추고, 진입 지면 세 곳을 각각 녹화해 “이 화면에서 시작해 이 화면으로 돌아온다” 한 줄과 함께. 이틀 뒤 앱 흐름까지 확인됐다.
• 하네스에서 화면을 붙잡을 때 응답을 바꾸면 화면이 바뀐다. 늦추면 화면은 그대로다.

요청은 갔고, 착수는 안 됐다

시간순으로 놓으면 이렇다.

D+1 의 답을 받은 순간 나는 이 건을 닫았다. 배포까지 3주가 남았고, 확인하겠다는 사람이 있었다. 그런데 “확인하겠다” 는 착수 예고이지 착수가 아니었고, 그 사람에게는 그날 다른 배포가 있었다. 요청·착수·완료 중 내가 확인한 건 요청뿐이었는데 완료처럼 다뤘다.

D+12 에 상태를 물은 건 내가 아니라 다른 조직의 QA 담당자였다. 3주 일정을 관리하는 쪽에서 “이 티켓 어디까지 갔나” 를 훑다가 걸린 것이다. 내가 먼저 물었어야 했다.

다시 배포하자 진짜 문제가 나왔다

재배포 43분 뒤에 온 답은 “안 된다” 가 아니라 “확인할 수 없다” 였다. 브릿지 페이지에서 「이전 페이지로 돌아가기」 를 눌러봐야 하는데, 브릿지가 뜨자마자 카드사로 넘어가 버려서 버튼을 누를 틈이 없다는 것이다. 마우스를 올려도 포인터가 바뀌지 않는다는 말도 붙어 있었다.

원인은 계정이었다. 브릿지는 통합회원 여부를 API 로 확인하고, 통합회원이면 사용자 조작 없이 카드사로 보낸다. QA 담당자 계정도, 내 계정도 통합회원이었다. 브릿지는 로딩 화면을 잠깐 보이고 사라진다. 포인터가 안 바뀐 건 커서 스타일 문제가 아니라 버튼이 있는 화면에 도달하지 못한 것 이었다. 버튼은 세 지면 모두 cursor: pointer 였다.

즉 검증할 사람이 검증할 장면에 도달할 수 없었다. 처음 요청할 때 붙인 설명(“웹은 탭이 닫히며 돌아오고, 앱은 진입 지면으로 이동한다”)은 결과를 말했지 그 결과를 어떻게 보는지 는 말하지 않았다. 통합회원 계정으로는 볼 수 없다는 것도.

장면을 만들어 보냈다

다음 날 오전에 보낸 것은 영상 3편과 짧은 설명이다.

브릿지를 붙잡았다. Playwright 로 흐름을 돌리되, 통합회원 확인 API 라우트를 가로채 1~2분 동안 응답하지 않게 했다. 브릿지는 로딩 스피너를 띄운 채 버튼이 있는 화면에 머문다. 스피너는 녹화 직전에 DOM 에서 걷어냈다. CTA 와 복귀 코드는 배포본 그대로였지만, 이 영상은 버튼 동작을 설명하기 위한 재현 증빙이지 전체 흐름의 E2E 증명은 아니다. 카드사를 거쳐 돌아오는 전체 흐름의 최종 확인은 이후 실제 앱에서 따로 진행됐다.

처음에는 응답을 { isOneMember: false } 로 바꿨었다. 브릿지는 멈췄지만 대신 「통합 계정으로 전환하시겠어요?」 다이얼로그가 떴다. 그 영상을 보내면 “이 다이얼로그는 뭐죠” 부터 돌아올 것이다. 응답을 바꾸면 화면이 바뀐다. 늦추면 화면은 그대로이고 시간만 멈춘다.

지면마다 따로. 상품 상세·주문서·마이페이지 각각 한 편. 상품 상세와 주문서는 넛지가 새 탭을 열므로 탭마다 영상이 따로 나오고(Playwright 는 페이지 단위로 녹화한다), 원래 탭과 새 탭을 나란히 볼 수 있게 파일명에 순서를 붙였다.

끝까지. 버튼을 누르고 원래 지면이 다시 뜨는 것이 마지막 프레임이다. 검증 대상이 “복귀” 이니까.

설명은 정정부터. 재배포 직후 내가 급하게 남긴 답에 틀린 문장이 있었다. “웹은 버튼을 눌러도 카드 혜택 페이지로 이동한다.” 실제로는 진입 지면으로 돌아온다. 영상과 함께 그 문장을 먼저 정정하고, 지면별로 한 줄씩 “이 화면에서 시작해 이 화면으로 돌아온다” 를 적었다. 포인터 이야기에는 “커서 문제가 아니라 그 화면에 도달하지 못하신 것” 이라고 답했다.

영상에는 마우스 위치와 커서 값을 표시하는 오버레이가 얹혀 있었다. 실제 화면 요소가 아니라는 것도 적었다. 이틀 뒤 기획자가 앱 흐름을 확인했다는 답이 왔다.

하네스가 사용자 조건을 흉내 내야 했다

녹화보다 녹화할 수 있는 상태를 만드는 데 시간이 더 들었다. 메모로 남긴다.

• 다이얼로그의 「다음에」 는 history.back() 이다. 브릿지를 page.goto 로 직접 열면 뒤로 갈 곳이 없어 화면이 빈다. 실제 사용자처럼 랜딩에서 window.open 으로 열어야 히스토리가 맞는다.
• 새 탭은 context.pages() 개수로 잡았다. Promise.race([page.waitForEvent('popup'), …]) 는 놓치는 경우가 있었다.
• 지연은 녹화 길이보다 조금만 길게. 처음에 10분으로 뒀더니 브라우저 컨텍스트가 닫히지 않아 녹화 파일이 저장되지 않았다.
• 프레임 추출. 대표 프레임을 배포 티켓에 붙이려는데 작업 환경에 ffmpeg 이 없었다. macOS 라 AVFoundation 을 쓰는 Swift 스크립트 수십 줄로 뽑았다.

배포 승인자에게는 또 다른 형식

QA 가 끝나고 운영 배포 티켓을 만들 때 독자가 한 번 더 바뀐다. 승인자는 코드도 영상도 보지 않는다. “검증됐는가, 남은 위험은 무엇인가” 를 한 화면에서 보고 싶어 한다.

• QA 환경 검증 표: 항목 13개, 지면·채널·결과. 13/13.
• 실기기: Android 에서 발견된 결함 1건, 수정 커밋, 수정 후 Android·iOS 재확인. 영상은 링크만.
• 같은 날 배포되는 다른 PR 과의 파일 겹침: 0.
• 남은 위험: 딥링크 복귀 후 브릿지 웹뷰가 뒤에 남음. 배포 차단 아님, 앱팀 후속.
• 정책 판단이 필요했던 질문(마이페이지 배너와 메뉴가 다르게 동작하는 이유)과 그 답.

배포 당일 승인자에게서 추가 질문은 없었다.

Playwright smoke 결과를 PR 증빙으로 남기는 방법 은 첫 번째 줄의 이야기였다. 이번 글은 나머지 두 줄이다.

배운 것

1. 요청·착수·완료를 구분한다. “확인하겠다” 는 착수가 아니다. 대기 기간이 길수록 중간에 상태를 한 번 묻는다. 이번엔 다른 조직이 대신 물어줬다.
2. “확인할 수 없다” 는 “안 된다” 와 다른 답이고, 더 유용하다. 검증할 사람이 도달할 수 없는 장면이 있다는 뜻이다. 그 장면에 어떻게 도달하는지(또는 왜 도달 못 하는지)를 먼저 답한다.
3. 결과가 아니라 보는 법을 적는다. “탭이 닫히며 돌아온다” 는 결과다. “어느 계정으로 어디서 들어가면 어떤 화면에서 무엇을 누른다” 가 보는 법이다.
4. 하네스에서 상태를 고정하려면 응답을 바꾸지 말고 늦춰라. 바꾸면 화면이 바뀐다. 늦추면 시간만 멈춘다.
5. 급하게 남긴 설명은 정정부터 한다. 틀린 문장을 두고 영상을 얹으면 영상이 그 문장을 증명하는 것처럼 읽힌다.

읽을 거리

• 스킬은 외우지 않는다 — Playwright smoke PR 증빙 — 리뷰어용 증빙.
• E2E 검증을 설계와 실행으로 나눈 이유 — 검증 항목을 먼저 표로 적는 습관.
• Playwright — Videos — 컨텍스트 단위 녹화, 페이지마다 파일이 나뉘는 동작.
• Playwright — page.route() — 응답을 바꾸지 않고 지연시키는 데 쓴 API.