핵심 정리

I-JSON으로 교환 안정성을 높이는 기준

- UTF-8로 인코딩
- object member name은 중복 없이 생성
- 53비트 안전 정수 범위를 넘는 숫자는 string 검토
- timestamp는 명확한 date-time string 사용
- 프로토콜 최상위는 object를 우선 고려

상호운용 기준

I-JSON은 더 엄격한 JSON 사용 프로필이다

JSON 문법은 단순하지만, 모든 유효 JSON이 모든 구현에서 같은 의미로 안전하게 처리되는 것은 아니다. I-JSON은 인터넷 프로토콜에서 예측 가능한 JSON 교환을 위해 더 엄격한 생성 기준을 둔다. JSON을 새로 발명하는 형식이 아니라, 상호운용성이 떨어지는 표현을 피하도록 제한한 사용 방식이다.

UTF-8과 Unicode 경계를 명확히 해야 한다

RFC 7493은 I-JSON 메시지를 UTF-8로 인코딩하는 기준을 둔다. 또한 문자열과 member name에 문제가 되는 surrogate나 noncharacter를 넣지 않는 쪽으로 제한한다. JSON parser가 문법적으로 받아들일 수 있더라도, 서로 다른 언어와 저장소를 거치며 문자열이 다르게 해석되면 검색, 비교, 서명, 로그 처리에서 문제가 생긴다.

number는 수학 값보다 구현 가능 범위를 먼저 봐야 한다

JSON number는 정수와 실수를 문법적으로 표현할 수 있지만, 수신 구현이 이를 어떤 숫자 타입으로 읽을지는 다르다. I-JSON은 IEEE 754 double precision 범위를 실무 기준으로 보고, 9007199254740991을 넘는 정수를 정확한 값으로 기대하지 않는 기준을 제시한다. ID, 주문 번호, 정밀 금액처럼 정확도가 중요한 값은 string 또는 별도 단위 규칙으로 설계하는 편이 안전하다.

{
  "orderId": "9007199254740993",
  "amountMinor": 129900,
  "currency": "KRW"
}

최상위 object는 확장과 must-ignore 규칙에 유리하다

I-JSON 프로토콜 설계에서는 최상위 구조를 object로 두고, 알 수 없는 member는 무시할 수 있게 설계하는 방식이 권장된다. 이 구조는 새 field를 추가해도 기존 클라이언트가 깨질 가능성을 줄인다. 배열을 최상위로 두면 나중에 meta, version, requestId 같은 확장 정보를 붙이기 어렵다.

적용 기준

공식 참고: RFC 7493: I-JSON, RFC 8259: JSON

주의할 점

{
  "id": 9007199254740993
}

이 값은 JSON 문법상 유효하지만 JavaScript 같은 환경에서는 정확한 정수로 유지되지 않을 수 있다. 계산하지 않는 식별자는 처음부터 string 계약으로 두는 편이 안전하다.