문자·인코딩·직렬화·엔디언
보낸 쪽 화면에는 한글이 보이는데 받은 쪽에는 깨진 기호가 나타나거나, 숫자 1을 보냈는데 아주 큰 수로 읽히는 일이 있다. 전송 중 바이트가 훼손되지 않았어도 이런 문제는 생긴다. 보내는 쪽과 받는 쪽이 문자 대응 규칙, 여러 바이트의 순서, 구조화된 값의 포장 규칙을 다르게 사용했기 때문이다.
같은 바이트가 다른 글자와 숫자가 되는 이유
보낸 쪽 화면에는 한글이 보이는데 받은 쪽에는 깨진 기호가 나타나거나, 숫자 1을 보냈는데 아주 큰 수로 읽히는 일이 있다. 전송 중 바이트가 훼손되지 않았어도 이런 문제는 생긴다. 보내는 쪽과 받는 쪽이 문자 대응 규칙, 여러 바이트의 순서, 구조화된 값의 포장 규칙을 다르게 사용했기 때문이다.
메모리 속 값은 곧바로 의미를 가진 메시지가 아니다. 문자 인코딩은 문자와 바이트를, 엔디언은 여러 바이트의 순서를, 직렬화는 여러 필드의 구조와 바이트열을 연결한다.
먼저 되짚기: 전송되는 것은 바이트열이다
앞 절에서 바이트는 보통 8비트 묶음이며 파일과 네트워크는 대개 이 바이트들의 순서를 다룬다고 배웠다. 그러나 바이트열만으로는 문자·수·필드 경계를 알 수 없다. 이번 절은 그 바이트열에 공통 해석 규칙을 붙인다.
바이트열 하나에 세 종류의 계약이 겹친다
문자의 바이트 표현은 인코딩, 다바이트 값의 배치는 엔디언, 필드의 구조는 스키마 계약으로 정한다. UTF-16·UTF-32의 문자 코드 단위도 여러 바이트이므로 바이트 순서가 필요할 수 있다. 반면 이 절의 UTF-8 바이트열을 빅·리틀 엔디언에 맞춰 뒤집지는 않는다. 이 서로 다른 규칙이 직렬화된 바이트열과 역직렬화 과정에 함께 들어간다. 어느 한 규칙이 같다는 이유로 나머지 계약도 일치한다고 판단하지 않는다.
각 규칙은 다른 질문을 다루므로 한 규칙의 일치로 나머지까지 자동 일치한다고 보지 않는다.
문자 인코딩과 UTF-8
문자 인코딩은 문자와 숫자 코드, 바이트열을 대응시키는 규칙이다. 문자의 목록과 각 문자에 붙인 번호가 있어도, 그 번호를 실제 바이트로 만드는 규칙이 같아야 저장하고 전송할 수 있다.
UTF-8(Unicode Transformation Format - 8-bit)은 유니코드의 문자 번호를 1~4바이트의 가변 길이 바이트열로 표현하는 인코딩이다. 보내는 쪽과 받는 쪽이 모두 UTF-8을 사용한다는 계약이 있어야 같은 바이트를 같은 문자로 복원한다.
엔디언
엔디언은 여러 바이트로 된 값을 메모리나 전송열에 놓는 순서다. 큰 자릿값의 바이트를 먼저 두면 빅 엔디언, 작은 자릿값의 바이트를 먼저 두면 리틀 엔디언이라고 한다. 값의 수학적 의미가 달라지는 것이 아니라 바이트를 배열하고 다시 조립하는 약속이 다르다.
직렬화 전에 엔디언을 다시 잇는다
엔디언은 여러 바이트로 된 값을 메모리나 전송열에 놓는 순서다. 직렬화 형식이 다바이트 수를 담을 때 송신자와 수신자가 같은 바이트 순서 계약을 써야 원래 값을 복원할 수 있다.
직렬화
직렬화(serialization)는 메모리의 구조화된 값을 저장·전송 가능한 바이트열로 바꾸는 과정이다. 역직렬화는 바이트열을 다시 필드와 값으로 복원하는 과정이다. 직렬화 계약에는 필드 이름·순서·자료형·길이·누락 가능성·문자 인코딩·숫자 바이트 순서·버전이 포함될 수 있다.
주문 메시지가 바이트열이 되었다 돌아오는 과정
필드·문자·바이트 순서를 합의해 같은 값을 복원한다 · 상태 따라가기
id와 문자는 같은 의미를 바이트 계약에 연결한다. 모든 단계에서 구조화 값·바이트·복원의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.
상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.
메모리 값 {id:258, name:가}에 필드 구조·자료형, name의 UTF-8, id의 두 바이트 순서 계약을 함께 적용해 전송열을 만든다. 수신자는 같은 계약으로 id 258과 문자 가를 복원한다. 필드표시와 문자길이도 전송 형식의 일부이며 이것은 실제 프로토콜이 아닌 자체 교육 예다.
이 예의 조건
- 메모리 값 {id:258, name:가}에 필드 구조·자료형, name의 UTF-8, id의 두 바이트 순서 계약을 함께 적용해 전송열을 만든다. 수신자는 같은 계약으로 id 258과 문자 가를 복원한다. 필드 표시와 문자 길이도 전송 형식의 일부이며 이것은 실제 프로토콜이 아닌 자체 교육 예다.
- 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.
관계도의 보충 설명
| 대상 | 원 설명 |
|---|---|
| 메모리 값 | id:258 / name:가 |
| 필드 구조·자료형 | 직렬화 규칙 |
| 문자 UTF-8 | name → EA B0 80 |
| 숫자 바이트 순서 | id258 → 01 02 |
| 전송 바이트열 | 필드 표시·값·문자 길이 |
| 복원한 메모리 값 | id:258 / name:가 |
| 연결 | 원 라벨·방향 |
|---|---|
| 메모리 값 → 필드 구조·자료형 | 라벨 없는 연결 / 정방향 / 실선 |
| 메모리 값 → 문자 UTF-8 | 라벨 없는 연결 / 정방향 / 실선 |
| 메모리 값 → 숫자 바이트 순서 | 라벨 없는 연결 / 정방향 / 실선 |
| 필드 구조·자료형 → 전송 바이트열 | 라벨 없는 연결 / 정방향 / 실선 |
| 문자 UTF-8 → 전송 바이트열 | 라벨 없는 연결 / 정방향 / 실선 |
| 숫자 바이트 순서 → 전송 바이트열 | 라벨 없는 연결 / 정방향 / 실선 |
| 전송 바이트열 → 복원한 메모리 값 | 같은 계약 / 정방향 / 실선 |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 직렬화 입력 id와 문자는 같은 의미를 바이트 계약에 연결한다. |
|
|
| 바이트 생성 id의 01 02와 가의 EA B0 80은 서로 다른 표현 규칙을 따른다. |
|
|
| 같은 계약으로 복원 수신자는 정한 형식·문자 인코딩에 맞춰 같은 의미를 복원한다. |
|
|
필드·문자·바이트 순서를 합의해 같은 값을 복원한다 · 상태 따라가기
id와 문자는 같은 의미를 바이트 계약에 연결한다. 모든 단계에서 구조화 값·바이트·복원의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.
상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.
메모리 값 {id:258, name:가}에 필드 구조·자료형, name의 UTF-8, id의 두 바이트 순서 계약을 함께 적용해 전송열을 만든다. 수신자는 같은 계약으로 id 258과 문자 가를 복원한다. 필드표시와 문자길이도 전송 형식의 일부이며 이것은 실제 프로토콜이 아닌 자체 교육 예다.
이 예의 조건
- 메모리 값 {id:258, name:가}에 필드 구조·자료형, name의 UTF-8, id의 두 바이트 순서 계약을 함께 적용해 전송열을 만든다. 수신자는 같은 계약으로 id 258과 문자 가를 복원한다. 필드 표시와 문자 길이도 전송 형식의 일부이며 이것은 실제 프로토콜이 아닌 자체 교육 예다.
- 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.
관계도의 보충 설명
| 대상 | 원 설명 |
|---|---|
| 메모리 값 | id:258 / name:가 |
| 필드 구조·자료형 | 직렬화 규칙 |
| 문자 UTF-8 | name → EA B0 80 |
| 숫자 바이트 순서 | id258 → 01 02 |
| 전송 바이트열 | 필드 표시·값·문자 길이 |
| 복원한 메모리 값 | id:258 / name:가 |
| 연결 | 원 라벨·방향 |
|---|---|
| 메모리 값 → 필드 구조·자료형 | 라벨 없는 연결 / 정방향 / 실선 |
| 메모리 값 → 문자 UTF-8 | 라벨 없는 연결 / 정방향 / 실선 |
| 메모리 값 → 숫자 바이트 순서 | 라벨 없는 연결 / 정방향 / 실선 |
| 필드 구조·자료형 → 전송 바이트열 | 라벨 없는 연결 / 정방향 / 실선 |
| 문자 UTF-8 → 전송 바이트열 | 라벨 없는 연결 / 정방향 / 실선 |
| 숫자 바이트 순서 → 전송 바이트열 | 라벨 없는 연결 / 정방향 / 실선 |
| 전송 바이트열 → 복원한 메모리 값 | 같은 계약 / 정방향 / 실선 |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 직렬화 입력 id와 문자는 같은 의미를 바이트 계약에 연결한다. |
|
|
| 바이트 생성 id의 01 02와 가의 EA B0 80은 서로 다른 표현 규칙을 따른다. |
|
|
| 같은 계약으로 복원 수신자는 정한 형식·문자 인코딩에 맞춰 같은 의미를 복원한다. |
|
|
정수 258은 십육진수로 0x0102다. 빅 엔디언은 01 02, 리틀 엔디언은 02 01 순서로 둘 수 있다. 받는 쪽이 반대로 조립하면 다른 수가 된다. 문자 가도 UTF-8이라는 정보를 모르면 다른 인코딩으로 잘못 해석할 수 있다. 직렬화 형식이 이 규칙들을 자체 표시하거나, 통신 계약이 바깥에서 고정해야 한다.
위의 {id: 258, name: "가"}는 실제 실행 코드가 아니라 두 항목을 가진 기록을 짧게 쓴 표기다. 중괄호는 기록의 시작과 끝, id와 name은 항목 이름, 콜론 오른쪽은 해당 값이고 따옴표는 문자값을 구별한다. 대괄호 안의 01 02는 두 자리 십육진수로 적은 바이트 두 개이며 숫자 1, 2를 각각 담는다. 큰 자릿값 바이트는 1×256, 작은 바이트는 2×1을 나타내므로 1×256+2=258이다. 한 바이트가 256가지 값을 만들므로 바이트 하나 왼쪽의 자릿값이 256배인 것이다. 같은 전송열을 반대 약속으로 읽으면 2×256+1=513이 되어 원래 주문번호를 잃는다.
필드 경계까지 정한 완전한 교육용 형식을 한 번 읽어 보자. “첫 바이트는 id 길이, 다음은 빅 엔디언 id, 다음 한 바이트는 UTF-8 문자값의 바이트 길이, 나머지는 그 문자값”으로 약속하면 02 | 01 02 | 03 | EA B0 80이 된다. 여기서 세로선은 설명용 구분선으로 전송하지 않는다. 수신자는 먼저 02를 읽고 다음 두 바이트로 id 258을 만든 뒤, 03을 읽고 다음 세 바이트로 가를 복원한다. 총 바이트 수는 1+2+1+3=7이다. 문자값에 필요한 3바이트가 남아 있는지 확인한 뒤 읽어야 하므로, 마지막 80이 없는 입력은 부족한 형식으로 거부한다. 이 형식에서 UTF-8과 빅 엔디언은 미리 고정한 통신 약속이며 메시지 자체가 그 이름을 포함하지는 않는다.
ES-1: A가와 정수 258을 한 메시지로 왕복한다
UTF-8에서 ASCII 문자 A는 1바이트이고 가는 EA B0 80의 3바이트이므로 문자열 A가는 이 예에서 총 4바이트다. 문자 수 2와 바이트 수 4를 같은 값으로 사용하지 않는다.
정수 258은 0x0102다. 두 바이트 정수라고 정했을 때 빅 엔디언은 01 02, 리틀 엔디언은 02 01 순서다. 수신자가 반대 순서로 두 바이트를 조립하면 258이 아닌 다른 값을 얻는다.
앞에서 정한 [id 길이/형][id 바이트][문자열 길이][문자열 바이트] 형식을 이어 쓰면 A가의 완전한 메시지는 02 | 01 02 | 04 | 41 EA B0 80이고 총 1+2+1+4=8바이트다. id 길이 02 뒤 두 바이트로 258을 복원하고, 문자열 길이 04 뒤 네 바이트를 UTF-8로 읽어 두 문자를 얻는다. 구분선은 전송 바이트에 포함하지 않는다. 왕복시험은 문자열을 UTF-8로 복원하고 id를 합의한 엔디언으로 258로 복원하며, 잘못된 길이·불완전 UTF-8·초과 전체크기는 정상 오류로 거부하는지 함께 확인한다.
세 규칙을 구분한다
| 규칙 | 묻는 질문 | 불일치 결과 | 계약에서 확인할 것 |
|---|---|---|---|
| 문자 인코딩 | 문자를 어떤 바이트로 바꾸나 | 글자 깨짐·변환 실패 | 인코딩 이름·잘못된 바이트 처리 |
| 엔디언 | 여러 바이트 수를 어떤 순서로 놓나 | 다른 숫자로 해석 | 바이트 순서·값 길이 |
| 직렬화 | 필드와 구조를 어떻게 포장하나 | 필드 누락·형식 오류 | 스키마·자료형·버전·선택 필드 |
사람이 읽기 쉬운 텍스트 형식은 조사와 연동이 편하지만 같은 정보를 표현하는 바이트가 더 많고 파싱 비용이 들 수 있다. 이진 형식은 작고 빠르게 만들 수 있지만 별도 도구와 정확한 스키마가 필요하다. 선택할 때는 메시지 크기·성능·변경 빈도·조사 가능성을 함께 본다.
여기서 파싱은 정해진 형식에 따라 필드의 경계와 값을 찾아 읽는 일이다. 뒤 절에서 정식으로 다룰 스키마는 그 필드가 어떤 값을 의미하는지 정하는 계약이며, 이 절에서는 위의 두 길이와 값 규칙만으로 작은 메시지를 읽었다. 이 예에서 거부서비스 위험은 잘못된 입력을 처리하느라 자원이 소진되어 정상 요청을 받지 못하는 상황을 뜻한다. 따라서 외부 길이값이 아주 크면 그만큼 저장공간을 먼저 마련하는 대신 허용 전체 크기와 실제 남은 바이트 수를 먼저 검사한다.
실패조건과 방어
기본값 의존은 운영체제나 프로그램의 기본 인코딩·엔디언이 같을 것이라 가정하는 경우다. 경계를 넘는 형식에는 이름과 버전을 명시한다.
바이트 수와 문자 수 혼동은 UTF-8 문자열 공간을 글자 수만큼만 잡는 경우다. 필요한 제한이 문자 개수인지 실제 바이트 길이인지 구분한다.
필드 경계 모호성은 길이 또는 구분 규칙 없이 값을 이어 붙일 때 생긴다. 필드 길이·태그·구분자의 탈출 규칙 중 하나를 명확히 둔다.
신뢰할 수 없는 입력의 역직렬화에서는 외부 바이트가 주장하는 거대한 길이나 잘못된 구조를 그대로 믿지 않도록 주의한다. 전체 크기·깊이·필드 범위를 검증하고 실패를 정상적인 오류 경로로 처리한다.
자체 10점 문제
문자 인코딩·직렬화·엔디언의 차이와 상호운용 통제를 설명하시오.
요구어는 설명이다. 문자, 숫자 바이트순서, 필드 구조가 각각 어떤 계약인지와 왕복 검증을 연결한다.
10점 풀이 방향과 모범답안 보기
10점 답안 목차
- 문자 인코딩과 UTF-8
- 엔디언과 다바이트 정수
- 직렬화와 필드 경계
- 형식·길이·버전 계약
- 왕복·오류 입력 검증
10점 답안 도식
문자·숫자·필드의 각 규칙으로 바이트열을 만들고, 수신자가 같은 계약으로 원래 값을 복원하는 과정을 대조한다. 형식·인코딩·길이·바이트 순서와 오류 입력을 함께 검증한다.
모범답안 축약본: 경계를 넘는 바이트의 의미를 고정한다
문제: 문자 인코딩·직렬화·엔디언의 차이와 상호운용 통제를 설명하시오. 문자 인코딩은 문자와 바이트열의 대응 규칙이고, 직렬화는 객체·목록 같은 구조화된 값을 전송·저장 가능한 형식으로 바꾸는 규칙이며, 엔디언은 여러 바이트로 된 수를 낮은 주소부터 어떤 순서로 놓는지 정한다. 문자열 가, 32비트 정수, 주문 객체가 같은 메시지에 있어도 세 규칙은 각각 필요하다. 송신자는 형식 버전, 문자 인코딩, 필드 길이·형, 수의 바이트 순서를 정하고 수신자는 전체 크기·깊이·범위를 검증한 뒤 역직렬화한다. UTF-8의 문자 수와 바이트 수를 혼동하거나 길이 없이 필드를 붙이고, 검증하지 않은 길이값만큼 메모리를 할당하면 손상·거부서비스가 생긴다. 경계 계약과 대표·경계·오류 바이트의 왕복 시험으로 의미 일치와 안전한 실패를 검증한다.
출처와 적용 경계
UTF-8의 1~4바이트 인코딩과 불완전·잘못된 바이트열 처리는 RFC 3629 §3·§4·§10, UTF-8과 UTF-16·UTF-32 코드 단위의 바이트 순서 차이는 Unicode 공식 UTF FAQ의 비교표와 BE/LE 설명으로 확인할 수 있다. A가·258과 길이 필드 형식은 자체 예이며 특정 표준 메시지 형식이 아니다.
UTF-8 바이트와 다바이트 정수 순서는 공개 규격으로 검증할 수 있는 안정된 기초다. 본문 메시지 형식과 길이필드는 자체 교육 예이며 특정 프로토콜의 실제 wire format을 재현하지 않는다.
30초 정리
- 문자 인코딩은 문자와 바이트, 엔디언은 여러 바이트의 순서, 직렬화는 구조화된 값과 바이트열을 연결한다.
- 전송 바이트가 같아도 이 계약 중 하나가 다르면 글자·숫자·필드 의미가 달라진다.
- 경계를 넘을 때는 형식·인코딩·순서·길이·버전·오류 처리까지 명시한다.
자기교정과 조건 변경
| 잘못 쓴 답 | 왜 틀렸는가 | 고쳐 쓸 내용 | 복습 |
|---|---|---|---|
| A가 두 글자이므로 UTF-8도 2바이트다 | 문자 수와 바이트 수를 혼동했다 | 이 예에서는 1+3=4바이트다 | ES-1 |
| 01 02와 02 01은 언제나 같은 숫자다 | 엔디언 계약을 생략했다 | 합의한 순서로 조립해야 258을 복원한다 | ES-1 |
| UTF-8이 맞으면 필드 경계도 자동으로 안다 | 인코딩과 직렬화를 혼동했다 | 길이·태그·스키마 등 필드 규칙이 별도다 | 세 규칙 |
| 역직렬화는 입력 길이를 그대로 믿어도 된다 | 외부 입력의 크기·구조 위험을 무시했다 | 전체 크기·깊이·필드 범위를 검증한다 | 실패 |
| 엔디언이 다르면 UTF-8 문자열 바이트를 뒤집는다 | 인코딩과 코드 단위를 구분하지 않았다 | UTF-8은 바이트 순서를 유지하고 UTF-16·UTF-32는 다바이트 코드 단위의 배치도 확인한다 | 정의 |
문자열이 AAA라면? UTF-8에서 각 A가 1바이트이므로 이 예에서는 문자 수와 바이트 수가 모두 3이지만 이를 일반 규칙으로 확대하지 않는다.
id가 한 바이트 값이면? 한 바이트 자체에는 앞뒤 바이트 순서가 없으므로 엔디언 차이가 드러나지 않는다.
길이필드가 실제 남은 바이트보다 크면? 부족한 입력을 정상 값으로 채우지 않고 형식 오류로 거부한다.