한글 바이트 계산 원리 — 2바이트일까 3바이트일까

같은 한글인데 왜 2바이트라고도 하고 3바이트라고도 할까

글자를 저장하는 방식(인코딩)이 다르기 때문입니다. 컴퓨터는 글자를 숫자로 바꿔 저장하는데, 어떤 규칙표를 쓰느냐에 따라 같은 글자가 차지하는 용량이 달라집니다. 한글 기준으로 두 규칙만 기억하면 됩니다.

• EUC-KR 계열: 한글 1자 = 2바이트 — 문자메시지, 게임 닉네임 제한, 오래된 전산 시스템이 쓰는 방식. 영문·숫자는 1바이트.
• UTF-8: 한글 1자 = 3바이트 — 요즘 웹과 앱 대부분이 쓰는 방식. 영문·숫자는 여기서도 1바이트.

그래서 “바이트 제한”을 만나면 먼저 어느 쪽 기준인지부터 확인해야 합니다. 같은 “20바이트 제한”이 EUC-KR이면 한글 10자, UTF-8이면 한글 6자입니다.

문자메시지가 중간에 끊기는 이유 — SMS 90바이트

휴대폰 단문 문자(SMS)는 보통 90바이트가 한도입니다. EUC-KR 기준이라 한글로 약 45자, 영문으로 90자입니다. 이 한도를 넘으면 장문(LMS)으로 자동 전환되는데, 요금제에 따라 과금이 달라질 수 있습니다. 한글과 영문을 섞어 쓰면 계산이 헷갈리므로, 자동응답 문자나 광고 문구처럼 한도가 중요한 문자는 바이트를 직접 세보는 게 확실합니다.

게임 닉네임 “12바이트 이내”의 뜻

게임이나 커뮤니티의 닉네임 제한은 EUC-KR 기준 바이트로 걸려 있는 경우가 많습니다. 12바이트 제한이면 한글 6자 또는 영문 12자, 혹은 “한글 4자 + 영문 4자”처럼 섞어 쓸 수 있습니다. 한글·영문 조합 닉네임이 자꾸 거부된다면 바이트 초과가 원인일 가능성이 큽니다.

왜 하필 2바이트와 3바이트인가

규칙표가 담는 글자 수가 다르기 때문입니다. EUC-KR은 한국어를 쓰려고 만든 표라서 한글 완성형 11,172자와 한자 일부만 담으면 됐습니다. 2바이트면 이론상 65,536자를 구분할 수 있으니 충분했습니다.

UTF-8은 전 세계 문자를 하나의 표에 담습니다. 글자마다 번호(코드포인트)를 붙이고, 번호가 클수록 더 많은 바이트를 씁니다. 영문과 숫자는 번호가 작아 1바이트, 한글 완성형은 번호 범위가 커서 3바이트가 됩니다. 일본어 가나와 한자도 같은 이유로 3바이트입니다.

정리하면 EUC-KR은 “한국어만 쓸 거니까 짧게”, UTF-8은 “모든 언어를 섞어 써야 하니 조금 길게”를 택한 결과입니다. 요즘 새로 만드는 시스템은 거의 전부 UTF-8입니다. 한글 2바이트 기준을 마주쳤다면 대체로 오래된 시스템이거나 통신 규격입니다.

이모지는 4바이트, 그래서 더 빨리 잘린다

이모지는 한글보다 번호가 더 큰 영역에 있어서 UTF-8에서 보통 4바이트를 씁니다. 그런데 화면에 이모지 하나로 보인다고 항상 4바이트인 것도 아닙니다.

• 가족 이모지나 피부색이 적용된 이모지는 여러 글자를 이음문자로 붙여 만든 것이라 20바이트를 넘기도 합니다.
• 국기 이모지는 알파벳 두 글자에 해당하는 특수 문자 두 개의 조합이라 8바이트입니다.

닉네임이나 소개글에 이모지를 넣었다가 “글자 수는 남았는데 더 입력이 안 되는” 경우가 이것 때문입니다. 바이트 제한이 있는 칸에서는 이모지 하나가 한글 한 자보다 비쌉니다.

개발자·실무자가 만나는 바이트 제한

엑셀 업로드나 외부 시스템 연동에서 “글자수는 맞는데 잘린다”면 십중팔구 글자수 제한이 아니라 바이트 제한입니다. 헷갈리는 이유는 데이터베이스마다 세는 단위가 다르기 때문입니다.

