같은 키가 두 번 나오면 첫 값·마지막 값·오류·전체 보존처럼 구현마다 결과가 달라질 수 있습니다. 값과 처리 정책을 바꿔 비교합니다.
같은 객체 안에 status가 ‘공개’와 ‘비공개’로 두 번 적히면 어느 것이 진짜일까요?
RFC 8259는 객체 안의 이름이 고유해야 한다고 권고합니다. 중복이면 많은 구현은 마지막 값만 보고하지만, 어떤 구현은 오류를 내거나 모든 값을 보존합니다.
앞단 검증기는 첫 값을 보고 ‘공개’를 허용했는데 뒤 실행기는 마지막 ‘비공개’를 쓰거나 그 반대가 되면 정책 판단이 어긋납니다.
AI가 만든 JSON도 신뢰 경계를 통과할 때 스키마 검증기로 중복 이름을 거부하고, 정규화된 한 표현만 다음 단계로 넘겨야 합니다.
두 status가 모두 ‘공개’라면 당장 결론은 같아 보이지만, 다음 수정에서 하나만 바뀌면 잠복 충돌이 드러납니다.
따라서 결과값 일치보다 객체 이름의 유일성이라는 구조 조건을 검사하는 편이 안전합니다.
RFC 8259가 설명하는 구현 차이를 네 가지 명시적 정책으로 단순화했습니다. 실제 라이브러리의 보안성이나 특정 AI 모델의 출력을 측정하지 않습니다.
RFC 8259는 객체 이름이 고유해야 한다고 권고하며, 중복일 때 구현 행동이 달라질 수 있다고 설명합니다. 생성 단계에서 중복 키를 만들지 않고 수신 단계에서 명시적으로 검증해야 합니다.
두 문제의 답을 모두 선택하면 해설을 볼 수 있습니다.
메모는 현재 기기의 브라우저에만 보관됩니다. 계정이나 다른 기기에는 동기화되지 않습니다.
원문을 참고해 설명·도표·문항·실험을 새로 작성했습니다. 별도 표시가 없는 사례와 수치는 학습을 위한 가상 예시입니다. 원문 번역이나 실제 모델의 성능 평가 자료가 아닙니다.
2017년 12월 표준 원문 전체를 확인했습니다. 정수는 [−(2^53)+1, (2^53)−1] 범위에서 널리 정확히 상호운용되고, 객체 이름은 고유해야 하며 중복 이름의 수신 동작은 구현마다 다를 수 있다고 설명합니다.
