블로그

온라인 JSON 에디터가 20MB Base64 처리 중 멈추는 이유와 벤치마크 결과

2026년 4월 23일 게시 · 약 6분 소요

20MB Base64 문자열이 포함된 API 응답은 파싱, 하이라이트, 레이아웃에 많은 시간이 들 수 있습니다. 영향은 에디터, 브라우저, 기기, 테스트 데이터에 따라 달라지므로 여기서는 세 도구를 같은 절차로 비교합니다.

왜 이런 일이 벌어질까요? 하드웨어 성능이 부족한 걸까요, 아니면 브라우저가 텍스트를 처리하는 방식 자체에 근본적인 한계가 있는 걸까요? 하이엔드 데스크톱 환경에서 투명한 벤치마크를 돌려, 주요 포맷팅 도구가 왜 한계에 부딪히는지, 그리고 어떻게 해결할 수 있는지 직접 확인해 보았습니다.

20MB 벤치마크: 주요 온라인 JSON 에디터 성능 비교

하드웨어 탓을 원천 차단하기 위해, 플래그십 개발 머신에서 테스트를 진행했습니다:

  • CPU: Intel Core i7-14700F
  • 메모리: 32GB RAM

Playwright 스크립트를 사용해 1MB에서 20MB까지의 페이로드를 각 도구에 붙여넣는 동작을 시뮬레이션했습니다. GitHub Gist의 스크립트로 직접 재현하거나 수정할 수 있습니다. 아래는 실측 결과이며, Load 시간을 중심으로 정리했습니다(괄호 안은 Format/Minify 시간):

원본 CSV 다운로드. 러너는 작업 시간과 실패를 기록했지만 OS, Chromium, Playwright, 네트워크, 테스트한 사이트 빌드 버전은 기록하지 않았습니다. 영구적인 순위가 아니라 날짜가 있는 측정 결과로 보세요.

파일 크기 CodeBeautify JSONFormatter ViewJSON
1MB 1.1s(F: 1.1s, M: 1.0s) 1.2s(F: 0.9s, M: 1.0s) 0.7s(F: 0.6s, M: 0.6s)
5MB 2.5s(F: 4.1s, M: 3.1s) 4.3s(F: 3.0s, M: 3.8s) 0.9s(F: 0.7s, M: 0.7s)
10MB 4.3s(F: 7.8s, M: 6.4s) 5.9s(F: 5.2s, M: 6.9s) 1.1s(F: 0.8s, M: 0.7s)
20MB 8.7s(F: 16.0s, M: 13.1s) 12.6s(F: 15.4s, M: 11.6s) 1.6s(F: 1.0s, M: 0.8s)

* F = Format 시간, M = Minify 시간. 각 수치는 3회 측정의 중앙값. 메인 컬러 수치는 Load 시간을 나타냅니다. 시간은 소수점 첫째 자리로 반올림.

20MB 로드 시간 막대 차트: CodeBeautify 8.7s, JSONFormatter 12.6s, ViewJSON 1.6s.
20MB 벤치마크 시각화 (낮을수록 빠름).

온라인 JSON 에디터는 왜 거대한 Base64 문자열에서 느려질까?

이 압도적인 성능 차이는, 기존 웹 애플리케이션이 코드 하이라이팅을 처리하는 방식에 심각한 한계가 있음을 보여줍니다. 온라인 JSON 에디터가 대용량 Base64 데이터에서 느려지는 원인은 크게 두 가지 병목으로 귀결됩니다:

1. 싱글 스레드 CPU 병목

많은 에디터 작업은 여전히 메인 스레드에서 실행되므로 큰 문서의 파싱이나 토큰화가 입력을 지연시킬 수 있습니다. Worker로 일부 작업을 옮길 수 있지만 구현은 에디터마다 다르며 CPU 사용량은 측정해야 합니다.

2. 초장문 단일 라인 렌더링 병목

JSON 파일을 처리할 때, 구문 하이라이터는 Base64 문자열 전체를 단 하나의 <span class="string"> 노드에 감쌉니다. 진짜 문제는 이 노드에 약 2,700만 글자가 들어있고, 줄바꿈 없이 한 줄로 이어져 있다는 점입니다. 에디터의 코어 엔진은 이 "초장문 한줄"에 대해 글자 폭 측정, 줄 바꿈 위치 계산, 커서 위치 산정을 수행해야 합니다. 이 정도 규모의 연속 문자열에 대한 레이아웃 계산은 치명적인 메모리 오버헤드를 유발하여 브라우저의 메인 스레드를 완전히 잠가 버립니다.

ViewJSON의 해법: 미디어 치환과 무손실 클립보드

기존 에디터가 먹통이 되는 근본 원인은, 수천만 글자를 사람이 읽으라고 그대로 렌더링하려 들기 때문입니다. 하지만 우리는 본질적인 사실을 깨달았습니다—20MB Base64 난수 문자열을 붙여넣는 개발자는 그 코드를 읽으려는 게 아니라, 그 뒤에 숨겨진 실제 미디어를 확인하고 싶은 것입니다.브라우저의 한계에 정면 돌파를 시도하는 대신, ViewJSON은 UX 관점에서 아키텍처를 재설계했습니다:

  • 미디어 치환 (단순 자르기가 아님): ViewJSON은 Base64 문자열을 감지하면 매직 바이트를 디코딩하고, 읽을 수 없는 코드 블록을 실제 인라인 미디어 미리보기(이미지 등)로 통째로 교체합니다. 미리보기를 끄면 긴 문자열을 스마트하게 축약 표시합니다. 어느 경우든, 수백만 글자가 에디터의 텍스트 버퍼에 유입되는 것을 차단하여 코어 엔진과 렌더링 스레드의 부담을 근본적으로 해소합니다.
  • 무손실 클립보드 복구: 원본 텍스트를 숨기면 보통 치명적인 문제가 생깁니다—JSON을 복사하면 데이터가 잘려 나가는 것이죠. ViewJSON은 커스텀 클립보드 매니저로 이 문제를 해결합니다. 화면에 이미지 미리보기가 보이든 축약 텍스트가 보이든, "복사"를 클릭하면 에디터가 백그라운드에서 원본 Base64 페이로드를 복원해 복사된 데이터의 100% 완전성을 보장합니다.

이 테스트 환경에서 ViewJSON은 20MB 사례를 약 1.6초에 불러왔습니다. 페이로드, 브라우저, 기기가 달라지면 결과도 달라질 수 있습니다.

관련 글

JSON API 응답에서 Base64 이미지 디버깅하기 →

느린 JSON 에디터, 이제 그만

자신의 브라우저와 페이로드로 큰 JSON을 테스트하세요. 대용량 문서는 여전히 메모리를 사용하므로 하나의 측정값에만 의존하지 마세요.

ViewJSON 열기 →