Excel이 CSV 코드의 앞자리 0을 지우는 이유와 이를 지키는 방법 (2026 가이드)

30초 진단: 파일은 멀쩡하고, Excel이 잘못 추측한 것이다

코드의 앞자리 0이 사라졌을 때 가장 먼저 가려야 할 것은 데이터가 손상됐는지, 아니면 잘못 읽힌 것인지이다. 두 경우는 해결 방법이 완전히 다르고, 잘못된 해결 방법은 표시 문제를 실제 데이터 손실로 바꿀 수 있다. 30초 테스트는 다음과 같다. 같은 파일을 일반 텍스트 편집기로 열어 본다. 윈도우의 메모장이나 맥의 일반 텍스트 모드 텍스트편집이 좋다. 거기서 코드가 0을 온전히 보여준다면, 즉 00123, 02138, 07477 그대로 보인다면 데이터는 온전하고 Excel 표시만 잘못된 것이다. 디스크에 있는 파일은 올바른 문자를 갖고 있고, Excel이 파일을 열면서 그 의미를 바꿨을 뿐이다. 이것이 가장 흔한 경우이며, 이 가이드의 모든 해결 방법은 여기서 출발한다.

두 번째 단서는 어떤 값이 바뀌었는지이다. 일반적인 단어와 짧은 숫자, 구두점은 멀쩡한데 앞자리 0이 있는 코드만 0을 잃고, 긴 식별자는 마지막 숫자를 잃고, 큰 숫자가 지수 표기로 보인다면, 이는 구분자 문제도 손상도 아니라 형식 추측 문제이다. 구분자 문제는 행 전체를 한 열에 몰아넣는다. 손상은 모든 것을 뒤섞거나 행을 빠뜨린다. 형식 추측은 정밀하게 작동한다. 숫자로 보이는 값만 바꾸고 나머지는 그대로 둔다. 00123이 123이 되고, 02138이 2138이 되고, 16자리 식별자의 끝에 원래 없던 0이 붙었다면, Excel이 텍스트를 숫자로 취급한 것이며, 원인도 해결 방법도 여기서 바로 알 수 있다.

세 번째 확인은 구조가 아직 가능한지 결정한다. 텍스트 편집기에서도 값이 이미 잘린 상태로 보인다면, 그 파일 사본은 변환 뒤에 다시 저장된 것이며, 0은 그 사본에서는 이미 사라졌을 수 있다. 아직 당황하지 말고, 무엇보다 원본 위에 다시 저장하지 말라. 이 가이드 뒤쪽의 구조 절이 바로 이 경우를 다룬다. 그중에서도 숫자가 진짜로 복구 불가능한 경우는 한 가지뿐이다. 긴 식별자가 15자리로 잘렸을 때 잃어버린 숫자는 그 사본에서 사라진 것이며, 원본 데이터만이 다시 만들 수 있다. 확인하기 전까지는 원본 파일을 건드리지 말고, 사본으로 작업하며, 변환된 파일을 좋은 파일 위에 다시 저장하지 말라.

Excel이 추측하는 이유: CSV 파일에는 형식이 없다

이 문제가 계속 반복되는 이유를 이해하려면 CSV 형식에 대한 한 가지 사실을 알아야 한다. CSV 파일은 일반 텍스트이며, 어떤 값이 숫자이고 어떤 값이 텍스트이고 어떤 값이 날짜인지 알려주는 머리말이 없다. 스프레드시트 파일은 셀 형식을 함께 저장한다. CSV 파일은 형식도 서식도 저장하지 않는다. 문자와 쉼표, 줄바꿈만 있을 뿐이다. 프로그램이 파일을 열면 프로그램이 각 값의 의미를 결정해야 하며, 프로그램마다 결정이 다르다. 구글 시트와 파이썬은 지시하지 않는 한 CSV 값을 텍스트로 유지하므로 같은 파일이 거기서는 올바르게 보인다. Excel은 CSV 파일을 더블 클릭하면 추측한다. 숫자로 보이는 것은 숫자가 되고, 날짜로 보이는 것은 날짜가 되며, 그 추측이 맞았는지 확인하지 않는다.

