CSV 한글 깨짐과 앞자리 0: Excel에서 데이터 손상 없이 여는 법

CSV를 열었더니 상품명이 알아볼 수 없는 글자로 바뀌고, 상품코드 00127은 127이 되어 있습니다. 둘 다 흔히 “파일이 깨졌다”고 부르지만, 같은 문제로 묶으면 해결 순서부터 어긋납니다. 한쪽은 문자를 읽는 방식의 문제일 수 있고, 다른 쪽은 Excel이 코드에 숫자 계산 규칙을 적용한 결과일 수 있습니다. 한글만 돌아왔다고 안심하면 숫자로만 이루어진 식별자는 그대로 잘못된 채 다음 작업으로 넘어갑니다. 텍스트·CSV 파일 가져오기와 내보내기 앞자리 0과 긴 숫자 유지

이 글에서 답할 질문은 하나입니다. 받은 CSV의 원래 내용을 유지하면서 Excel로 확인·가공하고, 다른 프로그램에 전달하려면 무엇을 어느 단계에서 검사해야 할까요? 아래 상품자료와 값은 절차를 설명하기 위한 가상사례입니다. 안내 기준일은 2026년 10월 7일이며, 기본 절차는 Windows 데스크톱 Excel의 텍스트/CSV 가져오기를 중심으로 설명합니다. Mac의 지원 조건은 별도로 구분합니다.

같은 ‘깨짐’이라도 먼저 고칠 곳은 다릅니다

CSV는 행과 필드를 문자로 기록한 텍스트 파일입니다. XLSX 통합문서처럼 각 열을 텍스트형으로 유지하라는 셀 설정까지 함께 보관하는 파일은 아닙니다. 따라서 같은 파일을 다른 방식으로 열면 열 분리와 값의 해석이 달라질 수 있습니다. Excel의 CSV 자동 열기도 현재 기본 데이터 형식 설정을 사용합니다. Excel 지원 파일 형식

보이는 증상	먼저 확인할 원인	처음 할 조치
한글만 엉뚱한 문자로 보임	파일 인코딩과 읽기 설정 불일치 가능성	원본 복사본을 가져오며 문자 해석을 비교합니다.
한 줄의 내용이 한 셀 또는 한 열에 몰림	구분자 설정 또는 파일 구조	미리보기에서 콤마·탭·세미콜론 등을 확인합니다.
00127이 127로 바뀜	식별코드의 숫자 변환	원본의 코드 열을 텍스트로 다시 가져옵니다.
긴 식별자의 끝자리가 달라짐	숫자 정밀도 손실 가능성	변환 전 원본 문자열과 대조합니다.
03/04/2026의 월·일이 달라짐	날짜 해석에 사용한 지역 규칙	원래 날짜 규격을 확인할 때까지 텍스트로 둡니다.

이 구분의 실익은 복구 가능성을 섣불리 포기하지 않는 데 있습니다. 파일을 읽는 방법만 틀렸다면 원본을 다시 가져오면 됩니다. 반대로 잘못 해석된 결과를 원본에 덮어썼다면, 가져오기 설정을 바꾸는 것만으로는 이전 값으로 돌아갈 수 없습니다. 지금 보이는 이상한 값이 원래 파일에도 있는지, Excel 안에서만 생긴 것인지부터 나눠야 합니다.

원본 보존: 열어 보기보다 먼저 복사합니다

파일 탐색기에서 받은 CSV를 복사해 원본 보관용과 작업용을 구분합니다. 예를 들어 상품목록_수신원본.csv는 그대로 두고 상품목록_가져오기용.csv로 작업합니다. 파일명에 수신일이나 자료 기준일을 함께 적어 두면, 나중에 재전송받은 파일과 잘못 섞이는 일도 줄일 수 있습니다. 이름이 달라도 어느 원본에서 출발했는지는 기록해 둡니다.

