한 줄 요약: UTF-8은 ASCII 호환·가변 길이(1~4바이트)·자기 동기화라는 세 가지 설계 덕분에 기존 시스템을 깨지 않고 전 세계 문자를 담아 웹의 99% 표준이 됐다.

2026년 기준 전 세계 웹페이지의 99%가 UTF-8을 사용합니다. 왜 하필 UTF-8일까요? 인코딩 선택은 단순한 취향이 아니라 호환성, 공간, 안전성의 종합적인 점수입니다. 풀어 설명하겠습니다.

ASCII 호환: 가장 큰 장점

UTF-8의 가장 중요한 설계 목표는 ASCII와의 완벽한 호환이었습니다. ASCII 문자(영문 알파벳, 숫자, 기호)는 UTF-8에서도 1바이트로 동일하게 인코딩됩니다. 즉, 기존 ASCII 소프트웨어는 UTF-8 텍스트도 그대로 처리할 수 있습니다. 이 ‘기존 시스템에 거슬리지 않는’ 설계가 도입의 가장 큰 장벽을 낮추었습니다.

가변 길이: 1~4바이트, 문자에 따라 다르다

UTF-8은 가변 길이 인코딩입니다. 문자의 코드 포인트(번호)에 따라 바이트 수가 달라집니다.

범위	바이트 수	예시
U+0000~U+007F	1바이트	영문 알파벳(A = 0x41)
U+0080~U+07FF	2바이트	라틴 확장, 그리스, 키릴
U+0800~U+FFFF	3바이트	한글, 한자, 일본어
U+10000~U+10FFFF	4바이트	이모지, 고대 문자

바이트 패턴: 앞부분이 길이를 알려준다

UTF-8 바이트의 첫 비트를 확인하면 이 바이트가 문자의 시작인지 연속인지를 알 수 있습니다.

• 0xxxxxxx: 1바이트 문자 (ASCII)
• 110xxxxx: 2바이트 문자의 시작
• 1110xxxx: 3바이트 문자의 시작
• 11110xxx: 4바이트 문자의 시작
• 10xxxxxx: 연속 바이트(continuation byte)

이 구조 덕분에 자기 동기화(self-synchronizing)가 가능합니다. 데이터 스트림의 중간부터 읽기 시작해도 다음 문자의 시작 위치를 찾을 수 있습니다. 손상된 바이트를 건너뛰고 복구할 수 있다는 의미입니다.

공간 효율: 영어는 1바이트, 한글은 3바이트

영어 텍스트는 ASCII와 동일하게 1바이트 per 문자이므로 UTF-8이 가장 효율적입니다. 한글은 3바이트 per 문자로 UTF-16(2바이트)보다 큽니다. 하지만 웹페이지의 대부분은 HTML 태그, 코드, 영어 단어가 혼합되어 있어, 전체 용량에서 영어 비율이 더 크게 작용합니다.

왜 UTF-16이 아닌가: 엔디안 문제, ASCII 비호환

UTF-16은 기본적으로 2바이트 고정이므로 CJK 문자에 공간 효율이 좋습니다. 하지만 두 가지 문제가 있습니다:

• 엔디안(endianness): 바이트 순서가 시스템마다 달라서 BOM(바이트 순서 표시)이 필요합니다. UTF-8은 바이트 단위이므로 순서 문제가 없습니다.
• ASCII 비호환: 영문도 2바이트가 되어 기존 ASCII 소프트웨어와 호환되지 않습니다.

어떻게 연결되는가

한 줄로 요약하면: ASCII 호환, 가변 길이, 자기 동기화(1바이트, 1~4바이트, 바이트 패턴)의 세 가지 설계가 결합하여, 기존 시스템에 거슬리지 않으면서 전 세계 문자를 표현할 수 있게 만든 인코딩입니다. ‘가장 우수한’ 것이 아니라 ‘가장 거슬리지 않는’ 것이 UTF-8의 진짜 승리입니다.

출처: 위키백과: UTF-8 · RFC 3629: UTF-8

이미지: Callidus, Wikimedia Commons (CC-BY-SA 3.0) — 원본