엑셀에서 CSV를 저장하면 파일이 바뀌는 이유와 원본을 안전하게 지키는 방법 (2026 가이드)

30초 진단: 저장 전후 파일을 비교하세요

엑셀을 거친 뒤 CSV 파일이 달라 보일 때 가장 먼저 확인할 것은 파일 자체가 바뀌었는지, 아니면 엑셀 화면만 그렇게 보이는지입니다. 두 경우의 해결책이 완전히 다르기 때문입니다. 30초 진단법은 이렇습니다. 엑셀에서 CSV를 열기 전에 파일을 하나 복사해 두세요. 엑셀에서 저장한 뒤에는 두 파일을 모두 일반 텍스트 편집기로 여세요. 윈도우에서는 메모장, 맥에서는 일반 텍스트 모드의 텍스트편집기를 쓰면 됩니다. 두 파일을 나란히 비교했을 때 저장된 사본에서 구분자가 달라졌거나, 문자가 달라졌거나, 0이 사라졌거나, 날짜 형식이 바뀌었다면 파일이 바뀐 것입니다. 두 파일이 문자 하나까지 똑같다면 엑셀 화면만 오해를 불러일으킨 것이고 파일은 안전합니다.

두 번째 단서는 변화가 나타나는 위치입니다. 파일을 다시 쓴 저장은 파일 전체에 일관된 패턴으로 변화를 남깁니다. 모든 쉼표 구분자가 세미콜론이 되고, 모든 악센트 이름이 물음표나 이상한 문자 조합으로 바뀌고, 모든 코드가 앞자리 0을 잃습니다. 한 행에만 무작위로 손상이 생겼거나 한 행만 사라졌다면 다른 원인, 예를 들어 편집 실수나 잘린 내보내기를 의심해야 합니다. 파일 전체에 걸친 일관된 변화는 엑셀 기본값으로 저장하면서 파일을 다시 쓴 흔적이며, 정확히 어느 설정을 고쳐야 하는지 알려줍니다. 구분자 설정인지, 인코딩 선택인지, 아니면 애초에 파일을 연 방식인지가 드러납니다.

세 번째 확인은 복구가 아직 가능한지 결정하는 것이며, 사람들이 가장 자주 건너뛰는 단계입니다. 엑셀을 거치기 전의 사본이나 CSV가 나온 원본 자료가 아직 있다면 잃은 것은 없습니다. 좋은 사본에서 다시 가져오거나 다시 내보내면 문제는 끝납니다. 저장된 파일이 유일한 사본을 덮어썼다면 복구는 백업과 버전 기록, 또는 원본 시스템에서 다시 내보내는 방법에 달려 있으며, 이는 뒤쪽 복구 절에서 다룹니다. 확인이 끝날 때까지 다시 저장하지 말고, 같은 파일 위에 통합 문서를 닫지 말고, 저장된 사본을 삭제하지 마세요. 데이터 대부분이 남아 있는 손상된 사본이라도 사본이 아예 없는 것보다 훨씬 좋은 증거가 됩니다.

BEFORE (as exported, comma delimited, UTF-8):
code,zip,name,shipDate,note
00123,02138,Zoë Café,2026-03-04,fragile; handle with care
00456,07477,Müller,2026-04-03,gift

AFTER (saved from Excel on a European-locale machine):
code;zip;name;shipDate;note
123;2138;Zoë Café;03.04.2026;fragile; handle with care
456;7477;Müller;03.04.2026;gift

What changed: commas became semicolons, leading zeros vanished,
dates were reformatted, and one note split into two columns.

이 예시가 보여주는 것은 하나의 설정이 모든 문제를 일으킨 것이 아니라는 점입니다. 구분자는 컴퓨터 로케일 때문에 바뀌었고, 0은 열 때 형식 추측 때문에 사라졌고, 날짜는 엑셀이 날짜를 저장한 뒤 자체 표시 형식으로 다시 썼기 때문에 바뀌었습니다. 저장은 하나의 오류를 새로 만드는 것이 아닙니다. 엑셀이 파일을 열 때 한 모든 추측을 한 번에 고정하는 것이며, 그래서 화면에서는 사소해 보이던 추측 하나하나가 저장을 거치면 파괴적으로 느껴지는 것입니다.

저장이 복사가 아닌 이유: 엑셀이 실제로 디스크에 쓰는 것

저장이 CSV를 바꾸는 이유를 이해하려면 엑셀이 파일을 열 때 하는 일에 대한 사실 하나를 알아야 합니다. 엑셀은 파일을 텍스트로 들고 있지 않습니다. 텍스트를 셀 단위로 나누고, 각 셀의 형식을 정하고, 사용자의 지역 설정을 적용한 뒤 표를 보여줍니다. 화면에 보이는 것은 파일 자체가 아니라 엑셀이 해석한 파일입니다. 저장하면 엑셀은 그 표를 다시 텍스트로 씁니다. 따라서 저장된 파일은 원래 문자가 아니라 모든 추측이 박힌 표를 반영합니다. 텍스트에서 표로, 다시 표에서 텍스트로 돌아오는 이 왕복 과정에서 이 가이드의 모든 변화가 일어납니다.

