(MySQL을 기준으로) VARCHAR의 크기는 얼마가 적당할까? CHAR와의 차이는 무엇일까?

[DB] CHAR와 VARCHAR: 최적의 문자열 데이터 타입 설계를 위한 심층 분석

데이터베이스 스키마를 설계할 때, 습관적으로 VARCHAR(255)와 같이 문자열 데이터 타입을 설정하는 경우가 많습니다. 그러나 이러한 관행이 과연 최적의 선택일까요? "왜 이 컬럼을 VARCHAR(255)로 지정하셨나요?"라는 질문을 계기로, VARCHAR의 크기 설정이 데이터베이스 성능에 미치는 영향과 CHAR 타입과의 근본적인 차이점을 심도 있게 분석해 보았습니다.

본 아티클에서는 CHAR와 VARCHAR의 내부 동작 방식과 성능 특성을 비교하고, 다양한 데이터 유형에 따른 최적의 타입 및 크기 선정 전략을 제시하여 데이터베이스 설계를 한 단계 발전시키는 것을 목표로 합니다.

1. CHAR vs. VARCHAR: 핵심 차이점 분석

두 데이터 타입의 가장 본질적인 차이는 데이터 저장 방식에 있습니다.

1-1. CHAR: 고정 길이(Fixed-Length) 방식

CHAR 타입은 선언된 길이만큼의 저장 공간을 항상 고정적으로 차지합니다. 예를 들어, CHAR(10)으로 선언된 컬럼에 'hello' (5바이트)를 저장하면, 실제 데이터인 5바이트와 나머지 5바이트를 채우는 공백(space padding)을 포함하여 총 10바이트의 공간이 할당됩니다.

• 장점: 모든 데이터의 길이가 동일하므로, 행(Row) 내에서 데이터의 시작 위치를 빠르게 계산할 수 있어 아주 미세하게나마 데이터 접근 속도에서 이점을 가질 수 있습니다.
• 단점: 실제 데이터 길이에 상관없이 항상 선언된 길이만큼 공간을 차지하므로, 데이터 길이가 가변적일 경우 심각한 공간 낭비를 초래할 수 있습니다.

1-2. VARCHAR: 가변 길이(Variable-Length) 방식

VARCHAR 타입은 실제 저장되는 데이터의 길이에 따라 사용하는 공간이 달라집니다. 데이터 자체의 길이와 더불어, 해당 데이터의 길이를 명시하는 **1~2바이트의 접두사(Length Prefix)**가 추가로 필요합니다.

• 데이터 길이가 255바이트 이하일 경우 1바이트의 접두사가, 255바이트를 초과할 경우 2바이트의 접두사가 사용됩니다.
• 장점: 데이터 길이에 맞춰 공간을 할당하므로, 길이가 다양한 데이터를 저장할 때 저장 공간을 매우 효율적으로 사용할 수 있습니다.
• 단점: 길이를 나타내는 접두사를 추가로 저장해야 하며, 행 업데이트 시 데이터 길이가 변경되면 행의 재배치(Row Migration)가 발생할 수 있습니다.

1-3. 비교 요약

구분	CHAR (고정 길이)	VARCHAR (가변 길이)
길이 유형	고정 길이 (Fixed-Length)	가변 길이 (Variable-Length)
공간 할당	선언된 길이만큼 고정 할당 (남는 공간은 공백으로 채움)	실제 데이터 길이 + 길이 정보 (1~2 bytes)
공간 효율성	데이터 길이가 항상 동일할 때 우수	데이터 길이가 가변적일 때 압도적으로 우수
최대 길이	255 (문자셋에 따라 바이트는 다름)	65,535 (테이블 전체 행 크기 제한 내에서)
값 비교	후행 공백(trailing space)을 제거하고 비교	후행 공백을 포함하여 정확하게 비교

CHAR 타입의 적절한 사용 사례
국가 코드(KR, US 등), 성별(M/F), Y/N 플래그와 같이 데이터의 길이가 항상 동일함이 보장되는 경우에 CHAR를 사용하는 것이 합리적입니다. 대부분의 일반적인 상황에서는 VARCHAR가 더 효율적인 선택입니다.

---

2. VARCHAR 크기, 왜 신중하게 설정해야 하는가?

"어차피 가변 길이이므로 VARCHAR(65535)처럼 최댓값으로 설정해도 무방하지 않을까?"라고 생각할 수 있지만, 이는 데이터베이스 성능에 심각한 악영향을 미칠 수 있는 잠재적 위험 요소입니다.

2-1. 메모리 사용량 증가와 성능 저하

MySQL은 정렬(ORDER BY)이나 그룹화(GROUP BY) 같은 연산을 수행할 때, 효율적인 처리를 위해 메모리 상에 임시 테이블(Temporary Table)을 생성할 수 있습니다. 이때, 임시 테이블의 컬럼 크기는 원본 테이블에 선언된 VARCHAR의 최대 길이를 기준으로 메모리를 할당하려는 경향이 있습니다.

예를 들어, 평균 길이가 15자인 사용자 이름을 저장하는 username 컬럼이 있다고 가정해 봅시다.

• A: username VARCHAR(50)
• B: username VARCHAR(5000)

두 경우 모두 실제 데이터의 크기는 같지만, 100만 건의 데이터를 username으로 정렬하는 쿼리를 실행하면, B의 경우 MySQL은 한 행당 최대 5000자에 해당하는 메모리를 확보하려 시도합니다. 이는 메모리 할당량을 급격히 증가시켜 결국 메모리 부족으로 이어지고, 성능이 현저히 느린 디스크 기반 임시 테이블(On-disk temporary table)을 사용하게 만듭니다. 결과적으로 쿼리 성능은 극단적으로 저하됩니다.

