미니게임 UI 리소스 네이밍 규칙: 투명 이미지, 버튼, 아이콘, 캐릭터 소재

프로젝트 폴더 안에 btn_ok.png, button_confirm.png, 按钮_确定.png 같은 파일이 함께 누워 있지는 않나요? 세 가지 네이밍 스타일, 세 가지 해석 방식, 그리고 세 가지 협업 재난의 시작입니다.

저도 이 함정에 빠진 적이 있습니다. 첫 미니게임 프로젝트가 끝났을 때 아트 폴더에는 200장이 넘는 소재가 있었고, 절반은 영어 축약어, 절반은 중국어 직역, 일부는 아예 新建文件夹 (2).png라는 이름이었습니다. 파일을 찾는 일은 바다에서 바늘을 찾는 일 같았고, UI를 고칠 때마다 어떤 파일이 어떤 상태에 대응하는지 확인하느라 반나절이 걸렸습니다.

이 글은 한 가지 문제를 해결합니다. 한 세트의 네이밍 공식으로 UI 리소스를 한눈에 알아보게 만드는 방법입니다. 접두사, 카테고리, 기능, 상태. 이 네 요소만 조합하면 충분합니다.

1장: 네이밍 혼란의 실제 비용 - 규칙이 중요한 이유

먼저 실제 이야기를 하나 해보겠습니다.

작년에 친구 두 명과 캐주얼 미니게임을 만들었습니다. 세 명이 역할을 나눴습니다. 저는 코드를 맡고, 왕은 아트를 만들고, 리는 기획을 썼습니다. 프로젝트 두 번째 달에 왕이 버튼 소재 묶음을 보내왔습니다. 파일은 12개였고 이름은 전부 按钮1.png부터 按钮12.png까지였습니다. 제가 어떤 것이 확인 버튼이고 어떤 것이 취소 버튼인지 묻자 그는 이렇게 말했습니다. “이미지를 보면 알잖아.”

그 순간 저는 화면 위의 12장 이미지를 바라봤습니다. 모두 비슷한 크기의 둥근 사각형이고 색만 조금씩 달랐습니다. 대응 관계를 정리하는 데 15분이 걸렸습니다. 나중에 프로젝트가 출시된 뒤 왕이 버튼 색상안을 다시 바꾸고 새 이미지 12장을 보냈습니다. 이번 이름은 新按钮1.png부터 新按钮12.png까지였습니다. 기존 이미지는 삭제되지 않았고 새 이미지와 섞였습니다. 제 폴더에는 “버튼”이라는 이름의 파일이 24개나 누워 있었습니다.

Tencent WeChat 게임 팀은 합리적인 네이밍이 파일 검색 시간을 80% 줄일 수 있다고 통계로 확인했습니다. 작은 숫자가 아닙니다. 매일 소재를 10번 찾고, 한 번에 3분이 걸린다고 해봅시다. 하루 30분입니다. 규칙을 정하면 6분으로 줄어듭니다. 한 달이면 12시간을 아낍니다. 새 기능 프로토타입 하나를 끝내기에 충분한 시간입니다.

더 큰 문제는 자동화 스크립트에서 생깁니다. 저는 버튼 소재를 일괄 교체하는 작은 도구를 만든 적이 있습니다. 로직은 단순했습니다. btn_으로 시작하는 모든 PNG 파일을 찾아 새 버전으로 바꾸는 방식이었습니다. 그런데 스크립트가 한참을 돌아도 파일을 하나도 찾지 못했습니다. 왕의 네이밍에는 애초에 btn_이 없고 전부 중국어였기 때문입니다. 스크립트는 쓸모없어졌고, 저는 두 시간을 들여 수동으로 바꿨습니다.

코드에서 소재 이름을 참조할 때 문제는 더 뚜렷해집니다. 이 두 줄을 보세요.

// 규칙이 있는 네이밍
this.confirmButton.spriteFrame = assets.get('btn_ok_pressed');

// 규칙이 없는 네이밍
this.confirmButton.spriteFrame = assets.get('button2');

첫 줄은 “확인 버튼의 눌린 상태”라는 것을 한눈에 알 수 있습니다. 두 번째 줄은 어떨까요? button2가 무엇일까요? 아트 폴더를 열고 button2.png를 찾아 이미지를 확인해야 합니다. UI를 고칠 때마다 이렇게 뒤져야 한다면 코드 가독성은 바로 무너집니다.