이미 더블클릭했다면 우선 저장하지 않습니다. 값이 달라 보여도 곧바로 덮어쓰지 않은 원본은 별도로 검사할 수 있습니다. 수정 사항을 버리고 닫을지 판단한 뒤 새 통합문서에서 원본 복사본을 가져오는 편이, 변환된 셀을 하나씩 고치는 것보다 원래 상태에 가까운 출발점입니다. 자동 저장이나 다른 편집 과정으로 파일이 바뀌었을 가능성이 있다면 보관 사본 또는 발신자의 원본과 먼저 대조합니다.

메모장으로 내용을 확인하는 것 자체가 금지된 행동은 아닙니다. 다만 “일단 UTF-8로 저장하면 되겠지” 하고 원본을 다시 저장하는 것은 다른 일입니다. 잘못 읽힌 문자열을 새 인코딩으로 기록하면, 해결에 필요한 원래 문자 정보 대신 잘못 읽힌 결과를 남길 수 있습니다. 텍스트 편집기를 쓴다면 복사본을 저장하지 않는 열람용으로 다루고, 인코딩을 바꿔 다시 읽는 기능과 내용을 바꿔 저장하는 기능을 구별합니다.

원본이 남아 있지 않고 받은 파일 자체에 상품명 대신 물음표가 저장되어 있다면, 물음표가 어떤 글자였는지는 Excel이 알아낼 수 없습니다. 이때 필요한 것은 더 많은 인코딩 후보가 아니라 내보내기 전 데이터, 백업, 또는 재발급 파일입니다. 다만 한 프로그램에서 물음표로 보인다는 이유만으로 실제 문자 손실이라고 단정하지는 않습니다. 올바른 문자 해석으로 읽은 원본 내용인지까지 확인해야 합니다.

미리보기: 인코딩과 구분자를 따로 맞춥니다

새 통합문서에서 텍스트/CSV로 가져옵니다

빈 통합문서를 열고 데이터(Data) → 텍스트/CSV에서(From Text/CSV)를 선택합니다. 배치에 따라 데이터 가져오기(Get Data) → 파일에서(From File) → 텍스트/CSV에서 안에 있을 수 있습니다. 작업용 CSV를 선택한 다음, 바로 로드하지 말고 미리보기에서 열과 값을 확인합니다. 변환이 필요하면 데이터 변환(Transform Data)으로 Power Query 편집기에 들어갑니다.

미리보기에서는 먼저 첫 행이 머리글인지 살핍니다. 파일 맨 위에 “10월 상품목록” 같은 설명 행이 있으면 그것을 열 이름으로 잘못 취급할 수 있습니다. 반대로 머리글이 없는 자료인데 첫 행을 머리글로 올리면 첫 번째 상품이 데이터에서 사라집니다. 제공 규격의 열 이름과 실제 첫 행을 맞춰 보는 작업은 사소해 보이지만, 이후 검산의 행수를 결정합니다. Power Query 자료형 변경

한글이 돌아오는 설정과 열이 나뉘는 설정은 다릅니다

파일 원본(File Origin) 또는 인코딩 항목은 파일의 바이트를 어떤 문자로 읽을지 정합니다. 구분자(Delimiter)는 그렇게 읽은 내용을 어느 지점에서 열로 나눌지 정합니다. 한글이 정상인데 모든 값이 A열에 몰려 있다면 인코딩만 계속 바꿀 이유가 없습니다. 구분자가 실제 파일과 맞는지 확인할 차례입니다. Power Query 텍스트·CSV 커넥터

인코딩은 발신 시스템의 내보내기 규격을 우선합니다. UTF-8이라고 안내받았다면 해당 설정으로 읽고, CP949라고 명시되어 있다면 그에 맞는 항목을 선택해 확인합니다. “요즘 파일이니까 UTF-8”, “한국에서 받았으니까 CP949”는 근거가 아닙니다. 정보가 없다면 가능한 설정을 미리보기에서 비교하되, 익숙한 단어 한 개가 그럴듯해진 것만으로 끝내지 않습니다. 한글 상품명 여러 개, 기호, 빈칸 주변까지 살피고 발신자에게 인코딩을 확인합니다.

