엑셀 CSV 한글 깨질 때, 더블클릭 대신 가져오기

Excel에서 CSV를 열었을 때 ‘서울’이 알아볼 수 없는 기호나 ‘ì„œìš¸’ 같은 문자열로 보인다면, 파일이 손상됐다기보다 기록할 때 쓴 문자 인코딩과 Excel이 적용한 인코딩이 다른 경우가 많다. 글꼴을 바꾸거나 깨진 셀을 직접 고쳐서는 해결되지 않는다. 원본 파일의 바이트를 올바른 인코딩으로 다시 해석해야 한다.

같은 한글을 세 가지 인코딩으로 가져와 보기

내 파일을 바꾸기 전에 아래 연습 파일로 가져오기 설정을 확인할 수 있다. 세 파일에는 똑같이 연필 3개·1,500원, 공책 2개·4,000원이 들어 있다. 가상 상품 예시이며 인코딩만 다르다.

연습 파일과 가져오기에서 맞출 문자 인코딩
파일	맞출 인코딩	다른 점
UTF-8 CSV 받기	65001: Unicode (UTF-8)	BOM 없음
BOM 있는 UTF-8 CSV 받기	65001: Unicode (UTF-8)	맨 앞에 EF BB BF
CP949 CSV 받기	949: 한국어 / Windows	UTF-8과 한글 바이트가 다름

파일을 내려받고 엑셀의 데이터 → 텍스트/CSV 가져오기에서 연다. 메뉴 이름과 제공되는 가져오기 기능은 버전에 따라 다를 수 있다.
파일에 맞는 인코딩과 쉼표 구분자를 선택한다. 미리보기에서 첫 행은 상품·수량·금액, 다음 행은 연필·3·1500으로 보여야 한다.
미리보기가 맞으면 불러온다. 글자가 깨져 보이면 저장하지 말고 인코딩을 바꿔 다시 확인한다.

이 자료는 Python으로 인코딩한 뒤 동일한 인코딩으로 다시 읽어 문자열이 모두 일치하는지 검사했다. 실제 엑셀의 모든 버전에서 자동 인식이나 더블클릭 동작을 시험한 자료는 아니다. UTF-8 파일을 949로 읽거나 반대로 읽으면 같은 바이트를 다른 문자로 해석하게 된다. 이미 물음표 등으로 바뀐 내용을 덮어썼다면 인코딩 선택만으로 원래 한글이 복구되지 않을 수 있으므로, 원본을 다시 받아 가져오는 편이 정확하다.

가장 먼저 할 일은 깨진 상태의 CSV를 덮어쓰지 않는 것이다. 저장하지 않고 파일을 닫은 뒤, 빈 통합 문서에서 데이터 → 텍스트/CSV에서로 원본을 가져온다. 미리 보기에서 UTF-8을 먼저 시험하고 맞지 않으면 한국어 코드 페이지를 비교한다. 한글과 열 구분이 모두 정상일 때 데이터를 불러온 뒤, 편집용 파일은 XLSX로, 다른 시스템에 전달할 파일은 CSV UTF-8로 저장한다.

같은 CSV인데 한글이 깨지는 이유

CSV를 안전하게 여는 순서

CSV는 행과 열의 값을 쉼표 같은 구분 문자로 나눈 일반 텍스트 파일이다. XLSX처럼 시트 구조, 셀 서식, 글꼴과 여러 기능을 하나의 패키지에 담는 통합 문서 형식은 아니다. CSV의 공통 형식과 text/csv 미디어 유형을 문서화한 IETF RFC 4180도 문자 집합을 나타내는 charset을 선택적 매개변수로 두고, US-ASCII 외 문자 집합도 사용할 수 있다고 설명한다. 확장자가 모두 .csv여도 내부 문자는 UTF-8이나 한국어 코드 페이지 등 서로 다른 방식으로 기록될 수 있다.