그 추측이 문제의 전부이다. 숫자는 정의상 앞자리 0이 없다. 숫자 123과 코드 00123은 같은 숫자이지만 같은 코드가 아니다. 우편번호나 SKU, 직원 번호, 전화 앞자리는 수량이 아니다. 숫자로 이루어진 이름표이며, 앞자리 0은 단어의 글자처럼 이름표의 일부이다. Excel은 이를 모른다. 숫자만 보고 숫자 규칙을 적용해 0을 지우는데, 진짜 숫자에서는 0이 정보를 담고 있지 않기 때문이다. 같은 논리가 두 번째 피해도 설명한다. Excel 숫자는 유효 숫자 15자리까지만 유지하므로, 16자리 이상의 식별자는 뒷자리가 0으로 바뀐다. 파일은 바뀌지 않았다. 파일을 읽는 쪽이 문자의 의미를 바꾼 것이다.

이 문제가 JSON에서 변환한 파일에서 자주 나타나는 이유도 설명된다. JSON은 형식을 구분한다. 문자열 "00123"과 숫자 123은 다른 값이며, JSON을 CSV로 변환하면 문자열이 문자 00123으로 그대로 쓰인다. 변환은 올바르다. 열기가 맞지 않는 것이다. 이 페이지의 변환기를 예로 들면, 코드 00123과 00456, 우편번호 02138과 07477, 18자리 주문 번호를 담은 샘플에 실행했을 때 모든 값을 CSV에 바이트 단위로 동일하게 만들어냈고, 따옴표 트릭도 숫자 누락도 없었다. 불일치가 변환 단계가 아니라 열기 단계에 있다는 것을 알면 해결할 위치도 분명해진다. 다음 절에서 설명하는 가져오기 단계에서, Excel이 추측하기 전에 고치는 것이다.

추측이 데이터를 망가뜨리는 세 가지 방식, 그리고 구별 방법

형식 추측은 데이터를 세 가지 서로 다른 방식으로 망가뜨리며, 이를 구별하는 일이 중요한 이유는 일부만 복구할 수 있기 때문이다. 첫째는 앞자리 0 삭제이다. 00123은 123이 되고, 02138은 2138이 된다. 남은 숫자는 맞지만 코드는 틀렸다. 0을 잃은 우편번호는 다른 지역을 가리키고, 0을 잃은 SKU는 창고 시스템과 일치하지 않으며, 바코드 스캐너는 짧아진 코드를 거부할 수 있다. 둘째는 정밀도 절단이다. 15자리를 넘는 식별자는 뒷부분을 잃는다. 16자리 계좌 번호 1234567890123456은 1234567890123450이 되어 1.23457E+15로 표시된다. 마지막 숫자가 숨겨진 것이 아니라 0으로 대체된 것이며, 식별자는 이제 다른 기록을 가리키거나 어떤 기록도 가리키지 않는다.

세 번째 방식은 더 미묘하며, 문제를 고쳤다고 생각하는 사람들을 걸려들게 한다. 지수 표기 표시는 데이터 손실처럼 보이지만 아직은 아닐 수 있다. 1.23E+15로 표시되는 값이 15자리 제한 안에 있다면 전체 숫자가 셀 안에 그대로 남아 있을 수 있으며, 열을 넓히거나 형식을 바꾸면 다시 보인다. 그러나 값이 15자리를 넘으면 표시는 정직하다. 숫자가 정말로 사라진 것이다. 테스트는 수식 입력줄이다. 셀을 클릭하고 셀 표시가 아니라 수식 입력줄을 읽어라. 수식 입력줄에 전체 값이 보이면 표시만 고치면 된다. 수식 입력줄에 잘린 값이 보이면 데이터 자체가 바뀐 것이며, 구조 절만이 도울 수 있다. 코드와 식별자에서는 셀 표시만 믿지 말라.

