AI 에셋 생성 워크플로우: 기획부터 3D·코드 적용까지

AI 에셋 생성은 프롬프트를 잘 쓰는 일만으로 끝나지 않습니다. 게임에 들어갈 결과물은 기획 의도, 기술 제약, 라이선스, 성능 예산을 함께 만족해야 합니다. 이 글에서는 콘셉트 이미지부터 3D 모델과 코드 보조 생성까지를 하나의 검수 가능한 파이프라인으로 연결합니다.

먼저 정할 것: 생성물이 아니라 사용 조건

에셋 제작을 시작하기 전에 ‘무엇을 만들지’와 함께 ‘어디에 어떻게 쓸지’를 문서화합니다. 이 단계가 빠지면 보기 좋은 시안은 쌓여도 실제 프로젝트에 적용하려면 추가 조정이 필요할 수 있습니다.

작은 에셋 명세에는 다음 항목이면 충분합니다.

용도: 플레이어 캐릭터, 배경 소품, UI 아이콘처럼 실제 사용 위치
시점과 스타일: 탑다운, 3인칭, 사실적, 셀 셰이딩 등
기술 조건: 목표 플랫폼, 최대 폴리곤 수, 텍스처 해상도, 머티리얼 수
상호작용: 충돌체, 애니메이션, 파괴 여부, 네트워크 동기화 필요성
권리 조건: 생성 도구의 상업 이용 약관, 입력 레퍼런스의 사용 범위, 팀 내부 승인 기준

특히 생성 도구의 출력물 권리는 도구마다 약관과 플랜에 따라 달라질 수 있습니다. 출시용 에셋에는 사용한 도구, 날짜, 프롬프트, 레퍼런스 출처와 검수 결과를 함께 기록해 두는 편이 안전합니다.

파이프라인을 짧은 피드백 고리로 만들기

생성 결과를 곧바로 게임에 넣기보다 각 단계에서 다음 단계에 필요한 정보를 남기는 구조가 좋습니다. 콘셉트는 스타일 기준을 만들고 3D 모델은 엔진 성능과 충돌을 검증하며 코드는 반복 작업을 줄이는 보조 수단으로 둡니다.

flowchart LR
    A[에셋 명세] --> B[레퍼런스와 스타일 가이드]
    B --> C[AI 콘셉트 시안]
    C --> D[선정 및 수정 지시]
    D --> E[3D 제작 또는 생성]
    E --> F[정리: 토폴로지·UV·텍스처]
    F --> G[엔진 임포트]
    G --> H[성능·표현·권리 검수]
    H -->|수정 필요| D
    H -->|승인| I[에셋 등록]

여기서 중요한 것은 AI가 만든 파일을 원본으로 취급하지 않는 것입니다. 프로젝트에 들어가는 최종 산출물은 메시 구조, UV, 텍스처 경로, 머티리얼, 임포트 설정이 정리된 버전이어야 합니다.

1. 콘셉트 생성: 프롬프트를 사양서처럼 작성하기

콘셉트 생성 도구에는 장면을 묘사하는 문장만 넣지 말고 게임에서 필요한 판별 정보를 포함합니다. 예를 들어 아이템 아이콘이라면 배경, 실루엣, 카메라 각도, 금지 요소가 결과 품질에 직접 영향을 줍니다.

모바일 판타지 RPG의 회복 물약 아이콘.
정면에서 약간 위를 내려다보는 3/4 시점.
짙은 남색 단색 배경, 중앙에 하나의 작은 유리병.
붉은 액체와 금색 마개, 두꺼운 외곽선, 높은 명암 대비.
텍스트와 로고, 손, 복잡한 배경은 제외.
1024x1024, 읽기 쉬운 단순한 실루엣.

프롬프트에는 다음처럼 재사용 가능한 필드를 두면 팀 작업이 편해집니다.

asset_id: consumable_health_potion_01
purpose: inventory_icon
camera: three_quarter_front
style: bold_outline_stylized
palette: navy_red_gold
must_have:
  - single_bottle
  - readable_silhouette