2-2. 비효율적인 인덱스

VARCHAR 컬럼에 생성된 인덱스의 크기 또한 선언된 최대 길이에 영향을 받습니다. 불필요하게 큰 VARCHAR 크기는 다음과 같은 문제를 야기합니다.

• 인덱스 크기 증가: 디스크 공간을 더 많이 차지하며, I/O 비용을 증가시킵니다.
• 캐시 효율 감소: 한정된 버퍼 풀(Buffer Pool) 메모리에 더 적은 수의 인덱스 페이지만 캐시할 수 있게 되어, 캐시 히트율(Cache Hit Ratio)이 낮아지고 디스크 접근이 빈번해져 성능이 저하됩니다.
• 인덱스 관리 비용 증가: 인덱스를 생성하거나 수정(INSERT, UPDATE, DELETE)할 때 더 많은 비용이 소요됩니다.

결론적으로 VARCHAR의 크기는 "Just Large Enough", 즉 예상되는 데이터의 최대 길이를 충분히 수용하면서도 불필요한 낭비가 없도록 정밀하게 설정하는 것이 핵심입니다.

---

3. 데이터 유형별 최적 타입 선정 가이드

1) 고정 길이 데이터

• 국가 코드 (ISO 3166-1 alpha-2): 항상 2자리 문자.
  • 권장: CHAR(2)
• 비밀번호 해시 (SHA-256): 결과는 항상 64자리의 16진수 문자열.
  • 권장: CHAR(64)
  • 최적화: BINARY(32) - 16진수 문자열을 이진 데이터로 저장하여 공간을 절반으로 줄일 수 있습니다.

2) UUID

UUID ('f81d4fae-7dec-11d0-a765-00a0c91e6bf6')를 CHAR(36)으로 저장하는 것은 공간 및 인덱스 효율성 측면에서 매우 비효율적입니다.

• 문제점: 36바이트의 큰 저장 공간, 비효율적인 문자열 인덱스.

• 해결책: 하이픈(-)을 제거하고 16진수 문자열을 16바이트의 이진 데이터로 변환하여 저장합니다. MySQL 8.0 이상에서는 UUID_TO_BIN(), BIN_TO_UUID() 함수를 제공합니다.

  • 권장: BINARY(16)

  • 사용 예시:

    -- 저장 시
    INSERT INTO my_table (id, ...) VALUES (UUID_TO_BIN(UUID()), ...);
    
    -- 조회 시
    SELECT BIN_TO_UUID(id), ... FROM my_table;

  • 기대 효과: 저장 공간 50% 이상 절감 및 인덱스 성능 대폭 향상.

3) IP 주소

IP 주소('192.168.0.1')를 VARCHAR(15)와 같은 문자열로 저장하는 것보다 정수형으로 저장하는 것이 훨씬 효율적입니다.

• 해결책: IP 주소를 정수형으로 변환하여 저장합니다. MySQL은 INET_ATON(), INET6_ATON() 등의 변환 함수를 지원합니다.

  • IPv4 권장: INT UNSIGNED (4바이트)

  • IPv6 권장: VARBINARY(16) (16바이트)

  • 사용 예시:

    -- IPv4 저장/조회
    INSERT INTO logs (ip_address) VALUES (INET_ATON('192.168.1.100'));
    SELECT INET_NTOA(ip_address) FROM logs;
    
    -- IPv6 저장/조회
    INSERT INTO logs (ip_address) VALUES (INET6_ATON('2001:db8::1'));
    SELECT INET6_NTOA(ip_address) FROM logs;

  • 기대 효과: 저장 공간 절약 및 숫자 기반의 빠른 비교/범위 검색 가능.

4) 일반적인 가변 길이 데이터

• 이메일 주소: RFC 표준상으로는 매우 길 수 있으나, 현실적으로 255자를 넘는 경우는 극히 드뭅니다.
  • 권장: VARCHAR(255)
• 사용자 이름/닉네임: 서비스 정책에 따라 가변적입니다.
  • 권장: VARCHAR(20) ~ VARCHAR(50) 등 정책에 맞게 설정.
• 게시글 제목:
  • 권장: VARCHAR(255)
• 긴 텍스트 (게시글 본문 등): VARCHAR의 최대 길이(65,535바이트)를 초과하는 데이터는 TEXT 계열 타입을 사용해야 합니다. 단, TEXT 타입은 인덱스 생성에 제약이 있으므로(prefix indexing만 가능), 신중한 접근이 필요합니다.

---

결론: 현명한 설계가 안정적인 미래를 보장한다

데이터 컬럼의 타입을 결정하고 크기를 설정하는 것은 단순히 데이터를 저장하는 차원을 넘어, 데이터베이스의 메모리 사용 효율, 쿼리 성능, 인덱스 효율성까지 결정하는 핵심적인 설계 과정입니다.

핵심 요약:

1. 길이가 고정된 데이터는 CHAR, **가변적인 데이터는 VARCHAR**를 사용하는 것이 기본 원칙입니다.
2. VARCHAR의 크기는 예상되는 최대 길이를 고려하여 필요한 만큼만 타이트하게 설정해야 합니다. 이는 메모리 관리와 인덱스 성능에 직접적인 영향을 미칩니다.
3. UUID, IP 주소와 같은 특수한 데이터는 문자열이 아닌, BINARY, INT 등 전용 타입과 내장 함수를 활용하여 저장 효율과 검색 성능을 극대화해야 합니다.