Json To Csv LogoJson To Csv

Convert Large JSON to CSV Online Free: 대용량 파일, 어디까지 변환할 수 있을까요? (2026 가이드)

대용량 JSON 파일은 어느 지점까지는 브라우저에서 잘 변환돼요. 그리고 그 지점은 속도가 아니라 메모리예요. 이 가이드는 이 페이지의 변환 엔진으로 실제 한계를 측정하고, 행을 하나도 잃지 않는 청크 분할 레시피를 보여주고, 어떤 파일은 스크립트로 처리해야 하는지 솔직하게 알려드려요.

업데이트: 2026-10-209 분 소요

"대용량"이 브라우저 변환기에게 의미하는 것

사람들이 JSON 파일이 크다고 말할 때, 그 범위는 5천 행부터 5기가바이트까지 제각각이에요. 그리고 이건 완전히 다른 문제예요. 브라우저 변환기에는 한계가 하나만 있는 게 아니라 셋이 있어요. 어떤 한계에 먼저 부딪힐지를 알면, 그냥 변환하면 되는지, 나눠서 변환해야 하는지, 아니면 브라우저를 아예 떠나야 하는지 판단할 수 있어요.

첫 번째 한계는 파싱이에요. 변환이 시작되기도 전에 브라우저는 JSON.parse로 JSON 텍스트를 메모리의 객체로 바꿔요. 파싱된 객체는 원본 텍스트보다 대략 2~3배의 메모리를 차지해요. 25MB짜리 파일은 CSV 셀 하나도 만들기 전에 메모리에 50~75MB짜리 객체가 돼요. 두 번째 한계는 입력 방식이에요. 수십 메가바이트짜리 텍스트를 텍스트 입력 상자에 붙여넣는 건 어떤 컴퓨터에서도 느리고 불편해요. 그래서 업로드 버튼이 있는 거예요. 클립보드를 거치지 않고 파일을 바로 변환기로 넘겨주니까요. 세 번째 한계는 미리보기예요. 변환이 끝나면 페이지가 결과를 눈으로 확인할 수 있게 표를 렌더링하는데, 50만 행짜리 DOM을 그리는 게 실제로 탭을 멈춰 세우는 주범이에요. 이 목록에서 빠진 걸 눈치채셨나요? 변환 속도예요. 아래 실측에서 보시겠지만, 객체를 CSV 텍스트로 바꾸는 건 전체 과정 중에서 가장 저렴한 단계예요.

그래서 "대용량 JSON 파일을 온라인에서 무료로 변환할 수 있나요"라는 질문은 사실 더 작은 질문 세 개로 나뉘어요. 브라우저가 메모리 부족 없이 파싱할 수 있을까. 입력 경로가 파일을 무리 없이 받아줄까. 미리보기가 버텨낼까. 사람들이 대용량이라고 부르는 대부분의 파일은 세 질문에 대한 답이 모두 "예"이고, 이 가이드의 나머지는 추측이 아니라 솔직하게 그 경계를 찾는 방법에 관한 거예요.

실측: 이 페이지가 대용량 파일을 변환하는 속도

이 섹션의 숫자는 전부 빌드 머신에서 이 페이지가 내 브라우저에서 돌리는 변환 엔진과 정확히 같은 엔진, 즉 평탄화를 켠 상태의 jsonToCsv 함수로 측정했어요. 테스트 데이터는 중첩된 customer 객체를 포함한 주문 데이터예요. 머신은 평범한 서버일 뿐 정교하게 튜닝된 벤치마크 장비가 아니니까, 괜찮은 노트북에서 나올 정도라고 이해하시면 돼요.

1천 행, JSON 0.10MB는 20밀리초. 1만 행, 1.01MB는 57밀리초. 5만 행, 5.10MB는 221밀리초. 10만 행, 10.21MB는 403밀리초. 25만 행, 12.5MB는 636밀리초. 50만 행, 25.0MB는 엔진 시간으로 대략 1.4초, 벽시계 시간으로 2.3초. 50만 행 파일의 출력 CSV는 11.7MB였고, 헤더 행은 예상대로 정확히 나왔어요. id, item, qty, price, customer.name, customer.city.

