글자수 공백 포함·제외, 자소서는 어느 쪽으로 세나

2026년 7월 20일

입력창에 두 문단짜리 글을 붙여 넣자 글자수 공백 포함과 공백 제외, 단어·문장·문단·줄·바이트 수가 함께 표시된 화면

자기소개서에 "1,000자 이내"라고 적혀 있는데, 워드에서 센 숫자와 지원 화면이 보여주는 숫자가 다른 경우가 있습니다. 결론부터 말하면 글자수를 요구한 쪽이 세는 값이 기준이고, 숫자가 갈리는 원인은 몇 가지로 정해져 있습니다.

원인은 셋뿐입니다. 공백을 세는지, 줄바꿈을 공백으로 보는지, 그리고 글자가 아니라 바이트를 세는지입니다. 이 셋만 알면 어느 계산기든 규칙을 직접 알아낼 수 있습니다.

요약 ① 기준이 공고에 적혀 있으면 그게 우선이고, 온라인 입력 폼이면 그 폼의 카운터가 최종 판정입니다. ② 공백 포함은 공백 제외보다 항상 크거나 같으므로, "이내" 제한은 공백 포함으로, "이상" 요구는 공백 제외로 맞추면 어느 기준이든 안전합니다. ③ 두 줄짜리 짧은 문장 하나를 넣어 보면 그 계산기가 줄바꿈을 세는지 30초 만에 확인됩니다.

같은 글인데 세는 곳마다 숫자가 다른 이유

원고를 워드에서 쓰고 지원 화면에 붙여 넣었더니, 워드에서는 여유가 있었는데 화면에서는 글자수 초과로 막히는 상황이 대표적입니다.

이때 대부분은 줄바꿈 때문입니다. 문단을 나누려고 누른 Enter를 글자 1개로 세는 곳과 아예 세지 않는 곳이 갈리는데, 문단이 열 개면 그것만으로 10글자가 차이 납니다.

두 번째는 공백의 범위입니다. 흔히 말하는 공백에는 스페이스만 있는 게 아니라 탭, 그리고 한글 자판에서 만들어지기도 하는 전각 공백(넓은 빈칸)이 있습니다. 이걸 공백으로 보는 계산기는 "공백 제외"에서 빼고, 안 보는 계산기는 글자로 남깁니다.

세 번째는 글자가 아니라 바이트를 세는 경우입니다. 문자 서비스나 오래된 게시판처럼 길이 제한이 바이트로 걸려 있으면, 한글 한 글자가 몇 바이트냐에 따라 들어가는 분량이 달라집니다.

도구 없이 글자수를 직접 세는 방법

계산기를 열지 않아도 확인할 수 있는 방법이 두 가지 있습니다. 지금 쓰고 있는 프로그램에 이미 들어 있거나, 브라우저에 이미 들어 있습니다.

문서 프로그램에 이미 있는 기능

마이크로소프트 워드는 검토 탭의 단어 개수를 열면 "문자(공백 포함)"와 "문자(공백 제외)"가 함께 나옵니다. 구글 문서는 도구 메뉴의 단어 수에서 같은 값을 보여줍니다.

여기서 중요한 건 어느 항목을 보느냐입니다. 두 값이 함께 나오므로, 제출처가 요구한 기준에 해당하는 줄만 읽으면 됩니다.

브라우저 콘솔로 네 가지 값을 한 번에

브라우저 개발자 도구(대개 F12)의 콘솔에 아래를 넣으면 네 가지 숫자가 각각 나옵니다. 이 중 2~4번째 줄은 저희 도구가 글자수(공백 포함)·글자수(공백 제외)·바이트를 계산할 때 쓰는 식과 같습니다.

const s = "여기에 글을 붙여넣습니다";
s.length;                                  // UTF-16 코드유닛 수(이모지는 2로 셉니다)
Array.from(s).length;                      // 글자수(공백 포함)
Array.from(s.replace(/\s/g, "")).length;  // 글자수(공백 제외)
new TextEncoder().encode(s).length;        // UTF-8 바이트 수

여기서 replace(/\s/g, "")가 지우는 것은 스페이스만이 아닙니다. 탭·줄바꿈·전각 공백까지 함께 지웁니다. 그래서 이 식으로 나온 "공백 제외" 값에는 줄바꿈이 들어 있지 않습니다.

