작성일 2026.10.17수정일 2026.10.10작성 SOPBiz 운영자

03-04를 보고 날짜인지 먼저 묻기

품목 코드 03-04를 CSV로 열었는데 3월 4일처럼 보이면 셀 표시를 텍스트로 바꾸는 것만으로 원래 코드를 되찾지 못할 수 있습니다. 프로그램이 이미 날짜 값으로 변환했을 가능성이 있기 때문입니다. 날짜를 의도한 03-04도 연도와 월·일 순서가 빠져 있어 확정할 수 없습니다. 같은 문자열을 코드 열과 날짜 열에서 다르게 다루는 계약이 필요합니다.

이 글의 대상은 코드가 날짜처럼 보이는 데이터와 실제 날짜 데이터가 한 파일에 섞인 경우입니다. 앞자리 0을 보존하는 문제를 넘어 열마다 어떤 의미와 자료형으로 가져올지 정합니다. 아래 예제는 원문을 그대로 둔 설명용 8행이며 실제 파일을 특정 프로그램에서 가져와 검증한 경험을 주장하지 않습니다.

열 이름만으로 자료형을 추측하지 않기

코드 열은 문자열로 유지하고 날짜 열은 연·월·일이 있는 날짜인지 검사한 뒤 변환합니다. “번호”처럼 넓은 이름보다 품목 코드, 적용일처럼 역할을 드러내는 이름을 사용합니다. 원문 문자열, 열 역할, 입력 형식, 변환 결과, 판정을 나눠두면 원래 03-04가 무엇을 뜻했는지 확인할 수 있습니다.

날짜 입력 계약은 이 예제에서 YYYY-MM-DD로 정했습니다. 2026-03-04는 허용하지만 03-04는 연도 미확인으로 보류합니다. YYYY-DD-MM이나 지역별 M/D/Y를 자동으로 혼용하지 않습니다. 계약이 다른 원본을 받으면 원본 형식을 따로 정의하고 변환 열에서 같은 기준으로 맞춥니다.

코드는 날짜처럼 보이더라도 날짜 변환 대상이 아닙니다. 03-04, 2026-03-04, 01E03 모두 코드 열에서는 원문 그대로 비교할 수 있어야 합니다. 의미를 알 수 없는 코드에 날짜 형식을 씌우지 않습니다. 날짜열과 코드열의 값이 비슷하다는 사실이 자료형을 같게 정할 이유는 아닙니다.

03-04가 날짜로 바뀔 때: 날짜 열과 코드 열을 분리하는 법의 설명용 사례표
제공 CSV의 설명용 사례를 표로 렌더링했습니다. 가상 데이터입니다. 실제 현장 성과·기록을 나타내지 않습니다.

정상 날짜·불명 날짜·코드를 나누어 읽기

D-01의 코드 03-04와 D-04의 코드 2026-03-04는 둘 다 원문 보존입니다. D-02는 실제 날짜 역할의 2026-03-04라 형식과 존재 여부를 통과하면 같은 날짜로 변환할 수 있습니다. D-03은 날짜 역할이지만 연도가 없으므로 변환값을 비워 둡니다.

D-05의 2026-02-30은 모양이 계약과 같아도 실제로 존재하지 않는 날짜입니다. D-06의 2026-12-31은 연말 경계의 정상 날짜입니다. D-07의 01E03은 지수 표기로 바뀔 수 있는 코드라 문자열로 유지합니다. D-08은 날짜가 빈 상태로 값 확인이 필요합니다. 변환 실패를 오늘 날짜나 0으로 대신 채우지 않습니다.

행 ID 열 역할 원문 문자열 입력 계약 변환·보존 값 판정
D-01 품목 코드 03-04 텍스트 03-04 원문 보존
D-02 적용일 2026-03-04 YYYY-MM-DD 2026-03-04 날짜 가능
D-03 적용일 03-04 YYYY-MM-DD 연도·순서 확인
D-04 품목 코드 2026-03-04 텍스트 2026-03-04 원문 보존
D-05 적용일 2026-02-30 YYYY-MM-DD 날짜 범위 오류
D-06 적용일 2026-12-31 YYYY-MM-DD 2026-12-31 날짜 가능
D-07 품목 코드 01E03 텍스트 01E03 원문 보존
D-08 적용일 YYYY-MM-DD 값 확인

