AI 기반 에셋 제작과 통합 워크플로

2026-08-27Views 7약 8분생성형 AI 활용

Summary

AI 에셋은 완성품보다 후보군에 가깝다

AI로 만든 이미지, 아이콘, 텍스처, 3D 모델, 사운드 아이디어는 제작 초기에 큰 도움이 된다. 기획 문서의 추상적인 문장을 빠르게 시각화하고, 여러 분위기를 비교하며, 임시 에셋으로 플레이 감각을 확인할 수 있다. 하지만 이 에셋을 바로 상용 프로젝트에 넣는 것은 다른 문제다.

에셋은 게임 안에 들어가는 순간 세 가지 조건을 만족해야 한다. 첫째, 프로젝트의 스타일과 맞아야 한다. 둘째, 엔진에서 성능 문제 없이 동작해야 한다. 셋째, 사용할 권리가 명확해야 한다. AI가 만든 결과물은 이 세 조건을 자동으로 보장하지 않는다.

따라서 이 장의 기본 원칙은 간단하다. AI 에셋은 빠르게 만들고, 천천히 검증한다. 초안 생성은 빠르게 하되, 통합은 폴더 구조, 이름, 메타데이터, 압축, 라이선스 확인을 거쳐 진행해야 한다.

AI 기반 에셋 제작과 통합 워크플로 AI 생성 이미지

Figma에서 에셋을 엔진용으로 정리하기

Figma는 UI 이미지와 아이콘을 엔진으로 넘기기 전에 정리하는 작업대가 될 수 있다. AI로 만든 아이콘, 상점 배너, 스킬 카드, 튜토리얼 이미지, 플레이스홀더 캐릭터 컷신을 한곳에 모아 비교하고, 크기와 스타일을 맞춘 뒤 내보낸다.

먼저 에셋을 용도별 프레임으로 나눈다.

Assets / Icons
Assets / UI_Banners
Assets / Item_Thumbnails
Assets / Placeholder_Characters
Assets / VFX_Concepts

이때 중요한 것은 예쁜 배열이 아니라 엔진에서 어떻게 쓰일지 드러나는 구조다. 예를 들어 fire-icon보다 skill_fireball_icon_default가 낫다. banner 01보다 shop_event_banner_summer_1920x640이 낫다. 이름 안에 용도, 상태, 크기 정보를 넣으면 Unity나 Unreal에서 검색하기 쉽고, AI에게 후속 작업을 요청할 때도 혼동이 줄어든다.

아이콘은 같은 캔버스 크기로 맞춘다. 64, 128, 256, 512px처럼 프로젝트 기준을 정하고, 내부 여백도 통일한다. 아이콘마다 실제 그림이 차지하는 면적이 다르면 엔진에서 버튼에 넣었을 때 어떤 것은 커 보이고 어떤 것은 작아 보인다. 배너는 적용 위치를 기준으로 크기를 정한다. 예를 들어 모바일 상점 상단 배너, PC 런처 배너, 인게임 팝업 배너는 같은 이미지처럼 보여도 필요한 비율이 다르다.

내보내기 전에는 다음 항목을 확인한다.

배경이 필요한 에셋인지, 투명 PNG가 필요한 에셋인지 구분한다.
아이콘 세트의 선 두께, 그림자, 채도, 시점이 일관적인지 본다.
텍스트가 이미지 안에 박혀 있으면 로컬라이징이 어려우므로 가능한 분리한다.
플레이스홀더는 파일명에 placeholder 또는 wip를 붙여 최종 에셋과 구분한다.
AI 생성 과정, 사용 모델, 프롬프트, 수정 날짜를 별도 표나 Figma 주석에 남긴다.

Figma AI 출력물에 대한 저작권 보호나 면책 조건은 플랜과 조직 설정에 따라 다를 수 있다. 예를 들어 Figma는 Organization 및 Enterprise 고객에게 Figma AI 출력물에 대한 저작권 보호 요청 절차를 제공하지만, 적용 범위는 팀의 계약 조건을 따로 확인해야 한다¹. 즉, Figma에서 만들었다는 사실만으로 모든 상용 사용이 자동 승인되는 것은 아니다.

Unity로 가져올 때의 기준

Unity 프로젝트에는 AI 에셋을 바로 Assets 루트에 흩뿌리지 않는다. 최소한 원본, 검수 중, 실제 사용 폴더를 분리한다.

