파일 이름 가.txt가 두 번 보이거나 다른 컴퓨터에서 같은 이름을 찾지 못한다면 한글의 유니코드 정규화 형태가 다른지 확인할 수 있습니다. 완성된 글자 하나로 표현한 이름과 여러 코드 포인트를 조합한 이름은 같은 모양으로 보이면서도 원문 문자열이 다를 수 있습니다. 이름을 정리하기 전에 파일 내용과 경로를 함께 보존해야 합니다.
먼저 구분할 조건
NFC와 NFD는 문자의 정규화 형태입니다. 가라는 한글 음절을 한 코드 포인트로 두는 방식과 구성 문자를 나누는 방식이 가능합니다. 폰트가 같은 모양으로 표시해도 코드 포인트 수·바이트·문자열 비교 결과가 달라질 수 있습니다. 운영체제와 파일시스템, ZIP 도구가 이름을 처리하는 조건도 다르므로 한 환경에서 만든 문자열 차이가 모든 파일 목록에서 같은 모습으로 나타난다고 가정하지 않습니다.
직접 확인한 예제와 방법
ZIP에 NFC의 가.txt와 NFD로 정규화한 이름을 넣었습니다. 실제 파일시스템에 비슷한 이름 두 파일을 만드는 대신 ZIP 내부 이름을 직접 저장해 이름 처리 조건을 분리했습니다. Python 3.12.14에서 두 내부 이름의 코드 포인트 수는 5와 6, 원문 비교는 다름, 둘을 NFC로 정규화한 비교는 같음이었습니다. 각 파일의 내용도 NFC DEMO와 NFD DEMO로 나눴습니다. 표시 이름의 차이와 내용의 차이를 혼동하지 않기 위한 가상 예제입니다.
| 확인 항목 | 관찰 결과 |
|---|---|
| 표시 이름 | 둘 다 가.txt처럼 보임 |
| 코드 포인트 수 | 5 / 6 |
| 원문 비교 | 다름 |
| NFC 정규화 후 | 같음 |
결과를 해석하는 기준
NFC 정규화 뒤 같아졌다고 두 파일의 내용까지 같은 것은 아닙니다. 이번 ZIP에는 서로 다른 내용이 들어 있습니다. 이름을 한 규칙으로 바꾸면 기존 경로가 충돌할 수 있으므로 어느 파일을 최종본으로 둘지 별도의 내용 비교가 필요합니다. 정규화를 중복 파일 제거 기능처럼 바로 적용하지 마세요.
같은 한글 이름에 대해 글자 수나 바이트 수가 다른 것도 손상의 단독 증거는 아닙니다. 저장 표현의 차이일 수 있습니다. 반대로 원문 이름이 다르다는 이유만으로 사용자에게 서로 다른 자료라고 확정해도 안 됩니다. 전체 경로·원문 이름·정규화 이름·파일 내용이라는 네 정보를 나눠 두면 이동 과정의 문제를 더 정확히 설명할 수 있습니다.
정규화한 이름이 겹쳐도 내용은 다를 수 있습니다
작성 예제로 NFC·NFD 두 파일이 같은 표시 이름을 쓰지만 초안과 승인본 내용이 다른 상황을 생각해 볼 수 있습니다. 이름을 같게 정리하는 규칙이 두 내용 중 어느 것을 보존해야 하는지는 결정하지 못합니다. 변경 전에 파일별 내용과 원문 이름을 대응시켜야 합니다.
| 상황 | 확인할 질문 | 먼저 할 일 |
|---|---|---|
| 정규화 후 이름이 같음 | 내용도 실제로 같은가 | 전체 내용 또는 해시 대조 |
| 동일 내용·다른 이름 | 두 경로가 업무에 필요한가 | 사용 목적을 확인 후 정리 |
| 다른 내용·같은 최종 이름 | 어느 자료가 최종본인가 | 서로 다른 이름으로 먼저 보존 |
파일명 정리는 내용을 선택하는 작업과 분리합니다. 충돌을 해결하기 전 원본을 덮어쓰지 않으면 정상 자료를 되찾을 여지가 남습니다.
내 자료에서 확인할 순서
- 문제 파일을 삭제하거나 일괄 이름 변경하지 말고 전체 경로와 원문 이름을 목록으로 보존합니다. ZIP 원본이 있으면 그대로 유지합니다.
- 코드 포인트나 정규화 형태를 확인할 수 있는 작은 비교에서 같은 표시 이름의 문자열 차이를 읽습니다.
- NFC 또는 업무에서 정한 방식으로 비교용 이름을 계산하되 실제 파일 이름은 아직 바꾸지 않습니다. 충돌 후보 목록을 먼저 만듭니다.
- 같아지는 이름의 파일 내용을 비교합니다. 크기만 보지 말고 필요한 문서 내용 또는 전체 해시로 동일 여부를 확인합니다.
- 이름 변경이 필요하면 충돌을 피할 새 경로·파일명을 정하고 사본에서 수행합니다. 원문 이름과 새 이름의 대응 기록을 남깁니다.
- 다른 컴퓨터와 ZIP 해제 과정에서도 경로·파일 개수·내용이 유지되는지 확인합니다. 어떤 앱에서 처리했는지도 기록합니다.
잘못 바꾸었거나 확인이 어려울 때
정규화 이름만 기준으로 하나를 덮어쓰면 다른 내용의 파일을 잃을 수 있습니다. 실제 파일시스템이 이름을 다시 정규화하는 환경에서는 두 이름을 그대로 별개 파일로 추출하는 것도 예상과 다를 수 있습니다. 원본 ZIP과 내용별 사본을 보존한 상태에서 소유자에게 필요한 최종 파일을 확인하는 편이 안전합니다.
정상 완료 기준
정상 완료는 필요한 파일 내용과 경로가 모두 보존되고, 정한 이름 규칙에서 충돌이 처리되며, 다른 환경에서 다시 읽어도 의도한 파일을 찾을 수 있는 상태입니다. 표시 이름만 정리된 상태로 끝내지 않습니다. 원문과 새 이름의 대응 목록은 다시 문제가 생길 때 필요한 복구 자료가 됩니다.
같은 예제를 다시 확인할 자료
ZIP 내부 이름과 Python의 정규화 결과를 확인했습니다. Windows 탐색기·macOS Finder·모든 압축 앱의 이름 처리 동작을 실측한 것은 아닙니다. 표시 형태가 같은 임의의 두 문자열이 항상 NFC/NFD 관계라는 뜻도 아닙니다.
- unicode-names.zip (228 bytes)
자료는 비민감 가상 예제입니다. 손상·불일치라고 표시한 파일은 차이를 확인하는 실험용이며 업무 원본으로 사용하지 않습니다. 파일 크기·SHA-256 목록으로 내려받은 원본을 확인할 수 있습니다.
같은 전체 경로가 중복된 ZIP의 결과는 중복 이름 ZIP 실험에서, 파일 내용의 차이는 해시 비교에서 확인할 수 있습니다.