아래 코드 블록은 이 페이지의 실제 변환기를 세 행 샘플에 실행해 얻은 정확한 출력을 보여준다. CSV 출력은 모든 코드에 대해 JSON 입력과 바이트 단위로 동일하며, 이는 변환기가 범인이 아니라는 증거이다. 오른쪽 열은 같은 값을 더블 클릭했을 때 Excel이 만드는 결과를 보여주며, 이 가이드가 고치는 동작이 바로 그것이다. 패턴에 주목하라. 변환기는 보존하고, Excel은 추측하며, 숫자가 사라지는 곳은 바로 그 추측이다.

CSV file (from this page converter, verified):\nsku,zip,name,orderId\n00123,02138,Widget A,\n00456,07477,Widget B,\n00078,,Widget C,123456789012345678\n\nWhat Excel shows on double-click:\nsku -> 123, 456, 78 (leading zeros dropped)\nzip -> 2138, 7477 (leading zeros dropped)\norderId -> 1.23457E+17, stored as 123456789012345000 (last 3 digits replaced with zeros)

이 표가 증명하는 바에 주목하라. 파일에서는 아무것도 빠지지 않았고, Excel 화면에서는 모든 것이 빠져 있다. 그래서 가져오기 해결 방법이 그토록 완전하게 작동한다. 불러오기 전에 열을 텍스트로 지정하도록 Excel에 알려주면, Excel은 같은 문자를 변환 없이 그대로 저장하고, 모든 코드는 편집도 찾기 및 바꾸기도 데이터 입력도 없이 제자리로 돌아온다. 파일이 이 패턴과 일치한다면 신화 깨기 절을 건너뛰고 가져오기 해결 방법으로 바로 가라. 손상된 파일이 있는 것이 아니다. 잘못 읽힌 파일이 있는 것이다.

작동하지 않는 네 가지 해결 방법, 그리고 사람들이 계속 시도하는 이유

작동하는 해결 방법에 앞서 작동하지 않는 네 가지 해결 방법을 치워두는 것이 좋다. 각각이 시간을 낭비하고, 그중 하나는 상황을 악화시키기 때문이다. 첫째는 CSV에서 값을 따옴표로 감싸는 것이다. 많은 가이드가 "00123"처럼 따옴표를 쓰면 0이 보호된다고 주장한다. Excel에서는 그렇지 않다. Excel은 가져오기 과정에서 따옴표를 제거한 뒤 안쪽 값에 같은 숫자 추측을 적용하므로, "00123"은 따옴표 없는 00123과 똑같이 123이 된다. 따옴표는 값 안의 쉼표를 처리하는 방식을 제어할 뿐, Excel이 값에 부여하는 형식을 제어하지 않는다. 코드를 보호하려고 따옴표를 씌워주는 변환기를 샀다면, 따옴표가 보호하는 것은 쉼표이지 0이 아니다.

둘째는 파일을 연 뒤 열 형식을 텍스트로 바꾸는 것이다. 이는 앞으로 입력되는 항목이 처리되는 방식을 바꾸지만, 파일을 읽을 때 이미 떨어져 나간 숫자를 되돌리지 못한다. 0은 읽는 시점에 버려졌고, 서식은 더 이상 존재하지 않는 문자를 만들어낼 수 없다. 셋째는 00000 사용자 지정 형식으로, 표시를 다섯 자리로 채운다. 고정 길이 코드에 대해서만 표시용으로 작동하며, 숫자가 살아남았을 때만 가능하다. 123은 00123으로 표시되지만 저장된 값은 여전히 123이므로, 내보내면 123이 쓰이고 실제 코드와의 조회는 실패한다. 더 나쁜 점은 가변 길이 코드에서 조용히 실패한다는 것이다. 다섯 자리로 채우려는 여섯 자리 코드는 그대로이고, 다섯 자리로 채우려는 네 자리 코드는 원래 없던 0을 얻는다.