두 가지 솔직한 주의사항이 있어요. 첫째, 이 측정값은 변환만의 시간이에요. 브라우저는 그 전에 JSON을 파싱하고, 변환 후에는 미리보기 표를 렌더링해요. 큰 파일일수록 미리보기가 비싼 단계예요. 2초 만에 변환되는 파일도 50만 행짜리 표가 그려지는 동안에는 탭이 무겁게 느껴질 수 있어요. 둘째, 테스트 데이터는 균일하게 생성된 거예요. 키가 들쭉날쭉하거나, 중첩이 깊거나, 거대한 텍스트 덩어리가 섞인 실제 데이터는 엔진이 모든 값을 하나하나 훑어야 해서 조금 더 느려요. 그래도 결과의 큰 그림은 흔들리지 않아요. 변환 단계는 10만 행을 훌쩍 넘어도 1초를 넘기지 않고, 50만 행에서도 낮은 한 자릿수 초 안에 머물러요. 다른 변환기가 대용량 파일을 느리게 변환한다면 그건 변환기 자체가 비효율적인 거예요. 실제 작업량이 적은 게 아니라요.

측정한 변환 시간 (페이지 엔진, 빌드 머신)
rows        JSON size    convert time
1,000       0.10 MB      20 ms
10,000      1.01 MB      57 ms
50,000      5.10 MB      221 ms
100,000     10.21 MB     403 ms
250,000     12.5 MB      636 ms
500,000     25.0 MB      ~1.4 s engine / 2.3 s wall

# header produced for every file:
# id,item,qty,price,customer.name,customer.city

60초 테스트: 복잡한 방법부터 쓰지 말고 먼저 해보세요

대용량 파일에 대한 불안감은 대부분 그냥 해보는 걸로 해결돼요. 몇 메가바이트가 넘는 파일은 붙여넣기 대신 업로드 버튼을 쓰세요. 변환기 위에 있는 상태 배지를 보면 돼요. JSON이 깨끗하게 파싱되면 Ready에서 Valid로 바뀌고 행 수도 표시돼요. 탭이 잘 반응하고 다운로드 버튼으로 CSV를 받아왔다면 그걸로 끝이에요. 청크 나누기 같은 전략은 애초에 필요 없었던 거예요.

테스트를 제대로 하려면 두 가지를 신경 쓰세요. 첫째, 자동 변환(Auto Convert)을 켜 두세요. 기본값이 켜져 있긴 해요. 파일이 로드되자마자 클릭 한 번 없이 CSV가 보이거든요. 둘째, 행 수를 믿으세요. 배지에 Valid와 함께 480,000행이라고 뜨고, 예상한 행 수도 그 정도라면 파서가 내 파일을 정확히 이해한 거예요. 반대로 행 수가 말도 안 되게 다르면, 보통은 1로 나오는데, 그건 JSON이 배열을 감싸고 있는 거대한 객체 하나일 가능성이 커요. 변환기는 추출할 수 있는 걸 추출한 거고, 이건 크기 문제가 아니라 파일 형태 문제예요. 래퍼(wrapper) 패턴에 대한 설명은 평탄화 가이드에 있어요.

탭이 멈추거나, 오래 버벅거리거나, 브라우저가 페이지를 종료하겠냐고 물어보면, 그때는 멈추고 청크로 나누세요. 새로고침하고 같은 파일을 다시 붙여넣으면서 다른 결과를 기대하지 마세요. 메모리 한계는 타협하지 않아요. 다음 섹션이 바로 그 돌파구예요.

브라우저에서 청크 나누기: 행을 하나도 잃지 않는 방법

