엑셀로 열리지 않는 큰 CSV 파일, 원인과 해결 방법 (2026 가이드)

30초 진단: 파일을 탓하기 전에 행 수부터 세세요

엑셀이 CSV 파일을 거부하거나 잘라서 열 때 가장 먼저 확인할 것은 파일이 실제로 몇 행을 들고 있는지입니다. 해결책은 전적으로 그 숫자에 달려 있고, 추측은 시간 낭비이기 때문입니다. 행이 90만 개인 파일은 엑셀에서 잘 열리고, 문제는 구분자나 인코딩 같은 다른 데 있으며, 이는 동반 가이드에서 다룹니다. 행이 120만 개인 파일은 그리드 제한에 걸리고, 엑셀 안의 어떤 설정으로도 맞출 수 없습니다. 먼저 세고, 숫자에 맞는 해결책을 고르세요. 무작정 해결책을 시도하지 마세요.

가장 빠른 세는 방법은 터미널 외에 다른 소프트웨어가 필요 없습니다. 윈도우에서는 PowerShell을 열고 Get-Content와 Measure-Object를 실행하고, 맥이나 리눅스에서는 파일에 wc -l을 실행하면 줄 바꿈을 셉니다. 상태 표시줄에 줄 수가 나오는 텍스트 편집기도 쓸 수 있지만, 아주 큰 파일은 편집기에서 여는 데 시간이 걸릴 수 있습니다. 이렇게 얻는 숫자는 줄 수이지 데이터 행 수가 아닙니다. 머리글이 있는 파일은 데이터 행보다 한 줄이 더 많고, 따옴표 안에 줄 바꿈이 들어 있는 값은 한 줄보다 더 차지할 수 있어서, 줄 수는 정확한 행 수가 아니라 상한이며, 대부분의 내보내기 파일에서는 판단하기에 충분히 정확합니다.

정확한 개수를 세려면 파이썬 csv 모듈을 쓰세요. 파일을 한 행씩 읽고 메모리에 통째로 올리지 않기 때문에 스프레드시트로는 너무 큰 파일에도 쓸 수 있습니다. 아래 스니펫은 데이터 행 1,200,000개인 테스트 파일을 몇 초 만에 셌고, 따옴표 안 줄 바꿈이 없는 파일이라 줄 수와 정확히 일치했습니다. 두 개수가 파일에서 다르면 csv 모듈 개수를 믿으세요. 그 차이는 줄 바꿈이 들어 있는 값 때문이며, 파일에 따옴표로 묶인 여러 줄 값이 있다는 뜻이기도 하고, 이는 이 가이드 뒤쪽의 분할 방법에서 중요합니다.

Terminal (Mac or Linux):
$ wc -l big_sample.csv
1200001 big_sample.csv

PowerShell (Windows):
PS> (Get-Content big_sample.csv | Measure-Object -Line).Lines
1200001

Python (exact row count, one row at a time):
import csv
with open('big_sample.csv', newline='') as f:
    reader = csv.reader(f)
    header = next(reader)
    rows = sum(1 for _ in reader)
print(header, rows)
# ['id', 'name', 'total'] 1200000

Lines minus the header row: 1,200,001 - 1 = 1,200,000 data rows.
That is 151,425 rows over Excel's limit.

이 테스트 파일이 증명하는 것을 눈여겨보세요. 세 열이 짧은 120만 행 CSV 파일은 디스크에서 약 32MB에 불과하므로 문제는 메가바이트 단위의 파일 크기가 아닙니다. 사람들은 큰 파일이면 수백 메가바이트일 거라고 예상하지만, 짧은 행이 백만 개 모인 좁은 파일은 디스크에서는 작고 그리드에는 여전히 너무 큽니다. 중요한 숫자는 메가바이트가 아니라 행 수이며, 그래서 세는 것이 첫 단계입니다. 파일이 1,048,575개 데이터 행을 넘으면 그리드 제한 문제이며, 이 가이드의 나머지가 적용됩니다. 그보다 적으면 문제는 다른 데 있으며, 한 열로 열리는 문제, 인코딩 문제, 앞자리 0 문제를 다룬 동반 가이드를 보세요.

결정적인 숫자 하나: 1,048,576행

