엑셀 CSV 한글 깨짐, 원래 글자로 되살리기

엑셀이나 편집기에서 CSV·텍스트 파일을 열었더니 한글이 '뷁뷁'이나 '���'로 깨져 보인다면, 파일이 손상된 게 아닙니다. 글자를 바이트로 바꿔 저장할 때 쓴 규칙(인코딩)과, 그 바이트를 다시 글자로 읽을 때 쓴 규칙이 서로 달라서 생긴 일입니다.

규칙만 맞춰 다시 읽으면 원래 글자가 그대로 돌아옵니다. 이 글은 왜 깨지는지를 인코딩 원리로 설명하고, 어떤 인코딩으로 저장됐는지 스스로 판별해 되살리는 방법까지 정리합니다.

요약 ① 한글 깨짐은 파일이 망가진 게 아니라, 저장할 때 쓴 인코딩과 열 때 쓴 인코딩이 다를 때 나타나는 증상입니다. ② 옛 윈도우 프로그램이 만든 파일은 대개 CP949(메모장이 'ANSI'라 부르는 것)이고, 요즘 편집기·웹·엑셀 내부는 UTF-8이 기본입니다. ③ 같은 바이트를 두 인코딩으로 동시에 읽어 깨짐 글자(치환문자 U+FFFD, 화면엔 검은 마름모 물음표)가 더 적은 쪽을 고르면, 그 파일이 어떤 인코딩인지 알아낼 수 있습니다.

왜 이런 일이 생기나 — 은행 CSV를 내려받았을 때

은행·카드사 사이트에서 거래내역을 CSV로 내려받거나, 예전 회계·급여 프로그램에서 데이터를 내보낸 상황을 떠올려 보겠습니다. 파일을 더블클릭하면 엑셀이 열리는데, 날짜와 숫자는 멀쩡한데 한글 열만 '뷁·꽭·븳' 같은 엉뚱한 글자로 가득합니다.

같은 파일을 VS Code나 메모장으로 열면 이번엔 검은 마름모 물음표가 줄줄이 나오기도 합니다. 증상이 두 가지로 보이지만 원인은 하나입니다.

이런 파일은 대개 옛 윈도우 프로그램이 만든 것이라, 한글이 CP949 방식으로 저장돼 있습니다. 그런데 요즘 프로그램은 파일을 UTF-8로 가정하고 읽습니다. 저장한 규칙과 읽는 규칙이 어긋나면서 글자가 깨지는 것입니다.

인코딩이 뭐길래: 글자를 담는 '바이트 규칙서'

컴퓨터는 글자를 그대로 저장하지 못합니다. 모든 글자는 숫자(바이트)로 바꿔서 저장하고, 읽을 때 다시 글자로 되돌립니다. 이 '글자 ↔ 바이트' 변환 규칙서가 바로 인코딩입니다.

문제는 규칙서가 하나가 아니라는 점입니다. 같은 '한'이라는 글자도 규칙서마다 다른 바이트로 저장됩니다.

'한' 글자를 저장하면
 CP949 규칙서: c7 d1        (2바이트)
 UTF-8 규칙서: ed 95 9c     (3바이트)

그래서 CP949로 저장한 파일을 UTF-8 규칙서로 읽으면, 컴퓨터는 c7 d1을 UTF-8 규칙에 맞는 글자로 해석하려다 실패합니다. 이렇게 읽어낼 수 없는 자리에 표시되는 게 치환문자 U+FFFD, 화면에는 검은 마름모 물음표로 보이는 글자입니다. 그래서 물음표 기호가 줄줄이 뜹니다.

반대로 UTF-8로 저장한 파일을 CP949 규칙서로 읽으면(엑셀이 CSV를 열 때 한국어 윈도우에서 벌어지는 일), 3바이트짜리 한글이 2바이트씩 엉뚱하게 잘려 읽힙니다. 그 결과가 '뷁·븞' 같은, 존재는 하지만 뜻이 없는 한글 음절의 나열입니다.

정리하면 깨짐은 두 방향으로 나타납니다. 파일 자체는 그대로이고, 읽는 규칙만 바꾸면 원래 글자가 돌아옵니다.

CP949·EUC-KR·ANSI·UTF-8·BOM은 각각 무슨 뜻인가

용어가 뒤섞여 있어 헷갈리기 쉽습니다. 하나씩 사실만 짚어보겠습니다.

