글자수와 바이트 — 자소서 1000바이트는 왜 한글 500자일까

자기소개서 입력창 아래에 이렇게 적혀 있습니다. "1000바이트 이내". 글자수도 아니고 바이트라니, 몇 자를 쓰라는 건지 감이 안 옵니다. 게다가 어떤 회사는 "공백 포함 1000자", 또 어떤 회사는 "공백 제외 700자"라고 씁니다.

기준이 제각각인 데는 이유가 있습니다. 이 글은 그 이유와, 제출 전에 반드시 확인해야 할 것들을 정리한 것입니다.

왜 글자수가 아니라 바이트로 제한할까요

바이트 제한은 옛날 시스템의 흔적입니다.

채용 사이트나 관공서 민원 시스템의 입력칸은 결국 데이터베이스의 한 컬럼에 저장됩니다. 예전 데이터베이스는 컬럼 크기를 글자 수가 아니라 저장 공간의 크기, 즉 바이트로 지정했습니다. 자소서 항목에 4000바이트를 잡아 뒀다면, 그것을 넘는 글은 저장하다가 잘려 나갑니다.

그래서 시스템은 "글자를 몇 개 썼는지"가 아니라 "저장하면 몇 바이트인지"로 막습니다. 사용자에게는 불친절하지만 시스템 입장에서는 정확한 기준인 셈입니다. 문제는 같은 글이라도 어떤 방식으로 저장하느냐에 따라 바이트 수가 달라진다는 점입니다.

한글 한 글자는 2바이트일 수도, 3바이트일 수도 있습니다

글자를 숫자로 바꿔 저장하는 규칙을 인코딩이라고 합니다. 어떤 인코딩을 쓰느냐에 따라 한글 한 글자가 차지하는 크기가 달라집니다.

인코딩	한글 1자	영문·숫자 1자
EUC-KR (완성형)	2바이트	1바이트
UTF-8	3바이트	1바이트

EUC-KR은 한글을 쓰기 위해 만든 오래된 방식이라 한글에 2바이트만 씁니다. UTF-8은 전 세계 문자를 한 체계에 담다 보니 한글에 3바이트가 듭니다. 자소서의 바이트 제한은 대체로 EUC-KR 기준이고, 웹과 최신 시스템은 UTF-8을 씁니다. 어느 쪽인지 모르겠다면 두 값을 모두 보고 작은 쪽에 맞추면 안전합니다. 도구는 UTF-8·EUC-KR·UTF-16 세 가지를 동시에 보여 주므로 내 글이 각각 몇 바이트인지 바로 확인할 수 있습니다.

1000바이트는 한글로 몇 자인가요

한글만 썼다면 계산은 간단합니다. EUC-KR 기준으로 바이트를 2로 나누면 됩니다.

즉 1000바이트는 한글 약 500자입니다. 같은 식으로 200바이트는 100자, 4000바이트는 2000자입니다.

다만 실제 글에는 공백과 마침표, 영문과 숫자가 섞입니다. 이것들은 1바이트씩만 먹기 때문에 섞일수록 쓸 수 있는 글자 수는 늘어납니다. 그래서 500자는 어디까지나 한글만 썼을 때의 하한선이고, 실제로는 550자쯤 들어가는 경우가 흔합니다. 여기서 대충 계산하다 마지막에 잘려 나가는 일이 생기니, 목표 바이트를 도구의 제한 체크에 넣어 두고 쓰는 편이 낫습니다. 기준을 EUC-KR로 고르고 목표를 입력하면 진행바와 함께 남은 바이트가 표시됩니다.

공백 포함인지 제외인지는 제출처마다 다릅니다

이건 규칙이 없습니다. 모집 요강에 적힌 대로 따라야 합니다.

• 공백 포함 — 띄어쓰기와 줄바꿈까지 다 셉니다. 가장 흔한 기준입니다.
• 공백 제외 — 띄어쓰기를 빼고 셉니다. 같은 글이 대략 20% 정도 적게 잡힙니다.

문제는 요강에 아무 말이 없는 경우인데, 이때는 공백 포함으로 맞춰 두는 것이 안전합니다. 더 빡빡한 기준이기 때문입니다. 도구는 공백 포함과 제외를 동시에 보여 주므로, 요강을 확인한 뒤 해당하는 숫자만 보면 됩니다.

한 가지 주의할 점. 줄바꿈도 문자입니다. 문단을 나누려고 엔터를 여러 번 누르면 그만큼 글자수와 바이트가 늘어납니다. 특히 시스템에 따라 줄바꿈 하나가 2바이트로 계산되기도 하니, 아슬아슬하다면 빈 줄부터 줄이십시오.

이모지는 생각보다 무겁습니다