넷째는 코드 앞에 작은따옴표를 붙여 입력하는 요령이다. 작은따옴표와 함께 00123을 입력하면 Excel이 그 항목을 텍스트로 저장하므로 직접 입력하는 값에는 작동한다. 그러나 CSV 가져오기에는 작동하지 않는다. 작은따옴표가 파일 내용의 일부가 되기 때문이다. 작은따옴표 뒤에 숫자가 오는 CSV 셀은 문자 그대로 작은따옴표로 시작하는 텍스트 값으로 가져와지며, 조회와 내보내기를 망가뜨린다. 작은따옴표는 직접 입력하는 항목에 쓰고, 파일에는 가져오기 해결 방법을 사용하라. 어떤 해결 방법이 실패하는지 아는 것은 가장 흔한 함정에서 벗어나게 한다. 표시가 올바르게 보인다는 이유로 문제가 해결됐다고 믿는 동안 저장된 값은 여전히 틀린 상태인 함정이다.

해결 방법 1: 파일을 가져오고 코드 열을 텍스트로 설정한다

이것이 먼저 시도할 해결 방법이다. 시스템도 파일도 바꾸지 않으며, 구분자나 인코딩과 관계없이 모든 CSV에 작동하기 때문이다. 파일을 더블 클릭하는 대신 Excel을 먼저 연 뒤 안내되는 가져오기를 통해 파일을 들여오면, 각 열의 형식을 직접 선택할 수 있다. 가져오기 대화 상자의 미리 보기에서 선택이 맞았는지 즉시 확인할 수 있다. 코드가 미리 보기에서 0과 함께 표시되면 시트에서도 그대로 표시된다. 미리 보기에서 여전히 잘린 코드가 보인다면 아직 아무것도 바꾸지 않은 것이므로, 불러오기 전에 열 형식을 조정할 수 있다.

• ▸빈 통합 문서를 Excel에서 연다. CSV 파일을 더블 클릭하지 않는다.
• ▸데이터, 텍스트/CSV에서 가져오기로 이동해 파일을 선택한다.
• ▸미리 보기 대화 상자에서 구분자와 파일 원본을 확인한 뒤 불러오기가 아니라 데이터 변환을 클릭해 Power Query 편집기를 연다.
• ▸Power Query 편집기에서 자동으로 만들어진 형식 변경 단계를 찾아 제거한다. 숫자 추측이 일어나는 곳이 바로 그 단계이다.
• ▸모든 코드 열, 우편번호와 SKU, 식별자, 전화 앞자리를 선택하고 데이터 형식을 텍스트로 설정한다.
• ▸닫기 및 불러오기를 클릭한다. 코드는 앞자리 0과 모든 숫자가 온전한 텍스트로 들어온다.

CSV 파일을 여는 기본 방식으로 이 방법을 삼아라. 구조용으로만 쓰지 말라. 더블 클릭은 구분자와 인코딩, 모든 열의 형식에 대한 추측이다. 가져오기는 세 가지에 대한 선택이며, 선택에는 1분 정도 더 걸릴 뿐이다. 맥에서도 같은 경로가 데이터, 텍스트에서 가져오기를 통해 작동하며, 열 형식은 가져오기 단계에서 설정한다. 파이썬 csv 모듈처럼 CSV를 일반 텍스트로 읽는 도구는 전혀 추측하지 않으므로, 스크립트에서는 0이 보이고 Excel에서는 보이지 않는 파일이 있다면 그 자체가 진단이다. 파일은 멀쩡하고 Excel이 잘못 추측한 것이다.

해결 방법 2: Excel 자동 데이터 변환을 끈다(Microsoft 365와 Excel 2024)