이 글의 기록 양식 내려받기

03-04가 날짜로 바뀔 때: 날짜 열과 코드 열을 분리하는 법 — CSV 양식

UTF-8 BOM이 있는 기록용 CSV입니다. 계산식·드롭다운·서식은 들어 있지 않습니다. 첫 행 6열, 설명용 데이터 8레코드가 있습니다.

설명용 8행입니다. CSV에는 열 자료형 지정이 없으므로 가져온 환경에서 원문 문자열과 날짜 의미를 확인해야 합니다. 변환·보존 값은 자동 수식이 아닌 예시값입니다.

CSV 구조와 식별자 점검 도구에서 사본의 열 수와 문자열을 확인할 수 있습니다.

자동 변환 옵션과 가져오기 경로를 확인하기

Microsoft의 Excel 공식 문서는 해당 버전의 자동 데이터 변환 선택지를 설명합니다. 일부 날짜처럼 보이는 문자·숫자 조합의 변환을 끌 수 있지만 공백이나 다른 기호가 있는 형태는 여전히 날짜로 읽힐 수 있다고 안내합니다. 따라서 특정 옵션 하나를 껐다는 사실만으로 모든 코드 보존이 끝났다고 판단하지 않습니다.

가능하면 파일을 더블클릭해 바로 열기보다 열별 형식을 지정할 수 있는 가져오기 경로를 사용합니다. 코드 열을 텍스트로 정하고, 날짜 열은 원문을 먼저 확보한 뒤 변환합니다. 실제 메뉴는 프로그램·버전·운영체제마다 다를 수 있으므로 사용하는 환경과 경로를 기록합니다. 다른 담당자가 같은 파일을 열어도 같은 설정을 재현할 수 있어야 합니다.

구글시트에서도 붙여넣기, 가져오기, 기존 시트 서식이 같은 결과를 내는지 단정하지 않습니다. 원문 셀과 가져온 셀의 실제 문자열, 길이, 자료형을 대조합니다. 화면에 03-04가 보이더라도 내부 날짜 값에 사용자 표시 형식을 적용한 것인지 확인해야 합니다. 코드 검사는 문자 동일성, 날짜 검사는 날짜 구성요소의 의미를 봅니다.

DATEVALUE를 계약 없는 추측에 쓰지 않기

Google Sheets 공식 문서에 따르면 DATEVALUE가 이해하는 형식은 지역·언어 설정의 영향을 받을 수 있습니다. 따라서 03-04에 DATEVALUE를 적용해 숫자가 나왔다는 사실은 3월 4일로 확정했다는 근거가 아닙니다. 결과가 4월 3일이거나 현재 연도를 보충한 값일 수 있는지 원본 계약과 비교해야 합니다.

YYYY-MM-DD 입력을 다루는 경우 문자열 길이와 하이픈 위치, 숫자 구성요소를 먼저 확인한 뒤 연·월·일을 분리합니다. DATE로 구성한 결과가 원래 연·월·일과 같은지 다시 대조합니다. DATE는 범위 밖 월·일을 다른 날짜로 재계산할 수 있으므로 함수가 오류 없이 날짜를 반환했다는 이유만으로 입력을 허용하지 않습니다.

예를 들어 2026-02-30의 구성요소를 DATE에 넣으면 다른 달로 넘어가는 값이 만들어질 수 있습니다. 이 예제의 규칙은 원래 월 2·일 30이 결과와 같은지 확인해 다르면 보류합니다. 자동 보정된 날짜를 원본이 의도한 일정으로 저장하지 않습니다. 소수 연·월·일도 정수 입력 계약에 맞지 않으므로 변환 전에 검사합니다.

원문 대조와 재저장을 별도 시험으로 하기

첫 번째 시험은 코드 03-04가 정확히 다섯 문자로 남는지, 01E03이 다섯 문자로 남는지 확인합니다. 두 번째는 날짜 2026-03-04가 연 2026·월 3·일 4로 해석되는지 확인합니다. 세 번째는 결과를 CSV로 다시 저장한 뒤 텍스트 편집기에서 원문 형태가 어떻게 나갔는지 대조합니다.