Microsoft는 UTF-8 CSV가 BOM을 포함하면 일반적인 방식으로 열 수 있으며, 그렇지 않은 경우 Power Query 등으로 가져오도록 안내합니다. 여기서 BOM은 UTF-8 해석을 돕는 표식이지 상품코드 보호 장치가 아닙니다. 한글이 정상적으로 열리는 파일에도 숫자·날짜 자동 변환은 별도 문제로 남습니다. UTF-8 CSV 열기

구분자는 파일의 실제 구조에 맞춰 콤마, 탭, 세미콜론 등을 비교합니다. 예상 열이 여섯 개인데 하나만 나오거나 일곱 개로 갈라지면 로드하지 않습니다. 특히 특정 상품의 설명이 길 때만 열이 어긋난다면 구분자 전체 설정뿐 아니라 그 필드의 따옴표 처리를 의심해야 합니다. Power Query에서는 구분자 변경 결과를 미리 확인할 수 있습니다.

문장 속 콤마까지 열 경계는 아닙니다

가상 상품자료가 다음과 같다고 가정합니다. 첫 줄은 머리글이고, 나머지 두 줄이 데이터입니다. 설명을 위해 표시한 코드 블록이며 실제 수신 파일을 제시하는 것은 아닙니다.

상품코드,외부식별자,기준일,상품명,메모,수량
00127,12345678901234567,03/04/2026,"컵, 대형","고객이 ""선물용"" 요청",2
00128,12345678901234568,04/04/2026,접시,일반포장,3

첫 번째 상품명은 컵, 대형이라는 하나의 값입니다. 바깥 큰따옴표는 그 안의 콤마를 열 구분과 구별하고, 메모의 연속된 큰따옴표 두 개는 값 안의 큰따옴표 한 개를 나타냅니다. 올바르게 읽으면 메모는 고객이 "선물용" 요청입니다. 이런 인용 규칙은 RFC 4180에 설명되어 있습니다. 모든 시스템이 똑같이 구현한다고 가정하지 않고, 받는 쪽 규격도 함께 확인합니다. CSV 형식 규칙(RFC 4180)

따옴표를 전부 지우거나 모든 콤마를 다른 문자로 치환하면 이 구조가 망가집니다. 원래 여섯 열인 자료에서 상품명만 둘로 갈라져 뒤의 메모와 수량이 밀릴 수 있습니다. 또 따옴표로 묶인 필드 안에 줄바꿈이 허용된 파일이라면, 편집기에서 보이는 물리적인 줄 수와 실제 데이터 행수도 다를 수 있습니다. Power Query의 CSV 인용 줄바꿈 처리와 생산 시스템의 규격을 맞춰야 합니다. Csv.Document 함수

자료형: 계산할 숫자와 보존할 코드를 구별합니다

가져오기의 기본 전략은 모르는 열을 서둘러 계산 가능한 값으로 만드는 것이 아닙니다. 식별자와 모호한 날짜는 먼저 텍스트로 확보하고, 수량처럼 용도가 확실한 열만 숫자로 바꿉니다. Power Query의 데이터 형식 검색 설정에서 자동 형식 검색을 하지 않도록 선택할 수 있다면 모든 열을 텍스트로 시작하는 방법이 유용합니다. 이 선택이 보이지 않으면 편집기에서 자동 변환 단계를 직접 점검합니다.

가상 값과 용도	우선 자료형	보존·변환 후 확인
상품코드 00127	텍스트(Text)	앞의 0을 포함한 5글자가 일치하는지 확인합니다.
외부식별자 12345678901234567	텍스트(Text)	17자리 전체와 마지막 두 자리까지 대조합니다.
기준일 03/04/2026	규격 확인 전 텍스트	월/일 순서를 확인한 뒤 날짜로 변환합니다.
상품명 컵, 대형	텍스트(Text)	콤마를 포함해 한 필드에 남는지 봅니다.
수량 2, 3	정수 등 업무에 맞는 숫자형	숫자 셀 2개, 합계 5인지 검산합니다.

00127은 숫자 127에 장식을 붙인 값이 아닙니다

