Cocos Creator AI 아트 에셋 정리 실전: 생성부터 가져오기까지 전체 워크플로

머릿속에는 멋진 캐릭터, 씬, 아이템이 끝없이 떠오르지만, 실제 예산과 시간으로는 캐릭터 러프 하나 겨우 그릴 수 있는 상황이 많습니다. 아트 에셋은 아이디어와 완성작 사이에 놓인 큰 간격이고, 많은 게임 아이디어가 문서 안에만 남는 이유이기도 합니다.

기존 방식에서는 2D 캐릭터 하나를 디자인해서 실제로 쓸 수 있는 상태로 만들기까지 수십만 원 이상의 비용과 몇 주 단위의 시간이 필요했습니다. 이제 AI 도구를 쓰면 캐릭터 생성, 리깅, 스키닝, 모션 제작을 10분 안에 처리하고 비용도 기존의 10분의 1 수준으로 낮출 수 있습니다. 문제는 그다음입니다. AI가 만든 소재를 어떻게 Cocos Creator에서 쓸 수 있는 리소스로 바꿀까요? 가져온 뒤 디렉터리가 뒤죽박죽이 되고, 유지보수가 어려워지고, Draw Call이 높아져 게임이 버벅이는 문제를 저도 한 번씩 겪었습니다.

이 글에서는 AI로 아트 에셋을 생성하는 단계부터 Cocos Creator 리소스 디렉터리의 표준 구조, 네이밍 규칙, 아틀라스 제작, 성능 튜닝까지 차례대로 정리합니다. 끝까지 따라가면 개념에서 엔진에서 바로 쓸 수 있는 리소스까지 이어지는 경로가 생각보다 분명하다는 것을 알 수 있습니다.

Cocos Creator 리소스 디렉터리 구조 기본

Cocos Creator 프로젝트를 열면 assets, library, local, settings, temp 같은 여러 폴더가 보입니다. 이 중에서 실제 “리소스 저장소”는 어디일까요?

답은 하나입니다. assets입니다.

assets 디렉터리는 에디터의 에셋 매니저에 표시되는 유일한 디렉터리입니다. 이미지, 애니메이션, 프리팹, 스크립트는 모두 여기에 둡니다. 나머지 폴더 중 library는 캐시, local은 로컬 설정, settings는 프로젝트 설정, temp는 임시 파일입니다. 평소에는 건드릴 필요도 없고, 섣불리 삭제하지 않는 편이 좋습니다.

meta 파일: 각 리소스의 “신분증”

assets 디렉터리에는 처음 보면 꽤 거슬리는 파일이 있습니다. 모든 파일 옆에 .meta 파일이 따라붙습니다. 예를 들어 knight.png가 있으면 옆에는 반드시 knight.png.meta가 있습니다.

이 meta 파일은 Cocos Creator가 리소스를 관리하는 핵심 메커니즘입니다. 리소스의 uuid, 즉 고유 식별자와 버전 정보, 하위 리소스 정보를 기록합니다. meta 파일을 삭제하면 엔진은 해당 리소스를 찾지 못합니다. 리소스 파일의 이름을 바꾸거나 이동할 때도 meta 파일이 함께 처리되어야 합니다. 그렇지 않으면 참조가 전부 끊깁니다.

처음 프로젝트를 만들었을 때 저는 meta 파일이 너무 지저분해 보여서 한 번에 다 지운 적이 있습니다. 결과는 명확했습니다. 프로젝트 전체가 망가졌고, 모든 리소스 참조가 “Missing”으로 바뀌었습니다. 꽤 뼈아픈 교훈이었습니다.

resources 디렉터리: 동적 로딩을 위한 특수 통로

assets 아래에는 특수한 하위 디렉터리인 resources가 있습니다. 여기에 들어간 리소스는 코드로 동적 로딩할 수 있습니다.

resources.load('sprite-frames/background', cc.SpriteFrame, (err, spriteFrame) => {
    // 동적으로 로드한 SpriteFrame
});

다만 resources 디렉터리에는 함정이 있습니다. 빌드할 때 이 디렉터리 아래의 모든 리소스가 실제 사용 여부와 관계없이 패키징됩니다. 그래서 모든 것을 resources에 넣으면 안 됩니다. 다국어 전환용 텍스트나 플레이어 진행도에 따라 잠금 해제되는 씬처럼 정말 동적으로 로딩해야 하는 리소스만 넣는 것이 좋습니다.

