엑셀에서 CSV 한글이 깨질 때, UTF-8 가져오기와 원본 손상 구분법
CSV 파일을 엑셀로 열었는데 한글이 깨지면 파일 인코딩과 엑셀의 읽기 방식을 구분하고, 텍스트/CSV 가져오기에서 문자 집합을 확인해 원본 손상 없이 검증하는 방법입니다.
거래처나 사내 시스템에서 받은 CSV를 엑셀로 열었더니 고객명이나 상품명만 깨지는 경우가 있습니다. 이때 파일이 망가졌다고 바로 판단하거나 깨진 셀을 손으로 고치면 원본 데이터의 일관성을 잃기 쉽습니다. 파일 안의 글자가 이미 손상됐는지, 아니면 엑셀이 다른 문자 인코딩으로 읽었는지를 먼저 구분해야 합니다.
CSV는 쉼표로 값을 나누는 텍스트 파일입니다. 같은 바이트라도 UTF-8, 다른 한국어 문자 인코딩 등 어떤 방식으로 해석하느냐에 따라 한글 표시 결과가 달라질 수 있습니다. Microsoft는 Excel에서 CSV UTF-8 파일을 올바르게 여는 방법으로 데이터 가져오기 기능을 안내합니다. 원본 파일을 그대로 두고 읽는 방식을 시험하는 것이 안전한 출발점입니다.
새 이름으로 복사한 파일에서만 시험한다
우선 받은 CSV 원본을 보존하고, 사본을 만들어 확인합니다. 파일명을 바꾸거나 확장자를 다시 붙이는 것만으로 문자의 인코딩이 변환되지는 않습니다. 한글이 깨진 상태로 열린 통합 문서를 바로 덮어써 버리면, 단순 표시 문제였던 것이 저장 과정에서 실제 데이터 손상으로 이어질 수 있습니다.
다음 두 장면을 비교하면 원인 범위를 좁힐 수 있습니다.
| 확인 결과 | 의심할 지점 |
|---|---|
| 원본을 인코딩 선택이 가능한 텍스트 편집기에서 열면 한글이 정상인데 엑셀에서만 깨짐 | 엑셀의 열기 방식이나 인코딩 해석 |
| 다른 인코딩을 선택해도 원본 내용에 이미 물음표나 대체문자가 저장돼 있음 | 내보낸 시스템에서 이미 손상됐을 가능성 |
| 일부 열의 값만 날짜·숫자로 변함 | 문자 깨짐과 별개인 자동 데이터 형식 변환 |
| 특정 행부터 열이 한 칸씩 밀림 | 인코딩보다 CSV 구분자·따옴표 규칙 문제 |
물음표 한 개만 보고 모든 원인을 단정할 수는 없습니다. 다만 원본에도 문자 정보가 사라졌다면 읽기 옵션만 바꿔 원래 글자를 복원할 수는 없습니다. 그때는 데이터를 내보낸 곳에서 올바른 형식으로 다시 추출해야 합니다.
더블클릭 대신 ‘텍스트/CSV 가져오기’를 사용하는 이유
Excel에서는 CSV를 더블클릭해 여는 대신 데이터 탭의 텍스트/CSV 가져오기를 이용할 수 있습니다. Microsoft 공식 안내에 따르면 UTF-8 CSV에 BOM(바이트 순서 표시)이 있으면 정상적으로 바로 열릴 수 있지만, 그렇지 않은 경우에는 가져오기 기능으로 읽는 방법을 선택할 수 있습니다.
실무에서는 다음 순서로 시험합니다.
- 빈 통합 문서를 열고 데이터 가져오기에서 텍스트/CSV 파일을 선택합니다. 메뉴 이름과 위치는 사용하는 Excel 버전에 따라 다를 수 있습니다.
- CSV 사본을 선택한 뒤 미리보기 화면에서 파일 원본 또는 문자 집합이 올바른지 살핍니다. UTF-8로 내보낸 파일이라면 UTF-8로 해석했을 때 한글이 정상인지 확인합니다.
- 한글이 깨진다면 원본 시스템의 내보내기 인코딩을 확인하고 그 방식에 맞춰 다시 미리보기합니다. 한글이 읽힌다는 이유만으로 임의의 인코딩을 정답으로 확정하지는 않습니다.
- 구분자와 각 열의 데이터 형식도 확인한 뒤 새 시트로 불러옵니다.
- 정상적으로 보이는 열 몇 개만 보지 말고 첫 행, 중간 행, 마지막 행의 값이 일치하는지 대조합니다.
불러온 뒤 표시가 정상이더라도 원본보다 행이 적거나 특정 열이 밀려 있으면 해결된 것이 아닙니다. 쉼표와 따옴표 때문에 열이 어긋난다면 CSV 열 밀림과 구분자 문제를 확인하는 방법을 별도로 적용해야 합니다.
UTF-8로 ‘저장’하는 것과 UTF-8로 ‘읽기’는 다르다
받은 파일의 한글이 깨졌을 때 필요한 일은 우선 올바르게 읽는 것입니다. 원본이 어떤 인코딩인지 확인하지 않고 깨진 화면 그대로 CSV UTF-8로 다시 저장하면 잘못 읽힌 글자가 새로운 파일에 고정될 수 있습니다.
반대로 내보내는 쪽을 관리할 수 있다면 시스템의 CSV 출력 옵션에서 문자 인코딩을 확인하고, 받는 쪽 Excel에서 해당 파일이 정상적으로 열리는지 시험해 보세요. 파일 교환 상대가 여러 프로그램을 쓴다면 ‘CSV’라는 확장자만 전달하지 말고 UTF-8 사용 여부와 구분자 규칙을 함께 알려주는 것이 재작업을 줄입니다.
원본을 수정해야 할 이유가 없다면 CSV를 먼저 Excel 통합 문서로 가져와 검수용 파일로 저장하고, 외부 시스템에 다시 넣어야 할 때에만 요구된 CSV 형식으로 별도 내보내는 방법도 있습니다. 시스템에 따라 UTF-8 또는 다른 인코딩을 요구할 수 있으므로 임의로 통일하지 마세요.
한글이 보인다고 숫자 데이터까지 안전한 것은 아니다
CSV를 열 때는 인코딩뿐 아니라 데이터 형식도 바뀔 수 있습니다. 예를 들어 고객코드가 00127인데 Excel에서 127로 읽으면 한글은 멀쩡해도 식별번호가 달라집니다. 코드·우편번호처럼 산술 계산을 하지 않는 열은 문자열로 가져와야 하는지 판단하세요. CSV에서 앞자리 0이 사라지는 문제와는 원인이 다릅니다.
날짜로 보이는 텍스트가 자동으로 날짜 값으로 바뀌거나 긴 식별번호가 지수 형태로 보이는 문제도 별도로 점검해야 합니다. 인코딩을 바꾼 뒤 다시 불러오더라도 이 위험이 저절로 사라지는 것은 아닙니다.
검수할 때는 한글이 섞인 대표 행뿐 아니라 총 행 수, 열 개수, 비어 있으면 안 되는 항목, 식별코드 자릿수를 확인합니다. 가능하면 원본 데이터의 고유키 두세 개를 대조해 가져오기 전후에 같은 레코드가 유지됐는지 보세요.
반복해서 받는 CSV라면 내보내기 조건을 기록한다
한 번은 정상인데 다음 주 파일에서 또 한글이 깨진다면 담당자가 매번 문자 설정을 바꾸는 문제일 수 있습니다. 파일 제공자에게 출력 인코딩, 구분자, 따옴표 처리 방식과 예시 파일을 확인하고 간단한 인수인계 메모로 남겨두세요. 데이터 공급자가 바뀌면 같은 확장자라도 다시 검증해야 합니다.
작업 완료 기준은 분명합니다. 원본을 보존한 상태에서 한글이 정확하게 읽히고, 행·열 구조와 식별번호까지 원본과 일치하는 것입니다. 화면에서 글자가 예쁘게 보이게 만드는 작업이 아니라 잘못 변환된 데이터를 업무에 전달하지 않는 과정으로 생각하면 점검 순서가 명확해집니다.