블로그

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

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

API 응답을 파싱하려고 온라인 JSON 에디터를 열면, 보통은 바로 로딩될 거라 기대합니다. 그런데 데이터 안에 최신 AI 또는 멀티미디어 API가 반환하는 20MB짜리 Base64 이미지 문자열이 포함돼 있으면, 거의 모든 도구가 극심하게 느려집니다. 응답 시간이 치솟고, 스크롤은 끊기고, 에디터 자체가 사실상 먹통이 됩니다.

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

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

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

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

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

파일 크기 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 병목

브라우저의 JavaScript 실행은 싱글 스레드입니다. 기존 포맷터가 20MB 파일을 받으면, 매우 무거운 구문 토크나이징과 레이아웃 계산을 메인 스레드 위에서 실행합니다. 이 작업을 여러 CPU 코어로 분산할 수 없기 때문에, i7-14700F 같은 고성능 CPU도 제대로 활용하지 못합니다. 코어 하나만 100%로 치솟고, 페이지 전체가 클릭이나 스크롤에 반응하지 않게 됩니다.

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

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

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

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

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

이 "렌더링 회피"와 "데이터 무결성"의 조합 덕분에 ViewJSON은 20MB 페이로드를 2초 이내에 포맷할 수 있습니다.

관련 글

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

느린 JSON 에디터, 이제 그만

대용량 JSON 응답을 ViewJSON에 바로 붙여넣어 보세요. 즉각적인 포맷팅, 인라인 미디어 미리보기, 제로 렉을 경험할 수 있습니다.

ViewJSON 열기 →