피해야 할 흔한 실수

자주 나오는 실수는 몇 가지로 정리됩니다.

• project.json 파일을 직접 수정합니다. 이 파일은 에디터가 자동으로 관리하므로 직접 바꾸면 문제가 생길 수 있습니다.
• library 폴더를 삭제합니다. 삭제한 뒤 프로젝트를 다시 열면 재생성되지만 시간이 오래 걸립니다. 큰 프로젝트라면 몇 분을 기다려야 할 수도 있습니다.
• 모든 리소스를 resources에 밀어 넣습니다. 빌드 크기가 커지고 로딩 시간이 길어집니다.
• meta 파일 동기화를 무시합니다. 참조가 끊기고 프리팹 안의 이미지가 전부 Missing으로 바뀝니다.

AI 아트 에셋 생성에 쓸 수 있는 실전 도구

요즘 AI 아트 도구는 정말 많습니다. 그중 무엇을 골라야 할까요? 실제로 써본 기준으로 인디 개발자에게 맞는 세 가지 선택지를 추천합니다.

SOON 플랫폼: 스켈레톤 애니메이션 원클릭 생성

SOON은 게임 캐릭터 애니메이션에 특화된 AI 플랫폼입니다. “갑옷을 입은 카툰 기사, 검을 든 전투 자세”처럼 한 문장으로 설명을 입력하면 캐릭터 생성, 리깅, 스키닝, 모션 제작을 자동으로 처리하고 Spine 형식의 스켈레톤 애니메이션으로 내보낼 수 있습니다.

기존 방식에서는 캐릭터 디자인, 리깅, 스키닝, 모션 디자인 각각에 전문 인력이 필요했고, 전체 기간도 몇 주 단위로 잡아야 했습니다. SOON은 이 기간을 10분까지 줄입니다. Sina.com 보도에 따르면 비용도 기존 프로세스 대비 80%-90% 낮출 수 있습니다.

저는 SOON으로 횡스크롤 액션 게임의 주인공을 만든 적이 있습니다. 10분 뒤 대기, 걷기, 달리기, 점프, 공격, 피격, 사망 등 36종의 모션 애니메이션이 바로 내보내졌습니다. 각 동작도 꽤 자연스러웠습니다. 아티스트에게 맡겼다면 견적서를 받는 순간 마음이 먼저 식었을 가능성이 큽니다.

Holopix AI: 게임 맞춤형 AI 그림 생성과 스마트 누끼

Holopix AI는 게임 개발을 위해 설계된 AI 그림 도구입니다. 특히 쓸모 있는 기능은 두 가지입니다. 원클릭 초안 생성과 원클릭 누끼입니다.

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

원클릭 초안 생성은 캐릭터 설명을 입력하면 여러 스타일 후보를 만들어 줍니다. 서구풍, 애니메이션풍, 픽셀 스타일처럼 게임에 자주 쓰이는 방향별 모델이 따로 훈련되어 있어 범용 AI 도구보다 게임 요구에 잘 맞습니다.

원클릭 누끼도 중요합니다. 생성된 캐릭터 이미지에는 보통 배경이 포함되지만, 게임 안에서는 투명 배경의 스프라이트가 필요합니다. Holopix AI의 누끼 기능은 한 번에 배경을 제거하고 가장자리도 깔끔하게 처리합니다. 아트 작업에 익숙하지 않은 프로그래머에게는 꽤 큰 도움이 됩니다.

Anything XL: 로컬 배포형 SDXL

Anything XL은 로컬에 배포해서 쓰는 Stable Diffusion XL 도구입니다. 장점은 분명합니다. 아이디어가 외부로 나갈 위험이 낮고, 사용 횟수 제한도 없습니다.

프로젝트에 보안 요구가 있거나 아트 콘셉트를 클라우드 플랫폼에 올리고 싶지 않다면 Anything XL이 좋은 선택입니다. 배포 과정은 조금 번거롭고 GPU도 필요하지만, 한 번 구성해 두면 생성 속도가 안정적이고 소재 품질을 직접 통제할 수 있습니다.

도구 비교와 선택 기준

