엑셀에서 CSV 날짜가 바뀌는 이유와 날짜를 그대로 지키는 방법 (2026 가이드)

30초 진단: 파일은 멀쩡하고 엑셀이 잘못 추측한 것입니다

날짜가 바뀌었을 때 가장 먼저 확인해야 할 것은 데이터가 손상된 것인지, 아니면 엑셀이 잘못 읽은 것인지입니다. 두 경우의 해결 방법이 완전히 다르고, 잘못된 해결 방법을 쓰면 단순한 표시 문제가 실제 데이터 손실로 바뀔 수 있기 때문입니다. 30초 테스트는 간단합니다. 같은 파일을 일반 텍스트 편집기로 여십시오. 윈도우에서는 메모장, 맥에서는 일반 텍스트 모드의 TextEdit이면 됩니다. 그곳에서 날짜가 원본 그대로, 즉 03/04/2026, 2026-03-04, 1-2 형태로 보인다면 데이터는 온전하고 엑셀의 읽는 방식만 잘못된 것입니다. 디스크의 파일에는 올바른 문자가 들어 있고, 엑셀이 파일을 열면서 그 의미를 바꾼 것입니다. 이것이 가장 흔한 경우이며, 이 가이드의 모든 해결 방법은 여기서 출발합니다. 원본 파일을 건드리지 말고 복사본으로 작업하는 습관이 이 단계에서 가장 중요합니다.

두 번째 단서는 어떤 값이 바뀌었는지입니다. 일반 단어, 짧은 숫자, 구두점은 멀쩡한데 날짜만 이동하거나 뒤바뀌거나 서식이 바뀌고, 1-2나 MARCH1 같은 짧은 코드가 날짜로 바뀌었다면, 이는 구분자 문제도 손상도 아니라 형식 추측 문제입니다. 구분자 문제는 행 전체를 한 열에 몰아넣습니다. 손상은 모든 것을 뒤섞거나 행을 빠뜨립니다. 형식 추측은 정밀합니다. 날짜처럼 보이는 값만 정확히 바꾸고 나머지는 그대로 둡니다. 03/04/2026이 3월 4일이어야 하는데 4월 3일이 되었고, 1-2라는 코드가 1월 2일이 되었다면, 엑셀이 텍스트를 날짜로 취급한 것이며, 이것만으로 원인과 해결 방법이 모두 드러납니다. 특히 일부 행만 바뀌고 일부 행은 그대로인 패턴은 형식 추측의 전형적인 흔적입니다.

세 번째 확인은 아직 복구가 가능한지를 가르는 기준이며, 셀 자체가 아니라 수식 입력줄을 봐야 합니다. 바뀐 날짜 셀을 클릭하고 수식 입력줄을 읽으십시오. 수식 입력줄에 46085 같은 일련번호가 보이거나, 파일과 다른 배열의 날짜가 보인다면, 그 셀은 이제 원래 문자가 아니라 엑셀 날짜 값을 들고 있는 것입니다. 반대로 수식 입력줄에 원래 문자가 그대로 보인다면 표시 서식만 바뀐 것이므로 셀 서식을 다시 지정하면 해결됩니다. 확인이 끝나기 전까지는 원본 파일을 절대 건드리지 말고, 복사본으로만 작업하며, 변환된 파일을 좋은 파일 위에 다시 저장하지 마십시오. 이 한 번의 저장이 복구 가능한 문제를 복구 불가능한 문제로 바꾸는 경우가 많습니다.

엑셀이 추측하는 이유: CSV 파일에는 형식이 없습니다

이 문제가 반복되는 이유를 이해하려면 CSV 형식에 대한 한 가지 사실을 알아야 합니다. CSV 파일은 어떤 값이 날짜이고, 어떤 값이 숫자이고, 어떤 값이 텍스트인지 알려 주는 머리말이 없는 순수 텍스트입니다. 스프레드시트 파일은 셀 형식을 함께 저장합니다. CSV 파일은 형식도 서식도 저장하지 않습니다. 문자와 쉼표, 줄 바꿈만 있을 뿐입니다. 프로그램을 열어 값을 읽을 때는 프로그램이 각 값의 의미를 직접 정해야 하고, 프로그램마다 정하는 방식이 다릅니다. 파이썬 csv 모듈이나 구글 시트는 따로 지시하지 않는 한 CSV 값을 텍스트로 유지하기 때문에 같은 파일이 그곳에서는 올바르게 보입니다. 반면 엑셀은 CSV 파일을 더블클릭하면 추측합니다. 날짜처럼 보이는 것은 날짜로, 숫자처럼 보이는 것은 숫자로 바꾸고, 그 추측이 맞았는지 확인하지 않습니다. 바로 이 자동 추측이 모든 문제의 출발점입니다.