다시 쓸 때 가장 먼저 사라지는 것은 셀 값이 아닌 모든 것입니다. CSV 파일은 행과 열의 값만 담고 그 외의 것은 담지 않으므로, 엑셀이 저장할 때는 현재 워크시트 셀에 화면에 보이는 텍스트와 값만을 남깁니다. 차트와 이미지, 셀 색상, 굵은 글자, 병합된 셀, 데이터 유효성 검사 규칙, 하이퍼링크는 형식이 저장할 곳이 없어 살아남지 못합니다. 수식은 현재 계산된 결과값으로 대체되므로, 합계를 계산하는 수식이 들어 있던 셀은 수식이 아니라 합계 숫자 하나만 저장됩니다. 다른 시스템으로 내보낼 때는 대개 원하는 결과이지만, 저장된 CSV는 한 순간의 스냅샷이지 작동하는 스프레드시트가 아니며, 다시 열어도 수식은 돌아오지 않습니다.

다시 쓸 때 두 번째로 사라지는 것은 보고 있던 시트 외의 모든 시트입니다. 통합 문서는 여러 시트를 담을 수 있지만 CSV 파일은 표 하나이므로, 엑셀은 현재 시트만 저장하고 다른 시트는 저장되지 않는다고 경고합니다. 사람들은 이 경고를 매일 그냥 넘기고, 저장된 파일에는 한 시트 분량의 데이터만 남고 나머지는 저장되지 않은 통합 문서 뒤에 남습니다. 통합 문서를 스프레드시트 형식으로 저장하지 않고 닫으면 다른 시트는 사라집니다. 이 경고는 엑셀이 저장이 손실이 있다는 것을 솔직하게 알려주는 것이며, 안전한 대응은 CSV로 내보내기 전에 통합 문서를 별도로 자체 형식으로 저장해 두는 것입니다.

다시 쓸 때 세 번째로 바뀌는 것은 값 자체입니다. 엑셀은 저장된 값이 아니라 화면에 보이는 값으로 저장하기 때문입니다. 소수 둘째 자리까지 표시하도록 서식을 지정한 정밀한 숫자가 들어 있는 셀은 전체 저장값이 아니라 두 자리로 표시된 값으로 저장됩니다. 일련번호로 저장된 날짜는 사용자의 컴퓨터 표시 형식으로 저장됩니다. 숫자라고 추측된 코드는 앞자리 0 없이 그 숫자로 저장됩니다. 어느 것도 버그가 아닙니다. 표를 텍스트로 저장한다는 것이 바로 이런 의미입니다. 하지만 저장된 파일은 다른 프로그램이 읽을 때까지 보이지 않는 방식으로 원본과 달라질 수 있으며, 그래서 화면이 아니라 텍스트 편집기로 저장된 파일을 확인하는 일이 중요한 것입니다.

조용한 덮어쓰기: Ctrl+S가 추측을 파일로 만드는 과정

가장 손상이 큰 저장은 다른 이름으로 저장이 아닙니다. 그저 보려고 했던 CSV 파일에 습관적으로 누르는 Ctrl+S, 또는 닫으면서 나오는 저장 확인이 가장 위험합니다. 값을 확인하려고 CSV를 더블클릭하고, 오타 하나를 고치고, 습관대로 Ctrl+S를 누르면 엑셀은 자체 기본값으로 파일 전체를 다시 씁니다. 고친 셀은 하나지만 엑셀은 모든 행을 다시 썼습니다. 이 비대칭이 문제의 핵심입니다. 저장은 고친 셀만 고치는 패치가 아니라 파일 전체를 대상으로 하는 작업이며, 열 때 엑셀이 한 모든 추측이 같은 키 입력으로 영구화됩니다.

엑셀은 두 번 경고하며, 두 경고 모두 쉽게 무시됩니다. 첫 번째 경고는 파일에 CSV와 호환되지 않는 기능이 있을 수 있다는 내용으로, 서식과 추가 시트가 사라진다는 뜻입니다. 두 번째 경고는 일부 버전에서 현재 형식을 유지할지 묻습니다. 이 대화상자를 매일 보는 사람들은 데이터 손실 경고가 아니라 일상적인 확인처럼 보여서 내용을 읽지 않고 현재 형식 유지를 클릭합니다. 정확히 이 두 대화상자에서 속도를 늦출 가치가 있습니다. 원본 파일이 아직 손대지 않은 채로 남아 있는 마지막 순간이며, 저장하지 않거나 새 이름으로 다른 이름으로 저장하는 선택은 비용이 들지 않고 모든 것을 보존합니다.

