외주 마일스톤 납품물을 증빙 기준으로 자동 체크하는 Acceptance Evidence 운영법
외주 마일스톤 납품물을 감으로 검수하지 않고 요구사항, 실행 로그, 테스트 결과로 자동 판정하는 Acceptance Evidence 설계법과 운영 템플릿을 정리합니다.
핵심 요약
외주 마일스톤 검수는 결과물의 인상보다 요구사항을 입증하는 증거 묶음인 Acceptance Evidence를 기준으로 운영해야 합니다. 각 인수 기준에 식별자, 판정 규칙, 증거 형식, 재현 절차를 연결하고 GitHub Actions, Jira 또는 Linear 같은 협업 도구에 자동 검증을 붙이면 누락과 해석 차이를 줄일 수 있습니다.
핵심은 다음 세 가지입니다.
- 마일스톤 요구사항을 관찰 가능한 인수 기준으로 쪼갭니다.
- 스크린샷, 빌드 해시, 테스트 로그, 영상, 변경 파일 목록을 기준별로 연결합니다.
- 모든 기준이 충족되거나 예외가 승인되었을 때만
Accepted상태로 변경합니다.
Acceptance Evidence란 무엇인가?
Acceptance Evidence는 외주 납품물이 계약서나 작업 명세서의 인수 기준을 충족했다는 사실을 확인할 수 있는 증거 묶음입니다. 단순히 “기능 구현 완료”라고 보고하는 것이 아니라 누가 어떤 버전에서 어떤 절차로 확인했는지를 남기는 방식입니다.
예를 들어 “인벤토리 화면을 구현한다”는 스코프는 검수 기준으로 부족합니다. 다음처럼 관찰 가능한 조건으로 바꿔야 합니다.
| 구분 | 모호한 요구사항 | 증빙 가능한 인수 기준 |
|---|---|---|
| 기능 | 인벤토리를 구현한다 | 아이템 20개를 추가했을 때 5열 그리드에 표시된다 |
| 입력 | 조작이 자연스럽다 | 마우스 드래그로 아이템을 슬롯 간 이동할 수 있다 |
| 예외 | 오류를 처리한다 | 가득 찬 슬롯으로 이동하면 원래 위치로 돌아간다 |
| 성능 | 충분히 빠르다 | 기준 PC에서 60초 동안 프레임 드롭 5회 이하를 기록한다 |
| 납품 | 소스를 전달한다 | 지정 브랜치의 커밋 해시와 변경 파일 목록을 제출한다 |
이 기준은 결과물 자체뿐 아니라 검수자가 같은 절차를 반복했을 때 같은 결론에 도달할 수 있어야 합니다.
외주 납품 검수가 자주 꼬이는 이유는 무엇인가?
외주 마일스톤에서 분쟁이 생기는 원인은 결과물의 품질만이 아닙니다. 요구사항과 검수 방법이 서로 다른 수준으로 작성되어 있기 때문입니다.
- 발주자는 기대하는 사용자 경험을 설명하고 수주자는 구현 범위로 해석합니다.
- “완료”의 의미가 기능 구현, 커밋 완료, 플레이 가능한 빌드 중 무엇인지 합의되지 않습니다.
- 스크린샷은 제출되었지만 어떤 커밋에서 촬영했는지 알 수 없습니다.
- 영상은 정상 흐름만 보여주고 실패 조건이나 경계값을 보여주지 않습니다.
- 자동 테스트가 실패해도 담당자가 수동으로 상태를
Accepted로 변경할 수 있습니다. - 마일스톤 후반에 누락된 증거를 발견해 재작업 비용이 커집니다.
따라서 Acceptance Evidence는 검수 단계에서 새로 만드는 문서가 아니라 마일스톤 정의 단계부터 설계해야 합니다.
인수 기준과 증거를 어떻게 연결할까?
기준마다 고유한 ID를 부여하고 판정 방법을 명시합니다. 기준 ID는 계약서, 작업 티켓, 빌드 리포트, 이슈에 동일하게 사용해야 합니다.
권장 필드는 다음과 같습니다.
| 필드 | 목적 | 예시 |
|---|---|---|
criterion_id | 기준을 추적한다 | INV-UI-003 |
requirement | 충족해야 할 조건 | 아이템 드래그 이동 |
verification_method | 판정 방법 | 수동 시나리오 + 자동 테스트 |
evidence_required | 제출해야 할 증거 | 영상, 테스트 로그, 빌드 해시 |
owner | 증거 제출 책임자 | 외주 담당자 |
reviewer | 승인 책임자 | 프로듀서 또는 QA |
status | 현재 상태 | Pending, Failed, Accepted |
exception | 예외 승인 정보 | 승인자, 만료일, 보완 조건 |
증거의 5가지 품질 조건
좋은 증거는 많을 필요가 없습니다. 다음 조건을 만족하면 됩니다.
- 관찰 가능해야 합니다. “재미있다”보다 “아이템을 드래그하면 슬롯 위치가 교체된다”가 적합합니다.
- 재현 가능해야 합니다. 테스트 맵, 입력 순서, 디바이스 조건을 함께 기록합니다.
- 버전에 귀속되어야 합니다. Git 커밋 해시나 빌드 번호를 연결합니다.
- 시간 범위가 명확해야 합니다. 제출일, 테스트일, 사용한 브랜치를 남깁니다.
- 기준 하나 이상과 직접 연결되어야 합니다. 관련 없는 스크린샷을 증거 개수로 세지 않습니다.
Acceptance Evidence 운영 흐름은 어떻게 설계할까?
다음 흐름은 소규모 게임 팀과 외주 파트너가 함께 사용하기 적합한 기본 구조입니다.
flowchart TD
A[마일스톤 요구사항 정의] --> B[인수 기준 ID 발급]
B --> C[외주 납품 및 Evidence 제출]
C --> D[자동 검사: 파일, 해시, 테스트, 메타데이터]
D --> E{모든 필수 기준 통과?}
E -->|예| F[리뷰어 승인]
E -->|아니오| G[반려 사유와 보완 기한 기록]
F --> H[Accepted 및 마일스톤 정산]
G --> C자동 검사는 사람의 판단을 없애는 장치가 아니라 사람이 확인해야 할 범위를 줄이는 장치입니다. 파일 존재 여부, 빌드 식별자, 테스트 성공 여부는 자동화하고 아트 방향성, 조작감, 연출 품질처럼 정성적인 항목은 리뷰어가 판단하도록 분리합니다.
1단계: 마일스톤을 검수 가능한 단위로 쪼개기
마일스톤 이름을 기준으로 삼지 말고 사용자 행동과 시스템 상태를 기준으로 분해합니다. “전투 시스템 1차 완료” 대신 다음과 같이 작성합니다.
- 플레이어가 적을 타깃으로 지정할 수 있습니다.
- 지정된 타깃에게 기본 공격을 실행할 수 있습니다.
- 공격 쿨다운 중에는 동일 공격이 중복 실행되지 않습니다.
- 적 처치 후 보상 이벤트가 한 번만 발생합니다.
- 전투 진입과 종료 로그가 지정 포맷으로 기록됩니다.
각 기준에는 필수 여부도 표시합니다.
| 우선순위 | 의미 | 운영 규칙 |
|---|---|---|
| Must | 없으면 마일스톤 목적을 달성할 수 없음 | 미충족 시 자동 반려 |
| Should | 품질과 완성도를 높임 | 미충족 시 조건부 승인 가능 |
| Could | 후속 마일스톤으로 미뤄도 됨 | 현재 승인에 영향 없음 |
이 우선순위를 계약서와 티켓에 함께 기록하면 “추가 요청”과 “필수 납품 누락”을 구분하기 쉬워집니다.
2단계: 기준별 증거 유형을 미리 지정하기
증거 형식은 납품 직전에 정하지 않습니다. 기준을 작성하는 순간 필요한 증거를 함께 결정합니다.
| 인수 기준 유형 | 권장 증거 | 자동 체크 가능 여부 |
|---|---|---|
| 파일 및 리소스 | 변경 파일 목록, 파일 해시, 폴더 구조 | 높음 |
| 게임플레이 기능 | 테스트 리포트, 재현 영상, 입력 시나리오 | 중간 |
| UI 레이아웃 | 해상도별 스크린샷, 기준 이미지 비교 | 중간 |
| 성능 | 프로파일러 CSV, 프레임 타임 로그 | 높음 |
| 오디오 | 에셋 목록, 샘플레이트 검사, 재생 영상 | 높음 |
| 코드 품질 | 빌드 로그, 정적 분석 결과, 리뷰 링크 | 높음 |
| 감성 및 연출 | 리뷰 코멘트, 비교 레퍼런스, 승인 기록 | 낮음 |
스크린샷만으로 기능 완료를 증명하려 하면 실패 조건과 버전 정보가 빠지기 쉽습니다. 기능 기준에는 최소한 다음 메타데이터를 붙이는 편이 안전합니다.
- 게임 빌드 번호
- Git 커밋 해시
- 테스트 맵 또는 씬 이름
- 입력 장치와 해상도
- 재현 단계
- 기대 결과와 실제 결과
- 캡처 또는 로그 생성 시각
3단계: Evidence 패키지의 표준 구조 만들기
파트너마다 제출 방식이 다르면 검수 자동화가 어렵습니다. 저장소나 공유 드라이브에 마일스톤별 디렉터리 규칙을 정하고 파일 이름에도 기준 ID를 포함합니다.
milestone-m03/
├── manifest.yaml
├── build/
│ └── game-m03-1842.zip
├── logs/
│ ├── INV-UI-003-test.log
│ └── PERF-001-frame-time.csv
├── screenshots/
│ ├── INV-UI-003-normal.webp
│ └── INV-UI-003-full-slot.webp
├── videos/
│ └── INV-UI-003-repro.mp4
└── review/
└── reviewer-notes.mdmanifest.yaml에는 패키지의 기준 목록과 파일 연결 정보를 둡니다.
milestone_id: M03
build_number: 1842
git_commit: 8f4a2c1
submitted_at: 2026-08-24T09:30:00+09:00
criteria:
- id: INV-UI-003
status: pass
evidence:
- screenshots/INV-UI-003-normal.webp
- videos/INV-UI-003-repro.mp4
- id: PERF-001
status: pass
evidence:
- logs/PERF-001-frame-time.csv운영 환경에서 사용하는 실제 날짜와 커밋 정보는 제출 시점에 생성되어야 합니다. 예시의 값은 형식 설명을 위한 샘플입니다.
4단계: 무엇을 자동으로 검사할까?
자동화 대상은 명확한 참과 거짓으로 판정할 수 있는 항목부터 시작합니다.
파일과 메타데이터 검사
manifest.yaml이 존재하는지 확인합니다.- 모든 Must 기준이 manifest에 등록되어 있는지 확인합니다.
- manifest에 적힌 증거 파일이 실제로 존재하는지 확인합니다.
- 빌드 번호, 브랜치, 커밋 해시가 일치하는지 확인합니다.
- 파일의 SHA-256 해시를 계산해 제출 이후 변경 여부를 확인합니다.
- 금지된 임시 파일과 누락된 라이선스 문서를 검사합니다.
테스트와 로그 검사
- 자동 테스트 종료 코드가 0인지 확인합니다.
- 테스트 리포트에 기준 ID가 포함되어 있는지 확인합니다.
- 성능 로그의 측정 시간과 샘플 수가 최소 조건을 충족하는지 확인합니다.
- 크래시, 오류 로그, 실패한 어설션이 있는지 확인합니다.
- 테스트가 지정된 빌드 번호에서 실행되었는지 확인합니다.
영상과 이미지 검사
영상의 재생 여부나 길이는 자동으로 확인할 수 있지만 “조작감이 좋다”는 자동 판정하기 어렵습니다. 이미지의 해상도와 파일 존재 여부는 자동 검사하고 구성과 품질은 리뷰어가 확인합니다.
5단계: 자동 판정과 사람 검토를 분리하기
모든 기준을 하나의 점수로 합치면 중요한 실패가 평균에 묻힐 수 있습니다. 특히 보안, 저장 데이터, 크래시, 계약상 필수 기능은 가중치로 보정하기보다 하드 게이트로 관리하는 편이 안전합니다.
권장 판정 규칙은 다음과 같습니다.
정량 점수가 필요한 경우에는 보조 지표로만 사용합니다.
예를 들어 Evidence Coverage가 100%라도 Must 기준 하나가 실패하면 마일스톤은 승인되지 않아야 합니다. 반대로 Should 기준 하나가 부족한 경우에는 조건부 승인과 보완 기한을 별도로 기록할 수 있습니다.
GitHub Actions로 기본 검사를 자동화하는 예시
게임 엔진이나 저장소 구조에 따라 명령은 달라지지만 자동화의 뼈대는 비슷합니다. 아래 예시는 manifest 파일의 존재와 필수 증거 파일 누락을 검사하는 개념적인 워크플로입니다.
name: acceptance-evidence-check
on:
pull_request:
paths:
- "milestones/**"
jobs:
validate-evidence:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check manifest
run: test -f milestones/m03/manifest.yaml
- name: Check evidence files
shell: bash
run: |
required=(
"milestones/m03/screenshots/INV-UI-003-normal.webp"
"milestones/m03/videos/INV-UI-003-repro.mp4"
"milestones/m03/logs/PERF-001-frame-time.csv"
)
for file in "${required[@]}"; do
test -f "$file" || { echo "Missing evidence: $file"; exit 1; }
done실제 프로젝트에서는 이 검사 뒤에 JSON Schema 또는 YAML Schema 검증, 테스트 실행, 빌드 생성, SHA-256 기록을 추가할 수 있습니다. 단, 자동 검사가 통과했다는 사실과 제품이 최종적으로 승인되었다는 사실은 분리해야 합니다.
반려와 조건부 승인 규칙을 어떻게 운영할까?
반려 사유는 “미완성”처럼 넓게 쓰지 말고 기준 ID와 재현 결과를 포함해야 합니다.
| 상태 | 의미 | 다음 조치 |
|---|---|---|
Pending | 증거 제출 전 또는 검토 전 | 제출자와 기한 확인 |
Evidence Missing | 기준은 있으나 증거가 없음 | 누락 파일 제출 |
Failed | 증거는 있으나 판정 조건 불충족 | 수정 후 재검증 |
Needs Review | 자동 검사는 통과했지만 정성 판단 필요 | 리뷰어 승인 대기 |
Conditionally Accepted | Should 기준 일부가 미충족 | 보완 기한과 책임자 등록 |
Accepted | 필수 기준과 승인 절차 완료 | 정산 및 다음 마일스톤 진행 |
조건부 승인을 허용할 때는 반드시 세 가지를 남깁니다.
- 미충족 기준 ID
- 보완 완료 기한과 담당자
- 보완이 늦어질 때의 처리 규칙
이 정보가 없으면 조건부 승인이 사실상 미확정 상태로 남습니다.
운영 회고에서 어떤 지표를 볼까?
Acceptance Evidence는 검수 문서이면서 협업 프로세스의 품질을 측정하는 장치이기도 합니다. 다음 지표를 마일스톤 회고에서 확인하면 반복되는 문제를 찾기 좋습니다.
| 지표 | 계산 방법 | 해석 |
|---|---|---|
| 증거 누락률 | 누락된 증거 수 ÷ 필수 증거 수 | 제출 가이드의 명확성 |
| 최초 통과율 | 첫 검수에서 통과한 기준 수 ÷ 전체 기준 수 | 요구사항과 구현의 정렬 정도 |
| 재검수 횟수 | 반려 후 다시 검수한 횟수 | 기준 또는 작업 품질의 문제 |
| 증거 준비 리드타임 | 제출 완료부터 승인까지 걸린 시간 | 검수 병목 정도 |
| 기준 변경률 | 마일스톤 중 변경된 기준 수 ÷ 전체 기준 수 | 스코프 안정성 |
지표의 목적은 외주사를 단순 비교하는 것이 아니라 프로세스를 개선하는 데 있습니다. 예를 들어 증거 누락률이 계속 높다면 담당자를 탓하기보다 템플릿, 파일 이름 규칙, 제출 체크리스트를 먼저 개선해야 합니다.
현장에서 바로 쓰는 Acceptance Evidence 체크리스트
마일스톤 시작 전
- Must, Should, Could 기준을 구분했다.
- 각 기준에 검증 방법과 증거 형식을 지정했다.
- 테스트 환경과 기준 디바이스를 합의했다.
- 제출 폴더, 파일 이름, manifest 스키마를 공유했다.
- 기준 변경 승인자를 정했다.
납품 시
- 빌드 번호와 Git 커밋 해시를 기록했다.
- 모든 Must 기준에 증거 파일을 연결했다.
- 정상 흐름과 실패 조건을 모두 검증했다.
- 자동 테스트 로그와 종료 결과를 첨부했다.
- 변경 파일 목록과 알려진 이슈를 제출했다.
승인 시
- 자동 검사 결과를 확인했다.
- 정성 검토가 필요한 기준을 사람이 확인했다.
- 반려 또는 조건부 승인 사유를 기준 ID와 함께 기록했다.
- 최종 상태를 변경한 사람과 시각을 남겼다.
- 다음 마일스톤으로 넘길 잔여 작업을 분리했다.
자주 묻는 질문(FAQ)
Acceptance Evidence와 QA 테스트 결과는 같은 것인가요?
같지 않습니다. QA 테스트 결과는 품질 검증 결과이고 Acceptance Evidence는 계약상 인수 기준을 충족했다는 사실을 입증하는 패키지입니다. QA 결과가 핵심 증거가 될 수는 있지만 빌드 버전, 기준 ID, 제출 책임자 같은 인수 메타데이터도 함께 필요합니다.
스크린샷만 제출해도 마일스톤을 승인할 수 있나요?
단순 UI 상태를 보여주는 기준이라면 가능하지만 기능 구현 전체를 증명하기에는 부족합니다. 기능 기준에는 재현 절차, 빌드 번호, 테스트 로그 또는 영상 중 하나 이상을 추가하고 실패 조건도 확인하는 것이 좋습니다.
모든 검수를 자동화해야 하나요?
아닙니다. 파일 존재 여부, 해시, 빌드 번호, 자동 테스트, 성능 로그처럼 명확한 항목부터 자동화하면 됩니다. 조작감, 연출 의도, 아트 방향성처럼 맥락과 감각이 필요한 항목은 리뷰어의 판단과 코멘트로 남기는 편이 적합합니다.
정리
외주 마일스톤 운영의 핵심은 납품물을 많이 받는 것이 아니라 각 요구사항이 어떤 증거로 검증되었는지 추적하는 것입니다. 기준 ID와 표준 manifest를 만들고 자동 검사와 사람 검토를 분리하면 일정, 스코프, 품질, 정산에 대한 대화가 같은 기록 위에서 이루어집니다.
처음부터 복잡한 시스템을 만들 필요는 없습니다. 다음 마일스톤 하나를 골라 Must 기준 다섯 개를 정의하고 빌드 번호, 커밋 해시, 테스트 로그, 증거 파일을 연결하는 것부터 시작하면 됩니다.