그 추측이 날짜에서 특히 문제가 되는 이유는 날짜 표기법이 전 세계적으로 통일되어 있지 않기 때문입니다. 미국은 월을 먼저 써서 03/04/2026을 3월 4일로 읽습니다. 유럽 대부분은 일을 먼저 써서 같은 03/04/2026을 4월 3일로 읽습니다. ISO 8601은 연도를 먼저 쓰는 2026-03-04 형태로 모호함이 없지만, 내보낸 파일 대부분은 이 형식을 쓰지 않습니다. CSV 파일은 날짜가 어떤 관습을 따르는지 말해 주지 않으므로, 엑셀은 파일을 여는 컴퓨터의 관습에 의존합니다. 같은 파일을 뉴욕과 베를린에서 열면 하나의 파일에서 두 개의 서로 다른 스프레드시트가 나오고, 어느 쪽 컴퓨터도 선택이 이루어졌다고 경고하지 않습니다. 같은 원리가 두 번째 피해도 설명합니다. 날짜가 아닌 값, 예를 들어 범위 1-2, 비율 5/6, 코드 MARCH1도 날짜 패턴과 충분히 비슷해서 엑셀이 함께 변환해 버립니다. 파일은 변하지 않았습니다. 파일을 읽는 쪽이 문자의 의미를 바꾼 것입니다.

이 문제는 JSON에서 변환한 파일에서 특히 자주 나타납니다. JSON은 형식을 구분합니다. 문자열 “2026-03-04”와 문자열 “03/04/2026”은 서로 다른 문자열이며, JSON을 CSV로 변환하면 각 값이 쓰인 그대로 정확히 출력됩니다. 변환 자체는 올바릅니다. 여는 방식이 맞지 않는 것입니다. 이 페이지의 변환기를 예로 들면, 2026-03-04, 03/04/2026, 2026-03-04T10:30:00Z 날짜를 담은 샘플로 실행했을 때 모든 값이 CSV에 바이트 단위로 동일하게 나왔고, 서식 변경도 숫자 변경도 없었습니다. 따라서 불일치는 변환 단계가 아니라 여는 단계에 있다는 것을 알면, 어디를 고쳐야 할지 분명해집니다. 엑셀이 추측하기 전, 즉 가져오는 단계에서 고쳐야 하며, 다음 절들이 바로 그 방법을 보여 줍니다.

추측이 날짜를 바꾸는 세 가지 방식과 구별하는 법

형식 추측은 날짜를 세 가지 서로 다른 방식으로 바꾸며, 이를 구별하는 일이 중요한 이유는 일부만 복구할 수 있기 때문입니다. 첫 번째는 일과 월이 뒤바뀌는 경우입니다. 03/04/2026이 조용히 4월 3일이 되거나 그 반대가 됩니다. 겉으로는 아무것도 깨져 보이지 않습니다. 열은 그럴듯한 날짜로 가득 차 있고, 모든 날짜가 유효해 보이며, 날짜의 4분의 1이 오류 메시지 하나 없이 틀려 있습니다. 뒤바뀜은 일이 12 이하일 때만 일어납니다. 그럴 때만 일이 월로 둔갑할 수 있기 때문입니다. 그래서 위험합니다. 뒤바뀔 수 없는 행은 문제를 드러내지만, 실제로 뒤바뀐 행은 문제를 숨깁니다. 겉보기에 정상인 열일수록 꼼꼼히 확인해야 하는 이유가 여기에 있습니다.