엑셀은 워크시트 하나에 최대 1,048,576행과 16,384열까지 담을 수 있고, 셀 하나에는 최대 32,767자까지 들어갑니다. 이는 현재 스프레드시트 형식의 공개된 제한이며, 수년째 바뀌지 않았습니다. 머리글 행도 1,048,576행 중 하나로 세기 때문에, 머리글이 있는 CSV 파일은 한 시트에 최대 1,048,575개의 데이터 행까지만 담을 수 있습니다. 데이터 행 1,048,576개에 머리글을 더한 파일은 한 행이 넘고, 엑셀은 잘라냅니다. 오래된 .xls 형식은 훨씬 작아서 시트당 65,536행이므로, 파일이 오래된 시스템에서 나왔다면 형식도 확인하세요. 하지만 최신 엑셀에서 여는 .csv 파일이라면 1,048,576이 그 숫자입니다.

CSV 형식 자체에는 제한이 전혀 없습니다. CSV 파일은 일반 텍스트로, 행은 줄 바꿈으로, 값은 구분자로 나뉘며, 형식 설명인 RFC 4180은 행, 열, 바이트의 최대 개수에 대해 아무것도 말하지 않습니다. CSV 파일은 디스크 공간이 허용하는 만큼 행을 담을 수 있고, 이 가이드의 테스트 파일은 32MB 안에 120만 행을 문제없이 담고 있습니다. 제한은 파일을 여는 쪽에서 나오지 파일 자체에서는 나오지 않으므로, 같은 파일이 텍스트 편집기나 데이터베이스에서는 온전히 열리고 엑셀에서는 잘립니다. 파일이나 내보낸 프로그램을 탓하는 것은 핵심을 놓치는 것입니다. 내보낸 쪽은 제 역할을 했고, 천장이 있는 쪽은 읽는 쪽입니다.

실제로는 두 가지 다른 숫자가 문제를 좌우합니다. 첫째는 열 수입니다. 16,384열은 넉넉하고, 실제 CSV가 거기에 근접하는 일은 거의 없어서 열이 제한이 되는 경우는 드뭅니다. 둘째는 메모리입니다. 엑셀은 보여주는 행을 메모리에 올리고, 행 수 제한에 가까운 파일에 행이 넓으면 행 수가 기술적으로 제한 아래라도 프로그램이 느려지거나 멈출 수 있습니다. 값이 짧은 백만 행은 잘 열리지만, 텍스트가 긴 백만 행은 열리지 않을 수 있으므로, 1,048,576을 절대 상한으로, 행이 넓은 수십만 행을 실질 상한으로 생각하세요. 파일이 크면서 느리기까지 하다면 이 가이드의 분할 방법이 두 번 도움이 됩니다. 작은 파일은 빠른 파일이기 때문입니다.

파일이 너무 클 때 엑셀이 실제로 하는 일

그리드가 담을 수 있는 것보다 행이 많은 CSV 파일을 열면 엑셀은 파일을 거부하지 않습니다. 머리글을 포함한 처음 1,048,576행을 불러오고, 데이터 집합이 그리드에 너무 커서 저장하면 불러오지 못한 데이터가 사라진다는 경고를 보여줍니다. 마이크로소프트 자체 지원 페이지는 모든 언어에서 정확히 이렇게 표현합니다. 데이터 집합이 엑셀에서 사용할 수 있는 행 수를 초과하므로 일부 데이터가 불러와지지 않았습니다. 나머지 행은 디스크의 파일에 그대로 있지만 통합 문서에는 없고, 화면에서는 어떤 행이 빠졌는지 개수 외에는 알 수 없습니다.

위험한 부분은 조용하다는 점입니다. 통합 문서는 완전해 보입니다. 머리글이 있고, 시트 맨 아래까지 행이 있으며, 빠진 행은 틈도 표시도 없이 그냥 없습니다. 그 통합 문서에서 정렬, 필터, 차트를 만들면 부분 데이터 집합으로 작업하게 되고, 처음 백만 행이 대표성을 띠는 경우가 많아서 결과를 알아채기 어렵게 틀립니다. 잘린 통합 문서로 계산한 합계, 평균, 개수는 모두 실제보다 적고, 오차는 제한을 넘는 행이 늘어날수록 커집니다. 120만 행 파일은 데이터의 약 8분의 1을 조용히 잃고, 500만 행 파일은 5분의 4를 잃으면서도 화면에서는 똑같이 보입니다.