어느 계산기든 규칙을 알아내는 30초 시험

계산기가 줄바꿈을 세는지는 이 두 줄만 넣어 보면 끝납니다.

가나
다라

공백 포함이 5로 나오면 줄바꿈을 1글자로 세는 것이고, 4면 세지 않는 것입니다. 참고로 저희 도구는 5로 셉니다(공백 제외는 4입니다).

문제는 이걸 매번 콘솔을 열어 확인하기 번거롭고, 여러 줄짜리 원고를 따옴표 안에 붙여 넣기가 까다롭다는 점입니다.

저희 도구로 확인하기. 입력창에 원고를 그대로 붙여 넣으면 공백 포함·제외 글자수가 한 화면에 같이 나옵니다.

글자수 세기

설치·회원가입 없이 브라우저 안에서 즉시 계산되며, 붙여 넣은 글은 서버로 전송되지 않습니다.

자기소개서·리포트는 어느 쪽으로 세야 할까

순서대로 판단하면 됩니다.

1. 공고나 과제 안내에 적힌 문구가 최우선입니다. "공백 포함 1,000자", "공백 제외 500자 이상"처럼 명시돼 있으면 그 기준만 보면 됩니다.

2. 온라인 입력 폼이면 그 폼의 카운터가 사실상 최종 기준입니다. 제출 버튼을 막는 건 그 화면이기 때문에, 워드에서 몇 자였는지는 판정에 쓰이지 않습니다. 붙여 넣은 뒤 화면 숫자를 확인하는 게 확실합니다.

3. 기준을 알 수 없으면 부등호 방향으로 정합니다. 공백 포함 값은 공백 제외 값보다 항상 크거나 같습니다. 그래서 "이내" 제한은 공백 포함 값을 제한 안에 맞추고, "이상" 요구는 공백 제외 값이 요구치를 넘게 맞추면 어느 기준으로 채점하더라도 걸리지 않습니다.

숫자가 갈리는 지점 정리

갈리는 지점	계산기에 따라
줄바꿈(Enter)	1글자로 세거나, 아예 세지 않습니다
탭·전각 공백	공백으로 보면 '공백 제외'에서 빠지고, 아니면 글자로 남습니다
이모지	1글자로 세는 곳과 2글자로 세는 곳이 갈립니다
바이트	한글 한 글자가 UTF-8에서 3바이트, EUC-KR 계열에서 2바이트입니다

이모지가 갈리는 이유는 내부 저장 방식 때문입니다. 자바스크립트의 문자열.length는 UTF-16 코드유닛을 세기 때문에 😀 같은 이모지가 2로 잡히고, 사람이 보는 글자 단위로 세면 1이 됩니다. 저희 도구는 글자 단위로 세어 1로 표시합니다.

한 가지 더, 한국어에서 "단어" 수는 사전적 단어가 아니라 공백으로 끊은 어절 수입니다. 저희 도구도 공백 기준으로 나눠 세므로, 영어 글의 단어 수와 같은 의미로 비교하기는 어렵습니다.

정리

숫자가 갈리는 원인은 줄바꿈·공백의 범위·바이트 셋으로 거의 정리됩니다.
공백 포함은 공백 제외보다 항상 크거나 같습니다. "이내"는 공백 포함으로, "이상"은 공백 제외로 맞추면 안전합니다.
온라인 제출 폼이 있으면 그 화면의 카운터가 최종 판정입니다.
"가나 / 다라" 두 줄을 넣어 5인지 4인지 보면, 그 계산기가 줄바꿈을 세는지 바로 확인됩니다.
문자 서비스처럼 제한이 바이트로 걸린 곳에서는 글자수가 아니라 바이트 값을 봐야 합니다.

글자수 세기

설치·회원가입 없이 브라우저 안에서 즉시 계산되며, 붙여 넣은 글은 서버로 전송되지 않습니다.

📖 실제 사용자들이 겪는 현실적인 사연과 트러블

실무 현장과 일상에서 글자수와 바이트 수 계산을 둘러싸고 예상치 못한 수많은 문제에 직면하게 됩니다. 다음은 실제 사용자들이 가장 빈번하게 겪는 대표적인 실패 사례들입니다.

