공백포함 글자수 — 그 폼이 말하는 숫자는 어느 쪽인가

글은 하나인데 셈은 셋

공백 포함이 가장 큰 숫자이고 가장 흔한 기본값입니다. 글자 하나하나, 낱말 사이의 공백, 그리고 대개 줄바꿈까지 한 자로 셉니다.

공백 제외는 그 사이를 뺍니다. 보통의 글에서는 15~20퍼센트쯤 작아지는데, 들어가느냐 잘리느냐를 가르기에 충분한 차이입니다.

바이트는 아예 다른 잣대입니다. 눈에 보이는 기호가 아니라 글이 차지하는 저장 공간을 셉니다. 영문에서는 둘이 거의 같지만 한글·일본어·중국어는 다릅니다 — 한 글자가 보통 3바이트라서, 500바이트 제한은 500자가 아니라 166자쯤을 뜻하게 됩니다.

네 번째 숫자인 단어 수는 앞의 것들을 줄인 값이 아닙니다. 공백으로 끊긴 덩어리를 세는 것이라 영문에는 공평한 잣대이고, 낱말을 띄어 쓰지 않는 언어에서는 거의 뜻이 없습니다.

폼이 말하지 않으면 큰 숫자에 맞춘다

대부분의 폼은 「500자」라고만 하고 끝납니다. 어느 기준인지 알아낼 수 없다면 더 빡빡한 쪽, 즉 공백을 포함해서 세는 쪽에 맞춰 쓰세요.

이유는 대칭이 아니기 때문입니다. 사실은 공백을 빼고 세는 폼이었다면 여러분은 조금 짧게 쓴 것이고 아무 일도 일어나지 않습니다. 반대로 공백을 포함해 세는 폼인데 작은 숫자에 맞춰 썼다면 글이 잘립니다. 그리고 잘리는 자리는 대개 문장 한가운데인 끝부분 — 가장 오래 붙들고 있던 대목입니다.

확실히 아는 방법이 하나 있고 10초면 됩니다. 입력하는 동안 글자 수가 실시간으로 뜨는 칸이라면, 글을 붙여 넣고 바깥 도구가 아니라 그 숫자를 읽으세요. 실제로 받아 주거나 잘라 내는 것은 그 칸이고, 그와 다른 값을 내는 도구는 다른 질문에 답하고 있는 것입니다.

실시간 표시가 없다면, 길이를 스스로 세어 둔 시험 문장을 붙여 넣고 그대로 받아들여지는지 보세요. 짧은 실험 하나가 짐작보다 낫습니다.

바이트 제한 — 한글·일본어에서 이상해지는 이유

글자가 아니라 바이트를 세는 칸이 있습니다. 걸리기 전까지는 보이지 않습니다. 게다가 통용되는 관행이 둘이고 서로 어긋납니다.

요즘 시스템은 글을 UTF-8로 저장하는데, 라틴 문자는 1바이트, 악센트가 붙은 문자는 대개 2바이트, 한글·일본어·중국어 글자는 3바이트입니다. 그래서 바이트로 적힌 제한은 이런 언어에서 크게 줄어듭니다.

오래된 폼은 2바이트 인코딩 시절의 다른 관행을 그대로 가지고 있습니다. 전각 문자는 2, 나머지는 1로 세는 방식입니다. 지금도 그렇게 세는 폼이 적지 않은데, 특히 지원서 시스템과 문자 메시지에서 그렇습니다. 규정을 그때 그렇게 썼고 아무도 다시 들여다보지 않았기 때문입니다.

실제로 할 일은 이렇습니다. 제한이 바이트로 적혀 있고 글이 순수한 라틴 문자가 아니라면 짐작하지 마세요. 두 값을 다 확인하시고 — 우리 글자수 세기는 실제 UTF-8 길이와 전각 2바이트 관행을 나란히 보여 줍니다 — 어느 쪽인지 못 가리겠으면 큰 숫자에 맞춰 쓰세요.

줄바꿈·이모지, 그리고 조용한 이견들

줄바꿈이 가장 흔한, 눈에 안 보이는 차이입니다. 어떤 도구는 줄바꿈 하나를 한 자로 세고, 어떤 시스템에서는 두 자로 세며, 아예 안 세는 도구도 있습니다. 문단이 많은 긴 글에서는 이것만으로 총합이 수십 자 달라집니다. 사람이 실제로 보는 단위에는 유니코드가 붙인 이름이 있습니다. 유니코드 표준 부속서 #29가 정의하는 「확장 자소 묶음」입니다. 가족 이모지는 한 묶음이면서 코드포인트 일곱 개이고 동시에 25바이트입니다. 셋 중 어느 것을 보여 줄지는 계수기마다 다릅니다.

