Excel에서 CSV가 깨진 문자로 보이는 이유와 인코딩 해결 방법 (2026 가이드)

30초 진단: 데이터가 손상된 것이 아니라 잘못 읽힌 것이다

CSV를 열었을 때 깨진 문자가 보이면 가장 먼저 확인해야 할 것은 데이터가 손상되었는지, 아니면 표시만 잘못되었는지이다. 두 경우는 해결 방법이 완전히 다르고, 잘못된 해결 방법을 쓰면 표시 문제였던 것이 실제 데이터 손실로 바뀔 수 있기 때문이다. 30초 테스트는 간단하다. 같은 파일을 일반 텍스트 편집기로 열어보자. 윈도우에서는 메모장, 맥에서는 일반 텍스트 모드의 텍스트편집기를 쓰거나, 구글 시트에서 파일, 가져오기를 통해 열어보면 된다. 그곳에서 문자가 정상으로 보인다면 데이터는 온전하고 Excel 표시만 잘못된 것이다. 디스크 위 파일에는 올바른 바이트가 그대로 들어 있고, Excel이 잘못된 인코딩으로 디코딩하고 있을 뿐이다. 이것이 가장 흔한 경우이며, 이 가이드의 모든 해결 방법은 여기서 출발한다.

두 번째 단서는 어떤 문자가 잘못 표시되는지이다. 일반 영문 텍스트, 숫자, 문장 부호는 정상인데 악센트 문자, 움라우트, 세디유, 유로 기호, 라틴 문자가 아닌 문자만 잘못 보인다면, 이는 구분자 문제도 아니고 손상도 아니며 인코딩 불일치이다. 구분자 문제는 행 전체를 한 열에 몰아넣는다. 손상은 모든 것을 뒤섞거나 행을 빠뜨린다. 인코딩 문제는 정확히 UTF-8에서 한 바이트를 초과하는 문자들만 깨뜨리고 나머지는 그대로 둔다. José가 José로 보이거나, München이 München으로 보인다면, 그 패턴 자체가 UTF-8 바이트를 오래된 단일 바이트 인코딩으로 읽었다는 지문이며, 원인과 해결 방법을 동시에 알려준다.

세 번째 확인 사항은 구제가 아직 가능한지 여부이다. 텍스트 편집기에서도 문자가 깨져 보인다면, 파일 자체가 잘못 읽힌 뒤 다시 저장되면서 잘못된 문자들이 파일에 그대로 기록되었을 수 있다. 아직 당황할 필요는 없으며, 무엇보다 원본 위에 다시 저장해서는 안 된다. 이 가이드의 구제 절에서는 바로 이 경우를 다루며, 진짜로 복구할 수 없는 경우는 딱 하나이다. 저장 과정에서 문자가 물음표나 대체 기호로 바뀌었다면, 그 복사본에서는 원래 정보가 사라진 것이며, 원본 데이터로만 다시 만들 수 있다. 확인이 끝날 때까지 원본 파일은 손대지 말고, 복사본으로 작업하며, 깨진 파일을 좋은 파일 위에 덮어쓰는 일은 절대 하지 말자.

Excel이 왜 잘못 추측하는가: CSV 파일에는 인코딩 표시가 없다

이 문제가 계속 반복되는 이유를 이해하려면 CSV 형식에 대한 사실 하나를 알아야 한다. CSV 파일은 어떤 인코딩을 사용했는지 알려주는 머리말이 없는 순수 텍스트이다. 스프레드시트 파일은 구조와 텍스트 인코딩을 함께 가지고 있지만, CSV 파일은 둘 다 가지고 있지 않다. 바이트와 쉼표, 줄 바꿈만 있을 뿐이다. 프로그램이 파일을 열면 바이트를 문자로 바꾸는 방법을 스스로 정해야 하며, 프로그램마다 그 결정이 다르다. 최신 텍스트 편집기와 구글 시트는 대부분의 경우 UTF-8을 자동으로 감지하므로 같은 파일이 그곳에서는 정상으로 보인다. 반면 Excel은 CSV 파일을 더블 클릭해서 열 때 감지하지 않는다. 시스템 기본 인코딩을 그대로 사용하며, 많은 윈도우 시스템에서 그 기본값은 Windows-1252 같은 오래된 코드 페이지이고, 그 추측이 맞는지 확인하지도 않는다.