사연 1: 마감 2분 전 발생한 대기업 공채 입사지원서 에러

취업 준비생 A씨는 "1,000자 이내 (공백 포함)"라는 엄격한 글자수 제한을 맞추기 위해 마이크로소프트 워드(MS Word)에서 심혈을 기울여 자기소개서를 작성했습니다. 워드 하단 상태 표시줄의 단어 개수 창에서는 분명 '문자(공백 포함)'가 995자로 완벽하게 기준을 통과했습니다. 워드는 단락을 나누기 위해 누른 엔터(Enter, 줄바꿈) 기호를 글자수에 포함하지 않았기 때문입니다. 하지만 밤 11시 58분, 서류 마감을 단 2분 남기고 기업 채용 포털에 복사하여 붙여넣는 순간 "총 1,011자로 1,000자를 초과하여 제출할 수 없습니다"라는 치명적인 에러 팝업이 떴습니다. 해당 기업의 시스템은 윈도우(Windows) 방식의 CRLF 줄바꿈을 문단마다 각각 2글자로 카운트하여 8개 문단의 줄바꿈이 무려 16자로 계산되어 버린 것입니다.

사연 2: 88바이트 단문(SMS)인 줄 알았으나 장문(LMS) 3배 과금 폭탄을 맞은 마케터

중소기업의 SMS 마케팅 담당자 B씨는 5,000명의 고객에게 발송할 프로모션 문자를 작성했습니다. 그는 웹 기반의 일반 텍스트 에디터에서 글자수를 확인하며, 이동통신사의 SMS 최대 허용치인 80바이트 제한(EUC-KR 기준)을 고려해 정확히 80바이트로 맞추려 했습니다. 하지만 이모지 하나(🔥)를 추가하여 시각적인 효과를 높인 것이 화근이었습니다. 일반적인 EUC-KR 환경에서 한글은 2바이트지만, 최신 웹 기반 메시징 시스템은 UTF-8 인코딩을 적용해 한글을 3바이트로, 이모지를 4바이트로 처리했습니다. 시스템 내부적으로 80바이트를 훌쩍 넘긴 140바이트로 인식되었고, 시스템은 아무런 경고 없이 5,000건의 문자를 장문 메시지(LMS)로 자동 전환하여 발송해 버렸습니다. 결과적으로 예산보다 3배 이상인 150,000원의 추가 요금이 청구되는 불상사가 일어났습니다.

사연 3: '공백 포함'과 '공백 제외'를 혼동한 공공기관 논술 불합격

공기업 필기시험에 응시한 C씨는 "공백 제외 1,500자 이상"이라는 논술 분량 제한 규정을 전달받았습니다. 그는 온라인 글자수 세기 프로그램에 본인의 답안을 붙여넣고 상단에 크게 뜬 "1,520자"라는 숫자를 보고 안심하여 최종 제출 버튼을 눌렀습니다. 그러나 그 1,520자는 '공백 포함' 글자수였으며, 띄어쓰기와 줄바꿈이 많은 논술 글의 특성상 '공백 제외' 실 글자수는 1,180자에 불과했습니다. 결과적으로 요구된 최소 분량 기준(1,500자)을 320자나 미달하게 되어, 내용의 완성도와 관계없이 규정 위반으로 즉각적인 탈락 처리를 통보받게 되었습니다.

🔬 핵심 기술 메커니즘 — 왜 계산기마다 결과가 다를까?

글자수 계산이 어긋나는 근본적인 이유는 컴퓨터가 문자를 인식하고 메모리에 저장하는 방식, 즉 '인코딩(Encoding)'과 '문자열 처리 엔진'이 각 플랫폼마다 다르기 때문입니다.

1. 문자열 길이(String Length) 표현 방식의 차이

프로그래밍 언어와 브라우저 엔진은 문자열의 길이를 각기 다른 단위로 측정합니다.

