콘솔 인증 Traceability Matrix 운영법: 기능·테스트 케이스·증빙을 연결하는 실무 가이드

핵심 요약

콘솔 인증용 Traceability Matrix는 인증 요구사항인 Requirement를 게임 기능, 테스트 케이스, 실행 결과, 증빙 자료까지 연결하는 관리 문서다. 핵심은 모든 요구사항에 담당 기능과 검증 방법을 지정하고 실패·예외·변경 이력을 추적할 수 있게 만드는 것이다.

운영 순서는 다음과 같다.

1. 플랫폼별 인증 요구사항을 고유한 Requirement ID로 쪼갠다.
2. 각 요구사항에 Feature ID, Test Case ID, Evidence ID를 연결한다.
3. 빌드 버전, 실행 환경, 결과, 증빙 위치를 기록하고 변경 시 영향 범위를 갱신한다.

왜 콘솔 인증 요구사항은 기능 목록만으로 관리되지 않는가?

기능 목록은 무엇을 만들었는지를 보여준다. 그러나 콘솔 인증에서는 기능이 요구사항을 충족하는지 어떤 조건에서 검증했는지 인증 제출 시 어떤 자료로 설명할 수 있는지가 더 중요하다.

예를 들어 “컨트롤러를 분리해도 게임이 정상 동작해야 한다”는 요구사항이 있다고 하자. 이 요구사항은 단순히 컨트롤러 입력 기능이 구현되었다는 사실만으로 충족되지 않는다.

• 플레이 중 컨트롤러를 분리한다.
• 다른 컨트롤러를 연결하거나 재연결한다.
• 온라인 세션과 로컬 멀티플레이 상태를 각각 확인한다.
• 일시정지 화면과 오류 메시지의 동작을 확인한다.
• 검증 결과를 영상, 로그, 스크린샷 등으로 남긴다.

따라서 인증 대응 문서는 기능 관리표가 아니라 다음 연결을 중심으로 설계해야 한다.

Requirement → Feature → Test Case → Test Run → Evidence

Traceability Matrix에는 어떤 ID와 필드를 넣어야 하는가?

최소 단위는 요구사항 하나를 독립적으로 식별하고 검증할 수 있는 행이다. 플랫폼 문서의 항목 번호를 그대로 복사하기보다 프로젝트 내부에서 변경을 추적할 수 있는 ID를 별도로 부여하는 편이 좋다.

필드	목적	예시
Requirement ID	인증 요구사항의 고유 식별	CR-INPUT-014
Source Version	요구사항 출처와 버전 기록	Platform Guide v2026.1
Platform	대상 플랫폼과 SKU 구분	Console A / Console B
Feature ID	구현 기능 또는 시스템 연결	F-INPUT-022
Test Case ID	검증 절차 연결	TC-INPUT-031
Test Run ID	실제 실행 기록 연결	RUN-2026-0830-07
Evidence ID	영상, 로그, 스크린샷 식별	EV-INPUT-031
Build	검증에 사용한 빌드	1.0.0-rc3
Environment	본체, OS, 주변기기, 네트워크 조건	Retail Kit / Offline
Result	Pass, Fail, Blocked, N/A 등	Pass
Owner	현재 조치 책임자	QA Lead
Risk	인증 실패 가능성과 영향도	High
Last Updated	마지막 변경 시점	2026-08-29

Requirement ID와 Test Case ID만 있는 문서는 반쪽짜리 추적성이다. 인증 과정에서 문제가 생기면 실제 실행 결과와 증빙 파일을 찾아야 하므로 Test Run ID, Evidence ID, Build까지 연결해야 한다.

인증 요구사항을 원자화하는 방법은 무엇인가?

플랫폼 인증 문서의 한 문장이 여러 검증 조건을 포함하는 경우가 많다. 이런 문장을 하나의 행으로 관리하면 일부 조건만 테스트하고도 전체가 Pass처럼 보일 수 있다.

다음 기준으로 요구사항을 쪼갠다.