CSV 파일을 매일 연다면 매번 가져오기는 지겹고, 오래 가는 해결 방법은 Excel이 기본적으로 추측하는 내용을 바꾸는 것이다. 최근 Excel 버전인 Microsoft 365와 Excel 2024, 그리고 맥용 대응 버전에는 파일, 옵션, 데이터 아래에 자동 데이터 변환이라는 설정이 있다. 이 설정은 Excel이 스스로 적용하는 변환 목록을 보여주며, 여기에는 숫자 텍스트에서 앞자리 0 제거, 숫자를 15자리로 절단, 날짜나 지수 표기처럼 보이는 문자와 숫자 조합의 변환이 포함된다. 원하지 않는 변환의 선택을 해제하면 Excel은 앞으로 파일을 열 때, 더블 클릭으로 여는 경우를 포함해 해당 값을 텍스트로 남겨둔다.

이 설정에 의존하기 전에 두 가지 주의점이 있다. 첫째, 앞으로의 동작만 바꾼다. 이미 변환된 셀을 고치지 못하며, 이미 떨어져 나간 숫자를 되돌리지 못한다. 지난주에 연 파일은 통합 문서 안에 여전히 변환된 값을 갖고 있으며, 원본 파일에서 새로 가져와야만 코드가 돌아온다. 둘째, 이 설정은 파일이 아니라 사용자의 컴퓨터에 속한다. 기본 설정을 쓰는 컴퓨터에서 같은 파일을 여는 동료는 여전히 잘린 코드를 보게 되며, 보내는 파일에는 어떤 보호도 따라가지 않는다. 이 설정은 자신의 컴퓨터를 위한 편의 기능으로 여기고, 공유하는 파일에는 가져오기 해결 방법을 믿을 만한 방법으로 여겨라. 열기 시 Excel이 하는 나머지 두 가지 추측인 구분자와 인코딩은 한 열 문제와 인코딩 문제에 대한 동반 가이드에서 다루며, 아래 관련 가이드에 연결되어 있다.

해결 방법 3: 직접 만드는 파일은 원본에서 코드를 텍스트로 유지한다

CSV를 직접 만든다면 가장 강력한 해결 방법은 Excel에 닿기 전에 원본 데이터를 모호하지 않게 만드는 것이다. JSON에서는 코드를 문자열로 유지한다는 뜻이다. 문자열 "00123"은 문자 00123으로 변환되지만, 숫자 123은 0을 보존할 여지 없이 123으로 변환된다. 이는 변환기 설정이 아니라 원본 데이터 결정이다. 원본 숫자가 한 번도 갖지 못한 0을 어떤 변환기도 만들어낼 수 없기 때문이다. 원본 시스템이 이미 우편번호를 숫자로 저장하고 있다면 0은 변환 전에 사라진 것이며, 고정 너비 문자열로 다시 내보내는 등 원본 시스템만이 되돌릴 수 있다.

이미 0을 잃었지만 길이가 고정된 값에는 정당한 재구성 방법이 하나 있다. 바로 TEXT 함수이다. 한 열의 모든 코드가 다섯 자리라면 =TEXT(A2,"00000")은 잘린 숫자에서 표시와 텍스트 값을 다시 만드는데, 이는 빠진 숫자가 모두 0이고 그 개수가 알려졌기 때문이다. 결과를 복사해 값으로 붙여넣어 고정한다. 그러나 이는 길이가 고정되고 피해가 앞자리 0 삭제뿐일 때만 작동한다. 잘린 긴 식별자는 재구성할 수 없다. 잃어버린 숫자는 0이 아니라 0으로 대체된 알 수 없는 숫자였고, 어떤 수식도 이를 추측할 수 없기 때문이다. 식별자의 길이가 제각각이거나 15자리를 넘는다면 채우지 말고 원본에서 다시 생성하라.

이미 잘린 코드로 저장된 파일을 구조한다