왕복 과정이 덮어쓰기를 되돌리기 어렵게 만드는 이유입니다. 파일을 열면 형식을 추측하고, 저장하면 추측을 다시 쓰고, 두 번째로 열면 이미 추측된 값에서 시작해 그 위에 다시 추측합니다. 첫 번째 열기에서 0을 잃은 코드는 두 번째 열기에서 0을 되찾을 수 없습니다. 파일에 0이 더 이상 남아 있지 않아 어떤 프로그램도 읽을 수 없기 때문입니다. 첫 번째 열기에서 일과 월이 뒤바뀐 날짜는 다시 뒤바뀌거나 뒤바뀐 채로 남습니다. 파일이 뒤바뀐 날짜를 진짜인 것처럼 들고 있기 때문입니다. 엑셀을 한 번 왕복할 때마다 정보는 잃을 수만 있고 복원할 수는 없으며, 그래서 이 가이드의 규칙은 절대적입니다. CSV 파일의 유일한 사본 위에 엑셀이 저장하게 두지 마세요.

변화 1: 구분자 교체, 쉼표가 세미콜론이 될 때

가장 눈에 띄는 저장 변화는 구분자 교체입니다. 쉼표로 구분된 파일이 세미콜론으로 구분된 파일로 돌아오고, 다음 프로그램이 파일을 읽으면 모든 행이 한 열에 들어가거나 파일을 거부합니다. 원인은 사용자의 컴퓨터 목록 구분 기호, 즉 엑셀이 CSV 파일을 쓸 때마다 사용하는 지역 설정입니다. 북미와 영국에서는 목록 구분 기호가 쉼표라서 저장된 CSV는 쉼표 구분을 유지합니다. 유럽 대부분에서는 쉼표가 소수점 기호라서 목록 구분 기호가 세미콜론이 되고, 엑셀은 쉼표 대신 세미콜론을 씁니다. 파일 확장자는 어느 경우든 csv로 유지되므로 파일 이름만으로는 다음 읽기 프로그램에 구분자가 바뀌었다고 경고하지 못합니다.

이 문제는 한 열로 열리는 문제를 다룬 동반 가이드와 같은 구분자 문제이지만, 저장 방향은 별도의 경고가 필요합니다. 해결책이 다르기 때문입니다. 파일이 한 열로 열리면 여는 방법을 고칩니다. 파일이 잘못된 구분자로 저장되면 내보내기를 고칩니다. 엑셀에서 파일, 옵션, 고급 순으로 이동해 시스템 구분 기호 사용의 선택을 해제하고, 소수점 구분 기호를 마침표로, 자릿수 구분 기호를 쉼표로 설정하면 엑셀이 목록 구분 기호로 쉼표를 사용합니다. 한 파일에만 필요하다면 내보낸 뒤 설정을 되돌리세요. 설정이 바뀌어 있는 동안 엑셀이 쓰는 모든 CSV에 영향을 미치기 때문입니다. 맥에서는 같은 설정이 시스템 설정의 언어 및 지역 안에 있는 숫자 구분 기호에 있습니다.

손상이 생기기 전에 이 변화를 잡아내는 더 간단한 확인 방법도 있습니다. 저장된 파일을 텍스트 편집기로 열고 첫 줄을 보세요. 원래 파일에서는 쉼표였던 자리에 머리글에 세미콜론이 보이면 구분자가 바뀐 것이며, 위의 설정으로 다시 내보내야 합니다. 텍스트 편집기는 한눈에 진실을 보여주지만, 엑셀은 두 구분자를 모두 같은 표로 읽기 때문에 완전히 숨깁니다. 저장된 CSV를 엑셀 화면으로 판단하지 마세요. 텍스트로 보았을 때 모습으로 판단하세요.

변화 2: 인코딩 다운그레이드, 악센트 문자가 깨질 때

두 번째 저장 변화는 더 조용하고 더 지독합니다. 바로 인코딩 다운그레이드입니다. 엑셀은 거의 똑같아 보이는 CSV 저장 형식 두 가지를 제공하는데, 잘못된 쪽을 선택하면 파일 안의 모든 비영어 문자가 손상됩니다. CSV UTF-8은 파일을 UTF-8로 쓰며, 악센트 문자와 움라우트, 비라틴 문자까지 모두 다룹니다. 일반 CSV는 사용자의 시스템 레거시 인코딩으로 파일을 쓰는데, 많은 윈도우 컴퓨터에서는 그 문자들을 표현할 수 없어 물음표나 잘못된 문자로 돌아옵니다. 두 옵션은 다른 이름으로 저장 목록에서 나란히 있으며, 사람들은 습관적으로 일반 쪽을 선택합니다.

