UUID·GUID 바이트 순서: 같은 ID가 다른 16바이트로 보이는 이유

문자열 순서와 저장 순서를 구분하세요

RFC 9562 §4의 기본은 필드별 빅 엔디언이며 명시적인 프로토콜 규칙은 예외입니다.

같은 가상 UUID의 앞 8바이트를 RFC 순서와 .NET 기본 순서로 비교하고 뒤 8바이트가 같은 도식 — 직접 실행한 결과를 그린 도식입니다. 앞의 4·2·2바이트 그룹만 각각 뒤집히고 마지막 8바이트는 유지됩니다. 실제 데이터베이스 화면이 아닙니다.

.NET에서 같은 ID로 왕복하기

2026년 10월 5일 .NET 10.0.11에서 아래 코드를 실행했습니다. 기본 ToByteArray()는 33 22 11 00 55 44 77 46으로 시작합니다. ToByteArray(true)는 00 11 22 33 44 55 46 77로 시작합니다. 둘 다 마지막은 88 99 aa bb cc dd ee ff입니다. 기본 바이트 배열을 기본 생성자로 읽으면 원래 문자열로 돌아옵니다. true로 만든 배열에는 해당 엔디언을 지정한 생성자를 짝지었습니다. 전체 16바이트를 뒤집으면 이 예제의 어느 결과와도 같지 않습니다.

$id = [guid]'00112233-4455-4677-8899-aabbccddeeff'
$bytes = $id.ToByteArray()
($bytes | ForEach-Object { $_.ToString('x2') }) -join ' '
# 33 22 11 00 55 44 77 46 88 99 aa bb cc dd ee ff
([guid]::new($bytes)).ToString()
# 00112233-4455-4677-8899-aabbccddeeff
$network = $id.ToByteArray($true)
([guid]::new($network, $true)).ToString()
# 00112233-4455-4677-8899-aabbccddeeff

Microsoft .NET 10: Guid.ToByteArray

Moyoutil에서는 무엇을 확인할 수 있나요?

현재 UUID 생성기는 v4 문자열 목록을 만들고 대소문자·텍스트·JSON 표시를 바꿉니다. 16바이트 바이너리 내보내기나 GUID 엔디언 변환은 제공하지 않습니다. 생성한 문자열을 연동 코드의 테스트 자료로 보관하고 송신·수신 API의 바이트 규칙을 맞추세요. 불일치가 생기면 같은 문자열, 16바이트 길이, 첫 세 그룹, 끝 8바이트를 순서대로 비교하세요. 바이트를 임의로 뒤집어 맞추기 전에 API 계약을 확인하는 절차를 권합니다.

const id = '00112233-4455-4677-8899-aabbccddeeff';
const hex = id.replaceAll('-', '');
const bytes = Uint8Array.from(hex.match(/../g), s => parseInt(s, 16));
console.log(new TextEncoder().encode(hex).length, bytes.length);
// 32 16