← 전체 글

한글 파일명 자소분리 막는 법: 보내기 전 2분 체크리스트

한글 파일명 자소분리(보고서.xlsx가 ㅂㅗㄱㅗㅅㅓ.xlsx처럼 보이는 현상)를 비롯해 "파일 이름이 깨져서 왔어요"라는 답장을 받지 않으려면, 보내기 전에 다섯 가지만 확인하면 됩니다. 윈도우에서 쓸 수 없는 문자(\ / : * ? " < > |)가 없는지, 이름 앞뒤에 공백이나 마침표가 없는지, 전체 길이가 적당한지, 확장자가 붙어 있는지, 그리고 한글·일본어·악센트 문자가 맥이 흔히 쓰는 분해형(NFD)이 아니라 결합형(NFC)으로 저장되어 있는지입니다. 앞의 네 가지는 눈으로 보면 알 수 있습니다. 다섯 번째는 눈에 보이지 않기 때문에 가장 많은 혼란을 일으키고, FilenameFixer 같은 무료 도구가 몇 초 만에 처리해 주는 항목이기도 합니다.

이 글은 체크리스트 버전입니다. 유니코드 이론을 깊게 다루지 않고, 메일에 파일을 첨부하기 직전, 과제 제출 사이트에 올리기 직전, 동료에게 보낼 폴더를 압축하기 직전에 한 번 훑어보는 용도로 썼습니다.

한글 파일명 자소분리까지 잡는 다섯 가지 점검

보내려는 파일마다 아래 항목을 확인합니다. 대부분의 파일은 몇 초면 통과합니다.

  1. 평범한 문자만 사용. 한글, 영문, 숫자, 공백, 하이픈(-), 밑줄(_), 마침표, 괄호는 어디서나 안전합니다. \ / : * ? " < > | 중 하나라도 들어가면 윈도우는 저장을 거부하거나 이름을 조용히 바꿔 버립니다.
  2. 이름 앞뒤에 이상한 문자 금지. 이름 맨 앞이나 맨 끝에 공백이나 마침표가 오면 안 됩니다. 윈도우는 끝의 공백과 마침표를 잘라내기 때문에 보고서 .pdf가 받는 쪽에서는 다른 이름이 됩니다.
  3. 짧게 유지. 윈도우에는 폴더 이름을 포함한 전체 경로가 260자를 넘지 못하는 오래된 제한이 있습니다. 내 바탕화면에서는 멀쩡한 150자짜리 파일명이 C:\Users\홍길동\Downloads\2026년 1학기 프로젝트 자료\... 안에 들어가면 열리지 않을 수 있습니다.
  4. 확장자 확인. 3월_견적서.pdf여야지 3월_견적서나 3월_견적서.pdf.txt면 안 됩니다. macOS가 확장자를 숨기고 있다면 Finder에서 파일을 선택하고 Command-I(정보 가져오기)로 확인합니다.
  5. 한글·일본어·악센트 문자는 결합형(NFC)으로. 이것이 눈으로 확인할 수 없는 항목입니다. 김민수_과제.hwp나 보고서.xlsx라는 이름은 맥에서 똑같아 보이지만 두 가지 다른 바이트 순서로 저장될 수 있고, 그중 하나가 윈도우와 많은 업로드 폼에서 깨집니다.

다섯 항목을 모두 통과하면 그냥 보내면 됩니다. 5번이 의심스럽다면 계속 읽어 주세요.

맥·윈도우·웹 사이트 사이에서 파일명이 깨지는 이유

시스템마다 규칙이 다르고, 파일은 그 경계를 끊임없이 넘나듭니다.

사용할 수 없는 문자

macOS는 콜론(:)을 제외하면 거의 모든 문자를 파일명에 허용합니다(Finder에서 슬래시를 입력하면 내부적으로는 콜론으로 저장됩니다). 윈도우는 아홉 가지 문자를 아예 금지하고, CON, PRN, AUX, NUL, COM1, LPT1 같은 이름도 확장자 유무와 관계없이 거부합니다. nul.txt라는 파일은 윈도우에서 만들 수조차 없습니다. 실제로 이런 이름은 드물지만, 3분기 실적: 초안?.xlsx 정도는 맥 사용자가 별생각 없이 치는 이름입니다.

앞뒤 문자와 길이

윈도우는 파일을 저장할 때 끝에 붙은 공백과 마침표를 잘라냅니다. 메모 .txt가 들어 있는 zip은 메모.txt로 풀리면 다행이고, 압축 해제 자체가 실패할 수도 있습니다. 긴 경로도 같은 이유로 실패합니다. 제한은 내가 보는 파일 이름이 아니라 받는 사람 컴퓨터의 전체 경로에 적용됩니다.

보이지 않는 문제: NFD와 NFC

지원 문의가 가장 많이 들어오는 항목입니다. 유니코드는 한이라는 글자를 완성형 코드 하나(결합형, NFC)로 저장할 수도 있고, 자모 ㅎ, ㅏ, ㄴ을 이어 붙인 형태(분해형, NFD)로 저장할 수도 있습니다. é 같은 악센트 문자(e + 결합 악센트)나 탁점이 붙은 일본어 가나(が를 か + ゛로)도 마찬가지입니다.

macOS는 오래전부터 파일명을 분해형으로 기록해 왔습니다. 맥 화면에서는 정상으로 보이기 때문에 보내는 사람은 전혀 알아채지 못합니다. 반면 윈도우, 대부분의 웹 서버, 많은 업로드 폼은 결합형을 기대합니다. 그래서 파일이 도착하면 익숙한 장면이 벌어집니다.

  • 한글_보고서.pptx가 ㅎㅏㄴㄱㅡㄹ_ㅂㅗㄱㅗㅅㅓ.pptx처럼 자음과 모음이 따로 떨어져 보입니다.
  • 맥에서 압축한 zip을 윈도우에서 풀면 폴더 안 파일 이름이 전부 자소분리되어 있습니다.
  • 資料が.xlsx는 탁점이 글자에서 떨어져 보입니다.
  • Zoë_CV.pdf는 Zoe¨_CV.pdf처럼 보이거나 e 뒤에 네모 상자가 붙습니다.
  • 업로드 폼이 파일을 거부하거나, DB 기록과 맞지 않는 이름으로 저장합니다.

파일 자체는 멀쩡합니다. 이름만 받는 쪽 시스템이 정규화하지 않는 형태일 뿐입니다.

보내기 전에 파일명을 확인하고 고치는 순서

그대로 따라 할 수 있는 순서입니다. 1~3단계는 눈에 보이는 문제, 4~5단계는 NFD 문제를 다룹니다.

  1. Finder에서 눈에 띄는 것부터 수정. 파일을 선택하고 Return 키를 눌러 \ / : * ? " < > |를 지우고 하이픈이나 공백으로 바꿉니다. 이름 앞뒤의 공백과 마침표도 같은 방법으로 없앱니다.
  2. 확장자 확인. Finder에서 파일을 선택하고 Command-I를 누릅니다. 이름 및 확장자 항목에서 확장자가 있는지, 확장자 가리기가 이중 확장자 같은 실수를 숨기고 있지 않은지 봅니다.
  3. 긴 이름 줄이기. 파일명에 상대방 쪽 폴더 경로를 더해 200자 근처라면 지금 줄입니다. 2026-03-15 형식의 날짜와 짧은 프로젝트 코드를 쓰면 길지 않으면서도 정렬이 됩니다.
  4. 이름이 NFD인지 검사. 눈으로는 구분할 수 없습니다. 두 가지 빠른 방법이 있습니다.
    • 개발자: 터미널에서 python3 -c "import unicodedata,sys; print(unicodedata.is_normalized('NFC', sys.argv[1]))" "$(ls | head -1)"를 실행하면 파일 하나를 검사할 수 있고, 폴더 전체는 반복문으로 돌리면 됩니다. False가 나오면 분해형입니다.
    • 그 외: 무료 FilenameFixer 웹앱을 열고 텍스트 변환 칸에 파일명을 붙여 넣은 뒤 결과를 원본과 비교합니다. 도구가 무언가를 바꿨다면 원본이 NFD였다는 뜻입니다.
  5. NFC로 변환. 파일이 몇 개뿐이라면 브라우저에서 FilenameFixer 페이지에 끌어다 놓으면 결합형으로 일괄 이름 변경이 됩니다. 처리는 브라우저 안에서 로컬로 이루어지고 파일은 서버로 올라가지 않습니다. 이미 압축해 둔 폴더라면 ZIP 파일명 복원 도구가 압축 파일 안의 이름을 다시 써 줍니다(200MB까지). 개발자라면 파이썬의 unicodedata.normalize('NFC', name)이나 자바스크립트의 str.normalize('NFC')로 자기 스크립트에서 같은 작업을 할 수 있습니다.

5단계가 끝나면 4단계를 다시 실행합니다. 이제 결과가 바뀌지 않아야 정상입니다.

도구 없이 피하는 방법

내용상 가능하다면 파일명을 영문과 숫자로만 짓는 것이 가장 확실합니다. 견적서_3월.pdf 대신 quote_2026-03.pdf, 한글 제목은 파일명이 아니라 문서 안에 넣는 식입니다. 솔직히 말해 많은 사무용 파일에는 이 방법이 통합니다. 다만 이름 자체가 정보일 때는 쓸 수 없습니다. 스캔한 신분증, 과제 제출 파일에 붙는 학생 이름, 파일명을 DB와 대조하는 데이터셋 같은 경우입니다.

메일·카톡·업로드 사이트·동료별로 챙길 것

몇 가지 상황은 체크리스트에 따로 한 줄씩 적어 둘 만합니다.

메일과 카카오톡 첨부. 메일 클라이언트와 메신저는 대체로 저장된 파일명을 그대로 전달합니다. 맥에서 확인 없이 첨부하면 윈도우 쪽 상대는 자소분리된 이름을 받습니다. "이름이 깨져서 왔다"는 답장을 받은 뒤가 아니라 첨부하기 전에 이름을 고치거나 변환합니다.

과제 제출·채용·관공서 사이트. 대학 LMS, 채용 사이트, 관공서 업로드 폼은 NFD가 조용히 실패하는 곳입니다. 업로드는 성공한 것처럼 보이는데 저장된 이름이 깨져 있거나, "올바르지 않은 파일명"이라는 애매한 오류로 거부됩니다. 자주 올린다면 FilenameFixer 크롬 확장 프로그램이 웹사이트에 파일을 올리는 시점에 파일명을 자동으로 변환하므로, 체크리스트 5번을 매번 기억하지 않아도 됩니다. 어쩌다 한 번 올리는 경우라면 파일을 먼저 변환하는 것으로 충분합니다.

맥 쓰는 동료에게서 받은 파일. 맥을 쓰는 동료가 보낸 한글 파일이나 zip이 깨져서 도착했다면 받는 쪽에서 해결할 수 있습니다. 파일이나 zip을 웹앱에 넣고 변환하면 이름이 복원됩니다. 다음 파일부터 깨끗하게 오도록 이 체크리스트를 보낸 사람에게 전달해 두는 것도 좋습니다.

USB·외장하드·NAS 공유. 맥에서 복사해 넣은 파일을 윈도우에서 열 때도 같은 현상이 납니다. 공유 폴더에 넣기 전에 변환하거나, 윈도우 쪽에서 꺼낸 뒤 변환하면 됩니다.

개발자와 공유 저장소. 파일을 기록하는 스크립트에서는 파일명을 NFC로 정규화하고, 업로드를 받는 서버에서는 들어오는 이름을 검증합니다. 클라이언트가 결합형을 보내 줄 것이라고 기대하지 마세요. NFD를 거부하거나 도착 시 변환하는 필터 하나가 나중의 디버깅 시간을 크게 줄여 줍니다.

알아 둘 한계

파일명 체크리스트는 대부분의 문제를 막아 주지만 전부는 아닙니다. 시스템마다 추가 규칙이 있습니다. 예를 들어 SharePoint는 설정에 따라 #과 %를 거부하고, 오래된 FTP 서버는 ASCII 밖의 문자를 아예 처리하지 못하기도 합니다. NFC 변환은 분해형 문제만 고칩니다. 이름을 줄여 주거나, 금지 문자를 지우거나, 상대 쪽에서 이미 잘못 바뀐 이름을 되돌려 주지는 않습니다. 그리고 어떤 도구도 특정 사이트가 그 이름을 받아 줄 것이라고 약속할 수는 없습니다. 검증 규칙은 각 서비스가 정하기 때문입니다. 위 다섯 가지를 기본으로 삼고, 받는 쪽의 알려진 특이사항을 그 위에 얹으면 "파일 이름이 깨졌어요"라는 메일은 대부분 사라집니다.