지금까지의 모든 해결 방법은 디스크에 있는 파일이 여전히 올바르고 Excel 화면만 잘못됐다고 가정했다. 그러나 잘린 버전이 이미 저장된 경우도 있으며, 이때 문제는 저장된 사본에서 원래 코드를 아직 복구할 수 있는지이다. 답은 저장 과정에서 정확히 무슨 일이 일어났는지에 달려 있으며, 구별해야 할 두 가지 경우가 있다. 첫 번째 경우, 디스크에 있는 파일은 여전히 원래 문자를 갖고 있고 통합 문서 표시만 잘못됐다. 이는 텍스트 편집기 테스트가 찾아내는 경우이다. 편집기가 0을 보여주므로 잃은 것은 없으며, 해결 방법 1이 화면을 고친다. 두 번째 경우, 디스크에 있는 파일은 이제 잘린 값 자체를 담고 있다. 누군가 Excel에서 파일을 열고 짧아진 코드를 본 뒤 CSV로 다시 저장해 변환된 값을 파일에 썼기 때문이다.

두 번째 경우는 좁은 상황에서만 복구할 수 있다. 모든 코드의 길이가 고정되고 피해가 앞자리 0 삭제뿐이라면 해결 방법 3의 TEXT 함수가 이를 다시 만드는데, 이는 빠진 문자가 0임이 알려졌기 때문이다. 유일한 버전이 아니라 사본으로 작업하고, Excel에서 다시 열기 전에 텍스트 편집기에서 결과를 확인하라. 피해가 정밀도 절단이라면, 즉 15자리를 넘는 식별자의 뒷부분이 0으로 대체됐다면 원래 숫자는 그 사본에서 사라진 것이다. 어떤 디코딩이나 서식, 수식도 자리 표시자로 대체된 숫자를 복구할 수 없다. 자리 표시자는 대체한 숫자에 대한 정보를 담고 있지 않기 때문이다. 이 경우 사본 고치기를 멈추고 원본에서 파일을 다시 생성하라. 데이터베이스나 도구, 원래 JSON에서 다시 내보내고, 이번에는 해결 방법 1로 열어라. 그리고 무엇을 하든 재생성된 파일이 제대로 확인될 때까지 손상된 사본을 옆에 두어라. 대체 파일을 확인하기 전에 유일한 사본을 삭제하는 것이 복구 가능한 문제를 잃어버린 데이터셋으로 만드는 방법이다.

이 페이지 변환기에서 나온 파일에 대한 의미

이 페이지의 변환기는 바로 이 가이드가 다루는 종류의 파일을 만들므로, 그 동작을 솔직하게 밝힐 가치가 있다. 다운로드 파일은 JSON이 갖고 있는 코드를 정확히 보존한다. 이는 가정한 것이 아니라 실제 코드로 검증했다. 변환 엔진은 코드 00123, 00456, 00078과 우편번호 02138, 07477, 18자리 주문 번호 123456789012345678를 담은 세 행 샘플에 실행됐고, 모든 값을 CSV에 바이트 단위로 동일하게 만들어냈다. 코드는 구분자를 포함하지 않으므로 따옴표 없이, 긴 식별자는 손대지 않고 만들어졌다. 따라서 변환한 파일이 Excel에서 잘린 코드로 보인다면 변환이 아무것도 손상시키지 않은 것이다. 파일은 올바르고, Excel이 더블 클릭 시 형식을 추측한 것이다.

변환한 파일에 대한 선택지는 두 가지로 깔끔하다. 첫째는 가져오기 경로이다. 다운로드한 파일을 데이터, 텍스트/CSV에서 가져오기로 열고, 데이터 변환을 클릭한 뒤 모든 코드 열을 텍스트로 설정하고 불러온다. 코드는 올바르게 읽히며, 파일에 대해 아무것도 바꾸지 않았으므로 다른 모든 도구에도 유효하게 남는다. 둘째는 자신의 컴퓨터를 위한 해결 방법 2의 자동 변환 설정이다. 형식 추측 표시 문제를 고치려고 데이터를 다시 변환하지 말고, 변환한 출력을 스프레드시트에 붙여넣고 다시 저장하지 말라. 그 왕복 과정은 이 가이드와 동반 가이드가 막으려고 존재하는 구분자와 인코딩, 형식 불일치를 그대로 불러올 수 있기 때문이다. 데이터를 고치지 말고 열기를 고쳐라.