2장: 범용 네이밍 공식 - 한 공식으로 모든 상황 해결하기

“규칙”이라는 말에 겁먹을 필요는 없습니다. 핵심 공식은 사실 아주 단순합니다.

prefix_function_state.png

조금 더 완전하게 쓰면 다음과 같습니다.

[email protected]

네 요소가 왼쪽에서 오른쪽으로 단계적으로 좁혀집니다. 예를 들어 [email protected]를 보겠습니다. 풀어 쓰면 메일 모듈, 아이콘 카테고리, 검색 기능, 눌린 상태, 2배 이미지입니다. 각 부분의 의미가 명확합니다.

자주 쓰는 접두사 빠른 표

Tencent Cloud Cocos Creator 기초 튜토리얼과 Zhaopin UI 디자인 규칙의 제안을 종합해 가장 자주 쓰는 축약어 15개를 정리했습니다.

축약어	전체 이름	적용 상황
bg	background	화면 배경, 팝업 배경
nav	navbar	내비게이션 바 요소
tab	tabbar	탭 바 아이콘
btn	button	다양한 버튼
icon	icon	기능 아이콘, 상태 아이콘
img	image	범용 이미지 소재
txt	text	제목 같은 텍스트 이미지
pop	popup	팝업 관련
bar	bar	진행 바, 상태 바
mask	mask	마스크 레이어
sep	separator	구분선
del	delete	삭제 버튼, 삭제 아이콘
add	add	추가 버튼, 추가 아이콘
msg	message	알림 메시지, 말풍선
logo	logo	로고 이미지

이 축약어들은 공통점이 있습니다. 짧고, 외우기 쉽고, 한눈에 무엇인지 알 수 있습니다. button 대신 btn, background 대신 bg를 쓰세요. 길수록 오타가 나기 쉽고, 길수록 문자를 차지합니다.

모듈 전용 리소스 vs 공용 리소스

이름을 붙이기 전에 먼저 한 가지를 생각해야 합니다. 이 소재는 한 모듈에서만 쓰이나요, 아니면 프로젝트 전체에서 쓸 수 있나요?

공용 리소스: 모듈 접두사를 붙이지 않고 바로 카테고리로 시작합니다. 예를 들어 홈 화면 배경 이미지는 home_bg.png가 아니라 bg_home.png로 이름을 붙입니다. 배경은 다른 모듈에서도 재사용될 수 있으므로 카테고리 기준으로 묶는 편이 더 찾기 쉽습니다.

모듈 전용 리소스: 모듈 접두사를 붙이면 일괄 처리가 쉬워집니다. 예를 들어 메일 모듈의 검색 아이콘은 mail_icon_search.png로 이름을 붙입니다. 메일 UI를 통째로 바꿀 때 mail_ 접두사만 검색하면 관련 소재를 함께 교체할 수 있습니다.

크기 차이가 있는 이름

같은 버튼에 큰 버전과 작은 버전이 있는 경우가 있습니다. 저는 기능 뒤에 크기 설명을 붙입니다.

btn_ok_big_n.png      # 큰 확인 버튼(정상 상태)
btn_ok_small_n.png    # 작은 확인 버튼(정상 상태)

또는 구체적인 크기 숫자를 쓸 수도 있습니다.

btn_ok_128_n.png      # 폭 128px 확인 버튼
btn_ok_64_n.png       # 폭 64px 확인 버튼

어느 쪽을 선택해도 괜찮습니다. 핵심은 프로젝트 안에서 통일하는 것입니다. 한 번은 big/small, 한 번은 숫자, 또 한 번은 l/s를 쓰면 안 됩니다. 혼란의 뿌리는 네이밍 규칙 자체가 아니라 규칙이 통일되지 않는 데 있습니다.

3장: 버튼과 아이콘 네이밍 - 상태를 한눈에 명확하게

버튼은 UI 소재 중 수량이 가장 많고 상태가 가장 복잡한 유형입니다. 버튼 하나에는 보통 네 가지 상태가 있습니다. 정상, 눌림, 선택, 비활성입니다. Douban UI 네이밍 규칙은 영어 단어나 축약어를 통일해 쓰라고 제안합니다.

