웹 파일명, 꼭 '영어 소문자'로 통일해야 할까?
영어 소문자로 많은 것들이 해결된다
웹사이트에 이미지나 동영상 파일을 올릴 때, "파일명은 반드시 영어 소문자로 통일하고 띄어쓰기는 하이픈(-)을 사용하라"는 조언을 들어본 적이 있을 것이다.
문득 의문이 든다.
MyPhoto.JPG처럼 대문자를 쓰거나 강아지사진. jpg처럼 한글 파일명을 쓰면 정말 큰일이 나는 걸까? 개발 환경(로컬)에서는 아무 문제 없이 잘 보이는데 왜 굳이 이런 규칙을 따라야 할까?
만약 별생각 없이 올린 파일이 어느 날 서버에서 보이지 않는 '엑박(X-Box)'으로 뜨거나, 링크가 깨지는 경험을 했다면 이 규칙의 중요성을 짐작할 수 있다.
이 글에서는 이것이 단순히 오래된 개발자들의 깐깐한 고집인지, 아니면 여러 시스템을 거쳐야 하는 '웹'이라는 환경의 특수성에서 비롯된 합리적인 '업계 표준(Best Practice)'인지, 그 기술적인 이유를 명확히 파헤쳐 본다.
1. 영문 소문자를 '강력히' 권장하는 이유
파일명을 영문 소문자로 통일하려는 이유는 크게 세 가지로 요약할 수 있다.
1) 운영체제(OS) 간의 호환성: 가장 결정적인 이유
이것이 가장 중요하고 결정적인 이유이다.
Windows (내 개발 PC): 파일명의 대소문자를 구분하지 않는다. (image.jpg와 Image.jpg를 같은 파일로 인식)
Linux/Unix (대부분의 웹 서버): 파일명의 대소문자를 구분한다. (image.jpg와 Image.jpg를 다른 파일로 인식)
대부분의 개발자는 Windows PC에서 웹사이트를 개발하고, 완성된 파일은 Linux 환경의 서버로 전송(배포)한다.
개발자가 자신의 Windows PC에서 Image.jpg (대문자 I) 파일을 저장하고, HTML 코드에는 (소문자 i)라고 썼다고 가정해 보자.
<img src="image.jpg">
로컬 환경(Windows): 이미지가 아주 잘 보인다. (Windows가 대소문자를 구분하지 않으므로) 운영 서버(Linux): 이미지가 보이지 않는다. (404 Not Found, 엑박). (Linux는 image.jpg 파일을 찾지만 실제 파일은 Image.jpg이므로 "파일 없음"으로 처리)
이런 사소한 실수로 인해 웹사이트 이미지가 깨지는 현상이 빈번하게 발생한다. 모든 파일명을 처음부터 '영문 소문자'로 통일하면, 이런 시스템 간의 차이에서 오는 문제를 원천적으로 차단할 수 있다.
2) 비영문자(한글 등)의 URL 인코딩 문제
URL(웹 주소)은 본래 ASCII(아스키) 문자셋(영문, 숫자, 일부 특수문자)을 기반으로 설계되었다. (참고: ASCII는 'American Standard Code for Information Interchange'의 약자로, '미국 정보 교환 표준 부호'를 의미한다.)
한글, 한자, 일본어, 공백, 기타 특수문자 등 비(非) ASCII 문자는 URL에서 직접 사용할 수 없으며, '퍼센트 인코딩(Percent-encoding)'이라는 과정을 거쳐 알아볼 수 없는 문자열로 자동 변환된다.
강아지 사진.jpg → %EA%B0%95%EC%95%84%EC%A7%80%20%EC%82%AC%EC%A7%84.jpg
이렇게 변환된 URL은 다음과 같은 문제를 일으킨다.
가독성 저하: URL이 매우 길고 지저분해져 사용자가 링크를 복사하거나 공유할 때 신뢰하기 어렵다.
시스템 오류: 일부 오래된 시스템, 브라우저, 또는 서버 환경에서는 이 인코딩 된 주소를 제대로 해석하지 못해 파일을 찾지 못하는 오류가 발생할 수 있다.
3) 관리의 일관성과 휴먼 에러 방지
팀 단위로 작업하거나, 시간이 지난 뒤 프로젝트를 유지보수할 때 명확한 파일명 규칙이 없으면 혼란이 생긴다.
MyImage.png
my_image.png
my-image.png
myimage.png
어떤 파일은 대문자로 시작하고, 어떤 파일은 언더스코어(_)를 쓰는 등 중구난방이 되면, 개발자가 파일 경로를 입력할 때 "그 파일 이름이 대문자였나? 소문자였나?"를 매번 고민해야 한다.
'모든 파일명은 영문 소문자로 한다'는 단순한 규칙은 이런 고민을 없애 휴먼 에러(Human Error, 사람이 실수할 가능성)를 극적으로 줄여준다.
2. 띄어쓰기 처리: 하이픈(-) vs. 언더스코어(_)
그렇다면 띄어쓰기는 어떻게 처리해야 할까? 띄어쓰기 역시 %20으로 인코딩되므로 파일명에 사용하지 않는 것이 좋다.
이를 대체하기 위해 '하이픈(-)'과 '언더스코어(_)'가 널리 쓰이며, 이 둘은 각기 명확한 장단점을 가진다.
1) 하이픈 (Hyphen, '케밥 케이스')
예시: my-new-image.jpg
방식: 단어 사이를 하이픈(-)으로 연결한다.
[장점]
검색 엔진 최적화 (SEO): 구글을 비롯한 대부분의 검색엔진은 하이픈을 명확한 '단어 구분자'로 인식한다. 즉, my-new-image를 "my", "new", "image" 세 단어로 해석한다. 이는 사용자가 "new image" 등으로 검색했을 때 내 파일이나 게시물이 노출될 확률을 높여준다.
웹 표준 및 가독성: URL에서 공백을 대체하는 가장 일반적인 방식이며, 많은 웹 프레임워크(워드프레스 등)의 표준 방식이다. 시각적으로도 깔끔하다는 인식이 있다.
[단점]
코드 에디터 선택 불편: (개발자에게는 치명적일 수 있음) 코드 에디터에서 my-new-image 파일명을 더블 클릭하면, 하이픈이 단어 구분자로 인식되어 my, new, image가 각각 나뉘어 선택된다. 파일명 전체를 한 번에 복사하기 불편하다.
2) 언더스코어 (Underscore, '스네이크 케이스')
예시: my_new_image.jpg
방식: 단어 사이를 언더스코어(_)로 연결한다.
[장점]
코드 에디터 선택 편의성: my_new_image를 더블 클릭하면, 대부분의 에디터가 이 문자열 전체를 하나의 단어로 인식하여 한 번에 선택해 준다. 코드 내에서 파일명을 자주 복사/붙여 넣기 하는 개발자에게는 이 편의성이 매우 크다.
[단점]
검색 엔진 최적화 (SEO): 과거 검색엔진은 언더스코어를 '단어 연결자'로 인식하는 경향이 있었다. my_new_image를 "mynewimage"라는 하나의 단어로 해석할 수 있어, SEO 측면에서 하이픈보다 불리했다. (최근에는 구글이 이를 잘 처리한다고는 하나, 여전히 공식적으로 권장하는 방식은 하이픈이다.)
URL 표준: 웹 URL 표준으로는 하이픈 방식보다 덜 선호된다.
3. 결론: 가장 안전하고 합리적인 선택
'웹 파일명'은 단순히 내 컴퓨터의 파일을 식별하는 이름을 넘어, URL의 일부이자, 검색엔진이 수집하는 정보가 된다.
이러한 '웹 환경'의 특수성을 모두 고려할 때, 가장 안전하고 합리적인 '업계 표준'은 다음과 같이 정리할 수 있다.
OS 호환성 오류를 원천 차단하기 위해 '영문 소문자'를 사용한다.
SEO와 웹 표준을 준수하기 위해 띄어쓰기 대신 '하이픈(-)'을 사용한다.
물론, '언더스코어(_)'가 주는 개발 편의성(더블 클릭으로 전체 선택)은 매우 매력적인 장점이다.
따라서 만약 SEO가 중요하지 않고 팀 내부적으로만 사용하는 파일이라면 언더스코어를 사용해도 무방하다. 하지만 불특정 다수에게 노출되는 블로그 게시물이나 웹사이트의 공개 파일이라면, '영문 소문자 + 하이픈' 조합이 여전히 가장 강력하게 권장되는 표준 방식이다.