파괴적인 부분은 저장할 때 일어납니다. 잘린 통합 문서를 저장하면 엑셀이 불러온 행만 다시 쓰므로, 그리드에 들어가지 못한 행은 저장된 파일에서 영구적으로 사라집니다. 저장에 대한 동반 가이드에서 이 왕복 과정을 자세히 다루지만, 여기서 규칙은 절대적입니다. 그리드 제한 경고를 보여준 통합 문서에서 원본 CSV 위에 저장하지 마세요. 유일한 사본 위에 이미 저장했다면 OneDrive나 SharePoint 버전 기록, 백업, 이메일 첨부 파일, 파일이 나온 원본 시스템을 확인하세요. 저장된 파일에는 빠진 행이 더 이상 없고, 어떤 수식으로도 되돌릴 수 없기 때문입니다. 잘린 통합 문서는 저장하지 않고 닫고, 원본 파일에서 아래 해결 방법 중 하나로 다시 시작하세요.

앱별 제한: 엑셀, 구글 시트, 리브레오피스, 그리고 제한이 없는 도구

모든 프로그램이 같은 지점에서 멈추는 것은 아니므로, 올바른 해결책은 다른 프로그램에서 시작할 때가 있습니다. 엑셀은 위에서 말한 대로 워크시트당 1,048,576행과 16,384열에서 멈춥니다. 리브레오피스 Calc도 1,048,576행에서 멈추지만 열은 1,024개까지만 되므로, 넓은 파일에도 도움이 되지 않습니다. 애플 Numbers는 파일이 약 1,000,000줄을 넘으면 경고를 보여주므로 같은 부류입니다. 구글 시트는 행이 아니라 셀을 셉니다. 스프레드시트 하나에 최대 2,000만 셀까지 담을 수 있고, CSV 가져오기도 100MB로 제한되므로, 좁은 파일은 엑셀보다 더 많은 행을 담을 수 있고, 넓은 파일은 더 적은 행을 담으며, 정확한 행 제한은 열 수에 달려 있습니다. 10개 열 파일은 구글 시트에 약 200만 행까지 들어가고, 50개 열 파일은 약 40만 행까지 들어갑니다.

텍스트 편집기는 자체 행 제한이 없고 컴퓨터 메모리만 제한이 되므로, 큰 CSV 파일은 메모장, 텍스트편집기, VS Code에서 일반 텍스트로 온전히 열리고, 검색하고 처음과 마지막 행을 읽고 머리글을 확인할 수 있지만, 스프레드시트처럼 정렬하거나 필터링할 수는 없습니다. 그래서 텍스트 편집기는 큰 파일을 살펴보는 데는 맞는 도구이고 분석하는 데는 틀린 도구입니다. 파이썬과 csv 모듈에도 행 제한이 없고 메모리만 제한이 되며, csv 모듈이 한 행씩 읽기 때문에 메모리를 거의 쓰지 않고 스프레드시트보다 훨씬 큰 파일을 세고, 필터링하고, 나눌 수 있습니다. 데이터베이스 방식에는 실질적인 행 제한이 전혀 없습니다. CSV를 SQLite, Postgres, 데스크톱 데이터베이스에 가져오면 백만 행은 작은 표가 됩니다.

실질적인 규칙은 파일을 우연히 열어둔 도구에 억지로 맞추지 말고 도구를 작업에 맞추는 것입니다. 데이터를 봐야 한다면 텍스트 편집기를 쓰세요. 필터링하거나 나눠야 한다면 스크립트를 쓰세요. 전부 그리드에서 분석해야 한다면 아래 데이터 모델 해결 방법을 쓰거나 데이터베이스를 쓰세요. 요약만 필요하다면 스크립트로 파일을 집계하고 작은 요약을 엑셀에서 여세요. 파일이 문제가 아니고 스프레드시트가 고장 난 것도 아닙니다. 백만 행 데이터 집합과 백만 행 그리드 사이의 불일치가 문제이며, 해결책은 그리드에 담을 수 있는 것보다 더 많이 담으라고 요구하지 않는 것입니다.

해결 방법 1: 파일을 엑셀이 열 수 있는 크기로 나누세요