• 트리거가 다르면 분리한다. 예: 연결 해제, 배터리 부족, 계정 전환
• 상태가 다르면 분리한다. 예: 타이틀 화면, 게임 플레이, 일시정지, 로딩
• 입력 장치나 주변기기가 다르면 분리한다.
• 오프라인과 온라인 조건이 다르면 분리한다.
• 정상 흐름과 오류 흐름이 다르면 분리한다.
• 결과를 별도 증빙해야 한다면 분리한다.

좋은 요구사항 행은 다음 질문에 답할 수 있어야 한다.

누가 어떤 환경에서 어떤 동작을 했을 때, 어떤 결과가 나오면 통과하는가?

예를 들어 다음처럼 추상적인 항목은 테스트하기 어렵다.

컨트롤러 연결 변경을 처리한다.

이를 다음과 같이 바꾸면 검증 가능한 요구사항이 된다.

게임 플레이 중 활성 컨트롤러를 분리하면 입력을 중지하고 사용자에게 재연결 안내를 표시한다.

이때 Requirement ID는 CR-INPUT-014, 기능은 컨트롤러 세션 관리자, 테스트 케이스는 연결 해제 시나리오로 연결할 수 있다.

기능·테스트 케이스·증빙은 어떻게 연결하는가?

Traceability Matrix는 한 방향으로만 읽는 문서가 아니다. 요구사항에서 증빙으로 내려갈 수도 있고 실패한 테스트에서 영향을 받는 요구사항으로 올라갈 수도 있어야 한다.

flowchart LR
    R[Requirement ID] --> F[Feature ID]
    F --> T[Test Case ID]
    T --> X[Test Run ID]
    X --> E[Evidence ID]
    X --> S{Result}
    S -->|Pass| P[제출 가능성 검토]
    S -->|Fail| B[결함 및 재검증]
    S -->|Blocked| K[블로커와 일정 영향 기록]

각 연결은 다음 규칙을 따른다.

연결	확인해야 할 질문
Requirement → Feature	어떤 구현 요소가 이 요구사항을 충족하는가?
Feature → Test Case	기능의 정상·오류·경계 조건을 어떻게 검증하는가?
Test Case → Test Run	어느 빌드와 환경에서 실제로 실행했는가?
Test Run → Evidence	결과를 제3자가 재검토할 수 있는 자료가 있는가?
Evidence → Submission Item	인증 제출 패키지의 어느 항목에 사용되는가?

하나의 기능이 여러 요구사항을 충족할 수 있고 하나의 요구사항이 여러 기능에 걸쳐 있을 수도 있다. 따라서 셀에 긴 설명을 반복하기보다 ID를 연결하고 세부 정보는 각 관리 문서에서 유지하는 편이 변경에 강하다.

콘솔 인증 Traceability Matrix 운영 절차 5단계

1단계. 공식 요구사항을 버전과 함께 수집한다

플랫폼별 인증 가이드, 제출 포털 안내, 하드웨어별 추가 조건을 수집한다. 문서명만 기록하지 말고 다음 정보를 함께 남긴다.

• 문서 버전 또는 발행일
• 적용 플랫폼과 지역
• 대상 제품, SKU, 릴리스 유형
• 해석이 필요한 문장과 내부 결정 사항
• 원문 위치 또는 링크
• 담당 검토자

요구사항이 변경되면 기존 행을 조용히 덮어쓰지 말고 변경 이벤트를 기록한다. 인증 실패 원인이 구현 결함이 아니라 요구사항 버전 차이인 경우가 있기 때문이다.

2단계. 요구사항을 위험도와 릴리스 게이트로 분류한다

모든 요구사항을 같은 우선순위로 관리하면 일정 후반에 중요한 항목이 밀린다. 다음처럼 분류할 수 있다.

분류	의미	일정 운영
Critical	제출 불가나 즉시 거절로 이어질 수 있음	초기 프로토타입부터 검증
High	인증 실패 가능성이 높거나 수정 비용이 큼	기능 완료 전 사전 테스트
Medium	특정 조건에서만 발생하거나 우회 가능	RC 단계까지 검증
Low	문서·표현·부가 조건 중심	제출 패키지 점검 시 확인