청크 나누기는 타협처럼 들리지만, 실제로는 정확한 방법이에요. JSON 배열을 조각으로 나누고, 각 조각을 탭에서 변환하고, 조각마다 CSV 하나씩 다운로드한 뒤, 헤더 행을 하나로 유지하면서 다시 합치면 돼요. 빌드 머신에서 직접 검증했어요. 2만 행짜리 파일을 둘로 나누고, 각 절반을 따로 변환하고, 두 번째 CSV의 헤더를 제거하고, 두 본문을 이어 붙였어요. 합친 결과는 파일 전체를 한 번에 변환한 결과와 바이트 단위로 동일했어요.

왜 이게 통하는지 한 문장으로 설명할게요. 모든 청크의 형태가 같으면 변환기가 각 청크마다 같은 순서로 같은 열 목록을 도출하니까, 본문들이 완벽하게 맞물려요. 신경 써야 할 건 헤더뿐이에요. 첫 번째 CSV의 헤더를 남기고, 그 이후 CSV의 헤더 줄을 버리고 이어 붙이면 돼요. 유일하게 조심해야 할 경우는 들쭉날쭉한(ragged) 데이터예요. 행마다 키가 다르면 청크 1이 본 적 없는 "notes" 열이 청크 2에 있을 수 있고, 그럼 열이 맞물리지 않아요. 들쭉날쭉한 파일은 뒤쪽 섹션의 스크립트 방법을 쓰세요. 스크립트는 전체 열 목록을 먼저 계산하거든요.

청크를 몇 개로 나눌까요. 탭에서 편하게 변환할 수 있는 크기로 나누세요. 위 실측을 보면 청크당 5만~10만 행 정도가 좋아요. 40만 행 파일은 4~8개 청크가 되고, 각 청크는 0.5초 안에 변환돼요. 클릭 시간까지 합쳐도 전체 작업은 몇 분이면 끝나고, 모든 행이 살아남아요.

JSON을 깨뜨리지 않고 파일 나누기

피해야 할 실수가 있어요. 파일을 텍스트로 자르면 안 돼요. 25MB 파일을 텍스트 에디터에서 반으로 자르면 거의 항상 깨져요. 열린 채로 남은 대괄호, 따옴표 중간에서 잘린 문자열, 경계에 홀로 남은 쉼표가 생기거든요. 데이터를 데이터답게, JSON을 이해하는 도구로 나눠야 각 조각이 그 자체로 유효한 JSON이 돼요.

가장 짧고 확실한 나누기는 파이썬 몇 줄이에요. 파일을 한 번 읽어들이고, 리스트를 잘라서, 각 조각을 별도 파일로 저장해요. 빌드 머신에서 3만 행짜리 파일로 검증했어요. 1만 행짜리 조각 세 개로 나왔고, 조각들을 다시 합치니 원본 파일과 정확히 일치했어요. 터미널에 머물고 싶으면 jq도 같은 방식으로 배열을 잘라요. jq '.[0:50000]' big.json > part1.json은 처음 5만 개 요소를 가져오고, jq '.[50000:100000]'은 그 다음 5만 개를 가져와요. 표준 jq 슬라이스 문법이고, jq 매뉴얼에 문서화돼 있어요.

조각들 이름을 순서대로 part1, part2, part3으로 정하고, 순서대로 변환하세요. CSV도 같은 순서로 나오고, 다시 합치는 건 이전 섹션의 헤더 규칙을 따라 이어 붙이는 것뿐이에요.

JSON 배열을 유효한 조각으로 나누기 (검증됨)
import json

