글자수 세기

공백 포함은 띄어쓰기와 줄바꿈까지 모두 센 값이고, 공백 제외는 둘 다 뺀 값입니다. 예를 들어 “안녕 하세요”는 공백 포함 6자, 공백 제외 5자, UTF-8로 16바이트입니다.

제출할 곳이 “공백 포함 500자 이내”처럼 기준을 적어 두었다면 그 기준의 숫자만 보면 됩니다. 기준이 적혀 있지 않으면 공백 포함으로 맞추는 편이 안전합니다. 공백 제외 글자수는 공백 포함보다 클 수 없어서, 공백 포함 500자 안에 든 글은 공백 제외로 세도 500자 안에 듭니다.

공백 제외는 띄어쓰기 습관과 상관없이 내용 분량만 비교할 때 씁니다. 같은 문장을 띄어 쓰든 붙여 쓰든 공백 제외 글자수는 같습니다.

채용 사이트나 제출 양식마다 줄바꿈을 1자로 세는지, 2자로 세는지, 아예 빼는지가 다를 수 있습니다. 그래서 이 도구는 줄바꿈을 1자로 센 “공백 포함”과 줄바꿈만 뺀 “줄바꿈 제외”를 나눠 보여 줍니다. 제출 화면에 글자수 표시가 있으면 마지막에는 그 숫자로 한 번 더 확인하세요.

웹 입력란 안에서는 줄바꿈이 1자입니다. HTML 표준은 textarea의 maxlength를 셀 때 줄바꿈을 한 글자로 정규화한다고 정해 두었습니다.

그런데 같은 표준은 폼을 전송할 때 줄바꿈을 CR과 LF 두 문자로 바꾸도록 정합니다. 서버가 받은 값을 그대로 세면 줄바꿈 하나가 2자가 될 수 있습니다. 입력란에서는 500자였는데 제출한 뒤 초과로 나올 수 있는 이유입니다. 줄바꿈 4개로 문단 5개를 나눈 글이라면, 2자로 세는 곳에서는 4자가 늘어납니다.

이 도구는 사람이 한 글자로 보는 단위로 셉니다. 브라우저의 Intl.Segmenter가 유니코드 표준 UAX #29 규칙으로 글자 경계를 나눠 줍니다. 가족 이모지 👨‍👩‍👧‍👦는 사람 넷과 그 사이를 잇는 보이지 않는 문자(ZWJ) 셋, 모두 코드 포인트 7개로 되어 있지만 화면에는 한 글자라서 1자로 셉니다.

반면 JavaScript의 length와 입력란의 maxlength는 UTF-16 코드 단위로 셉니다. 같은 가족 이모지가 11자가 됩니다. maxlength로 막는 입력란은 이 도구보다 먼저 한도에 닿을 수 있어서, 글에 이모지나 결합 문자가 있으면 그 숫자도 따로 알려 줍니다.

마지막 줄처럼 한글도 초성·중성·종성을 따로 적은 형태(NFD)로 들어오면 코드 포인트가 3개입니다. 화면에는 똑같이 “한”으로 보이니 이 도구는 1자로 세지만, UTF-8 바이트는 완성형 “한”의 3바이트보다 세 배 많습니다.

바이트는 글자를 저장하거나 보낼 때 차지하는 크기이고, 인코딩마다 다릅니다. UTF-8은 영문·숫자·기호 같은 ASCII 문자를 1바이트, 한글 음절을 3바이트, U+10000 이후 문자(이모지 대부분)를 4바이트로 씁니다(RFC 3629). “안녕 하세요”가 16바이트인 것은 한글 5자 × 3바이트에 띄어쓰기 1바이트를 더한 값입니다.

오래된 시스템이 쓰는 EUC-KR과 CP949는 한글 한 글자를 2바이트로 씁니다. “한글 2바이트” 칸은 ASCII를 1바이트, 나머지 문자를 모두 2바이트로 세서 같은 글이 11바이트로 나옵니다. EUC-KR에는 이모지가 없으므로 이모지가 섞인 글에서는 이 숫자를 어림값으로만 보세요.

데이터베이스 칸의 길이도 기준이 다릅니다. MySQL의 VARCHAR(100)은 글자 100개를 뜻하지만, Oracle의 VARCHAR2(100)은 BYTE·CHAR 한정자를 적지 않으면 NLS_LENGTH_SEMANTICS 설정에 따라 100바이트를 뜻할 수 있습니다. 바이트 기준 칸에 UTF-8 한글 100자를 넣으려면 300바이트가 필요합니다.

문단은 내용이 있는 줄 하나를 한 문단으로 셉니다. 빈 줄은 세지 않습니다. 입력란에서는 엔터 한 번으로 문단을 나누는 일이 많아서 이 기준을 골랐습니다. 단어 수는 띄어쓰기와 줄바꿈으로 나뉜 덩어리 수라서, 한국어에서는 어절 수와 같습니다.

이 블로그도 글을 올리기 전에 문단 길이를 셉니다. 지금 게시 전 검사 스크립트는 한 문단이 150자를 넘으면 쪼개라고 표시하고, 2026년 8월 29일에 공개 글을 다시 검사했을 때는 긴 문단이 138건 나왔습니다. 이 검사를 고치다가 macOS 기본 awk가 글자 대신 바이트를 세서 한글 한 글자를 3자로 잡은 일도 있었습니다. 바이트와 글자를 섞어 세면 한글 문단이 세 배로 부풀어 기준이 소용없어집니다. 검사를 만든 과정은 글쓰기 규칙은 문서가 아니라 게이트여야 합니다에 적었습니다. 위젯의 “가장 긴 문단”도 같은 이유로 넣었습니다.