Assets/
  Art/
    AI_Working/
      Images/
      Textures/
      Audio_Ideas/
    UI/
      Icons/
      Banners/
    Materials/
    VFX/
  Documentation/
    Asset_Provenance/

AI_Working은 실험 공간이다. 이곳에 있는 파일은 빌드에 들어가지 않는다는 규칙을 둔다. 실제 사용이 결정된 에셋만 UI, Materials, VFX 같은 목적 폴더로 옮긴다. 옮길 때는 파일명도 프로젝트 규칙에 맞춘다.

ui_icon_skill_fireball_default_v01.png
ui_banner_shop_summer_1920x640_v02.png
tex_stone_floor_tile_1024_albedo_v01.png
sfx_ui_confirm_soft_v01.wav

Unity에서 이미지 에셋을 임포트한 뒤에는 타입과 압축을 확인한다. UI 아이콘은 보통 Sprite로 설정하고, 스프라이트 시트는 Multiple로 나누어야 한다. 픽셀아트라면 Filter Mode를 Point로, 부드러운 일러스트라면 Bilinear나 Trilinear를 검토한다. 타일 텍스처는 Wrap Mode를 Repeat로, 일반 UI 이미지는 Clamp로 두는 경우가 많다. 모바일 프로젝트라면 ASTC 같은 플랫폼 압축을 고려하고, PC·콘솔은 대상 플랫폼에 맞는 압축 포맷을 별도로 본다.

AI로 만든 텍스처는 특히 반복 경계가 문제다. 바닥, 벽, 천처럼 타일링되는 이미지는 씬에 크게 깔아 보고 이음새가 보이는지 확인한다. 노멀맵이나 마스크맵을 AI가 제안했다면 실제 조명 아래에서 재질이 과하게 번들거리거나 방향이 뒤집히지 않았는지 본다.

Unity는 AI 생성 에셋도 최종 빌드에 포함되는 콘텐츠이므로 개발자가 사용 권리를 확인해야 한다고 안내한다. Unity AI로 생성된 에셋에는 추적을 위한 UnityAI 메타데이터가 붙을 수 있지만, 이 메타데이터가 법적 검토를 대신하지는 않는다². 팀은 이 정보를 검색과 검수에 활용하되, 출시 전에는 별도의 승인 절차를 거쳐야 한다.

Unreal로 가져올 때의 기준

Unreal에서도 원칙은 같다. AI 에셋은 먼저 격리하고, 검수된 것만 실제 콘텐츠 폴더로 옮긴다.

Content/
  _AI_Working/
    Images/
    Textures/
    Meshes/
    SoundIdeas/
  UI/
    Icons/
    Banners/
  Materials/
  VFX/
  Audio/
  Documentation/

Unreal은 Content Browser에서 에셋 이름이 곧 작업 언어가 된다. 접두어를 정해 두면 검색과 자동화가 쉬워진다.

T_UI_Icon_Fireball_Default_v01
T_Tile_StoneFloor_Albedo_v01
M_StoneFloor_AIPrototype_v01
MI_StoneFloor_Gameplay_v01
NS_Fireball_Impact_Prototype_v01
WBP_ItemTooltip_Prototype_v01

T_는 Texture, M_은 Material, MI_는 Material Instance, NS_는 Niagara System, WBP_는 Widget Blueprint처럼 팀의 접두어 규칙을 따른다. 중요한 것은 규칙의 종류보다 일관성이다. AI에게 "화염 스킬 임팩트에 필요한 Niagara와 머티리얼을 찾아 수정해 달라"고 요청할 때도 이런 이름 규칙이 있어야 대상이 명확해진다.

텍스처 임포트 후에는 Compression Settings, sRGB, Mip Gen Settings를 확인한다. 색상 텍스처는 보통 sRGB가 필요하지만, Roughness, Metallic, Mask 같은 데이터 텍스처는 sRGB를 끄는 경우가 많다. UI 텍스처는 선명도가 중요하고, 월드 텍스처는 거리별 밉맵과 압축 품질이 중요하다. 4K로 생성된 이미지를 그대로 쓰기보다 실제 화면 점유 크기에 맞춰 512, 1024, 2048 중 필요한 해상도를 선택한다.