JavaScript의 기본 Length 속성 (UTF-16 코드 유닛): 가장 흔하게 쓰이는 자바스크립트의 string.length는 문자를 UTF-16 코드 유닛 단위로 셉니다. 영문 알파벳과 한글 등 기본 다국어 평면(BMP) 문자는 1로 세지만, 보충 평면(SMP)에 존재하는 이모지(예: 😀)나 일부 특수 기호는 서로게이트 페어(Surrogate Pair)로 인식되어 1개의 문자를 2개의 길이로 반환합니다.
그래핌 클러스터(Grapheme Cluster) 카운팅: 사람의 눈에 보이는 직관적인 '한 글자' 단위로 세는 방법입니다. Array.from(str).length나 최신 브라우저의 Intl.Segmenter를 사용하면 복잡한 조합형 이모지(👨‍👩‍👧‍👦)나 한글의 초·중·종성 조합을 사람이 인지하는 정확히 1개의 문자로 정확히 계산해냅니다.
바이트(Byte) 단위 인코딩 차이: 글자수가 아니라 저장 공간의 크기를 셀 때는 인코딩 방식이 결과를 좌우합니다.
- ASCII: 영문, 숫자, 기본 기호는 모든 환경에서 1바이트입니다.
- EUC-KR (CP949): 레거시 윈도우 환경과 오래된 국내 SMS 시스템에서 주로 쓰이며 한글 1글자를 2바이트로 처리합니다.
- UTF-8: 현재 웹 표준 인코딩으로 한글 1글자를 3바이트로 처리합니다. 이모지 같은 특수문자는 4바이트를 차지합니다.

2. 줄바꿈 문자(Line Break)의 처리 변수

글자수를 카운트할 때 가장 많은 혼란을 일으키는 주범은 줄바꿈입니다. 운영체제에 따라 엔터 키를 쳤을 때 삽입되는 문자가 다릅니다.

LF (Line Feed, \n): 유닉스(Unix), 리눅스, macOS 환경에서 사용되며 줄바꿈을 1글자(1바이트)로 취급합니다.
CRLF (Carriage Return + Line Feed, \r\n): 윈도우(Windows) 운영체제와 RFC 2822 표준 이메일 규격에서 사용되며, 눈에 보이지 않지만 2개의 문자(2바이트)가 결합되어 있어 엄격한 글자수 계산기에서는 2글자로 잡힙니다.

3. 전각 공백과 반각 공백의 함정

반각 공백 (Half-width Space, \u0020): 우리가 흔히 스페이스바를 눌러 입력하는 기본 공백으로 1바이트를 차지합니다.
전각 공백 (Full-width Space, \u3000): 일본어나 한글 입력기에서 특정 키 조합으로 입력되는 넓은 폭의 공백입니다. 육안으로는 일반 공백을 여러 번 친 것처럼 보이지만, 시스템 내부적으로는 하나의 문자이며 UTF-8 환경에서 3바이트를 차지합니다. '공백 제외' 정규식 처리가 미흡한 카운터에서는 이 전각 공백을 문자로 인식하여 글자수 오차를 발생시키기도 합니다.

📊 상황별 글자 및 바이트 계산 기준 비교표 (Comparison Matrix)

각 주요 플랫폼과 기업 포털들이 어떠한 기준으로 글자수와 바이트 수를 책정하는지 명확하게 정리한 매트릭스입니다. (※ 시스템 업데이트에 따라 변동 가능성이 있습니다.)

플랫폼 및 시스템	공백 처리 기준	줄바꿈(Enter) 처리	이모지/특수문자	한글 바이트 매핑
마이크로소프트 워드 (MS Word)	선택 확인 가능	글자수 미포함 (0자)	1글자로 인식	OS 기본 인코딩 종속
구글 문서 (Google Docs)	선택 확인 가능	1글자로 인식	1글자로 인식	UTF-8
사람인 / 잡코리아 채용 폼	기업 설정에 따름	기업별 상이 (통상 2자)	특수문자 오류 주의	시스템 내부 기준
국세청 홈택스 (Hometax)	공백 포함	CRLF (2바이트 처리)	사용 불가(에러 발생)	EUC-KR 기반(2바이트)
공기업 NCS 블라인드 채용 폼	공백 포함 (대다수)	통상 2자 (플랫폼 상이)	시스템 필터링 대상	EUC-KR / UTF-8 혼용
트위터(X) 280자 리밋	공백 1자 포함	1자로 카운트	2글자로 가중치 부과	한글 2글자(웨이트 적용)
SMS 단문 메시지 (80~90바이트)	공백 1바이트 처리	LF/CRLF 플랫폼 의존	통상 발송 불가/LMS 전환	한글 2바이트 (EUC-KR)