규칙은 간단합니다. 받는 프로그램이 레거시 형식을 명시적으로 요구하지 않는 한 엑셀에서 저장할 때는 항상 CSV UTF-8을 선택하세요. 그리고 그 경우에도 텍스트 편집기로 결과를 확인하세요. 레거시 인코딩 손실은 되돌릴 수 없기 때문입니다. 악센트 문자가 저장된 파일에서 물음표로 대체되고 나면 어떤 다시 가져오기로도 원래 문자를 복원할 수 없습니다. 저장된 파일이 더 이상 그 문자를 들고 있지 않기 때문입니다. 동반 인코딩 가이드에서는 진단을 전부 다루며, 더블클릭 시 엑셀이 UTF-8로 추측하게 만드는 바이트 순서 표시(BOM) 요령도 포함합니다. 하지만 저장 규칙 자체는 독립적입니다. 저장할 때 선택한 인코딩이 다음 읽기 프로그램이 받는 인코딩이며, 잘못된 선택은 모든 비ASCII 값을 한 번에 손상시킵니다.

이 페이지에서 나온 파일에 대해 중요한 인코딩 세부 사항이 하나 더 있습니다. 변환기 다운로드 파일은 바이트 순서 표시가 없는 순수 UTF-8이며, 대부분의 도구에는 가장 깔끔한 형태입니다. 하지만 일부 윈도우 컴퓨터에서는 엑셀 더블클릭 시 악센트 문자를 잘못 읽을 수 있습니다. 그것은 저장 문제가 아니라 열기 문제이며 인코딩 가이드에서 다루고, 저장 규칙을 바꾸지 않습니다. 원본 인코딩이 무엇이든 엑셀에서는 CSV UTF-8로 저장하고, 파일을 보내기 전에 텍스트 편집기에서 악센트 이름이 제대로 읽히는지 확인하세요.

변화 3: 형식 다시 쓰기, 추측이 데이터가 될 때

세 번째 저장 변화는 형식 다시 쓰기이며, 사실 세 가지 동반 문제가 함께 도착합니다. 같은 열기 후 저장 왕복이 엑셀이 한 모든 추측을 다시 쓰기 때문입니다. 앞자리 0이 사라지는 이유는 열 때 코드를 숫자로 읽었고 숫자를 다시 쓰기 때문입니다. 날짜가 다시 형식화되거나 뒤바뀌는 이유는 날짜를 일련번호로 저장했다가 자체 표시 형식으로 다시 쓰기 때문입니다. 긴 식별자(ID)의 끝자리 숫자가 사라지는 이유는 엑셀이 유효 숫자 15자리까지만 유지하고 나머지는 0으로 쓰기 때문입니다. 각각은 자체 동반 가이드에 자체 해결책이 있으며, 이 글에서는 그 해결책을 반복하지 않습니다. 저장 교훈은 세 경우 모두 같기 때문입니다. 손상은 열 때 발생했고, 저장이 그것을 영구화했습니다.

여기서 밝힐 가치가 있는 것은 화면 문제와 저장된 문제를 구분하는 검사입니다. 파일을 텍스트 편집기로 여세요. 코드와 날짜, 식별자가 그곳에서 제대로 읽힌다면 파일은 아직 양호하고 엑셀 화면만 잘못된 것입니다. 저장하지 않고 닫은 뒤 제대로 다시 가져오면 됩니다. 텍스트 편집기에서 0이 사라진 코드, 뒤바뀐 날짜, 잘린 식별자가 보인다면 저장이 이미 파일을 다시 쓴 것이며, 복구 절이 유일한 경로입니다. 이 검사는 10초면 끝나며, 이 가이드 전체에서 가장 유용한 습관입니다. 좋은 파일이 아직 있는지, 손상된 파일만 남았는지 알려주기 때문입니다.

다시 쓰이지 않는 것이 무엇인지 아는 것도 가치가 있습니다. 일반 단어와 추측이 필요 없는 짧은 숫자, 엑셀이 텍스트로 남긴 값은 저장을 그대로 견딥니다. 그래서 저장된 파일은 코드와 날짜, 식별자처럼 중요한 열에서만 틀리면서 대부분 옳아 보일 수 있습니다. 평범한 행 하나만 대충 확인하는 것으로는 아무것도 증명되지 않습니다. 저장 후에는 매번 텍스트 편집기에서 민감한 열, 즉 코드 열과 날짜 열, 긴 식별자 열을 구체적으로 확인한 뒤 파일을 보내세요.

저장 후에는 통하지 않는 네 가지 해결책

효과 있는 해결책에 들어가기 전에, 통하지 않는 네 가지 해결책을 정리할 가치가 있습니다. 각각은 시간을 낭비하고, 그중 하나는 상황을 악화시키기 때문입니다. 첫 번째는 저장된 파일의 서식을 나중에 다시 지정하는 것입니다. 열 서식을 바꾸면 저장된 값이 표시되는 방식은 바뀌지만, 저장이 이미 제거한 문자를 복원할 수는 없습니다. 123으로 저장된 코드는 열을 텍스트 형식으로 지정한다고 해서 0을 되찾을 수 없습니다. 파일이 이제 123만을 들고 있고 그 외의 것은 없기 때문입니다. 서식은 표시일 뿐입니다. 저장된 텍스트가 데이터이며, 표시 변경은 데이터를 건드리지 않습니다.