상품코드에 더하기나 평균이 필요하지 않다면 숫자로 바꿀 이유가 없습니다. 이 예시의 00127은 다섯 글자짜리 식별자입니다. 숫자 127과 같은 상품을 뜻하는지는 Excel이 아니라 해당 상품 시스템의 규칙이 정합니다. 원래 코드가 127, 0127, 00127로 서로 구별되는 체계라면 숫자 변환은 세 코드를 하나로 합쳐 버리는 셈입니다.

숫자 127에 사용자 지정 표시 형식 00000을 적용하면 셀에서 00127처럼 보이게 만들 수 있습니다. 그러나 밑바탕 값은 숫자 127입니다. 이는 보고서의 자릿수를 맞추는 표시 방법이지 원래 코드의 길이를 알아내는 복구 방법은 아닙니다. Microsoft도 외부 프로그램의 데이터 원본으로 사용하지 않는 통합문서 내 표현과, 코드의 텍스트 보존을 구분해 안내합니다.

별도 열의 =TEXT(A2,"00000")으로 다섯 글자 텍스트를 만드는 방법도 있습니다. 이 수식은 “모든 코드는 정확히 다섯 자리이며 빈자리는 0으로 채운다”는 규칙이 확인된 경우에만 의미가 있습니다. 숫자 127만 남은 상황에서 원래가 네 자리였는지 여섯 자리였는지는 알 수 없습니다. 알려진 규격대로 새 표현을 만드는 일과 잃어버린 원본을 되찾는 일은 구분해야 합니다. TEXT 함수

긴 식별자는 지수 표기보다 끝자리 손실을 봅니다

Excel 숫자는 유효숫자 정밀도가 15자리입니다. 따라서 가상 외부식별자 12345678901234567을 일반 숫자로 입력·변환하면 17자리 전부를 정확히 보존할 수 없습니다. 이미 숫자로 저장되며 손실된 값을 나중에 텍스트 서식으로 바꿔도 원래 끝자리가 살아나지 않습니다. 원본에서 텍스트로 다시 가져와야 합니다.

또 1.23457E+16 같은 지수 표기만 보고 손상 여부를 판정하지 않습니다. 핵심은 표현 방식이 아니라 원래 문자열과의 일치입니다. 열 너비를 늘려 길게 보이게 하는 것, 소수점 표시를 바꾸는 것, 셀을 텍스트 서식으로 지정하는 것은 이미 없어진 마지막 숫자를 추론하지 못합니다. 원본의 두 식별자가 마지막 한 자리만 달랐다면, 변환 뒤 같은 값으로 합쳐지지 않았는지도 확인합니다.

숫자가 모두 들어 있으니 숫자형이 맞겠다는 직감은 수량에는 통하지만 식별자에는 통하지 않습니다. 이런 열에서 필요한 계산은 평균이 아니라 일치 여부입니다. 긴 값을 끝까지 읽고 보존하는 편이, 큰 수를 계산 가능한 형태로 바꾸는 것보다 업무 목적에 맞습니다.

03/04/2026은 그 자체로 날짜의 뜻을 확정하지 못합니다

이 문자열은 월/일/연도 규칙이면 2026년 3월 4일, 일/월/연도 규칙이면 2026년 4월 3일입니다. 양쪽 모두 유효한 날짜이므로 오류가 표시되지 않았다는 사실도 정답의 증거가 아닙니다. 어떤 규칙인지 모르면 원문 텍스트를 남기고, 발신 시스템의 날짜 형식을 먼저 확인합니다.

규칙이 확인되면 원문 열을 보존한 채 복제한 열에서 날짜 변환을 진행하는 방법이 좋습니다. Power Query의 형식 변경(Change Type) → 로캘 사용(Using Locale)에서 날짜형과 원문에 맞는 지역 설정을 지정합니다. 앞의 예시라면 미국식 월/일인지 영국식 일/월인지에 따라 결과가 달라집니다. 변환 후에는 원문과 연·월·일을 따로 대조합니다. 날짜 표시만 yyyy-mm-dd로 바꾸어도 잘못 해석된 월과 일이 자동으로 교정되지는 않습니다. Power Query 자료형

Power Query에서도 ‘Changed Type’ 이전을 확인합니다

