글자수 세기

계산 예시

문자 종류별 바이트 수

이 도구는 국내 채용 시스템에서 통용되는 전각 2바이트 기준을 사용합니다. UTF-8 실제 인코딩에서 한글은 3바이트이며, 시스템에 따라 기준이 다를 수 있습니다.

자주 묻는 질문

자소서에 글자수 제한이 붙는 이유

채용 담당자 입장에서 분량 제한은 읽는 시간을 통제하는 장치입니다. 공채 한 직군에 수천 건의 지원서가 들어오는 상황에서 문항마다 길이가 제각각이면 검토 시간을 예측할 수 없고, 긴 글을 낸 지원자가 단순히 정보량 때문에 유리해지는 왜곡도 생깁니다. 모든 지원자에게 같은 칸을 주는 것은 평가의 공정성과 운영 효율을 동시에 확보하기 위한 최소한의 장치인 셈입니다.

동시에 제한 자체가 평가 항목이기도 합니다. 정해진 분량 안에 경험과 근거를 압축해 넣는 일은 실무에서 보고서나 회의 자료를 쓰는 능력과 직결되기 때문입니다. 같은 경험을 500자로 설명한 두 사람 중 한 명이 훨씬 선명하게 읽힌다면, 그 차이는 경험의 크기가 아니라 편집 능력의 차이로 읽힙니다. 그래서 분량을 아슬아슬하게 넘겨 억지로 잘라낸 글은 앞뒤가 끊기며 그 능력이 부족하다는 인상을 남기기 쉽습니다.

실무적으로는 제한의 80~100%를 채우는 것이 무난합니다. 절반만 채운 답변은 준비가 부족하거나 지원 의지가 낮다는 신호로 읽히는 경우가 많고, 반대로 제한을 넘긴 글은 입력 단계에서 문제가 생깁니다. 상당수 채용 시스템은 초과분을 조용히 잘라 저장하거나 저장 자체를 거부하는데, 마감 직전에 이 사실을 발견하면 손볼 시간이 없습니다. 제출 하루 전에는 분량 점검을 끝내 두는 편이 좋습니다.

시스템마다 글자수 기준이 다른 기술적 배경

같은 글을 두고 도구마다 다른 숫자가 나오는 근본 원인은 문자 인코딩, 즉 글자를 숫자로 바꿔 저장하는 방식이 여러 가지이기 때문입니다. 영문과 숫자만 담던 초기 ASCII는 한 글자에 1바이트를 썼습니다. 여기에 한글을 담기 위해 국내에서 쓰인 EUC-KR과 그 확장인 CP949는 한글 한 글자를 2바이트로 표현했습니다. 오늘날 웹 표준인 UTF-8은 문자마다 길이가 달라지는 가변 길이 방식으로, ASCII 문자는 1바이트, 라틴 확장이나 그리스·키릴 문자는 2바이트, 한글과 한자는 3바이트, 이모지는 4바이트를 씁니다.

그러니 '한글 1자는 몇 바이트인가'라는 질문에는 인코딩을 정하지 않으면 답할 수 없습니다. EUC-KR에서는 2바이트, UTF-8에서는 3바이트이고, 자바나 자바스크립트가 내부적으로 쓰는 UTF-16에서는 한글도 영문도 똑같이 2바이트입니다. 국내 채용 시스템의 바이트 제한이 대부분 2바이트 기준인 것은 그 제한값이 EUC-KR로 데이터베이스를 운영하던 시절에 정해졌기 때문입니다. 이후 시스템이 UTF-8로 옮겨간 뒤에도 지원자에게 익숙한 '2,000바이트'라는 숫자와 실질 분량을 유지하려고 계산 규칙만 관행으로 남겨둔 곳이 많습니다.

이 도구도 그 관행을 따릅니다. 문자의 코드 포인트가 U+007F 이하이면 1바이트, 그보다 크면 2바이트로 계산하므로 한글·한자·가나는 물론 원문자나 특수기호 같은 비ASCII 문자도 일괄 2바이트가 됩니다. 이모지는 UTF-8 실제 인코딩에서 4바이트를 차지하지만 이 도구에서는 2바이트로 집계되니, 이모지를 많이 쓴 글이라면 실제 시스템의 값과 벌어질 수 있습니다.

