CSV 앞자리 0·긴 숫자·날짜 자동 변환을 막는 법

CSV 원문에는 00123, 1234567890123456, 1-2가 그대로 있는데 Excel에서 파일을 열자 123, 1.23457E+15, 날짜 값으로 보일 수 있습니다. 이때 먼저 구분해야 할 것은 CSV 파일에 저장된 값과 Excel이 셀에 가져오면서 해석한 값입니다.

CSV는 셀의 표시 형식이나 데이터 타입을 저장하지 않는 텍스트 형식입니다. Excel은 CSV를 열 때 각 열이 숫자인지 날짜인지 자동으로 판단할 수 있습니다. 화면에서 값이 달라진 뒤 같은 파일에 덮어쓰면, 처음에는 원문에 남아 있던 정보까지 실제로 사라질 수 있습니다.

따라서 가장 먼저 원본 CSV를 별도로 보관하고, 자동 변환된 통합 문서를 원본 파일명으로 저장하지 않아야 합니다.

세 가지 위험은 서로 다릅니다

원본 문자열	Excel에서 생길 수 있는 변화	잃을 수 있는 정보
`001234`	`1234`	앞자리 0 두 개
`1234567890123456`	끝자리가 다른 숫자 또는 지수 표기	15자리를 넘는 정밀도
`1-2`, `3/4`, `2026-08`	날짜 또는 월·일 값	코드로서의 원문

화면에 지수 표기로 보인다고 항상 원본 숫자가 손상된 것은 아닙니다. 열 너비나 표시 형식 때문에 그렇게 보일 수도 있습니다. 반대로 셀 표시를 텍스트로 바꿔 원래처럼 보이게 했더라도, 이미 가져오기 단계에서 끝자리가 바뀌었다면 표시 형식만으로 복구할 수 없습니다. 원본 CSV의 실제 문자열과 비교해야 합니다.

앞자리 0은 숫자 크기가 아니라 값의 일부일 수 있습니다

전화번호, 우편번호, 사번, 상품 코드와 회계 코드의 앞자리 0은 자릿수를 맞추기 위한 값일 수 있습니다. 00123과 123이 같은 대상을 뜻한다고 도구나 Excel이 임의로 판단해서는 안 됩니다.

CSV에서 값을 큰따옴표로 감싼다고 열 타입이 텍스트로 고정되는 것도 아닙니다.

고객번호,전화번호
"00123","01012345678"

이 따옴표는 쉼표와 줄바꿈 같은 문자를 한 필드 안에 담기 위한 CSV 문법입니다. RFC 4180도 큰따옴표를 필드 구분과 이스케이프 규칙으로 설명하며 열의 데이터 타입은 정의하지 않습니다. Excel이 그 필드를 숫자로 해석할지까지 지정하지 않으므로, 앞자리 0을 지켜야 한다면 가져오기 단계에서 해당 열을 텍스트 형식으로 지정해야 합니다.

16자리 이상 숫자는 표시 문제가 아니라 정밀도 문제일 수 있습니다

Excel 숫자는 유효 숫자 15자리까지만 정확하게 유지할 수 있습니다. 주문 식별자, 카드·계좌와 비슷한 긴 코드, 장비 일련번호를 숫자로 가져오면 16번째 이후 자리가 0이나 다른 값으로 바뀔 수 있습니다.

예를 들어 1234567890123456은 계산을 위한 수량이 아니라 식별자라면 숫자로 연산할 이유가 없습니다. 처음부터 텍스트로 가져와야 합니다. Microsoft의 앞자리 0과 큰 숫자 안내도 16자리 이상의 숫자 코드를 텍스트 형식으로 처리하는 방법을 설명합니다.

이미 Excel에서 숫자로 변환한 뒤 CSV나 XLSX로 저장했다면 사라진 끝자리를 파일만 보고 알아낼 수 없습니다. 이 경우에는 변환 전 원본이나 데이터를 만든 시스템에서 다시 받아야 합니다.

날짜처럼 보이는 코드는 자동 변환 대상이 될 수 있습니다

1-2는 1월 2일일 수도 있지만 창고 위치, 규격, 분류 코드일 수도 있습니다. 3/4도 날짜, 분수 또는 코드 중 무엇인지 문자열만 보고 확정할 수 없습니다. 자동 변환은 화면을 편하게 만들 수 있지만 원래 의미를 모르는 상태에서는 손실이 됩니다.

다음 값은 특히 원본과 비교해야 합니다.

하이픈이나 슬래시가 들어간 분류 코드
연도와 월만 있는 2026-08 형식
03-04처럼 월과 일을 어느 순서로 썼는지 모호한 값
숫자만 있지만 고정 자릿수를 유지해야 하는 20260801 형식

CSV 데이터 정리 도구도 이런 값을 날짜로 추측해 자동 변경하지 않습니다. 업무 규칙상 바꿔야 할 값이 명확하다면 CSV 데이터 정리 도구에서 적용할 열과 규칙을 직접 선택하고 변경 전·후를 확인하세요. 이미 사라진 앞자리나 바뀐 날짜 원문을 추측해 복구하는 기능은 아닙니다.

Excel에서 안전하게 가져오는 순서

