바이트 수 계산기

바이트¹ 수 제한이 있어서 한도에 맞춰 썼는데, 입력창에 초과라고 뜨는 경우가 있습니다. 또 다른 사이트에서 세어보면 숫자가 또 달라집니다. 바이트 수 계산기는 입력한 글이 인코딩 방식별로 몇 바이트를 차지하는지 계산하는 도구입니다. 한글은 EUC-KR에서 2바이트, UTF-8에서 3바이트를 차지하기 때문에 어떤 기준으로 세느냐에 따라 결과가 1.5배까지 벌어집니다. 아래 바이트 수 계산기는 세 가지 인코딩을 동시에 확인할 수 있습니다.

바이트 수 계산기란

바이트 수 계산기는 글자 개수가 아니라 저장 용량을 세는 도구입니다. 글자 수 세기는 ‘몇 글자인가’를 묻고, 바이트 계산은 ‘컴퓨터가 몇 칸을 쓰는가’를 묻습니다. 문자 발송, 데이터베이스 입력칸, 일부 지원서 양식이 바이트로 한도를 거는 이유가 여기에 있습니다.

바이트 수 계산기가 한 화면에서 처리하는 항목은 네 가지입니다. 첫째, EUC-KR·UTF-8·UTF-16 바이트와 글자 수를 동시에 계산합니다. 둘째, 발송 과정에서 깨질 수 있는 문자를 찾아 종류별로 표시합니다. 셋째, 한도를 넘긴 글을 원하는 단위로 자르거나 여러 건으로 나눕니다. 넷째, 알림톡처럼 변수를 쓰는 문구는 실제 값이 들어간 뒤의 길이를 계산합니다.

확인 항목	계산 내용
인코딩 4종	EUC-KR, UTF-8, UTF-16 바이트와 순수 글자 수
위험 문자 진단	이모지, 보이지 않는 문자, 분리된 한글 자모
자동 잘라내기	글자·어절·문장 단위 절단, 여러 건 분할
변수 치환	변수에 값이 들어간 뒤의 최종 길이

한글 1글자는 몇 바이트인가요?

한글 1글자는 EUC-KR에서 2바이트, UTF-8에서 3바이트, UTF-16에서 2바이트를 차지합니다. 하나의 정답이 없고 어떤 인코딩²을 쓰는 자리인지에 따라 달라집니다. ‘안녕하세요’ 다섯 글자를 바이트 수 계산기에 넣으면 EUC-KR 10바이트, UTF-8 15바이트, UTF-16 10바이트로 나옵니다.

문자 발송에 쓰는 EUC-KR은 왜 2바이트인가요?

EUC-KR은 한글과 한자에 2바이트, 영문·숫자·공백·줄바꿈에 1바이트를 배정하는 방식입니다. 유니코드가 널리 쓰이기 전에 만들어진 규칙이라 한국어 문자만 담습니다. 기업 문자 발송 회선과 오래된 게시판, 일부 지원서 입력칸이 지금도 이 기준을 씁니다. 한글만 45자를 쓰면 정확히 90바이트가 되는 계산이 여기서 나옵니다.

웹과 데이터베이스가 쓰는 UTF-8은 왜 3바이트인가요?

UTF-8은 전 세계 문자를 하나의 규칙으로 담기 위해 글자마다 1~4바이트를 가변으로 씁니다. 영문과 숫자는 1바이트를 유지하지만 한글은 3바이트가 필요합니다. 웹 페이지, 대부분의 데이터베이스, API 파라미터가 이 방식입니다. 같은 ‘안녕하세요’가 문자 발송에서는 10바이트, 웹 서버에서는 15바이트로 잡히는 이유입니다.

이모지는 왜 계산기마다 1자와 2자로 갈리나요?

이모지는 UTF-8에서 4바이트를 쓰고, 자바스크립트 내부에서는 두 칸으로 나뉘어 저장되기 때문입니다. 많은 글자수 세기 도구가 이 내부 저장 값을 그대로 읽어서 👍 하나를 2글자로 셉니다. 가족 이모지처럼 여러 기호가 합쳐진 문자는 8글자로 세기도 합니다. 이 바이트 수 계산기는 사람이 보는 단위로 묶어서 세기 때문에 이모지 하나는 1글자로 표시합니다.

사이트마다 바이트 계산 결과가 다른 이유

도구마다 잡아 놓은 인코딩 기준과 공백 처리 방식이 다르기 때문입니다. 어느 쪽이 틀린 것이 아니라, 서로 다른 자리를 기준으로 계산하고 있는 것입니다. 그래서 숫자를 비교하기 전에 그 도구가 무슨 기준을 쓰는지 확인해야 합니다.

인코딩 기준이 다릅니다

