SCM 주문번호 정밀도 검수: 긴 숫자가 바뀌는 경계를 찾는 법

SCM 주문번호는 JavaScript 숫자 변환에서 손실될 수 있습니다. 2026-11-06 기준, 다른 파서의 정밀도는 별도 확인합니다.

원천 주문은 다른데 조회 화면에서 하나로 합쳐지면 재전송이나 중복 제거부터 의심하기 쉽습니다. 그보다 앞에서 번호 자체가 바뀌었을 수도 있습니다. 수신 건수와 함께 원천 번호의 값·타입을 대조하면 변환 과정의 손실을 찾을 수 있습니다.

API가 정상인데 주문번호 끝자리가 왜 바뀌나요?#

긴 번호를 JavaScript Number로 해석하면 서로 다른 정수가 같은 값이 될 수 있습니다. 번호를 식별자로 쓴다면 계산 가능한 수인지보다 원천의 자릿수와 표기가 보존되는지 확인해야 합니다. 이 글은 JSON·JavaScript 경계의 재현과 인수 설계에 한정합니다.

ECMAScript 2026의 Number.MAX_SAFE_INTEGER는 9007199254740991입니다. 그보다 큰 모든 정수가 당장 틀리는 것은 아니지만, 서로 다른 정수를 정확히 구분한다는 보장이 사라집니다. ECMA-262 공식 규격의 안전 정수 설명은 9007199254740992와 9007199254740993이 같은 Number 값이 되는 예를 명시합니다. 발행은 2026-06, 확인일은 2026-11-06입니다.

API 연동 담당자는 숫자로 보내고 받는 경계를, 화면 담당자는 조회·선택·재전송 과정의 변환을 확인합니다. 현업 인수자는 서로 다른 두 주문이 별도 주문으로 남는지 대조합니다. 합계가 맞아도 주문별 연결이 잘못됐을 수 있습니다.

숫자로 바꾼 뒤 문자열로 되돌리면 복원되나요?#

이미 정밀도가 손실된 숫자에 String을 적용해도 원래 자릿수는 복원되지 않습니다. 숫자 변환을 하기 전의 문자열이나 원천 자료가 있어야 대조할 수 있습니다. 앞자리 0이 사라진 번호에도 같은 원칙을 적용합니다.

아래는 고객 자료가 아닌 합성 JSON 표본입니다. 2026-11-06 Node v25.2.1에서 실행해 숫자 충돌, 늦은 문자열 변환, 문자열 왕복 보존 등을 확인했습니다. 실제 SCM API·DB·화면 전체를 시험한 결과는 아닙니다.

const a = JSON.parse('{"orderId":9007199254740992}').orderId;
const b = JSON.parse('{"orderId":9007199254740993}').orderId;
const kept = JSON.parse('{"orderId":"9007199254740993"}').orderId;

console.log(a === b); // true
console.log(String(b)); // 9007199254740992
console.log(kept); // 9007199254740993
console.log(Number("00123")); // 123

JSON이 큰 정수를 문법상 금지하는 것은 아닙니다. RFC 8259의 숫자 상호운용성 설명은 수신 구현이 숫자의 범위와 정밀도에 한계를 둘 수 있다고 설명합니다. 문서 발행은 2017-12, 확인일은 2026-11-06입니다. JavaScript의 결과를 모든 언어와 파서에 그대로 일반화하지 마세요.

문자열로 받기로 합의했다면 공급자 응답부터 내부 스키마와 저장·조회 경로까지 그 계약을 유지합니다. 숫자를 반환하는 원천을 당장 바꿀 수 없다면 원문을 손상 없이 해석하는 처리와 변환 규칙을 별도로 정해야 합니다. 이미 Number로 해석된 값만 보관한 상태에서는 원천 재확인이 필요합니다.

원천·저장·화면에서 무엇을 같은 기준으로 비교하나요?#

각 경계에서 기대 문자열, 실제 값과 타입, 서로 다른 번호의 구분 결과를 함께 받습니다. 번호를 건수만으로 대사하거나 안전 정수 판정 하나로 통과시키지 않습니다. 예를 들어 00123이 123으로 변해도 결과 숫자 자체는 안전 정수일 수 있습니다.

다음 표는 같은 식별자를 수신부터 다시 내보내기까지 대조하는 설계 예시입니다. 비용·납기나 실제 장애 빈도를 비교하는 표가 아닙니다. 원천 계약에서 번호의 앞자리 0·접두어·공백을 어떻게 정의하는지 먼저 합의합니다.