보통 워크시트에서 데이터가 필요할 때는 나누는 방법이 가장 먼저 시도할 해결책입니다. 간단하고, 파이썬 외에는 아무것도 필요 없으며, 모든 청크가 머리글을 온전히 갖춘 채 엑셀에서 정상적으로 열리기 때문입니다. 방법은 파일을 한 행씩 읽으면서 청크마다 최대 1,048,575개의 데이터 행을 쓰고, 모든 청크 맨 위에 머리글 행을 반복해서, 청크마다 그 자체로 완전한 CSV 파일이 되게 하는 것입니다. 1,048,576이 아니라 1,048,575를 쓰는 이유는 머리글이 한 행으로 세기 때문이며, 데이터 행 1,048,576개에 머리글을 더한 청크는 다시 한 행이 넘기 때문입니다. 아래 스크립트가 정확히 그렇게 하며, 파이썬 표준 라이브러리만 쓰므로 설치할 것이 없습니다.

이 스크립트는 진단 절의 1,200,000행 샘플 파일로 테스트했는데, 디스크에서 32MB입니다. 두 개 청크가 나왔습니다. 첫 번째 청크는 머리글에 데이터 행 1,048,575개를 더해 정확히 1,048,576줄이고, 두 번째 청크는 머리글에 남은 데이터 행 151,425개를 더했습니다. 두 번째 청크에서 반복된 머리글을 제거하고 청크를 다시 합치면 원본과 바이트 단위로 똑같은 파일이 나왔고, 파일 해시를 비교해 확인했으므로, 분할은 아무것도 잃지 않고 아무것도 바꾸지 않습니다. 500만 행 파일도 같은 방식으로 다섯 청크로 나뉘고, 1,000만 행 파일은 열 개 청크로 나뉘며, 디스크 공간 외에는 상한이 없습니다.

나눌 때 중요한 세부 사항이 두 가지 있습니다. 첫째, 모든 청크에 머리글을 넣으세요. 머리글이 없는 청크는 첫 데이터 행을 머리글로 삼아 열리고 열 이름이 사라지기 때문입니다. 둘째, 엑셀에서 열고 행을 손으로 복사해서 파일을 나누지 마세요. 손으로 복사하는 작업은 잘린 통합 문서에서 시작하므로 제한을 넘은 행은 이미 빠져 있기 때문입니다. 엑셀이 파일을 건드리기 전에 디스크의 원본 파일에서 스크립트로 나누세요. 청크가 생기면 한 번에 하나씩 열고, 작업을 하고, 원본 파일은 따로 보관하세요. 청크는 작업용 사본이고 원본이 유일하게 완전한 사본이기 때문입니다.

import csv

LIMIT = 1_048_575  # data rows per chunk (header counts as a row)

with open('big.csv', newline='') as f:
    reader = csv.reader(f)
    header = next(reader)
    chunk = 0
    count = 0
    out = open(f'chunk_{chunk}.csv', 'w', newline='')
    writer = csv.writer(out)
    writer.writerow(header)
    for row in reader:
        if count == LIMIT:
            out.close()
            chunk += 1
            count = 0
            out = open(f'chunk_{chunk}.csv', 'w', newline='')
            writer = csv.writer(out)
            writer.writerow(header)
        writer.writerow(row)
        count += 1
    out.close()

print(f'split into {chunk + 1} chunks')

# Verified on a 1,200,000-row file (32 MB):
# chunk_0.csv = 1,048,576 lines (header + 1,048,575 rows)
# chunk_1.csv = 151,426 lines (header + 151,425 rows)
# Rejoining the chunks (header stripped from chunk 1 onward)
# reproduced the original file byte-identically.

나누기의 또 다른 장점도 언급할 만합니다. 청크는 독립적인 파일이라서 동료에게 청크 하나를 넘기거나, 느린 컴퓨터에서 청크 하나를 열거나, 청크를 병렬로 처리할 수 있고, 스프레드시트로 열 수 없는 단일 파일로는 이 중 어느 것도 불가능합니다. 파일이 매주 커진다면 스크립트를 보관해 두고 새로 내보낼 때마다 실행하세요. 매번 손으로 나누지 마세요. 그리고 데이터를 보내려고 나눈다면 청크가 작업용 사본이라는 점을 기억하세요. 보관할 파일은 원본이고, 열 파일은 청크입니다.

해결 방법 2: Power Query로 파일 전체를 데이터 모델에 불러오세요

