CodeKitHub이 도구는 무엇인가요?
순수 ASCII 텍스트(영문자, 숫자, 기본 구두점)의 경우 문자 수와 바이트 수는 같은 숫자입니다—UTF-8에서 각 문자는 정확히 1바이트를 차지합니다. 악센트 문자, 중국어/일본어/한국어 문자, 키릴 문자, 아랍어, 이모지, 그 밖의 대부분 비ASCII 문자가 포함되면 더 이상 그렇지 않습니다. 하나의 문자가 UTF-8에서 2, 3, 또는 4바이트를, UTF-16에서 2 또는 4바이트를 차지할 수 있습니다.
이는 시스템이 문자 수가 아니라 바이트 수로 제한을 두는 모든 경우에 중요합니다—SMS 메시지, 데이터베이스 열 크기, API 페이로드 제한, 그리고 일부 소셜 플랫폼은 모두 문자가 아니라 바이트로 측정하므로, 어떤 언어나 기호가 포함되었는지에 따라 같은 텍스트라도 조용히 제한을 초과할 수 있습니다.
왜 사용해야 할까요?
- 트위터/X 스타일 자기소개 필드가 문자 수가 아니라 바이트 수로 제한을 거는데 이름에 이모지가 들어 있을 때 — 폼이 조용히 잘라내기 전에 여기서 실제 바이트 비용을 확인합니다.
- 앱의 데이터베이스 컬럼이 내부적으로 VARCHAR(255) 바이트 기준으로 정의되어 있고, '짧아 보이는' 일본어나 아랍어 상품명이 계속 거부될 때 — 여기 붙여넣으면 라틴 문자 제목보다 실제로 3배 많은 바이트를 쓰는 이유를 볼 수 있습니다.
- 다국어 마케팅 메시지가 SMS 몇 세그먼트를 쓸지 예상해야 할 때 — 통신사는 바이트 크기로 요금을 매기고 분할하므로, 여기서 UTF-8/UTF-16 바이트 수를 확인하는 게 대충 짐작해서 요금 폭탄 맞는 것보다 낫습니다.
- 엄격한 바이트 길이 검증기를 쓰는 JSON 필드에서 API가 알 수 없는 "payload too large" 오류를 반환하는데, 에디터에서는 문자열이 멀쩡해 보일 때 — 이 도구가 그 문자열이 실제로 몇 바이트인지 정확히 보여줍니다.
- 같은 문장이 언어에 따라 저장 용량을 더 많이 쓰는 이유를 비교하고 싶을 때 — 각 버전을 입력해보고 순수 ASCII 버전 대비 CJK나 아랍어 텍스트에서 UTF-8 바이트 수가 얼마나 뛰는지 확인합니다.
- 까다로운 검증 규칙이 사용자 이름의 이모지를 한 글자로 세는지 두 글자로 세는지 재확인해야 할 때 — 이 도구는 사람이 실제로 보는 방식대로 세므로, 다른 시스템이 잘못 세고 있는지 판단할 수 있습니다.
사용 방법
- 박스에 텍스트를 입력하거나 붙여넣습니다.
- 아래에 표시되는 문자 수, UTF-8 바이트 수, UTF-16 바이트 수를 확인합니다—입력하는 대로 업데이트됩니다.
예시
입력
Hello, 世界! 🌍결과
12자, UTF-8 19바이트, UTF-16 26바이트ASCII 부분('Hello, '와 '! ')은 UTF-8에서 문자당 1바이트를 차지합니다. 각 중국어 문자는 3바이트, 이모지는 4바이트를 차지하므로, 바이트 수가 문자 수보다 눈에 띄게 높습니다.
일반적인 활용
- 다국어 제품 설명이 문자 수가 아닌 바이트 길이로 정의된 데이터베이스 열에 들어맞는지 확인.
- SMS는 바이트 크기로 과금되고 분할되며 비라틴 텍스트는 세그먼트당 제한이 다르므로, SMS 세그먼트 사용량 추정.
- 제출 전에 API 페이로드나 폼 필드가 바이트 기반 크기 제한 이내인지 확인.
- '짧아 보이는' 문자열이 바이트 기반 길이 검사를 하는 시스템에서 거부되는 이유 이해.
문자 유형별 UTF-8 바이트 크기
아래 표는 문자 카테고리별 일반적인 UTF-8 바이트 비용을 보여줍니다 — 전체 텍스트를 붙여넣기 전에 다국어 텍스트가 실제로 얼마나 무거울지 가늠하는 데 유용합니다.
| 문자 유형 | 예시 | UTF-8 바이트 | UTF-16 바이트 |
|---|---|---|---|
| ASCII 문자/숫자 | A, 7 | 1 | 2 |
| 악센트 있는 라틴 문자 (é, ñ, ü) | é | 2 | 2 |
| 키릴 / 그리스 / 히브리 / 아랍 문자 | д, α, א | 2 | 2 |
| CJK(중국어, 일본어, 한국어) | 世 | 3 | 2 |
| 대부분의 이모지(BMP 밖) | 🌍 | 4 | 4 |
자주 묻는 질문
왜 문자 수와 바이트 수가 일치하지 않나요?
유니코드 텍스트는 바이트로 저장되며, 각 문자가 필요로 하는 바이트 수는 인코딩과 문자 자체에 따라 달라집니다. UTF-8에서 ASCII 문자는 1바이트, 대부분의 악센트가 있는 라틴 문자와 키릴/그리스/히브리/아랍 문자는 2바이트, 대부분의 CJK 문자는 3바이트, 이모지는 일반적으로 4바이트를 차지합니다. 문자 수는 저장 방식과 상관없이 단순히 기호의 개수를 셉니다.
바이트 제한이 있는 필드에는 어떤 바이트 수를 사용해야 하나요?
시스템이 텍스트를 저장하거나 전송할 때 실제로 사용하는 인코딩을 사용하세요—대부분의 최신 웹 API, 데이터베이스, 파일은 UTF-8을 사용하므로 보통 UTF-8 바이트 수가 관련된 숫자입니다. 일부 구형 시스템(Windows/Java 내부 문자열 처리 등)은 UTF-16을 사용합니다.
이모지도 정확하게 계산되나요?
네. 많은 이모지가 내부적으로 UTF-16 '서로게이트' 코드 유닛 쌍으로 저장되며, 단순한 계산 방식은 이를 2개의 문자로 셉니다. 이 도구는 유니코드 코드 포인트를 정확히 계산하므로, 이모지는 사람이 실제로 보는 문자 수와 일치하게 1개의 문자로 계산됩니다.
단어 수 카운터 도구와 같은 건가요?
아니요—단어 수 카운터는 글쓰기를 위한 단어 수와 문장 수에 초점을 맞춥니다. 이 도구는 단어 수 요건이 아니라 기술적 제한과 관련된, 바이트 크기 대 문자 수에 특화되어 있습니다.
제 텍스트가 어딘가로 업로드되나요?
아니요. 계산은 브라우저 안에서 JavaScript 내장 텍스트 인코더를 사용해 로컬로 이루어지며, 서버로 전송되는 것은 없습니다.
왜 같은 문자가 UTF-8과 UTF-16에서 서로 다른 바이트 수를 차지하나요?
두 인코딩은 코드 포인트를 바이트로 매핑하는 규칙이 완전히 다릅니다. UTF-8은 문자에 따라 1~4바이트를 쓰며 ASCII가 1바이트로 유지되도록 최적화되어 있습니다. UTF-16은 대부분 문자에 2바이트를 쓰고, 기본 다국어 평면 밖의 문자(대부분의 이모지 등)에만 4바이트를 씁니다 — 그래서 중국어 문자는 UTF-8에서 3바이트지만 UTF-16에서는 2바이트이고, 이모지는 둘 다 4바이트입니다.
피부톤이나 가족 이모지(여러 문자가 결합된 것)도 정확히 계산되나요?
이 도구는 유니코드 코드 포인트를 기준으로 세므로, 제로 너비 조인터로 여러 코드 포인트를 이어붙인 합성 이모지(가족 이모지 등)는 하나가 아니라 여러 문자로 계산됩니다 — 하나의 글리프로 보이더라도 실제 인코딩 방식과 일치하게 계산하는 것입니다.
일반 영어 텍스트에서는 UTF-8 바이트 수와 문자 수가 어떻게 다른가요?
ASCII 문자, 숫자, 공백, 기본 구두점만 쓰는 표준 영어 텍스트라면 둘은 동일합니다 — UTF-8에서 모든 문자가 정확히 1바이트이기 때문입니다. 악센트 문자, 기호, 비라틴 문자가 추가될 때만 차이가 나타납니다.
이걸로 트위터/X나 SMS 글자 수 제한을 정확히 확인할 수 있나요?
이 도구는 그런 제한의 기반이 되는 원시 문자 수와 바이트 수를 알려주지만, 플랫폼마다 자체 가중치 규칙을 적용하기도 합니다(예: 일부는 특정 이모지나 URL을 실제 길이와 무관하게 고정된 문자 수로 셈). 예외적인 경우는 해당 플랫폼의 구체적인 규칙을 확인하고, 이 도구로는 그 바탕이 되는 바이트 비용을 파악하는 데 활용하세요.