두 번째 방식은 혼합 열이며, 뒤바뀜이 일어났다는 결정적인 증거입니다. 미국식 파일을 일 우선 컴퓨터에서 열면, 일이 13 이상인 행은 월이 될 수 없으므로 엑셀은 그 셀을 텍스트로 남겨 두고 나머지만 날짜로 변환합니다. 그러면 한 열에 두 종류의 셀이 섞입니다. 매월 초 12일분의 행은 진짜 날짜가 되고, 나머지는 텍스트가 됩니다. 그 열을 정렬하면 텍스트 행이 한쪽 끝에 몰리고, 날짜 필터는 그 행을 놓치며, 그 열로 만든 차트나 계산식은 그 행을 조용히 빠뜨립니다. 날짜 열이 이상하게 정렬되거나 일부 행이 날짜처럼 동작하지 않는다면, 데이터를 탓하기 전에 이 분리 현상을 먼저 확인하십시오. 특히 월말 날짜만 계산에서 빠지는 패턴이 보이면 혼합 열을 의심해야 합니다.

세 번째 방식은 날짜가 아닌 값이 날짜로 변환되는 경우입니다. 범위 1-2는 1월 2일이 되고, 비율 5/6은 5월 6일이 되며, 코드 MARCH1은 3월 1일이 됩니다. 내부적으로 엑셀은 날짜를 일련번호로 저장합니다. 1899년 12월 30일 이후 경과한 일수를 세는 방식이라서, 2026년 3월 4일은 46085, 2026년 4월 3일은 46115로 저장됩니다. 값이 일단 일련번호가 되면 그 워크북에서는 원래 문자가 사라집니다. 이후에 셀을 텍스트 서식으로 바꿔도 원래 문자가 돌아오지 않습니다. 46085라는 일련번호를 텍스트로 보여 줄 뿐, 2026-03-04가 되지 않습니다. 이것이 표시 문제와 데이터 손실을 가르는 테스트입니다. 수식 입력줄에 일련번호가 보인다면 그 복사본에서는 문자가 사라진 것이며, 뒤에 나오는 복구 절만이 도움이 됩니다.

CSV file (from this page converter, verified):
order,shipDate,dueDate,window,code
A-101,2026-03-04,03/04/2026,1-2,MARCH1
A-102,2026-04-03,04/03/2026,12-3,SEPT2
A-103,2026-03-04T10:30:00Z,3/4/2026,5/6,OCT4

What Excel shows on double-click, US machine (month first):
shipDate -> real dates, displayed 3/4/2026, 4/3/2026, 3/4/2026
window -> 1-2 becomes Jan-02, 12-3 stays text, 5/6 becomes Jun-05
code -> MARCH1 becomes Mar-01, SEPT2 becomes Sep-02, OCT4 becomes Oct-04

What Excel shows on double-click, day-first machine:
dueDate 03/04/2026 -> April 3 (was March 4); 04/03/2026 -> March 4 (was April 3)
dueDate 3/4/2026 -> April 3 (was March 4); rows with day above 12 stay text

이 표가 보여 주는 것은 분명합니다. 파일에서 빠진 것은 아무것도 없고, 엑셀 화면에서 모든 것이 바뀌었습니다. 그래서 가져오기 해결 방법이 그토록 완전하게 통합니다. 엑셀에 열을 텍스트라고 미리 알려 주면, 엑셀은 변환 없이 같은 문자를 그대로 저장하고, 모든 날짜가 편집이나 다시 입력 없이 제자리로 돌아옵니다. 여러분의 파일이 이 패턴과 일치한다면, 통념 깨기 절은 건너뛰고 바로 가져오기 해결 방법으로 가십시오. 여러분의 파일은 손상된 파일이 아닙니다. 잘못 읽힌 파일입니다. 이 구분 하나만으로 불필요한 재작업을 피하고, 원본을 안전하게 지킬 수 있습니다.

통하지 않는 네 가지 해결 방법과 사람들이 계속 시도하는 이유

효과 있는 해결 방법에 앞서, 통하지 않는 네 가지 방법을 먼저 정리할 가치가 있습니다. 각각 시간을 낭비하고, 그중 하나는 상황을 더 악화시키기 때문입니다. 첫 번째는 파일을 연 뒤 열 서식을 바꾸는 방법입니다. 숫자 서식을 바꾸면 저장된 날짜가 표시되는 방식만 바뀌지, 저장된 날짜 자체는 바뀌지 않습니다. 엑셀이 파일의 의도인 3월 4일 대신 4월 3일을 저장했다면, 서식을 바꿔도 4월 3일이 다른 모양으로 보일 뿐이고, 틀린 날짜는 그대로 틀립니다. 서식은 표시일 뿐입니다. 저장된 일련번호가 데이터이며, 표시 변경은 저장된 값을 건드리지 않습니다. 화면이 보기 좋아졌다고 문제가 해결된 것이 아닙니다.

