주제 이해를 돕기 위한 AI 생성 이미지 · LTCT 자체 제작오늘의 질문계산하지 않을 주문번호도 숫자처럼 보내면 더 간단하고 안전할까요?
긴 식별번호 문자열이 JSON 숫자와 이진 부동소수점 변환을 거쳐 끝자리가 달라지고, 문자열 경로에서는 원문이 보존되는 관계 그림입니다. · 한국논리학협회 자체 제작그림 크게 보기 ↗01문법상 JSON 숫자와 정확히 저장되는 숫자는 다릅니다
JSON 문법은 매우 긴 정수도 적을 수 있지만, 수신 프로그램이 IEEE 754 배정밀도 Number로 읽으면 모든 큰 정수를 정확히 구분하지 못합니다.
9007199254740993은 JavaScript Number를 거치며 9007199254740992로 반올림될 수 있습니다.
참고 · Tim Bray 편집 · IETF — JSON 데이터 교환 형식 ↗
02식별자는 크기보다 동일성이 중요합니다
주문번호·자료 ID·전화번호는 더하고 곱할 양이 아닙니다. 선행 0과 마지막 자리까지 그대로 비교해야 하므로 문자열로 전송하는 계약이 알맞습니다.
AI 도구가 구조화 출력을 만들 때 스키마에서 ID를 string으로 지정하고, 수신부에서도 정규식·길이·원문 일치를 검증합니다.
03안전 범위 밖이라고 모든 수가 곧바로 틀리지는 않습니다
2^53 자체처럼 우연히 표현 가능한 큰 정수도 있습니다. 하지만 이웃 정수를 모두 구분할 수 없으므로 ‘이번 값이 맞았다’를 일반 규칙으로 삼을 수 없습니다.
활동은 숫자 표현의 한계를 보여 주며 계정·신분·금융 식별자를 입력하지 않도록 가상 값만 씁니다.
보낸 문자열9007199254740993숫자로 읽고 다시 쓴 값9007199254740992정확히 같은 정수아니요JavaScript 안전 정수아니요 끝자리 정보가 달라졌습니다: 9007199254740993 → 9007199254740992실제 AI 호출이 아니라 브라우저의 Number와 JSON 직렬화를 재현합니다. 긴 ID·계좌번호·주문번호는 계산 대상이 아니라면 문자열로 계약하는 편이 안전합니다.
관계를 읽고, 다른 상황에 적용하기두 문제로 생각 확인
나의 설명으로 마무리오늘 발견한 관계
0 / 4,000자
메모는 현재 기기의 브라우저에만 보관됩니다. 계정이나 다른 기기에는 동기화되지 않습니다.
출처와 제작 안내
원문을 참고해 설명·도표·문항·실험을 새로 작성했습니다. 별도 표시가 없는 사례와 수치는 학습을 위한 가상 예시입니다. 원문 번역이나 실제 모델의 성능 평가 자료가 아닙니다.
- JSON 데이터 교환 형식 ↗Tim Bray 편집 · IETFRFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
2017년 12월 표준 원문 전체를 확인했습니다. 정수는 [−(2^53)+1, (2^53)−1] 범위에서 널리 정확히 상호운용되고, 객체 이름은 고유해야 하며 중복 이름의 수신 동작은 구현마다 다를 수 있다고 설명합니다.
