게임 외주 계약 관리와 품질 검수 프로세스: 아티스트·프로그래머 납품을 안정화하는 방법
게임 외주 아티스트와 프로그래머의 계약, 일정, 변경 요청, 검수 기준을 한 흐름으로 관리하는 실무 프로세스를 정리합니다. 재작업과 납기 지연을 줄이는 문서·승인·품질 관리 방법을 제공합니다.
게임 외주 관리의 핵심은 계약서에 산출물과 승인 기준을 측정 가능하게 적고 작업 중에는 변경 요청을 통제하며 납품 전에는 동일한 체크리스트로 검수하는 것입니다. 아트와 프로그래밍 모두 ‘좋아 보인다’가 아니라 파일 형식, 성능 기준, 통합 조건, 수정 횟수, 승인권자를 명확히 해야 재작업과 납기 분쟁을 줄일 수 있습니다.
외주 계약 관리가 어려워지는 이유는 무엇인가?
외주 문제는 대개 실력 부족보다 모호한 기대치에서 시작합니다. 기획자가 생각한 캐릭터 표현, 아티스트가 이해한 스타일, 클라이언트가 승인할 기준이 서로 다르면 결과물이 나와도 완료로 판정하기 어렵습니다. 프로그래밍 외주도 마찬가지입니다. ‘인벤토리 구현’은 기능 한 줄이 아니라 데이터 구조, UI 상태, 저장 규칙, 예외 처리, 성능, 테스트 범위를 포함합니다.
계약서와 작업 지시서(SOW, Statement of Work)는 법무 문서이면서 동시에 프로젝트의 실행 명세여야 합니다.
| 관리 항목 | 아티스트 외주 예시 | 프로그래머 외주 예시 | 검수 가능한 기준 |
|---|---|---|---|
| 산출물 | 3D 캐릭터 1종, 텍스처, 애니메이션 | Unity 인벤토리 모듈 | 파일과 기능 목록을 수량화 |
| 기술 규격 | FBX, 1m 단위, 2K PNG, PBR | Unity 6, C#, Addressables | 도구 버전과 포맷 명시 |
| 품질 기준 | 25,000 triangles 이하, 본 80개 이하 | GC Alloc 0 B/frame, 오류 로그 없음 | 수치와 재현 절차 제시 |
| 승인 절차 | 러프 → 중간본 → 최종본 | 설계 → PR → 통합 빌드 | 단계별 승인권자 지정 |
| 수정 범위 | 단계별 2회, 범위 변경은 별도 견적 | 결함 수정과 기능 변경 구분 | 변경 요청서로 기록 |
외주 계약서와 SOW에는 무엇을 넣어야 할까?
계약서 본문만으로 모든 제작 세부 사항을 담기 어렵다면 계약서에는 책임과 대금 조건을 두고 SOW를 별첨하는 방식이 실무적입니다. SOW는 계약 대상, 완료 정의, 검수 기준을 한 문서에서 연결합니다.
1. 산출물의 완료 정의(Definition of Done)를 작성한다
완료는 ‘파일을 전달했다’가 아니라 ‘프로젝트에 통합할 수 있다’여야 합니다. 예를 들어 Unity용 캐릭터 에셋의 완료 정의는 다음처럼 작성할 수 있습니다.
- Unity 6 프로젝트에서 Import 오류 없이 로드된다.
- FBX 1개, Albedo/Normal/Mask 텍스처 각 1개를 포함한다.
- Humanoid Avatar가 유효하며 애니메이션 8종이 재생된다.
- LOD0 기준 Triangle Count는 25,000 이하이다.
- 머티리얼은 URP Lit Shader를 사용하며 외부 유료 에셋 의존성이 없다.
- Git LFS 또는 지정한 저장소 경로에 원본과 최종 파일을 업로드한다.프로그래밍 외주는 사용자 시나리오와 실패 조건을 함께 정의합니다. 예를 들어 저장 기능이라면 저장 성공뿐 아니라 파일이 없을 때, 데이터 버전이 다를 때, 용량이 초과될 때의 동작까지 정해야 합니다.
2. 대금 지급을 마일스톤 승인과 연결한다
선금·중도금·잔금의 비율보다 중요한 것은 각 지급 조건이 승인 가능한 결과와 연결되는지입니다. ‘작업 진행률 50%’처럼 해석이 갈리는 표현은 피합니다.
예를 들어 아트 외주는 콘셉트 승인 20%, 중간 모델 승인 40%, 엔진 통합 검수 통과 40%로 나눌 수 있습니다. 프로그래밍 외주는 기술 설계 승인, 기능 데모, 통합 테스트 통과를 지급 조건으로 설정할 수 있습니다.
3. 수정과 변경 요청을 구분한다
계약된 요구사항을 충족하지 못한 부분의 수정은 하자 보완입니다. 반면 승인된 요구사항에 없던 스킨 추가, 플랫폼 추가, 데이터 구조 변경은 변경 요청(Change Request)입니다. 이를 섞으면 외주자는 끝없는 수정을 우려하고 발주자는 계약 범위 내 수정이라고 판단해 충돌합니다.
변경 요청서에는 최소한 다음을 기록합니다.
- 요청 일자와 요청자
- 변경 전·후 요구사항
- 일정 영향과 추가 비용
- 영향받는 산출물과 테스트 항목
- 승인자와 승인 일시
게임 외주 일정은 어떻게 운영할까?
일정표는 납품일만 적는 문서가 아닙니다. 불확실성을 가장 이른 승인 단계로 옮기는 장치입니다. 최종 납품에서 처음 보는 결과물이 많을수록 재작업 비용은 커집니다.
flowchart LR
A[킥오프: SOW·레퍼런스 확정] --> B[초기 시안·기술 설계]
B --> C{승인}
C -->|수정 필요| B
C -->|승인| D[중간 납품]
D --> E[통합 검수]
E --> F{완료 기준 충족}
F -->|아니오| G[결함 수정]
G --> E
F -->|예| H[최종 승인·잔금]킥오프에서 합의할 항목
- 단일 소통 창구를 정한다. 발주사와 외주사 양쪽에 PM 또는 책임자를 한 명씩 지정합니다. 피드백은 이 창구를 통해 취합해 전달합니다.
- 레퍼런스의 우선순위를 정한다. 여러 참고 이미지가 충돌할 수 있으므로 ‘색감은 A, 비율은 B, UI 밀도는 C’처럼 항목별 기준을 분리합니다.
- 리뷰 주기와 응답 기한을 정한다. 예를 들어 매주 화요일 빌드 제출, 발주사는 영업일 기준 2일 안에 승인 또는 수정 의견을 전달하도록 합의합니다.
- 의존성을 공개한다. 외주 결과물이 내부 애니메이션, 서버 API, 라이선스 에셋에 의존한다면 제공 책임자와 제공일을 일정에 포함합니다.
아트 외주 품질 검수 체크리스트
아트 검수는 미적 평가와 기술 검수를 분리하는 편이 좋습니다. 미적 피드백은 주관성이 크지만 기술 기준은 재현 가능해야 합니다.
비주얼 검수
- 콘셉트 문서와 실루엣, 비율, 색상 팔레트가 일치하는가?
- 카메라 거리와 실제 게임 조명에서 읽히는가?
- UI 아이콘은 최소 표시 크기에서 식별 가능한가?
- 캐릭터의 표정, 장비, 이펙트가 게임 등급 및 세계관 가이드에 맞는가?
기술 검수
- 파일명, 폴더 구조, 피벗, 스케일이 팀 규칙에 맞는가?
- 텍스처 해상도와 압축 설정이 플랫폼 메모리 예산에 맞는가?
- 모델의 노멀, UV, 웨이트, 리깅, 루트 모션이 정상인가?
- Unity Profiler 또는 Unreal Insights에서 드로우콜, 텍스처 메모리, 셰이더 오류를 확인했는가?
아트 검수 결과는 ‘수정 필요’만 남기지 말고 위치와 기대 결과를 적습니다. 예를 들어 ‘머리카락이 이상함’보다 ‘전방 카메라 5m 거리에서 머리카락 알파 경계가 깜빡인다. Alpha Clipping 임계값과 텍스처 가장자리를 조정해 해결해 달라’가 실행 가능한 피드백입니다.
프로그래밍 외주 품질 검수는 어떻게 해야 할까?
프로그래밍 납품은 기능 데모만 보고 승인하면 위험합니다. 소스 코드, 빌드, 문서, 테스트 가능한 재현 절차를 함께 받아야 합니다.
1. 통합 전 정적 검토를 한다
PR(Pull Request) 또는 패치 단위로 코드 구조를 검토합니다. 프로젝트의 코딩 컨벤션, 네임스페이스, 외부 의존성, 라이선스, 설정 파일 변경을 확인합니다. 특히 외주 코드가 전역 싱글턴, 하드코딩된 경로, 특정 씬 이름에 과도하게 결합되어 있지 않은지 봅니다.
2. 인수 조건에 따라 기능 테스트를 한다
기능별로 Given-When-Then 형식의 인수 테스트를 작성하면 검수 범위를 명확히 할 수 있습니다.
Given: 플레이어가 빈 인벤토리를 보유한다.
When: 최대 적재량이 20인 회복 아이템을 21개 획득한다.
Then: 인벤토리에는 20개만 저장되고 1개는 월드 드롭 또는 보관함으로 이동한다.
And: 오류 로그가 발생하지 않는다.3. 비기능 요구사항을 측정한다
성능과 안정성은 감상으로 승인하지 않습니다. 목표 플랫폼과 측정 장면을 고정하고 수치를 기록합니다.
| 항목 | 예시 기준 | 확인 방법 |
|---|---|---|
| 프레임 시간 | 대상 기기에서 16.67 ms 이하 목표 | Unity Profiler, Unreal Insights |
| 메모리 할당 | 매 프레임 GC Alloc 0 B | Profiler Timeline |
| 오류 | Error 로그 0건 | 개발 빌드 로그 |
| 저장 안정성 | 100회 반복 저장·불러오기 성공 | 자동 또는 수동 반복 테스트 |
| 회귀 | 기존 핵심 시나리오 통과 | 스모크 테스트 목록 |
기준 프레임 시간은 목표 FPS로부터 계산할 수 있습니다.
예를 들어 60 FPS의 프레임 예산은 16.67 ms입니다. 다만 외주 모듈 하나에 전체 프레임 예산을 적용하지 말고 프로파일링 구간과 해당 기능의 허용 비용을 SOW에 별도로 적는 것이 정확합니다.
검수 피드백은 어떤 형식으로 전달해야 재작업이 줄어들까?
좋은 피드백은 우선순위와 완료 조건을 포함합니다. 한 이슈에 여러 요구사항을 섞지 말고 추적 도구의 티켓 하나가 검증 가능한 수정 단위가 되게 합니다.
| 필드 | 작성 예시 |
|---|---|
| 제목 | [P1] 장비 교체 후 공격력 UI가 갱신되지 않음 |
| 환경 | Windows 11, Unity 6.0.0f1, 개발 빌드 0.8.3 |
| 재현 절차 | 장비 A 장착 → 장비 B 장착 → 캐릭터 정보 창 열기 |
| 실제 결과 | 이전 장비 A의 공격력이 표시됨 |
| 기대 결과 | 장비 B의 공격력이 즉시 표시됨 |
| 증빙 | 스크린샷, 동영상, 로그, 저장 데이터 |
| 완료 조건 | 장비 교체 10회 반복 시 UI와 실제 능력치가 모두 일치 |
우선순위도 통일합니다. 예를 들어 P0는 빌드 불가·데이터 손실, P1은 핵심 플레이 차단, P2는 기능 오류지만 우회 가능, P3는 경미한 표현 또는 사용성 문제로 정의합니다. 외주자와 내부 팀이 같은 기준을 써야 ‘급한 수정’이 남발되지 않습니다.
자주 묻는 질문 (FAQ)
외주 작업물은 몇 번까지 수정 요청할 수 있나?
계약 범위와 승인 단계에 따라 다릅니다. 요구사항 미충족은 합의한 하자 보완 기간 동안 수정 대상으로 두고 승인 후의 기능·방향 변경은 변경 요청으로 별도 일정과 비용을 협의하는 방식이 안전합니다.
최종 납품 전에 소스 파일과 원본 파일을 받아야 하나?
재사용·유지보수가 필요한 게임 프로젝트라면 받아야 합니다. 아트는 원본 작업 파일과 내보낸 파일을 프로그래밍은 소스 코드, 빌드 방법, 의존성 목록, 설정값, 간단한 운영 문서를 납품 목록에 포함하세요.
외주 결과물이 기준에 미달하면 잔금을 보류해도 되나?
계약서에 검수 기간, 불합격 통지 방식, 보완 기한, 최종 승인과 지급 조건이 명시되어 있어야 합니다. 분쟁 가능성이 있다면 감정적 표현 대신 체크리스트, 재현 절차, 측정 로그를 근거로 통지하는 것이 좋습니다.
정리: 외주를 납품이 아니라 통합 가능한 생산 과정으로 관리하자
외주 관리는 사람을 압박하는 일이 아니라 불확실성을 문서와 승인 단계로 줄이는 일입니다. 계약 전에는 완료 정의와 변경 규칙을 합의하고 제작 중에는 짧은 주기로 중간 승인을 받으며 납품 시에는 기능·기술·성능 체크리스트로 검수하세요. 이 세 가지가 갖춰지면 외주 아티스트와 프로그래머 모두가 예상 가능한 범위에서 작업할 수 있고 팀은 재작업 대신 게임 완성도에 시간을 쓸 수 있습니다.