나누기는 보통 워크시트가 필요할 때 통하지만, 전체 데이터 집합을 한 번에 분석해야 할 때가 있고, 그럴 때 엑셀에는 두 번째 문이 있습니다. 바로 데이터 모델입니다. Power Query는 CSV 파일을 그리드 대신 데이터 모델에 불러올 수 있고, 데이터 모델은 압축을 사용해 수천만 행을 메모리에 담으므로 그리드의 1,048,576행 제한을 훨씬 넘습니다. 시트에서 모든 행을 볼 수는 없습니다. 그리드 제한은 표시되는 것에도 여전히 적용되기 때문입니다. 하지만 전체 데이터 집합으로 피벗 테이블과 피벗 차트를 만들 수 있고, 집계는 그리드가 절대 보여줄 수 없는 행까지 모두 셉니다. 행을 하나하나 보는 것이 아니라 요약, 합계, 피벗이 궁금할 때 맞는 해결책입니다.

윈도우용 엑셀에서의 단계는 일부러 평범합니다. 빈 통합 문서를 열고, 데이터, 데이터 가져오기, 파일에서, 텍스트/CSV에서 순으로 이동해 파일을 고른 뒤, 미리 보기에서 로드 대상 선택을 고르고, 연결만 만들기를 선택하고 이 데이터를 데이터 모델에 추가를 체크하세요. 표로 불러오지 마세요. 그런 다음 데이터 모델에서 피벗 테이블을 만들면 피벗이 전체 데이터 집합을 읽습니다. 그리드에 너무 큰 데이터 집합에 대한 마이크로소프트 공식 안내가 정확히 이 방법을 설명하고 있으며, 표로 잘못 불러오면 그리드에 여전히 처음 행만 들어 있으므로 원본 파일 위에 저장하지 말라고 다시 경고합니다.

여기에는 두 가지 주의 사항이 있으며, 솔직히 말하겠습니다. 첫째는 데이터 모델 방식에 Power Query가 있는 윈도우용 엑셀이 필요하고, 맥용 엑셀은 데이터 모델을 만들고 쓰는 지원이 제한적이므로, 맥 사용자는 윈도우를 실행하거나 대신 분할 방법을 써야 할 수 있습니다. 둘째는 데이터 모델 위의 피벗 테이블이 집계 질문에는 답하지만 행 질문에는 답하지 못한다는 점입니다. 파일 전체를 합산하고, 세고, 그룹으로 묶을 수는 있지만, 시트에서 3,000,000번째 행을 스크롤해서 볼 수는 없습니다. 시트는 여전히 1,048,576행에서 멈추기 때문입니다. 제한을 넘은 개별 행을 봐야 한다면 파일을 나누세요. 전부 합산해야 한다면 데이터 모델을 쓰세요.

해결 방법 3: 필요한 행만 골라서 보세요

대부분의 경우 백만 행 전부를 한 번에 화면에 볼 필요는 사실 없습니다. 필요한 것은 한 고객, 한 달, 한 지역, 한 오류 코드에 대한 행이고, 파일의 나머지는 절대 읽지 않을 배경입니다. 열기 전에 파일을 필요한 만큼 줄이는 것이 나누는 것보다 빠르고, 엑셀에서 정상적으로 열리는 작은 파일이 나오며, 관리할 청크도 없습니다. 필터는 한 행씩 읽는 스크립트에서 실행되므로 어떤 크기의 파일에도 통하고, 출력은 자체 머리글을 갖춘 완전한 CSV 파일이라 바로 열 수 있습니다.

아래 방법은 파이썬 표준 라이브러리만 쓰며, 같은 1,200,000행 샘플 파일로 테스트했습니다. total 열이 90보다 큰 행만 남기자 74,227줄짜리 파일이 나왔고, 데이터 행은 74,226개였으며, 약 2초가 걸렸고, 처음 남은 행은 예상대로 total이 처음 90을 넘는 행이었습니다. 조건을 자신의 질문에 맞게 바꾸세요. 날짜 범위, 고객 이름, 상태 값으로 바꾸면 출력은 실제로 필요한 파일의 일부가 됩니다. 같은 패턴은 처음 N개 행에도 통합니다. head 명령이나 N개 행 뒤에 멈추는 카운터로, 파일이 어떻게 끝나는지 확인할 때는 tail 명령으로 마지막 N개 행을 볼 수 있습니다.

필터링은 파일을 열 가치가 있는지 묻는 질문에도 답합니다. 먼저 조건에 맞는 행 수를 세고, 개수가 적으면 필터링한 파일을 여세요. 개수가 여전히 그리드 제한을 넘으면 더 좁게 필터링하거나, 대신 집계하세요. 파일을 월별, 고객별, 상태별로 그룹으로 묶고 요약을 열면 백만 행 대신 수백 행이 됩니다. 요약이 실제 결과물인 경우가 많고, 동료가 실제로 열 수 있는 파일이기도 하며, 결과를 다른 사람에게 보낼 때 기억할 만한 점입니다.