두 번째는 가져온 뒤 시스템 지역 설정을 바꾸는 방법입니다. 지역 설정은 엑셀이 파일을 읽는 순간에 영향을 미치지, 읽은 뒤에는 영향을 주지 않습니다. 일련번호가 저장되고 나면, 컴퓨터를 월 우선에서 일 우선으로 바꿔도 저장된 일련번호가 표시되는 방식만 바뀔 뿐, 서식을 바꾸는 것과 정확히 같습니다. 파일을 다시 읽지 않으며, 뒤바뀜을 되돌리지 않습니다. 세 번째는 CSV에서 값을 따옴표로 감싸는 방법입니다. 많은 가이드가 “03/04/2026”을 따옴표로 감싸면 날짜가 보호된다고 주장하지만, 엑셀에서는 그렇지 않습니다. 엑셀은 가져오는 과정에서 따옴표를 제거한 뒤 안쪽 값에 같은 날짜 추측을 적용하므로, 따옴표로 감싼 날짜는 따옴표가 없는 날짜와 똑같이 변환됩니다. 따옴표는 값 안의 쉼표를 처리하는 방식을 제어할 뿐, 엑셀이 값의 형식을 정하는 방식을 제어하지 않습니다.

네 번째는 변환된 날짜에 찾기 및 바꾸기를 적용해 월과 일을 손으로, 또는 수식으로 열 전체에 걸쳐 되돌리는 방법입니다. 이 방법은 모든 행이 뒤바뀌었을 때만 통하는데, 그런 경우는 절대 없습니다. 일이 12를 넘는 행은 뒤바뀌지 않고 텍스트로 남았으므로, 열 전체에 일괄 뒤바뀜을 적용하면 틀린 행은 고치면서 맞았던 행을 망가뜨립니다. 찾기 및 바꾸기는 직접 입력한 값에 쓰고, 파일에는 가져오기 해결 방법을 쓰십시오. 어떤 해결 방법이 실패하는지 아는 것만으로도 가장 흔한 함정을 피할 수 있습니다. 표시가 올바르게 보인다고 해서 문제가 해결된 것으로 믿는 함정, 그 이면에서 저장된 값은 여전히 틀린 채 남아 있는 함정입니다.

해결 방법 1: 파일을 가져오고 날짜 열을 텍스트로 설정하기

이 방법은 가장 먼저 시도해야 할 해결 방법입니다. 시스템도 파일도 바꾸지 않으며, 구분자나 인코딩이 어떻든 모든 CSV에 통하기 때문입니다. 파일을 더블클릭하는 대신 엑셀을 먼저 열고 안내식 가져오기를 통해 파일을 들여오면, 각 열의 형식을 직접 선택할 수 있습니다. 가져오기 대화 상자의 미리 보기에서 선택이 맞았는지 즉시 확인할 수 있습니다. 날짜가 미리 보기에서 파일과 같은 문자로 정확히 표시된다면, 아직 아무것도 불러오지 않은 상태에서 올바른 선택을 한 것입니다. 미리 보기에 여전히 변환된 날짜가 보인다면 아직 아무것도 변경되지 않은 것이므로, 불러오기 전에 열 형식을 조정하면 됩니다. 미리 보기가 바로 안전장치 역할을 합니다.

• ▸엑셀에서 빈 통합문서를 엽니다. CSV 파일을 더블클릭하지 마십시오.
• ▸Data, From Text/CSV 순서로 들어가서 파일을 선택합니다.
• ▸미리 보기 대화 상자에서 구분자와 파일 원본을 확인한 뒤, Load 대신 Transform Data를 클릭해 Power Query 편집기를 엽니다.
• ▸Power Query 편집기에서 자동으로 만들어진 Changed Type 단계를 찾아 제거합니다. 날짜 추측이 일어나는 곳이 바로 이 단계입니다.
• ▸모든 날짜 열과 날짜처럼 보이는 모든 코드 열을 선택하고 데이터 형식을 Text로 설정합니다.
• ▸Close and Load를 클릭합니다. 날짜가 쓰인 문자 그대로 텍스트로 들어옵니다.