두 번째는 저장한 뒤 실행 취소를 누르는 것입니다. 실행 취소는 열린 통합 문서 안의 편집을 되돌리지만, 이미 디스크에 저장된 파일을 되돌리지는 못합니다. 저장이 끝나면 디스크는 다시 쓰인 파일을 들고 있으며, 통합 문서에서 아무리 되돌려도 원래 문자는 돌아오지 않습니다. 세 번째는 저장된 파일의 값에 따옴표를 붙이는 것입니다. 따옴표는 값 안의 쉼표가 처리되는 방식을 제어할 뿐 엑셀이 값의 형식을 정하는 방식을 바꾸지 못하며, 엑셀은 가져올 때 따옴표를 제거하고 어차피 형식을 추측합니다. 그래서 손상된 파일에 따옴표를 추가해도 손상에 대해서는 아무것도 바뀌지 않습니다. 네 번째는 뒤바뀐 날짜나 사라진 0을 손으로 복구하려고 저장된 파일 전체에 찾아 바꾸기를 적용하는 것입니다. 모든 행이 같은 변화를 겪었을 때만 통하는데, 열이 섞인 경우에는 절대 그렇지 않으므로, 일괄 교체는 틀린 행을 고치는 동안 옳았던 행을 손상시킵니다.

어떤 해결책이 실패하는지 알면 가장 흔한 함정을 피할 수 있습니다. 화면의 통합 문서는 옳아 보이는데 디스크의 파일은 여전히 틀렸다고 믿으면서 문제가 해결됐다고 여기는 함정입니다. 화면은 파일이 아닙니다. 텍스트 편집기가 파일입니다. 이 가이드 뒤쪽의 모든 복구는 그 구분에서 시작하고, 모든 확인은 그 구분으로 끝납니다.

해결책 1: 원본 위에 저장하지 말고 마스터 사본을 보관하세요

이것이 먼저 시도할 해결책입니다. 비용이 들지 않고, 시스템 설정을 바꾸지 않으며, 이 가이드의 다른 모든 실수를 복구 가능하게 만들기 때문입니다. 원본 CSV 파일은 손대지 말고, 모든 엑셀 작업은 사본에서 하세요. 작업 방식은 의도적으로 지루합니다. CSV가 도착하면 originals라는 폴더에 저장하고 그 사본은 엑셀에서 절대 열지 마세요. 작업 폴더에 복사본을 만들고 작업 사본을 여세요. 저장이 잘못되면 작업 사본을 삭제하고 원본을 다시 복사한 뒤 처음부터 시작하세요. 복구도, 수리도, 데이터 손실도 없습니다. 좋은 파일이 애초에 위험에 노출되지 않았기 때문입니다.

CSV를 직접 만든다면 마스터를 스프레드시트 형식으로 유지하고 CSV는 문서가 아니라 내보내기로 취급하세요. 통합 문서에서 작업하고, 통합 문서를 저장하고, 필요할 때마다 새 CSV를 내보내며, customers-2026-11-05.csv처럼 버전이 드러나는 이름을 붙여 내보낸 파일이 이전 파일을 조용히 대체하지 않게 하세요. CSV는 납작하게 만든 스냅샷이지 데이터 자체가 아니므로, 보호해야 할 것은 마스터 통합 문서, 더 나아가 데이터가 나온 데이터베이스나 JSON입니다. CSV가 데이터의 유일한 사본이 되는 순간 모든 엑셀 저장은 유일한 사본에 대한 위험이 되며, 바로 그 상황을 막으려고 이 가이드가 존재합니다.

• ▸받은 모든 CSV는 어디에서 열기 전에 originals 폴더에 저장하세요.
• ▸사본에서만 작업하고, 내보낸 파일에는 날짜를 붙여 조용히 덮어쓰지 않게 하세요.
• ▸마스터 통합 문서는 CSV 내보내기와 별도로 스프레드시트 형식으로 저장하세요.
• ▸저장이 잘못되면 작업 사본을 버리고 원본에서 다시 시작하세요.

이 규칙은 다중 시트 경고로부터도 보호합니다. 통합 문서에 여러 시트가 있고 그중 하나를 CSV로 내보내도, 통합 문서 자체는 자체 형식으로 온전히 남고, 필요할 때마다 각 시트를 따로 내보낼 수 있습니다. CSV 내보내기는 특정 목적을 위한 단방향 스냅샷이며, 통합 문서는 계속 살아 있는 문서로 남습니다. 사람들은 CSV가 위험해서 시트를 잃는 것이 아니라, 내보낸 뒤 통합 문서를 저장하지 않고 닫아서 잃습니다. 마스터 사본 습관은 그 실수를 불가능하게 만듭니다.

해결책 2: 텍스트 편집기나 제대로 된 가져오기로 안전하게 편집하세요

