한글·이모지·줄바꿈에서 글자 수와 UTF-8 바이트가 달라지는 이유

PROBLEM

왜 이 구분이 필요한가

화면에서 한 글자로 보이는 이모지는 여러 Unicode code point의 조합일 수 있고, 한글 한 글자는 UTF-8에서 보통 3바이트입니다. 그래서 자기소개서의 글자 제한, API의 byte 제한, SMS 과금 단위를 같은 숫자로 다루면 오차가 생깁니다. 줄바꿈도 운영체제에 따라 CRLF나 LF로 저장되지만 줄 수와 byte 수의 목적은 서로 다릅니다.

PROCEDURE

실무 적용 순서

먼저 제출처가 공백 포함 글자, 공백 제외 글자, UTF-8 byte 중 무엇을 제한하는지 확인합니다. 원문을 도구에 붙여넣고 다섯 지표를 각각 기록합니다. 공백 제외 값은 Unicode 공백을 제거한 뒤 세며, 단어 수는 형태소 분석이 아니라 공백 덩어리를 나누는 기준입니다. 이모지가 많은 문서는 실제 제출 서비스의 미리보기와 비교하고 API라면 전송 직전 UTF-8 byte 제한도 검증합니다.

BASIS

계산과 검증 근거

가능한 브라우저에서는 Intl.Segmenter가 grapheme cluster 단위로 사용자가 인식하는 글자를 나눕니다. UTF-8 byte는 TextEncoder 결과 배열의 길이입니다. 단어는 Unicode 공백을 기준으로 분리하고 줄은 CRLF, CR, LF를 한 줄 경계로 처리합니다. Segmenter가 없는 브라우저에서는 Array.from fallback을 사용하므로 결합 이모지 수가 달라질 수 있습니다.

LIMITS

지원 범위와 한계

입력 길이에 명시적 상한은 없고 브라우저 메모리에 의존합니다. 단어 수는 한국어 형태소나 문장 의미를 분석하지 않습니다. UTF-8 byte는 GSM-7, UCS-2 같은 SMS 인코딩과 다릅니다. 플랫폼이 자체 정규화, URL 단축, 금칙 문자 규칙을 쓰면 도구 결과와 다를 수 있습니다.

WORKED EXAMPLES

직접 재현할 예제