한글을 2바이트로 세는 도구는 EUC-KR 기준이고, 3바이트로 세는 도구는 UTF-8 기준입니다. 한글 1,000자짜리 글을 넣으면 앞쪽은 2,000바이트, 뒤쪽은 3,000바이트를 보여줍니다. 어느 쪽 숫자가 필요한지는 글을 넣을 입력창이 정합니다. 문자 발송이면 EUC-KR, 웹 서비스나 데이터베이스면 UTF-8을 보면 됩니다.

공백과 줄바꿈 처리가 다릅니다

공백 포함과 공백 제외는 같은 글에서 10~20% 차이를 만듭니다. 줄바꿈도 1바이트로 세는 곳과 2바이트로 세는 곳이 나뉩니다. 지원서 양식은 대체로 공백을 포함해 세지만, 기관과 문항에 따라 다르게 안내하기도 합니다. 제출 전에 해당 지원서 화면의 글자 수 안내 문구를 직접 확인하는 편이 안전합니다.

워크드 예시로 확인해 보겠습니다. 지원서 한 문항이 4,000바이트로 제한된 경우를 계산해 보겠습니다. 한글만 쓴다면 2바이트씩이므로 정확히 2,000자입니다. 그런데 실제 문장에는 공백과 숫자가 섞여 있어 평균이 글자당 1.6~1.7바이트로 내려갑니다.

실제 자기소개서 문체의 예시 문단을 바이트 수 계산기에 넣어보면 156자에 261바이트로, 글자당 1.673바이트가 나왔습니다. 이 비율을 적용하면 4,000바이트는 공백 포함 약 2,390자에 해당합니다. 흔히 ‘4,000바이트는 2,300자 정도’라고 말하는 근거가 이 계산입니다.

바이트 수 계산기 사용 방법

기준을 먼저 고르고 본문을 붙여 넣으면 나머지는 자동으로 계산됩니다. 계산 버튼을 누를 필요가 없고 입력하는 동안 숫자가 바뀝니다.

기준을 먼저 선택합니다

상단 칩에서 SMS 90byte, LMS³·MMS 2,000byte, 알림톡 1,000자, DB 255byte, 직접 입력 중 하나를 고릅니다. 칩을 누르면 바로 아래에 그 기준이 어떤 상황에 쓰이는지 설명이 함께 나옵니다. 위 다섯 가지에 없는 한도라면 직접 입력을 선택하고 계산 기준과 숫자를 넣으면 됩니다.

미리보기에서 잘리는 지점을 확인합니다

본문을 넣으면 미리보기 영역에 두 가지 색이 나타납니다. 붉은 배경은 한도를 넘긴 구간이고, 노란 배경은 발송이 깨질 수 있는 문자입니다. 숫자만 보면 몇 바이트를 넘겼는지만 알지만, 색으로 보면 어느 문장에서 잘리는지 바로 보입니다. 문장 중간이 잘리는지 문장 끝에서 잘리는지에 따라 고칠 방법이 달라집니다.

지표 여섯 개를 나누어 읽습니다

상단 검은 카드는 선택한 기준의 사용량과 남은 용량을 보여줍니다. 그 아래 카드 여섯 개는 EUC-KR, UTF-8, UTF-16 바이트와 글자 수, 공백 제외 글자 수, 줄과 어절 수입니다. 지원서를 쓸 때는 글자 수와 공백 제외 값을, 문자를 보낼 때는 EUC-KR 값을 보면 됩니다.

문자 90바이트는 왜 한글 45자까지만 들어가나요?

단문 문자의 한도 90바이트를 한글 1자당 2바이트로 나누면 45자가 되기 때문입니다. 영문과 숫자, 공백은 1바이트라서 섞어 쓰면 글자 수는 더 늘어납니다. 90바이트를 넘기면 단문이 자동으로 장문으로 바뀌고, 장문은 단문보다 건당 단가가 높습니다.

실제 문구로 확인해 보겠습니다. “[뉴스컬리] 8월 정기 점검 안내드립니다. 8월 15일 새벽 2시부터 4시까지 서비스 이용이 제한됩니다.”는 58자이지만 EUC-KR 기준 94바이트입니다. 4바이트를 넘겨서 장문으로 전환되는 상태입니다. 같은 내용을 “[뉴스컬리] 8월 정기 점검 안내입니다. 15일 새벽 2시~4시 서비스가 중단됩니다.”로 줄이면 75바이트가 되어 단문 안에 들어갑니다. 대괄호로 감싼 발신 표기와 날짜 표기만 정리해도 20바이트 가까이 줄어듭니다.

계산기 상단에는 ’90byte를 4byte 넘겨 LMS로 전환됩니다. 한글 2자를 줄이면 SMS로 보낼 수 있습니다’처럼 줄여야 할 글자 수가 함께 나옵니다. 여러 건을 대량으로 보내는 상황이라면 이 두 글자가 전체 비용을 가르는 기준선이 됩니다.

이모지를 넣은 문자가 깨지는 이유는 무엇인가요?