저의 선택 기준은 단순합니다. 캐릭터 애니메이션은 SOON, 정적 스프라이트는 Holopix AI, 보안이 필요한 소재는 Anything XL을 씁니다. 세 도구를 조합하면 대부분의 아트 요구를 커버할 수 있습니다.

AI 생성 결과를 Cocos로 가져오는 전체 흐름

AI로 만든 소재가 생겼다면 다음 단계는 엔진에서 쓸 수 있는 리소스로 바꾸는 일입니다. 이 단계에서 문제가 가장 많이 생기므로 하나씩 나눠 보겠습니다.

형식 변환과 배경 제거

AI가 생성한 이미지는 보통 배경을 포함합니다. 게임에서는 투명 배경의 스프라이트가 필요하므로 첫 단계는 배경 제거입니다.

사용할 수 있는 배경 제거 도구는 다음과 같습니다.

• Transparify: 웹 기반 도구입니다. 이미지를 업로드하면 한 번에 배경을 제거하고 가장자리도 깔끔하게 처리합니다.
• SpriteCut AI: 게임 스프라이트에 특화되어 있습니다. 캐릭터 외곽선을 인식하고 불필요한 빈 공간을 자동으로 잘라냅니다.
• Holopix AI 내장 누끼: 생성 단계에서 투명 배경 옵션을 선택하면 한 번에 처리됩니다.

처리가 끝나면 Alpha 채널이 포함된 PNG 형식으로 내보냈는지 확인하세요. JPG는 투명을 지원하지 않으므로 쓰면 안 됩니다.

아틀라스 제작 실전

개별 스프라이트 이미지를 그대로 가져오면 스프라이트 하나마다 Draw Call이 한 번 발생합니다. 스프라이트가 10개면 Draw Call 10번, 100개면 100번입니다. 저사양 기기에서는 버벅임이 눈에 보일 정도로 나타납니다.

해결책은 아틀라스입니다. 여러 스프라이트를 하나의 큰 이미지로 패킹하면 엔진은 이 아틀라스를 참조하는 모든 스프라이트를 한 번의 Draw Call로 렌더링할 수 있습니다.

TexturePacker 설정 핵심:

1. TexturePacker를 열고 스프라이트 이미지 파일을 추가합니다.
2. Output 형식은 cocos2d-x를 선택하고 plist+png 파일로 내보냅니다.
3. Trim Mode는 trim을 선택합니다. 투명 픽셀은 잘라내지만 원본 이미지 프레임은 바꾸지 않습니다. crop이나 flush position은 애니메이션 위치가 어긋날 수 있으므로 선택하지 않습니다.
4. Max Size는 목표 기기에 맞게 조정합니다. 보통 2048x2048이면 충분합니다.

Cocos Creator 3.0은 TexturePacker v4.x 미만의 형식을 지원하지 않습니다. 오래된 TexturePacker를 쓰고 있다면 최신 버전으로 올리는 편이 좋습니다.

Cocos Creator로 가져오는 단계

TexturePacker는 .plist와 .png 두 파일을 내보냅니다. 이 두 파일은 함께 Cocos Creator로 가져와야 합니다.

가져오는 방법은 간단합니다. 두 파일을 assets 디렉터리로 그대로 드래그합니다. 드래그한 뒤 에셋 매니저에 Atlas 리소스가 나타나고, 펼쳐 보면 모든 SpriteFrame을 확인할 수 있습니다.

각 SpriteFrame은 개별적으로 사용할 수 있습니다. Sprite 컴포넌트의 SpriteFrame 속성에서 원하는 프레임을 선택하면 해당 스프라이트가 표시됩니다.

전체 사례: 2D 횡스크롤 액션 게임 캐릭터 가져오기

SOON으로 기사 캐릭터를 만들고 36종의 모션 애니메이션을 생성했다고 가정해 보겠습니다. 전체 가져오기 흐름은 다음과 같습니다.

Step 1: AI 생성

• SOON 플랫폼에 “갑옷을 입은 카툰 기사”를 입력합니다.
• 대기, 걷기, 공격, 점프 같은 동작 유형을 선택합니다.
• PNG 시퀀스 프레임을 내보냅니다. 각 동작은 여러 프레임으로 구성됩니다.

Step 2: 배경 제거

• PNG 시퀀스 프레임을 Transparify로 가져옵니다.
• 한 번에 배경을 제거하고 투명 PNG로 내보냅니다.

Step 3: 아틀라스 패킹

