ReleaseGate

릴리즈 직전 회의에서 "이거 내보내도 괜찮을까"가 매번 감과 목소리 큰 사람의 직관으로 결정된다. QA 엔지니어·PM·개발자가 같은 화면을 보면서 같은 점수로 판단할 수 있는 자리가 없다.

QA 엔지니어로 14년 동안 직접 본 릴리즈 미팅의 반복 패턴. 체크리스트는 많지만 "릴리즈 신뢰도"라는 한 줄 답이 없어서, 결정 책임이 가장 자신감 있는 한 사람에게 쏠리는 구조였다.

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

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

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

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

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

"릴리즈 결정"이라는 단어가 가진 무게를 한 화면에 담아내는 게 어렵다는 걸 확인. 점수 자체보다 점수의 근거를 보여주는 디자인이 채택률을 좌우한다는 가설로 다음 라운드 진행 중.

QA 엔지니어가 매번 "이슈 트래커에 다 있는데 왜 결정자가 못 본다고 할까"를 마주했던 경험이 제품의 출발점. 정보가 있는 것과 결정에 닿는 형태로 정리되는 것은 다른 문제라는 통찰이 핵심 기능 우선순위를 정했다.

• FastAPI
• React
• PostgreSQL
• OpenAI API

• releasegate.app ↗