왜 엑셀에서 CSV 한글이 깨지나요?

엑셀은 확장자가 .csv인 파일을 열 때 파일에 BOM(순서 표시)이 없으면 인코딩을 EUC-KR(한글 완성형)로 추측해서 읽습니다. 하지만 실제 파일이 BOM 없는 UTF-8로 저장돼 있으면 한글 한 글자가 여러 바이트로 나뉘어 있는데 이를 EUC-KR 방식으로 잘못 해석해 깨진 문자로 표시됩니다. 이 도구로 UTF-8에 BOM을 붙여 다시 저장하면 엑셀이 인코딩을 정확히 인식합니다.

BOM(Byte Order Mark)은 파일 맨 앞에 붙는 몇 바이트짜리 표시로, 이 파일이 어떤 인코딩으로 저장됐는지 프로그램에게 알려주는 역할을 합니다. UTF-8 BOM은 EF BB BF라는 세 바이트이며 실제 텍스트 내용에는 영향을 주지 않고 인코딩 판별용으로만 쓰입니다. 엑셀은 이 BOM을 보고서야 UTF-8로 정확히 해석하기 때문에 한국에서 만든 CSV에는 BOM을 붙이는 것이 안전합니다.

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

아니요. 이 도구는 브라우저 안에서만 파일을 읽고 인코딩을 변환하며 선택한 파일은 서버로 전송되지 않습니다. 변환과 다운로드 과정이 모두 사용자의 기기 안에서 끝나기 때문에 고객 명단이나 개인정보가 담긴 CSV도 안심하고 사용할 수 있습니다.

EUC-KR로 저장은 왜 안 되나요?

브라우저가 표준으로 제공하는 TextEncoder는 UTF-8 인코딩만 지원하고 EUC-KR 같은 완성형 인코딩으로의 저장 기능은 제공하지 않아 이 도구에서는 EUC-KR로 저장하는 기능을 만들 수 없습니다. EUC-KR로 저장된 CSV가 꼭 필요하다면 엑셀에서 파일을 연 뒤 다른 이름으로 저장 메뉴에서 'CSV(쉼표로 분리)' 형식을 선택해 저장하는 방법을 대안으로 쓸 수 있습니다.

구글 시트나 맥 엑셀에서도 이 문제가 있나요?

구글 시트는 대부분 UTF-8을 기본으로 처리하기 때문에 BOM 없는 UTF-8 CSV를 올려도 한글이 깨지지 않고 잘 열립니다. 반대로 EUC-KR로 저장된 CSV를 구글 시트에 올리면 한글이 깨질 수 있어 이때는 이 도구로 먼저 UTF-8로 바꾼 뒤 업로드하는 것이 안전합니다. 맥의 엑셀도 최신 버전은 대부분 BOM 있는 UTF-8을 잘 인식하지만 오래된 버전에서는 여전히 EUC-KR로 추측하는 경우가 있어 BOM 포함 옵션을 권장합니다.

CSV 한글 깨짐 해결

엑셀에서 CSV 파일을 열었을 때 한글이 깨져 보인다면 인코딩 문제입니다. 파일을 선택하면 브라우저 안에서만 인코딩을 감지해 엑셀이 정확히 인식하는 UTF-8(BOM)로 바꿔주며, 파일은 서버로 전송되지 않습니다.

여기로 CSV 파일을 끌어다 놓으세요

변환 옵션 엑셀용 UTF-8 (BOM 포함) — 권장 UTF-8 (BOM 없음) — 웹 업로드·개발용

사용법

위 영역에 한글이 깨지는 CSV 파일을 끌어다 놓거나 파일 선택 버튼으로 선택합니다.
감지된 인코딩 배지와 미리보기에서 한글이 올바르게 보이는지 확인합니다.
대부분의 경우 기본 선택된 '엑셀용 UTF-8 (BOM 포함)' 옵션을 그대로 둡니다.
다운로드 버튼을 눌러 변환된 파일을 받은 뒤 엑셀에서 다시 열어 한글이 정상으로 보이는지 확인합니다.

이런 경우에 쓰기 좋아요

은행이나 카드사 사이트에서 내려받은 거래내역 CSV를 엑셀로 열었더니 적요란의 한글이 전부 깨져서 어떤 지출인지 알아볼 수 없을 때
쇼핑몰 관리자 페이지에서 내려받은 주문 목록의 고객 이름과 배송지 주소가 물음표나 알 수 없는 문자로 표시될 때
개발팀이나 외주 업체가 데이터베이스에서 뽑아 보내준 CSV가 다른 프로그램에서는 멀쩡한데 유독 엑셀에서만 한글이 깨질 때
설문조사 플랫폼에서 내려받은 응답 파일의 주관식 답변을 엑셀로 정리하려는데 한글 응답이 전부 외계어처럼 보일 때
반대로 윈도우 엑셀에서 저장한 CSV를 구글 시트에 올렸더니 한글이 깨져서 BOM 없는 UTF-8로 다시 저장해야 할 때