• TexturePacker에 모든 PNG 프레임을 추가합니다.
• Output 형식은 cocos2d-x로 선택합니다.
• knight_atlas.plist와 knight_atlas.png를 내보냅니다.

Step 4: 엔진으로 가져오기

• plist와 png를 assets/characters/hero/sprites/로 드래그합니다.
• meta 파일이 자동 생성될 때까지 기다립니다.

Step 5: 씬에서 사용

• Sprite 노드를 만듭니다.
• SpriteFrame 속성에서 knight_atlas 안의 해당 프레임을 선택합니다.
• Animation 컴포넌트로 프레임 애니메이션을 재생하고 동작을 전환합니다.

이 흐름을 끝내면 기사 캐릭터가 게임 안에서 움직일 수 있습니다. 36종의 동작을 모두 사용할 수 있고, 모두 같은 아틀라스에서 나오기 때문에 Draw Call도 한 번만 발생합니다.

리소스 디렉터리 네이밍 규칙과 모범 사례

프로젝트가 절반쯤 진행되면 assets 디렉터리가 엉망이 되는 경우가 많습니다. 이미지, 스크립트, 프리팹이 섞여 있고, 파일명도 제각각이라 리소스를 찾는 일이 바다에서 바늘 찾기처럼 됩니다. 실제 프로젝트에서 겪은 경험을 기준으로 Cocos Creator용 리소스 디렉터리 규칙을 정리해 보겠습니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

기본 네이밍 규칙

핵심 원칙은 단순합니다. 한 폴더에는 한 종류의 파일만 둡니다.

texture, prefab, animation을 같은 디렉터리에 넣지 마세요. 유형별로 나누면 찾기도 쉽고 유지보수도 덜 피곤합니다.

네이밍 형식은 Unity나 Unreal에서 자주 쓰이는 업계 관례를 참고할 수 있습니다.

prefix_theme_description_suffix

예시는 다음과 같습니다.

• char_knight_idle_a.png - 캐릭터, 기사, 대기, albedo 기본 색상
• char_knight_attack_01.png - 캐릭터, 기사, 공격, 번호 01
• ui_btn_play_9slice.png - UI, 버튼, 재생, 9-slice

suffix 약속:

• _a - albedo, 기본 색상 텍스처
• _n - normal, 노멀 맵
• _9 - 9slice, 9-slice 이미지

이 네이밍 규칙은 처음에는 번거롭게 보입니다. 하지만 장점은 분명합니다. 파일명만 봐도 무엇인지, 어디에 쓰이는지 알 수 있습니다. 팀으로 작업할 때 네이밍 규칙은 커뮤니케이션 비용을 가장 낮게 줄이는 방법입니다.

추천 디렉터리 구조 템플릿

리소스 유형이 아니라 게임 기능 모듈 기준으로 나누는 것을 추천합니다. 개발 중에는 “모든 텍스처”가 아니라 “캐릭터 시스템”을 기준으로 생각하기 때문입니다.

assets/
├── characters/
│   ├── hero/
│   │   ├── textures/         # 캐릭터 텍스처
│   │   ├── animations/       # 애니메이션 리소스
│   │   ├── sprites/          # SpriteFrame
│   │   └── prefab/           # 캐릭터 프리팹
│   ├── enemies/
│   │   ├── textures/
│   │   ├── animations/
│   │   ├── sprites/
│   │   └── prefab/
│   ├── npcs/
│
├── scenes/
│   ├── level01/
│   │   ├── textures/         # 씬 텍스처
│   │   ├── tilemaps/         # 타일맵
│   │   ├── prefab/           # 씬 프리팹
│
├── ui/
│   ├── textures/             # UI 텍스처
│   ├── fonts/                # 폰트 파일
│   ├── prefab/               # UI 프리팹
│
├── audio/
│   ├── effects/              # 효과음
│   ├── music/                # 배경 음악
│
├── scripts/                  # TypeScript 스크립트
│   ├── components/           # 사용자 정의 컴포넌트
│   ├── utils/                # 유틸리티 클래스
│
├── resources/                # 동적 로딩 리소스, 신중하게 사용
│   ├── languages/            # 다국어 텍스트
│   ├── unlock-scenes/        # 잠금 해제 씬