상태	전체 이름	축약어	예시
정상	normal	n / def	btn_ok_n.png
호버	hover	h	btn_ok_h.png
눌림	pressed	p / pre	btn_ok_p.png
선택	selected	s / sel	btn_ok_s.png
비활성	disabled	d / dis	btn_ok_d.png

저는 한 글자 축약어를 자주 씁니다. 이유는 단순합니다. 짧기 때문입니다. btn_ok_n.png는 btn_ok_normal.png보다 5자가 적고, 입력이 빠르며 보기에도 산뜻합니다. 물론 팀이 전체 이름에 익숙하다면 전체 이름을 통일해서 써도 됩니다. 어떤 버튼은 btn_ok_normal, 어떤 버튼은 btn_ok_n이라고 부르면 검색할 때 매우 번거로워집니다.

버튼 네이밍 실전

프로젝트에 파란색 둥근 스타일의 “확인” 버튼이 필요하고 네 가지 상태가 모두 있다고 가정해 보겠습니다. 네이밍은 이렇게 할 수 있습니다.

btn_ok_n.png          # 정상 상태
btn_ok_p.png          # 눌린 상태
btn_ok_s.png          # 선택 상태
btn_ok_d.png          # 비활성 상태

빨간색과 초록색 버전도 있다면 다음처럼 씁니다.

btn_blue_ok_n.png     # 파란색 확인 버튼(정상)
btn_red_ok_n.png      # 빨간색 확인 버튼(정상)
btn_green_ok_n.png    # 초록색 확인 버튼(정상)

순서는 카테고리(btn) + 색상(blue) + 기능(ok) + 상태(n)입니다. 이렇게 배열하면 파일을 알파벳순으로 정렬했을 때 같은 색상의 버튼이 모여 일괄 교체하기 편합니다.

아이콘 네이밍: 기능 우선

아이콘과 버튼의 차이는 상태 수입니다. 대부분의 아이콘은 정상과 비활성, 두 가지 상태만 있습니다. 네이밍 패턴은 다음과 같습니다.

icon_search_n.png     # 검색 아이콘(정상)
icon_search_d.png     # 검색 아이콘(비활성)

아이콘 네이밍의 핵심은 기능 설명이 정확해야 한다는 점입니다. icon1.png라고 부르지 말고 icon_search.png나 icon_delete.png라고 부르세요. 파일명만 봐도 용도를 알 수 있어야 하며, 이미지를 열어 추측하게 만들면 안 됩니다.

흔한 잘못된 예

저는 button_确认_正常.png 같은 이름을 본 적이 있습니다. 영어 접두사, 중국어 기능, 중국어 상태가 섞여 있습니다. 보기에는 직관적일 수 있지만 문제는 다음과 같습니다.

1. 정렬 혼란: 중국어는 파일 시스템마다 정렬 규칙이 안정적이지 않아 确认이 取消 앞에 올 수도 있고 뒤에 올 수도 있습니다.
2. 스크립트 호환성 저하: 일괄 처리 스크립트는 보통 정규식으로 매칭하는데, 중국어 문자는 매칭 로직을 복잡하게 만듭니다.
3. 팀 협업 난이도 증가: 나중에 프로젝트가 국제화를 지원해야 하면 중국어 이름을 모두 바꿔야 합니다.

가장 안정적인 방법은 전체 과정에서 영어, 소문자, 밑줄 구분을 사용하는 것입니다. btn_ok_n.png는 간결하고, 정렬 가능하며, 정규식으로 처리하기 쉽고, 국제화에도 유리합니다.

4장: 캐릭터 소재 네이밍 - 액션 프레임 시퀀스를 더 이상 헷갈리지 않게

캐릭터 소재는 UI 버튼보다 훨씬 복잡합니다. 주인공 하나만 해도 여러 동작이 있을 수 있습니다. 대기, 걷기, 달리기, 공격, 피격, 사망, 점프 같은 동작입니다. 각 동작은 다시 여러 방향으로 나뉘고, 각 방향에는 애니메이션 프레임이 이어집니다.

제가 가장 크게 겪은 문제는 프레임 번호였습니다. 처음 캐릭터 애니메이션을 만들 때는 한 자리 번호를 사용했습니다.

hero_run_left_1.png
hero_run_left_2.png
hero_run_left_3.png
...
hero_run_left_10.png