must_not_have:
  - text
  - logo
  - hands

시안을 고를 때는 ‘가장 멋진 이미지’ 대신 게임 화면에서 식별되는 이미지를 선택합니다. 실제 UI 크기로 축소해 보고 밝은 배경과 어두운 배경에서 모두 확인해야 합니다.

인벤토리 슬롯 크기로 축소한 물약 아이콘 시안 비교

2. 3D 에셋: 생성 후 정리 작업을 별도 단계로 둔다

이미지 기반 또는 텍스트 기반 3D 생성은 블록아웃과 소품 초안에 활용할 수 있습니다. 생성된 메시에는 불균일한 토폴로지, 중복된 면, 비정상적인 노멀, 불필요하게 많은 머티리얼이 있을 수 있으므로 확인이 필요합니다. 생성 직후에는 다음 정리 과정을 거칩니다.

메시와 텍스처 체크리스트

스케일과 축 방향을 프로젝트 규칙에 맞춘다.
겹친 정점과 뒤집힌 노멀을 정리한다.
실루엣에 영향이 적은 면부터 줄여 LOD를 만든다.
UV가 겹치거나 지나치게 잘게 분할되지 않았는지 확인한다.
PBR 텍스처의 채널과 색 공간을 확인한다.
머티리얼 수를 줄이고 텍스처 아틀라스 사용 가능성을 검토한다.
필요한 충돌체와 피벗 위치를 설정한다.

예산은 장르와 플랫폼에 따라 달라지므로 절대적인 숫자를 외우기보다 장면 전체 예산에서 역산합니다. 예를 들어 한 화면에 동시에 보이는 소품 수를 기준으로 대략적인 삼각형 수를 추정할 수 있습니다.

T_{scene}=N_{visible}\times T_{asset}

여기서 $N_{visible}$ 은 동시에 보이는 에셋 수이고 $T_{asset}$ 은 화면에 보이는 에셋의 평균 삼각형 수입니다. 실제 성능은 드로우 콜, 셰이더 복잡도, 오버드로우, 조명 방식에도 영향을 받으므로 이 계산은 출발점으로만 사용합니다.

3D 생성 원본과 게임용으로 정리한 메시 및 UV 비교

3. Unity와 Unreal에 적용할 때 확인할 점

엔진 임포트는 파일을 넣는 작업을 넘어 런타임 비용에 영향을 줄 수 있는 단계입니다.

Unity

Unity에서는 FBX를 기본 임포터로 가져오고 FBX 임포터의 Model 탭에서 스케일, 노멀, 리그, 애니메이션 분할을 확인합니다. glTF를 사용한다면 프로젝트에 별도 임포터 패키지를 추가한 뒤 해당 패키지의 설정을 확인합니다. 텍스처는 용도에 맞는 타입으로 지정하고 노멀 맵은 Normal map으로 설정합니다. 반복 사용되는 소품이라면 프리팹으로 만들고 콜라이더와 LOD Group을 함께 구성합니다.

에셋에 최소한의 검증용 컴포넌트를 붙이면 누락을 빨리 찾을 수 있습니다.

using UnityEngine;

[RequireComponent(typeof(Renderer))]
public class AssetSanityCheck : MonoBehaviour
{
    [SerializeField] private int maxMaterialCount = 2;

    private void Awake()
    {
        var renderer = GetComponent<Renderer>();

        if (renderer.sharedMaterials.Length > maxMaterialCount)
        {
            Debug.LogWarning(
                $"{name}: 머티리얼 수가 예산을 초과했습니다. " +
                $"현재 {renderer.sharedMaterials.Length}, 제한 {maxMaterialCount}",
                this);
        }
    }
}

이 코드는 성능 측정 도구를 대신하지 않습니다. 다만 프리팹을 열지 않아도 단순한 규칙 위반을 발견하는 안전망으로 쓸 수 있습니다.

Unreal Engine

