JSON 정리 후 긴 ID가 바뀌는 이유

JSON을 보기 좋게 정리했을 뿐인데 긴 주문 ID의 마지막 숫자가 바뀌었다면, 들여쓰기보다 숫자 처리 방식을 먼저 확인해야 합니다. 일부 구현은 JSON을 자바스크립트 값으로 읽은 뒤 다시 문자열로 만듭니다. 이 과정에서는 큰 정수의 정밀도가 손실될 수 있습니다. 이미 바뀐 숫자에 따옴표를 붙여도 원래 값은 복구되지 않습니다.

이 글의 예제는 실제 고객 정보가 없는 테스트 데이터입니다. 운영 로그, 인증 토큰, 고객 식별자는 복사하지 말고 아래 예제로 먼저 확인하세요.

1. 마지막 숫자가 바뀌는 사례

다음 코드는 자바스크립트에서 JSON을 파싱한 후 다시 출력하는 일반적인 형태입니다.

const original = '{"id":9007199254740993}';
const result = JSON.stringify(JSON.parse(original));
console.log(result);
// {"id":9007199254740992}

입력은 9007199254740993인데 결과는 9007199254740992입니다. JSON 문법이 틀려서가 아닙니다. 자바스크립트 Number가 이 정수를 정확히 표현하지 못하기 때문입니다. MDN도 JSON.parse로 숫자를 읽는 과정에서 정밀도를 잃을 수 있다고 설명합니다. 모든 JSON 도구가 같은 문제를 일으키는 것은 아니며, 실제로 어떤 구현을 사용하는지가 중요합니다.

2. ID를 문자열로 전달할 때 주의할 점

계산에 쓰지 않는 식별자라면 생성하는 쪽과 받는 쪽이 문자열로 전달하도록 명세를 맞추는 방법을 검토할 수 있습니다.

{"id":"9007199254740993"}

다만 기존 API가 숫자를 요구한다면 임의로 문자열로 바꾸면 안 됩니다. 생산자와 소비자의 자료형 계약을 함께 수정해야 합니다. 반대로 원본 파일에는 정확한 숫자가 있었는데 중간 프로그램이 이미 반올림했다면, 현재 값을 문자열로 바꾸는 것으로는 부족합니다. 손실되기 전 원본이나 데이터 생성 시스템에서 다시 받아야 합니다.

3. 형식 정리와 값 변환을 구분합니다

바로정리의 JSON 기능은 이번 수정에서 구문 검사와 출력 생성을 분리했습니다. 문법을 검사한 뒤 파싱된 값으로 결과를 다시 만들지 않고, 원본 숫자·문자열 표기를 유지하면서 문자열 밖의 공백과 줄바꿈을 정리합니다.

1. 바로정리에서 ‘형식 변환’을 선택합니다.
2. ‘JSON 보기 좋게’를 누르고 아래 테스트 데이터를 붙여 넣습니다.
3. 긴 ID의 끝자리, 1e400 표기, 두 개의 status 항목이 남는지 비교합니다.
4. ‘JSON 한 줄로’로 바꿔도 같은 표기가 남는지 확인합니다.

{"id":9007199254740993,"amount":1e400,"status":"draft","status":"sent"}

같은 유형의 큰 정수·지수 표기·중복 키 보존은 브라우저 화면의 들여쓰기·한 줄 변환으로 확인했습니다. 별도 자동 검사에서는 큰 정수, 긴 소수, 지수 표기, 음의 0, 문자열 이스케이프, 중복 키, 잘못된 문법을 확인했습니다. 테스트 통과가 모든 입력과 환경에 대한 무오류 보증은 아닙니다.

4. 중복 키를 보존하는 것과 안전한 데이터는 다릅니다

위 예제의 status는 의도적으로 두 번 넣었습니다. 원문을 진단하는 도구가 두 항목을 그대로 보여 주는 것은 도움이 되지만, 이런 JSON을 서비스 간 데이터 교환에 권장한다는 뜻은 아닙니다. RFC 8259는 객체의 이름이 고유해야 상호운용에 유리하다고 설명하며, 중복 이름 처리 결과는 구현에 따라 달라질 수 있습니다.

따라서 두 status 중 하나를 도구가 임의로 삭제하게 하기보다, 데이터를 만드는 코드에서 왜 중복되었는지 확인하세요. 바로정리는 중복 키 경고나 업무 규칙 검사를 제공하지 않습니다. 1e400 표기가 보존되어도 이를 받는 프로그램이 해당 숫자를 처리할 수 있다는 뜻은 아닙니다.

5. 사용 범위와 한계

• JSON 입력은 100,000자, 중첩은 100단계, 변환 결과는 1,000,000자까지 처리합니다. 여기서 문자 수는 자바스크립트 문자열 길이 기준이며 바이트 수와 다릅니다.
• 문법 오류가 있으면 결과를 표시하지 않고 복사를 막습니다. 오류 위치를 정밀하게 안내하는 편집기는 아닙니다.
• 도구 코드의 변환 처리는 브라우저 안에서 이루어집니다. 이것이 기기·확장 프로그램·클립보드까지 포함한 보안 보증은 아니므로 민감한 원본은 입력하지 마세요.
• 들여쓰기 성공은 데이터가 업무상 정확하다는 뜻이 아닙니다. 필수 키, 자료형, 날짜, 중복 키는 별도로 확인해야 합니다.

핵심은 간단합니다. 보기 좋게 정리하는 작업과 값을 해석해서 다시 만드는 작업은 다릅니다. 긴 ID가 있는 JSON이라면 변환 전후를 원본과 비교하고, 이미 손실된 값은 반드시 원본에서 다시 확인하세요.

참고 자료

• MDN: JSON.parse와 숫자 정밀도
• RFC 8259: 객체 이름 중복과 숫자의 상호운용성
• 관련 글: 한 줄 JSON 로그에서 구조를 확인하는 방법