겉보기에는 정상입니다. 문제는 파일 정렬에서 발생했습니다. 폴더를 열어 보니 hero_run_left_10.png가 hero_run_left_1.png와 hero_run_left_2.png 사이에 있었습니다. 파일 시스템은 문자 기준으로 정렬하고, 10의 첫 글자인 1이 2보다 앞서기 때문입니다.

완전한 재난이었습니다.

그 뒤로 저는 두 자리 번호를 강제로 사용했습니다.

hero_run_left_00.png
hero_run_left_01.png
hero_run_left_02.png
...
hero_run_left_09.png
hero_run_left_10.png

00부터 09까지는 모두 10보다 작으므로 정렬이 드디어 정상으로 돌아옵니다. 애니메이션 프레임 수가 100을 넘는다면 세 자리 번호(000부터 999)를 사용하세요.

캐릭터 네이밍 공식

캐릭터 스프라이트 이미지의 전체 네이밍 공식은 다음과 같습니다.

character_action_direction_frame.png

예시를 풀어보면 다음과 같습니다.

• hero_idle_down_00.png - 주인공_대기_아래 방향_0번 프레임
• player_run_left_01.png - 플레이어_달리기_왼쪽_1번 프레임
• enemy_attack_right_02.png - 적_공격_오른쪽_2번 프레임

동작 단어 빠른 표

동작	영어	축약어(선택)
대기	idle	-
걷기	walk	-
달리기	run	-
공격	attack	atk
피격	hurt	-
사망	death	die
점프	jump	-
시전	cast	-

축약어를 쓸지는 취향에 달려 있습니다. atk는 attack보다 짧지만 새 팀원이 모를 수 있습니다. 전체 이름은 더 보편적이고, 축약어는 더 간결합니다. 저는 애니메이션 프레임 수가 20개 이하라면 전체 이름을 쓰고, 20개를 넘을 때만 축약어를 고려하라고 권합니다. 파일명이 너무 길면 경로 표시가 잘릴 수 있기 때문입니다.

방향 표시

가장 단순한 방식은 4방향입니다. up, down, left, right를 씁니다.

8방향은 0부터 7까지 번호로 표시할 수도 있습니다. 0을 위쪽, 1을 오른쪽 위로 약속하고 이어 가는 방식입니다. 하지만 번호 방식은 외우기 어렵고 매번 표를 확인해야 한다는 문제가 있습니다. 저는 방향 이름을 직접 쓰는 쪽을 더 좋아합니다.

hero_attack_up.png
hero_attack_upright.png
hero_attack_right.png
hero_attack_downright.png
hero_attack_down.png
hero_attack_downleft.png
hero_attack_left.png
hero_attack_upleft.png

8방향 이름은 조금 길지만 읽을 때 추측할 필요가 없습니다. 프로젝트의 방향이 단순하다면, 예를 들어 4방향이거나 좌우만 있다면 방향 이름이 가장 안정적입니다. 방향이 복잡하다면, 8방향 또는 그 이상이라면 번호가 더 압축적일 수 있습니다.

5장: Cocos Creator 리소스 디렉터리 구조 - 분류 저장으로 효율 높이기

네이밍 규칙은 “파일 이름을 무엇으로 할 것인가”를 해결합니다. 디렉터리 구조는 “파일을 어디에 둘 것인가”를 해결합니다. 두 가지를 모두 잘해야 소재를 진짜로 빠르게 찾을 수 있습니다.

Tencent Cloud Cocos Creator 기초 튜토리얼이 제안하는 구조는 다음과 같습니다.

assets/
├── textures/           # 텍스처 소재
│   ├── ui/             # UI 요소(버튼, 진행 바)
│   ├── icons/          # 기능 아이콘
│   ├── backgrounds/    # 배경 이미지
│   └── characters/     # 캐릭터 스프라이트 이미지
├── audio/              # 오디오 파일
│   ├── effects/        # 효과음
│   └── music/          # 배경음악
├── animations/         # 애니메이션 클립
├── prefabs/            # 프리팹
└── scripts/            # TypeScript 스크립트

공용 vs 모듈 전용: 따로 보관하기

제가 겪은 문제 중 하나는 모든 소재를 textures/ui/에 밀어 넣는 것이었습니다. 그 결과 300개 파일이 한 폴더에 몰렸습니다. 열 때도 오래 걸리고, 스크롤도 오래 걸리고, 파일 찾기도 오래 걸렸습니다.