⚠️ 무심코 저지르는 글자수 계산 실수 5가지

사소한 실수가 서류 탈락이나 과도한 비용 청구라는 돌이킬 수 없는 결과로 이어질 수 있습니다. 반드시 피해야 할 5가지 치명적인 실수를 확인하세요.

'공백 포함(With Spaces)'과 '공백 제외(Without Spaces)'의 혼동: 가장 빈번한 오류입니다. 제출처가 명시한 기준이 둘 중 어느 것인지 확인하지 않고, 계산기 화면에 가장 크게 뜨는 기본 숫자만 믿고 제출하는 행위는 매우 위험합니다.
문단이 많은 에세이에서 줄바꿈 글자수를 간과하는 행위: 논리적인 전개를 위해 문단을 잘게 쪼개는 것은 좋지만, 줄바꿈 기호(CRLF)가 매번 1~2자씩 누적된다는 사실을 잊으면 1,000자 제한 폼에서 뒷부분의 문장 하나가 통째로 잘려나갈 수 있습니다.
바이트 제한 폼(SMS, 레거시 게시판)에서 무분별한 이모지 사용: 이모지는 UTF-16에서 2개 이상의 코드 유닛, UTF-8에서 4바이트 이상을 소모합니다. 80바이트 제한 폼에 이모지를 하나 넣는 순간 한글 2글자를 지워야 하는 페널티가 발생합니다.
마이크로소프트 워드의 글자수 카운트를 맹신하는 태도: 워드는 줄바꿈을 카운트하지 않으므로 웹 폼과 결과가 다르게 나옵니다. 초안은 워드에서 작성하더라도, 최종 글자수는 반드시 해당 기업의 온라인 포털 폼에 직접 붙여넣어 검증해야 합니다.
서류 마감 5분 전까지 카운팅 검증을 미루는 습관: 마감 직전은 서버 트래픽이 폭주하는 시기입니다. 1,001자로 복사가 거부된 상황에서 1자를 줄이기 위해 문맥을 해치지 않고 편집하는 것은 엄청난 스트레스를 유발하며, 서버가 다운될 위험도 존재합니다.

💡 이력서 및 자소서 글자수 최적화 5단계 워크플로우

단 1글자의 차이로 시스템 에러가 발생하여 억울하게 탈락하는 일을 막기 위한 무결성 워크플로우입니다.

1단계 (가이드라인 검증 및 기준선 확립): 채용 공고나 시스템 안내문에 기재된 기준이 '공백 포함'인지 '공백 제외'인지, 바이트 단위인지 정확히 확인합니다.
2단계 (최대 한도의 90~95% 목표로 초안 작성): 1,000자 이내라면 900~950자를 목표로 글을 작성합니다. 처음부터 1,000자에 딱 맞추려 하면 수정 과정에서 지속적인 글자수 오버 현상에 시달리게 됩니다.
3단계 (웹 기반 전용 카운터로 시뮬레이션): 워드나 한글 문서 프로그램의 카운터를 믿지 말고, 줄바꿈과 공백을 웹 표준으로 정확히 세어주는 본 사이트의 전용 카운터에 복사하여 실질적인 분량을 측정합니다.
4단계 (군더더기 및 불필요한 공백 제거): 글자수가 아슬아슬하게 초과했다면, 잦은 줄바꿈을 합치고, 눈에 보이지 않는 문장 끝의 스페이스(Trailing Spaces)를 지우며, 불필요한 수식어를 덜어냅니다. 전각 공백이 섞여 있는지도 확인합니다.
5단계 (마감 2시간 전 실제 포털 테스트 입력): 실제 접수 포털의 텍스트 에어리어(Textarea)에 초안을 복사하여 넣은 뒤, 포털 하단에 표시되는 내부 카운터가 빨간색(초과) 경고를 띄우지 않는지 마감 시간 최소 2시간 전에 여유를 가지고 최종 확인합니다.

🔍 실무자와 카피라이터를 위한 7가지 고급 팁

텍스트 분량 조절과 최적화를 자유자재로 다루기 위한 전문가들의 글쓰기 및 카운팅 노하우입니다.

