압축 파일 한글명이 깨지는 이유 및 해결법

압축을 풀었더니 파일 내용은 멀쩡한데 이름만 ???나 낯선 기호로 바뀐 경험, 한 번쯤 있으실 겁니다. 저도 외부 업체에서 받은 프로젝트 ZIP을 풀다가 똑같은 상황을 겪었는데, 처음엔 파일 자체가 손상된 줄 알고 꽤 당황했습니다. 알고 보니 파일 내용이 아니라 이름 정보를 해석하는 방식이 달랐을 뿐이었습니다. 이 글에서는 그 원인과 제가 직접 해결한 순서를 정리했습니다.

파일명이 왜 깨지는가 — 인코딩 충돌의 배경

파일이 손상된 게 아닌데 이름만 깨진다는 게 처음엔 직관적으로 이해가 안 됐습니다. ZIP 규격을 들여다보고 나서야 납득이 됐는데, 결론은 단순합니다. ZIP 파일 안에는 파일의 실제 내용과 파일명 같은 메타데이터가 서로 별도의 공간에 저장되어 있습니다. 그래서 내용은 온전해도 이름 정보만 엉킬 수 있습니다.

핵심은 문자 인코딩(Character Encoding)입니다. 여기서 문자 인코딩이란 한글이나 영문 같은 문자를 컴퓨터가 저장·처리할 수 있는 숫자 코드로 변환하는 규칙을 말합니다. ZIP 규격은 오래된 시대에 설계되어, 파일명에 쓸 인코딩을 딱 하나로 못 박지 않았습니다. 현재 표준에서는 언어 인코딩 플래그(Language Encoding Flag)가 설정된 경우 UTF-8로 처리하도록 정하고 있습니다. 언어 인코딩 플래그란 "이 파일명은 UTF-8로 쓰여 있다"는 표시를 ZIP 헤더 안에 넣는 방식입니다.

문제는 이 플래그 없이 만들어진 오래된 파일입니다. 예전 한국어 Windows 환경에서 만든 ZIP은 CP949라는 코드 페이지로 파일명을 기록했습니다. CP949란 한국어 Windows가 오랫동안 사용해온 한국어 전용 문자 코드 체계입니다. 압축을 만든 쪽은 CP949로 썼는데, 받는 쪽 프로그램이 이를 UTF-8이나 다른 문자표로 읽으면 한글 바이트가 엉뚱한 기호로 둔갑합니다. 제가 직접 겪었을 때도 외부 업체 담당자는 자기 화면에서는 아무 이상 없다고 했고, 저만 깨져 보이는 상황이었습니다. 전형적인 송수신 인코딩 불일치 케이스였습니다.

한 가지 더 알아두면 좋은 점이 있습니다. "???로 바뀌는 현상"과 "글자가 ㄱ, ㅏ처럼 자모 단위로 분리되는 현상"은 원인이 완전히 같지 않습니다. 후자는 유니코드 정규화(Unicode Normalization) 방식 차이와 관련될 수 있습니다. 유니코드 정규화란 같은 한글 글자를 완성형(NFC)으로 저장하느냐, 자모를 조합한 형태(NFD)로 저장하느냐의 차이인데, macOS는 기본적으로 NFD 방식을 사용해 Windows에서 만든 파일을 자모 분리로 보여주는 경우가 생깁니다. 단순히 인코딩 하나만 바꿔서 항상 해결된다고 단정하면 안 되는 이유가 여기 있습니다.

실제 손상인지 인코딩 문제인지 구분하는 법

일반적으로 파일명이 깨지면 압축 자체에 문제가 생겼다고 생각하는 분들도 있는데, 저는 그게 아닐 가능성을 먼저 확인해야 한다고 봅니다. 두 가지를 병행하면 대부분 원인을 좁힐 수 있었습니다.

첫 번째는 파일 내용 확인입니다. 깨진 이름의 파일을 직접 열어 봤을 때 PDF, 이미지, 문서가 정상적으로 표시되고 파일 크기도 자연스럽다면 인코딩 해석 문제일 가능성이 높습니다. 제가 직접 해봤는데, 이름은 알아볼 수 없는 기호 덩어리였지만 PDF를 더블클릭하자 도면이 멀쩡하게 열렸습니다. 그 시점에서 "아, 내용은 살아 있구나" 확신이 생겼습니다.