변환기에 대한 세부 사항이 하나 더 중요하다. 변환기는 다운로드 전에 구분자를 선택하게 하며, 그 선택은 형식 추측과 별개이다. 파일은 구분자는 맞는데 코드는 잘린 상태일 수도 있고, 코드는 맞는데 구분자는 틀린 상태일 수도 있으며, 둘 다 틀린 상태일 수도 있다. 변환한 파일이 한 열로 열리고 코드도 잘못 보인다면 같은 가져오기에서 두 가지 설정을 모두 고쳐라. 변환 시 선택한 구분자를 고르고 코드 열을 텍스트로 설정한다. 한 열 문제에 대한 동반 가이드는 구분자 절반을 자세히 다루고, 인코딩 가이드는 문자 절반을 다루며, 둘 다 아래 관련 가이드에 연결되어 있다.

예방 체크리스트: 아무도 고치지 않아도 되게 코드를 내보낸다

형식 추측은 쓰는 쪽과 읽는 쪽 사이의 불일치이므로, 예방이란 쓰는 쪽이 값의 의미를 읽는 쪽이 받아들일 방식으로 선언하게 한다는 뜻이다. CSV를 만들 때 이 체크리스트를 실행하면 다음에 파일을 여는 사람은 이 가이드가 필요 없어진다. 첫째, 원본에서 코드를 문자열로 유지한다. 데이터에 우편번호나 SKU, 식별자가 있다면 원본 시스템에서 텍스트로 저장하라. 숫자 형식은 어떤 내보내기가 일어나기 전에 0을 떨어뜨리기 때문이다. 둘째, 대상이 Excel이라면 파일 여는 방법을 알려준다. 코드 열을 텍스트로 설정해 가져오라는 한 줄 메모가 문제 전체를 막으며, 파일과 함께 넣는 데 비용이 들지 않는다.

셋째, 구조한 파일을 텍스트 편집기에서 확인하기 전에는 원본 위에 다시 저장하지 않는다. Excel에서 저장하면 형식을 비롯해 구분자와 인코딩을 Excel 자체 기본값으로 다시 쓰게 되며, 이는 다음 읽는 사람에게 불일치를 다시 불러오거나 표시 문제를 실제 데이터 손실로 바꿀 수 있다. 넷째, 파일을 받았을 때 뭔가 이상해 보인다면 먼저 텍스트 편집기에서 열고, 스프레드시트가 그 위에 저장하게 두기 전에 코드를 확인한다. 다섯째, 원본 데이터를 보관한다. CSV는 평평하게 만든 스냅샷이지 데이터 자체가 아니므로, 구조가 잘못되면 원본이 손상된 사본을 고치는 대신 깨끗하게 다시 내보낼 수 있게 한다. 대부분의 코드 관련 끔찍한 이야기는 손상된 CSV가 유일한 사본이었음을 너무 늦게 깨닫는 것으로 끝난다. 그 파일이 당신의 파일이 되지 않게 하라.

관련 가이드

• CSV가 Excel에서 한 열로 열리는 이유와 해결 방법 (2026 가이드) →
• Excel에서 CSV가 깨진 문자로 보이는 이유와 인코딩 해결 방법 (2026 가이드) →
• JSON을 CSV로 변환하는 방법: 확실한 3가지 방법 (2026 가이드) →
• 엑셀에서 CSV 날짜가 바뀌는 이유와 날짜를 그대로 지키는 방법 (2026 가이드) →
• 엑셀에서 CSV를 저장하면 파일이 바뀌는 이유와 원본을 안전하게 지키는 방법 (2026 가이드) →
• 엑셀로 열리지 않는 큰 CSV 파일, 원인과 해결 방법 (2026 가이드) →

자주 묻는 질문