JSON 파싱 및 처리 라이브러리 비교

핵심부터 말하면, 필요를 먼저 분류한 뒤 구현을 비교하세요. 읽기 전용 값에는 네이티브 JSON.parse, 오프셋이 필요하거나 원본 형식을 보존해야 하면 jsonc-parser, 쿼리나 패치 라이브러리는 꼭 필요한 곳에만 더하세요. 큰 라이브러리는 페이지별로 지연 로딩하고 유지 관리되지 않는 것은 버리세요.

모든 라이브러리가 "빠르고 작고 완전하다"고 주장합니다. 진짜 차이는 뭔가 잘못됐을 때 얼마나 많은 정보를 주는가입니다.

1. 목적별 네 가지 범주

먼저 어느 범주인지 식별한 뒤 구체 구현을 비교하세요. 아니면 쿼리 라이브러리로 파서의 일을 하는 실수를 하기 쉽습니다.

2. 나란히 비교

JSON.parse 오류 메시지는 엔진마다 크게 다릅니다. V8은 Unexpected token } in JSON at position 42 같은 것을 내지만 위치가 정확한지는 엔진 버전에 달려 있습니다. jsonc-parser는 대신 안정적인 구조화 { error, offset, length }를 반환해 에디터 마커에 적합합니다.

3. 네 가지 핵심 결정 포인트

3.1 오프셋이 필요한가

에디터를 만들고 "오류를 클릭하면 해당 줄로 점프"를 원한다면 오프셋이 반드시 필요합니다. 검사는 간단합니다. 오류 메시지가 "invalid JSON"만 찍을 수 있다면 사용자가 스스로 찾아야 합니다.

复制import { parse, printParseErrorCode } from 'jsonc-parser';

const errors: Array<{ error: number; offset: number; length: number }> = [];
parse(text, errors, { allowTrailingComma: true, disallowComments: false });

if (errors.length > 0) {
  const firstError = errors[0];
  console.error(`${printParseErrorCode(firstError.error)} at offset ${firstError.offset}`);
}

3.2 원본 텍스트를 보존해야 하나

값만 읽는다 → 어떤 파서도 괜찮습니다. "필드 하나를 바꾸고 나머지는 정확히 그대로 둔다" → "파싱 → 객체 변경 → 직렬화"가 아니라 편집형 API를 써야 합니다.

후자는 주석, 키 순서(일부 구현), 들여쓰기 스타일, 숫자 리터럴 표기(1e3이 1000이 됨), 이스케이프 형태(\u4e2d가 실제 문자가 됨)를 잃습니다.

3.3 경계 동작이 명시되어 있는가

라이브러리를 고르기 전에 문서에서 세 가지를 확인하세요:

1. 중복 키를 어떻게 처리하는지(마지막 유지 / 오류)
2. 큰 정수가 정밀도를 잃는지(대부분 JS 라이브러리가 잃음, 모두 Number를 거치기 때문)
3. BOM, 주석, 후행 쉼표의 지원 범위

문서가 없으면 작은 샘플을 써서 직접 시험하세요. README를 읽는 것보다 신뢰할 만합니다.

3.4 유지 관리 상태

JSON 라이브러리의 위험은 기능 누락이 아니라 장기 방치입니다. 보안 패치(프로토타입 오염, ReDoS)를 아무도 내놓지 않습니다.

4. 다른 언어와 비교

언어 간 데이터 교환에서 가장 넘어지기 쉬운 것은 여전히 숫자 정밀도와 시간 형식이며, 라이브러리 선택은 이를 완화할 뿐 없애지 못합니다.

5. 전형적인 조합

옵션 1: 도구 사이트(브라우저 측)

复制Parsing and error location: jsonc-parser
Editor: CodeMirror 6 + @codemirror/lang-json
Query: jsonpath-plus
Patch: fast-json-patch
Share links: lz-string

이 조합의 특징은 모두 로컬에서 실행되고 데이터를 업로드하지 않는다는 것이며, 유틸리티 사이트의 프라이버시 기대에 맞습니다.

옵션 2: 서버 측 API 게이트웨이

复制Validation: Ajv (compile the schema once, reuse it)
Parsing: native JSON.parse (together with a body size limit)
Deferred parsing of large fields: keep the raw string, parse only when needed

게이트웨이 계층에 쿼리/패치 라이브러리를 들여와 업무 로직을 구현하지 마세요. 그것은 업무 계층의 일입니다.

옵션 3: CLI와 스크립트

复制Pick fields: jq
Format conversion: yq / dasel
Interactive browsing: jless
Batch validation: ajv-cli

6. 번들 크기와 성능의 실제 영향

• jsonc-parser는 아주 작아 메인 번들에 적합합니다.
• json5는 문법 지원이 많아 jsonc-parser보다 약간 큽니다.
• jsonpath-plus는 표현식 평가를 포함해 눈에 띄게 커서 페이지별 지연 로딩해야 합니다.
• fast-json-patch는 중간 크기이며 비교 기능이 있을 때만 필요합니다.

최적화는 간단합니다. 페이지별로 동적 임포트하고 첫 화면 청크에 넣지 마세요.

复制const { JSONPath } = await import('jsonpath-plus');

7. 체크리스트

• [ ] 목적별로 라이브러리를 고르고 파싱에 쿼리 라이브러리를 쓰지 않습니다
• [ ] 정확한 오류 위치가 필요하면 jsonc-parser를 씁니다
• [ ] 주석과 형식을 보존해야 하면 편집형 API를 씁니다
• [ ] 세 경계 동작(중복 키, 큰 정수, BOM)을 실제로 시험합니다
• [ ] 라이브러리의 유지 관리 상태와 보안 공지를 지켜봅니다
• [ ] 큰 라이브러리를 필요에 따라 동적 임포트합니다

FAQ

프로젝트 규모에 따라 JSON 라이브러리를 어떻게 고르나?

API 데이터만 읽는 작은 도구는 네이티브 JSON.parse로 충분합니다. 에디터급 오류 위치가 필요하거나 원본 형식을 보존해야 하는 프로젝트는 jsonc-parser를 쓰세요. 서버 측 게이트웨이는 검증과 파싱만 필요해 쿼리와 패치 라이브러리는 업무 계층에 남기고, CLI 스크립트는 jq, yq, ajv-cli를 바로 쓸 수 있습니다.

유지 관리 상태가 왜 기능 수보다 중요한가?

JSON 라이브러리의 진짜 위험은 기능 누락이 아니라 장기 방치입니다. 프로토타입 오염이나 ReDoS 보안 패치를 아무도 내놓지 않습니다. 기능 목록이 아무리 완전해도 정체된 라이브러리는 스스로 패치해야 합니다. 기능 표를 비교하기보다 유지 관리와 보안 공지를 엄격한 기준으로 삼으세요.

필드 하나를 바꾸면서 주석과 들여쓰기를 유지하려면 JSON.parse를 써야 하나?

아니요. 파싱, 객체 변경, 직렬화는 주석, 키 순서, 들여쓰기 스타일, 숫자 리터럴 표기(1e3이 1000이 됨), 이스케이프 형태(\u4e2d가 실제 문자가 됨)를 잃습니다. 필드 하나만 바꾸고 나머지를 그대로 두려면 jsonc-parser의 modify와 applyEdits 같은 편집형 API가 필요합니다.