JSON은 실행 코드가 아니라 데이터를 교환하는 형식입니다
JSON은 문자열·숫자·불리언·null·배열·객체 등의 데이터를 표현합니다. JavaScript와 문법이 닮았지만 함수나 날짜 객체를 그대로 실행·복원하는 형식은 아닙니다. 받은 문자열은 JSON 파서로 읽고 필요한 구조를 검증해야 하며 코드를 실행하는 방식으로 대신하지 않습니다. 근거: MDN JSON·JSON.parse, 2026-11-04.
근거: MDN JSON · 2026-11-04 확인
정상 입력과 잘못된 쉼표를 실제로 비교했습니다
집필 중 로컬 Node.js v24.20.0에서 {"name":"Mina","count":2}를 JSON.parse로 읽어 name=Mina, count=2를 확인했습니다. 같은 환경에서 {"count":2,}처럼 마지막 쉼표가 있는 문자열은 거부되었습니다. 입력과 출력은 example-observations.json에 보존했습니다. 이는 작은 구문 예의 관찰이지 외부 API 데이터나 모든 JSON 도구를 검증한 결과는 아닙니다.
근거: MDN JSON.parse · 2026-11-04 확인
파싱 성공 뒤에도 필요한 의미를 대조합니다
가상의 재고 데이터에서 count가2여도 그것이 개수인지 상자 수인지 형식만으로 알 수 없습니다. 필수 필드와 타입, 허용 범위, 단위·기준일을 해당 데이터 계약과 비교합니다. 날짜가 문자열로 왔다면 문자열 형식·시간대·누락 조건을 확인하고 저절로 Date 객체라고 취급하지 않습니다. null과 필드 없음도 계약에서 같은지 따로 봅니다.
근거: MDN JSON · 2026-11-04 확인
실패하면 원문 보존과 오류 분류부터 합니다
허가된 데이터의 비밀 없는 최소 예를 만들고 구문 오류인지 타입 불일치인지 업무 조건 오류인지 나눕니다. 서버가 HTML 오류를 보냈다면 Content-Type·상태·최종 주소를 먼저 확인합니다. 키를 임의로 삭제하거나 오류 문자열을 숫자로 강제해 통과시키지 않습니다. 외부 입력은 코드로 평가하지 않고 안전한 파싱과 검증 경로를 사용합니다.
성공 보고는 구문과 데이터 계약을 분리합니다
JSON으로 읽혔다면 구문 성공, 필수 구조와 단위를 대조했다면 그 범위의 데이터 검증으로 적습니다. 실제 저장·전송·화면 결과는 또 다른 확인입니다. 이 글에서는 로컬 예제 파싱만 실행했으며 시스템 통합이나 외부 자료 정확성 통과를 주장하지 않습니다.
원문으로 이어 읽기
확인일: 2026-11-04. 정의와 적용 범위, 발행일과 판본을 함께 살펴봅니다. 원문이 존재한다는 사실만으로 개별 주장의 정확성과 재사용 권리가 자동 보장되지는 않습니다.