아이콘에 제대로 된 이름 붙여주기
Naming Conventions for Icons
많은 글들이 아이콘의 종류와 밀도 등 디자인 팁에 대해 자세히 설명하고 있다면, 이번에는 아이콘 등 비표준화된 네이밍 컨벤션에 관한 노하우와 그 에셋들을 효율적으로 관리하는 방법에 대해서 공유하고자 합니다.
Basic Principle
1. 제작한 아이콘들에 대해 일반적이며 규칙적인 범용적 네이밍 시스템을 사용하자.
아이콘 이름을 붙일 때, 이미지 파일들의 이름이 관련 있는 것들끼리 디렉토리 내에서 그룹핑될 수 있도록 정하는 게 좋습니다. 특히 일반적인 prefix를 사용하여 각각의 아이콘 타입과 배치될 위치를 나타내는 것은 매우 유용합니다. 반드시 이렇게 해야만 하는 것은 아니지만, 규칙을 지정해서 관리가 수월하게 하기 위한 하나의 팁입니다.
2. 논리적이고 예측 가능한 직관적인 명칭을 붙여주자.
아이콘의 구체적인 기능이 아니라 형태에 맞춰서 이름을 붙이는 편이 좋습니다. 예를 들어 < 라는 아이콘을 만들었을 때 기능은 History Back/Undo를 의미하더라도 'ic_arrow_left.png'와 같이 형태를 따르는 직관적인 이름을 붙여 줍니다. < 라는 아이콘이 다른 곳에서는 해당 기능이 아닌 요소로 재활용될 수 있기 때문입니다.
3. 아이콘에도 깔끔하고 효율적인 관리가 필요하다.
같은 이미지이나 다른 밀도(density)를 가진 아이콘 파일은 해상도만 다를 뿐 동일한 파일 이름을 사용해야 합니다. 저장 시에 밀도별 리소스 디렉토리에 각각의 경로(xxxhdpi, xxhdpi, xhdpi, hdpi, mdpi, ldpi)로 저장되기 때문에 파일이 이름이 같다고 해서 충돌이 일어나는 일은 거의 없습니다. 하지만 이 부분은 각 기기 화면에 따라 시스템이 적절한 리소스를 찾아 로드해주는 안드로이드 스튜디오에서 지원하는 기본 기능일 뿐이며, 디자이너는 각 디렉토리에 있는 아이콘 등의 그룹을 일관성 있게 유지해야 합니다.
4. 디자인 팀 단위, 프로젝트 단위의 명명 규칙을 설정하면 누구나 동일한 네이밍 룰을 따라야 한다.
일관성 있는 네이밍 룰은 시스템이 커지더라도 아이콘의 속성을 이해하기 쉽게 도와주고, 해당 에셋이 어디에 사용되는지 쉽게 알 수 있도록 합니다. 명확한 규칙 하나로 디자이너 모두가 작업의 목표를 빠르게 파악하도록 이끌 수도 있습니다. 그래서 좋은 네이밍 규칙을 위해서는 디자이너간/팀간 원활한 의사소통이 필수입니다. 정해진 아이콘 이름 규칙은 새로 조인한 디자이너들도 금방 이해할 수 있어야 합니다. 또 비정형적이고 난해하고 추상적이며 외우기 어려운 전문 용어를 적용한 나쁜 네이밍은 커뮤니케이션에 혼선을 가져와 프로젝트 관리 비용을 증가시킬 수밖에 없습니다. 아이콘이 한 번 배포되면 이름을 변경하는 것은 굉장히 귀찮기 때문에 되도록이면 임시 이름을 붙이지 않는 룰도 중요합니다.
5. 좋은 네이밍 규칙은 디자인 리소스를 아낄 수 있다.
만든 아이콘이 치수도 동일하고 이미지 하나를 회전만 시키는 것뿐이라면 디자이너는 네이밍을 지정해서 전달하고, 엔지이너가 코드를 통해 약간의 작업으로 회전시키는 게 훨씬 효율적입니다. UI에서 아이콘은 굉장히 중요한 작업이지만 스타트업 디자이너들이 대부분 많은 멀티태스킹 일들을 처리하고 있으니까.. 아이콘에서 필요한 모든 컬러 아이콘을 만들지 말고 코드로 덮을 수 있는(디자인에서 mask 개념으로) 환경도 엔지이너와 사전 협의로 가능합니다.
How-to
중간에 몇 번의 UI 리뉴얼 있던 작업이나 여러 명의 디자이너가 참여하고 있는 대규모 프로젝트의 경우 XML 네임스페이스가 뒤죽박죽 섞여 쉽게 제어할 수 없는 상황이 종종 발행합니다. 이런 고통을 해결할 저의 네이밍 꿀팁을 공유합니다.
우선 공통의 요소를 간단히 설명하겠습니다.
1. 미국식 영어 소문자 a-z, 언더대시 _, 숫자 0-9가 유효한 문자 세트입니다.
2. 아이콘 이름의 첫 글자는 _ 또는 영어 대소문자 일 수 있으며, 숫자는 될 수 없습니다.
3. .png와 .jpg, .svg와 같은 확장자에도 대문자를 사용하지 마십시오.
4. 공백을 사용할 수 없기 때문에 두 단어를 구별할 때 구분 기호로 안드로이드는 underdash _ / iOS는 dash -를 사용하세요. (한 번에 변경 가능한 플러그인들이 있어서 _로 통일해서 사용하셔도 무방합니다)
5. 에셋 네임은 앱/화면 전체에서 고유해야 합니다. 크기가 다른 두 개의 추가(add) 버튼이 있는 경우, 두 가지 이름을 모두 'add_icon.png'로 지정할 수 없습니다. 'add_icon_small.png'와 'add_icon_big.png'와 같은 두 가지 아이콘 이름을 붙여 다양한 밀도를 대응할 수 있습니다.
아래 그림에 제가 자주 사용하는 네이밍 규칙의 큰 구조를 정리했습니다. 에셋 이름을 중심으로 접두사(prefix)가 어떻게 붙을지 정의되고, 필요에 따라 옵션들이 접미사(suffix)로 붙는 방식입니다.
● 먼저 빨갛게 표시한 접두사(prefix) 영역에서 에셋의 유형과 네임스페이스를 정해줍니다.
에셋의 유형(asset type)은 what, 즉 이 리소스는 무엇?에 대한 대답이라고 생각하면 쉽습니다. 아이콘의 경우 icon를 축약해 ic로, 버튼의 경우 button의 btn, 이미지는 img, 로고의 경우 logo, 배경은 bg 등으로 큰 구분을 해줍니다.
네임스페이스(namespace)는 where, 즉 논리적으로 앱에 속한 위치를 적어줍니다. 여러 화면에서 사용되는 아이콘은 네임스페이스를 따로 붙이지 않고, 구체적인 하위 클래스에 속하는 아이콘에만 location에 해당하는 네임스페이스를 추가합니다. 예를 들어, 내비게이션에 사용될 아이콘이라면 'ic_navi_xxxx.png'로 붙을 수 있고, 런쳐에 사용될 아이콘이라면 'ic_launcher_xxx.png'라고, 또 탭 바에만 사용될 아이콘이라면 'ic_tab_xxxx.png' 등으로 구분할 수 있습니다.
● 노란 부분인 root는 에셋의 고유 이름입니다. 해당 아이콘을 가장 잘 설명할 수 있는 명사로 이름을 붙여줍니다. 대표할 만 명사가 없다면 구체적이고 특징적인 묘사 혹은 메타포(metaphor)로 네이밍을 붙여줍니다. 예로 arrow, check_box, chevron, error, cancel, radio_btn, star 등을 다양하게 붙일 수 있습니다.
● 마지막으로 파랗게 표시한 접미사(suffix) 영역은 앞의 ● 영역과 ● 명사의 조합으로 아이콘의 이름을 만들었는데 동일한 이름의 이미 다른 아이콘에 사용하고 있어서 아이콘끼리 충돌하는 상황에 부가적으로 한정자(qualifier)를 추가하는 부분입니다. 그림에서 표현된 박스의 순서대로 붙이는 편이 좋습니다.
direction은 모든 방향을 지닌 것들을 추가할 수 있습니다. 예로 right와 left, up과 down, horiz와 vert 등이 있습니다.
shape은 아이콘 고유의 형태에 대한 구체적인 언급이 필요할 경우 사용합니다.
outline은 축약해서 _o 만 붙이는 경우도 있으며, 안드로이드처럼 filled가 기본 형태 일 때 예외 케이스에서 아웃라인만의 아이콘이 필요할 경우 붙여줍니다. iOS처럼 아웃라인이 기본인 경우는 생략해도 됩니다.
status는 버튼의 경우 control status에 대한 묘사가 필요할 때 붙여줍니다.
color의 경우 black, white, pink, gray500 등 외의 다른 특별한 설명이 필요하다면 rgb 값보다 16 진수 코드(hexadecimal number)를 표기하는 게 좋습니다.
size는 구체적인 dp 값, small/medium/big 또는 @2x, @3x (Sketchapp과 Zeplin에서 iOS를 기준으로 추출하면 자동으로 처리 부분이라 네이밍 차원에서 붙이지 않아도 됩니다) 등이 들어갈 수 있습니다.
위에서 정리한 규칙을 적용해 보면 중복되지 않으면서 아이콘의 특징과 상태를 나타내는 이름을 빠르게 만들어 붙일 수 있습니다.
ic_chevron_left_black_24dp.png
ic_chevron_right_circle_black_24dp.png
ic_launcher_volume_down_white_36dp.png
ic_launcher_volume_outline_mute_white_36dp.png
ic_launcher_volume_off_white_36dp.png
배경, 이미지, 로고 등의 에셋에도 같은 방식의 네이밍 규칙을 적용해 관리할 수 있습니다.
bg_paris_120h.png
bg_portland_120h.png
img_portland_thumbnail.png
img_portland_001.png
img_portland_002.png
logo_shinhanbank_symbol.png
logo_shinhanbank_wordmark.png
추가로 제가 활용하고 있는 (가상의) 치트 시트를 공유합니다. 아래의 링크를 보면 실제 어떻게 활용될 수 있는지 도움이 됩니다.
https://docs.google.com/spreadsheets/d/17hykH_YPFdB0VHUUN1eWOsPTfEB6cuPN-2cZWMKFhz4/edit?usp=sharing
Naming Things:
snake_case vs. kebab-case vs. camelCase
Naming conventions Matrix
Case Mappingsnake_case: 'ic_show_me_the_money.png' 뱀이 바닥을 훑고 지나가는 것처럼.. 소문자로 쓴 단어/문장의 띄어쓰기 부분에 underscore(_)를 채워주는 표기 방식입니다. 보통 일반적인 안드로이드 아이콘 표기법입니다.
kebab-case: 케밥 꼬챙이를 생각하시면 됩니다. 단어/문장의 띄어쓰기 부분에 dash(-)를 넣어서 끼워져 있는 방식이며, 웹 URI 등과 iOS에서 아이콘 네이밍 작성에 사용합니다. camelCase가 Objective-C의 관례이지만 반드시 자산 이름에 적용해야 한다는 의미는 아닙니다.
camelCase: (단봉) 낙타 표기법이라고 하는데, 각 단어의 첫 문자를 대문자로 표기하고 붙여 쓰되, 맨 처음 문자는 소문자로 표기하는 방식입니다. 여담으로 카멜 케이스에 첫 문자도 대문자로 쓰는 경우를 파스칼 케이스(PascalCase)라고 합니다.
프로그래밍 언어에 따라서 외부에서 보이는 모든 변수(variable), constant, funtions/methods, structs/classes 등 각각 다른 케이스를 사용합니다. 엔지니어분들도 각각 다른 케이스의 선호도가 있다고 하네요. 이 아티클에서는 아이콘 등 drawable asset을 중심으로 한 명명법을 제안하기 때문에 안드로이드 아이콘 이름에선 snake case를 적용하였고, iOS와 웹에서는 kebal case로 표기하였습니다.
긴 글 읽어주셔서 감사합니다 ☻