인코딩은 문자를 바이트로 나타내는 규칙이다. 파일을 만든 서비스가 ‘서울’을 UTF-8 바이트로 기록했는데 Excel이 다른 문자 집합으로 해석하면, 원래 바이트는 그대로여도 화면에는 엉뚱한 문자가 나타난다. 반대로 오래된 국내 업무 프로그램이 한국어 코드 페이지로 내보낸 파일을 UTF-8로 읽어도 한글이 깨진다. 글꼴 문제는 특정 문자의 모양을 표시하지 못하는 경우이고, 인코딩 문제는 같은 바이트를 다른 문자로 해석하면서 생긴다.

한국어 파일에서 흔히 만나는 선택지 가운데 하나가 코드 페이지 949다. Microsoft의 Windows 코드 페이지 식별자 문서는 949를 한국어 통합 한글 코드로 분류한다. 다만 프로그램이 ‘ANSI’라고만 표시했다면 그 말만으로 949라고 단정할 수는 없다. ANSI라는 표현은 환경의 기본 코드 페이지를 가리키는 식으로 모호하게 쓰이기도 하므로, 파일을 만든 시스템의 내보내기 설명과 Excel 미리 보기 결과를 함께 확인해야 한다.

UTF-8 파일 앞에는 BOM(Byte Order Mark)이 붙을 수 있다. UTF-8의 BOM은 EF BB BF이며 필수 요소는 아니다. Unicode Consortium의 BOM 설명에 따르면 UTF-8은 바이트 순서가 고정돼 있으므로, 이 BOM은 바이트 순서를 결정하기보다 표식 없는 텍스트가 UTF-8임을 알리는 서명 역할을 한다. 일부 프로그램은 BOM을 기대하지 않으므로 언제나 붙여야 하는 것도 아니다.

Microsoft의 Excel 지원 문서는 BOM과 함께 저장된 UTF-8 CSV는 정상적으로 열 수 있으며, 그렇지 않을 때는 Power Query의 데이터 가져오기나 텍스트 가져오기 기능을 사용하라고 안내한다. 이 차이 때문에 같은 UTF-8 CSV라도 한 파일은 더블클릭으로 잘 열리고 다른 파일은 깨져 보일 수 있다.

모든 값이 한 열에 몰리는 현상은 별개 문제다. 대개 인코딩이 아니라 쉼표, 세미콜론, 탭 같은 구분 기호를 Excel이 다르게 판단해서 생긴다. 한글 깨짐과 열 나눔 오류가 함께 나타날 수 있으므로, 가져오기 화면에서 파일 원본과 구분 기호를 각각 점검해야 한다.

깨진 파일은 먼저 닫고 원본부터 확보한다

한글이 깨진 상태에서 저장하면 Excel이 잘못 해석한 문자가 새 바이트로 기록될 수 있다. 그러면 원본에 남아 있던 정상 바이트가 사라져, 나중에 올바른 인코딩을 선택해도 복구되지 않을 수 있다. 깨짐을 발견하면 저장하지 말고 닫는다. 이미 덮어썼다면 최초 다운로드 파일, 메일 첨부 원본, 백업본을 찾거나 원래 시스템에서 다시 내려받는다.

원본을 확보한 뒤에는 복사본으로 시험한다. 텍스트 편집기에서 파일을 열어 보는 일은 진단에 도움이 되지만, 편집기도 인코딩을 자동 추정할 수 있다. 화면에 한글이 보인다는 사실만으로 실제 인코딩이 확정되지는 않는다. ‘인코딩으로 다시 열기’나 현재 인코딩 표시가 있다면 여러 후보를 비교하되, 변환 저장은 반드시 복사본에서 한다.

