자소서 글자수, 공백 포함인가 — 입력창이 실제로 세는 단위

"500자 이내"가 공백 포함인지는 공고마다 다르다. 더 큰 문제는 워드에서 센 숫자와 지원 폼이 센 숫자가 애초에 같지 않다는 점이다.

작성 2026-09-13 · 갱신 2026-09-18 (HTML 표준 원문 확인·실측 예시 추가)

자소서 글자수 질문은 공채 시즌마다 같은 형태로 반복된다. 코멘토·링커리어·블라인드·해커스잡에 "공백 포함인가요 제외인가요"가 각각 따로 쌓여 있고, 인크루트는 아예 자체 글자수 세기 도구를 붙여 두고 있다. 질문이 이렇게 흩어져 반복된다는 것은 답이 한곳에 정리돼 있지 않다는 뜻이다.

지금 쓴 원고의 숫자부터 맞춰 보려면 Character Limit Checker에 붙여 넣어 글자 수·코드 유닛 수·바이트 수를 한 화면에서 대조할 수 있다. 아래는 그 숫자들이 왜 서로 다른지에 대한 설명이다.

공고에 표기가 없으면 공백 포함이 기본값이다

먼저 확인할 것은 공고 원문이다. "공백 포함", "공백 제외", "띄어쓰기 포함" 같은 표기가 있으면 그 표기가 최종 기준이다. 표기가 없을 때 공백 포함을 기본값으로 잡는 근거는 관행이 아니라 구조에 있다. 지원서 입력창은 대부분 웹 폼이고, 웹 폼의 글자 수 제한은 입력된 문자열 전체의 길이로 걸린다. 공백도 문자열에 들어 있는 문자이므로 함께 세진다. 공백을 빼고 세려면 시스템이 일부러 공백을 걷어내는 처리를 넣어야 하는데, 그런 폼이라면 대개 안내 문구로 그 사실을 밝힌다.

그래서 판단 순서는 단순하다. 표기가 있으면 그대로, 없으면 공백 포함으로 맞춘다. 공백 포함으로 한도를 지킨 원고는 공백 제외 기준에서도 자동으로 한도 안에 들어오므로 한 방향으로만 안전한 선택이다.

입력창이 세는 단위는 사람이 세는 '글자'가 아니다

여기서부터 워드에서 센 숫자와 폼이 센 숫자가 갈라진다. 브라우저에서 문자열 길이는 length 값으로 재는데, 단위가 글자가 아니라 UTF-16 코드 유닛이다. 한글 음절과 한자, 라틴 문자는 대부분 코드 유닛 하나라 사람이 세는 숫자와 일치한다. 일치하지 않는 것은 두 종류다.

자소서에 그림문자를 넣는 경우는 드물지만, 워드나 한글 문서에서 복사할 때 따라오는 특수 기호와 결합 부호가 같은 방식으로 숫자를 올린다. 한도를 아슬아슬하게 채운 원고가 붙여 넣는 순간 초과로 잡히는 사례가 대개 여기다.

줄바꿈은 1자일 수도 2자일 수도 있다

문단을 나누는 줄바꿈이 몇 자로 세지는지는 더 까다롭다. 화면에서는 줄이 하나 바뀔 뿐이지만, 폼이 서버로 값을 보낼 때 줄바꿈은 두 문자짜리 표현으로 바뀐다. WHATWG는 폼 제출 동작을 이렇게 적고 있다.

"form values containing newlines are normalized to CRLF, no matter whether the DOM value had LF or CR instead"

어느 쪽 숫자로 한도를 거는지는 그 지원 시스템이 검사를 브라우저에서 하느냐 서버에서 하느냐에 달려 있고, 이 지점의 브라우저 동작 차이는 오래된 미해결 이슈로 남아 있다(모질라 버그 702296). 지원자가 통제할 수 있는 결론은 하나다. 문단이 많은 원고는 줄바꿈 하나당 2자가 더 든다고 보고 여유를 잡는다. 문단 열 개짜리 원고라면 최대 20자 차이가 나고, 500자 한도에서 20자는 문장 하나 분량이다.

브라우저가 입력 도중에 거는 제한은 반대 방향이라는 점도 함께 알아 둘 만하다. HTML 표준은 maxlength 한도를 재는 방법을 이렇게 적고 있다(2026-09-18 확인).

"The number of characters is measured using length and, in the case of textarea elements, with all newlines normalized to a single character (as opposed to CRLF pairs)."

여기서 말하는 length는 Infra 표준이 "A string's length is the number of code units it contains."로 정의한 값, 즉 UTF-16 코드 유닛 수다. 정리하면 같은 줄바꿈이 입력창에서는 1자, 제출값에서는 2자다. 입력창이 막지 않았다고 해서 서버 쪽 한도를 통과했다는 보장이 없는 구조적 이유가 이것이다.

같은 원고, 다섯 개의 숫자

실제로 얼마나 벌어지는지는 짧은 예문 하나로 바로 보인다. 아래 두 문장(사이에 줄바꿈 1개, 공백 23개)을 그대로 세어 본 값이다.

저는 물류 자동화 팀에서 배차 지연 원인을 로그로 분석해, 평균 대기 시간을 42분에서 18분으로 줄였습니다.
이 과정에서 배운 것은 숫자를 먼저 정의해야 개선이 측정된다는 점입니다.

같은 원고가 세는 방법에 따라 78에서 244까지 흩어진다. 공백 포함과 제외의 차이만 23자, 이 예문 기준 22.8퍼센트다. 같은 비율이라면 500자 한도에서 공백 포함으로 세는 폼에는 공백 제외 386자어치만 들어간다(500 × 78 ÷ 101). 공백 제외로 알고 쓴 원고를 공백 포함 폼에 붙였을 때 백 자 넘게 초과하는 일이 생기는 계산이 이것이다. 공백 비중은 원고마다 다르므로 본인 원고로 같은 다섯 값을 한 번 재 보는 편이 정확하다.

바이트로 제한을 거는 폼

일부 공공기관과 사내 시스템은 글자 수가 아니라 바이트 수로 한도를 건다. UTF-8에서 한글 음절 하나는 3바이트, 영문자와 숫자는 1바이트다. 그래서 같은 2,000바이트 한도라도 순수 한글 원고는 약 666자, 영문 섞인 원고는 그보다 많이 들어간다. 한도 단위가 "바이트"로 적혀 있으면 3으로 나눠 대략의 한글 글자 수부터 잡는 편이 빠르다.

정리: 제출 전 확인 순서

1. 공고에 공백 포함 여부 표기가 있는지 본다. 있으면 그것이 기준이다.
2. 표기가 없으면 공백 포함으로 맞춘다.
3. 줄바꿈 개수만큼 2자씩 더 든다고 보고 한도의 95퍼센트 선에서 마감한다.
4. 한도 단위가 바이트면 한글 1자를 3바이트로 환산한다.
5. 완성본은 워드가 아니라 실제 입력창에 붙여 넣어 최종 확인한다.

같은 계수 문제를 다른 플랫폼에서 다룬 글: X의 가중 문자 규칙과 한국어 글자값, 디스코드 임베드 한도, 링크드인 게시물 절단 지점. 해외 플랫폼 정산이 궁금하다면 한국 거주자 기준 수수료 계산도 같은 방식으로 정리해 두었다.