더 좋은 방법은 “공용 리소스”와 “모듈 전용 리소스”를 구분하는 것입니다.

공용 리소스는 textures/ 아래의 1차 하위 디렉터리에 둡니다. 예를 들어 모든 모듈에서 쓸 수 있는 아이콘은 textures/icons/에 보관합니다.

모듈 전용 리소스는 모듈 전용 디렉터리에 둡니다. 예시는 다음과 같습니다.

assets/
├── modules/
│   ├── login/          # 로그인 모듈
│   │   ├── textures/   # 로그인 화면 전용 소재
│   │   ├── prefabs/    # 로그인 화면 프리팹
│   │   └── scripts/    # 로그인 로직 스크립트
│   ├── battle/         # 전투 모듈
│   │   ├── textures/   # 전투 화면 소재
│   │   ├── prefabs/    # 전투 프리팹
│   │   └── scripts/    # 전투 스크립트

이렇게 하면 모듈을 바꿀 때 전체 assets 디렉터리를 뒤질 필요가 없습니다. 전투 화면을 고칠 때는 modules/battle만 보면 되고, 로그인 화면을 고칠 때는 modules/login만 보면 됩니다.

지나친 세분화는 피하기

너무 세밀한 분류는 오히려 번거로움을 더합니다. 저는 textures/ui/buttons/blue/rounded/처럼 다섯 단계 디렉터리를 만들고 각 디렉터리에 파일을 두세 개만 넣는 사례를 본 적이 있습니다. 소재를 찾을 때 디렉터리 트리를 한 단계씩 눌러 들어가야 해서 파일명을 바로 보는 것보다 더 느립니다.

제 제안은 이렇습니다. 1차 분류면 충분합니다. 특정 소재가 정말 많을 때, 예를 들어 캐릭터 소재가 스프라이트 이미지 50개를 넘을 때만 더 나누세요. textures/ui/에는 버튼, 진행 바, 구분선을 두고, textures/icons/에는 아이콘을 두고, textures/backgrounds/에는 배경을 둡니다. 세 단계 이내면 한눈에 들어옵니다.

프리팹과 스크립트는 가까이 두기

프리팹(prefabs)과 스크립트(scripts)는 대응하는 소재와 같은 층에 두는 편이 좋습니다. 예를 들어 로그인 화면의 버튼 프리팹은 modules/login/prefabs/에, 해당 소재는 modules/login/textures/에 둡니다. 두 디렉터리가 나란히 있으면 참조 경로가 짧고, 수정할 때 디렉터리를 크게 넘나들 필요가 없습니다.

Cocos Creator 공식 문서도 이 원칙을 언급합니다. 관련 파일은 가까운 곳에 보관해 디렉터리 간 참조를 줄이세요. 경로가 짧을수록 프로젝트가 더 명확해지고, 마이그레이션과 리팩터링도 더 쉬워집니다.

6장: 7가지 네이밍 황금 원칙 - Tencent 게임 팀의 경험

Tencent WeChat 게임 팀은 네이밍 황금 원칙을 정리한 적이 있습니다. 여기에 제 실무 경험을 더해 하나씩 풀어보겠습니다.

1. 간명하게: 충분한 세부 정보를 담되 지나치게 복잡하지 않게

파일명은 핵심 정보를 전달해야 하지만 너무 길어서는 안 됩니다.

좋은 예: btn_ok_n.png - 버튼, 확인 기능, 정상 상태라는 것을 한눈에 알 수 있습니다.

나쁜 예: button_confirm_normal_state_blue_rounded_large.png - 정보가 너무 밀집되어 읽기 어렵고 입력하기도 번거롭습니다.

제 방식: 파일명은 3-5개의 단어 조각 안에 맞춥니다. 5개를 넘으면 부차적인 정보, 예를 들어 “rounded” 같은 세부 사항은 삭제하고 필요하면 코드 주석에 보충합니다.

2. 단계적으로 좁히기: 개괄에서 구체로 이름 붙이기

네이밍 순서는 인지 흐름에 맞아야 합니다. 먼저 큰 카테고리, 그다음 작은 기능, 마지막에 세부 정보입니다.

environment_forest_tree_01.png

해석하면 환경 소재 -> 숲 장면 -> 나무 -> 첫 번째 변형입니다.