rows = json.load(open('big.json'))
chunk = 50000
for i in range(0, len(rows), chunk):
    part = rows[i:i+chunk]
    json.dump(part, open('part%d.json' % (i // chunk + 1), 'w'))
    print('part%d.json:' % (i // chunk + 1), len(part), 'rows')

# terminal alternative (standard jq slice syntax):
# jq '.[0:50000]' big.json > part1.json
# jq '.[50000:100000]' big.json > part2.json

어떤 파일이든 브라우저 탭의 한계를 넘을 때

솔직한 한계가 있고, 분명히 말할 가치가 있어요. 브라우저가 파일 자체를 메모리에 파싱하지 못한다면, 어떤 온라인 변환기도 도와줄 수 없어요. 모든 온라인 변환기가 결국은 먼저 파싱하니까요. 증상은 명확해요. 로드 중에 탭이 페이지를 종료하겠냐고 물어보거나, 브라우저가 메모리 부족 오류를 내거나, 파일 업로드가 끝나지 않는 거예요. 이 단계에 이르면 파일이 탭의 크기를 넘어선 거고, 작업은 내 컴퓨터에서 도는 스크립트의 몫이에요. 스크립트는 데이터 전체를 한 번에 객체로 들고 있지 않아도 되거든요.

실전에서는 그 한계가 어디쯤일까요. 내 컴퓨터의 RAM과 데이터의 중첩 깊이에 따라 다르지만, 평범한 노트북에서는 JSON 텍스트로 수백 메가바이트쯤 되는 파일부터 탭이 죽기 시작해요. 25MB 파일은 여기서 2초 정도에 여유롭게 변환됐지만, 250MB 파일은 완전히 다른 동물이에요. 메모리 압박이 대략 열 배고, 1GB 파일은 확실히 스크립트의 영역이에요. 내가 어느 쪽에 있는지 모르겠다면, 앞 섹션의 60초 테스트가 경험적으로 답을 줘요. 죽은 탭은 그 파일이 스크립트를 원한다는 신호예요.

한 가지 더 솔직하게 말할게요. "파일 크기 무제한"을 내세우는 사이트가 있어요. 보통 그건 자기네 서버가 업로드를 받아준다는 뜻일 뿐이에요. 한계를 내 브라우저에서 자기네 대기열로 옮긴 거고, 그 과정에서 내 데이터를 제3자에게 넘기는 거예요. 파일이 클수록, 이 교환이 성립할 일은 거의 없어요.

스크립트 방법: 들쭉날쭉한 데이터도 버티는 청크 파이썬

브라우저가 손을 들었다면, 답은 이 스크립트예요. 파일 전체를 한 번 읽고, 각 청크를 pandas로 평탄화해서 청크당 CSV 하나씩 써요. 그리고 브라우저 방법이 못 하는 걸 처리해요. 키가 제각각인 들쭉날쭉한 행들이요. 비결은 전체 열 목록을 모든 데이터에서 먼저 계산한 뒤, 쓰기 전에 각 청크를 그 열에 맞추는 거예요. 빌드 머신에서 검증했어요. 어떤 행은 notes 필드를, 어떤 행은 flag 필드를 가진 3만 행짜리 파일로, 청크 CSV 세 개를 합치니 파일을 한 번에 변환한 결과와 바이트 단위로 동일했고, 시간은 0.4초였어요.

이 패턴은 브라우저가 절대 못 따라가는 규모로 확장돼요. 각 청크를 변환하고 쓴 다음에야 다음 청크가 로드되니까, 피크 메모리는 파일 크기가 아니라 청크 크기에 비례하거든요. 사양 좋은 컴퓨터에서는 청크 크기를 키워서 빠르게, 메모리가 빠듯하면 낮추세요. 그리고 이 합집합 열 방식은 데이터 중간에 열 구성이 바뀌는 경우에도 보호해줘요. 실제 데이터는 그걸 참 좋아하거든요.

마지막으로 하나 판단할 게 남아요. 청크마다 CSV 하나씩 쓸지, 합친 파일 하나로 만들지요. 아래 스크립트는 청크당 하나씩 써요. 각 조각을 독립적으로 쓸 수 있게요. 단일 파일이 원한다면, 브라우저 방법과 같은 헤더 규칙으로 합치세요. 첫 파일의 헤더를 남기고 나머지를 버리면 돼요.

들쭉날쭉한 데이터에도 안전한 청크 변환 (검증됨, pandas)
import json, pandas as pd

rows = json.load(open('big.json'))
cols = list(pd.json_normalize(rows).columns)  # union of all keys

chunk = 50000
for i in range(0, len(rows), chunk):
    part = pd.json_normalize(rows[i:i+chunk]).reindex(columns=cols)
    part.to_csv('out_part%d.csv' % (i // chunk + 1), index=False)

# merge the parts into one CSV (keep one header):
# head -n 1 out_part1.csv > merged.csv
# tail -n +2 -q out_part*.csv >> merged.csv

대용량 파일과 개인정보: 규모가 클수록 클라이언트 측이 중요한 이유

대용량 파일은 보통 민감한 파일이에요. 50만 행짜리 내보내기 데이터가 장난감 데이터셋일 일은 거의 없어요. 고객, 주문, 로그, 환자 기록이죠. 바로 이럴 때 변환기의 구조가 가장 중요해져요. 이건 누군가의 서버 대신 브라우저 탭에서 변환할 때 따라오는 조용한 장점이에요.

이 페이지의 변환기는 페이지가 로드된 뒤에는 전적으로 브라우저 안에서 돌아요. 다운로드 가이드 작성을 위해 페이지 소스로 직접 검증했어요. 변환 엔진은 로컬 클라이언트 코드로 가져오고, 변환기 전체에서 유일한 네트워크 요청은 선택 기능인 URL 가져오기(fetch-from-URL) 버튼이에요. 그것도 내가 클릭할 때만, 내가 입력한 주소만 가져와요. 붙여넣거나 업로드한 데이터는 어디로도 전송되지 않아요. 제3자가 파일을 볼 일도, 업로드 대기열에서 기다릴 일도, 데이터 보관 정책을 읽을 일도 없어요.

그래서 위의 청크 나누기 방법도 개인정보에 안전해요. 모든 청크가 내 컴퓨터에서 변환되고, 조각들이 컴퓨터를 떠나지 않거든요. 파일이 커서 스크립트 방법이 필요하다 해도 같은 성질이 유지돼요. 파이썬 스크립트는 로컬에서 돌고, 네트워크를 건드릴 일이 전혀 없으니까요.

대용량 파일에 하면 안 되는 것들

자주 나오는 실수 네 가지예요. 첫째, 업로드 버튼 대신 입력 상자에 수십 메가바이트를 붙여넣는 것. 업로드 경로는 바로 이럴 때 쓰라고 있는 거고, 붙여넣기는 큰 파일을 페이지에 넣는 가장 느린 방법이에요. 둘째, JSON을 압축(minify)해서 크기가 의미 있게 줄기를 기대하는 것. 압축은 일반적인 데이터에서 대략 10퍼센트 정도만 줄여줘요. 너무 큰 파일이 여전히 너무 큰 파일이 되는 거예요. 셋째, 50만 행짜리 CSV를 스프레드시트로 열어서 "확인"하는 것. 스프레드시트는 100만 행쯤에서 한계에 부딪히고, 그보다 훨씬 전부터 느리게 렌더링돼요. 행 수를 확인하고 파일의 앞부분과 뒷부분을 찍어서 확인하세요. 넷째, 매주 도착하는 거대한 데이터를 매번 손으로 변환하는 것. 파일이 정기적으로 온다면, 앞 섹션의 파이썬 스크립트는 한 번만 설정하면 수십 번의 수작업을 이기는 방법이에요.

그리고 걱정 안 해도 되는 것 하나. 평탄화예요. 중첩된 데이터가 크기 계산을 의미 있게 바꾸진 않아요. 평탄화 토글은 중첩 객체를 점 표기법 열로 바꾸는데, 엔진이 다른 작업과 같은 패스에서 처리해요. 위 실측은 전부 평탄화를 켠 상태로 측정한 거예요.

관련 가이드

자주 묻는 질문

대용량 JSON을 CSV로 변환해주는 무료 온라인 도구가 있나요?

네, 이 페이지의 변환기가 무료예요. 가입도 없고, 이쪽에서 걸어둔 파일 크기 제한도 없어요. 파일을 업로드하고, 상태 배지에 행 수가 확인되는 걸 보고, CSV를 다운로드하면 돼요. 변환이 전적으로 브라우저 안에서 실행되니까 데이터가 내 컴퓨터를 떠나지 않아요. 수십만 행이 넘는 파일은 이 가이드의 방법대로 먼저 청크로 나누세요.

온라인에서 변환할 수 있는 JSON 파일 크기의 최대치는 얼마인가요?

이 페이지에 고정된 상한선은 없어요. 실질적인 천장은 브라우저 탭의 메모리예요. 이 페이지의 엔진으로 측정한 결과, 25MB / 50만 행이 2초 정도에 여유롭게 변환됐어요. 그 이상부터는 변환이 아니라 파싱용 메모리와 미리보기 표가 한계가 돼요. 탭이 멈추거나 죽으면, 파일을 청크로 나누거나 이 가이드의 스크립트 방법으로 바꾸세요.

대용량 JSON 파일을 작은 파일들로 나누는 방법이 있나요?

텍스트가 아니라 데이터로 나눠야 각 조각이 유효한 JSON으로 남는 거예요. 파이썬으로는 json.load로 파일을 읽고, 리스트를 조각으로 자르고, 각 조각을 json.dump로 저장해요. 터미널에서는 jq '.[0:50000]' big.json > part1.json이 처음 5만 개 요소를 가져와요. 텍스트 에디터로 자르는 건 절대 안 돼요. 경계에서 대괄호와 따옴표가 깨지거든요.

청크로 나누면 CSV 결과가 달라지나요?

모든 청크의 형태가 같다면 달라지지 않아요. 빌드 머신에서 검증했어요. 파일을 둘로 나누고, 두 조각으로 변환하고, 헤더를 하나로 유지하면서 합친 결과가 파일을 한 번에 변환한 결과와 바이트 단위로 동일했어요. 예외는 행마다 키가 다른 들쭉날쭉한 데이터예요. 그건 이 가이드의 스크립트를 쓰세요. 스크립트는 쓰기 전에 전체 열 목록을 먼저 계산하거든요.

민감한 데이터가 들어간 대용량 JSON 파일을 온라인에서 변환해도 안전한가요?

이 페이지에서는 네, 안전해요. 변환이 전적으로 브라우저 안에서 실행돼요. 엔진은 로컬 클라이언트 코드이고, 내 파일은 어떤 서버에도 업로드되지 않아요. 변환기에서 유일한 네트워크 요청은 선택 기능인 URL 가져오기 버튼이에요. 그래서 브라우저 방법과 청크 나누기 방법이 제3자에게 맡기기 꺼려지는 개인정보가 섞인 데이터에도 안전한 거예요.

대용량 JSON 파일을 변환하면 브라우저가 왜 멈추나요?

보통은 변환이 아니라 미리보기 표 때문이에요. 수십만 행짜리 표를 렌더링하는 게 CSV 텍스트를 만드는 것보다 훨씬 비싸요. 업로드 대신 입력 상자에 거대한 파일을 붙여넣으면 더 심해져요. 파일을 업로드하고, 그래도 탭이 버거워하면 청크로 나눠서 변환하세요. 각 조각이 작으면 미리보기가 바로 그려져요.

1GB짜리 JSON 파일을 브라우저에서 CSV로 변환할 수 있나요?

솔직히 말하면, 안 돼요. 그 크기면 브라우저 탭이 메모리로 파싱할 수 있는 수준을 넘고, 어떤 온라인 변환기도 그걸 바꾸지 못해요. 내 컴퓨터에서 스크립트를 쓰세요. 이 가이드에 나온 대로 파이썬으로 청크 단위 json_normalize를 쓰거나, JSON-lines 데이터에는 스트리밍 도구를 쓰세요. 파일이 하나의 거대한 배열이라면, 먼저 JSON-lines로 바꾸세요. 줄마다 객체 하나씩인 형태라 스트리밍으로 깔끔하게 처리돼요.

큰 파일로 지금 바로 테스트해 보세요

큰 JSON의 일부를 붙여 넣고 변환기가 몇 밀리초 만에 처리하는 모습을 보세요. 무료이며, 회원 가입 없이, 브라우저 안에서 전부 실행됩니다.

JSON to CSV 변환기 열기
모든 가이드