Fab이나 Marketplace에서 가져온 에셋도 같은 방식으로 격리해 검토한다. 외부 팩은 프로젝트의 Content 폴더에 추가되며, 필요한 에셋만 골라 사용하는 절차가 권장된다³. AI 생성 에셋도 이와 비슷하게 다룬다. 먼저 별도 폴더에 넣고, 의존성·라이선스·성능을 확인한 뒤 프로젝트의 정식 구조로 이동한다.

3D 모델과 사운드 아이디어는 더 보수적으로 다룬다

AI 기반 3D 모델은 프로토타입에는 유용하지만, 실제 게임에 넣기 전 확인할 항목이 많다. 겉보기에는 괜찮아도 토폴로지가 지저분하거나, UV가 겹치거나, 피벗이 엉뚱한 위치에 있을 수 있다. 캐릭터라면 리깅과 애니메이션 호환성도 봐야 한다.

3D 모델 검수 기준은 다음과 같다.

폴리곤 수가 대상 플랫폼에 맞는가?
피벗 위치와 스케일 단위가 프로젝트 기준과 맞는가?
UV가 정리되어 있고 라이트맵이나 텍스처 베이킹에 문제가 없는가?
머티리얼 슬롯이 지나치게 많지 않은가?
충돌체를 자동 생성할지, 별도 제작할지 결정했는가?
LOD가 필요한 거리에서 준비되어 있는가?

사운드는 조금 다르게 접근한다. AI가 만든 사운드를 최종 음원으로 쓰기보다, 사운드 방향을 정하는 레퍼런스로 쓰는 편이 안전하다. 예를 들어 "짧고 둔탁한 금속 클릭", "부드러운 UI 확인음", "불꽃이 터진 뒤 잔향이 짧게 남는 임팩트"처럼 아이디어를 만들고, 실제 최종 사운드는 라이선스가 명확한 라이브러리나 사운드 디자이너 작업으로 대체할 수 있다.

엔진에 넣을 때는 WAV 원본과 압축본을 구분하고, 반복 재생 여부, 2D/3D 사운드 여부, 동시 재생 수를 확인한다. UI 클릭음 하나도 수십 번 반복되면 피로감을 줄 수 있다. AI가 제안한 소리가 좋은지보다 게임 안에서 반복해 들었을 때 거슬리지 않는지가 더 중요하다.

머티리얼과 VFX는 제안보다 검증이 중요하다

AI는 "푸른 불꽃", "마법 보호막", "전기 충격", "독 안개" 같은 시각 효과 아이디어를 빠르게 제안할 수 있다. 하지만 엔진의 머티리얼과 파티클 시스템에서는 성능과 가독성이 우선이다.

Unity에서는 AI가 제안한 효과를 머티리얼, Shader Graph, Particle System 또는 VFX Graph로 나누어 검토한다. 작은 스킬 임팩트라면 Particle System으로 충분할 수 있다. 화면을 가득 채우는 마법진이나 GPU 기반 대량 입자가 필요하면 VFX Graph를 검토한다. 이때 바로 복잡한 그래프를 만들지 말고, 색상·크기·수명·방향·알파 변화만 가진 기본 효과부터 만든다.

Unreal에서는 Material Graph와 Niagara를 분리해서 본다. 머티리얼은 표면이 어떻게 보이는지 담당하고, Niagara는 입자가 언제 어디서 어떻게 움직이는지 담당한다. AI가 "불꽃이 회전하며 폭발하게 만들기"라고 제안해도 실제 구현에서는 다음처럼 나누어야 한다.

Material: 불꽃 텍스처, 투명도, 색상 변화, 왜곡
Niagara: 입자 생성 수, 속도, 수명, 회전, 중력, 충돌
Gameplay: 언제 생성하고 언제 제거할지
Audio: 폭발음과 잔향 타이밍

검증은 씬 안에서 한다. 검은 배경에서 멋진 효과가 실제 전투 화면에서는 적을 가리거나 UI를 방해할 수 있다. 다음 기준을 체크한다.

중요한 적, 탄환, 목표 지점을 가리지 않는가?
저사양 타깃에서 프레임이 급격히 떨어지지 않는가?
같은 효과가 여러 번 겹쳐도 화면이 과하게 밝아지지 않는가?
색상이 팀의 속성 규칙과 맞는가? 예: 불=주황, 독=초록, 보호막=파랑.
효과가 끝난 뒤 오브젝트나 파티클이 씬에 남지 않는가?