두 번째 해결책은 편집 방법에 관한 것이며, 작업 크기에 따라 두 갈래로 나뉩니다. 작은 편집, 즉 값 한두 개 바꾸기나 오타 수정, 한 행 바로잡기라면 파일을 엑셀에서 아예 열지 마세요. 텍스트 편집기에서 파일을 열고, 변경하고, 편집기에서 저장하세요. 텍스트 편집기는 보이는 문자를 그대로 다시 쓰며, 형식 추측도, 구분자 교체도, 인코딩 변경도 없습니다. 단, 저장할 때 같은 인코딩을 유지해야 합니다. 한 행짜리 수정에서는 텍스트 편집기가 임시방편이 아닙니다. 올바른 도구이며, 그 일에는 엑셀보다 빠릅니다.

정렬이나 필터, 수식이 필요한 큰 편집이라면 더블클릭하지 말고 파일을 제대로 가져오세요. 빈 통합 문서를 열고 데이터, 텍스트/CSV에서 순으로 이동한 뒤 미리보기에서 구분자와 인코딩, 민감한 열의 형식을 불러오기 전에 설정하세요. 코드와 식별자는 텍스트로, 날짜는 텍스트로 또는 원본 로케일에 맞는 날짜로 지정합니다. 작업을 마친 뒤에는 다른 이름으로 저장으로 내보내고, CSV UTF-8을 선택하고, 원본을 덮지 못하도록 새 이름을 붙인 뒤 보내기 전에 텍스트 편집기로 결과를 확인하세요. 가져오기 단계에서 세 가지 추측을 한 번에 통제할 수 있으며, 텍스트 편집기 확인 단계에서 내보낸 파일이 깨끗한지 증명합니다.

언급할 가치가 있는 안전한 편집 방법이 하나 더 있습니다. CSV를 편집하는 대신 데이터의 원본에서 편집하는 것입니다. CSV가 JSON에서 왔다면 JSON을 고치고 다시 변환하면 왕복 손상 없이 깨끗한 파일이 나옵니다. 데이터베이스에서 왔다면 데이터베이스에서 다시 내보내세요. 이미 스프레드시트를 거친 파일을 수리하는 것보다 원본에서 다시 생성하는 편이 항상 깨끗합니다. 원본은 진짜 값을 들고 있고, 내보낸 파일은 그 값의 스냅샷만을 들고 있기 때문입니다.

해결책 3: 보내기 전에 확인하세요, 2분 텍스트 편집기 검사

세 번째 해결책은 설정이 아니라 습관입니다. 저장한 모든 CSV를 어디로 보내기 전에 텍스트 편집기로 확인하세요. 약 2분 걸리는 짧은 체크리스트를 쓰면 됩니다. 저장된 파일과 원본을 나란히 열고 다섯 가지를 확인하세요. 첫째, 구분자입니다. 머리글 행이 두 파일에서 같은 구분 기호를 쓰는지 보세요. 둘째, 행 개수입니다. 저장된 파일이 같은 줄 수를 들고 있는지 보세요. 단, 줄 바꿈을 포함한 값은 여러 줄에 걸쳐 있을 수 있음을 기억하세요. 셋째, 민감한 열입니다. 코드가 앞자리 0을 유지하는지, 날짜가 원본이 쓴 방식대로 읽히는지, 긴 식별자가 모든 자릿수를 유지하는지 보세요. 넷째, 인코딩입니다. 악센트 이름이 물음표나 이상한 문자 조합 없이 제대로 읽히는지 보세요. 다섯째, 따옴표입니다. 구분자를 포함한 값이 따옴표로 감싸져 한 열에 머무는지 보세요.

어느 확인에서든 실패하면 파일을 보내지 말고 스프레드시트에서 고치려 하지 마세요. 원본으로 돌아가 실패를 일으킨 설정을 고친 뒤 다시 내보내세요. 확인 실패는 원본이 아직 있을 때는 싸고, 원본이 없을 때는 비쌉니다. 그래서 이 확인은 누군가 불평한 뒤가 아니라 보내기 전에 해야 합니다. 확인에 실패했을 때 가장 흔한 반응은 저장된 파일을 엑셀에서 다시 열어 고치는 것인데, 이는 또 다른 왕복을 시작해 대개 새로운 손상을 더합니다. 내보낸 파일을 고치지 말고 내보내기를 고치세요.

확인을 내보내기와 별개의 잡일이 아니라 내보내기 자체의 일부로 만드세요. 다른 이름으로 저장하고, 텍스트 편집기로 열고, 다섯 가지 확인을 실행한 뒤 보내세요. 몇 번 내보내고 나면 확인이 자동화되고, 보내는 파일에 대해 0이 사라졌다거나 날짜가 뒤바뀌었다거나 한 열로 배치됐다는 불만이 돌아오지 않게 됩니다. 확인은 증거이기도 합니다. 받는 사람이 나중에 문제를 보고하면 보낸 파일을 원본과 비교해 변화가 정확히 어디에서 일어났는지 보여줄 수 있습니다. 추측할 필요가 없습니다.

이미 덮어쓴 파일 구하기