텍스트 날짜에는 솔직히 이해해야 할 한 가지 상충 관계가 있습니다. 텍스트 날짜는 진짜 엑셀 날짜가 아닙니다. 진짜 날짜와 함께 시간 순서로 정렬되지 않으며, 의도적으로 변환하기 전까지는 날짜 수식이 이를 무시합니다. 원본 문자를 보존하는 것이 목표일 때는 이것이 단점이 아니라 장점입니다. 원본 관습을 확인한 뒤 다음 해결 방법으로 의도적으로 변환하십시오. CSV 파일을 여는 기본 방식을 가져오기로 바꾸십시오. 단순한 구조 수단이 아니라, 매번 파일을 안전하게 여는 습관으로 만드십시오. 더블클릭은 구분자와 인코딩, 모든 열의 형식에 대한 추측입니다. 가져오기는 세 가지 모두에 대한 선택이며, 그 선택은 1분 정도만 더 걸립니다. 맥에서도 같은 경로가 Data, From Text를 통해 통하며, 가져오기 단계에서 열 형식을 설정합니다.

해결 방법 2: 원본 로케일로 가져와서 의도한 변환만 일어나게 하기

텍스트가 아니라 진짜 엑셀 날짜가 필요하다면, 가져오기 경로는 그대로 쓰되 한 단계를 더합니다. 엑셀이 원본 파일이 따르는 관습을 알려 주는 것입니다. Power Query 편집기에서 날짜 열을 마우스 오른쪽 버튼으로 클릭하고 Change Type, Using Locale을 선택합니다. 데이터 형식으로 Date를 고르고 원본 파일과 일치하는 로케일을 고릅니다. 월 우선 파일에는 English (United States)를, 유럽식 내보내기에는 그에 맞는 일 우선 로케일을 고릅니다. 그러면 Power Query는 일이 12를 넘는 행을 포함해 모든 행을 하나의 관습 아래에서 변환하므로, 열이 균일하게 나옵니다. 모두 진짜 날짜가 되고, 텍스트로 남는 행도 없고, 조용한 뒤바뀜도 없습니다. 로케일을 정확히 고르는 것이 이 방법의 핵심입니다.

불러오기 전에 뒤바뀜을 드러내는 행으로 결과를 확인하십시오. 일이 12보다 큰 기록을 찾습니다. 올바른 로케일에서는 날짜로 불러와지고, 잘못된 로케일에서는 텍스트로 남거나 실패합니다. 그런 다음 일과 월이 모두 12 이하인 기록을 찾아 원본 의도대로 읽히는지 확인합니다. 어느 쪽 검사든 실패하면 로케일을 잘못 고른 것이며, 아직 아무것도 불러오지 않았으므로 잃은 것이 없습니다. 로케일을 바꾸고 다시 확인하십시오. 이 두 기록 검사에는 10초가 걸리며, 그렇지 않으면 몇 달 동안 숨어 있을 실수를 잡아냅니다. 특히 월말 마감일이나 결제일이 걸린 파일에서는 이 10초 검사가 큰 손실을 막아 줍니다.

해결 방법 3: 다시 가져오지 않고 이미 가져온 날짜를 고치기

때로는 다시 가져오는 것이 불가능합니다. 원본 파일은 사라지고 워크북만 남아 있기 때문입니다. 고칠 수 있는 범위는 무엇이 살아남았는지에 달려 있습니다. 가져온 날짜가 여전히 텍스트로 남아 있다면, 엑셀이 인식하지 못했다는 뜻이며, Text to Columns 도구가 이를 고칩니다. 열을 선택하고 Data, Text to Columns 순서로 들어가서 Next를 두 번 클릭한 뒤, 3단계에서 Date를 선택하고 원본 파일과 일치하는 형식, 월 우선이면 MDY, 일 우선이면 DMY를 고릅니다. 그러면 엑셀은 열 전체를 하나의 관습 아래에서 변환하는데, 이는 더블클릭이 절대 주지 않던 통제력입니다. 변환 전에 열의 샘플 몇 개를 원본과 대조하면 실수를 줄일 수 있습니다.