이 구조의 장점은 각 모듈이 자기 안에서 완결된다는 점입니다. hero 캐릭터를 수정할 때는 characters/hero 디렉터리 안에서만 작업하면 되고, 다른 리소스를 잘못 건드릴 가능성도 줄어듭니다.

흔한 오류와 피하는 방법

제가 직접 겪었던 문제는 다음과 같습니다.

문제 1: 파일을 섞어 둠
hero.png와 hero.prefab을 같은 디렉터리에 두면 나중에 정리가 어려워집니다. 분리해서 보관하세요. textures에는 이미지, prefab에는 프리팹을 둡니다.

문제 2: 파일명을 마음대로 지음
image1.png, new_picture.png, untitled.png 같은 이름은 한 달만 지나도 무엇인지 알기 어렵습니다. 규칙에 맞춰 이름을 지으면 파일명 자체가 문서 역할을 합니다.

문제 3: meta 파일을 무시함
리소스의 이름을 바꾸거나 이동하면서 meta 파일 동기화를 놓치면 프리팹 안의 참조가 전부 Missing으로 바뀝니다. 다시 연결하는 데 시간이 많이 듭니다.

Cocos Creator에는 에디터 안에서 이름을 바꾸거나 이동하면 meta 파일을 자동으로 동기화하는 메커니즘이 있습니다. 그래서 모든 리소스 작업은 에디터 안에서 처리해야 합니다. 파일 시스템에서 직접 건드리지 않는 것이 좋습니다.

meta 파일 관리의 핵심 주의사항

meta 파일과 리소스 파일은 서로 묶여 있습니다. 핵심 규칙은 다음과 같습니다.

1. 같은 이름, 같은 디렉터리: knight.png.meta는 반드시 knight.png와 같은 디렉터리에 있어야 합니다.
2. 삭제 금지: meta 파일을 지우면 uuid가 사라지고 참조가 끊깁니다.
3. 직접 이름 변경 금지: meta 파일명을 직접 바꾸면 엔진이 리소스를 찾지 못할 수 있습니다.
4. 에디터 안에서 작업: 이름 변경, 이동, 삭제는 모두 에디터의 에셋 매니저에서 처리합니다.

파일 시스템 밖에서 작업해야 하는 상황, 예를 들어 대량 가져오기를 해야 한다면 가져온 뒤 meta 파일이 자동으로 생성될 때까지 기다리세요. 큰 프로젝트에서는 몇 분이 걸릴 수 있으니 중간에 과정을 끊지 않는 것이 중요합니다.

성능 튜닝: 아틀라스 제작과 Draw Call 제어

게임을 출시한 뒤 플레이어가 “버벅인다”, “프레임이 떨어진다”고 말할 때가 있습니다. 확인해 보니 Draw Call이 120+까지 올라가 있었습니다. 저사양 기기는 버티기 어렵습니다.

Draw Call은 무엇일까요? 스프라이트 하나를 렌더링할 때마다 엔진은 GPU에 그리기 명령을 한 번 보냅니다. 이 횟수가 너무 많아지면 CPU-GPU 통신 비용이 커지고 프레임레이트가 30 아래로 떨어집니다.

아틀라스가 필요한 이유: Draw Call 원리

직관적인 예를 들어 보겠습니다.

게임에 배경, 버튼, 아이콘, 텍스트 박스 등 UI 요소가 50개 있다고 합시다. 각 UI 요소가 모두 독립된 Sprite라면 엔진은 Draw Call을 50번 보내야 합니다.

반대로 이 50개 UI 요소를 모두 하나의 아틀라스로 패킹하면 엔진은 Draw Call을 한 번만 보내면 됩니다. GPU는 한 번의 렌더링 명령으로 아틀라스 전체 데이터를 로드하고, SpriteFrame에 따라 서로 다른 영역을 잘라 표시합니다.

데이터로 보면 차이가 더 분명합니다. 어떤 프로젝트는 조정 전 Draw Call이 120+였고, 조정 후에는 10 미만으로 내려갔습니다. 프레임레이트도 25fps에서 60fps로 올랐습니다. 저사양 기기에서는 체감이 바로 납니다.

동적 아틀라스 메커니즘 자세히 보기

Cocos Creator에는 자동 조정 메커니즘인 Dynamic Atlas가 있습니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

원리는 간단합니다. 엔진이 런타임에 흩어진 이미지를 임시 아틀라스로 자동 병합합니다. 개발자가 직접 패킹하지 않아도 엔진이 대신 처리합니다.