그 가정이 문제의 전부이다. UTF-8에서 é 같은 문자는 두 바이트로 표현되고, € 같은 문자는 세 바이트로 표현된다. 오래된 단일 바이트 인코딩은 각 바이트를 각각 하나의 문자로 읽으므로, é 하나가 잘못된 문자 두 개(é)가 되고, € 하나가 잘못된 문자 세 개(€)가 된다. 파일은 변하지 않았다. 바이트의 의미를 해석하는 쪽이 바뀐 것이다. 그래서 이 문제는 지역과 컴퓨터에 따라 다르게 나타난다. 파일과 같은 기본 인코딩을 쓰는 동료의 컴퓨터에서는 정상으로 보이고, 내 컴퓨터에서는 깨져 보이며, 같은 파일이 한 컴퓨터에서는 멀쩡하고 다른 컴퓨터에서는 깨져 보일 수 있다. 어느 컴퓨터도 고장 난 것이 아니고 파일이 손상된 것도 아니다. 두 프로그램이 바이트의 의미를 다르게 해석할 뿐이며, 더블 클릭한 Excel은 묻지도 않고 자기 기본값을 믿는다.

이것은 JSON에서 변환한 파일에서 이 문제가 자주 나타나는 이유도 설명한다. JSON은 정의상 UTF-8이므로, JSON을 CSV로 변환하면 자연스럽게 UTF-8 CSV가 만들어지며, 원본 데이터에 들어 있던 모든 악센트 이름과 도시, 통화 기호가 그대로 포함된다. 변환은 올바르다. 열기가 맞지 않는 것이다. 이 페이지의 변환기를 예로 들면, 다운로드 파일은 BOM이 없는 순수 UTF-8이다. 이는 웹 업로드, 데이터베이스, 구글 시트, 파이썬에 올바른 선택이지만, 윈도우 Excel에서 더블 클릭하면 잘못된 인코딩을 추측할 수 있다는 뜻이다. 불일치가 변환 단계가 아니라 열기 단계에 있다는 것을 알면, 해결할 위치도 분명해진다. 다음 절에서 설명하는 가져오기 단계에서 고치거나, BOM을 추가하는 것이다.

깨진 문자 읽기: 이상한 문자가 알려주는 것

망가진 텍스트는 무작위가 아니며, 이를 읽는 법을 알면 원본 문자를 파악하고 아무것도 건드리기 전에 진단을 확정할 수 있다. 대표적인 패턴은 à 뒤에 다른 문자가 오는 형태이다. é, ä, ü, ç가 보인다면, UTF-8 문자를 Windows-1252로 읽은 것이다. Ã는 UTF-8 순서의 첫 번째 바이트가 자기 혼자 하나의 문자로 잘못 읽힌 것이고, 뒤의 문자도 두 번째 바이트가 잘못 읽힌 것이다. 패턴을 알면 머릿속으로 깨진 문자를 되돌릴 수 있다. é는 é였고, ü는 ü였고, ç는 ç였고, ão는 ão였으므로, São Paulo는 São Paulo로 보인다. 유로 기호가 가장 극적이다. €는 UTF-8에서 세 바이트이므로 세 문자 €로 표시된다. 긴 대시는 â€로, 곡선 작은따옴표는 ’로 표시된다.

문자에 따라 패턴이 달라지며, 그 차이 자체도 진단 단서가 된다. 라틴 문자 이름은 위의 à 패턴을 만든다. 일본어, 한국어 같은 라틴 문자가 아닌 문자들은 더 긴 깨짐을 만든다. 각 문자가 UTF-8에서 세 바이트이기 때문에 문자 하나가 잘못된 문자 세 개가 되기 때문이다. 東京라고 쓴 도쿄는 æ±äº¬ 같은 문자들의 나열로 보이고, 한국 이름도 비슷한 나열이 된다. 그런 긴 깨짐이 보인다면 진단은 같다. 단일 바이트 인코딩으로 UTF-8을 읽은 것이며, 다만 관련된 문자가 세 바이트짜리일 뿐이다. 반대로 문자 자리에 물음표나 검은 다이아몬드 대체 기호가 보인다면 진단은 다르다. 그 기호들은 표시 단계에서 잘못 읽힌 것이 아니라, 저장 단계에서 이미 정보가 손실되었다는 뜻이며, 그 경우의 대처법은 구제 절에서 다룬다.