날짜가 잘못된 일련번호로 저장되었다면, 즉 모든 행이 뒤바뀌었다면, 수식으로 되돌릴 수 있습니다. 도우미 열에 =DATE(YEAR(A2),DAY(A2),MONTH(A2))를 입력하면 각 날짜를 일과 월을 맞바꾼 형태로 다시 만들고, 결과를 복사해 값으로 붙여 넣으면 고친 내용이 고정됩니다. 하지만 이 방법은 열의 모든 행이 뒤바뀌었을 때, 즉 원래 일이 모두 12 이하일 때만 통합니다. 열이 혼합 상태라면, 날짜와 텍스트로 남은 행이 섞여 있다면, 두 그룹을 따로 고치십시오. 먼저 Text to Columns으로 텍스트 행을 변환한 뒤, 날짜 행이 과연 뒤바뀜을 고쳐야 하는지 확인합니다. 혼합 열에 일괄 수식을 적용하면 맞았던 행이 망가집니다. 그리고 원래 문자가 사라져서 어떤 행이 뒤바뀌었는지 알 수 없다면 멈추십시오. 파일에 더 이상 없는 정보를 수식으로 복원할 수는 없으며, 복구 절이 유일하게 솔직한 길입니다.

해결 방법 4: 자동 날짜 변환을 끄고 원본에서 ISO 날짜를 쓰기

CSV 파일을 매일 여는 경우, 매번 가져오기를 반복하는 일은 금방 지겨워지고, 오래 가는 해결 방법은 엑셀이 기본적으로 추측하는 내용을 바꾸는 것입니다. 최근 엑셀 버전, Microsoft 365와 Excel 2024, 그리고 그 맥 버전에는 자동 데이터 변환이라는 설정이 있습니다. File, Options, Data 순서로 들어가면 찾을 수 있습니다. 엑셀이 스스로 적용하는 변환 목록이 나오는데, 날짜처럼 보이는 문자와 숫자 문자열을 변환하는 항목이 포함되어 있습니다. 원하지 않는 변환의 선택을 해제하면, 엑셀은 이후에 여는 파일에서, 더블클릭으로 여는 경우를 포함해, 그 값을 텍스트로 남겨 둡니다. 매일 파일을 여는 사람에게는 이 설정 하나가 반복 작업을 크게 줄여 줍니다.

이 설정에 의존하기 전에 두 가지 주의점이 있습니다. 첫째, 이 설정은 앞으로의 동작만 바꿉니다. 이미 변환된 셀을 고치지 않으며, 이미 일련번호로 대체된 문자를 되돌리지 않습니다. 지난주에 연 파일은 워크북에 변환된 값을 그대로 들고 있으며, 원본 파일에서 새로 가져와야만 날짜가 돌아옵니다. 둘째, 이 설정은 파일이 아니라 사용자의 컴퓨터에 속합니다. 기본 설정인 컴퓨터에서 같은 파일을 여는 동료는 여전히 변환된 날짜를 보게 되며, 외부로 보내는 파일에는 어떤 보호도 함께 가지 않습니다. 이 설정은 자신의 컴퓨터를 위한 편의 기능으로 여기고, 공유하는 파일에는 가져오기 해결 방법을 믿을 수 있는 방법으로 쓰십시오. 두 방법을 함께 쓰면 개인 작업과 공유 작업 모두를 안전하게 처리할 수 있습니다.

CSV를 직접 만드는 입장이라면 가장 강력한 해결 방법은 원본에서부터 시작됩니다. 날짜를 ISO 8601 형태, 즉 연도 우선인 2026-03-04로 쓰는 것입니다. 연도 우선 날짜는 어떤 읽는 쪽에도 일과 월의 모호함을 남기지 않습니다. 연도가 먼저 오고 월은 항상 가운데 숫자이기 때문입니다. 그렇다고 엑셀이 완벽해지는 것은 아니므로 가져오기는 여전히 확인해야 하지만, 슬래시나 하이픈 날짜가 불러오는 뒤바뀜 오류의 전체 유형이 사라집니다. JSON에서는 날짜를 ISO 형태의 문자열로 유지해야 합니다. 로케일 형식 문자열이 아니라, 문자열 “2026-03-04”는 문자 2026-03-04로 변환되지만, “03/04/2026” 같은 로케일 문자열은 모호함을 건드리는 모든 파일에 그대로 옮겨 갑니다. 이것은 변환기 설정이 아니라 원본 데이터의 결정입니다. 원본이 밝히지 않은 관습을 변환기가 선언해 줄 수는 없기 때문입니다.

이미 변환된 날짜로 저장된 파일 복구하기

