AI 에셋 생성 파이프라인 협업 갈등 조율법: 아티스트와 개발자가 함께 만드는 기준
AI 에셋 생성 파이프라인의 산출물 계약, 아트·기술 검수, 승인 권한과 우선순위 운영안을 정리합니다. 반복 수정과 일정 충돌을 기록하고 조율하는 기준을 제안합니다.
AI 에셋 생성 파이프라인에서 갈등이 생기면 산출물의 정의와 승인 권한부터 확인하자. 이 글에서는 프롬프트, 원본 파일, 게임 적용용 최종 에셋을 구분하고 각 단계의 품질 기준·담당자·완료 조건을 문서로 합의하는 운영안을 제시한다.
AI 에셋 생성 파이프라인에서 갈등은 왜 발생하는가?
이미지를 생성한 뒤에도 게임의 파일 규격과 품질 기준을 검수해야 한다. 아래 표는 협업 중 생길 수 있는 기대 차이의 예시이며, 모든 아티스트와 개발자의 관점을 조사한 결과는 아니다. 팀의 실제 담당자와 승인 기준에 맞춰 항목을 바꾼다.
| 자주 쓰는 표현 | 아티스트가 기대하는 결과 | 개발자가 기대하는 결과 | 합의해야 할 조건 |
|---|---|---|---|
| 시안이 나왔다 | 아트 디렉션을 판단할 이미지 | 바로 구현 가능한 리소스 | 시안과 납품본을 구분한다 |
| AI로 생성했다 | 편집 가능한 작업 출발점 | 출처와 재생성 경로가 있는 파일 | 모델, 프롬프트, 시드, 후편집 기록 |
| 완료됐다 | 시각 품질 검수가 끝난 상태 | 빌드에 포함되고 오류가 없는 상태 | 아트 승인과 기술 승인을 모두 명시한다 |
| 수정이 적다 | 스타일 훼손이 없다 | 코드와 데이터 변경이 작다 | 수정 비용을 유형별로 기록한다 |
AI 생성 결과를 재현하려면 프롬프트 외에도 모델 버전, 시드(seed), 참조 이미지, ControlNet 또는 LoRA 적용 여부를 기록해야 한다. 이 조건을 같게 맞춰도 실행 환경이나 라이브러리가 달라지면 동일한 결과가 보장되지 않는다. Diffusers 재현성 문서에서 설명하는 제약을 확인하고, ‘이 느낌으로 다시 뽑아 주세요’라는 요청에는 기준 이미지와 수정할 요소를 함께 적는다.
아티스트와 개발자의 협업 기준을 어떻게 문서화할까?
에셋 유형별로 한 페이지짜리 산출물 계약(Asset Contract)을 출발점으로 삼는다. 팀이 무엇을 받으면 완료로 인정하는지 적고, 필요한 명세를 연결한다.
1. 에셋을 시안·원본·납품본으로 분리한다
AI 결과 PNG 한 장에 모든 책임을 얹지 않는다.
- 시안(Concept): 분위기와 구도를 판단한다. 게임에 바로 넣지 않는다.
- 원본(Source): 레이어 파일, 마스크, 생성 설정, 참조 이미지 사용 여부를 포함한다.
- 납품본(Runtime Asset): Unity 또는 Unreal Engine에서 사용할 크기, 포맷, 피벗, 아틀라스 규칙을 만족한다.
예를 들어 2D 캐릭터 초상화라면 납품 조건을 아래처럼 적을 수 있다.
asset_id: portrait_npc_merchant_01
engine: Unity 2022.3 LTS
source_format: PNG
runtime_texture_format: RGBA32
canvas_px: 1024x1024
pivot: center
alpha: required
max_file_size_kb: 512
source_required:
- layered_psd
- generation_prompt
- model_name_and_version
- seed_if_available
art_approver: art_lead
tech_approver: client_programmer이 문서에는 아틀라스 등 기술 제약과 납품 조건을 미리 공유한다. 합의된 문서만으로 임포트 성공을 보장할 수는 없으므로 기준 에셋을 실제 프로젝트에 넣어 확인한다.
2. 품질 기준을 주관적 평가와 객관적 검수로 나눈다
이 운영안에서는 시각 품질과 런타임 적용 가능성을 별도로 승인한다. 승인 항목을 두 갈래로 나눈다.
- 아트 검수: 캐릭터 비율, 세계관 적합성, 색상 팔레트, 손가락·문자·장신구 같은 AI 아티팩트
- 기술 검수: 해상도, 투명도, 파일 크기, 네이밍, 임포트 설정, 메모리 예산, 라이선스 기록
비압축 텍스처의 최상위 밉 레벨에 필요한 픽셀 데이터 크기는 다음 식으로 계산할 수 있다. 전체 런타임 메모리의 상한은 아니며 밉맵, CPU 복사본, 정렬 및 부가 버퍼는 별도로 계산한다. PNG 파일의 디스크 용량과도 다르다.
RGBA32 텍스처는 픽셀당 4바이트다. 2048×2048 최상위 밉의 데이터는 정확히 16 MiB이며, 1×1까지 포함한 전체 밉 체인은 약 21.33 MiB다. CPU 복사본이나 GPU 압축 여부도 확인한 뒤 메모리 예산에 맞춰 기술 승인한다.
3. 승인권자를 단계마다 한 명씩 정한다
여러 사람이 의견을 낼 수는 있어도 한 단계의 최종 승인자는 한 명이어야 한다. 아트 디렉션은 아트 리드, 런타임 적용 가능성은 담당 개발자가 승인하는 식으로 역할을 분리한다. 프로듀서나 PM은 취향을 대신 판정하기보다 승인 지연과 의사결정 누락을 관리한다.
flowchart LR
A[요청 카드] --> B[아트 시안 생성]
B --> C{아트 승인}
C -- 수정 --> B
C -- 승인 --> D[원본 정리·후편집]
D --> E[런타임 납품본 생성]
E --> F{기술 승인}
F -- 규격 수정 --> E
F -- 승인 --> G[빌드 반영]이 흐름에서 중요한 점은 기술 검수가 시안을 부정하는 자리가 아니라는 것이다. 구도와 스타일이 승인된 뒤 기술 검수는 이미 합의된 목표를 게임 규격에 맞게 전달하는 단계가 된다.
일정 충돌을 줄이는 AI 에셋 우선순위 운영법
AI 에셋 작업은 생성 시간이 짧아 보여도 검토, 후편집, 게임 적용, 재검수가 누적된다. 따라서 ‘생성 가능한 것’이 아니라 ‘이번 스프린트에서 플레이 경험을 검증할 수 있는 것’을 먼저 만든다.
요청 카드를 세 가지로 분류한다
| 분류 | 목적 | 일정 원칙 | 예시 |
|---|---|---|---|
| 플레이 검증용 | 재미와 가독성 검증 | 가장 먼저, 임시 에셋 허용 | 적 공격 텔레그래프 |
| 제작 기준용 | 이후 작업의 기준 확정 | 소수만 고품질로 제작 | 주인공, UI 아이콘 스타일 |
| 출시 품질용 | 최종 빌드 품질 확보 | 콘텐츠 잠금 이후 집중 | NPC 초상화 변주 |
게임플레이 변경이 이미 만든 에셋의 규격이나 내용에 영향을 주면 재작업이 필요하다. 플레이 검증용 에셋은 검증 목적에 따라 단색 도형이나 기존 에셋으로 대체할 수 있다. AI 생성이 가능하다는 이유만으로 첫 스프린트에 넣을 필요는 없다.
갈등이 생겼을 때는 어떻게 조율할까?
갈등을 취향 토론으로 끌고 가지 말고 요청을 검증 가능한 선택지로 바꾼다.
- 충돌을 한 문장으로 기록한다. 예: ‘상점 NPC 초상화의 화풍 수정 때문에 UI 구현이 이틀 지연된다.’
- 결정 기준을 붙인다. 예: 튜토리얼 완료율에 영향을 주는가, 출시 전 반드시 필요한가, 기존 시안으로 기능 검증이 가능한가를 확인한다.
- 되돌릴 수 있는 결정을 먼저 한다. 기능 검증은 현재 시안으로 진행하고 화풍 수정은 다음 마일스톤의 기준 에셋 1개에만 적용할 수 있다.
이 방식은 아티스트에게 ‘품질을 포기하라’고 말하지 않고 개발자에게 ‘일정을 무시하라’고도 말하지 않는다. 대신 지금 확정해야 하는 범위와 나중에 바꿔도 되는 범위를 분리한다.
회의에서 바로 쓸 수 있는 결정 기록 템플릿
- 결정: 상점 NPC 초상화는 현재 시안으로 기능 구현을 진행한다.
- 이유: 대화 UI의 가독성 검증이 이번 스프린트 목표다.
- 보류: 화풍 수정은 기준 초상화 1종을 먼저 승인한 뒤 나머지 12종에 적용한다.
- 담당: 아트 리드 / 클라이언트 프로그래머
- 재검토일: 다음 스프린트 계획 회의결정 기록에는 결정, 이유, 보류 범위, 담당자, 재검토일을 남긴다. 논의의 근거가 필요하면 원본 자료를 연결하고, 재논의가 발생한 이유와 걸린 시간을 기록해 운영 효과를 확인한다.
자주 묻는 질문 (FAQ)
AI 프롬프트를 모두 문서화해야 하나요?
이 운영안에서는 최종 후보와 기준 에셋에 모델명, 버전, 프롬프트, 시드, 참조 이미지 사용 여부를 우선 기록한다. 탐색 단계 기록의 보관 범위는 팀의 재현·검수 목적과 도구·데이터 제공자의 조건에 맞춰 정한다.
아티스트 승인과 개발자 승인이 충돌하면 누가 결정하나요?
각 승인자가 자기 영역을 결정한다. 화풍과 품질은 아트 리드가, 런타임 규격과 구현 위험은 개발자가 결정한다. 일정·스코프 충돌은 두 결정을 바꾸지 않고 어떤 에셋을 이번 범위에 넣을지 PM 또는 프로젝트 책임자가 정한다.
AI 생성 에셋에도 기존 아트 파이프라인이 필요한가요?
필요하다. AI는 생성 도구일 뿐이고 네이밍, 버전 관리, 임포트 설정, 저작권 기록, 빌드 검수는 여전히 게임 제작 파이프라인의 책임이다.
정리
이 글의 운영안은 시안·원본·납품본을 구분하고 아트 승인과 기술 승인을 분리하며 플레이 검증에 필요한 에셋부터 우선순위를 정하는 것이다. 산출물 계약을 적용한 뒤에도 반복 수정 횟수와 승인 대기 시간, 일정 충돌의 원인을 기록해 팀에 맞는지 확인한다.
