문자 인코딩 깨짐 해결 가이드 - UTF-8 변환부터 깨진 한글 복구까지
메모장에서 글자가 ?나 □로 보이거나 한글이 외계어처럼 깨졌다면 인코딩 문제입니다. 원인 진단부터 UTF-8 변환, 깨진 파일 복구까지 단계별로 정리했습니다.
한글 파일을 열었더니 글자가 모조리 ㅁㅁㅁ로 보이거나, 외국에서 받은 텍스트 파일이 ?로 가득 차 있던 경험이 한번쯤 있으실 겁니다. 작업 도중 갑자기 깨진 글자를 마주하면 막막합니다. 다행히 대부분의 깨짐 현상은 원인만 알면 몇 분 안에 복구할 수 있습니다.
문자 인코딩이 무엇이고 왜 깨지는가
컴퓨터는 글자를 그대로 저장하지 않습니다. 모든 문자는 숫자(코드 포인트)로 변환된 뒤 0과 1로 저장됩니다. 이때 어떤 문자에 어떤 숫자를 배정할지 정한 규칙이 바로 문자 인코딩입니다. 한국어 환경에서 자주 마주치는 인코딩은 다음 세 가지입니다.
- UTF-8: 전 세계 모든 문자를 표현하는 표준. 웹과 리눅스, macOS의 기본값입니다
- EUC-KR: 한글 2바이트 인코딩. 과거 윈도우와 한국 사이트에서 널리 쓰였습니다
- CP949(MS949): EUC-KR의 확장판. 윈도우 기본 한글 인코딩입니다
저장할 때 사용한 인코딩과 열 때 사용한 인코딩이 다르면 글자가 깨집니다. UTF-8로 저장된 한글 파일을 EUC-KR이라고 가정하고 열면 글 같은 외계어가 나옵니다. 반대로 EUC-KR을 UTF-8로 열면 ?나 □ 기호가 나타납니다.
인코딩 깨짐의 99%는 "저장한 인코딩"과 "읽는 인코딩"의 불일치 때문입니다. 파일 자체가 망가진 것이 아니라 해석 방식이 틀렸을 뿐입니다.
깨진 글자 패턴으로 원인 찾는 법
깨진 형태만 봐도 어떤 인코딩 충돌인지 짐작할 수 있습니다. 가장 흔한 패턴을 정리하면 다음과 같습니다.
| 깨진 모양 예시 | 원본 인코딩 | 현재 해석 | 해결 방향 |
|---|---|---|---|
| 안녕하세요 → ????? | EUC-KR | UTF-8로 읽음 | EUC-KR로 다시 열기 |
| 안녕하세요 → 안녕하세요 | UTF-8 | Latin-1로 읽음 | UTF-8로 다시 열기 |
| 안녕하세요 → ¾È³çÇϼ¼¿ä | EUC-KR | Latin-1로 읽음 | EUC-KR로 다시 열기 |
| 맨 앞에 가 붙음 | UTF-8 with BOM | BOM 없이 읽음 | BOM 제거 후 저장 |
운영체제별 문자 인코딩 깨짐 해결 방법
윈도우
윈도우 메모장은 파일을 열 때 인코딩을 자동 감지하지만 정확도가 떨어집니다. 깨진 파일을 봤다면 다른 이름으로 저장 창에서 인코딩을 직접 바꿔보십시오. UTF-8, UTF-8 with BOM, ANSI(=CP949), UTF-16 LE 네 가지 중 맞는 것을 고르면 됩니다. 2019년 이후 윈도우 10/11 메모장은 기본 저장이 UTF-8로 바뀌었습니다. 옛날 텍스트 파일이 깨져 보인다면 ANSI로 다시 열어보면 보통 해결됩니다.
macOS
기본 텍스트 편집기는 UTF-8을 표준으로 사용합니다. EUC-KR 파일이 깨져 보이면 파일 → 다시 열기 → 인코딩 선택 메뉴를 활용하십시오. 또는 터미널에서 iconv -f EUC-KR -t UTF-8 input.txt > output.txt 명령어로 일괄 변환할 수 있습니다.
리눅스
리눅스는 iconv가 표준 도구입니다. 디렉터리 안의 파일을 모두 변환하려면 find . -name "*.txt" -exec iconv -f CP949 -t UTF-8 {} -o {}.utf8 \; 같은 한 줄 명령으로 처리할 수 있습니다.
코드 에디터에서 인코딩 변환하기
개발자나 블로거라면 코드 에디터에서 직접 인코딩을 다루는 경우가 많습니다. 주요 에디터별 처리법을 정리했습니다.
- VS Code: 우측 하단 상태바의 "UTF-8" 클릭 → "Reopen with Encoding" 또는 "Save with Encoding" 선택
- Notepad++: 메뉴 → 인코딩 → 인코딩 변환 → 변환할 인코딩 선택 후 저장
- Sublime Text: File → Reopen with Encoding 메뉴에서 인코딩 변경
- IntelliJ/WebStorm: 우측 하단 인코딩 표시 클릭 → Reload 또는 Convert 선택
웹페이지와 DB 인코딩 문제 해결
웹사이트나 데이터베이스에서 한글이 깨지는 경우는 보통 다음 세 지점 중 하나가 원인입니다.
- HTML 메타 태그 누락 또는 오류 (
<meta charset="UTF-8">) - 웹 서버 응답 헤더의 Content-Type charset 누락
- DB 테이블 컬럼의 charset 또는 collation 불일치
MySQL과 MariaDB에서는 utf8mb4 사용을 권장합니다. 일반 utf8은 3바이트까지만 지원해 이모지나 일부 특수문자가 깨집니다. 테이블 생성 시 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci로 지정하면 안전합니다. 이미 데이터가 깨진 상태로 저장됐다면 복구가 까다롭습니다. 일부 케이스는 "이중 인코딩"이라 불리는 현상으로, UTF-8을 Latin-1로 잘못 해석한 결과를 다시 UTF-8로 저장한 경우입니다. 원본 바이트 시퀀스가 남아 있다면 역변환이 가능하지만 손실된 비트는 복원되지 않습니다.
깨진 파일 복구가 어려운 경우
다음 상황에서는 완전 복구가 사실상 불가능합니다.
- 깨진 상태로 한 번이라도 저장(write)이 일어난 경우
- EUC-KR로 저장 가능하지 않은 문자(중국어, 일본어 일부, 이모지)가 변환 과정에서 ?로 치환된 경우
- 파일 일부 바이트가 손상되거나 잘려나간 경우
이런 사고를 막으려면 UTF-8을 표준으로 통일하는 것이 최선입니다. 새로 만드는 모든 텍스트, 코드, DB는 UTF-8(웹과 DB는 utf8mb4)로 시작하면 깨짐 사고를 사전에 차단할 수 있습니다.
인코딩 외에도 일상 작업에서 자주 쓰이는 간단한 온라인 도구가 많습니다. 영상이나 이미지 작업 시 자주 사용되는 화면 비율 계산기처럼, 작업 환경에 맞는 유틸리티 한두 개만 즐겨찾기 해두면 시간을 크게 아낄 수 있습니다.
지금 당장 할 일은 두 가지입니다. 첫째, 깨진 파일이 있다면 위 표의 패턴을 참고해 원본 인코딩을 추정하고 코드 에디터에서 "Reopen with Encoding"을 시도하십시오. 둘째, 앞으로 만드는 모든 파일은 UTF-8로 통일하십시오. 이 두 가지만 지켜도 인코딩 깨짐 문제의 90% 이상은 사라집니다.