import csv

kept = 0
with open('big.csv', newline='') as src, \
     open('filtered.csv', 'w', newline='') as dst:
    reader = csv.DictReader(src)
    writer = csv.DictWriter(dst, fieldnames=reader.fieldnames)
    writer.writeheader()
    for row in reader:
        if int(row['total']) > 90:
            writer.writerow(row)
            kept += 1
print(f'kept {kept} rows')

# Verified on the 1,200,000-row sample file:
# kept 74226 rows -> filtered.csv has 74,227 lines
# First kept row: 91,Customer 91,91
# The script reads one row at a time, so memory stays flat
# no matter how large the file is.

필터가 파일 자체에 대해 증명하는 것을 눈여겨보세요. 방법의 어느 부분도 파일이 얼마나 큰지 신경 쓰지 않습니다. 스크립트가 한 번에 한 행만 메모리에 들고 있기 때문입니다. 이것이 스트림용으로 만든 도구와 그리드용으로 만든 도구의 차이입니다. 스프레드시트는 보여주는 모든 것을 한 번에 메모리에 올리기 때문에 제한이 있습니다. 스트리밍 스크립트는 행 하나를 처리하고, 쓰거나 버리고, 넘어가기 때문에 실질적인 제한이 없습니다. 파일이 그리드에 너무 클 때는 스트리밍 도구를 먼저 쓰고, 그리드에서는 작은 결과만 여세요.

해결 방법 4: 작업에 맞는 도구를 쓰세요

그리드 제한에 계속 걸린다면, 솔직한 답은 스프레드시트가 그 데이터 집합에 틀린 도구이며, 엑셀 안의 어떤 해결책도 이를 바꾸지 못한다는 것일 수 있습니다. 큰 파일을 살펴보는 데는 텍스트 편집기가 맞는 도구입니다. 파일 전체를 텍스트로 열고, 값을 검색하고, 처음과 마지막 행을 보여주며, 메모리 외에는 행 제한이 없습니다. 큰 파일을 분석하는 데는 데이터베이스가 맞는 도구입니다. CSV를 SQLite에 가져오면 서버가 필요 없는 컴퓨터 안의 단일 파일이 되고, 백만 행은 SQL로 질의하고, 필터링하고, 집계할 수 있는 작은 표가 되며, 그리드가 전혀 방해하지 않습니다.

두 도구 중 어느 것을 고를지는 질문에 달려 있습니다. 파일 안에 무엇이 있는지가 질문이라면 텍스트 편집기를 쓰세요. 어떤 행이 조건에 맞는지가 질문이라면 필터 스크립트를 쓰세요. 파일 전체에 대한 합계나 피벗이 질문이라면 데이터 모델이나 데이터베이스를 쓰세요. 몇 행을 한 번 보는 것이 질문이라면 터미널에서 head와 tail을 쓰세요. 스프레드시트에 들어가야 하는 것은 일부분을 행 단위로 편집하는 질문일 때뿐이며, 그때도 나누거나 필터링해서 맞춘 일부분만 들어가야 합니다. 백만 행 데이터 집합을 백만 행 그리드에 억지로 넣는 것이 불일치지 데이터 집합이 아닙니다.

이런 파일을 만드는 사람들을 위한 계획 관점도 있습니다. 매주 CSV를 내보내는데 계속 백만 행을 넘는다면, 매번 전체 기록을 내보내지 말고 새 행만 내보내거나, 요약만 내보내거나, 원본에서 월별로 나눠서 내보내세요. 스프레드시트에 맞는 내보내기가 사람들이 실제로 쓸 수 있는 내보내기이며, 아무도 열 수 없는 내보내기는 아무리 완전해도 결과물이 아닙니다. 받는 사람에게 파일 이름이나 파일과 함께 보내는 한 줄 메모로 행 수를 알려주세요. 아무도 잘린 저장으로 데이터를 잃으면서 제한을 발견하지 않게 됩니다.

효과가 없는 해결 방법 네 가지