기업 문자 발송 회선이 쓰는 EUC-KR에 이모지가 아예 들어 있지 않기 때문입니다. 규칙에 없는 문자를 만나면 물음표로 바꾸거나 그냥 지웁니다. 발송 화면에서는 멀쩡히 보이다가 받는 사람 휴대폰에서만 깨져 보이는 이유입니다.

EUC-KR에 없는 문자는 물음표로 바뀝니다

컬러 이모지는 EUC-KR 규격에 없어 문자 회선을 통과하지 못합니다. 반면 ★, ※, ①, ℃ 같은 기호는 EUC-KR에 포함돼 있어 정상 발송됩니다. 바이트 수 계산기의 문자 진단 탭은 이 둘을 구분해서 위험한 문자만 골라 보여줍니다. 한자는 자주 쓰는 4천여 자만 포함돼 있어 드문 한자는 발송 전 테스트가 필요합니다.

복사·붙여넣기로 보이지 않는 문자가 딸려 옵니다

워드나 한글, 웹 페이지에서 복사한 글에는 눈에 보이지 않는 문자가 섞여 들어옵니다. 폭이 없는 공백이나 서식 제어 문자가 대표적입니다. 화면에는 아무것도 안 보이지만 바이트는 차지하고 발송 검증에서 실패하기도 합니다. 진단 탭에서 이런 문자는 개수와 함께 별도로 표시됩니다.

맥에서 복사한 한글은 용량이 3배가 됩니다

맥에서 만든 파일명이나 일부 텍스트는 한글이 자음과 모음으로 분리된 상태로 저장됩니다. ‘한’ 한 글자가 ㅎ, ㅏ, ㄴ 세 조각으로 나뉘어 UTF-8 기준 3바이트가 아닌 9바이트를 차지합니다. 화면에는 똑같이 ‘한’으로 보이기 때문에 눈으로는 찾을 수 없습니다. 진단 탭의 ‘위험 문자 정리하기’ 버튼을 누르면 분리된 자모를 하나로 합치고 보이지 않는 문자와 이모지를 함께 지웁니다.

• 자소분리: 한글 한 글자가 초성·중성·종성으로 쪼개져 저장된 상태를 말합니다.

한도를 넘겼을 때 어떻게 줄이거나 나누나요?

자동 잘라내기 탭에서 자르는 단위와 처리 방식을 고르면 결과가 바로 나옵니다. 직접 지워가며 바이트를 맞추는 과정을 건너뛸 수 있습니다.

글자·어절·문장 중 자르는 단위를 고릅니다

글자 단위는 한도에 정확히 맞추지만 단어 중간에서 끊깁니다. 어절 단위는 띄어쓰기를 기준으로 물러나서 자르고, 문장 단위는 마침표 앞에서 끊습니다. 앞의 점검 안내 문구를 90바이트에 맞춰 글자 단위로 자르면 ‘제한됩’에서 끊기고 89바이트를 씁니다. 문장 단위로 자르면 문장이 온전히 남는 대신 남는 용량이 늘어납니다.

순번을 붙여 여러 건으로 나눕니다

처리 방식에서 ‘여러 건으로 나누기’를 고르면 한도에 맞춰 자동 분할됩니다. 순번 표기를 체크하면 각 건 끝에 (1/3) 같은 표시가 붙습니다. 이때 순번이 차지하는 6바이트를 미리 빼고 계산하기 때문에, 순번을 붙여도 각 건이 90바이트를 넘지 않습니다. 순번을 붙인 뒤에 한도를 넘겨 발송이 실패하는 상황을 막기 위한 처리입니다.

변수는 값이 들어간 뒤의 길이로 확인합니다

알림톡처럼 #{이름} 형태의 변수를 쓰는 문구는 검수 시점과 발송 시점의 길이가 다릅니다. 변수⁴ 자리에 실제 이름이나 주문번호가 들어가면서 길어지기 때문입니다. 변수 치환 탭에 예시 값을 넣으면 최종 길이와 초과 여부가 계산됩니다. 변수마다 ‘더 쓸 수 있는 여유’도 함께 나오므로, 이름이 긴 고객까지 감안해 문구를 설계할 수 있습니다.

FAQ

최신 글

1. 바이트(byte): 컴퓨터가 문자 하나를 저장할 때 쓰는 용량 단위이며, 영문 1글자가 보통 1바이트를 차지합니다. ↩︎
2. 인코딩: 사람이 읽는 문자를 컴퓨터가 저장할 수 있는 숫자로 바꾸는 규칙입니다. ↩︎
3. LMS: 90바이트를 넘는 문자를 보낼 때 쓰는 장문 문자이며, 본문 한도는 2,000바이트입니다. ↩︎
4. 변수: 발송할 때 고객별 정보로 바뀌는 자리이며, 알림톡에서는 #{이름} 같은 형태로 씁니다. ↩︎