내부 QA는 요구사항과 구현 의도를 가장 잘 아는 사람이 기능을 깊게 점검하는 과정입니다. 이 역할은 납품 품질의 기반이며 외부 검증이 대신할 수 없습니다. 다만 만든 사람은 화면의 전제와 다음 단계를 이미 알고 있습니다. 처음 보는 사용자는 같은 화면에서도 다른 순서로 탐색하고, 익숙한 약어와 버튼의 의미를 다르게 해석합니다.

예를 들어 담당자는 권한 요청이 필요한 이유를 알고 있어 바로 허용을 누르지만, 처음 온 사용자는 왜 필요한지 알 수 없어 중단할 수 있습니다. 개발 환경에서 정상인 입력 흐름도 고객사의 기기, 브라우저, 계정 상태에서는 다른 순서로 나타날 수 있습니다. 이 차이는 구현 오류와 별개로, 실제 납품물의 사용 과정에서 확인해야 하는 범위입니다.

릴리즈가드는 내부 QA 결과를 평가하거나 대체하지 않습니다. 이미 확인한 요구사항은 존중하고, 그 결과가 답하지 못한 첫 사용 흐름과 실제 환경의 사각지대를 보완합니다. 같은 과업을 처음 보는 참여자가 수행한 기록을 추가하면, 팀은 기능 완료 여부와 사용 과정의 중단을 구분해 볼 수 있습니다.

납품 전 검증에서는 발주처가 실제로 이용할 핵심 과업을 먼저 정합니다. 회원 가입, 권한 요청, 신청서 제출, 검색 결과 확인처럼 사업 목적과 연결된 흐름이 대상이 됩니다. 모든 화면을 같은 깊이로 훑는 대신, 이번 납품에서 결정에 영향을 주는 질문을 좁혀 기록합니다. 요구사항 문서에 기능이 있다고 적혀 있는지와 사용자가 끝까지 수행하는지는 따로 확인합니다.

참여자는 정해진 조건에서 자신의 기기와 브라우저로 과업을 수행합니다. 화면이 멈춘 위치, 문구를 어떻게 이해했는지, 이전 단계에서 어떤 선택을 했는지를 함께 남깁니다. 같은 현상이 다른 기록에서도 나타나는지 대조하고, 한 번만 확인된 내용은 그 상태를 분리합니다. 이 과정은 결함 목록을 늘리는 일이 아니라, 납품 전에 수정할 범위와 추가 확인이 필요한 범위를 나누는 일입니다.

발주처의 검수 조건이 접근성, 특정 기기, 특정 사용자 집단처럼 나뉘어 있으면 각 조건을 처음부터 문서에 적습니다. 조건을 채우지 못했거나 대체가 발생하면 결과에 그대로 남깁니다. 확인하지 않은 환경을 통과한 것처럼 쓰지 않아야 납품 이후의 책임 범위도 분명해집니다. 검증의 범위와 제외 범위는 결과보다 먼저 합의합니다.

리포트는 내부 회의 메모가 아니라 고객사와 같은 기록을 보며 논의할 수 있는 산출물입니다. 각 검증 질문에 대해 어떤 과업을 확인했는지, 어느 조건에서 무슨 일이 발생했는지, 근거가 얼마나 확인되었는지를 연결해 적습니다. 화면만 첨부하고 해석을 맡기지 않으며, 발견 항목과 그 전후 맥락을 함께 전달합니다.

확인된 항목, 하나의 기록에서만 보인 항목, 이번 범위에서 확인하지 못한 항목을 분리하면 과장된 결론을 피할 수 있습니다. 고객사는 리포트를 통해 바로 수정할 항목과 다음 확인이 필요한 항목을 구분할 수 있습니다. 개발팀은 같은 근거를 기준으로 구현 범위를 정하고, PL은 납품 일정 안에서 우선순위를 설명할 수 있습니다.

리포트가 고객사에 제출된다고 해서 계약상 검수나 인증 절차를 대신하는 것은 아닙니다. 요구사항 충족 여부와 법적 판단은 발주처와 수행사가 각자의 계약과 절차에서 확인합니다. 릴리즈가드의 기록은 실제 사용 과정에서 얻은 근거를 정리한 별도 산출물입니다. 확인 범위와 한계를 적는 방식 자체가 결과를 다시 검토할 수 있게 합니다.

사전 검토에서 납품 일정, 확인할 과업, 발주처에 전달할 결과물의 범위를 정합니다. 다음으로 참여자 조건과 수행 환경을 확정합니다. 조건은 직함만으로 넓게 잡지 않고, 실제 과업을 수행하는 데 필요한 경험과 환경으로 좁힙니다. 범위가 정해지면 참여자가 본인 기기에서 과업을 수행하고, 중단과 완료의 과정을 기록합니다.

기록은 한 번 모아서 끝내지 않습니다. 화면, 수행 설명, 환경 정보와 다른 참여자의 기록을 대조해 같은 현상이 반복되는지 확인합니다. 서로 맞지 않는 자료는 하나의 결론으로 합치지 않고 차이를 남깁니다. 목표한 조건을 모두 채우지 못했거나 세그먼트를 대체했다면 그 사실도 결과에 적습니다. 이 과정은 납품 품질의 사각지대를 숨기지 않기 위한 절차입니다.

리포트에서는 질문별 근거와 남은 불확실성을 함께 정리합니다. PL과 개발팀은 이를 바탕으로 수정 우선순위, 추가 확인, 고객사 설명에 필요한 내용을 정할 수 있습니다. 검증 절차의 상세와 근거 상태의 의미는 방법론 문서에서 확인할 수 있습니다.

릴리즈가드는 자사 QA를 대행하지 않습니다. 테스트 케이스를 대신 운영하거나, 내부 품질 기준의 통과 여부를 승인하는 역할도 맡지 않습니다. 내부 QA는 제품의 요구사항과 구현을 깊게 확인하고, 릴리즈가드는 처음 보는 사용자의 수행 기록으로 그 과정의 사각지대를 보완합니다. 두 역할을 하나로 표현하지 않아야 결과의 책임과 범위를 분명하게 유지할 수 있습니다.

개발과 수정도 수행하지 않습니다. 발견 항목에 대한 화면과 맥락, 확인 상태는 전달하지만 어떤 코드나 디자인을 채택할지는 제품 팀과 수행사가 결정합니다. 수정 후 다시 확인이 필요하면 그 범위와 조건을 새로 정해 검증할 수 있습니다. 이전 기록이 다음 변경에서도 그대로 성립한다고 가정하지 않습니다.

납품 승인, 고객사 검수, 인증 심사 결과를 약속하지 않습니다. 이번에 실제로 수행한 과업과 환경에서 확인한 일만 리포트에 적습니다. 범위 밖의 기능, 참여하지 않은 세그먼트, 재현하지 못한 항목은 결과에 포함하지 않습니다. 이 경계를 지키면 발주처와 수행사는 리포트를 근거 자료로 쓰되, 그것이 답하지 않는 판단을 구분할 수 있습니다.