• MySQL·MariaDB — VARCHAR(100)은 글자 100자를 뜻합니다. 다만 저장 공간은 문자셋에 따라 커지고, utf8mb4는 글자당 최대 4바이트를 잡습니다.
• PostgreSQL — varchar(100) 역시 글자 100자 기준입니다.
• Oracle — VARCHAR2(100)은 기본이 바이트입니다. UTF-8 환경이면 한글 33자에서 가득 찹니다. 글자 기준으로 쓰려면 VARCHAR2(100 CHAR)처럼 따로 적어야 합니다.

그래서 같은 설계를 오라클에서 MySQL로 옮기거나 그 반대로 옮길 때 데이터가 잘리는 사고가 납니다. 오류 메시지에 적힌 숫자가 글자 수인지 바이트인지부터 확인하세요.

통신 규격에서도 자주 만납니다. 카드 결제 전문, 은행 이체 전문, 기관 간 연계 규격은 아직 EUC-KR 2바이트 기준으로 자리 길이를 정해 둔 경우가 많습니다. 이런 곳에 UTF-8 문자열을 그대로 넣으면 자리가 밀려 전체 전문이 깨집니다.

맥에서 만든 파일 이름이 유난히 긴 이유

한글은 “한”처럼 완성된 한 글자로 저장할 수도 있고, “ㅎ + ㅏ + ㄴ”처럼 자모를 나눠 저장할 수도 있습니다. 화면에는 똑같이 보이지만 용량은 다릅니다. 완성형은 3바이트, 자모를 나눈 쪽은 자모마다 3바이트씩 붙어 9바이트가 됩니다.

맥의 파일 이름은 자모를 나눠 저장하는 방식을 쓰기 때문에, 맥에서 만든 한글 파일을 윈도우나 웹 서버로 옮기면 이름이 깨지거나 길이 제한에 걸리는 일이 생깁니다. 파일명이 멀쩡해 보이는데 업로드만 실패한다면 이 문제를 의심해 보세요.

내 텍스트는 몇 바이트일까

글자수 세기에 텍스트를 붙여넣으면 EUC-KR 기준(한글 2바이트)과 UTF-8 기준(한글 3바이트) 바이트를 동시에 보여줍니다. 문자·닉네임은 2바이트 값을, 웹·데이터베이스는 UTF-8 값을 읽으면 됩니다.

자주 묻는 것

공백과 줄바꿈도 바이트를 차지하나요?

차지합니다. 공백은 1바이트입니다. 줄바꿈은 윈도우에서 2바이트, 맥과 리눅스에서 1바이트로 세는 경우가 많습니다. 문자 발송처럼 한도가 빠듯한 곳에서는 줄바꿈을 줄이는 것만으로도 몇 바이트를 아낄 수 있습니다.

글자 수 제한과 바이트 제한, 어느 쪽이 더 깐깐한가요?

한글만 쓴다면 바이트 제한이 더 깐깐합니다. 100자 제한은 한글 100자를 허용하지만, UTF-8 100바이트 제한은 한글 33자에서 막힙니다. 반대로 영문만 쓴다면 둘이 거의 같습니다.

“2,000바이트”라고만 적혀 있으면 어느 기준인가요?

문자 발송, 관공서 전산, 금융 전문이면 EUC-KR 2바이트로 보는 편이 안전합니다. 웹 서비스나 API 문서라면 UTF-8입니다. 확실치 않으면 더 불리한 쪽(UTF-8)으로 맞춰 두면 잘릴 일이 없습니다.

바이트를 줄이는 가장 쉬운 방법은?

한글을 영문·숫자로 바꿀 수 있는 부분을 바꾸는 것입니다. 한글 한 자가 2~3바이트인 반면 영문·숫자는 1바이트라 효과가 큽니다. 긴 URL이 들어간다면 단축 주소를 쓰는 것도 방법입니다.

정리

• 문자메시지·닉네임·옛 시스템 → 한글 2바이트 (EUC-KR)
• 웹·앱·데이터베이스 → 한글 3바이트 (UTF-8)
• 이모지는 4바이트 이상, 조합형 이모지는 20바이트를 넘기도 함
• SMS 한도 90바이트 ≈ 한글 45자, 초과하면 장문 전환
• 제한이 “자”인지 “바이트”인지, 바이트라면 어느 기준인지부터 확인