가끔 조언이 너무 늦게 도착하고, 저장된 파일이 이미 유일한 사본을 덮어쓴 경우가 있습니다. 복구는 경우에 따라 가능하며, 솔직한 답은 손상된 파일 외에 무엇이 또 존재하는지에 달려 있다는 것입니다. 먼저 자동 백업을 확인하세요. OneDrive와 SharePoint는 그 안에 저장된 파일의 버전 기록을 유지하므로, 다른 일을 하기 전에 파일을 마우스 오른쪽 버튼으로 클릭해 이전 버전을 찾아보세요. 윈도우 파일 기록과 맥 타임머신도 기능을 켜 두었다면 자체 사본을 유지합니다. 이메일 첨부 파일과 채팅 업로드, 공유 드라이브에는 잘못된 저장 전에 보낸 같은 파일의 이전 사본이 들어 있는 경우가 많으며, 그 사본이 가장 깨끗한 복구 수단인 경우가 잦습니다.

둘째, 이전 사본이 없다면 손상이 되돌릴 수 있을 만큼 균일한지 확인하세요. 모든 날짜가 하나의 규칙으로 뒤바뀌었고 원래 날짜의 일이 모두 12 이하였다면 수식으로 다시 뒤집을 수 있고, 모든 코드가 같은 개수의 0을 잃었다면 그 0을 서식으로 복원할 수 있습니다. 단, 열 전체에 걸쳐 손실이 균일했을 때만 가능합니다. 유일한 버전이 아니라 사본에서 작업하고, 신뢰하기 전에 알려진 기록과 결과를 대조하세요. 손상이 섞여 있다면, 일부 행은 뒤바뀌고 일부는 텍스트로 남고 일부 코드는 날짜가 됐다면, 원래 문자는 그 사본에서 수식으로 풀 수 없는 방식으로 사라진 것입니다. 저장된 숫자는 예전에 무엇이었는지 기록하지 않기 때문입니다.

셋째, 가장 확실한 방법은 파일의 원본에서 다시 생성하는 것입니다. 데이터베이스나 도구, 또는 파일이 나온 JSON에서 다시 내보내고, 이번에는 제대로 가져오기로 열고 그 위에 절대 저장하지 마세요. 원본이 JSON이라면 이 페이지의 변환기가 원래 JSON에서 몇 초 만에 새 CSV를 만들며, 모든 값을 쓴 그대로 담습니다. 그 새 파일이 손상된 파일을 완전히 대체합니다. 어떤 경로를 택하든 대체 파일이 텍스트 편집기에서 확인될 때까지 손상된 사본은 따로 보관하세요. 대체 파일을 확인하기 전에 유일한 사본을 삭제하는 것이 복구 가능한 문제를 잃어버린 데이터셋으로 만드는 길입니다.

이 페이지 변환기로 만든 파일에 대한 의미

이 페이지의 변환기는 바로 이 가이드가 다루는 종류의 파일을 만들기 때문에, 실제 코드를 가정하지 않고 확인한 동작을 솔직하게 밝힐 가치가 있습니다. 변환 엔진은 코드 00123과 00456, 우편번호 02138과 07477, 18자리 식별자 123456789012345678과 987654321098765432, 날짜 2026-03-04와 2026-04-03, 악센트 이름 Zoë Café와 Müller, 메모 fragile; handle with care와 gift를 담은 두 행 샘플로 실행됐습니다. 쉼표 구분자에서는 모든 값을 바이트 단위로 똑같이 만들었고, 쉼표를 포함한 이름만 따옴표로 감싸고 그 외의 것은 따옴표로 감싸지 않았습니다. 세미콜론 구분자에서는 세미콜론을 포함한 메모만 정확히 따옴표로 감싸고 그 외의 것은 감싸지 않았습니다. 따라서 변환된 파일이 엑셀을 거친 뒤 바뀐 값을 보인다면 변환이 손상을 일으킨 것이 아닙니다. 파일은 올바랐고, 엑셀이 열 때 추측하고 저장할 때 추측을 다시 썼을 뿐입니다.

Comma delimited (verified, real converter output):
code,zip,id,shipDate,name,note,price
00123,02138,123456789012345678,2026-03-04,"Zoë, Café",fragile; handle with care,19.99
00456,07477,987654321098765432,2026-04-03,Müller,gift,5

Semicolon delimited (verified, same sample):
code;zip;id;shipDate;name;note;price
00123;02138;123456789012345678;2026-03-04;Zoë, Café;"fragile; handle with care";19.99
00456;07477;987654321098765432;2026-04-03;Müller;gift;5

Codes, ZIPs, long IDs, and dates all survive byte-identically.
Quoting follows the delimiter: only values holding the delimiter
are quoted, in both cases.