효과가 있는 해결책에 앞서, 효과가 없는 네 가지 해결책을 정리할 만합니다. 각각은 시간을 낭비하고, 그중 하나는 데이터를 파괴하기 때문입니다. 첫째는 파일을 ZIP으로 압축하는 것입니다. 압축은 디스크의 파일을 줄이고, CSV 텍스트는 잘 압축되므로 때로는 크게 줄지만, 압축을 풀거나 가져오는 순간 원시 데이터는 여전히 같은 행 수를 들고 있고, 엑셀은 여전히 1,048,576행에서 멈춥니다. 압축은 저장을 바꾸지 행 수를 바꾸지 않으며, 그리드 제한은 행을 세지 메가바이트를 세지 않습니다.

둘째는 파일을 .xlsx로 저장하거나, 누군가에게 변환해 달라고 부탁하는 것입니다. .xlsx 형식은 엑셀에서 여는 CSV와 같은 1,048,576행 그리드 제한을 가지므로, 제한은 워크시트에 속하지 파일 형식에 속하지 않아서, 파일을 변환해도 시트에 몇 행이 들어가는지는 바뀌지 않습니다. 셋째는 구글 시트에서 파일을 열고 셀 제한이 구해주기를 바라는 것입니다. 구글 시트는 행이 아니라 2,000만 셀을 세므로 파일이 좁으면 엑셀보다 더 많은 행을 담을 수 있지만, 넓은 파일은 셀 상한에 더 빨리 걸리고, 100MB 가져오기 상한도 적용되며, 500만 행 파일은 구글 시트도 넘으므로, 이 해결책은 엑셀 제한을 간신히 넘는 파일에만 통하지 진짜로 큰 파일에는 통하지 않습니다.

넷째는 엑셀 안에서 행을 새 시트나 새 통합 문서로 복사해서 파일을 손으로 나누는 것입니다. 이는 잘린 통합 문서에서 시작하므로 제한을 넘은 행은 이미 빠져 있고, 복사본에는 절대 들어갈 수 없으며, 손으로 복사하는 작업은 느리고 오류가 나기 쉽고, 애초에 엑셀이 불러온 행으로만 제한됩니다. 위 방법대로 원본 파일에서 스크립트로, 엑셀이 파일을 건드리기 전에 나누세요. 그리고 단순히 실패하는 것이 아니라 데이터를 적극적으로 파괴하는 해결책은 잘린 통합 문서에서 원본 위에 저장하는 것으로, 불러오지 못한 행을 영구적으로 지우며, 저장에 대한 동반 가이드에서 자세히 설명합니다.

이 페이지 변환기에서 나온 파일에는 어떤 의미가 있을까요

이 페이지의 변환기는 정확히 이 가이드가 다루는 종류의 파일을 만들므로, 실제 코드로 검증한 동작을 추정하지 않고 솔직히 밝히는 것이 좋습니다. 변환 엔진은 이 컴퓨터에서 10,000행 JSON 샘플로 실행해 28밀리초 만에 끝났고, 10,000행과 3개 열을 만들었으며, 100,000행 샘플에서는 218밀리초 만에 끝나 2.35MB CSV를 만들었습니다. 이 시리즈의 이전 실행에서는 100,000행을 약 0.4초, 500,000행을 엔진 시간 약 1.4초로 측정했으므로, 변환기 자체는 큰 파일을 편안하게 처리하고, 병목은 결과를 여는 프로그램이지 변환이 아닙니다.

이 구분이 중요한 이유는 문제를 어디서 고칠지 정하기 때문입니다. 변환한 파일이 엑셀에서 온전히 열리지 않는다면 변환이 실패한 것이 아니고 파일이 손상된 것도 아닙니다. 파일은 모든 행을 바이트 단위로 그대로 들고 있고, 엑셀은 처음 1,048,576행만 불러왔습니다. 이 가이드 맨 위의 방법으로 행 수를 확인하고, 파일이 제한을 넘으면 위 스크립트로 나누거나, Power Query로 데이터 모델에 불러오거나, 필요한 행만 골라서 줄이세요. 다른 결과가 나올 거라고 기대하며 다시 변환하지 마세요. 변환기는 같은 완전한 파일을 만들고, 엑셀은 같은 방식으로 잘라낼 것이기 때문입니다.