• UTF-8: 전 세계 문자를 담는 유니코드를 바이트로 저장하는 국제 표준입니다. 영문·숫자는 1바이트, 한글은 글자당 3바이트로 저장합니다. 오늘날 웹·맥·리눅스·최신 윈도우의 기본값입니다.
• CP949: 마이크로소프트가 쓰던 한글 규격으로, 현대 한글 11,172자를 모두 2바이트로 담습니다. 옛 윈도우 프로그램이 한글을 저장하던 기본 방식이며, 통합 완성형(UHC)이라고도 부릅니다.
• EUC-KR: CP949의 이전 표준으로, 자주 쓰는 한글 2,350자만 2바이트로 담았습니다. '뷁'·'똠'처럼 이 목록에 없는 글자를 표현하지 못해서, 그 빈자리를 채워 확장한 것이 CP949입니다. 그래서 CP949는 EUC-KR을 포함합니다.
• ANSI: 윈도우 메모장의 '다른 이름으로 저장'에 나오는 인코딩 이름입니다. 실제로는 'ANSI'라는 국제 표준이 아니라 '그 컴퓨터의 기본 코드페이지'를 뜻하는 마이크로소프트식 별칭이고, 한국어 윈도우에서 그 기본값이 곧 CP949입니다. 즉 한국에서 '메모장 ANSI 저장'은 사실상 CP949 저장입니다.
• BOM(Byte Order Mark): 파일 맨 앞에 붙는 3바이트 표식(ef bb bf)으로, '이 파일은 UTF-8'이라는 서명 역할을 합니다. 엑셀은 이 표식이 없으면 CSV를 CP949로 읽어 UTF-8 한글을 깨뜨립니다.

이 다섯 용어만 정리해 두면, 아래에서 '어떤 규칙서로 읽느냐'가 왜 결과를 바꾸는지 이해하기 쉽습니다.

도구 없이 직접 되살리는 방법

전용 도구 없이도 되살릴 수 있습니다. 상황별로 아래 공식 기능을 쓰면 됩니다.

• 엑셀에서 CSV가 깨질 때는 파일을 더블클릭하지 말고 가져오기로 여는 것이 정석입니다. '데이터' 탭 → '텍스트/CSV에서'(또는 텍스트/CSV 가져오기) → 파일 선택 → 미리보기 창의 '파일 원본(File Origin)' 드롭다운에서 인코딩을 고릅니다. 여기에는 '949: 한국어(Windows)'와 '65001: 유니코드(UTF-8)'가 있으니, 한글이 제대로 보이는 항목을 고른 뒤 불러오면 됩니다.
• VS Code로 열었을 때는 하단 상태 표시줄의 현재 인코딩(예: UTF-8)을 클릭 → 'Reopen with Encoding' → 'Korean (Windows 949)'를 고릅니다. 글자가 돌아오면 다시 그 자리를 눌러 'Save with Encoding' → 'UTF-8'로 저장하면 UTF-8 파일이 됩니다.
• 윈도우 메모장은 최신 버전이라면 파일을 열었을 때 하단에 현재 인코딩을 보여주고, '다른 이름으로 저장' 창 아래 인코딩 드롭다운에서 UTF-8을 골라 다시 저장할 수 있습니다. 다만 메모장은 여는 인코딩을 강제하는 기능이 약해, 이미 깨진 채로만 보일 수도 있습니다.
• 명령줄이 익숙하다면 맥·리눅스에 기본 포함된 iconv 한 줄로 변환할 수 있습니다.

iconv -f cp949 -t utf-8 원본.csv > 결과.csv

여기서 어려운 지점은 '이 파일이 CP949인지 UTF-8인지'를 먼저 알아야 한다는 것입니다. 위 방법들은 인코딩을 사람이 하나씩 바꿔가며 눈으로 맞혀야 합니다. 파일이 여러 개라면 이 판별을 자동으로 해주는 편이 빠릅니다.

저희 도구로 확인해 보겠습니다.

직접 해보기 →

이 도구는 드롭한 파일을 브라우저 안에서만 읽어(서버로 올라가지 않습니다, 20MB까지), 같은 바이트를 UTF-8과 CP949 두 규칙서로 동시에 디코딩합니다. 각 결과에서 치환문자 비율을 세어, 파일 앞에 UTF-8 BOM이 있으면 UTF-8을, 없으면 깨짐 비율이 더 낮은 쪽을 '추천 인코딩'으로 자동 판별하고 그쪽에 초록 체크(✅)를 붙입니다. 이후 그 인코딩으로 읽어 UTF-8로 다시 저장하며, 저장 파일명에는 원본 뒤에 '-utf8'이 붙습니다.