두 번째는 압축 해제 중 오류 메시지 확인입니다. CRC 오류(CRC Error)가 대표적인 신호입니다. CRC 오류란 압축 전후 데이터의 체크섬 값이 달라 실제 데이터가 변형됐음을 의미하는 오류 코드입니다. 이 외에도 "예상치 못한 파일 끝(Unexpected End of File)"이나 "손상된 헤더(Corrupted Header)" 메시지가 뜨거나, 압축을 푼 뒤 파일 자체가 아예 열리지 않는다면 다운로드 과정에서 일부가 누락됐거나 압축 데이터 자체가 손상된 것입니다. 이 경우 인코딩을 바꿔도 내용은 복구되지 않습니다. 같은 파일을 다시 내려받거나 발신자에게 원본을 확인해 달라고 먼저 요청하는 편이 맞습니다.

또 하나 확인해볼 부분이 있습니다. 여러 프로그램에서 열어 봤을 때 반응이 다른지입니다. 최신 압축 프로그램에서는 파일명이 정상으로 보이는데, 오래된 기본 압축 기능에서만 깨진다면 그건 해제 프로그램의 해석 방식 차이입니다. 반대로 어떤 프로그램에서 열어도 똑같이 깨진다면 ZIP을 만든 단계에서 이미 잘못 기록됐을 가능성이 높습니다.

손상 vs 인코딩 문제 — 판단 기준 정리

• 파일을 열었을 때 내용이 정상으로 보이고 크기도 자연스러움 → 인코딩 해석 문제 가능성 높음
• 압축 해제 중 CRC 오류, 손상된 헤더 메시지 출력 → 실제 데이터 손상 의심
• 최신 프로그램에서는 정상, 구버전에서만 깨짐 → 해제 도구의 인코딩 해석 차이
• 모든 프로그램에서 동일하게 깨짐 → ZIP 생성 단계의 인코딩 기록 오류 가능성

원본 ZIP부터 보존하고 복구하는 실전 순서

제가 당시 저질렀던 실수가 하나 있습니다. 급한 마음에 깨진 이름의 파일 몇 개를 내용에 맞게 손으로 직접 바꿨습니다. 비슷한 도면이 많아서 순번을 확신하기 어려웠고, 계속하다 보면 오히려 자료를 뒤섞을 것 같아 작업을 멈췄습니다. 그때 멈춘 게 다행이었습니다.

가장 먼저 해야 할 일은 원본 ZIP 파일을 복사해 별도로 보관하는 것입니다. 이름이 깨진 파일들을 수십 개 수동으로 고치다 보면 원래 폴더 구조와의 대응 관계를 잃기 쉽습니다. 원본 ZIP은 손대지 말고, 복사본으로만 작업해야 돌아갈 곳이 생깁니다.

다음으로 최신 버전의 다른 압축 프로그램으로 원본 ZIP을 열어 봅니다. 프로그램이 파일명 문자 인코딩 선택 기능을 제공한다면, 생성 환경에 맞는 항목으로 바꿔 미리보기 결과를 비교해 봅니다. 오래된 한국어 Windows 환경에서 만든 ZIP이라면 CP949 또는 EUC-KR 코드 페이지로 해석했을 때 이름이 살아나는지 확인할 수 있습니다. 솔직히 이건 예상 밖이었습니다. 프로그램만 바꿔 다시 풀었더니 상당수 파일명이 그냥 복원됐습니다. 설정 하나의 차이였던 겁니다.

중요한 건 아무 인코딩이나 반복 적용한 뒤 같은 폴더에 덮어쓰지 않는 것입니다. 매번 별도의 시험 폴더를 만들어 결과를 비교해야 합니다. 그렇지 않으면 어떤 인코딩에서 어떤 결과가 나왔는지 추적이 불가능해집니다.

