ERROR - Updated 2026-05-15

DB varchar에서 한글이 잘리는 이유

DB varchar 컬럼에서 한글이 잘리거나 저장 오류가 나는 이유와 문자 수, byte, 문자셋, 컬럼 길이를 확인하는 방법.

DB varchar에서 한글이 잘리는 문제는 컬럼 길이, 문자셋, 애플리케이션 검증 기준이 서로 다를 때 자주 발생합니다. 한글은 UTF-8에서 보통 여러 byte를 차지하므로, 영문 기준으로 설계한 길이 제한이 한국어 서비스에서는 부족할 수 있습니다. 먼저 컬럼이 문자 수 기준인지 byte 기준인지 확인하고, 실제 입력값의 UTF-8 byte를 함께 계산해야 합니다.

증상

영문 이름은 저장되지만 한글 이름이나 상품명이 저장되지 않습니다.
저장은 되지만 끝부분이 잘려 표시됩니다.
DB 오류 메시지에 Data too long for column 또는 길이 초과가 나옵니다.
프론트엔드에서는 30자 이하인데 서버에서 거절됩니다.

원인

varchar의 길이 의미는 데이터베이스 종류, 버전, 문자셋, 컬럼 설정에 따라 다르게 체감될 수 있습니다. 또한 프론트엔드는 글자 수 기준으로 제한하고, 서버나 DB는 byte 기준으로 제한하는 식의 불일치가 생기면 한글만 문제가 되는 것처럼 보입니다.

확인 항목	왜 중요한가
DB 종류와 버전	varchar 길이 해석과 제한이 다를 수 있음
문자셋과 collation	UTF-8 계열인지, 레거시 문자셋인지 확인 필요
컬럼 길이	실제 저장 가능한 범위 확인
프론트엔드 검증	사용자에게 보여주는 제한과 DB 제한이 같은지 확인
서버 검증	API가 어떤 기준으로 자르는지 확인

바로 해결 방법

문제가 되는 실제 한글 입력값을 복사합니다.
Byte / Character Counter에서 글자 수와 UTF-8 byte를 확인합니다.
DB 컬럼 타입, 길이, 문자셋을 확인합니다.
프론트엔드와 서버의 길이 검증 기준을 DB 기준과 맞춥니다.
잘라야 한다면 글자 중간이나 이모지 중간이 깨지지 않도록 안전하게 자릅니다.

FixData 도구로 확인하기

Byte / Character Counter는 저장하려는 문구의 UTF-8 byte와 글자 수를 동시에 보여줍니다. "화면에서는 20자"인 값이 실제 저장에서는 몇 byte인지 확인해 DB 제한과 비교할 수 있습니다.

단, 도구는 DB별 varchar 동작을 대신 판정하지 않습니다. 실제 해결에서는 DB 스키마와 애플리케이션 validation 코드를 함께 봐야 합니다.

수동 해결 방법

제한 기준 통일하기

프론트엔드에서 maxlength=30을 걸어도 DB가 byte 제한으로 작동하면 한글에서는 부족할 수 있습니다. 사용자에게 보여주는 제한 문구와 서버 검증을 같은 기준으로 맞추세요.

컬럼 길이 재검토하기

상품명, 회사명, 주소, 메모처럼 다국어 입력이 들어오는 필드는 영문만 기준으로 길이를 정하면 위험합니다. 한국어, 일본어, 이모지, 공백, 괄호를 포함한 실제 샘플로 테스트해야 합니다.

안전하게 자르기

byte 기준으로 문자열을 자를 때는 문자 중간에서 끊기지 않게 처리해야 합니다. 그렇지 않으면 깨진 문자나 저장 오류가 생길 수 있습니다.

예제

영문 기준으로 충분해 보이는 컬럼:

VARCHAR(20)

하지만 실제 입력:

서울 강남구 테스트 상품명

한글과 공백이 포함되면 byte 기준으로는 예상보다 커질 수 있습니다. UI와 DB 모두에서 실제 한글 샘플을 넣어 확인해야 합니다.

자주 하는 실수

varchar 길이를 항상 byte 기준 또는 항상 문자 기준으로 단정합니다.
프론트엔드 maxlength만 있으면 DB 오류가 없을 것이라고 생각합니다.
한글과 이모지가 섞인 입력을 테스트하지 않습니다.
잘라내기 로직이 문자 중간을 끊는지 확인하지 않습니다.
오류를 인코딩 깨짐 문제로만 보고 컬럼 길이를 확인하지 않습니다.

업데이트 날짜

2026-05-15