흔한 오해와 실수

깨짐 현상은 원인이 정해져 있어서, 아래 표처럼 '실제 인코딩 × 여는 방식'으로 증상이 갈립니다.

초록 체크만 맹신하지 않는 것이 첫 번째 요령입니다. 추천 판별은 치환문자 개수를 세는 방식이라 대부분 맞지만, 드물게 깨진 쪽도 치환문자가 적게 나올 수 있습니다. 그래서 두 미리보기 중 실제로 단어가 읽히는 쪽을 눈으로 한 번 더 확인하는 게 안전합니다.

BOM은 파일 용도에 따라 다릅니다. 엑셀에서 열 CSV라면 BOM을 넣어야 엑셀이 UTF-8로 인식합니다. 그래서 도구에는 'CP949 → UTF-8 + BOM' 옵션이 따로 있습니다. 반대로 소스코드·JSON·셸 스크립트 같은 프로그래밍용 파일에서는 맨 앞 3바이트 BOM이 내용의 일부로 읽혀 파서나 실행이 어긋날 수 있어, BOM 없는 UTF-8로 저장합니다.

EUC-KR과 CP949를 구분하려 애쓸 필요는 없습니다. CP949가 EUC-KR을 포함하는 확장이고, 브라우저는 이 둘을 같은 디코더로 처리합니다. 그래서 도구도 둘을 나눠 묻지 않고 한쪽으로 읽습니다.

출력은 항상 UTF-8입니다. 이 도구는 UTF-8로 되살려 저장하는 방향만 지원합니다(브라우저의 저장용 인코더가 UTF-8만 지원하기 때문입니다). UTF-8 파일을 다시 CP949로 되돌리는 용도는 아닙니다.

정리

핵심만 추리면 다음과 같습니다.

1. 한글 깨짐은 파일 손상이 아니라, 저장한 인코딩과 읽는 인코딩이 어긋난 증상입니다. 읽는 규칙만 맞추면 되살아납니다.
2. 옛 윈도우 파일은 대개 CP949(메모장의 'ANSI')이고, 요즘 환경은 UTF-8이 기본이라 서로 만나면 깨집니다.
3. 어떤 인코딩인지는 같은 바이트를 두 방식으로 읽어 치환문자가 적은 쪽을 보면 알 수 있습니다. BOM이 있으면 UTF-8로 확정됩니다.
4. 엑셀용 CSV는 BOM을 넣고, 소스코드 등 프로그래밍용 파일은 BOM을 뺍니다.
5. 판별이 애매하면 초록 체크에만 의존하지 말고, 두 미리보기 중 글자가 읽히는 쪽을 눈으로 확인하면 됩니다.

자주 묻는 질문

엑셀에서 CSV 한글이 깨지는데 어떻게 되살리나요?

두 경우로 나뉩니다. 파일이 CP949(옛 ANSI)라면 그 인코딩으로 읽어 'UTF-8 + BOM'으로 다시 저장하면 됩니다. 파일이 이미 UTF-8인데 엑셀이 깨뜨린 것이라면, 앞에 BOM만 붙여도 엑셀이 UTF-8로 올바르게 인식합니다. 도구 없이 하려면 엑셀 '데이터 → 텍스트/CSV에서'로 가져오면서 파일 원본 인코딩을 직접 지정하면 됩니다.

CP949와 EUC-KR은 다른 인코딩인가요?

같은 계열입니다. EUC-KR은 자주 쓰는 한글 2,350자만 담았고, CP949는 여기에 '뷁'·'똠' 같은 나머지 현대 한글까지 더해 11,172자를 모두 담도록 확장한 규격입니다. 즉 CP949가 EUC-KR을 포함합니다. 브라우저는 이 둘을 같은 디코더로 처리하므로 변환할 때 구분하지 않아도 됩니다.

BOM은 꼭 넣어야 하나요?

파일 용도에 따라 다릅니다. 엑셀에서 열 CSV에는 넣는 편이 안전합니다. BOM이 없으면 엑셀이 UTF-8 파일을 CP949로 잘못 읽어 한글이 깨지기 때문입니다. 반대로 소스코드·JSON·셸 스크립트 같은 프로그래밍용 파일에서는 맨 앞 BOM 3바이트가 오류를 일으킬 수 있으니 넣지 않습니다.

파일이 서버로 올라가나요?

아니요. 브라우저에 내장된 디코더로 기기 안에서만 처리하므로 파일이 밖으로 나가지 않습니다. 처리 용량은 파일당 20MB까지입니다.