다른 프로그램으로도 복구가 안 되는 폴더는 발신자에게 최신 압축 도구로 다시 묶어 달라고 요청하는 것이 가장 빠릅니다. 가능하면 한글 이름의 작은 시험 파일 하나를 먼저 보내달라고 해서 수신 환경에서 정상인지 먼저 확인하면 좋습니다. 저는 이후 외부로 자료를 보낼 때 항상 이 방식을 씁니다. 한 번의 확인이 수백 개 파일을 다시 정리하는 시간을 막아 줍니다.

이미 일부를 직접 고친 경우라면, 새로 받은 압축본과 대조해 잘못 바꾼 항목이 없는지 검토한 뒤 따로 보관하는 것이 안전합니다. ZIP 파일의 구조와 인코딩에 관한 공식 규격은 출처: PKWARE APPNOTE(ZIP 공식 규격)에서 확인할 수 있습니다. 유니코드 정규화 기술 표준은 출처: Unicode Consortium, UAX #15에 공개되어 있습니다.

자주 묻는 질문

Q. ZIP 파일 이름을 영문으로 바꾸면 내부 파일명 깨짐이 해결되나요?

A. 해결되지 않습니다. ZIP 파일의 바깥쪽 이름과 내부에 기록된 각 항목의 파일명은 서로 완전히 다른 정보입니다. 내부 파일명 깨짐은 ZIP 안에 저장된 문자 인코딩 정보의 해석 방식을 바꿔야 해결됩니다. 바깥 이름을 바꾸는 것은 내부 메타데이터에 아무 영향을 주지 않습니다.

Q. 파일명만 깨지면 파일 내용도 손상된 건가요?

A. 일반적으로는 그렇지 않습니다. 제 경험상 파일명과 파일 내용은 ZIP 안에서 별도로 저장되기 때문에, 이름만 깨진 경우 파일을 직접 열어보면 내용은 정상인 경우가 많습니다. 다만 압축 해제 중 CRC 오류나 손상된 헤더 메시지가 나왔다면 실제 데이터 손상을 따로 확인해야 합니다.

Q. macOS에서 압축 풀면 한글 파일명이 자모 분리되는 이유가 뭔가요?

A. 이건 인코딩이 아니라 유니코드 정규화 방식의 차이 때문입니다. macOS는 기본적으로 NFD 방식을 사용해 한글을 자모 단위로 나눠 저장하는 반면, Windows는 NFC 방식으로 완성형 글자를 저장합니다. 그래서 Windows에서 만든 ZIP을 macOS 기본 유틸리티로 풀면 "한글"이 "ㅎㅏㄴㄱㅡㄹ"처럼 분리돼 보일 수 있습니다. 이 경우 단순 인코딩 변환으로는 해결이 안 되고, 정규화 방식을 처리해주는 도구를 사용해야 합니다.

Q. 깨진 파일명을 일일이 손으로 고쳐도 되나요?

A. 파일 수가 적다면 가능하지만, 제 경험상 비슷한 파일이 많을 때는 수동 작업이 오히려 순서와 구조를 뒤섞는 위험이 있습니다. 반드시 원본 ZIP을 따로 보관한 상태에서 진행해야 하고, 직접 고친 결과는 나중에 복구된 압축본과 대조해 검토하는 절차가 필요합니다.

결론

압축파일을 주고받을 때 중요한 건 압축률이 아니라, 이름과 폴더 구조가 받는 쪽에서도 그대로 유지되는가입니다. 파일 내용이 살아 있어도 이름이 깨지면 버전, 날짜, 순번을 확인하는 데 훨씬 많은 시간이 들고, 제가 겪었듯이 자료를 잘못 정리할 위험도 생깁니다.

이 문제를 특정 운영체제 탓으로 단순화하면 같은 실수가 반복됩니다. 실제로는 생성 도구와 해제 도구가 어떤 문자 인코딩 정보를 주고받았는가의 문제입니다. 만드는 쪽과 받는 쪽 모두 최신 도구를 쓰고, 한글 시험 파일 하나로 먼저 확인하는 작은 절차가 수백 개 파일을 다시 정리하는 시간을 막아줍니다. 대외 전달 자료라면 ZIP과 함께 파일 목록을 PDF나 텍스트로 따로 제공하는 것도 현실적인 예방책이라고 생각합니다.