저장 키에 충돌이 나면 처리 성공으로 묶지 않고 원천 값을 확인할 보류 대상으로 분류합니다. 단, 원천 시스템이나 법인이 다른데 같은 번호를 쓰는 문제는 별도 차원입니다. 문자열 보존만으로 시스템 간 식별 관계까지 결정되지는 않습니다.

Number.isSafeInteger는 수신한 Number가 안전 정수인지 검사하는 보조 도구입니다. 원천 문자열의 자릿수 보존이나 올바른 주문 연결을 증명하지는 않습니다. 공식 판정 규칙과 기대 문자열 대사를 함께 사용하세요.

문자열로 보관하면 다른 검수는 끝나나요?#

식별 문자열 보존은 수집 완료·업무 의미·재처리 검수를 대신하지 않습니다. BigInt 같은 큰 정수 처리도 앞자리 0이나 문자 접두어가 있는 식별 규칙까지 자동으로 보존해 주지는 않습니다. 어떤 표현을 선택하든 실제 전송·저장·화면 경로로 확인합니다.

페이지를 다 읽지 못해 주문이 빠지는 문제는 SCM 증분 수집과 체크포인트 검수에서, 들어온 상태값의 의미가 다른 문제는 SCM 주문 상태 코드 매핑에서 다룹니다. 이 글은 번호가 바뀌는 타입 변환 경계에 집중합니다.

주문번호는 합산 대상 금액과도 다릅니다. 금액의 행별·합계별 처리 차이는 정산 반올림 대사에서 확인할 수 있습니다. 번호를 보존했다는 이유로 금액 정밀도까지 검수했다고 기록하지 마세요.

알파카랩스는 맞춤 ERP 개발 서비스에서 기준 시스템과 연동 책임, 이관·대사와 오류 복구의 인수 범위를 협의한다고 공개합니다. 자사 제공 방식에 대한 자기표기이며, 이 글의 합성 재현을 실제 고객 장애나 납품 실적으로 주장하지 않습니다. 다음 검토는 2026-12-06 또는 연동 파서·스키마 변경 시 진행합니다.

SCM 주문번호 정밀도 검수 FAQ#

JSON은 큰 주문번호를 보낼 수 없나요?

JSON 문법 자체가 큰 정수를 일률적으로 금지하지는 않습니다. 수신 구현이 숫자를 어떤 타입과 정밀도로 해석하는지에 따라 보존 여부가 달라집니다. 공급자와 소비자 사이의 식별자 표현 계약을 확인해야 합니다.

JavaScript에서 안전 정수보다 큰 번호는 모두 잘못되나요?

모든 큰 정수가 즉시 다른 값으로 변하는 것은 아닙니다. 안전 정수 범위를 넘으면 서로 다른 정수를 정확히 구분한다는 보장이 없어집니다. 식별자 검수에서는 실제 원천 문자열과 경계별 결과를 대조합니다.

숫자로 받은 뒤 String으로 바꾸면 충분한가요?

이미 파싱 과정에서 자릿수가 바뀌었다면 String으로 원래 번호를 복원할 수 없습니다. 손상 전 문자열이나 원천 자료로 돌아가 확인해야 합니다. 문자열 계약은 숫자 변환 전에 적용할 수 있어야 합니다.

Number.isSafeInteger가 true면 주문번호도 맞나요?

그 값이 안전 정수라는 뜻이며 원천의 표기까지 보존했다는 뜻은 아닙니다. 문자열 00123을 숫자 123으로 바꾸면 앞자리 0이 없어져도 안전 정수입니다. 기대 문자열과 실제 타입을 함께 대조합니다.

DB에 문자열로 저장하면 검수는 완료되나요?

수신 전에 이미 손상됐거나 화면·후속 요청에서 다시 숫자로 변환할 수 있습니다. 원천부터 재전송까지 값·타입·주문 연결을 확인해야 합니다. 실제 같은 주문의 재전송과 서로 다른 주문의 키 충돌도 나눠 봅니다.

주문번호 경계 인수표 협의#

민감정보를 제거한 API 표본과 스키마로 원천·수신·저장·화면·후속 요청의 값과 타입을 대조할 수 있습니다. 산출물은 주문번호 경계 인수표 초안이며, 소요 시간은 자료와 연동 범위를 확인한 뒤 정합니다.