텍스트/CSV 가져오기를 사용했다는 이유만으로 손실 방지가 끝난 것은 아닙니다. Power Query는 비정형 원본을 읽으면서 자료형을 자동 추정하고 변경된 유형(Changed Type) 단계를 추가할 수 있습니다. 기본적인 형식 추정은 처음 200개 행을 검사하므로, 앞부분이 숫자뿐인 열의 뒤쪽에 다른 형태의 코드가 나오는 경우도 고려해야 합니다.

편집기의 적용된 단계(Applied Steps)에서 원본(Source), 머리글 승격(Promoted Headers), 변경된 유형을 차례로 선택합니다. 앞 단계에는 00127이 남아 있는데 변경된 유형 이후 127이 된다면 변환 위치가 드러납니다. 긴 식별자도 실제 적용된 숫자형과 각 단계의 값을 함께 확인합니다. Power Query의 정수형과 소수형은 표현 범위가 다르므로, 모든 숫자형 변환이 같은 방식으로 손실을 낸다고 뭉뚱그리지는 않습니다. 최종 Excel 식별자 열은 텍스트로 유지합니다.

해결할 때는 잘못된 숫자 변환 뒤에 텍스트 변환을 하나 더 붙이는 것으로 끝내지 않습니다. 문제의 유형 변경을 수정하거나 해당 단계를 제거해 원본 문자열이 남아 있는 단계에서 텍스트형을 지정합니다. 형식 변경 시 현재 항목 바꾸기(Replace Current) 선택이 제공되면 기존 변환을 바꾸는 방법도 있습니다. 다만 뒤 단계가 그 유형을 전제로 계산하고 있었다면 영향을 다시 살펴야 합니다.

반대로 Source 단계부터 127이고 원본 CSV에도 127이 들어 있다면 Power Query 안에서 앞의 0을 찾을 수 없습니다. 파일이 이미 바뀌었는지, 발신 시스템에서 숫자로 내보낸 것인지 확인해야 합니다. 쿼리 단계를 지우는 일은 쿼리 안의 변환을 되돌리는 것이지 발신 시스템의 과거 상태를 복구하는 작업은 아닙니다.

자동 변환 옵션과 Mac 지원은 적용 범위를 구분합니다

Microsoft의 자동 데이터 변환 옵션은 Microsoft 365용 Excel과 Excel 2024의 Windows·Mac 버전에 제공됩니다. Windows는 파일 → 옵션 → 데이터 → 자동 데이터 변환, Mac은 Excel → 기본 설정(Preferences) → 편집(Edit) → 자동 데이터 변환에서 관련 항목을 확인합니다. 앞자리 0 제거와 긴 숫자 변환 등을 끄는 설정을 사용할 수 있습니다. Excel 2021·2019·2016에 같은 옵션이 있다고 가정하지 않습니다. 자동 데이터 변환 설정

이 설정은 Power Query로 가져온 데이터에는 직접 적용되지 않습니다. 또한 날짜처럼 보이는 연속 문자·숫자 변환 옵션을 껐다고 해서 슬래시로 된 모든 날짜 문자열까지 보호된다고 확대해석해서는 안 됩니다. 정해진 작업에서 옵션을 활용하더라도 쿼리의 열 자료형과 날짜 로캘은 따로 확인합니다. 자동 변환을 줄이는 설정과 원본을 검증하는 절차는 대체 관계가 아닙니다.

Mac에서 Power Query 편집기를 사용하는 절차는 Microsoft 365 구독 여부와 버전도 확인합니다. Microsoft의 Mac 안내는 편집기를 Microsoft 365용 Excel 16.69(23010700) 이상에서 사용할 수 있다고 설명합니다. 자동 변환 옵션이 있는 Mac Excel 2024와 Power Query 편집기 지원을 같은 조건으로 묶지 않습니다. 메뉴가 없다면 사용 중인 에디션에서 지원하는 텍스트 가져오기 경로를 확인합니다. Mac용 Excel의 Power Query

기존 텍스트 가져오기 마법사를 사용하는 환경에서는 구분 기호로 분리된 파일인지 선택하고, 문자 원본과 구분 기호를 확인한 뒤 열별 데이터 형식에서 코드 열을 텍스트로 지정합니다. 날짜는 규칙을 확인한 경우에만 해당 순서로 지정합니다. 파일을 웹 변환 사이트에 올리거나 출처 모르는 매크로를 실행해야만 가능한 작업은 아닙니다. 텍스트 가져오기 마법사