원본을 제공한 서비스의 내보내기 화면도 확인할 만하다. ‘UTF-8’, ‘UTF-8 with BOM’, ‘Excel용 CSV’ 같은 항목이 있다면 Excel이나 업로드 대상 시스템의 요구 사항에 맞는 옵션으로 새로 받는 편이 가장 간단하다. 대상 서비스가 BOM 없는 UTF-8처럼 별도 형식을 명시한다면 그 요구 사항이 우선이다.

Excel의 텍스트/CSV 가져오기로 다시 읽기

문자 깨짐과 자동 변환의 차이

Windows용 Microsoft 365와 비교적 최신 Excel에서는 CSV를 더블클릭하지 말고 빈 통합 문서를 연다. 리본에서 데이터 → 텍스트/CSV에서를 선택한다. 구성에 따라 데이터 → 데이터 가져오기 → 파일에서 → 텍스트/CSV에서로 표시될 수도 있다. 파일을 선택하면 데이터 미리 보기 창이 나타난다. 이 흐름은 Microsoft의 텍스트 및 CSV 가져오기 안내에서 확인할 수 있다.

미리 보기의 ‘파일 원본’에서 먼저 65001: Unicode(UTF-8)을 선택한다. 이름, 주소, 상품명처럼 한글이 들어 있는 여러 열을 살피고 특수문자도 정상인지 확인한다. 열이 한 칸에 몰렸다면 구분 기호를 실제 파일에 맞춰 쉼표, 세미콜론 또는 탭으로 바꾼다. 미리 보기에서 선택 결과를 바로 볼 수 있으므로, 한글과 열 구조가 모두 맞을 때까지 로드하지 않는 편이 좋다.

UTF-8에서도 계속 깨진다면 파일 원본 목록의 한국어 항목을 비교한다. 환경에 따라 ‘949: 한국어’, ‘한국어’, ‘Korean’처럼 표시가 다를 수 있다. 이름만 보고 결정하기보다 파일 전체의 한글과 특수문자가 자연스럽게 나타나는지 확인한다. UTF-8과 949 어느 쪽에서도 정상으로 보이지 않는다면 다른 인코딩일 수 있으므로 원본 생성 프로그램의 설명을 확인해야 한다. 이미 원본에 대체 문자 �가 저장돼 있다면 Excel에서 인코딩만 바꿔 원래 글자를 되살릴 수는 없다.

우편번호, 사번, 전화번호, 주문번호처럼 모양을 그대로 유지해야 하는 열이 있다면 미리 보기에서 데이터 변환을 누른다. Power Query 편집기에서 해당 열을 선택해 데이터 형식을 텍스트로 지정한 뒤 닫기 및 로드한다. 미리 보기에서 바로 로드하면 Excel이 값의 형태를 판단해 숫자나 날짜로 바꿀 수 있으므로, 식별자 열이 있는 파일은 변환 단계를 거치는 편이 안전하다.

구형 Excel에서 텍스트/CSV에서가 보이지 않으면 텍스트 가져오기 마법사를 사용한다. 복사본의 확장자를 .csv에서 .txt로 임시 변경해 열면 마법사를 실행할 수 있다. 파일 원본에서 UTF-8 또는 적절한 한국어 인코딩을 고르고, 다음 화면에서 구분 기호를 선택한 뒤 마지막 단계에서 식별자 열의 형식을 텍스트로 지정한다. 버전과 운영체제에 따라 메뉴 이름이나 사용할 수 있는 가져오기 방식은 다를 수 있다.

정상화한 데이터의 저장 형식 선택

Excel에서 계속 편집할 파일이라면 XLSX로 저장하는 편이 안전하다. XLSX는 여러 시트와 수식, 셀 서식, 열 너비 등을 유지하지만 CSV는 한 시트의 값 중심 데이터를 전달하는 텍스트 형식이다. Microsoft의 Excel 지원 파일 형식 문서도 다른 형식으로 저장할 때 일부 서식, 데이터 또는 기능이 손실될 수 있다고 설명한다. CSV로 내보낼 때는 현재 시트만 저장된다는 점도 확인해야 한다.