지금까지의 모든 해결 방법은 디스크의 파일이 여전히 올바르고 엑셀 화면만 잘못되었다고 가정했습니다. 하지만 변환된 버전이 이미 저장된 경우도 있고, 그때의 문제는 저장된 복사본에서 원래 날짜를 여전히 복구할 수 있는지입니다. 답은 저장 과정이 정확히 무엇을 했는지에 달려 있으며, 구별해야 할 경우가 두 가지입니다. 첫 번째 경우는 디스크의 파일이 여전히 원래 문자를 들고 있고 워크북 표시만 잘못된 경우입니다. 텍스트 편집기 테스트가 바로 이 경우를 찾아냅니다. 편집기에 원래 날짜가 보이면 잃은 것이 없으며, 해결 방법 1이 화면을 고칩니다. 두 번째 경우는 디스크의 파일 자체가 변환된 값을 담고 있는 경우입니다. 누군가 엑셀에서 파일을 열고, 서식이 바뀐 날짜를 보고, CSV로 다시 저장하면서 변환된 값을 파일에 써 넣었기 때문입니다.

두 번째 경우는 좁은 조건에서만 복구할 수 있습니다. 모든 날짜가 하나의 관습 아래에서 뒤바뀌었고 원래 일이 모두 12 이하라면, 해결 방법 3의 DATE 수식이 이를 되돌립니다. 손상이 균일한 교환이기 때문입니다. 유일한 버전이 아니라 복사본으로 작업하고, 엑셀에서 다시 열기 전에 알려진 기록과 대조해 결과를 확인하십시오. 손상이 혼합 상태라면, 일부 행은 뒤바뀌고, 일부 행은 텍스트로 남고, 일부 코드는 날짜가 되었다면, 원래 문자는 그 복사본에서 수식으로 풀 수 없는 방식으로 사라진 것입니다. 일련번호는 어떤 관습이 이를 만들었는지 기록하지 않기 때문입니다. 그럴 때는 복사본 고치기를 멈추고 원본에서 파일을 다시 만드십시오. 데이터베이스나 도구, 또는 원래의 JSON에서 다시 내보내고, 이번에는 해결 방법 1로 여십시오. 그리고 무엇보다, 대체 파일이 제대로 확인될 때까지 손상된 복사본을 따로 보관하십시오. 대체본을 검증하기 전에 유일한 복사본을 지우는 것이, 복구 가능한 문제를 잃어버린 데이터로 바꾸는 지름길입니다.

이 페이지 변환기에서 나온 파일에는 어떤 의미인가

이 페이지의 변환기는 바로 이 가이드가 다루는 종류의 파일을 만들기 때문에, 그 동작을 분명히 말할 가치가 있습니다. 다운로드 파일은 JSON에 들어 있는 날짜를 정확히 보존합니다. 이는 가정이 아니라 실제 코드로 검증한 사실입니다. 변환 엔진은 ISO 날짜 2026-03-04, 슬래시 날짜 03/04/2026과 04/03/2026, 타임스탬프 2026-03-04T10:30:00Z, 그리고 날짜처럼 보이는 코드 1-2, 12-3, 5/6, MARCH1, SEPT2, OCT4를 담은 세 행 샘플로 실행되었고, 모든 값을 CSV에 바이트 단위로 동일하게 만들었습니다. 서식 변경도 변환도 숫자 변경도 없었습니다. 따라서 변환한 파일이 엑셀에서 바뀐 날짜로 보인다면, 변환이 무엇인가를 손상시킨 것이 아닙니다. 파일은 올바르고, 엑셀이 더블클릭으로 열면서 형식을 추측한 것입니다.

변환한 파일에는 두 가지 깔끔한 선택지가 있습니다. 첫 번째는 가져오기 경로입니다. 다운로드한 파일을 Data, From Text/CSV로 열고, Transform Data를 클릭한 뒤, 모든 날짜 열을 문자를 유지하는 Text로 설정하거나, 진짜 날짜가 필요하다면 원본 로케일에 맞는 Date로 설정하고 불러옵니다. 날짜는 올바르게 읽히고, 파일 자체는 아무것도 바꾸지 않았으므로 다른 모든 도구에서도 유효하게 남습니다. 두 번째는 해결 방법 4의 자동 변환 설정으로, 자신의 컴퓨터용입니다. 형식 추측 표시 문제를 고치겠다고 데이터를 다시 변환하지 말고, 변환한 출력을 스프레드시트에 붙여 넣어 다시 저장하지 마십시오. 그 왕복 과정이 바로 이 가이드와 동반 가이드들이 막으려는 구분자, 인코딩, 형식 불일치를 그대로 불러올 수 있기 때문입니다. 데이터를 고치지 말고 여는 방식을 고치십시오.

