자소서 글자수 공백 포함·제외와 바이트 기준 세는 법
자기소개서 글자수에서 '공백 포함'은 띄어쓰기 한 칸도 1글자로 세는 방식이고, '공백 제외'는 띄어쓰기를 빼고 글자만 세는 방식입니다. 같은 글이라도 공백 포함 기준이 공백 제외보다 띄어쓰기 개수만큼 많이 나옵니다. 따라서 공고에 "공백 포함 1,000자"라고 되어 있으면 띄어쓰기까지 합쳐 1,000자 안에 들어가야 합니다.
기준이 '바이트'로 적혀 있다면 계산이 또 달라집니다. 한글 한 글자를 EUC-KR 방식에서는 2바이트, UTF-8 방식에서는 3바이트로 세기 때문에, 같은 글이 어떤 시스템에서는 통과하고 어떤 시스템에서는 초과로 나올 수 있습니다.
이 글에서는 같은 문장을 여러 기준으로 직접 세어 보고, 줄바꿈과 특수문자, 이모지가 몇 글자 또는 몇 바이트로 계산되는지 정리합니다. 기업과 기관마다 기준이 다르므로, 최종 판단은 항상 해당 공고와 지원서 입력창의 표시를 기준으로 하셔야 합니다.
공백 포함과 공백 제외, 무엇이 다른가
공백(空白)은 띄어쓰기로 생기는 빈칸을 말합니다. 공백 포함 글자수는 화면에 보이는 글자와 빈칸을 모두 더한 값이고, 공백 제외 글자수는 빈칸을 뺀 값입니다.
한국어 문장은 어절마다 띄어 쓰기 때문에 공백이 생각보다 많습니다. 어절이 10개인 문장에는 공백이 9개 들어가므로, 공백 포함 기준이면 그만큼 쓸 수 있는 분량이 줄어듭니다.
공백 비율은 글마다 다르기 때문에 "공백 제외 1,000자는 공백 포함 몇 자"라는 고정 공식은 없습니다. 짧은 단어를 많이 쓰면 공백 비율이 높아지고, 긴 명사가 많으면 낮아집니다. 환산이 필요하면 자기 글을 직접 두 기준으로 세어 비교하는 수밖에 없습니다.
공백 제외에서 빠지는 것
'공백 제외'에서 빼는 대상이 띄어쓰기만인지, 탭과 줄바꿈까지인지는 도구마다 다릅니다. 띄어쓰기, 탭, 줄바꿈을 모두 제외하는 도구가 많지만, 띄어쓰기만 빼고 줄바꿈은 그대로 세는 도구도 있습니다. 지원 시스템이 어떻게 처리하는지는 공개되지 않는 경우가 많으므로, 입력창 카운터로 확인하는 것이 가장 확실합니다.
같은 문장을 여러 기준으로 세어 보기
다음 두 줄짜리 글을 예로 들어 보겠습니다.
협업 경험 팀원 5명과 앱을 출시했습니다.
먼저 글자를 종류별로 나눕니다.
- 한글: 첫째 줄 '협업경험' 4자, 둘째 줄 '팀원·명과·앱을·출시했습니다' 2+2+2+6=12자, 합계 16자입니다.
- 숫자와 기호: 숫자 '5' 1자, 마침표 1자, 합계 2자입니다.
- 띄어쓰기: 첫째 줄 1개, 둘째 줄 3개, 합계 4개입니다.
- 줄바꿈: 1개입니다.
이제 기준별로 계산하면 다음과 같습니다.
| 기준 | 계산 | 결과 |
|---|---|---|
| 공백 제외 글자수 | 한글 16 + 숫자·기호 2 | 18자 |
| 공백 포함 글자수(줄바꿈 미포함) | 18 + 띄어쓰기 4 | 22자 |
| 공백 포함 글자수(줄바꿈 1자) | 22 + 1 | 23자 |
| EUC-KR 바이트(줄바꿈 1바이트) | 한글 16×2=32, 나머지 6×1=6, 줄바꿈 1 | 39바이트 |
| UTF-8 바이트(줄바꿈 1바이트) | 한글 16×3=48, 나머지 6×1=6, 줄바꿈 1 | 55바이트 |
여기서 '나머지 6'은 숫자 1, 마침표 1, 띄어쓰기 4를 더한 값입니다. 줄바꿈을 2바이트(CRLF)로 세는 환경이라면 EUC-KR은 40바이트, UTF-8은 56바이트가 됩니다.
짧은 두 줄인데도 기준에 따라 18에서 56까지 차이가 납니다. 공고의 숫자만 보고 분량을 가늠하면 안 되는 이유가 여기에 있습니다.
바이트 기준: EUC-KR 2바이트와 UTF-8 3바이트
바이트(byte)는 컴퓨터가 글자를 저장할 때 쓰는 용량 단위입니다. 글자 하나를 몇 바이트로 저장할지는 '문자 인코딩'이라는 규칙이 정하는데, 국내 시스템에서 주로 쓰이는 것은 EUC-KR(및 이를 확장한 CP949)과 UTF-8입니다.
- EUC-KR/CP949: 한글과 한자, 일부 특수문자는 2바이트, 영문·숫자·기본 기호는 1바이트입니다. 오래된 시스템에서 "한글 1자=2바이트"라고 안내하는 것이 이 방식입니다.
- UTF-8: 영문·숫자는 1바이트, 한글은 3바이트, 이모지는 4바이트입니다. 문자 범위에 따라 1~4바이트를 쓰는 규칙은 RFC 3629에 정의되어 있습니다.
같은 글이 한쪽에서만 초과되는 경우
제한이 "2,000바이트"이고, 글이 한글 700자, 띄어쓰기 150개, 숫자·기호 30자로 이루어져 있다고 가정해 보겠습니다.
- EUC-KR: 700×2 + 150×1 + 30×1 = 1,400 + 150 + 30 = 1,580바이트
- UTF-8: 700×3 + 150×1 + 30×1 = 2,100 + 150 + 30 = 2,280바이트
EUC-KR 기준이면 420바이트가 남지만, UTF-8 기준이면 280바이트를 초과합니다. 공고에 바이트 제한만 있고 인코딩이 적혀 있지 않다면, 더 엄격한 UTF-8 기준으로 맞춰 두면 어느 쪽이든 안전합니다.
다만 이 계산은 제한이 처음부터 '바이트'로 적혀 있을 때만 해당합니다. 위 글은 공백 포함 880자, 공백 제외 730자이므로, "1,000자" 제한에 바이트 계산을 적용하면 쓸 수 있는 분량을 스스로 크게 줄이는 셈이 됩니다.
완성형 한글 2,350자 문제
순수 EUC-KR(KS X 1001)은 자주 쓰는 한글 2,350자만 담고 있어서 '똠', '햏'처럼 드문 글자는 표현하지 못합니다. CP949는 한글 11,172자를 모두 담고 있어 대부분의 국내 시스템에서는 문제가 없지만, 오래된 시스템에서는 특정 글자가 '?'로 바뀌어 저장될 수 있습니다. 이름이나 고유명사에 이런 글자가 있다면 임시저장 후 미리보기로 확인하는 것이 안전합니다.
줄바꿈은 몇 글자로 계산되나
줄바꿈은 눈에 보이지 않지만 엄연한 문자입니다. 어떤 문자로 저장되고 어디서 세느냐에 따라 0자, 1자, 2자로 다르게 계산됩니다.
| 환경 | 줄바꿈 처리 | 글자수 | 바이트 |
|---|---|---|---|
| 워드프로세서 문서 통계 | 문단 기호를 글자로 세지 않는 경우가 많음 | 0자 | 해당 없음 |
| 웹 입력창 안에서 실시간 계산 | 보통 LF 한 문자로 다룸 | 1자 | 1바이트 |
| 웹 양식 전송 후 서버 계산 | CR+LF 두 문자로 바뀌어 전송됨 | 2자 | 2바이트 |
| Windows 텍스트 파일 | 보통 CR+LF로 저장 | 2자 | 2바이트 |
LF는 '줄 넘김', CR은 '줄 맨 앞으로 이동'을 뜻하는 제어 문자이며, Windows는 전통적으로 두 문자를 이어 붙여 줄바꿈을 표현합니다.
문단 사이 빈 줄은 줄바꿈 2개
문단을 나누려고 빈 줄을 하나 넣으면 줄바꿈이 2개 들어갑니다. 문단이 5개인 글에 빈 줄을 모두 넣으면 문단 경계 4곳×2개로 줄바꿈은 8개이고, CRLF로 세는 시스템에서는 16자가 됩니다. 입력창 카운터는 여유가 있다고 표시했는데 제출 시 초과 오류가 난다면 이 차이를 의심해 볼 만합니다.
특수문자·이모지·한자는 어떻게 세나
글자수 기준에서는 대부분의 문자가 화면에 보이는 대로 1자입니다. 차이는 주로 바이트 기준과, 일부 프로그램의 내부 계산 방식에서 생깁니다.
| 문자 | 예시 | 글자수 | EUC-KR | UTF-8 |
|---|---|---|---|---|
| 한글 | 가 | 1 | 2 | 3 |
| 영문·숫자·기본 기호 | A 7 . , | 1 | 1 | 1 |
| 띄어쓰기 | (빈칸) | 1 | 1 | 1 |
| 가운뎃점(U+00B7) | · | 1 | 2 | 2 |
| 원문자·낫표 | ① 「 | 1 | 2 | 3 |
| 한자 | 學 | 1 | 2 | 3 |
| 이모지 | 😀 | 1 또는 2 | 표현 불가 | 4 |
이모지가 2자로 세어지는 이유
웹 페이지에서 쓰는 자바스크립트는 문자열 길이를 UTF-16 단위로 셉니다. 이모지 대부분은 UTF-16에서 두 단위를 차지하므로 화면에는 1자로 보여도 길이는 2로 계산됩니다. 이 동작은 MDN의 String.length 설명에서 확인할 수 있습니다.
가족 이모지 👨👩👧처럼 여러 이모지를 보이지 않는 연결 문자(ZWJ)로 묶은 경우는 더 커집니다. 남자·여자·여자아이 이모지 3개와 연결 문자 2개로 이루어져, UTF-16 길이는 2+1+2+1+2=8, UTF-8은 4+3+4+3+4=18바이트입니다. EUC-KR 기반 시스템에서는 이모지를 아예 저장하지 못해 깨지거나 거부될 수 있으므로, 지원서에는 넣지 않는 것이 맞습니다.
보이지 않는 특수 공백
웹 페이지나 문서에서 복사한 글에는 일반 띄어쓰기 대신 '줄바꿈 없는 공백(NBSP)'이나 폭이 0인 공백이 섞여 있을 수 있습니다. 화면에서는 구분되지 않지만, 도구에 따라 공백 제외 계산에서 빠지지 않거나 바이트가 더 크게 잡힙니다. 메모장 같은 일반 텍스트 편집기를 거쳐도 서식만 사라질 뿐 특수 공백 자체는 남을 수 있습니다.
찾아내는 방법은 간단합니다. 의심 가는 구간의 띄어쓰기를 지우고 키보드로 다시 입력한 뒤, 글자수 세기 도구의 공백 제외 수가 바뀌는지 비교합니다. 숫자가 줄었다면 그 자리에 특수 공백이 있었던 것입니다. 복사해 온 문단이 많다면 지원서 입력창에 붙여 넣은 뒤 해당 문단의 띄어쓰기를 직접 다시 치는 편이 확실합니다.
지원서 입력창과 글자수가 다르게 나올 때 확인하는 순서
워드프로세서, 글자수 세기 사이트, 지원서 입력창의 숫자가 서로 다른 것은 흔한 일입니다. 다음 순서로 확인하면 원인을 대부분 찾을 수 있습니다.
- 공고 문구를 다시 읽고 '공백 포함/제외', '자/바이트' 중 어느 기준인지 확인합니다.
- 기준이 일부만 적혀 있다면 단위별로 나눠 판단합니다. 제한이 '자' 단위인데 공백 포함/제외가 없으면 공백 포함·줄바꿈 2자로 맞추고, 제한이 '바이트' 단위인데 인코딩이 없으면 UTF-8(한글 3바이트)로 맞춥니다. 글자수 제한에 바이트 계산을 섞으면 한글 기준 분량이 3분의 1 수준으로 줄어드므로 두 단위를 섞지 않습니다.
- 글자수 세기 도구로 공백 포함·제외 수와 바이트를 함께 확인합니다. 글자수 세기에 붙여 넣으면 공백 포함·제외 글자수와 바이트를 함께 볼 수 있습니다. 이때 바이트 값이 어떤 인코딩 기준인지, 줄바꿈을 몇 바이트로 세는지는 도구 안내를 확인하시기 바랍니다. 빈 칸에 '가' 한 글자만 넣어 2가 나오면 EUC-KR, 3이 나오면 UTF-8 기준이고, 줄바꿈 하나를 넣었을 때 늘어나는 값으로 줄바꿈 처리도 알 수 있습니다.
- 실제 지원서 입력창에 붙여 넣어 카운터 숫자를 확인합니다. 최종 기준은 결국 그 입력창입니다.
- 입력창 숫자가 도구와 다르면 줄바꿈 개수와 이모지·특수 공백 여부를 먼저 점검합니다.
- 임시저장 후 미리보기에서 글자가 깨지거나 잘리지 않았는지 확인합니다.
다른 곳에서 복사해 온 글에 중복 공백이나 불필요한 줄바꿈이 많다면 줄바꿈 제거 도구로 정리한 뒤 문단만 다시 나누는 방법도 있습니다.
분량이 넘치거나 모자랄 때 맞추는 요령
넘칠 때: 의미는 그대로, 군더더기만 줄이기
가장 효과가 큰 방법은 '~할 수 있었습니다', '~라고 생각합니다', '~를 통해' 같은 표현을 줄이는 것입니다.
- 수정 전: "저는 이 경험을 통해 소통의 중요성을 깨달을 수 있었습니다." 한글 24자, 마침표 1자, 띄어쓰기 8개로 공백 포함 33자, 공백 제외 25자입니다.
- 수정 후: "이 경험으로 소통의 중요성을 깨달았습니다." 한글 18자, 마침표 1자, 띄어쓰기 4개로 공백 포함 23자, 공백 제외 19자입니다.
한 문장에서 공백 포함 기준으로 10자가 줄었고, 내용은 달라지지 않았습니다. 자기소개서는 본인 이야기이므로 문장 첫머리의 '저는'도 상당수 생략할 수 있습니다.
숫자를 아라비아 숫자로 쓰는 것도 도움이 됩니다. "약 이십 퍼센트"는 공백 포함 8자, "약 20%"는 5자입니다. 바이트 기준이라면 숫자와 %는 1바이트이므로 차이가 더 벌어집니다.
모자랄 때: 숫자와 과정을 채우기
분량이 부족할 때 형용사나 다짐을 덧붙이면 글이 늘어질 뿐 설득력은 오르지 않습니다. 대신 결과를 숫자로 밝히고(기간, 인원, 개선 폭), 그 결과에 이르기까지 본인이 판단한 내용과 이유를 한두 문장씩 보태는 편이 분량과 내용을 함께 채웁니다.
제한 대비 어느 정도를 채워야 하는지 공식적인 기준은 없습니다. 다만 제한을 넘으면 제출이 막히거나 뒷부분이 잘릴 수 있으므로, 입력창 기준으로 제한보다 몇 자 정도 여유를 두고 마무리하는 편이 안전합니다.
제출 전 글자수 점검 체크리스트
- 공고에 적힌 기준이 공백 포함인지 제외인지, 글자인지 바이트인지 확인했다.
- '자' 단위인데 공백 기준이 없으면 공백 포함·줄바꿈 2자로, '바이트' 단위인데 인코딩이 없으면 UTF-8(한글 3바이트)로 맞췄다.
- 사용한 글자수 세기 도구의 바이트 값이 어떤 인코딩 기준인지 확인했다.
- 문단 사이 빈 줄 수를 세어 줄바꿈 몫까지 여유를 남겼다.
- 이모지, 특수 공백, 드문 한글 글자가 섞여 있지 않은지 확인했다.
- 바이트 제한이라면 가운뎃점·원문자·한자처럼 바이트가 큰 문자를 꼭 필요한 곳에만 썼다.
- 맞춤법 검사 후 최종본으로 글자수를 다시 셌다.
- 실제 지원서 입력창에 붙여 넣어 카운터 숫자를 최종 확인했다.
- 임시저장 후 미리보기에서 글자가 깨지거나 잘리지 않았는지 확인했다.
자주 묻는 질문
공고에 글자수만 있고 공백 포함인지 제외인지 적혀 있지 않으면 어떻게 하나요?
가능하면 채용 담당 부서나 문의 게시판으로 확인하는 것이 가장 정확합니다. 확인이 어렵다면 더 엄격한 공백 포함 기준으로 맞추면 어느 쪽이든 제한을 넘지 않습니다. 이때 바이트로 환산할 필요는 없으며, 입력창에 카운터가 있다면 그 숫자가 사실상의 기준이 됩니다.
맞춤법 검사를 돌리고 나니 글자수가 바뀌었는데 왜 그런가요?
맞춤법 검사기는 띄어쓰기도 함께 교정하기 때문에 공백 개수가 늘거나 줄어듭니다. 그래서 공백 제외 글자수는 거의 그대로여도 공백 포함 글자수는 달라질 수 있습니다. 교정을 마친 최종본으로 글자수를 다시 확인해야 합니다.
엑셀에서 자소서 글자수를 셀 수 있나요?
LEN 함수는 띄어쓰기와 셀 안 줄바꿈까지 포함한 글자수를 돌려주고, LEN(SUBSTITUTE(A1," ",""))처럼 공백을 지운 뒤 세면 띄어쓰기를 뺀 글자수가 됩니다. 줄바꿈까지 빼려면 LEN(SUBSTITUTE(SUBSTITUTE(A1," ",""),CHAR(10),""))처럼 한 번 더 지웁니다. 한국어 환경의 LENB 함수는 한글을 2바이트로 세므로 EUC-KR 방식 바이트를 대략 확인할 때 참고할 수 있습니다.
메모장에 저장한 파일 크기로 바이트 수를 알 수 있나요?
어느 정도는 가능하지만 저장한 인코딩을 알아야 합니다. 최근 Windows 메모장은 기본적으로 UTF-8로 저장하므로 한글은 3바이트로 계산되며, BOM이 붙는 형식으로 저장하면 앞에 3바이트가 더해집니다. 줄바꿈도 보통 2바이트로 저장되므로, 정확한 확인은 글자수 세기 도구를 쓰는 편이 편리합니다.