글자수만 필요하면 어디서든 셀 수 있습니다. 실제로 막히는 건 바이트입니다. 한글은 인코딩에 따라 한 글자가 2바이트도 되고 3바이트도 됩니다.
| 인코딩 | 한글 1자 | 영문 1자 | 주로 쓰는 곳 |
|---|---|---|---|
| UTF-8 | 3바이트 | 1바이트 | 웹, JSON, 최근 DB |
| EUC-KR | 2바이트 | 1바이트 | 구형 시스템, 일부 공공 API, 레거시 DB |
그래서 VARCHAR(100) 컬럼에 한글을 몇 자 넣을 수 있는지가 시스템마다 다릅니다. UTF-8이면 33자, EUC-KR이면 50자입니다. “글자수는 맞는데 입력이 잘린다”는 대부분 여기서 옵니다.
함께 나오는 것
- 공백 포함·제외 글자수 — 원고료 정산과 과제 제출은 기준이 다릅니다
- UTF-8 / EUC-KR 바이트 — 컬럼 길이와 API 제한 확인용
- SMS 분할 — 90바이트를 넘으면 LMS로 넘어갑니다(EUC-KR 기준 한글 45자)
- 제목 길이 진단 — 검색 결과에 잘리지 않는 범위
- 키워드 반복 비중 — 같은 단어를 몇 번 썼는지. 과하면 읽기 나빠집니다
바이트를 세야 하는 실제 상황
- DB 컬럼 설계 —
VARCHAR(n)이 문자 기준인지 바이트 기준인지 DBMS마다 다릅니다. Oracle은 기본이 바이트, MySQLutf8mb4는 문자입니다. - 문자 메시지 발송 — 90바이트가 SMS와 LMS를 가릅니다. 요금이 달라집니다.
- 공공 API 연동 — 명세가 “한글 50자”라고만 적혀 있으면 EUC-KR 기준일 가능성이 높습니다.
- 파일명·URL — 인코딩에 따라 길이 제한에 걸리는 지점이 달라집니다.
이 도구가 재지 않는 것
이모지와 일부 한자는 UTF-8에서 4바이트이고, EUC-KR로는 아예 표현되지 않습니다. 결합 문자(조합형 한글, 일부 이모지)는 보이는 글자 수와 코드 포인트 수가 다릅니다. 정확한 저장 크기가 중요하다면 대상 시스템에서 직접 확인하세요.
인코딩 규격은 UTF-8 — RFC 3629에 정의돼 있습니다.