다른 서비스에 올리기 위해 CSV가 꼭 필요하다면 파일 → 다른 이름으로 저장에서 CSV UTF-8(쉼표로 분리)(*.csv)를 선택한다. 이름이 비슷한 일반 CSV, CSV(MS-DOS), CSV(Macintosh)는 같은 선택지가 아니다. Microsoft는 Windows용 Excel 2019부터 UTF-8 CSV를 열고 저장하는 기능과 해당 저장 형식을 제공한다고 안내한다. 이 옵션이 없는 이전 버전에서는 일반 CSV로 무리하게 저장하지 말고, UTF-8 저장을 지원하는 편집기나 원본 시스템을 이용하는 편이 낫다.

저장한 파일은 바로 원본과 교체하지 않는다. 새 CSV를 닫았다가 텍스트/CSV 가져오기로 다시 열어 한글, 특수문자, 구분 기호, 필드 안 줄바꿈과 큰따옴표, 앞자리 0을 확인한다. 값 안에 쉼표나 줄바꿈이 있으면 해당 필드는 큰따옴표로 둘러싸여야 하며, 필드 자체의 큰따옴표는 두 번 써서 이스케이프하는 것이 RFC 4180에 기술된 일반적인 CSV 처리 방식이다. 업로드할 서비스가 제공하는 샘플 파일이나 명세가 있다면 그 규칙을 우선한다.

한글이 돌아온 뒤에도 확인할 데이터 오류

문자가 정상으로 보인다고 데이터가 모두 보존된 것은 아니다. Excel은 00123 같은 값을 숫자 123으로 바꾸거나 날짜처럼 생긴 코드를 날짜로 해석할 수 있다. 16자리 이상의 주문번호나 계정번호를 숫자로 읽으면 과학적 표기법으로 보일 뿐 아니라 15번째 유효 숫자 뒤의 값이 0으로 바뀔 수 있다. 이런 식별자는 계산할 숫자가 아니라 텍스트로 가져와야 한다.

Microsoft의 앞자리 0과 큰 수 보존 안내는 Power Query에서 열 형식을 텍스트로 바꾸는 방법을 제공하며, Excel이 숫자의 유효 숫자를 최대 15자리까지만 유지한다고 설명한다. Microsoft 365와 Excel 2024에는 파일 → 옵션 → 데이터의 자동 데이터 변환 설정도 있다. 여기서 앞자리 0 제거, 긴 숫자의 15자리 변환, E가 포함된 값을 과학적 표기법으로 바꾸는 동작 등을 조절할 수 있다. 이 설정은 모든 구형 버전에 있는 기능이 아니므로, 버전과 무관하게 적용하기 쉬운 방법은 가져오기 단계에서 중요한 열을 텍스트로 지정하는 것이다.

일부 한글만 네모로 보이고 나머지는 정상이라면 해당 글리프를 지원하지 않는 글꼴 문제일 가능성이 있다. 반대로 한글 대부분이 일정한 기호 조합으로 바뀌었다면 인코딩 불일치 가능성이 높다. 모든 값이 한 열에 들어갔다면 구분 기호를, 행 수가 예상보다 늘었다면 필드 내부 줄바꿈과 큰따옴표의 짝을 점검한다. 서로 다른 문제를 한꺼번에 ‘한글 깨짐’으로 보지 않아야 원인을 빨리 찾을 수 있다.

해결 순서는 원본 보존, 올바른 인코딩으로 가져오기, 구분 기호와 열 형식 확인, 목적에 맞는 형식으로 저장, 재검증으로 이어진다. UTF-8을 먼저 시험하되 무조건 정답이라고 가정하지 말고 한국어 코드 페이지도 미리 보기로 비교해야 한다. 이 과정을 따르면 한글 깨짐뿐 아니라 앞자리 0, 긴 식별자, 열 분리 오류도 함께 예방할 수 있다.