CSV를 열었더니 품목 코드의 앞자리 0이 사라질 때

품목 00123을 123으로 바꾸면 생기는 문제

품목 ID는 계산할 숫자가 아니라 대상을 구분하는 이름입니다. 00123과 123을 서로 다른 코드로 사용한다면 앞의 0이 사라지는 순간 다른 품목으로 연결될 수 있습니다. 화면에 00123처럼 보이도록 서식을 바꾸는 것과 원래 문자열을 보존하는 것은 다릅니다. 이 글에서는 작은 CSV 하나로 가져오기 전후를 대조합니다.

식별자 보존 시험 CSV 내려받기

세 행은 실제 거래와 무관한 샘플입니다. 수량 열만 계산용 숫자이고 ID는 문자입니다. CSV에서 필드를 큰따옴표로 둘러싼 것만으로 스프레드시트가 반드시 문자로 가져오는 것은 아닙니다. 따옴표는 CSV 구문이며, 열의 자료형은 가져오는 프로그램이 정할 수 있습니다.

먼저 원본을 텍스트로 확인하기

파일을 바로 더블클릭해 덮어쓰지 말고 원본 사본을 남깁니다. 텍스트 편집기에서 첫 줄의 품목 ID·품목명·수량과 세 행을 확인합니다. 원본에 이미 123으로 저장돼 있다면 어떤 자리수였는지 별도 기준 없이 복원할 수 없습니다. 무조건 앞에 0을 붙이는 정리는 원본 보존이 아닙니다.

"품목 ID","품목명","수량"
"00123","종이컵","80"
"00007","영수증 용지","5"
"12345678901234567","포장 봉투","38"

가져오기에서 자동 변환을 확인하기

구글시트의 파일 가져오기 창에 텍스트를 숫자·날짜·수식으로 변환하는 옵션이 표시되면 식별자 시험에서는 변환을 끄고 가져옵니다. 프로그램과 가져오기 경로마다 화면이 다르므로 완료 뒤 값 검사가 필요합니다. 다른 방법은 ID 열을 일반 텍스트로 지정한 빈 시트에 원문을 옮긴 뒤 수량 열만 숫자로 바꾸는 것입니다.

Excel에서는 텍스트/CSV 가져오기 과정에서 해당 열의 데이터 형식을 텍스트로 정하는 방식을 사용합니다. 이미 숫자로 변환된 값을 나중에 텍스트 형식으로 바꿔도 사라진 0이나 반올림된 자릿수가 돌아오지는 않습니다. 그때는 저장하지 않은 원본에서 다시 시작합니다.

모양 대신 실제 값을 대조하기

원본과 같은 행 수만 확인해서는 부족합니다. ID 열의 길이와 정확한 문자열, 수량 합계까지 서로 다른 관점으로 확인합니다. 80+5+38은 123입니다. 수량을 문자로 가져왔다면 계산 전에 숫자로 변환하되 ID 열까지 함께 변환하지 않습니다. 값이 0인 수량과 빈칸인 수량도 구분합니다.

다시 CSV로 저장한 뒤 한 번 더 확인하기

검사가 끝난 시트를 CSV로 내보내고 텍스트 편집기에서 다시 엽니다. 저장 전 화면과 달리 출력 파일에 123이 들어 있다면 전달용 파일은 아직 틀린 상태입니다. 반대로 텍스트 파일에 00123이 남아 있다면 상대 프로그램의 가져오기 설정이 다음 확인 대상입니다. 전달할 때는 ID 열은 문자열이라는 설명을 같이 보냅니다.

이 샘플 파일은 배포 시 원문 문자열과 열 수를 대조했습니다. 모든 스프레드시트 프로그램에서 가져오기를 시험했다는 뜻은 아닙니다. 실제 사용하는 환경의 이름과 가져오기 경로, 세 ID의 대조 결과를 남겨야 다음 담당자가 같은 설정을 반복할 수 있습니다.

실무 파일에서 더 확인할 값

주문번호, 우편번호, 긴 일련번호, 날짜처럼 보이는 제품명도 같은 문제를 겪을 수 있습니다. 특히 03-04 같은 값은 날짜로 해석될 수 있으므로 그 열이 달력 날짜인지 제품 코드인지 먼저 정합니다. 사용자가 입력한 문자열을 CSV로 내보낼 때는 수식으로 해석될 수 있는 값도 별도 검사해야 합니다. 이 글의 샘플에는 외부 수식을 넣지 않았습니다.

이 글에서 사용한 원문

• Microsoft Excel의 선행 0과 큰 숫자 — 표시 형식과 입력값 보존의 차이를 확인하는 공식 안내입니다.
• RFC 4180 CSV 형식 — CSV의 필드·따옴표 규칙을 확인합니다. 스프레드시트 자료형을 지정하는 규격은 아닙니다.