2016년 겨울, 쇼핑몰 오픈을 코앞에 둔 새벽 3시였습니다. 개발자인 저는 막 넘어온 이미지 파일을 서버에 올리고 있었죠. 그런데 파일명이 가관이었습니다. main_banner_final.jpg, main_banner_final2.jpg, 그리고 main_banner_real_final.jpg.
“대체 뭐가 진짜 최종이야?” 전화기는 꺼져 있고, 저는 식은땀을 흘리며 ‘real’이 붙은 파일을 업로드했습니다. 결과는? 땡! 틀렸습니다. 디자이너가 마지막에 수정한 건 ‘final2’였거든요. 이 웃지 못할 해프닝 이후, 저는 깨달았습니다. 파일명은 단순한 이름표가 아니라, 동료에게 보내는 ‘메시지’라는 것을요.
1. ‘공백(Space)’은 죄악이다: Snake_case의 미학
가장 먼저 버려야 할 습관은 파일명에 띄어쓰기를 넣는 것입니다. main banner 01.jpg라고 저장하는 순간, 개발자의 코드로 들어가면 main%20banner%2001.jpg라는 괴상한 문자로 변환됩니다. 이는 링크 깨짐의 주범이 되죠.
우리는 두 가지 약속 중 하나를 선택해야 합니다.
- ✅ 스네이크 표기법 (Snake_case): 단어 사이를 언더바(_)로 연결합니다. (예:
icon_search_active.png) – 가독성 추천! - ✅ 케밥 표기법 (Kebab-case): 단어 사이를 하이픈(-)으로 연결합니다. (예:
icon-search-active.png) – URL 친화적!
“솔직히 말해서, 개발자들은 하이픈(-)과 언더바(_) 논쟁으로 밤을 새우기도 합니다. 하지만 중요한 건 ‘일관성’입니다. 디자이너분이 언더바를 쓰기로 했다면 끝까지 언더바만 써주세요. 섞어 쓰는 순간 혼란은 시작됩니다.”
2. 무엇(What) + 어디(Where) + 상태(State)
파일명만 보고도 이 이미지가 어디에 쓰이는지 알 수 있어야 합니다. image01.jpg 같은 성의 없는 이름은 최악입니다. 제가 추천하는 ‘절대 실패하지 않는 공식’은 다음과 같습니다.
분류_위치(이름)_상태_버전.확장자
| 순서 | 설명 | 예시 |
|---|---|---|
| 1. 분류 | 어떤 종류인가? | btn, bg, ico, img |
| 2. 위치 | 무엇인가? | submit, main, close |
| 3. 상태 | 어떤 상황인가? | default, hover, on |
합쳐보면 이렇게 됩니다: btn_submit_hover_v1.png. 개발자는 이걸 보자마자 “아, 전송 버튼에 마우스를 올렸을 때 나오는 이미지구나”라고 0.1초 만에 파악합니다.
3. ‘Final’ 금지어 지정과 버전 관리
제발 final, real, last, zzin 같은 단어는 쓰지 마세요. 디자인은 프로젝트가 끝날 때까지 끝난 게 아닙니다. 대신 숫자(Versioning)를 믿으세요.
- 🚫 나쁜 예:
logo_final.png,logo_final_new.png - ✅ 좋은 예:
logo_v1_0.png(초안),logo_v1_1.png(색상 수정),logo_v2_0.png(형태 변경)
💡 코드캠의 실전 TIP
오래된 버전을 지우지 마세요. 클라이언트는 꼭 “아까 보여준 두 번째 시안이 더 나은 것 같아요”라고 말하거든요. 대신 [z_Archive]라는 폴더를 만들어 구버전 파일들을 몰아넣으세요. 폴더명 앞에 ‘z’를 붙이면 정렬 순서상 맨 뒤로 가서 시야를 방해하지 않습니다.
마치며
파일 이름을 정하는 규칙은 단순한 ‘정리 정돈’이 아닙니다. 그것은 동료의 시간을 아껴주려는 배려이자, 프로페셔널함을 증명하는 가장 기초적인 태도입니다.
오늘부터 당장 팀원들과 모여 “우리 팀만의 네이밍 규칙”을 정해보는 건 어떨까요? 그 작은 약속 하나가 여러분의 퇴근 시간을 지켜줄 겁니다.
혹시 팀 내에서 파일명 때문에 겪었던 황당한 에피소드가 있으신가요? 댓글로 공유해주시면 같이 웃고(또는 울고) 해결책도 고민해 드리겠습니다!
