글자수와 바이트 세는 법

무엇을 세나

이 도구는 붙여 넣은 글에서 다섯 가지를 셉니다. 첫째는 글자수인데 공백을 포함한 값과 뺀 값을 함께 보여줍니다. 둘째와 셋째는 바이트인데 컴퓨터가 그 글을 저장할 때 실제로 차지하는 크기이고, 인코딩 방식에 따라 같은 글이 다른 바이트 수로 계산됩니다. 넷째는 단어수로 공백으로 나눈 조각 개수이고, 다섯째는 원고지 매수로 출판 관행인 200자 한 장 기준으로 환산한 값입니다.

바이트를 두 가지나 보여주는 이유는 회사마다 접수 시스템이 다른 인코딩 기준을 쓰기 때문입니다. 예전부터 운영해 온 국내 채용 시스템은 EUC-KR 기준을 쓰는 경우가 있고, 요즘 만들어진 웹 서비스는 대부분 UTF-8을 씁니다. 어느 쪽이 맞는지는 저희가 정할 수 없고, 공고문이나 접수창에 적힌 안내를 따라야 합니다.

기본 규칙

UTF-8과 EUC-KR이 왜 다른가

UTF-8은 지금 웹의 표준 인코딩이고, 완성형 한글 한 글자를 3바이트로 저장합니다. EUC-KR은 1990년대에 만들어진 한국어 인코딩(KS X 1001)으로, 완성형 한글 한 글자를 2바이트로 저장합니다. 그래서 같은 한글 문장이라도 UTF-8로 재면 EUC-KR보다 1.5배쯤 크게 나옵니다. 영어 알파벳이나 숫자, 마침표 같은 아스키 문자는 두 방식 모두 1바이트로 같습니다.

EUC-KR이 못 담는 글자도 있다

EUC-KR(KS X 1001)은 한글 음절을 전부 담지 못합니다. 현대 한글 음절은 총 11,172자인데, 이 표준은 그중 자주 쓰는 2,350자만 담습니다(저희 코드가 브라우저의 디코더를 거꾸로 돌려 실측한 값이라 지어낸 숫자가 아닙니다. 아래 이 앱의 세부 규칙에 이어집니다). 한자는 4,620자를 담습니다. "뷁", "힣"처럼 조합형에서만 쓰는 희귀 음절이나 이모지는 EUC-KR로 표현할 방법이 없어서, 그런 글자가 섞이면 저희는 바이트 수에서 빼고 몇 글자가 빠졌는지 따로 알려드립니다.

이 앱의 세부 규칙

여기부터는 저희 코드가 실제로 하는 일입니다(src/lib/euckr.ts, src/lib/count.ts).

EUC-KR 바이트는 표를 손으로 옮겨 적지 않았습니다. 자바스크립트 표준은 EUC-KR로 인코딩하는 기능을 제공하지 않지만(레거시 인코딩은 디코딩만 지원됩니다), 브라우저의 TextDecoder("euc-kr")는 정확합니다. 그래서 두 바이트 조합 8,836가지를 전부 디코드해 보고, 유효한 한 글자로 풀리는 조합만 남겨 표를 거꾸로 만들었습니다. 이 방식으로 나온 한글 2,350자, 한자 4,620자는 KS X 1001 표준의 한글 음절 수(2,350)와 정확히 일치합니다.

글자수는 자바스크립트 문자열의 코드 유닛 길이(string.length)를 씁니다. 사람인 글자수세기 도구를 2026년 9월 6일에 직접 열어 세 문장으로 대조했을 때 이 방식이 정확히 일치했고(46자와 39자, 54자와 47자, 109자와 85자), 같은 문장의 EUC-KR 바이트 수도 전부 일치했습니다(82와 75, 70과 63, 185와 161바이트). 표본과 방법은 docs/academic-basis.md에 남겨 두었습니다.

원고지 매수는 200자를 한 장으로 보는 통상 관행을 씁니다(공백 포함 글자수 기준, 올림 계산). 다만 이 기준은 출판사나 학교마다 199자를 쓰기도 하는 관행이라, 정확한 매수가 필요하면 제출하실 곳의 안내를 다시 확인해 주세요.

기본 요령

접수창에 적힌 글자 제한이 "공백 포함 500자"처럼 나와 있다면, 저희 화면의 공백 포함 글자수 칸을 보시면 됩니다. 제한 입력창에 500을 넣고 기준을 글자수로 두면 남은 글자가 바로 나와요. "바이트"라고만 적혀 있고 방식이 안 적혀 있다면, 우선 UTF-8을 써 보고 접수가 거절되면 EUC-KR 기준으로 다시 맞춰 보시는 편이 안전합니다(최근 시스템일수록 UTF-8일 확률이 높습니다).

단어수는 형태소를 분석하지 않고 공백으로만 나눕니다. 그래서 "저는 학생입니다"는 두 단어로 셉니다. 국어의 어절 개념과 같아서, 띄어쓰기가 그대로 단어 경계가 됩니다.

고급 요령

이모지나 희귀 한글 음절이 섞인 글을 EUC-KR 기준 시스템에 낸다면, 저희가 알려주는 "EUC-KR에 없는 글자" 개수를 0으로 만드는 편이 안전합니다. 그 글자들은 옛 시스템에 입력하면 물음표나 깨진 글자로 바뀔 수 있기 때문입니다. 특수문자나 이모지를 빼고 일반 문장부호(쉼표, 마침표, 물음표 등)로 바꿔 쓰면 EUC-KR로도 안전하게 저장됩니다.

공백 포함과 공백 제외 글자수 차이가 크다면 띄어쓰기가 많다는 뜻입니다. 자소서 글자수 제한은 공백 포함 기준을 쓰는 곳이 많으니, 공백 제외 기준으로 확인하고 제출했다가 초과로 잘리는 일이 없도록 두 값을 모두 확인하는 편이 좋습니다.

자주 막히는 부분

접수창 숫자와 안 맞아요. 접수창이 UTF-8을 쓰는데 EUC-KR 기준으로 보고 계셨거나, 그 반대인 경우가 가장 흔합니다. 두 값을 다 보시고 접수창에 다시 맞춰 보세요. 그래도 다르면 접수창이 공백을 다르게 세거나(예: 줄바꿈을 두 글자로 센다거나) 오래된 자체 계산식을 쓰고 있을 수 있어요. 그 경우는 저희가 확인할 방법이 없습니다.

원고지 매수가 예상과 달라요. 200자가 아니라 199자를 쓰는 곳도 있고, 공백을 빼고 세는 곳도 있습니다. 정확한 기준은 제출하실 곳에 문의해 주세요.

붙여넣은 글이 어디로 가나요. 아무 데도 안 갑니다. 이 브라우저 안에서 세어지고 서버로 보내지 않아요. 자세한 것은 개인정보 처리방침에 있어요.