제어 방식은 SpriteFrame의 Packable 속성입니다. Packable을 체크하면 해당 SpriteFrame이 동적 아틀라스에 참여합니다. 체크를 해제하면 참여하지 않습니다.

하지만 동적 아틀라스에는 한계가 있습니다.

1. 흩어진 이미지 32장 미만만 지원하며, 이를 넘으면 효과가 사라질 수 있습니다.
2. 런타임에 병합하므로 일정한 비용이 듭니다.
3. 이미지 수가 바뀌면 아틀라스가 재구성되어 안정성이 떨어질 수 있습니다.

그래서 정식 프로젝트에서는 수동 아틀라스 패킹을 권장합니다. 동적 아틀라스는 빠른 프로토타입에는 잘 맞지만, 실제 출시 프로젝트에는 덜 적합합니다.

자동 아틀라스 설정과 빌드 흐름

Cocos Creator 3.x에는 Auto Atlas라는 내장 기능이 있습니다.

사용 방법은 다음과 같습니다.

1. assets 디렉터리에 AutoAtlas 리소스를 만듭니다.
2. 패킹할 SpriteFrame을 추가합니다.
3. 프로젝트를 빌드할 때 “자동 아틀라스” 옵션을 체크합니다.
4. 빌드가 끝나면 흩어진 이미지가 자동으로 아틀라스로 병합됩니다.

자동 아틀라스의 장점은 빌드 시점에 자동으로 처리되어 수동 패킹 단계가 줄어든다는 점입니다.

다만 주의할 점이 있습니다. 빌드 후 아틀라스 파일은 assets 디렉터리가 아니라 빌드 출력 디렉터리에 생성됩니다. 개발 중에 보는 것은 여전히 개별 이미지이고, 빌드 후에야 아틀라스가 됩니다. 디버깅할 때 이 차이를 기억해야 합니다.

성능 개선 효과 수치화

아틀라스 조정 효과는 어떻게 확인할까요?

Cocos Creator의 디버그 패널을 열고 Draw Call 값을 확인하면 됩니다. 조정 전 값을 기록한 뒤 조정 후와 비교하세요.

프레임레이트가 두 배가 되고 버벅임이 사라집니다. 이것이 아틀라스 조정의 가치입니다.

아틀라스는 메모리 비용도 낮춥니다. 텍스처 전환이 줄어들어 GPU가 서로 다른 텍스처 데이터를 자주 로드할 필요가 없습니다. 메모리 사용도 더 안정적이고 GC 부담도 줄어듭니다.

정리

AI로 아트 에셋을 생성한 뒤 Cocos Creator에서 쓸 수 있는 리소스로 만드는 흐름의 핵심은 표준화와 자동화입니다.

SOON, Holopix AI, Anything XL 같은 AI 도구는 아트 비용을 기존의 10분의 1 수준으로 낮춰 줍니다. 하지만 소재 생성은 첫 단계일 뿐입니다. 엔진으로 가져오기, 규칙 있는 디렉터리 구조 만들기, 아틀라스 패킹, Draw Call 제어가 프로젝트의 장기 유지보수성을 결정합니다.

기억할 점은 네 가지입니다.

• assets 디렉터리는 유일한 리소스 저장소이며, 다른 폴더는 함부로 삭제하지 않습니다.
• meta 파일은 리소스의 신분증입니다. 모든 작업은 에디터 안에서 처리합니다.
• 디렉터리 구조는 기능 모듈 기준으로 나누고, 한 폴더에는 한 종류의 파일만 둡니다.
• 아틀라스 패킹은 성능 튜닝에서 필수에 가깝습니다. Draw Call을 100+에서 10 미만으로 낮출 수 있습니다.

작은 프로젝트에서 먼저 연습해 보기를 권합니다. SOON이나 Holopix AI로 캐릭터 하나를 만들고, 이 글의 흐름대로 Cocos Creator에 가져온 뒤 규칙 있는 리소스 디렉터리를 구성해 보세요. 아트 에셋 관리는 더 이상 막연한 문제가 아니라 반복 가능한 워크플로가 됩니다.

이 흐름을 한 번 통과하고 나면 큰 프로젝트의 리소스 관리도 훨씬 자연스럽게 이어집니다.