변환기에 대한 세부 사항 하나가 더 중요합니다. 다운로드 파일은 바이트 순서 표시가 없는 순수 UTF-8이며, 대부분의 도구에는 가장 깔끔한 형태이고, 변환기는 다운로드 전에 구분자를 고를 수 있게 합니다. 어느 선택도 행 제한에는 아무런 영향을 주지 않습니다. 세미콜론으로 구분된 파일은 쉼표로 구분된 파일과 정확히 같은 행에서 잘리고, UTF-8 파일은 예전 인코딩 파일과 정확히 같은 행에서 잘립니다. 변환한 파일이 한 열로 열리거나 문자가 깨져 보인다면 이는 별개의 문제로 별개의 해결책이 있으며, 아래에 링크한 동반 가이드에서 다루고, 크기를 처리하는 같은 가져오기에서 함께 고칠 수 있습니다. 여는 방법을 고치고, 필요하면 파일을 나누고, 엑셀에서 다운로드 파일 위에 저장하지 마세요.

Engine check, run on this machine (2026-11-09):
10,000 rows -> 28 ms, 3 columns, 226,762 bytes
100,000 rows -> 218 ms, 3 columns, 2.35 MB

Sample output, first rows:
id,name,total
1,Customer 1,1
2,Customer 2,2

Earlier verified timings in this series:
100,000 rows / 10 MB JSON in about 0.4 s
500,000 rows / 25 MB JSON in about 1.4 s engine time

The converter finishes in milliseconds. The file it writes
is complete. Excel is the bottleneck, not the conversion.

필요한 파일이 변환된 출력 자체이고, 엑셀에 너무 크다면, 가장 깔끔한 방법은 거대한 CSV 하나를 보관하고 매번 나누는 것보다, JSON을 보관하고 필요할 때마다 새로 변환하는 것입니다. JSON이 원본이고 CSV는 스냅샷이며, 원본에서 다시 만드는 것이 스프레드시트를 이미 거친 파일을 고치는 것보다 항상 깔끔합니다. 이는 저장에 대한 동반 가이드가 권하는 마스터 사본 습관과 같으며, 큰 파일에 적용한 것입니다. 원본을 보관하고, 필요한 것을 내보내고, 내보낸 것을 나누거나 필터링하세요. 원본은 절대 나누지 마세요.

예방 체크리스트: 사람들이 실제로 열 수 있는 CSV를 만드세요

행 제한은 쓰는 쪽과 읽는 쪽의 불일치이므로, 예방은 쓰는 쪽이 크기를 밝히고, 읽는 쪽이 믿기 전에 확인하게 만드는 것입니다. CSV를 만들거나 받을 때 이 체크리스트를 거치면, 다음에 파일을 만지는 사람은 이 가이드가 필요 없습니다. 첫째, 파일을 보내기 전에 행 수를 세고, 파일 이름이나 파일과 함께 보내는 한 줄 메모에 개수를 넣으세요. 받는 사람이 열기 전에 파일이 스프레드시트에 맞는지 알 수 있게 됩니다. customers-2026-11-09-1200000-rows.csv라는 파일 이름은 읽는 사람에게 경고하지만, customers.csv라는 이름은 경고하지 않습니다.

둘째, 내보내기가 제한을 넘을 때는 원본에서 나누세요. 데이터가 데이터베이스에서 나온다면 월별이나 지역별로 내보내서 각 파일이 그리드에 맞는 크기로 들어가게 하세요. 전체 기록을 한 파일에 넣어 아무도 열 수 없게 하지 마세요. 셋째, JSON이든, 데이터베이스든, 통합 문서든 원본 데이터를 보관하세요. 잘리거나 덮어쓴 파일을 고치는 대신 깨끗하게 다시 만들 수 있습니다. 넷째, 잘린 통합 문서에서 원본 위에 저장하지 말고, 스프레드시트가 덮어쓰기 전에 받는 모든 파일을 텍스트 편집기로 보거나 행 수를 세어 확인하세요.

다섯째, 받는 사람에게 파일을 여는 방법을 알려주세요. 파일이 120만 행을 들고 있으니 이 가이드의 스크립트로 나누거나 Power Query로 데이터 모델에 불러오라는 한 줄 메모는 이런 종류의 문제를 전부 막아주고, 파일과 함께 보내는 데 비용이 들지 않습니다. 대부분의 CSV 관련 문제는 잘린 파일이 유일한 사본이었다는 것을 너무 늦게 발견하거나, 부분 데이터 집합으로 계산한 요약을 뒤늦게 알아차리면서 끝납니다. 먼저 세고, 열기 전에 나누거나 필터링하고, 원본을 안전하게 보관하면, 큰 CSV는 다시 평범한 파일이 됩니다.

관련 가이드

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

자주 묻는 질문