변환된 파일에는 두 가지 깨끗한 선택지가 있습니다. 첫 번째는 안전 편집 경로입니다. 변환된 파일을 바꿔야 한다면 엑셀에서 CSV를 편집해 그 위에 저장하지 말고 JSON을 바꿔 다시 변환하세요. 왕복 손상 없는 새 파일이 나옵니다. 두 번째는 가져오기 경로입니다. 다운로드한 파일을 데이터, 텍스트/CSV에서 순으로 열고, 코드와 식별자 열은 텍스트로, 날짜 열은 텍스트로 또는 원본 로케일에 맞는 날짜로 설정한 뒤 작업하고, 새 이름으로 CSV UTF-8로 다른 이름으로 저장해 내보낸 뒤 텍스트 편집기로 결과를 확인하세요. 변환된 출력을 스프레드시트에 붙여넣고 다운로드 파일 위에 다시 저장하지 마세요. 그 왕복은 이 가이드와 동반 가이드들이 막으려는 구분자, 인코딩, 형식 불일치를 정확히 만들 수 있습니다. 저장된 파일을 고치지 말고 열기를 고치거나 원본에서 다시 생성하세요.

변환기 관련 세부 사항이 하나 더 중요합니다. 변환기는 다운로드 전에 구분자를 선택하게 하며, 그 선택은 엑셀이 나중에 하는 일과 무관합니다. 파일이 올바른 구분자를 지니면서도 날짜가 뒤바뀔 수 있고, 올바른 날짜를 지니면서도 구분자가 틀릴 수 있으며, 둘 다 한 번에 틀릴 수도 있습니다. 변환할 때 선택한 구분자는 엑셀이 저장할 때 쓰는 구분자가 아니기 때문입니다. 변환된 파일이 한 열로 열리고 값이 틀려 보인다면 같은 가져오기에서 두 가지를 모두 고치세요. 변환할 때 선택한 구분자를 고르고 민감한 열을 명시적으로 설정하세요. 한 열로 열리는 문제에 대한 동반 가이드는 구분자 절반을 자세히 다루고, 인코딩 가이드는 문자 절반을, 앞자리 0 가이드는 숫자 절반을 다루며, 세 가이드 모두 아래 관련 가이드에 연결돼 있습니다.

예방 체크리스트: 아무도 고치지 않아도 되는 CSV를 내보내세요

형식 추측과 저장 다시 쓰기는 쓰는 쪽과 읽는 쪽 사이의 불일치이므로, 예방이란 쓰는 쪽이 값을 무엇인지 선언하고 읽는 쪽이 그것을 존중하게 하며, 읽는 쪽이 신뢰하기 전에 확인하게 만드는 것입니다. CSV를 만들거나 받을 때 이 체크리스트를 실행하면 다음에 파일을 만지는 사람은 이 가이드가 필요하지 않습니다. 첫째, 원본 데이터를 보관하세요. CSV는 납작하게 만든 스냅샷이지 데이터 자체가 아니므로, 저장이 잘못되면 원본에서 다시 깨끗하게 내보낼 수 있습니다. 손상된 사본을 수리하는 대신 말입니다. 둘째, 원본 위에 절대 저장하지 마세요. originals 폴더를 유지하고, 사본에서 작업하고, 내보낸 파일에 날짜를 붙여 조용히 덮어쓰지 않게 하세요.

셋째, 엑셀에서 내보낼 때는 CSV UTF-8을 선택하고, 저장 전에 목록 구분 기호 설정을 확인하고, 보내기 전에 텍스트 편집기로 내보낸 파일을 검증하세요. 넷째, 파일을 받으면 무엇인가 이상해 보일 때 먼저 텍스트 편집기로 열고, 어떤 스프레드시트가 그 위에 저장하게 두기 전에 구분자와 인코딩, 민감한 열을 확인하세요. 다섯째, 받는 사람에게 파일을 여는 방법을 알려주세요. 코드 열은 텍스트로, 날짜는 텍스트로 또는 원본 로케일에 맞는 날짜로 가져오라고 적힌 한 줄 메모는 전체 문제를 예방하며, 파일과 함께 포함하는 데 비용이 들지 않습니다. 대부분의 CSV 재앙 이야기는 손상된 파일이 유일한 사본이었다는 사실을 너무 늦게 발견하면서 끝납니다. 여러분의 파일이 그렇게 되지 않게 하세요.

마지막으로 팀 단위로 작업한다면 이 규칙을 한 번만 정해 문서로 남겨두세요. 원본 폴더 이름과 내보내기 이름 규칙, CSV UTF-8 선택, 보내기 전 텍스트 편집기 확인을 팀 규칙으로 적어두면, 새로 합류한 사람도 같은 실수를 반복하지 않습니다. 개인 작업에서도 같은 효과가 있습니다. 매번 판단하지 않고 정해진 순서를 따르면 실수할 여지가 줄어들고, 파일이 여러 사람의 손을 거쳐도 원본은 안전하게 남습니다. 예방은 한 번의 설정이 아니라 매번 반복되는 작은 습관이며, 그 습관이 쌓이면 복구 가이드가 필요 없어집니다.

관련 가이드

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

자주 묻는 질문