아래 코드 블록은 정확한 오독 사례를 보여준다. 올바른 UTF-8 텍스트를 Excel이 더블 클릭할 때처럼 Windows-1252로 디코딩해서 만든 것이다. 지어낸 예가 아니다. 각 쌍은 기계적으로 생성되었으므로, 자신의 파일과 대조해서 진단을 확정한 뒤에 해결에 들어가면 된다. 자신의 파일이 오른쪽에 있어야 할 문자 대신 왼쪽의 형태를 보여준다면 인코딩 불일치가 맞으며, 다음 절의 가져오기 해결 방법이 파일을 바꾸지 않고 표시를 고쳐줄 것이다.

Correct text  ->  What Excel shows\nJosé García  ->  José GarcÃ\u00ada\nMünchen      ->  München\nFrançois     ->  François\nSão Paulo    ->  São Paulo\n€50,000      ->  €50,000\ncafé — ok    ->  café — ok\n東京 (Tokyo)  ->  æ\u00b1京\n김민준        ->  김민준

이 표가 증명하는 것은 아무것도 빠지지 않았다는 점이다. 잘못된 문자 하나하나가 원본의 실제 바이트에 대응하며, 다만 잘못된 표로 디코딩되었을 뿐이다. 그래서 가져오기 해결 방법이 그토록 완전하게 동작한다. Excel에 파일이 UTF-8이라고 알려주면, Excel은 같은 바이트를 올바른 표로 디코딩하고 모든 문자가 제자리로 돌아오며, 편집도, 찾기 및 바꾸기도, 직접 입력도 필요 없다. 파일이 이 패턴과 일치한다면 구제 절은 건너뛰고 바로 가져오기 해결 방법으로 가자. 손상된 파일이 아니라 잘못 읽힌 파일이다.

해결 방법 1: 파일을 가져오면서 Excel에 UTF-8이라고 알려주기

이 방법을 먼저 시도해야 한다. 시스템도 바꾸지 않고 파일도 바꾸지 않으며, 구분자가 무엇이든 모든 UTF-8 CSV에 동작하기 때문이다. 파일을 더블 클릭하는 대신 Excel을 먼저 연 뒤, 안내에 따라 가져오기를 진행하면서 인코딩을 직접 선택한다. 가져오기 대화 상자의 미리 보기에서 선택이 맞는지 바로 확인할 수 있다. 미리 보기에서 문자가 정상으로 보이면, 불러온 뒤에도 그대로 시트에 나타난다. 미리 보기에서 여전히 깨져 보인다면 아직 아무것도 바뀐 것이 아니므로, 불러오기 전에 다른 파일 원본을 시도해볼 수 있다.

• ▸Excel에서 데이터, 텍스트/CSV에서 가져오기를 선택하고 파일을 고른다.
• ▸미리 보기 대화 상자에서 파일 원본을 65001: Unicode(UTF-8)로 설정한다. 오래된 Excel 버전에서는 텍스트 가져오기 마법사에서 같은 옵션이 Unicode(UTF-8)로 나타난다.
• ▸미리 보기를 확인한다. 문자가 이제 정상으로 읽힌다면 계속 진행한다. 여전히 잘못 보인다면 파일 자체가 UTF-8이 아닐 수 있으므로, 목록의 다른 원본들을 하나씩 시도하면서 미리 보기를 살펴본다.
• ▸파일이 사용하는 구분자를 설정한다. 쉼표, 세미콜론, 탭, 파이프 중 하나이며, 같은 미리 보기에서 열이 올바르게 나뉘는지 확인한다.
• ▸불러오기를 클릭한다. 앞자리 0이 있는 코드처럼 반드시 텍스트로 유지해야 하는 열은 불러오기 전에 해당 열을 텍스트로 설정한다.

이 방법을 구조용 임시 방편이 아니라 CSV를 여는 기본 방식으로 삼자. 더블 클릭은 구분자와 인코딩을 모두 추측에 맡기는 것이고, 가져오기는 둘 다 직접 선택하는 것이며, 걸리는 시간은 열 초 정도 더 길 뿐이다. 맥에서도 같은 해결 방법이 동작하며, 가져오기 경로가 역시 안정적이다. 빈 통합 문서를 열고 데이터, 텍스트에서 가져오기를 선택하고 파일을 고른 뒤 파일 원본으로 Unicode(UTF-8)를 선택하고 마치면 된다. 구글 시트는 대부분의 경우 별도 해결이 필요 없는데, 파일, 가져오기가 UTF-8을 자동으로 감지하기 때문이다. 그래서 Excel에서는 깨져 보이던 파일이 시트에서는 멀쩡하게 보이는 경우가 많다. 그 차이 자체가 진단이다. 시트에서는 맞고 Excel에서는 틀리다면, 파일은 정상이고 Excel이 잘못 추측한 것이다.