안전 제일 '90% 룰' 적용: 기업이 요구하는 최대 글자수의 90% 이상을 채우되 95%를 넘지 않도록 맞추는 것이 가장 이상적입니다. 1,000자 제한이라면 900자~950자 사이로 마감하여, 시스템의 카운팅 오차 범위로 인한 불이익을 완전히 차단하세요.
줄바꿈 다이어트로 분량 확보: 문단을 나누기 위해 엔터를 두 번 연속 치는(빈 줄 삽입) 습관은 글자수를 2~4자씩 무의미하게 소모합니다. 텍스트 분량이 빠듯할 경우 연속된 줄바꿈을 단일 줄바꿈과 스페이스바로 교체하세요.
수동태형 문장을 능동형으로 압축: "되어졌다고 생각되어집니다" 같은 불필요한 피동·사동 표현을 "했습니다"와 같은 간결한 능동형으로 바꾸면 문장 가독성이 획기적으로 상승하며, 잉여 글자수를 10% 이상 절감할 수 있습니다.
정규식(Regex) s+$를 활용한 후행 공백 완전 삭제: 문장 끝부분 마침표 뒤에 무의미하게 추가된 스페이스바들은 육안으로 보이지 않지만 글자수를 은밀하게 갉아먹습니다. 편집기의 정규식 찾기 기능을 이용해 꼬리 공백들을 일망타진하세요.
정부/공공기관 시스템은 '바이트(Byte)' 크기를 우선 고려: 공기업 채용이나 국세청 등 오래된 레거시 시스템들은 EUC-KR 기반의 바이트를 기준으로 데이터를 자릅니다. 한글이 2바이트로 취급되므로, 제출 전 웹 바이트 계산기로 꼼꼼한 교차 검증이 필수입니다.
트위터(X)의 독특한 한글 가중치 이해: 글로벌 SNS인 트위터는 280자 제한을 두고 있으나, 한글과 한자 등 CJK 문자는 1글자를 '2자' 비중으로 계산합니다. 따라서 한글로만 작성할 경우 실질적인 최대 길이는 140자라는 점을 명심해야 합니다.
통합 대시보드 뷰 카운터 활용: 글자수(포함/제외)와 바이트(UTF-8/EUC-KR)를 한 화면에서 실시간으로 동시에 보여주는 다중 뷰어 툴을 북마크하여 작업창 한쪽에 띄워놓고 작성하면 생산성이 극대화됩니다.

🎯 맞춤형 글자수 계산 기준 판별을 위한 결정 트리 (Decision Tree)

내 글을 복사해 넣기 전, 어떤 기준을 적용해야 할지 3초 만에 결정할 수 있는 가이드 맵입니다.

타겟이 대기업/사기업 채용 포털입니까?
- ➔ YES: 포털 자체 카운터가 절대 권력입니다. 초안 작성 시 글자수(공백 포함) 기준으로 확인하되 95% 비율을 타겟팅하세요.
타겟이 공공기관/공무원 채용 시스템(NCS)입니까?
- ➔ YES: 지시사항에 '공백 제외'가 있는지 확인하십시오. 구형 시스템은 바이트 검열도 존재하므로 글자수(공백 제외) 및 EUC-KR 바이트 수를 동시에 모니터링하세요.
타겟이 SMS 문자 발송 시스템 또는 구형 게시판입니까?
- ➔ YES: 단연코 바이트 수(Byte) 기준이 1순위입니다. 가급적 이모지 사용을 억제하여 바이트 초과로 인한 전송 실패나 과금 오버를 방지하세요.
타겟이 글로벌 SNS(트위터 등) 입니까?
- ➔ YES: CJK 가중치가 적용된 전용 길이 알고리즘을 따릅니다. 한글 기준 140자 리밋으로 생각하고 공백을 타이트하게 관리하세요.

📑 전문가처럼 텍스트를 다루기 위한 필수 용어 치트시트