AI에게 VFX 작업을 요청할 때는 "멋지게"라고 쓰지 않는다. 목표와 제한을 함께 준다.

목표: 플레이어 화염구가 적에게 맞을 때 0.6초 동안 보이는 임팩트 VFX를 만든다.
엔진: Unreal 5, Niagara 사용.
제약: 화면 중앙 적을 가리지 않게 반경은 150cm 이하. 모바일 타깃도 고려해 입자 수는 80개 이하.
스타일: UI 아이콘의 주황색 팔레트와 맞춘다.
검증: PIE에서 10회 연속 발동해도 로그 오류가 없고, 프레임 드롭이 눈에 띄지 않아야 한다.

이런 지시서는 AI 결과를 평가하는 기준이 된다.

상용 프로젝트용 승인 체크리스트

AI 에셋을 실제 프로젝트에 넣기 전에는 팀 내부 승인 절차가 필요하다. 특히 상용 게임, 외주 프로젝트, 스토어 제출용 빌드는 "보기 좋다"만으로 통과시켜서는 안 된다.

다음 체크리스트를 사용한다.

1. 출처와 생성 기록

사용한 AI 도구와 모델명을 기록했는가?
생성 날짜와 작성자를 남겼는가?
원본 프롬프트와 주요 수정 내역을 보관했는가?
참고 이미지나 스타일 레퍼런스의 사용 권리가 명확한가?

2. 저작권과 라이선스

해당 AI 도구의 상용 사용 조건을 확인했는가?
특정 캐릭터, 브랜드, 작가 스타일을 모방하도록 요청하지 않았는가?
학습 데이터나 출력물 관련 제한이 있는 서비스인지 확인했는가?
외부 에셋과 합성했다면 그 에셋의 라이선스도 확인했는가?
스토어나 퍼블리셔가 AI 생성 콘텐츠 표시를 요구하는지 확인했는가?

3. 스타일과 품질

기존 아트 디렉션과 색상, 명암, 선 처리, 재질감이 맞는가?
같은 세트 안에서 아이콘 크기와 여백이 일관적인가?
해상도별로 깨짐이나 뭉개짐이 없는가?
텍스트가 이미지에 박혀 있어 번역을 방해하지 않는가?

4. 엔진 최적화

실제 사용 크기에 맞는 해상도로 줄였는가?
Unity 또는 Unreal의 압축 설정을 플랫폼별로 확인했는가?
불필요한 알파 채널이나 대형 텍스처가 남아 있지 않은가?
3D 모델의 폴리곤 수, LOD, 충돌체, 머티리얼 슬롯을 확인했는가?
VFX가 반복 실행될 때 프레임과 메모리에 문제가 없는가?

5. 팀 승인

아트 담당자가 스타일을 승인했는가?
테크 아티스트나 개발자가 성능을 확인했는가?
기획자가 게임 정보 전달에 문제가 없다고 확인했는가?
법무 또는 퍼블리싱 담당자가 사용 조건을 확인했는가?
최종 에셋과 플레이스홀더가 명확히 구분되어 있는가?

통합 워크플로는 기록을 남길 때 완성된다

AI 에셋 워크플로의 핵심은 생성 속도가 아니라 추적 가능성이다. 어떤 도구로 만들었고, 누가 수정했으며, 왜 채택했는지 남아 있어야 한다. 그래야 나중에 문제가 생겼을 때 교체할 수 있고, 비슷한 스타일의 에셋을 다시 만들 수 있으며, 출시 전 검수도 빠르게 진행된다.

정리하면 흐름은 다음과 같다.

AI 생성 → Figma 정리 → 출처 기록 → 엔진 격리 임포트 → 품질·성능 검증 → 라이선스 확인 → 정식 폴더 이동 → 빌드 포함

AI는 초안을 빠르게 만든다. Figma는 비교와 정리를 돕는다. Unity와 Unreal은 실제 동작과 성능을 검증한다. 사람은 스타일, 권리, 품질, 출시 책임을 판단한다. 이 역할 분담이 지켜질 때 AI 에셋은 위험한 임시 이미지가 아니라 제작 속도를 높이는 실무 자산이 된다.

참고

¹Request AI copyright protection for your organization

²Using AI-generated assets responsibly - Unity Learn

³Importing from Fab (Unreal Engine Marketplace)

책 목록

Figma AI와 Unity·Unreal AI 워크플로

전체 목차 보기