해결 방법 2: BOM을 추가해서 더블 클릭으로도 열리게 하기

같은 종류의 파일을 매일 연다면 매번 가져오기는 번거로워지고, 오래가는 해결 방법은 더블 클릭할 때 Excel이 필요로 하는 힌트를 파일에 주는 것이다. 그 힌트가 BOM, 즉 바이트 순서 표시이다. 파일 맨 앞에 붙는 보이지 않는 세 바이트로, 이 파일이 UTF-8이라는 뜻이다. Excel은 추측하기 전에 BOM을 먼저 확인하므로, BOM이 있는 UTF-8 파일은 기본 인코딩이 Windows-1252인 윈도우 시스템에서도 더블 클릭으로 정상 열리게 된다. BOM은 Excel과 대부분의 편집기에서 보이지 않으며, 어떤 데이터 행도 바꾸지 않는다. 파일의 처음 세 바이트에만 영향을 준다.

코드가 필요 없는 가장 쉬운 추가 방법은 메모장을 이용하는 것이다. 파일을 메모장으로 열고 파일, 다른 이름으로 저장을 선택한 뒤 인코딩 드롭다운을 BOM 포함 UTF-8로 설정하고 저장하면 된다. 이제 파일은 Excel에서 더블 클릭으로 정상 열린다. 스크립트에서 파일을 만든다면, 나중에 파일을 고치기보다 작성 시점에 BOM을 추가하는 것이 낫다. 파이썬에서는 단어 하나만 바꾸면 된다. 파일을 열 때 utf-8 대신 utf-8-sig 인코딩으로 열면 파이썬이 BOM을 대신 써준다. 아래 스니펫이 그 방법을 보여주며, 생성되는 바이트도 검증되었다. 파일은 세 바이트의 BOM으로 시작하고, 그 뒤에 순수 UTF-8 데이터가 이어진다.

with open("customers.csv", "w", encoding="utf-8-sig", newline="") as f:\n    f.write("name,city\n")\n    f.write("José García,München\n")\n# First bytes of the file: EF BB BF, then the UTF-8 data.\n# Excel now opens it correctly on double-click.

BOM을 모든 곳에 추가하기 전에 주의할 점이 두 가지 있다. 첫째, 일부 도구는 BOM을 표시가 아니라 데이터로 취급한다. 엄격한 CSV 파서는 첫 번째 헤더를 이름이 아니라 BOM과 이름이 합쳐진 것으로 읽어서 헤더 조회가 깨질 수 있다. 이 페이지의 변환기가 의도적으로 BOM 없이 다운로드하는 이유가 바로 이것이다. 순수 UTF-8은 웹 업로드, 데이터베이스, 파이썬에 올바른 형태이며, BOM은 Excel 더블 클릭을 위한 편의일 뿐이다. 따라서 BOM은 Excel용 복사본에만 추가하고, 다른 도구에 들어가는 원본 파일에는 추가하지 말자. 둘째, BOM은 UTF-8이 아닌 파일을 고쳐주지 않는다. Windows-1252로 작성된 파일 위에 BOM을 얹으면 오히려 상황이 악화된다. Excel이 단일 바이트 데이터를 UTF-8로 디코딩하면서 새로운 깨짐을 만들기 때문이다. BOM은 UTF-8임이 확실한 파일에만 추가해야 하며, 이는 진단 절의 텍스트 편집기 테스트로 확인할 수 있다.

이미 깨진 상태로 저장된 파일 구하기

지금까지의 모든 해결 방법은 디스크 위 파일이 여전히 올바르고 표시만 잘못되었다는 전제였다. 하지만 깨진 버전이 이미 저장된 경우도 있으며, 이때 문제는 저장된 복사본에서 원래 문자를 되찾을 수 있는지이다. 답은 저장 과정에서 정확히 무슨 일이 있었는지에 따라 달라지며, 두 가지 경우를 구분해야 한다. 첫 번째 경우는 디스크 위 파일이 여전히 원래 UTF-8 바이트를 가지고 있고 Excel 표시만 잘못된 경우이다. 텍스트 편집기 테스트가 바로 이 경우를 잡아낸다. 편집기에서 문자가 정상으로 보이면 손실된 것이 없으며, 해결 방법 1이 표시를 고쳐준다. 두 번째 경우는 디스크 위 파일이 이제 잘못된 문자 자체를 포함하는 경우이다. 누군가 Excel에서 파일을 열고 깨진 문자를 본 뒤 CSV로 다시 저장하면서, 잘못 읽힌 문자들을 파일에 써버렸기 때문이다.