프로그램 내부의 날짜 값을 CSV로 내보낼 때 표시 형식에 따라 3/4/2026처럼 바뀔 수 있습니다. 재배포 계약이 YYYY-MM-DD라면 내보내기 열의 형태를 다시 맞추고 그 열이 다음 환경에서 어떻게 읽히는지 확인합니다. 코드가 정상이어도 날짜 출력 형식이 계약과 다르면 같은 파일 전체가 배포 가능한 상태는 아닙니다.

원본을 덮어쓰지 않고 가져오기 전 원본, 변환 작업본, 다시 내보낸 사본을 따로 둡니다. 문제가 생겼을 때 날짜 값으로 변형된 작업본에서 코드를 추정 복원하기보다 원본 문자열로 다시 시작하는 편이 분명합니다. 가져온 뒤 수량·키·기간 조회에 사용하기 전에 문자열과 날짜 의미 검사를 완료합니다.

두 자리 연도와 모호한 구분자의 처리

26-03-04가 2026년을 뜻하는지 다른 코드인지 입력 계약 없이 정하지 않습니다. 이 예제는 네 자리 연도를 요구하므로 확인 대상으로 둡니다. 지역별로 세기를 보충하는 프로그램 동작에 기대지 않습니다. 하이픈 대신 슬래시를 허용하려면 구분자와 월·일 순서를 명시한 별도 형식을 추가합니다.

빈 날짜는 일정 없음인지 미입력인지 구분해야 합니다. 날짜 값 자체를 1900년이나 1970년 같은 기준일로 대체하면 유효기간 조회에서 오래된 정상 날짜처럼 보일 수 있습니다. 상태 열에 미입력 또는 해당 없음의 근거를 남기고 날짜 범위를 계산하는 대상에서는 분리합니다.

잘못 변환된 파일을 다시 배포하기 전

잘못된 코드가 주문·조회에 쓰였다면 원문 복원만으로 끝내지 않습니다. 영향받은 행 ID와 연결된 문서를 모아 기존 결과가 다른 품목이나 날짜를 가리키지 않았는지 확인합니다. 수정 파일은 새 버전으로 만들고 열 계약과 변환 경로를 같이 남깁니다. 이전 파일을 받은 담당자에게는 어떤 열을 다시 가져와야 하는지 명확히 안내합니다.

이 작업표는 원문 역할을 구분하고 가져오기 후 무엇을 검사할지 제시합니다. 실제 프로그램의 모든 날짜 인식 규칙을 차단하는 기능은 아닙니다. 코드열에 새 코드형식이 추가되거나 날짜 형식·환경 설정이 바뀌면 정상·모호·유효하지 않은 입력을 다시 넣어 결과를 대조합니다.

윤년과 자리수까지 확인해야 하는 이유

형식과 날짜 존재 여부는 별도 질문입니다. 2028-02-29는 윤년의 날짜지만 2026-02-29는 존재하지 않습니다. YYYY-MM-DD라는 문자 형태만 맞는 정규식으로는 두 값을 구분할 수 없습니다. 날짜 구성 후 연·월·일을 원문과 대조하거나 엄격한 달력 검사를 수행하는 이유입니다. 월 13·일 00 같은 입력도 자동 보정에 맡기지 않습니다.

원문에 시각이나 시간대가 붙은 값을 적용일 열에 그대로 받아들이지 않습니다. 2026-03-04T23:30:00Z를 어느 지역의 적용일로 읽을지 결정하면 날짜가 달라질 수 있습니다. 이 글의 날짜 계약은 시각이 없는 기준일입니다. 시각 로그는 별도 열과 변환 규칙을 쓰고, 날짜 문자열을 잘라 쓰는 임시 처리로 의미를 확정하지 않습니다.

원문에서 확인할 범위

자료 제작·검수: 2026년 10월 10일. 계산·사례의 확인 범위는 본문에 표시했습니다. 편집 기준 · 오류 정정

SOPBiz 운영자

작은 사업자의 반복 업무를 문서, 도구, 운영 루틴으로 정리합니다. 책임 운영자가 글의 수정 요청, 검수 기준, 정책 고지를 관리합니다.

콘텐츠 작성 기준 보기