이런 정렬의 장점은 같은 카테고리 파일이 자동으로 모인다는 점입니다. environment_forest를 검색하면 모든 숲 소재가 나타납니다.

3. 합리적인 정렬: 알파벳순 검색을 쉽게 만들기

접두사 선택은 정렬 효과에 영향을 줍니다. 가장 중요한 카테고리를 맨 앞에 둡니다.

예를 들어 캐릭터 소재에서는 character_hero_보다 hero_로 시작하는 편이 더 좋습니다. 모든 주인공 소재가 h 구역에 모이므로 c 구역에서 뒤질 필요가 없습니다.

4. 형식 일관성: snake_case 또는 camelCase 통일

프로젝트에서 한 가지 형식을 정하고 끝까지 통일합니다.

저는 snake_case(소문자 + 밑줄 구분)를 선호합니다. 이유는 다음과 같습니다.

• 파일 시스템 호환성이 좋습니다. 대소문자 민감성 문제가 덜합니다.
• 가독성이 높습니다. 단어 경계가 명확합니다.
• 정규식 매칭이 간단합니다. _로 바로 나눌 수 있습니다.

팀이 camelCase에 익숙하다면 카멜 케이스를 통일해 써도 됩니다. 섞어 쓰면 스크립트 처리에서 문제가 생깁니다.

5. 번호 통일: 01/02 또는 001/002를 사용해 한 자리 번호 피하기

이 내용은 4장에서 자세히 말했습니다. 한 자리 번호는 정렬 혼란을 만들기 때문에 반드시 0으로 채워야 합니다.

두 가지 규칙만 기억하면 됩니다.

• 프레임 수가 99를 넘지 않으면 두 자리 번호(00부터 99)를 씁니다.
• 프레임 수가 99를 넘으면 세 자리 번호(000부터 999)를 씁니다.

6. 문법 일관성: 동사 형태 통일

어떤 동작은 두 가지로 쓸 수 있습니다. spin과 spinning, attack과 attacking처럼요.

한 가지를 정했다면 끝까지 통일하세요.

잘못된 예:

cha_sonic_spin_01.png
cha_sonic_spinning_02.png

두 파일은 같은 동작이지만 네이밍이 일관되지 않습니다. 스크립트로 찾을 때 하나가 빠질 수 있습니다.

올바른 예:

cha_sonic_spin_01.png
cha_sonic_spin_02.png

7. 단어 형태 일관성: 철자 표준 통일

영국식 철자와 미국식 철자가 다른 경우가 있습니다. ambience(영국식)와 ambiance(미국식), colour(영국식)와 color(미국식)가 그렇습니다.

한 가지 표준을 정하세요. 일반적으로 더 보편적인 미국식 철자를 권장합니다. 프로젝트 안에서 한 번은 bg_ambience.png, 또 한 번은 bg_ambiance.png라고 쓰면 스크립트 처리에서 문제가 생깁니다.

7장: 투명 이미지와 특수 소재 네이밍 팁

일부 UI 소재는 조금 특별해서 이름을 붙일 때 추가 고려가 필요합니다.

투명 PNG 네이밍

투명 배경 PNG 소재는 게임 UI에서 흔합니다. 버튼, 아이콘, 오버레이 효과가 여기에 해당합니다. 이름을 붙일 때 _trans 또는 _overlay 접미사를 사용할 수 있습니다.

btn_trans_round.png        # 투명 둥근 버튼(테두리 없음)
icon_overlay_star.png      # 별 오버레이 아이콘(badge용)

투명 소재는 파일명만 보고 투명도를 판단하기 어려울 수 있으므로 접미사로 알려주는 편이 좋습니다. 사용할 때 이 파일의 배경이 투명하다는 것을 바로 알 수 있고, 열어서 확인할 필요가 줄어듭니다.

마스크 레이어 네이밍

마스크(mask)는 이미지를 자르거나 둥근 모서리 효과를 구현할 때 사용합니다. 네이밍 형식은 다음과 같습니다.

mask_rounded.png           # 둥근 모서리 마스크
mask_circle.png            # 원형 마스크
mask_gradient.png          # 그라데이션 마스크

마스크 파일은 보통 많지 않습니다. textures/ui/masks/ 디렉터리에 두어도 되고, 바로 textures/ui/에 두어도 괜찮습니다.

다국어 리소스 네이밍