두 번째 경우도 종종 구할 수 있으며, 판별 기준은 깨짐이 디코더 절에서 설명한 à 패턴을 따르는지 여부이다. 저장된 파일에 é 대신 é라는 문자가 그대로 들어 있다면, 구제는 다시 인코딩하는 것이다. 파일을 Windows-1252인 것처럼 읽으면 Excel이 잘못 읽었던 원래 UTF-8 바이트가 되돌아오고, 그 바이트를 UTF-8로 디코딩하면 원래 문자가 되돌아온다. 아래 스니펫이 정확히 그 작업을 하며, 실제 파일로 검증되었다. José라고 쓰인 이름이 José로 잘못 읽힌 뒤, 왕복 과정을 거쳐 바이트 단위로 José로 되돌아왔다. 복사본으로 작업하고, 유일한 버전을 직접 건드리지 말며, Excel에서 다시 열기 전에 텍스트 편집기에서 결과를 확인하자.

with open("mangled.csv", "r", encoding="cp1252") as f:\n    text = f.read()\n# Encode back to the bytes Excel misread, then decode as UTF-8.\nfixed = text.encode("cp1252").decode("utf-8")\nwith open("fixed.csv", "w", encoding="utf-8") as f:\n    f.write(fixed)\n# Verified: José -> José, München -> München.

다시 인코딩하는 방법에는 반드시 지켜야 할 한 가지 한계가 있다. 잘못 읽힌 문자들이 é와 그 짝 문자들처럼 저장 과정에서 온전하게 살아남았을 때만 동작한다는 점이다. 저장 과정에서 문자가 물음표나 검은 다이아몬드 대체 기호로 바뀌었다면, 그 복사본에서는 원래 정보가 사라진 것이다. 어떤 디코딩도 자리 표시자로 바뀐 문자를 되찾을 수 없는데, 자리 표시자는 어떤 문자였는지에 대한 정보를 가지고 있지 않기 때문이다. 그 경우에는 복사본 수리를 멈추고 원본에서 파일을 다시 생성하자. 데이터베이스, 도구, 또는 원래 JSON에서 다시 내보내고, 이번에는 해결 방법 1로 열거나 해결 방법 2로 BOM을 부여한다. 그리고 어떤 경우든 대체 파일이 제대로 동작하는지 확인하기 전까지 손상된 복사본은 옆에 두자. 대체 파일을 검증하기 전에 유일한 복사본을 삭제하는 것이, 구할 수 있었던 문제를 잃어버린 데이터셋으로 만드는 지름길이다.

이 페이지 변환기에서 나온 파일에 대한 의미

이 페이지의 변환기는 이 가이드가 다루는 바로 그런 파일을 만들므로, 그 동작을 분명하게 밝혀둘 가치가 있다. 다운로드 파일은 BOM이 없는 순수 UTF-8이다. 이는 추측이 아니라 실제 코드를 검증한 결과이다. 다운로드는 charset=utf-8인 text/csv Blob을 만들고 앞에 표시를 쓰지 않으며, 변환 엔진 자체도 José García, München, François, Łódź, São Paulo, 유로 금액, 일본어 도쿄, 한국 이름을 담은 샘플로 실행되었고, 모든 문자를 바이트 단위로 동일하게 만들었으며, 출력 시작 부분에 BOM이 없었다. 따라서 변환된 파일이 Excel에서 깨진 문자로 보인다면, 변환이 무엇인가를 손상시킨 것이 아니다. 파일은 올바른 UTF-8이며, Excel이 더블 클릭할 때 잘못된 인코딩을 추측한 것이다.

변환된 파일에 대해서는 두 가지 깔끔한 선택지가 있다. 첫째는 가져오기 경로이다. 다운로드한 파일을 데이터, 텍스트/CSV에서 가져오기로 열고, 파일 원본을 65001: Unicode(UTF-8)로 설정한 뒤 불러오면 된다. 문자는 정상으로 읽히며, 파일 자체는 아무것도 바꾸지 않았으므로 다른 모든 도구에도 유효하게 남는다. 둘째는 BOM 경로이다. 다운로드한 파일을 메모장으로 열고 BOM 포함 UTF-8로 저장한 뒤, 그 복사본은 Excel용으로 쓰고 원래 다운로드 파일은 다른 용도로 남겨두면 된다. 인코딩 표시 문제를 고치겠다고 데이터를 다시 변환하지 말고, 변환된 출력을 스프레드시트에 붙여넣고 다시 저장하지 말자. 그 왕복 과정이 바로 이 가이드가 막으려는 구분자와 인코딩 불일치를 만들 수 있기 때문이다. 데이터를 고치는 것이 아니라 열기를 고치자.