이모지 하나는 화면에서 한 칸을 차지하지만 저장 공간은 그렇지 않습니다. 대부분의 이모지는 UTF-8에서 4바이트를 씁니다. 한글보다 큽니다.

게다가 이모지는 여러 조각이 합쳐진 경우가 많습니다. 피부색이 붙은 손 모양이나 가족 이모지처럼 여러 부호가 결합한 것은 글자수로도 여러 개로 세어집니다. 도구가 코드포인트 단위로 세기 때문에, 이런 이모지를 넣으면 화면에 보이는 개수보다 큰 숫자가 나옵니다. 이상한 게 아니라 시스템이 실제로 그렇게 셉니다.

또 하나. EUC-KR에는 이모지 자리가 아예 없습니다. 옛 인코딩이 만들어질 때 존재하지 않던 문자이기 때문입니다. 도구의 EUC-KR 값은 이런 문자를 2바이트로 어림해 계산한 참고값이고, 실제 EUC-KR 시스템에 붙여 넣으면 물음표나 깨진 글자로 바뀝니다. 바이트 제한이 걸린 서식에는 이모지를 쓰지 않는 편이 좋습니다.

트위터와 문자메시지는 또 다른 방식으로 셉니다

같은 글자수 세기인데 서비스마다 방식이 다릅니다.

X(트위터) 는 280자가 한도지만 한글·한자·일본어는 한 글자를 2로 계산합니다. 그래서 한글로만 쓰면 실질적으로 140자입니다. 영문 트윗보다 절반밖에 못 쓰는 이유가 이것입니다.

문자메시지(SMS) 는 바이트로 끊습니다. 국내 이동통신 기준으로 단문 한 건이 90바이트라, 한글로는 약 45자입니다. 이 선을 넘으면 장문(LMS)으로 자동 전환되고 요금이 달라집니다. 광고 문자를 쓸 때 45자에서 멈추는 이유가 여기 있습니다. 다만 세부 기준은 통신사와 발송 서비스마다 차이가 있으니 실제 발송 전에 해당 서비스의 안내를 확인하십시오.

제출 직전에 확인할 세 가지

① 붙여넣기 뒤 다시 셉니다. 워드나 한글에서 복사해 오면 서식이나 특수 공백이 함께 넘어와 바이트가 늘어나는 일이 있습니다. 붙여 넣은 뒤 최종 숫자를 다시 확인하십시오.

② 제출처 화면의 카운터와 비교합니다. 사이트마다 세는 규칙이 조금씩 달라, 도구에서 990바이트인 글이 제출 화면에서 1010바이트로 나올 수 있습니다. 최종 기준은 언제나 제출처의 카운터입니다.

③ 여유를 남깁니다. 딱 맞춰 두면 오탈자 하나 고치다가 초과됩니다. 제한의 95% 정도에서 마무리하는 편이 안전합니다.

자주 묻는 질문

Q. 도구 숫자와 제출 사이트 숫자가 다릅니다. 어느 쪽이 맞나요? 제출 사이트가 맞습니다. 사이트마다 줄바꿈을 어떻게 세는지, 어떤 인코딩을 쓰는지가 달라 몇 바이트씩 차이가 납니다. 이 도구는 쓰는 동안 분량을 가늠하는 용도로 쓰고, 마지막 확인은 제출 화면에서 하십시오.

Q. 원고지 매수는 어떻게 계산되나요? 공백을 포함한 전체 글자수를 200으로 나눈 뒤 올림합니다. 원고지 한 장이 200자이기 때문입니다. 201자를 쓰면 2매로 나옵니다.

Q. 예상 읽기 시간과 말하기 시간은 어떤 기준인가요? 눈으로 읽는 속도를 분당 500자, 발표하듯 말하는 속도를 분당 350자로 잡은 참고값입니다. 실제 속도는 사람과 내용에 따라 다르니 면접 답변이나 발표 원고 분량을 어림잡을 때만 쓰십시오.

Q. 단어 수는 어떻게 세나요? 공백을 기준으로 끊어 셉니다. 영어처럼 단어 사이를 띄우는 언어에서는 정확하지만, 한국어는 조사가 붙어 있어 어절 수에 가깝습니다.

Q. 입력한 글이 서버로 전송되나요? 아니요. 세는 작업은 전부 브라우저 안에서 일어나므로 자소서 초안을 붙여 넣어도 어디에도 저장되거나 전송되지 않습니다.

바이트 제한은 글쓰기 실력과 아무 상관이 없는, 순전히 기술적인 제약입니다. 그래도 마지막에 문장이 잘려 나가면 인상이 나빠지는 건 사실입니다. 분량은 쓰기 전에 정해 두고, 그 안에서 쓰는 것이 순서입니다.