ReleaseGate

릴리즈 직전 회의에서 "이거 내보내도 괜찮을까"가 매번 감과 목소리 큰 사람의 직관으로 결정된다. QA 엔지니어가 정리한 결함 목록은 트래커에, PM이 본 사용자 영향도는 슬랙 스레드에, 개발자가 아는 변경 위험 영역은 PR 코멘트에 흩어져 있다. 같은 정보를 같은 화면에서 같은 점수로 비교할 자리가 없으니, 결정 책임이 가장 자신감 있는 한 사람에게 쏠리고 그 사람의 컨디션과 발언권 크기가 결정에 끼어든다. "릴리즈 신뢰도"를 두고 모두가 같은 한 줄을 보지 못한다는 게 진짜 문제다.

QA 엔지니어로 14년 동안 들여다본 릴리즈 미팅의 반복 패턴. 체크리스트와 회귀 케이스는 많지만 "릴리즈 신뢰도"라는 한 줄 답이 없어서, 결정 책임이 가장 자신감 있는 한 사람에게 쏠리는 구조였다. 도구가 없는 게 아니라 "결정 자체에 도구가 없는 것"이 문제라는 가설로 출발했다. JIRA·테스트 리포트·코드 리뷰가 다 있는 회사에서도 같은 질문이 반복된다는 게 그 가설을 뒷받침한다.

릴리즈 결정에 책임을 지는 PO/PM, 리스크를 보는 QA 리드, 출시 일정을 잡는 엔지니어링 매니저.

릴리즈 준비 상태를 0-100점의 단일 신뢰도 점수와 GO / HOLD 권고로 표현해 주면, 의사결정이 토론에서 검증으로 옮겨갈 것이다.

• Release Confidence Score (0-100) 설계 - 테스트 커버리지·미해결 결함·변경 위험 영역을 가중합으로 묶음
• GO / HOLD 권고와 그 근거가 함께 보이는 리포트 UI
• AI 기반 테스트 케이스 초안 생성 - QA 엔지니어가 빈 화면이 아닌 "수정할 초안"부터 시작하게
• 이해관계자 공유용 PDF 리포트 export

• 점수를 단일 숫자로 노출 - 회의실에서 "몇 점?" 한 마디로 합의가 시작되도록
• GO/HOLD는 권고로만 표시하고 최종 결정은 사람이 - 자동화의 신뢰 한계를 인정
• MVP에서는 통합 대신 PDF export 우선 - 도입 마찰을 최소화

• 점수 재현성 - 같은 입력(커버리지·미해결 결함·변경 위험)에 같은 신뢰도 점수가 나오는가(루브릭 결정론)
• GO/HOLD 권고와 최종 결정 사람 개입의 경계가 흐려지지 않는가 - 자동 판정으로 오인되지 않게
• 입력 경계값 - 빈 입력·50,000자 초과 같은 극단 입력에서 안전하게 막히는가(TC-P0-001·002)
• 블로커 유무에 따라 출력 구조가 일관되게 갈리는가(TC-P0-012~015 회귀 고정)
• LLM 응답을 결정론적 목으로 고정해 점수 산출을 회귀 대상으로 유지하는가
• 리스크 레지스터(docs/03)의 대부분 항목에 "검증 방법"과 Mitigated/Open 상태를 붙여 위험 기반 검증이 문서에서 추적되는가
• 자기 게이트에 스스로 못 미치는 구간을 정직하게 드러냈는가 - 커밋된 자동화는 CLI 루브릭에 집중되고 test_go_nogo.py는 빈 플레이스홀더, 웹앱 E2E·커버리지 목표(docs/05)는 아직 문서상 목표

MVP 단계. 초기 사용자 인터뷰 진행 중, 정량 지표는 측정 전.

"릴리즈 결정"이라는 단어가 가진 무게를 한 화면에 담아내는 게 만만치 않다는 걸 확인. 점수 한 줄을 띄우는 건 쉽지만, 회의실에서 그 점수가 받아들여지려면 "어떻게 그 점수가 나왔는지"가 같은 화면에서 즉시 보여야 했다. 점수가 결정의 시작점이라면 근거 화면은 결정의 안전망이라는 구분이 보이기 시작했고, 점수 자체보다 근거 디자인이 채택을 좌우한다는 가설로 다음 라운드를 짠다.

• 첫 라운드에서 단일 점수를 헤드라인으로 강조한 게 "숫자에 대한 신뢰" 질문을 너무 빨리 끌고 왔다. 다음 라운드는 점수의 근거 디자인부터.
• MVP에서 통합 대신 PDF export로 도입 마찰을 낮춘 결정은 첫 진입에는 옳았지만, 회의에서 실제로 어떻게 쓰이는지의 흔적이 얇게 남는다는 부작용도 있었다.