특히 계정, 저장 데이터, 결제, 네트워크, 개인정보, 컨트롤러 연결, 시스템 일시정지와 같은 영역은 프로젝트 초기에 별도 인증 스파이크를 계획하는 것이 안전하다.

3단계. Feature ID와 Test Case ID를 사전에 배정한다

기능 구현이 끝난 뒤 테스트 케이스를 만들면 이미 만들어진 정상 흐름만 검증하게 된다. 요구사항을 읽는 시점에 테스트 설계도 함께 시작한다.

테스트 케이스에는 다음 요소를 포함한다.

1. 사전 조건: 계정 상태, 네트워크 상태, 저장 데이터, 연결된 장치
2. 실행 절차: 사용자의 입력과 시스템 상태 변화
3. 기대 결과: 화면, 사운드, 입력 잠금, 데이터 보존 결과
4. 복구 절차: 재연결, 재시작, 세션 복귀 방법
5. 증빙 조건: 영상의 시작 상태, 로그 레벨, 스크린샷 시점

4단계. 실행 결과와 증빙을 같은 실행 단위로 묶는다

증빙 파일은 테스트 결과와 분리해 보관하지 않는다. 최소한 다음 메타데이터를 파일명이나 증빙 레지스트리에 포함한다.

EV-INPUT-031__TC-INPUT-031__RUN-2026-0830-07__build-1.0.0-rc3.mp4

증빙 레지스트리 예시는 다음과 같다.

Evidence ID,Test Case ID,Build,Environment,Type,Location,Retention,Reviewer
EV-INPUT-031,TC-INPUT-031,1.0.0-rc3,Retail Kit Offline,Video,qa-evidence/EV-INPUT-031.mp4,Submission,QA Lead
EV-INPUT-032,TC-INPUT-032,1.0.0-rc3,Retail Kit Online,Log,qa-evidence/EV-INPUT-032.zip,Submission,Network QA

증빙에는 결과만 보이지 않고 재현에 필요한 맥락도 보여야 한다. 영상이라면 빌드 번호와 플랫폼이 식별되어야 하고 로그라면 타임스탬프와 테스트 단계가 확인되어야 한다.

5단계. 정기 리뷰와 릴리스 게이트에 연결한다

Matrix는 문서 담당자만 관리하는 파일이 아니다. 주간 리뷰와 RC 승인 절차에 포함해야 실제 상태가 반영된다.

권장 리뷰 순서는 다음과 같다.

1. 새 요구사항과 변경된 요구사항을 확인한다.
2. Feature, Test Case, Evidence의 연결이 끊긴 행을 찾는다.
3. Critical과 High 항목의 Fail, Blocked 상태를 먼저 처리한다.
4. 빌드가 바뀌었지만 재검증되지 않은 항목을 찾는다.
5. 제출 패키지에 사용할 증빙의 접근 권한과 보존 상태를 확인한다.
6. 담당자와 완료 예정일을 확정한다.

Matrix 상태값은 어떻게 설계해야 하는가?

Pass와 Fail만으로는 일정과 협업 상태를 설명하기 어렵다. 다음 상태를 구분하면 의사결정이 빨라진다.

상태	의미	다음 조치
Not Started	테스트 설계 또는 실행 전	담당자와 예정일 지정
Ready	테스트와 환경이 준비됨	실행 예약
Pass	정의된 조건을 충족함	증빙 검토 및 제출 연결
Fail	기대 결과를 충족하지 못함	결함 등록과 재검증
Blocked	외부 의존성이나 환경 문제로 실행 불가	블로커와 일정 영향 기록
N/A	해당 제품·플랫폼 조건에 적용되지 않음	근거와 승인자 기록
Waived	위험을 검토한 뒤 예외 승인됨	승인 문서와 만료 조건 기록

N/A와 Waived는 편의상 사용하는 보류 상태가 아니다. 둘 다 적용 제외 또는 예외를 뒷받침하는 근거가 필요하다. 승인자와 승인일이 없는 예외는 인증 제출 직전에 다시 이슈가 된다.

변경 관리는 어떤 방식으로 해야 하는가?

다음 변경은 Matrix를 다시 검토해야 하는 대표적인 영향 이벤트다.