국제화 프로젝트에는 여러 세트의 텍스트 이미지가 필요합니다. 네이밍 형식은 다음과 같습니다.

title_zh.png               # 중국어 제목
title_en.png               # 영어 제목
title_ja.png               # 일본어 제목

또는 ISO 언어 코드를 사용할 수 있습니다.

btn_start_zh-CN.png        # 간체 중국어
btn_start_zh-TW.png        # 번체 중국어
btn_start_en-US.png        # 미국식 영어
btn_start_ja-JP.png        # 일본어

전체 ISO 코드는 더 정확하지만 파일명이 더 길어집니다. 프로젝트 언어 버전이 5개를 넘지 않는다면 zh/en/ja 같은 약어로도 충분합니다.

다중 배율 대응 네이밍

모바일 게임은 일반 화면, 고해상도 화면, 초고해상도 화면처럼 서로 다른 화면 밀도에 대응해야 합니다. Cocos Creator는 @1x, @2x, @3x 접미사를 권장합니다.

[email protected]            # 일반 밀도(1배)
[email protected]            # 고밀도(2배)
[email protected]            # 초고밀도(3배)

이 접미사는 iOS/Android 표준과 일치하며 TexturePacker 같은 소재 도구도 자동으로 인식할 수 있습니다.

주의: 배율 접미사는 상태 뒤에 둡니다. 파일명 맨 끝에 따로 두는 방식보다 [email protected]가 btn_ok@2x_n.png보다 더 명확합니다. 먼저 어떤 소재인지, 즉 확인 버튼의 정상 상태인지 확인하고, 그다음 어떤 배율인지 확인하는 순서입니다.

특수문자 처리

파일명에 공백, 괄호, 중국어 같은 특수문자가 들어가는 경우가 있습니다. 제 제안은 전부 피하는 것입니다.

공백: 밑줄로 대체합니다. btn ok.png -> btn_ok.png.

괄호: 삭제하거나 숫자로 바꿉니다. btn_ok(1).png -> btn_ok_01.png.

중국어: 영어로 통일합니다. 按钮_确定.png -> btn_ok.png.

특수문자는 크로스 플랫폼 환경에서 문제를 일으킬 수 있습니다. Windows는 중국어 파일명을 허용하지만 일부 Linux 서버는 지원하지 않을 수 있습니다. FTP 전송 중 중국어가 깨질 수 있습니다. CI/CD 빌드에서 경로 파싱이 실패할 수도 있습니다. 가장 안정적인 방법은 전체 과정에서 영어, 소문자, 특수문자 없음 원칙을 지키는 것입니다.

정리

네이밍 규칙의 핵심 공식은 결국 네 요소의 배열입니다. 접두사, 기능, 상태, 세부 정보입니다.

btn_ok_n.png는 카테고리(버튼) + 기능(확인) + 상태(정상)입니다. hero_run_left_00.png는 캐릭터 + 동작 + 방향 + 프레임 번호입니다. 이 공식을 익히면 UI 소재 네이밍의 90%를 해결할 수 있습니다.

나머지 10%는 세부 규칙입니다. 두 자리 번호로 정렬 혼란을 피하고, 전체 과정에서 영어를 사용해 크로스 플랫폼 문제를 피하며, 축약어를 통일해 스크립트가 실패하지 않게 하는 것들입니다. 이런 세부 사항은 이름 자체를 바꾸지는 않지만 실제 작업 효율을 결정합니다.

다음 세 가지부터 시작해 보세요.

1. 기존 프로젝트 점검: 아트 폴더를 열고 이름이 규칙에 맞지 않는 파일이 있는지 찾아 이 글의 공식으로 다시 이름을 붙입니다.
2. 축약어 표 만들기: 팀과 bg/btn/icon/nav 같은 축약어 표준을 정하고 적어 둔 뒤 잘 보이는 곳에 붙입니다.
3. 디렉터리 구조 정리: 공용 리소스와 모듈 전용 리소스를 구분하고 모든 파일을 한 폴더에 밀어 넣지 않습니다.

네이밍 규칙은 한 번 하고 끝나는 일이 아니라 지속적인 습관입니다. btn_ok_n.png라는 표기, 두 자리 번호, 전체 영어 네이밍에 익숙해지면 프로젝트 파일은 점점 더 명확해지고 소재를 찾는 속도도 점점 빨라집니다.