자주 발생하는 JSON 구문 오류 분석 및 수정: RFC 8259 표준 가이드

1. 구문 검증(Syntax) vs JSON Schema vs 비즈니스 규칙의 차이점

개발자들 사이에서 자주 발생하는 오해 중 하나는 모든 JSON 데이터 검증 작업을 단일 과정으로 혼동하는 것입니다. 현대 소프트웨어 공학에서는 다음과 같은 세 가지 독립적인 검증 계층이 명확하게 구분됩니다.

• RFC 8259 구문 검증(Syntax Validation): 입력 데이터가 JSON의 어휘 문법에 엄격히 부합하는지 확인합니다. 중괄호와 대괄호의 짝 일치, 큰따옴표로 감싸진 키와 문자열, 쉼표 구분자, 유효한 원시 리터럴(문자열, 숫자, 불리언, null)이 검사 대상입니다. 따옴표나 괄호가 하나라도 누락되면 유효한 JSON 문서로 성립조차 하지 않습니다.
• JSON Schema 검증: 구문적으로 올바른 JSON이 사전에 정의된 데이터 규약($schema 정의, 각 프로퍼티의 타입, 필수 필드, 배열 길이 한계값 등)을 충족하는지 평가합니다. 구문은 완벽하더라도 스키마 검증에서 위반되는 상황은 빈번하게 발생합니다.
• 비즈니스 규칙 검증(Business Rules): 애플리케이션 고유의 도메인 요구사항(예: 계좌 잔액은 음수가 될 수 없음, 종료일시는 시작일시보다 미래여야 함 등)을 검증합니다. 구문 파서나 범용 스키마로는 도메인 논리의 타당성까지 보장할 수 없습니다.

GoToolstack의 JSON 도구는 엄격한 RFC 8259 구문 검증 및 AST(추상 구문 트리) 기반 포맷팅만을 수행하며, JSON Schema 평가나 애플리케이션 비즈니스 규칙 검사 기능은 수행하지 않습니다.

2. 포맷팅은 자동 오류 복구가 아닙니다

JSON 포맷터(인덴트 정렬 및 압축 도구)는 이미 구문적으로 성립된 유효한 추상 구문 트리(AST)에 대해 공백, 줄바꿈, 들여쓰기를 정돈하는 도구입니다. 손상된 데이터를 임의로 추론하여 복원하는 자동 복구 엔진이 아닙니다.

구문이 깨진 문자열을 입력하면, 파서 엔진은 첫 번째 유효하지 않은 바이트 위치에서 처리를 즉각 중단하고, 오류 위치와 주변 컨텍스트를 포함한 명확한 진단 정보(예: Trailing comma in object is not allowed at position 45)를 출력하며 결과 영역을 비웁니다. 개발자의 의도를 임의로 추측하여 괄호를 닫거나, 불법 후행 쉼표를 임의로 제거하거나, 작은따옴표를 자동으로 치환하지 않습니다. 정상적인 포맷팅을 위해서는 소스 데이터의 구문 오류를 수동으로 수정해야 합니다.

3. 자주 발생하는 5가지 주요 JSON 구문 오류

{
  "name": "GoToolstack",
  "active": true,
}

{'status': 'success'}

{count: 42}

{"path": "C:\programs\data.json"}

// 서버 설정 항목
{"port": 8080}

4. 64비트 정수 정밀도 손실 함정: 무손실 토큰 보존 vs 수신 시스템의 제한

표준 JavaScript 환경에서 숫자는 모두 IEEE 754 배정밀도 64비트 부동소수점 숫자로 처리됩니다. 안전하게 표현 가능한 정수의 상한선은 다음과 같습니다.

Number.MAX_SAFE_INTEGER = 9,007,199,254,740,991 (2^53 - 1)

웹 API가 대규모 64비트 정수 식별자, 데이터베이스 기본 키, 트랜잭션 번호 등(예: 9007199254740993)을 반환할 때 표준 JSON.parse()를 실행하면 오류 없이 자동으로 9007199254740992로 반올림되어 데이터 손상이 발생합니다.

GoToolstack의 JSON 엔진은 수치를 AST 상에서 원본 텍스트 토큰으로 온전히 유지하는 커스텀 무손실(lossless) 파서를 탑재하고 있습니다. 따라서 본 도구 내에서 포맷팅할 때는 원래 자릿수가 모두 유지됩니다. 그러나 이 보존 동작이 외부 수신 시스템의 안전까지 보장하지는 않습니다. 포맷팅된 JSON을 전달받은 후속 마이크로서비스, DB 드라이버, 외부 프론트엔드가 표준 float64 파서로 파싱하면 그 시점에서 다시 반올림 오차가 발생합니다. 분산 시스템에서는 큰 64비트 정수 ID를 문자열 타입(예: "9007199254740993")으로 설계하고 통신하는 것이 권장됩니다.

5. 중복 객체 키와 RFC 8259 파서 해석의 모호성

동일한 객체 내에 동일한 이름의 키가 중복 작성된 구조를 고려해 봅니다.

{"user": "alice", "user": "bob"}

GoToolstack의 AST 파서는 각 키-값 쌍을 작성된 순서대로 모두 유지하며, 이전 항목을 임의로 삭제하지 않습니다. 그러나 RFC 8259 제4조에서는 중복 키에 대한 파서의 동작이 소프트웨어 구현마다 예측 불가능하다고 명시되어 있습니다.

• 첫 번째 키만 채택하고 이후의 중복을 무시하는 파서가 있습니다.
• 일반적인 표준 라이브러리(JS의 JSON.parse() 및 Python의 json.loads() 등)는 나중 값으로 덮어써 마지막 키만 남깁니다.
• 엄격한 파서의 경우 중복 키를 감지하는 즉시 구문 오류를 발생시키며 문서 전체를 파기합니다.

GoToolstack이 포맷팅 출력에서 중복 키를 보존한다고 해서 대상 수신 시스템이 이를 동일하게 해석한다는 보장은 없습니다. 프로덕션 환경의 JSON 데이터에서는 모든 키가 고유해야 합니다.

6. 도구의 기술적 제한 사항 및 처리 한계

• 트리 뷰 및 스키마 검증 미지원: 본 도구는 경량성과 즉각적인 반응성을 중시한 2페인 플레인 텍스트 에디터와 실시간 진단 기능을 제공합니다. 접이식 DOM 트리 뷰어나 JSON Schema 검증 기능은 포함하지 않습니다.
• 허용되지 않는 값: NaN, Infinity, -Infinity는 RFC 8259에서 허용되지 않습니다. JavaScript의 undefined, 함수, 순환 참조 구조를 가진 객체 역시 JSON으로 직렬화할 수 없습니다.
• 클라이언트 측 로컬 실행: 모든 구문 분석 및 AST 포맷팅은 사용자의 브라우저 메모리 내에서만 실행되며, 입력 데이터가 외부 서버로 전송되는 일은 전혀 없습니다.