CSV를 더블클릭해 바로 연 뒤 저장하는 흐름보다 가져오기 화면에서 열별 형식을 확인하는 편이 안전합니다.

원본 CSV를 복사하고 원본은 닫아 둡니다.
Excel에서 데이터 → 텍스트/CSV에서 파일을 선택합니다.
문자 인코딩과 구분자가 맞는지 미리보기에서 확인합니다.
미리보기에서 바로 불러오지 말고 데이터 변환 또는 편집을 선택해 Power Query 편집기로 들어갑니다.
전화번호, 우편번호, 식별번호와 날짜 유사 코드 열을 선택한 뒤 홈 → 데이터 형식 → 텍스트로 바꾸고, 형식 변경 창에서는 현재 항목 바꾸기를 선택합니다.
닫기 및 로드로 시트에 가져온 뒤 첫 행뿐 아니라 중간·마지막 행의 대표 값을 원본과 대조합니다.
작업 결과는 XLSX처럼 원본 CSV와 다른 파일명과 형식으로 저장합니다.

Excel 버전과 가져오기 화면에 따라 열 타입 선택 위치가 다를 수 있습니다. Microsoft의 텍스트·CSV 가져오기 안내는 가져오기 마법사와 데이터 가져오기 흐름을 설명합니다.

Power Query를 사용하는 경우에도 자동으로 추가된 변경된 유형 단계가 원하는 열을 숫자나 날짜로 바꾸지 않았는지 확인해야 합니다. 열 이름 옆의 형식과 적용된 단계를 검토한 뒤 불러오세요.

Python과 pandas에서는 문자열 열을 명시하세요

코드에서도 자동 타입 추론을 피하려면 우선 문자열로 읽고 필요한 열만 별도로 변환합니다.

import pandas as pd

df = pd.read_csv(
    "customers.csv",
    encoding="utf-8-sig",
    dtype=str,
    keep_default_na=False,
)

dtype=str은 모든 업무 규칙을 검증해 주는 옵션이 아닙니다. 하지만 파일에 있는 문자열을 먼저 보존한 뒤, 날짜·금액처럼 실제 계산이 필요한 열만 명시적으로 변환할 수 있게 합니다. 인코딩이나 구분자가 맞지 않으면 문자열로 읽기 전에 다른 문제가 생길 수 있으므로 pandas CSV 오류 가이드의 진단 순서를 함께 확인하세요.

CSV와 XLSX 중 무엇을 써야 할까요?

두 형식의 목적이 다릅니다.

형식	장점	보존하지 못하거나 주의할 점
CSV	구조가 단순하고 여러 시스템에서 교환하기 쉬움	열 타입, 표시 형식과 여러 시트 같은 통합 문서 기능을 저장하지 않으며 수식처럼 보이는 문자열도 프로그램마다 다르게 해석될 수 있음
XLSX	셀 타입과 표시 형식, 여러 시트와 서식을 저장할 수 있음	잘못 가져온 CSV 원문을 자동 복구하지 않음

CSV는 시스템 간 전달용 원본으로 유지하고, 사람이 Excel에서 검토하거나 열별 텍스트 형식을 보존해야 한다면 올바른 가져오기 설정을 거친 뒤 XLSX 작업본을 별도로 만드는 방법이 실용적입니다. XLSX로 저장했다는 사실만으로 이미 변환된 값이 원래대로 돌아오지는 않습니다.

데이터 응급실에서 먼저 확인할 것

CSV 파일 진단 도구는 원본을 바꾸지 않고 앞자리 0, 16자리 이상 정수, 날짜처럼 보이는 문자열과 수식으로 해석될 수 있는 값을 찾아 실제 행과 함께 보여 줍니다. 다음 상황에서 먼저 사용하세요.

어떤 열과 행이 자동 변환 위험에 해당하는지 모를 때
한글 인코딩과 구분자도 함께 확인해야 할 때
Excel에서 열기 전에 원본 문자열을 보고서로 남기고 싶을 때

CSV 데이터 정리 도구는 사용자가 선택한 열과 규칙만 새 사본에 적용합니다. 앞뒤 공백이나 문자 표현을 같은 기준으로 정리하는 데 사용할 수 있지만, CSV 자체에 텍스트 열 타입을 저장하거나 Excel의 자동 변환을 막는 형식으로 바꾸지는 않습니다.

저장 전 마지막 확인표

원본 CSV를 별도로 보관했는가?
앞자리 0이 있는 대표 값이 원문과 같은가?
16자리 이상 식별번호의 첫 자리와 마지막 자리가 모두 같은가?
날짜처럼 보이는 코드가 원래 문자열로 남아 있는가?
총 행 수와 열 수가 가져오기 전과 같은가?
자동으로 건너뛴 행이나 빈 값으로 바뀐 셀이 없는가?
결과를 원본 CSV와 다른 파일명으로 저장했는가?

가장 중요한 기준은 화면이 보기 좋게 열렸는지가 아니라 원본 문자열과 행·열 구조가 의도대로 유지됐는지입니다. 이미 값이 바뀌었다면 같은 파일을 계속 수정하기보다 보존해 둔 원본에서 다시 시작하세요.