2025년 6월, 모든 최신 브라우저에서 'Baseline Newly Available' 상태에 도달하며 ES2025(ECMAScript 2025) 표준으로 공식 채택된 'JSON 모듈 가져오기(JSON Modules)'에 대해 이야기해보려고 한다.
프론트엔드 개발을 하다 보면 더미 데이터나 설정 파일 같은 JSON 데이터를 다룰 일이 꽤나 많다. 사실 이 표준이 정립되기 전부터도 우리는 번들러의 도움을 받아 별생각 없이 아래와 같이 써왔다.
import data from './data.json';
이유는? 일단 익숙한 것이 첫 번째다. 그리고 다른 이유를 대자면, fetch를 쓰면 async/await도 써야 하고, useEffect도 걸어야 하고, response.json() 파싱도 해야 하는데, import는 그냥 한 줄이면 데이터가 들어오니까!
그런데 최근 단순히 '동기(import)냐 비동기(fetch)냐'의 스타일 차이 정도로만 여겼던 것이 큰 오산임을 알게 되었다. 이 편리함 뒤에는 메모리 점유와 파싱 시점에 있어 결정적인 차이가 숨어 있었다. 여러 기술 블로그와 문서를 통해 그동안 편의성 때문에 놓치고 있던 중요한 차이점들을 알게 되었다. 2025년 웹 표준으로 자리 잡은 이 시점에서, 그 배움을 정리해 보려고 한다.
☝️ 문법의 변화: assert 이 아닌 with
우선, 최신 자바스크립트 표준(ES Modules)에서는 JSON을 import 할 때 그냥 가져오는 게 아니라 "이건 JSON이야"라고 명시해 줘야 한다.
// 예전 방식
import data from './data.json' assert { type: 'json' };
// 최신 표준 (ES2025 / Baseline Newly Available)
import data from './data.json' with { type: 'json' };
브라우저는 보안상의 이유로 파일 확장자가 아닌 MIME 타입을 보고 파일을 실행한다. 만약 서버가 실수로 악성 코드를 JSON인 척 내려보내면 브라우저가 실행해 버릴 위험이 있다. 그래서 with { type: 'json' }을 붙여서 이 파일은 반드시 JSON이어야 한다는 것을 브라우저에게 강제하는 것이다.
물론 우리가 쓰는 Webpack이나 Vite 같은 번들러들이 이걸 알아서 처리해 주고 있어서 몰랐던 것뿐이다. 하지만 이제 브라우저 네이티브에서도 이 문법이 표준이 되었다.
🫠 Import의 치명적인 단점: 메모리 관리 (가비지 컬렉션)
내가 가장 크게 오해하고 있던 부분이 바로 메모리였다.
- Fetching: 데이터를
fetch()로 가져오면, 그 데이터는 우리가 변수에 담아 쓰고 나서 더 이상 참조하지 않으면, 자바스크립트 가비지 컬렉터가 알아서 메모리를 청소해 준다. - Importing: 반면, 모듈로
import된 JSON 객체는 "모듈 그래프(Module Graph)"에 영원히 박제된다. 페이지가 살아있는 동안 메모리에서 절대 사라지지 않는다.
만약 엄청나게 큰 대용량 JSON 파일을 import로 가져왔다고 가정해 보자.
import largeData from './huge-dataset.json' with { type: 'json' };이 데이터 중 딱 하나만 쓰고 싶어서 largeData.user만 변수에 담아도 나머지 데이터 전체가 메모리에 계속 남아있게 된다. 이는 메모리 누수의 원인이 될 수 있다.
👾 에러 핸들링
에러 처리 방식에서도 큰 차이가 있다.
- Import: 만약
import하려는 JSON 파일이 서버에 없거나 문법 에러가 있다면 전체 스크립트 실행이 멈춰버린다. 모듈 로딩 단계에서 에러가 나기 때문에try/catch로 잡기도 애매하고, 앱 전체가 하얀 화면이 뜰 수도 있다. - Fetch:
fetch는 실패하면 에러를 던지고, 우리는catch블록에서 "데이터 로딩 실패" 같은 안내 메시지를 띄우거나 재시도를 할 수 있어서 훨씬 유연하다.
🤔 언제 무엇을 써야 할까?
공부한 내용을 바탕으로 나름의 기준을 세워봤다.
- Importing을 쓰면 좋은 경우
- 작고 고정된 데이터:
config.json, 다국어 번역 파일, 상수로 쓰이는 작은 데이터들. - 빌드 시점에 확정되는 데이터: 런타임 HTTP 요청 없이 즉시 사용 가능한 정적 데이터
- Fetching을 쓰면 좋은 경우
- 동적/변화하는 데이터: API 응답, 실시간 업데이트 데이터.
- 대용량/조건부 데이터: 사용자 요청 시점에 로드하거나, 사용 후 메모리 해제 필요한 데이터.
- 외부/불확실한 데이터: 서드파티 API처럼 실패 가능성이 있어 유연한 에러 처리와 재시도 로직이 필요한 경우.
🙏 배운 점
"작동하니까 괜찮아"라고 생각하며 무심코 썼던 import 구문이 상황에 따라서는 앱의 성능을 갉아먹는 주범이 될 수 있다는 걸 깨달았다.
특히 메모리 관리 측면에서의 차이가 특히 인상 깊었다. 편리함을 좇다 보면 놓치기 쉬운 런타임 비용을 미리 계산하고 적절한 도구를 선택하는 습관이 중요하다는 교훈을 얻었다는 말을 끝으로 글을 마무리한다.