변환기 관련 세부 사항이 하나 더 있다. 변환기는 다운로드 전에 구분자를 선택하게 하며, 그 선택은 인코딩과 무관하다. 파일은 구분자는 맞는데 인코딩 표시가 틀릴 수도 있고, 인코딩은 맞는데 구분자가 틀릴 수도 있으며, 둘 다 틀릴 수도 있다. 변환된 파일이 한 열로 열리면서 문자까지 잘못 보인다면, 같은 가져오기에서 두 설정을 함께 고치자. 변환 시 선택했던 구분자를 고르고, 파일 원본을 65001로 설정한다. 한 열로 열리는 문제의 구분자 쪽은 아래 관련 가이드에 연결된 동반 가이드에서 자세히 다루고 있다.

예방 체크리스트: 누구도 고칠 필요가 없도록 올바르게 내보내기

인코딩 문제는 쓰는 쪽과 읽는 쪽의 불일치이므로, 예방이란 쓰는 쪽이 무엇을 썼는지 읽는 쪽이 받아들일 방식으로 선언하는 것이다. CSV를 만들 때 이 체크리스트를 실행하면, 다음에 파일을 여는 사람은 이 가이드가 필요 없게 된다. 첫째, 내보내기 시점에 인코딩을 알자. 데이터에 순수 아스키를 넘는 내용이 있다면 UTF-8로 내보내고, 파일 이름이나 함께 전달되는 메모에 그렇게 적어두자. CSV 파일은 스스로 말할 수 없기 때문이다. 둘째, 독자가 윈도우 Excel이라면 Excel용 복사본에 BOM을 추가하거나, Excel 다른 이름으로 저장에서 CSV UTF-8 형식을 이용해 내보내자. 그 형식은 BOM을 대신 써준다. 셋째, 파일이 다른 도구에도 들어간다면 그 도구들을 위해 BOM이 없는 순수 UTF-8 복사본을 따로 유지하자. 일부 파서는 BOM을 첫 번째 헤더의 일부로 취급하기 때문이다.

넷째, 구제한 파일을 텍스트 편집기에서 검증하기 전에는 원본 위에 다시 저장하지 말자. Excel에서 저장하면 구분자와 인코딩이 모두 Excel 기본값으로 다시 쓰이면서, 다음 독자에게 불일치가 다시 생기거나 표시 문제가 실제 데이터 손실로 바뀔 수 있다. 다섯째, 파일을 받았을 때 무엇인가 이상해 보인다면 먼저 텍스트 편집기로 열고, 어떤 스프레드시트가 그 위에 저장하기 전에 인코딩을 확인하자. 여섯째, 원본 데이터를 보관하자. CSV는 데이터 자체가 아니라 평탄화된 스냅샷이므로, 구제가 잘못되더라도 원본이 있으면 깨끗하게 다시 내보낼 수 있다. 대부분의 인코딩 공포 이야기는 손상된 CSV가 유일한 복사본이었다는 것을 너무 늦게 알게 되면서 끝난다. 내 파일이 그렇게 되지 않게 하자.

관련 가이드

• CSV가 Excel에서 한 열로 열리는 이유와 해결 방법 (2026 가이드) →
• JSON 파일을 온라인에서 CSV 파일로 변환하려면 어떻게 해야 하나요? (2026년 가이드) →
• JSON을 CSV로 로컬에서 변환하는 방법은? 6가지 방법 비교 (2026 가이드) →
• Excel이 CSV 코드의 앞자리 0을 지우는 이유와 이를 지키는 방법 (2026 가이드) →
• 엑셀에서 CSV 날짜가 바뀌는 이유와 날짜를 그대로 지키는 방법 (2026 가이드) →
• 엑셀에서 CSV를 저장하면 파일이 바뀌는 이유와 원본을 안전하게 지키는 방법 (2026 가이드) →
• 엑셀로 열리지 않는 큰 CSV 파일, 원인과 해결 방법 (2026 가이드) →

자주 묻는 질문