• 플랫폼 인증 가이드의 버전 변경
• SKU, 지역, 언어 또는 제품 에디션 변경
• 입력 시스템과 계정 시스템 변경
• 저장 데이터 구조 변경
• 네트워크 백엔드 또는 온라인 서비스 변경
• 사용자 인터페이스와 오류 메시지 변경
• 빌드 구성, 패키징, 권한, 설치 방식 변경

변경이 발생하면 먼저 변경된 Requirement ID를 찾고 연결된 Feature, Test Case, Evidence를 역추적한다. 이후 다음 정보를 변경 로그에 남긴다.

Change ID: CHG-2026-018
Source: Platform Guide v2026.1
Affected Requirements: CR-INPUT-014, CR-SESSION-009
Impact: 컨트롤러 재연결 테스트와 기존 영상 증빙 재검토 필요
Decision: RC4에서 재실행
Owner: QA Lead
Due Date: 2026-09-03

핵심은 모든 테스트를 무조건 다시 실행하는 것이 아니다. 변경 영향 분석을 통해 재검증 범위를 합리적으로 좁히고 그 판단을 기록하는 것이다.

인증 준비도를 어떤 지표로 측정할까?

단순한 Pass 비율은 위험을 숨길 수 있다. 예를 들어 Low 항목은 모두 통과했지만 Critical 항목 하나가 Blocked일 수 있다.

다음 지표를 함께 본다.

• 요구사항 연결률: Feature ID가 연결된 Requirement 비율
• 검증 설계율: Test Case ID가 연결된 Requirement 비율
• 실행 완료율: Test Run이 존재하는 Test Case 비율
• 증빙 완성률: 유효한 Evidence가 연결된 Pass 항목 비율
• Critical 미해결 수: Critical 등급의 Fail·Blocked·미실행 개수
• 변경 영향 미검토 수: 변경 후 재평가되지 않은 연결의 개수

증빙 완성률은 다음처럼 계산할 수 있다.

$$증빙 완성률 = 유효한 Evidence가 연결된 Pass 항목 수 ÷ Pass 항목 수 × 100$$

이 지표는 문서 품질을 측정하는 보조 수단이다. 최종 승인 기준은 숫자 하나가 아니라 위험도, 예외 승인, 플랫폼별 제출 조건을 함께 봐야 한다.

자주 묻는 질문(FAQ)

Traceability Matrix와 테스트 케이스 목록은 무엇이 다른가?

테스트 케이스 목록은 검증 절차 중심이다. Traceability Matrix는 요구사항에서 기능, 테스트 실행, 증빙까지의 양방향 연결과 누락 여부를 관리한다.

모든 테스트 결과를 영상으로 남겨야 하는가?

그럴 필요는 없다. 플랫폼 가이드와 내부 제출 기준에 따라 영상, 로그, 스크린샷, 실행 기록을 선택한다. 다만 어떤 증빙 형식을 선택했는지와 그 자료가 요구사항을 어떻게 입증하는지는 기록해야 한다.

빌드가 바뀌면 모든 항목을 다시 테스트해야 하는가?

변경 영향 분석에 따라 범위를 정한다. 입력, 저장, 계정, 네트워크처럼 변경의 파급 범위가 큰 영역은 회귀 검증을 넓게 잡고 영향이 없는 문서 항목은 검토 기록으로 대체할 수 있다.

마무리: Matrix를 문서가 아니라 릴리스 의사결정 도구로 운영하기

콘솔 인증 대응에서 Traceability Matrix의 가치는 표를 만드는 데 있지 않다. 요구사항이 구현되었는지 실제로 검증되었는지 제출 가능한 증빙이 있는지 변경 이후에도 유효한지를 한 화면에서 판단하게 만드는 데 있다.

프로젝트 시작 시 Requirement ID를 원자화하고 Feature·Test Case·Evidence ID를 연결해 두면 인증 준비가 일정 막판의 문서 작업으로 몰리지 않는다. 여기에 빌드, 환경, 상태, 예외 승인, 변경 이력을 함께 관리하면 팀은 인증 실패 위험을 조기에 발견하고 수정 범위와 출시 일정을 근거 있게 조정할 수 있다.