Unreal Engine에서는 메시 임포트 시 단위와 축을 먼저 확인합니다. Static Mesh Editor에서 LOD, UV 채널, 라이트맵 UV, 충돌 설정을 살펴보고 필요하면 단순 충돌을 별도로 생성합니다. Nanite는 고밀도 정적 메시에서 선택지가 될 수 있지만 모든 메시와 플랫폼에 자동으로 적합한 것은 아닙니다. 대상 플랫폼, 머티리얼, 그림자와 스트리밍 조건을 프로파일링으로 확인해야 합니다.

머티리얼 인스턴스를 활용하면 같은 셰이더를 유지하면서 색상이나 거칠기 같은 값만 바꿀 수 있습니다. AI가 만든 변형 소품을 여러 개 쓸 때는 각 소품마다 새 머티리얼을 만들기보다 인스턴스화 가능한 공통 머티리얼을 먼저 설계하는 편이 관리하기 쉽습니다.

4. 코드 생성 AI는 ‘작은 도구’부터 맡긴다

코드 생성 도구를 반복적인 에디터 도구, 데이터 변환, 검증 스크립트의 초안을 만드는 데 활용할 수 있습니다. 게임 규칙의 핵심 로직, 권한 처리, 네트워크 동기화처럼 오류 비용이 큰 영역에서는 요구 사항과 테스트를 사람이 명확히 작성한 뒤 제한적으로 사용하는 편이 안전합니다.

좋은 요청에는 실행 환경과 검증 기준이 들어갑니다.

Unity 6 프로젝트에서 실행할 EditorWindow 예제를 작성해 줘.
선택한 프리팹 아래의 Renderer를 순회해 sharedMaterials 개수를 출력해야 해.
에셋 파일을 수정하지 말고 null 머티리얼을 안전하게 처리해.
메뉴 경로와 필요한 using 문을 포함해.

받은 코드는 바로 병합하지 말고 다음 순서로 확인합니다.

프로젝트의 엔진 버전과 API가 맞는지 확인한다.
빈 입력, null, 중첩 프리팹 등 실패 경로를 테스트한다.
파일 수정이나 대량 변경이 있는지 읽어 본다.
작은 샘플 프로젝트나 별도 브랜치에서 실행한다.
팀의 코딩 규칙과 라이선스 정책에 맞게 정리한다.

5. 승인 기준을 자동화 가능한 규칙으로 바꾸기

AI 에셋의 품질 검수는 감각적인 평가와 기술적인 평가를 분리하면 기준을 정하고 누락 원인을 파악하기 쉽습니다. 아트 리뷰에서는 스타일, 실루엣, 레벨 맥락을 보고 기술 리뷰에서는 폴리곤, 텍스처, 머티리얼, 콜라이더, 파일 크기를 봅니다.

자동화하기 좋은 규칙은 다음과 같습니다.

파일 이름이 프로젝트 명명 규칙을 따른다.
텍스처 해상도가 허용 범위 안에 있다.
머티리얼 수와 메시 수가 에셋 유형의 예산 안에 있다.
피벗과 스케일이 규칙에 맞는다.
필수 콜라이더 또는 LOD가 존재한다.
출처와 사용 권한 정보가 에셋 메타데이터에 기록되어 있다.

반대로 캐릭터의 매력, 배경과의 조화, 플레이 중 식별성은 자동 검사만으로 판단하기 어렵습니다. 실제 카메라 거리와 조명에서 플레이 테스트하는 검수가 필요합니다.

마무리

AI를 에셋 제작의 일부에 활용할 수 있지만 게임에 적용 가능한 자산으로 바꾸는 책임까지 대신하지는 않습니다. 에셋 명세를 먼저 만들고 생성 결과를 정리하며 엔진 안에서 성능과 표현을 검증하는 흐름을 정해 두면 도구가 바뀌어도 같은 검수 기준을 적용하는 데 도움이 됩니다.

처음에는 UI 아이콘이나 배경 소품처럼 범위가 작은 에셋 하나를 골라 이 과정을 끝까지 반복해 보세요. 그 결과로 나온 프롬프트 템플릿, 임포트 프리셋, 검수 체크리스트는 다음 에셋 제작에서 시행착오와 반복 작업을 줄이는 데 도움이 됩니다.