로드 후에는 ‘읽힌 것’이 아니라 ‘같은 값인지’를 검사합니다

미리보기에서 열 경계와 자료형을 정했다면 닫기 및 로드(Close & Load)로 시트에 가져옵니다. 이제 머리글, 데이터 행수, 코드, 긴 식별자, 날짜, 수량을 확인합니다. 미리보기의 몇 줄만 보고 전체가 정상이라고 확정하지 않고, 변환 오류가 있는 행과 후반부의 예외적인 값도 살핍니다. 확인한 규칙은 원본 파일명과 함께 작업 기록에 남겨 재가져오기 때 같은 조건을 적용합니다.

앞의 가상자료가 A열부터 F열까지, 머리글은 1행, 데이터는 2~3행에 놓였다고 하겠습니다. 상품코드 A2는 =ISTEXT(A2)가 TRUE인지 확인하고 =LEN(A2)는 5인지 봅니다. 여기에 =EXACT(A2,"00127")을 사용하면 길이만 같은 다른 코드도 걸러낼 수 있습니다. 외부식별자 B2는 텍스트인지, 길이가 17인지, =EXACT(B2,"12345678901234567")이 TRUE인지 확인합니다. 텍스트 여부·길이·완전 일치를 나눠 검사하는 이유입니다. IS 계열 함수 LEN 함수 EXACT 함수

수량 F2:F3는 숫자로 변환한 뒤 =COUNT(F2:F3)이 2, =SUM(F2:F3)이 5여야 합니다. 두 셀을 텍스트로만 남겨 놓았다면 숫자 셀 개수가 맞지 않을 수 있고, SUM이 텍스트 값을 무시해 기대와 다른 합계를 낼 수 있습니다. 합계를 맞추려고 식별자까지 숫자로 바꾸지 말고 수량 열의 자료형과 오류만 점검합니다. COUNT 함수 SUM 함수

행수는 이 예시에서 머리글을 제외한 2개이며, 열은 6개입니다. 상품명 컵, 대형이 한 셀에 있고 메모에 큰따옴표가 한 쌍 남아야 합니다. 날짜는 원문 규칙이 확정된 뒤 기대하는 월·일과 비교합니다. 순서를 바꾸지 않은 단순 가져오기라면 같은 위치의 원문과 비교할 수 있지만, 정렬이나 필터 처리를 했다면 위치 대신 고유 식별자를 기준으로 찾아야 합니다.

다른 이름으로 저장한 뒤, 받는 환경까지 확인합니다

XLSX 작업본과 CSV 제출본을 분리합니다

검산한 작업 결과는 다른 이름으로 저장(Save As)에서 파일 형식을 Excel 통합 문서(.xlsx)로 선택해 남깁니다. 받은 CSV를 그대로 덮어쓰지 않고 작업용 파일을 따로 만드는 단계입니다. CSV 파일명의 .csv만 .xlsx로 고치는 것은 변환이 아닙니다. 파일을 구성하는 실제 형식이 달라야 하며, 확장자는 그 결과를 나타내는 이름일 뿐입니다.

XLSX에는 원본에 대한 설명, 자료형을 정한 작업 시트, 검산 결과를 함께 보관할 수 있습니다. 반면 CSV 내보내기는 현재 시트를 대상으로 하며 통합문서의 여러 시트와 서식·일부 기능을 그대로 유지하지 못합니다. 따라서 작업본을 먼저 보존하고 제출에 필요한 열만 둔 별도 시트를 CSV로 내보내는 흐름이 관리하기 쉽습니다.

날짜 원문을 보관하기 위해 추가한 열이나 검산용 수식 열까지 그대로 제출하면, 수신 시스템이 기대한 여섯 열과 달라질 수 있습니다. 제출용 시트에서는 열 이름·열 순서·필수 값·자료형별 표현을 다시 맞춥니다. 원본 열을 없애는 작업은 보관용 통합문서가 아니라 제출용 복사본에서 진행합니다.