공백 포함 (With Spaces): 글자를 구성하는 알파벳, 한글, 숫자뿐만 아니라 띄어쓰기(스페이스바)와 탭(Tab), 때로는 줄바꿈 기호까지 모두 각각 하나의 글자로 인정하여 모두 더한 값입니다. 일반적인 웹 포털 폼의 디폴트 기준입니다.
공백 제외 (Without Spaces): 글의 순수 의미를 담은 텍스트 문자만 카운트하며, 띄어쓰기와 탭, 줄바꿈 등을 뺀 알짜배기 글자수입니다. 지원자의 실질적인 작성 분량을 확인하고자 할 때 요구되는 깐깐한 기준입니다.
바이트 (Byte): 문자가 컴퓨터 메모리나 저장 장치에 기록될 때 차지하는 실질적인 데이터 용량 단위입니다. 글자수와 직결되지 않으며 인코딩 방식에 따라 천차만별로 달라집니다.
UTF-8 vs EUC-KR (CP949): 전 세계 표준 인코딩인 UTF-8은 한글을 무겁게(3바이트) 저장하지만 다국어 호환이 완벽하고, 한국 전용 인코딩인 EUC-KR은 한글을 가볍게(2바이트) 저장하지만 다른 나라 언어나 이모지가 깨질 위험이 큽니다.
서로게이트 페어 (Surrogate Pair): 최신 이모지나 특수 기호를 16비트(UTF-16) 공간 두 개를 연결하여 표현하는 방식입니다. 구형 자바스크립트 엔진에서는 이를 2글자로 인식하는 버그성 오차가 존재합니다.
줄바꿈 (CRLF vs LF): 엔터 키 입력 시 저장되는 보이지 않는 기호로 윈도우는 두 개의 기호(CR, LF)를, 맥과 리눅스는 하나의 기호(LF)를 삽입합니다.

자주 묻는 질문

글자수 계산의 미묘한 차이로 혼란을 겪는 사용자들이 가장 자주 묻는 핵심 질문에 대한 심층 해답입니다.

Q1. 워드에서 작성했을 때는 980자였는데, 기업 채용 포털에 붙여넣으니 1,020자가 되었습니다. 왜 이런 차이가 발생하나요?

A1. 두 시스템의 '줄바꿈(Enter)' 처리 방식 차이 때문입니다. MS 워드는 문단을 나누는 엔터 키를 글자수에 합산하지 않고 0자로 처리합니다. 반면 대부분의 기업 채용 웹 포털은 텍스트 입력 창(Textarea)의 속성상 줄바꿈을 문자(주로 CRLF 형태의 2글자)로 인식하여 고스란히 글자수에 포함시킵니다. 따라서 문단이 여러 개인 글일수록 두 시스템 간의 숫자 격차는 눈덩이처럼 벌어지게 됩니다. 최종 제출 시에는 반드시 해당 웹 포털의 자체 카운터 기준을 우선시해야 합니다.

Q2. 최신 이모지(😀)나 복잡한 이모티콘을 넣으면 글자수나 바이트 한도에 어떤 영향을 미치나요?

A2. 이모지는 일반 텍스트에 비해 훨씬 많은 디지털 자원을 소모하므로 제한된 폼에서는 매우 치명적일 수 있습니다. 글자수(Length) 관점에서는 구형 시스템이나 자바스크립트 내장 함수 기준으로 1개의 이모지가 2~4글자 분량을 잡아먹습니다. 바이트(Byte) 관점에서도 UTF-8 인코딩 환경에서 하나의 이모지는 무려 4바이트의 용량을 차지하여, 한글 1글자(3바이트)나 영문 4글자(4바이트)를 포기해야 하는 페널티를 안게 됩니다. 바이트 제한이 빡빡한 SMS 문자나 자기소개서에서는 이모지 사용을 자제하는 것이 바람직합니다.

Q3. 글자수가 제한을 딱 20자 초과했는데, 내용 훼손 없이 분량을 압축하는 가장 좋은 팁은 무엇인가요?

A3. 내용의 논리를 해치지 않고 20자를 줄이는 최적의 방법은 세 가지가 있습니다. 첫째, 불필요하게 쪼개진 문단들을 합쳐 줄바꿈 기호가 소모하는 보이지 않는 글자수를 절약하세요. 둘째, '~하는 것 같습니다', '~라고 생각되어집니다'와 같은 습관적이고 장황한 수동태·추측성 어미를 '~합니다', '~입니다'로 과감히 쳐내십시오. 셋째, 정규식 찾기를 통해 문장 끝이나 단어 사이에 과도하게 들어간 스페이스바 잉여 공백들을 검색하여 모두 삭제하면 충분히 20자를 확보할 수 있습니다.