변환기에 대한 한 가지 세부 사항이 더 중요합니다. 변환기는 다운로드 전에 구분자를 선택하게 해 주는데, 이 선택은 형식 추측과 무관합니다. 파일은 구분자는 맞고 날짜는 뒤바뀔 수 있고, 날짜는 맞고 구분자는 틀릴 수 있으며, 둘 다 틀릴 수도 있습니다. 변환한 파일이 한 열로 열리고 날짜도 이상해 보인다면, 같은 가져오기에서 두 설정을 함께 고치십시오. 변환할 때 선택한 구분자를 고르고, 날짜 열을 Text로 설정하거나 원본 로케일에 맞는 Date로 설정합니다. 한 열로 열리는 문제의 구분자 절반은 동반 가이드에서 자세히 다루고, 문자 절반은 인코딩 가이드에서, 숫자 절반은 앞자리 0 가이드에서 다루며, 세 가이드 모두 아래 관련 가이드에 연결되어 있습니다.

예방 체크리스트: 아무도 고칠 필요가 없게 날짜를 내보내기

형식 추측은 쓰는 쪽과 읽는 쪽 사이의 불일치이므로, 예방이란 쓰는 쪽이 값의 의미를 읽는 쪽이 존중할 방식으로 선언하는 것입니다. CSV를 만들 때 이 체크리스트를 실행하면, 다음에 파일을 여는 사람은 이 가이드가 필요하지 않습니다. 첫째, 원본에서 날짜를 ISO 8601 형태, 연도 우선으로 씁니다. 데이터에 날짜가 들어 있다면 원본 시스템에 ISO 문자열로 저장하십시오. 로케일 형식 날짜는 모호함을 모든 내보내기에 그대로 옮겨 가기 때문입니다. 둘째, 대상이 엑셀이라면 파일을 여는 방법을 알려 줍니다. 날짜 열을 Text로 설정하거나 원본 로케일에 맞는 Date로 설정해 가져오라는 한 줄 메모가 문제 전체를 막아 주며, 파일과 함께 포함하는 데 아무 비용도 들지 않습니다. 이 한 줄이 수십 통의 문의 메일을 줄여 줍니다.

셋째, 복구한 파일을 텍스트 편집기에서 검증하기 전에는 원본 위에 다시 저장하지 마십시오. 엑셀에서 저장하면 형식과 구분자, 인코딩이 엑셀 기본값으로 다시 쓰이면서, 다음 읽는 사람에게 불일치가 다시 생기거나, 표시 문제가 실제 데이터 손실로 바뀔 수 있습니다. 넷째, 파일을 받을 때 무엇인가 이상해 보이면 먼저 텍스트 편집기로 열고, 어떤 스프레드시트가 그 위에 저장하기 전에 날짜를 확인하십시오. 다섯째, 원본 데이터를 보관하십시오. CSV는 데이터 자체가 아니라 평평하게 만든 스냅샷이므로, 복구가 잘못되면 원본에서 깨끗하게 다시 내보낼 수 있습니다. 대부분의 날짜 공포 이야기는 손상된 CSV가 유일한 복사본이었다는 사실을 너무 늦게 깨닫는 것으로 끝납니다. 여러분의 파일이 그렇게 되지 않게 하십시오.

관련 가이드

• CSV가 Excel에서 한 열로 열리는 이유와 해결 방법 (2026 가이드) →
• Excel에서 CSV가 깨진 문자로 보이는 이유와 인코딩 해결 방법 (2026 가이드) →
• Excel이 CSV 코드의 앞자리 0을 지우는 이유와 이를 지키는 방법 (2026 가이드) →
• 엑셀에서 CSV를 저장하면 파일이 바뀌는 이유와 원본을 안전하게 지키는 방법 (2026 가이드) →
• 엑셀로 열리지 않는 큰 CSV 파일, 원인과 해결 방법 (2026 가이드) →

자주 묻는 질문