글자 수는 맞는데 저장 제한에 걸릴 때: 문자와 바이트

SmartInfoBank 운영자 · 작성 2026-10-20 · 수정 2026-10-20 · 7분

입력창에서는 글자 수 제한을 넘지 않았는데 데이터베이스에 저장하거나 외부 API로 전송할 때 길이 초과 오류가 발생하는 경우가 있습니다. 사용자 눈에 보이는 글자 하나와 컴퓨터 메모리나 저장소에 기록되는 바이트 크기는 항상 1대1로 일치하지 않기 때문입니다. 이전 글인 한글 파일 깨짐: UTF-8 인코딩 확인하는 순서에서는 잘못 읽힌 텍스트의 복구를 다루었다면, 이번에는 입력 데이터의 바이트 길이 제한을 사전에 진단하는 기준을 살펴봅니다.

글자 수와 바이트 길이가 어긋나는 이유

현대 웹과 소프트웨어 환경에서는 기본 문자 인코딩으로 UTF-8을 널리 사용합니다. str.encode 공식 문서에 명시되어 있듯이, 파이썬의 문자열 인코딩 기본값 역시 UTF-8로 지정되어 있습니다. UTF-8은 가변 길이 인코딩 방식을 채택하고 있어 문자의 종류에 따라 1바이트부터 4바이트까지 크기가 달라집니다.

영문 알파벳과 숫자 같은 ASCII 범위 문자는 1바이트로 표현되지만, 완성형 한글은 3바이트, 그림 문자(이모지)는 4바이트를 차지합니다. 따라서 시스템 저장 공간의 컬럼 설정이 문자 수(Character) 기준인지, 물리적 바이트(Byte) 기준인지에 따라 허용 한도가 완전히 달라집니다.

검증 입력값과 문자별 바이트 크기

ASCII 영문, 한글 음절, 이모지가 각각 한 글자씩 포함된 3문자 문자열을 기준으로 코드 포인트 개수와 UTF-8 인코딩 시의 바이트 길이를 측정한 결과입니다.

{
  "text": "A가😊",
  "code_points": 3,
  "UTF8_bytes": 8,
  "byte_per_character": [
    [
      "A",
      1
    ],
    [
      "가",
      3
    ],
    [
      "😊",
      4
    ]
  ]
}

검증 결과에서 볼 수 있듯이 전체 문자열의 길이는 코드 포인트 기준으로 3이지만, UTF-8 바이트로 환산하면 8바이트가 됩니다. 만약 시스템의 입력 필드가 '최대 5바이트'로 설정되어 있다면, 사용자는 세 글자만 입력했음에도 3바이트가 초과되어 저장이 거부됩니다.

안전한 바이트 길이 점검 절차

입력 양식이나 연동 인터페이스에서 길이 제한 문제를 사전에 방지하려면 다음 순서로 점검합니다.

1. 저장소 명세 기준 확인: 데이터베이스 컬럼이나 전송 규격이 문자 개수(VARCHAR/CHAR 문자 단위)인지 물리적 바이트 단위인지 확인합니다.
2. 기본 코드 포인트 길이 측정: 프로그래밍 언어의 기본 문자열 길이 함수를 사용해 글자 수를 점검합니다.
3. 인코딩 바이트 크기 계산: 실제 전송 및 저장에 사용할 인코딩(일반적으로 UTF-8)으로 바이트 객체를 생성한 뒤 바이트 길이를 측정합니다.
4. 경계 지점 자르기 규칙 적용: 허용 길이를 초과하여 문자열을 잘라내야 할 경우, 바이트를 임의로 쪼개지 않고 완성된 문자 경계에 맞춰 조정합니다.

파이썬 코드로 바이트 길이 직접 확인하기

파이썬 표준 라이브러리의 str.encode() 메서드를 사용하면 문자열 전체 및 각 문자의 바이트 길이를 손쉽게 검증할 수 있습니다.

text = "A가😊"

# 전체 문자열 코드 포인트 개수와 UTF-8 바이트 크기
print("글자 수:", len(text))
print("바이트 수:", len(text.encode("utf-8")))

# 개별 문자별 바이트 크기 확인
for char in text:
    encoded = char.encode("utf-8")
    print(f"{char}: {len(encoded)}바이트 ({list(encoded)})")

이 스크립트를 실행하면 A는 1바이트, 가는 3바이트, 😊는 4바이트로 출력되며, 전체 합산 8바이트 결과가 도출됩니다.

실패 사례와 흔한 계산 착오

길이 계산에서 가장 흔히 일어나는 실수는 다음과 같습니다.

• 모든 비ASCII 문자를 2바이트로 간주: 과거 레거시 시스템(EUC-KR, CP949) 환경을 기준으로 한글을 무조건 2바이트로 계산하면, 3바이트를 사용하는 UTF-8 환경에서 버퍼 넘침이 발생합니다.
• 바이트 단위 강제 절단으로 인한 깨짐: 8바이트 제한에 맞추기 위해 바이트 배열을 단순 슬라이싱하면 3바이트 한글이나 4바이트 이모지의 중간 바이트가 잘려나가 디코딩 불가능한 손상 데이터가 저장될 수 있습니다.
• 이모지 4바이트 처리 미비: 구형 데이터베이스 설정(예: 3바이트까지만 수용하는 구형 utf8 설정)을 사용할 경우 4바이트 이모지가 입력되는 순간 쿼리 실패가 일어납니다.

이 점검 방식의 한계와 주의점

str.encode('utf-8')를 통한 바이트 검증은 UTF-8 규격에 맞는 물리적 저장 길이를 정확하게 보여주지만 다음과 같은 부분까지 보장하지는 않습니다.

첫째, 대상 시스템이 UTF-8이 아닌 UTF-16이나 다른 문자 집합을 사용하는 경우에는 바이트 수가 완전히 달라집니다. 시스템의 정확한 인코딩 설정을 함께 확인해야 합니다. 둘째, 사용자가 화면에서 인지하는 시각적 글자 단위(Grapheme Cluster)와 코드 포인트 개수가 항상 같지는 않습니다. 악센트 결합 문자나 피부색이 결합된 합성 이모지 등은 여러 개의 코드 포인트가 합쳐져 한 글자로 렌더링되므로, 화면 레이아웃 폭이나 시각적 글자 수 계산은 별도의 그래픽 단위 기준을 검토해야 합니다.