개념
이 모듈의 모든 레슨이 이 순간을 위해 있었다 — 계획(레슨 1)을 세우고, 리스크(레슨 2)를 근거로 우선순위를 정하고, 규모(레슨 3)에 맞게 커버리지를 조정하고, 종료 조건(레슨 4)을 합의했다면, 이제 그 결과를 가지고 "릴리즈해도 되는가" 를 판단할 차례다.
앞의 네 레슨이 여기서 하나로 모인다
Go/No-Go 회의가 어려운 사람은 대개 회의 준비를 그날 아침에 시작한다. 사실 준비는 이 모듈 첫 레슨부터 이미 하고 있었다.
| 레슨 | 그때 만든 것 | Go/No-Go에서 쓰이는 방식 |
|---|---|---|
| 레슨 1 (계획·전략) | 테스트 범위, 하지 않기로 한 것 | "이 영역은 처음부터 범위 밖이었습니다"의 근거 |
| 레슨 2 (리스크) | 기능별 리스크 매트릭스 | 남은 결함·미실행 영역이 얼마나 위험한지 판정하는 자 |
| 레슨 3 (규모별 커버리지) | 변경 규모에 맞춘 커버리지 계획 | "왜 이만큼만 봤는가"에 대한 설명 |
| 레슨 4 (종료 조건) | 합의된 종료 조건 목록 | 충족 / 미충족을 사실로 판정하는 기준선 |
반대로 말하면, 앞의 네 개를 하지 않았다면 Go/No-Go 회의에서 QA는 할 말이 없다. "얼마나 테스트했나요?"에 "많이 했습니다"라고 답하게 되고, "안전한가요?"에 "아마도요"라고 답하게 된다. Go/No-Go 회의의 품질은 회의 당일이 아니라 계획 단계에서 이미 결정된다.
Go/No-Go 회의에 QA는 무엇을 들고 가는가
QA가 준비해야 할 정보는 네 가지다. 이 네 가지 밖의 것(예산, 마케팅 일정, 경쟁사 동향)은 QA의 몫이 아니고, 이 네 가지 안의 것은 전적으로 QA의 몫이다.
| 항목 | 답해야 할 질문 | 데이터 출처 | 빠지면 생기는 일 |
|---|---|---|---|
| 실행 현황 | 계획 대비 얼마나 실행했고, 무엇을 못 했나 | 테스트 관리 도구, 실행 로그 | "다 했습니다"라는 말이 검증 불가능해진다 |
| 미해결 결함 | 심각도별로 몇 건이 왜 남아 있나 | 결함 트래커(모듈 6) | 결정권자가 무엇을 안고 나가는지 모른 채 결정한다 |
| 종료 조건 충족 여부 | 합의한 조건 중 무엇이 충족·미충족인가 | 레슨 4의 종료 조건 | 판단이 다시 주관 논쟁으로 돌아간다 |
| 잔존 리스크 | 못 본 영역은 어디고 터지면 어떻게 되나 | 레슨 2 리스크 매트릭스 | 사고가 나면 "왜 아무도 몰랐나"가 된다 |
이 네 가지를 한 장으로 — 실제 양식
회의에서 슬라이드 열 장을 넘기며 설명하면 아무도 기억하지 못한다. 한 장에 담기지 않는 요약은 요약이 아니다. 실무에서 쓰는 형태는 대략 이렇다.
릴리즈 판단 요약 — 결제 수단 개편 v2.4
작성: QA 김OO / 2026-08-29 / 릴리즈 예정 8-31 14:00
[1] 실행 현황
계획 412건 / 실행 400건 (97.1%) / 미실행 12건
미실행 12건 = 관리자 정산 통계 화면 (레슨 2 기준 리스크 '낮음')
자동화 회귀 스위트 1,150건 전건 통과 (CI 8-29 03:12)
[2] 미해결 결함
치명(Critical) 0건
높음(High) 0건
중간(Medium) 2건 DEF-881 관리자 화면 정렬 오류
DEF-902 쿠폰 목록 페이지네이션 마지막 장 깨짐
낮음(Low) 7건 목록 별첨, 다음 스프린트 처리 합의됨
[3] 종료 조건 (레슨 4 합의본)
O 계획 케이스 95% 이상 실행 → 97.1%
O 심각도 '높음' 이상 전건 수정·재확인 → 0건
O 중간 이하 결함 목록화 및 리스크 인지 → 본 문서 [2]
O 핵심 기능 커버리지 100% → 결제 흐름 100%
△ 잔존 리스크 문서화 → 본 문서 [4], 이번 회의에서 확정
[4] 잔존 리스크
R1 신규 PG사 실계좌 결제 미검증 (샌드박스만 검증)
- 원인: 실계좌 테스트 승인이 8-30 이후 예정
- 영향: 특정 카드사 결제 실패 시 매출 직접 손실
- 완화: 신규 PG는 피처 플래그 OFF로 출시, 승인 후 별도 활성화
R2 관리자 정산 통계 미실행 12건
- 영향: 내부 사용자만, 매출 영향 없음, 수기 대조 가능
- 완화: 출시 후 첫 정산일(9-01) 담당자 확인
[5] QA 권고
조건부 Go.
조건 1 — 신규 PG 피처 플래그 OFF 상태로 배포
조건 2 — 출시 후 24시간 결제 성공률 모니터링 (기준 아래 [6])
조건 3 — 롤백 담당자·절차 사전 지정
[6] 출시 후 모니터링 (24시간)
결제 성공률 평시 99.2% → 98.5% 미만 30분 지속 시 롤백 검토
결제 API 5xx 평시 0.1% → 1% 초과 시 즉시 에스컬레이션
결제 관련 CS 문의 평시 일 3건 → 10건 초과 시 확인
담당: QA 김OO(주간) / 개발 이OO(야간)이 한 장이 갖는 힘은 모든 문장이 검증 가능하다는 데 있다. "충분히 테스트했습니다"는 반박도 확인도 불가능하지만, "412건 중 400건 실행, 미실행 12건은 이것"은 누구나 확인할 수 있다. 모듈 2(레슨 2)에서 배운 "테스트 가능한 요구사항"의 기준이 여기서 그대로 반복된다 — 관찰 가능한 문장만 쓴다.
실행 현황은 "몇 퍼센트 했다"가 아니라 "무엇을 안 했다"이다
초보 QA의 요약은 대개 "97% 실행 완료"에서 멈춘다. 결정권자에게 중요한 정보는 97%가 아니라 남은 3%가 무엇이냐 다. 같은 97%라도 뜻이 완전히 다르다.
| 같은 97% | 남은 3%의 정체 | 판단 |
|---|---|---|
| 사례 A | 관리자 통계 화면, 리스크 낮음, 수기 대조 가능 | 나가도 된다 |
| 사례 B | 결제 실패 후 재시도 흐름, 리스크 높음, 시간 부족 | 나가면 안 된다 |
퍼센트만 보고하면 이 둘이 구분되지 않는다. 실행률은 요약의 시작일 뿐이고, 실제 정보는 미실행 항목의 목록에 있다. 그래서 요약 양식의 [1]번 칸은 숫자 한 줄이 아니라 "무엇을 못 했고 왜 괜찮은가(혹은 안 괜찮은가)" 한 줄이 반드시 따라붙어야 한다.
미해결 결함은 심각도별로, 그리고 "왜 안 고쳤는지"까지
"미해결 9건"은 정보가 아니다. 심각도별로 갈라야 비로소 판단 재료가 된다. 모듈 6에서 다룰 심각도·우선순위 구분이 여기서 처음 실전으로 쓰인다.
- 치명·높음이 0건인지가 첫 번째 관문이다. 이 칸에 숫자가 있다면 나머지 설명은 대개 의미가 없다. 종료 조건이 이미 무너진 상태다.
- 중간 이하는 "몇 건"보다 "어디에 몰려 있나"가 중요하다. 중간 결함 2건이 서로 다른 화면에 흩어져 있는 것과, 둘 다 결제 화면에 몰려 있는 것은 전혀 다른 신호다. 후자는 그 영역이 아직 불안정하다는 뜻이고, 발견되지 않은 결함도 거기 더 있을 가능성이 높다(모듈 1의 결함 집중 원리).
- 왜 안 고쳤는지를 함께 적는다. "수정 시 회귀 범위가 커서 이번 릴리즈에서 제외 합의", "재현 불가로 모니터링 전환" 같은 한 줄이 있어야 결정권자가 "그럼 다음 릴리즈에 확실히 되는 거죠?"를 물을 수 있다.
잔존 리스크 — 가장 쓰기 어렵고 가장 중요한 칸
잔존 리스크(Residual Risk) 는 "테스트를 다 하고도 남은 위험"이다. 완전한 테스트가 불가능하다는 모듈 1(레슨 5)의 전제를 받아들이면, 잔존 리스크는 항상 0이 아니다. QA의 일은 그것을 0으로 만드는 게 아니라 보이게 만드는 것 이다.
쓸 때는 네 칸을 채운다. 이 중 하나라도 비면 읽는 사람이 판단할 수 없다.
| 칸 | 쓰는 법 | 나쁜 예 |
|---|---|---|
| 무엇이 | 검증되지 않은 대상을 구체적으로 | "일부 기능" |
| 왜 남았나 | 시간 부족·환경 부재·의도적 범위 제외 | (아예 안 적음) |
| 터지면 | 사용자·매출·데이터에 미치는 영향 | "문제가 생길 수 있음" |
| 완화 장치 | 플래그·모니터링·수기 대조·롤백 | (아예 안 적음) |
특히 "터지면" 칸을 사용자 언어로 쓰는 것 이 중요하다. "PG 연동 미검증"은 개발자에게만 의미가 있고, "특정 카드사 사용자가 결제 버튼을 눌렀을 때 실패할 수 있고, 그 경우 그 주문은 매출로 잡히지 않습니다"는 회의실의 모두에게 의미가 있다. 결정은 QA가 아니라 그 사람들이 내리므로, 리스크는 그들의 언어로 번역되어야 한다.
QA는 결정하지 않는다 — 그러나 침묵하지도 않는다
"릴리즈해도 되나요?"라는 질문에 QA가 혼자 답할 수 없는 이유는 겸손이 아니라 정보의 비대칭 때문이다. 릴리즈 판단에 들어가는 변수 중 QA가 아는 것은 일부뿐이다.
| 판단 변수 | 아는 사람 | QA가 아는가 |
|---|---|---|
| 품질 현황, 잔존 리스크 | QA | 안다 |
| 지연 시 계약·과징금 | 사업·법무 | 모른다 |
| 경쟁사 출시 일정 | PM·마케팅 | 모른다 |
| 이 기능에 걸린 매출 규모 | PM·사업 | 대개 모른다 |
| 지연 시 다른 팀 일정 연쇄 | PM·개발 리드 | 모른다 |
| 롤백·핫픽스 대응 여력 | 개발 리드·운영 | 부분적으로 안다 |
여섯 줄 중 QA가 확실히 아는 건 한 줄이다. 그 한 줄만 가지고 "나가면 안 됩니다"를 최종 결론으로 선언하면, 나머지 다섯 줄을 모른 채 남의 결정을 대신하는 셈이 된다.
그렇다고 "저는 판단할 위치가 아닙니다"가 답인 것은 절대 아니다. 이건 QA가 자기 역할을 축소하는 가장 흔한 방식이고, 조직이 QA를 "테스트만 하는 사람"으로 취급하게 만드는 원인이기도 하다. 세 가지 화법을 비교해보자.
| 유형 | 실제 발언 | 문제 |
|---|---|---|
| 결정하려 든다 | "이 상태로는 못 나갑니다." | QA가 모르는 변수를 무시한 단정 |
| 침묵한다 | "판단은 PM님이 하시면 됩니다." | 근거를 가진 유일한 사람이 의견을 버렸다 |
| 근거를 주고 권고한다 | "권고는 No-Go입니다. 종료 조건 2번이 미충족이고, 결제 재시도 흐름이 미검증입니다. 일정상 나가야 한다면 이 기능만 플래그로 끄고 나가는 방법이 있습니다." | — |
세 번째가 QA의 자리다. 정리하면 QA가 만들어야 하는 것은 "이걸 알고도 나가시겠습니까" 라는 질문이다. 여기에 "예"라고 답하는 것은 결정권자의 정당한 권한이다. 다만 그 "예"가 알고 하는 예인지 모르고 하는 예인지를 가르는 것이 QA의 책임이다.
조건부 Go — 답은 둘 중 하나가 아니다
Go와 No-Go 사이에는 실무에서 가장 자주 쓰이는 중간 지점이 있다. 이분법으로만 생각하면 "다 나간다 vs 다 미룬다"가 되어 협상 자체가 불가능해지지만, 릴리즈 단위를 쪼갤 수 있다는 걸 알면 대화가 완전히 달라진다.
| 방식 | 무엇을 하는가 | 무엇을 줄이나 | QA가 반드시 확인할 것 |
|---|---|---|---|
| 피처 플래그 | 문제 기능만 꺼둔 채 나머지를 출시 | 노출 범위를 0으로 | 플래그 OFF 상태가 정상 동작하는가 |
| 카나리·점진 배포 | 사용자 1%→10%→100%로 단계 확대 | 터졌을 때의 피해 규모 | 단계별 관찰 지표와 중단 기준이 있는가 |
| 롤백 준비 후 출시 | 되돌릴 준비를 갖추고 나감 | 문제 지속 시간 | 실제로 되돌려본 적이 있는가 |
세 방식 모두 QA에게 추가 테스트 대상을 만든다는 점을 놓치기 쉽다.
- 피처 플래그를 켰을 때만 테스트하고 껐을 때를 안 본다. 실무 사고가 가장 많이 나는 지점이다. 플래그 OFF 경로도 하나의 분기이고, 플래그가 두 개면 조합은 네 가지다. 모듈 3(레슨 5)의 페어와이즈가 여기서 그대로 쓰인다.
- 카나리는 지켜볼 지표가 없으면 그냥 "일부 사용자에게만 터뜨리기"다. 1% 배포 중에 무엇을 보고 다음 단계로 넘어갈지 미리 정해야 카나리가 된다.
- 리허설 없는 롤백 계획은 계획이 아니라 희망이다. 특히 DB 스키마 변경이 포함된 릴리즈는 코드만 되돌려도 데이터가 안 돌아온다. "이번 릴리즈는 롤백 가능한가"를 Go/No-Go 회의에서 반드시 물어야 하는 이유다.
이 도구들을 알고 있으면 권고문이 이렇게 바뀐다.
"핵심 결제 흐름의 종료 조건은 모두 충족됐습니다. 다만 신규 PG 연동은 실계좌 검증을 못 했고, 이건 실패 시 매출에 직접 영향이 갑니다. 그래서 신규 PG만 피처 플래그로 끈 채 배포하고, 승인이 나오는 다음 주에 별도로 켜는 것을 권합니다. 나머지에 대해서는 조건부로 Go를 권합니다."
No-Go를 말해야 할 때 — 데이터로 말하고, 기록을 남긴다
가끔은 조건을 붙여도 안 되는 상황이 있다. 그때의 화법에는 규칙이 있다.
| 이렇게 말하지 않는다 | 이렇게 말한다 |
|---|---|
| "왠지 불안합니다." | "종료 조건 2번(높음 결함 0건)이 미충족입니다. 현재 2건입니다." |
| "테스트가 부족했어요." | "계획 412건 중 340건(82%) 실행했고, 미실행 72건이 전부 결제 영역입니다." |
| "터질 것 같은데요." | "결제 재시도 흐름이 미검증이고, 실패 시 중복 청구 가능성이 있습니다." |
| "저희는 반대입니다." | "QA 권고는 No-Go입니다. 근거는 앞의 세 항목입니다." |
왼쪽은 전부 감정과 직감이고, 오른쪽은 전부 확인 가능한 사실이다. 왼쪽으로 말하면 논쟁은 "당신이 예민한 것 아니냐"로 흐르고, 오른쪽으로 말하면 논쟁이 사실 확인으로 끝난다. 감이 틀렸다는 뜻이 아니다 — 경험 많은 QA의 불안감은 대개 근거가 있다. 다만 그 불안감을 데이터로 번역하는 작업을 회의 전에 끝내두어야 한다.
반대에 부딪혔을 때 — 결정 기록 남기기
근거를 다 제시했는데도 "그래도 나갑니다"로 결론이 나는 일은 실무에서 흔하다. 그때 QA가 할 일은 화를 내거나 포기하는 게 아니라 결정을 기록하는 것 이다.
릴리즈 결정 기록 — v2.4 (2026-08-29 Go/No-Go 회의)
QA 권고: No-Go (종료 조건 2번 미충족, 결제 재시도 흐름 미검증) 회의 결정: Go — 계약상 8월 내 오픈 필요, 지연 시 위약 발생 결정자: PM 박OO / 배석: 개발리드 이OO, QA 김OO 인지된 리스크: 결제 재시도 시 중복 청구 가능성 (발생 시 CS 수기 환불) 합의된 대응: 출시 후 48시간 결제 로그 실시간 확인, 이상 시 즉시 롤백 다음 조치: 9월 1주차에 재시도 흐름 검증 완료
이 한 장이 하는 일은 세 가지다.
- QA를 보호한다. 사고가 났을 때 "왜 QA가 못 잡았나"가 아니라 "알고 결정한 리스크가 발현됐다"가 된다. 이건 책임 회피가 아니라 사실의 보존이다.
- 결정의 질을 높인다. 사람은 기록에 이름이 남는 결정을 더 신중하게 내린다. 기록을 남기겠다고 말하는 순간 "그럼 조건을 좀 붙이죠"로 대화가 바뀌는 일이 자주 있다.
- 조직의 학습을 남긴다. 반년 뒤 회고에서 "우리는 이런 상황에서 어떻게 판단했었나"를 볼 수 있는 유일한 자료다. 기록이 없으면 조직은 같은 실수를 같은 방식으로 반복한다.
다만 톤이 결정적이다. 이 기록은 "나중에 문제 생기면 제 책임 아닙니다"가 아니라 "우리가 무엇을 알고 결정했는지 남겨둡시다"여야 한다. 알리바이로 쓰는 QA는 한 번은 보호받지만 두 번째부터 회의에 불리지 않는다. 회의록에 한 줄, 릴리즈 티켓에 코멘트 한 줄이면 충분하고, 별도의 각서 같은 형태는 오히려 관계를 망친다.
릴리즈 이후로 이어지는 것 — 모니터링 계획은 지금 정한다
Go/No-Go 회의의 마지막 안건은 릴리즈가 아니라 릴리즈 이후 여야 한다. 잔존 리스크를 안고 나가기로 했다면, 그 리스크가 실제로 터지는지 지켜볼 방법을 같이 정해야 문장이 완성된다. 정할 것은 네 가지다.
| 정할 것 | 나쁜 예 | 좋은 예 |
|---|---|---|
| 무엇을 볼 것인가 | "이상 있는지 본다" | 결제 성공률, 결제 API 5xx 비율, 결제 CS 문의 수 |
| 어떤 신호면 되돌리나 | "심각하면 롤백" | 성공률 98.5% 미만이 30분 지속되면 롤백 검토 |
| 얼마 동안 볼 것인가 | "당분간" | 배포 후 24시간 집중, 첫 정산일까지 일 1회 |
| 누가 볼 것인가 | (안 정함) | 주간 QA 김OO / 야간 개발 이OO |
두 번째 줄이 이 표의 핵심이다. 롤백 기준을 사고가 난 뒤에 정하면 사람은 거의 항상 "조금만 더 지켜보자"를 택한다. 지표가 나빠지는 중에는 이미 되돌리기 싫은 마음이 생겨 있기 때문이다. 그래서 아직 아무 일도 일어나지 않은 시점, 즉 Go/No-Go 회의에서 숫자를 못 박아두는 것 이 유일하게 작동하는 방법이다.
그리고 여기서 QA가 "무엇을 볼 것인가"에 답하려면 애초에 볼 수 있는 데이터가 있어야 한다. 로그가 없고, 지표가 수집되지 않고, 대시보드가 없으면 모니터링 계획은 종이 위에서만 존재한다. 이 이야기가 모듈 14(레슨 6)의 관측성(Observability) 으로 이어진다 — 릴리즈 판단의 마지막 칸을 채우려면 로그·메트릭·대시보드가 미리 준비되어 있어야 한다는 것. 반대로 말하면, "이 기능이 잘 돌아가는지 어떻게 확인하죠?"라는 질문은 릴리즈 직전이 아니라 개발 착수 시점에 나왔어야 하는 질문이다.
사례 연구 — 같은 상황, 두 개의 릴리즈
같은 조건에서 출발한 두 팀의 이야기다. 조건은 이렇다. 결제 수단 개편, 릴리즈 이틀 전, 신규 PG 실계좌 검증이 승인 지연으로 완료되지 않았다.
A팀 — 근거 없이 Go. 회의에서 QA가 말했다. "전체적으로는 괜찮은데 신규 PG 쪽이 좀 걸립니다." PM이 물었다. "구체적으로 어떤 문제가 있나요?" QA가 답했다. "실제 결제를 못 해봐서요. 근데 샌드박스에서는 다 됐습니다." 회의는 3분 만에 Go로 끝났다. 누구도 나쁜 의도가 없었다 — 그저 판단할 재료가 회의실에 없었을 뿐이다. 릴리즈 다음 날 오전, 특정 카드사 결제가 전량 실패하기 시작했다. 발견은 사용자 CS 문의로 이뤄졌고(모니터링 항목을 정해두지 않았으므로), 원인 파악에 4시간, 롤백 시도에서 DB 스키마가 이미 바뀌어 있다는 것을 그때 알았다. 결국 핫픽스로 6시간을 더 썼다. 사후 회고에서 나온 질문은 "QA는 왜 못 잡았나"였다. QA는 그 리스크를 알고 있었지만, 아는 것과 회의실에 올려놓는 것은 다르다.
B팀 — 잔존 리스크를 명시하고 조건부 Go. 같은 상황에서 QA가 요약 한 장을 들고 들어갔다. 실행 400/412, 높음 결함 0건, 종료 조건 4/5 충족. 그리고 잔존 리스크 칸에 이렇게 적혀 있었다. "신규 PG 실계좌 미검증 — 실패 시 해당 카드사 사용자 결제 전량 실패, 매출 직접 손실. 완화안: 신규 PG를 피처 플래그 OFF로 배포." 회의는 15분 걸렸고, 논의는 "나갈까 말까"가 아니라 "플래그를 언제 켤까"였다. 결론은 조건부 Go — 플래그 OFF 배포, 24시간 결제 성공률 모니터링, 롤백 담당자 지정. 사흘 뒤 승인이 나와 플래그를 켰고, 이번엔 실계좌 검증을 마친 상태였다. 아무 일도 일어나지 않았다.
두 팀의 차이는 정보의 양이 아니라 정보를 회의실에 올려놓았는지 였다. A팀 QA도 리스크를 알고 있었다. 다만 "좀 걸립니다"라고 말했고, B팀 QA는 "무엇이, 왜, 터지면 어떻게 되고, 어떻게 줄일 수 있는지"를 적어서 말했다. Go/No-Go에서 QA의 실력 차이는 대부분 이 한 칸에서 갈린다.
모듈 1(레슨 5)로 돌아가서
이 모듈을 시작하기 전, 모듈 1 레슨 5에서 "버그 없음을 보장해달라"는 요청에 어떻게 답할지 연습했었다. 그때는 일반적인 답변 스크립트를 만드는 수준이었다면, 이제는 실제 종료 조건 충족 현황과 리스크 매트릭스라는 구체적인 데이터를 가지고 그 질문에 답할 수 있다. "버그가 없다고는 말씀드릴 수 없지만, 핵심 흐름의 종료 조건은 100% 충족했고, 남은 리스크는 이 정도이며, 이렇게 대응할 계획입니다"라고.
같은 말을 이 레슨의 언어로 다시 쓰면 이렇게 된다. QA는 "안전하다"를 말하는 사람이 아니라, "무엇을 알고 무엇을 모르는지"를 말하는 사람이다. 앞의 것은 증명할 수 없고, 뒤의 것은 언제나 정확하게 말할 수 있다.
다음 레슨은 이 판단이 특히 어려워지는 상황을 다룬다 — 성공 기준이 "아무것도 달라지지 않았다"인 마이그레이션·전환 프로젝트 다. 거기서는 기대 결과가 기획서가 아니라 기존 시스템 자체이고, Go/No-Go의 근거도 "등가성을 어디까지 증명했는가"로 바뀐다.
실무에서 왜 필요한가
Go/No-Go 순간은 QA가 조직에서 신뢰와 영향력을 얻는(혹은 잃는) 결정적 순간이다. 근거 없이 "괜찮은 것 같아요"라고 말하는 QA와, 종료 조건·결함 현황·리스크를 근거로 명확한 권고를 제시하는 QA는 완전히 다른 신뢰를 받는다. 이건 모듈 1(레슨 6)에서 다룬 QA의 조직 내 영향력과도 직결된다 — 이 순간을 잘 다루는 QA가 "테스트나 하는 사람"이 아니라 "의사결정에 필요한 사람"으로 인식된다.
첫째, 회의가 짧아진다. 요약 한 장이 있으면 회의는 "현황 파악"이 아니라 "판단"부터 시작한다. 요약이 없으면 30분 중 25분을 "그래서 얼마나 한 거죠?", "그 버그는 심각한 건가요?"에 쓰고, 정작 판단은 5분 만에 감으로 내린다. 순서가 정확히 거꾸로다.
둘째, 사고가 났을 때 조직이 배운다. 잔존 리스크와 결정 기록이 남아 있으면 사후 회고가 "누가 잘못했나"가 아니라 "우리의 판단 기준 중 무엇이 틀렸나"로 간다. R1을 '낮음'으로 분류했는데 터졌다면 리스크 평가 기준을 고치면 되고, 모니터링 지표에 그 신호가 없었다면 지표를 추가하면 된다. 기록이 없으면 그 어떤 것도 고칠 수 없고, 남는 건 사람에 대한 인상뿐이다.
셋째, 다음 릴리즈의 계획이 좋아진다. "이번에 실계좌 검증 승인이 늦어서 잔존 리스크가 됐다"가 기록되면, 다음 릴리즈 계획(레슨 1)에서 그 승인 요청을 2주 앞당기게 된다. Go/No-Go는 이 모듈의 끝이 아니라, 다음 사이클의 계획으로 되돌아가는 고리다.
넷째, 자동화 투자의 근거가 된다. "이번에도 회귀 테스트 때문에 이틀이 부족해서 종료 조건 1번을 못 채웠다"가 세 번 반복되면, 그건 QA의 게으름이 아니라 자동화가 필요하다는 데이터다. 스테이지 4의 자동화 우선순위는 이런 기록 위에서 정해질 때 설득력을 갖는다.
신입 QA가 특히 얻는 것. 경력이 적을 때 Go/No-Go 회의가 무서운 이유는 "내가 괜찮다고 했는데 터지면 어쩌지"라는 부담 때문이다. 이 레슨의 요약 양식은 그 부담을 구조적으로 덜어준다. QA는 "괜찮다"를 보증하는 사람이 아니라 네 칸을 정확하게 채우는 사람이기 때문이다. 네 칸을 정확히 채웠다면, 결과가 어떻게 되든 QA는 자기 일을 한 것이다.