왜 하필 엑셀에서만, 왜 하필 한글만 깨지는지 그 배경이 궁금하다면 CSV 한글 깨짐 가이드에 인코딩의 역사와 BOM의 역할을 정리해 두었습니다.

CSV뿐 아니라 일반 텍스트(.txt)나 자막(.srt·.smi) 파일이 다른 기기·플레이어에서 깨질 때도 같은 인코딩 문제입니다. 이 도구로 파일을 올려 UTF-8(자막·txt는 보통 'BOM 없음' 옵션)로 다시 저장하면 됩니다. 원리는 txt·자막 인코딩 깨짐 가이드에 바이트까지 정리했습니다.

변환한 파일의 글자수를 확인하려면 글자수 세기 도구를, 첨부할 이미지 용량이 크다면 이미지 용량 줄이기 도구를 이용해 보세요.

인코딩 네 가지를 바이트로 나란히 놓으면

한글이 깨진다는 건 화면 이야기고, 파일 안에서 벌어지는 일은 바이트로만 보입니다. 내용이 완전히 같은 3행짜리 CSV를 네 가지 방식으로 저장한 뒤 앞부분 바이트를 그대로 꺼내고, 각 파일을 이 도구에 넣어 무엇으로 감지하는지까지 확인했습니다. (MacBook Pro M1 Pro / macOS 26.5.2, Chrome 150.0.7871.187 헤드리스로 이 페이지를 그대로 실행, 바이트 확인은 파이썬 3.14.5)

내용: 이름,부서,금액 / 김한글,영업1팀,1250000 / 박서울,기술지원,830000

UTF-8 (BOM 없음)  80 byte   ec 9d b4  eb a6 84  2c ...
UTF-8 (BOM 있음)  83 byte   ef bb bf  ec 9d b4  eb a6 84  2c ...
CP949 (EUC-KR)    61 byte   c0 cc  b8 a7  2c ...
UTF-16 LE         86 byte   ff fe  74 c7  84 b9  2c 00 ...

같은 "이름" 두 글자가 UTF-8에서는 6바이트, CP949에서는 4바이트입니다. 한글 한 글자가 UTF-8에서 3바이트, CP949에서 2바이트라 한글이 많은 CSV를 UTF-8로 바꾸면 파일이 커집니다. 위 실측에서 61바이트 CP949 파일이 83바이트가 됐으니 36% 증가입니다. 맨 앞 ef bb bf 세 바이트가 BOM이고, 엑셀은 이 세 바이트가 있어야 UTF-8이라고 확신합니다.

넣은 파일	화면에 뜬 감지 결과	미리보기 첫 줄	변환 결과
UTF-8 (80 B)	UTF-8 (BOM 없음)	이름,부서,금액	83 B · BOM 추가
CP949 (61 B)	EUC-KR(CP949)	이름,부서,금액	83 B · UTF-8로 재저장
UTF-8 BOM (83 B)	UTF-8 (BOM)	이름,부서,금액	83 B · 그대로
UTF-16 LE (86 B)	UTF-16 LE	이름,부서,금액	83 B · UTF-8로 재저장

네 가지 모두 제대로 감지했고, 어느 쪽에서 출발하든 결과는 같은 83바이트 파일이 됩니다. 엑셀에서 "다른 이름으로 저장 → 유니코드 텍스트"로 나온 UTF-16 파일도 그대로 넣으면 됩니다. .txt 파일도 같습니다. CP949로 저장된 28바이트짜리 텍스트를 넣으면 EUC-KR로 감지해 39바이트 UTF-8로 바꿔 줍니다.

두 해석이 모두 가능한 345글자는 직접 고릅니다

감지 방식은 단순합니다. BOM이 있으면 그걸 믿고, 없으면 UTF-8로 엄격하게 읽어 보고, 실패하면 EUC-KR로 봅니다. 다만 CP949로 저장했는데 그 바이트가 UTF-8 규칙에도 우연히 들어맞는 경우에는 어느 쪽인지 자동으로 단정하지 않습니다. UTF-8 결과에 제어 문자·낯선 라틴 확장 문자나 기호가 있고, 같은 바이트를 CP949로 읽었을 때 완성형 한글이 나오면 두 해석을 함께 보여줍니다.

실제로 그런 한글이 있습니다. 음절 하나씩만 따져도 345자가 해당합니다. 치킨·칼칼·청첩·회칙·호칭 같은 실제 단어도 그 안에 있습니다. 이런 글자만으로 된 CSV를 CP949로 저장해 넣어 봤습니다.