‘UTF-8 CSV’도 수신 규격의 일부일 뿐입니다

받는 프로그램이 요구하는 인코딩, BOM 허용 여부, 구분자, 날짜 형식, 머리글 유무를 먼저 확인합니다. UTF-8을 요구하면 Excel의 해당 CSV 저장 형식을 사용하되, BOM까지 일치하는지는 수신 규격과 결과 파일로 확인합니다. CP949나 별도의 구분자를 요구한다면 일반 CSV 저장 항목 이름만 보고 충족했다고 단정하지 않습니다. 필요한 설정을 제공하지 않는 환경에서는 발신 시스템의 내보내기 기능 또는 조직에서 승인한 변환 절차를 사용합니다.

CSV는 숫자와 텍스트를 구분하는 Excel 셀 자료형까지 전달하지 않습니다. 코드에 큰따옴표를 씌웠다는 이유만으로 수신 프로그램이 반드시 텍스트로 읽는 것도 아닙니다. 파일에 00127이라는 문자가 정확히 남아 있는지와, 받는 프로그램이 이를 문자열 코드로 받아들이는지를 따로 검사해야 합니다. 이 점은 CSV 인용 규칙과 Excel의 자동 해석을 함께 보면 이해하기 쉽습니다.

검증 순서는 내보낸 파일을 다시 가져와 확인하는 것과 실제 수신 환경에서 확인하는 것으로 나눕니다. 재가져오기는 인코딩·구분자·텍스트형을 지정해 파일의 값을 검사합니다. 수신 환경 확인은 승인된 미리보기나 시험 기능이 있을 때 그것을 이용해, 대상 시스템이 같은 값으로 받아들이는지 봅니다. 검증한다고 실제 거래나 신청을 중복 등록해서는 안 됩니다. 시험 기능이 없다면 담당자와 검증 방법을 먼저 정합니다.

앞의 사례라면 상품 2행, 수량 합계 5, 두 코드의 앞자리 0, 17자리 식별자의 서로 다른 마지막 숫자, 콤마가 든 상품명, 인용부호가 든 메모를 대조합니다. 날짜도 수신 시스템이 요구한 표현으로 전달됐는지 확인합니다. 파일을 다시 Excel에서 더블클릭해 본 결과만으로 통과시키면, 검증 도중 처음과 같은 자동 변환을 다시 겪을 수 있습니다.

문제가 남았을 때는 실패한 단계로 돌아갑니다

한글은 맞는데 열이 하나라면 구분자 단계로, 열은 맞는데 코드가 짧아졌다면 자료형 단계로 돌아갑니다. 일부 행만 밀렸다면 그 행의 인용부호와 줄바꿈을 확인합니다. 값이 맞지만 수신 시스템이 거부한다면 인코딩뿐 아니라 열 이름, 날짜 표현, 빈값 허용 여부 등 입력 규격을 살핍니다. 오류가 난 위치에 맞춰 돌아가야 불필요한 전체 변환을 줄일 수 있습니다.

“숫자를 입력하라”는 표시가 나온다고 코드까지 숫자로 바꾸지 않습니다. 그 입력 항목이 정말 수량인지, 식별코드인데 수신 설정이 잘못된 것인지부터 확인합니다. 원본에 없는 자릿수를 임의로 채우거나 모호한 날짜를 국내에서 익숙한 순서로 확정하면 파일은 통과해도 데이터의 의미가 바뀔 수 있습니다.

완료의 기준은 저장 버튼이 눌렸다는 사실이 아닙니다. 원본이 보존되어 있고, 작업본에서 값과 자료형이 검산됐으며, 제출본이 수신 규격에 맞는 상태입니다. 이 세 파일의 역할을 분리하면 한글 깨짐은 문자 해석으로, 앞자리 0과 긴 식별자는 자료형으로, 전달 오류는 입력 규격으로 좁혀 해결할 수 있습니다. 다음번 같은 파일을 받을 때도 다시 추측할 필요 없이 확인해 둔 가져오기 조건에서 시작할 수 있습니다.