글자수 자체도 세는 단위에 따라 달라집니다. 이 도구는 코드 포인트를 기준으로 세기 때문에 이모지 하나가 1자로 잡히지만, 문자열 길이를 UTF-16 코드 단위로 재는 많은 프로그램에서는 같은 이모지가 2자로 계산됩니다. 반대로 국기나 가족 이모지처럼 여러 코드 포인트가 결합해 하나로 보이는 문자는 이 도구에서 2자 이상으로 잡힙니다. 일반적인 한글 자소서에서는 두 방식의 결과가 같으므로 신경 쓸 일이 거의 없지만, 특수 문자가 섞였다면 최종 확인은 실제 제출 화면의 카운터로 하는 것이 가장 확실합니다.

분량을 줄이면서 내용을 지키는 편집 기법

첫째, 술어를 압축합니다. '~하게 되었습니다'는 '~했습니다'로, '~라고 생각합니다'는 단정형으로, '~할 수 있었습니다'는 '~했습니다'로 바꿉니다. 문장마다 5~10자가 줄어들 뿐 아니라 표현이 단단해져 오히려 잘 읽힙니다. '~되어지다', '~에 의해 ~되었다' 같은 이중 피동도 능동으로 바꾸면 짧아집니다.

둘째, 명사화된 구절을 동사로 풉니다. '데이터 정합성 검증 작업을 수행하였습니다'는 '데이터 정합성을 검증했습니다'로 줄어듭니다. '~에 대한', '~에 있어서', '~을 통하여'처럼 조사를 늘리는 표현도 대부분 삭제하거나 한 글자짜리 조사로 대체할 수 있습니다.

셋째, 접속사와 강조 부사를 걷어냅니다. '그래서', '또한', '하지만', '매우', '정말', '굉장히'는 지워도 문맥이 거의 그대로 유지되는 경우가 많습니다. 자소서 한 편에서 이런 표현만 정리해도 보통 3~5% 분량이 빠집니다.

넷째, 문항 질문을 되풀이하는 서두를 삭제합니다. '제가 이 회사에 지원한 동기는 다음과 같습니다'로 시작하는 문장은 20자 이상을 쓰면서 아무 정보도 주지 않습니다. 곧바로 핵심 결론부터 쓰고 근거를 뒤에 붙이는 두괄식 구성으로 바꾸면 분량도 줄고 첫인상도 좋아집니다.

다섯째, 배경 설명을 수치로 압축합니다. 상황을 서너 문장으로 설명하는 대신 '3개월간 처리 시간 12% 단축', '주 5회 운영하던 회의를 2회로 축소' 같은 한 구절로 바꾸면 100자 가까이 아끼면서 구체성은 오히려 올라갑니다. 숫자는 읽는 사람에게 검증 가능한 근거로 읽히므로 남겨야 할 1순위 정보입니다.

여섯째, 같은 역량을 증명하는 에피소드가 둘 이상이면 하나로 통합합니다. 협업 능력을 보여주려고 팀 프로젝트 두 건을 나열했다면, 더 임팩트 있는 한 건만 깊이 쓰는 편이 분량과 설득력 양쪽에서 유리합니다. 일곱째, 한 문장에는 하나의 메시지만 담고 두 줄을 넘는 문장은 나누거나 후반부를 버립니다. 여덟째, 마지막 문단의 다짐성 마무리는 대체로 삭제 후보입니다. '입사 후 최선을 다하겠습니다' 류의 문장은 정보가 없어 가장 먼저 덜어내도 됩니다.

이 순서로 손보면 대개 원문의 15~25%가 줄어들고, 내용을 삭제하지 않고도 제한을 통과하는 경우가 많습니다. 한 단계 고칠 때마다 이 도구에 다시 붙여넣어 숫자가 얼마나 내려갔는지 확인하면, 어떤 기법이 자기 글에 가장 효과가 큰지도 자연스럽게 파악할 수 있습니다.

관련 계산기