넣은 파일 : item,qty / 치킨,3 / 칼칼,1 / 회칙,2   (CP949, 30 byte)
바이트    : 69 74 65 6d 2c 71 74 79 0a  c4 a1 c5 b2  2c 33 0a ...

화면 감지 : 확실하지 않음
UTF-8 해석: item,qty / ġŲ,3 / ĮĮ,1 / ȸĢ,2
CP949 해석: item,qty / 치킨,3 / 칼칼,1 / 회칙,2
선택 전   : 다운로드 비활성화
CP949 선택: 39 byte, 한글 그대로 저장됨

"치킨"의 CP949 바이트 c4 a1 c5 b2가 공교롭게도 UTF-8의 두 바이트 문자 규칙에 맞아떨어져 ġŲ로 읽혔습니다. 조건이 까다로워서(파일 전체의 한글이 전부 그 345자 안에 들어야 함) 흔하게 걸리지는 않지만, 한글 항목이 한두 개뿐인 짧은 CSV라면 가능성이 있습니다. 이 페이지에 위 30바이트 파일을 넣고 CP949 쪽을 골랐더니, 받은 파일은 BOM을 포함한 39바이트였고 네 줄의 한글이 모두 그대로였습니다.

이 상태에서는 두 미리보기 중 한글이 올바른 쪽을 고르기 전까지 다운로드 버튼이 켜지지 않습니다. UTF-8 문서에 실제 라틴 문자나 기호를 쓴 경우도 있을 수 있으므로 도구가 임의로 CP949를 선택하지 않고, 원문을 아는 사용자의 확인을 받습니다.

변환 파일은 바이트와 브라우저 미리보기로 확인했을 뿐 실제 엑셀에서 열어 보지는 않았습니다. Chrome 150 밖의 브라우저와 다른 기기에서의 감지 결과도 확인하지 못했습니다.

자주 묻는 질문

왜 엑셀에서 CSV 한글이 깨지나요?: 엑셀은 확장자가 .csv인 파일을 열 때 파일에 BOM(순서 표시)이 없으면 인코딩을 EUC-KR(한글 완성형)로 추측해서 읽습니다. 하지만 실제 파일이 BOM 없는 UTF-8로 저장돼 있으면 한글 한 글자가 여러 바이트로 나뉘어 있는데 이를 EUC-KR 방식으로 잘못 해석해 깨진 문자로 표시됩니다. 이 도구로 UTF-8에 BOM을 붙여 다시 저장하면 엑셀이 인코딩을 정확히 인식합니다.
BOM이 뭔가요?: BOM(Byte Order Mark)은 파일 맨 앞에 붙는 몇 바이트짜리 표시로, 이 파일이 어떤 인코딩으로 저장됐는지 프로그램에게 알려주는 역할을 합니다. UTF-8 BOM은 EF BB BF라는 세 바이트이며 실제 텍스트 내용에는 영향을 주지 않고 인코딩 판별용으로만 쓰입니다. 엑셀은 이 BOM을 보고서야 UTF-8로 정확히 해석하기 때문에 한국에서 만든 CSV에는 BOM을 붙이는 것이 안전합니다.
파일이 서버로 올라가나요?: 아니요. 이 도구는 브라우저 안에서만 파일을 읽고 인코딩을 변환하며 선택한 파일은 서버로 전송되지 않습니다. 변환과 다운로드 과정이 모두 사용자의 기기 안에서 끝나기 때문에 고객 명단이나 개인정보가 담긴 CSV도 안심하고 사용할 수 있습니다.
EUC-KR로 저장은 왜 안 되나요?: 브라우저가 표준으로 제공하는 TextEncoder는 UTF-8 인코딩만 지원하고 EUC-KR 같은 완성형 인코딩으로의 저장 기능은 제공하지 않아 이 도구에서는 EUC-KR로 저장하는 기능을 만들 수 없습니다. EUC-KR로 저장된 CSV가 꼭 필요하다면 엑셀에서 파일을 연 뒤 다른 이름으로 저장 메뉴에서 'CSV(쉼표로 분리)' 형식을 선택해 저장하는 방법을 대안으로 쓸 수 있습니다.
구글 시트나 맥 엑셀에서도 이 문제가 있나요?: 구글 시트는 대부분 UTF-8을 기본으로 처리하기 때문에 BOM 없는 UTF-8 CSV를 올려도 한글이 깨지지 않고 잘 열립니다. 반대로 EUC-KR로 저장된 CSV를 구글 시트에 올리면 한글이 깨질 수 있어 이때는 이 도구로 먼저 UTF-8로 바꾼 뒤 업로드하는 것이 안전합니다. 맥의 엑셀도 최신 버전은 대부분 BOM 있는 UTF-8을 잘 인식하지만 오래된 버전에서는 여전히 EUC-KR로 추측하는 경우가 있어 BOM 포함 옵션을 권장합니다.