이모지는 더합니다. 평범한 이모지는 사람에게도 프로그램에게도 하나이지만, 여럿을 이어 붙여 만든 것이 많습니다 — 피부색, 국기, 가족. 어떻게 세느냐에 따라 국기 하나가 한 자이기도 두 자이기도 합니다. 읽는 사람이 보는 단위가 아니라 저장 단위로 세는 도구는 여러분의 눈과 어긋납니다.

끝의 공백은 사람을 자주 잡는 작은 문제입니다. 맨 끝에 남은 공백 한 칸이나 빈 줄도 대부분의 칸에서는 세어지는데 화면에서는 보이지 않습니다. 한 자가 넘는데 어디가 넘는지 안 보인다면 글 끝부터 보세요.

이 중 어느 것도 버그가 아닙니다. 서로 다른 합리적인 정의일 뿐이고, 빠져나가는 유일한 길은 어떤 정의를 적용했는지 보여 주는 도구를 쓰는 것입니다.

글자수 세기 도구를 고르는 기준

숫자는 어느 도구나 냅니다. 쓸 만한 것과 나머지를 가르는 것은 셋입니다.

기준을 한 번에 여럿 보여 줍니다. 숫자 하나만 던지는 도구는 이 글이 다루는 결정을 감춰 버린 것이고, 확실치 않은 제한과 맞춰 볼 수가 없습니다.

경계에서 무엇을 하는지 말해 줍니다. 공백·줄바꿈·이모지를 세는지, 바이트는 어느 관행으로 세는지가 암시가 아니라 눈에 보여야 합니다.

그리고 글을 어디로도 보내지 않습니다. 세는 일은 산수라 서버가 필요 없습니다. 자기소개서나 계약서 문구처럼 공개할 생각이 없는 글을 붙여 넣는데 그것을 올려 보내는 도구라면, 아무 이유 없이 사본을 하나 넘긴 셈입니다. 우리 것은 브라우저 안에서 세고 그 사실을 화면에 적어 둡니다.

입력하는 동안 숫자가 따라오는 것은 생각보다 중요합니다. 제한에 맞춰 쓰는 일은 재는 것이 아니라 고치는 일이라서요. 줄이면서 숫자가 움직이는 것을 보는 편이, 고칠 때마다 다른 탭에 붙여 넣는 것보다 빠릅니다.

흔한 제한들이 대개 뜻하는 것

한국에서 이 셈이 가장 자주 걸리는 자리는 셋입니다 — 자소서(자기소개서), 학교생활기록부(생기부), 그리고 웹소설 연재 분량. 앞의 둘은 지원서·입학 서식과 같은 부류로 대개 공백 포함 글자수를 뜻하고, 상당수는 칸 안의 실시간 표시로 그것을 강제합니다. 웹소설 쪽은 연재처마다 기준이 갈리므로 편당 분량을 재기 전에 그 연재처가 공백을 세는지부터 확인해야 합니다. 아무 말이 없다면 공백 포함으로 읽는 것이 가장 안전합니다 — 그 칸이 실제로 하고 있는 셈이 거의 언제나 그쪽이기 때문입니다.

SNS 글은 글자를 세지만 서비스마다 링크와 첨부에 대한 규칙이 따로 있고, 링크는 실제 길이와 무관하게 고정 길이로 세는 곳도 있습니다. 직접 계산하지 말고 작성 창의 표시를 읽으세요.

검색 결과에 나오는 제목과 설명은 성격이 다릅니다. 사실 글자 수로 제한되는 것이 아니라 정해진 폭에 얼마나 들어가는가로 잘립니다. 그래서 넓은 글자로 쓴 제목은 좁은 글자로 쓴 제목보다 훨씬 일찍 잘립니다. 글자를 세면 근사치는 되고, 진짜 한계는 화면입니다.

자막·상품 정보 칸·데이터베이스 항목은 바이트 제한이 숨어 있는 자리입니다. 글자 수로는 말이 안 되는 길이에서 칸이 거부한다면 바이트를 세어 보세요. 대개 숫자가 스스로 설명해 줍니다.