컬럼 타입은 단순한 "라벨"이 아닙니다. INSERT로 값 하나가 들어오는 순간, 선언된 타입은 그 값을 어떻게 검사하고, 어떤 형식으로 디스크에 눕히고, 나중에 어떻게 비교·계산하고, 인덱스에 어떻게 얹을지를 매 단계에서 지배합니다. 이 5단계를 알면 "왜 이 INSERT가 거부되지", "왜 합계가 1원 틀리지", "왜 인덱스를 안 타지"를 단계로 좁혀 진단할 수 있습니다. 타입 선택이 성능과 정확성을 가르는 지점이 바로 이 흐름 위에 있습니다.

[값 입력]  INSERT INTO t (price, code) VALUES (19.9, '00042')
   │
   ① 타입 검사·변환   선언된 타입으로 파싱·캐스팅하고 범위를 확인
   │                  범위 초과면 여기서 거부 (INT에 30억 → out of range)
   │
   ② 저장 형식 결정   고정 길이(INT 4B·CHAR(n))냐 가변 길이(VARCHAR·NUMERIC)냐,
   │                  정밀도·자릿수 확정 (DECIMAL=고정소수, FLOAT=이진 근사)
   │
   ③ 연산 규칙 적용   비교·산술 시 타입 규칙 — 같은 타입끼리 비교,
   │                  섞이면 암묵 형변환, FLOAT 합산은 오차가 누적
   │
   ④ 인덱스 반영      키 타입의 크기·정렬성이 B-트리 모양을 결정,
   │                  조건의 타입이 어긋나면 인덱스를 못 탄다
   │
   ⑤ 용량·성능        행 크기 = 타입 크기의 합 → 페이지당 행 수·I/O를 좌우
   ▼
[디스크]  좁고 순차적인 타입일수록 더 작고 빠른 테이블·인덱스

각 단계에서 무슨 일이 일어나고, 타입을 잘못 고르면 어떤 증상인가:

즉 "저장은 됐다"가 "타입이 맞다"는 뜻은 아닙니다. 문제가 생기면 이 5단계 중 어디서 어긋났는지로 좁힙니다 — INSERT 거부는 ①, 계산·정밀도 오차는 ②③, 느린 조회에서 Seq Scan이 보이면 ④(조건과 컬럼의 타입이 같은지 확인), 테이블·인덱스가 예상보다 크면 ⑤입니다. 뒤에서 다루는 정수 범위, DECIMAL vs FLOAT, CHAR/VARCHAR, 타임존 타입은 모두 이 흐름의 특정 단계를 깊이 파고드는 이야기입니다.

INT로 선언한 ID 컬럼이 21억을 넘었습니다. 더 이상 INSERT가 안 됩니다. 컬럼 타입을 BIGINT로 바꾸려면 수천만 건 테이블에서 ALTER가 몇 시간씩 걸리고, 그 사이 서비스는 멈춥니다. 처음부터 타입을 올바르게 선택하지 않으면 이 문제를 나중에 서비스 중단 없이 해결하기 어렵습니다.

확대

정수형 타입 범위

INT Overflow 실제 사례

2012년 Pinterest는 INT PK overflow 문제를 경험했습니다. 21억 개 이상의 레코드가 쌓이면 INT가 오버플로우하기 때문입니다. 아래는 잘못된 선택과 올바른 선택을 비교한 예시입니다. 미래가 불확실하다면 처음부터 BIGINT를 사용하는 것이 안전합니다.

CREATE TABLE posts (
    id INT PRIMARY KEY
);

실행 완료 또는 조회 결과가 표시됩니다.

CREATE TABLE posts (
    id BIGSERIAL PRIMARY KEY
);

실수형: DECIMAL vs FLOAT

FLOAT과 DOUBLE은 IEEE 754 부동소수점 방식으로 소수를 이진 근사값으로 표현합니다. 이 때문에 SELECT 1.1 + 2.2를 실행하면 3.3000000000000003처럼 정밀도 오류가 발생합니다. 금액 컬럼에는 절대 FLOAT을 사용하면 안 됩니다. DECIMAL(NUMERIC)은 정확한 십진수 연산을 보장합니다.

DECIMAL(precision, scale)에서 precision은 전체 유효 숫자 개수이고, scale은 소수점 이하 자릿수입니다. 예를 들어 DECIMAL(12, 2)는 최대 9999999999.99까지 저장할 수 있습니다.

FLOAT/DOUBLE은 과학적 계산이나 통계 분석처럼 근사값이 허용되는 경우에만 사용합니다.

CREATE TABLE payments (
    amount        DECIMAL(15, 2) NOT NULL,
    tax_rate      DECIMAL(5, 4),
    exchange_rate DECIMAL(10, 6)
);

CREATE TABLE sensor_readings (
    temperature DOUBLE PRECISION,
    humidity    FLOAT
);

문자형 타입 선택

세 가지 문자형 타입의 저장 방식은 다음과 같습니다.

• CHAR(n): 고정 길이. 항상 n바이트를 사용합니다. 데이터가 n보다 짧으면 나머지를 공백으로 채웁니다.
• VARCHAR(n): 가변 길이. 최대 n글자까지 저장하며, 실제 문자열 길이 + 1~2바이트(길이 정보)만 사용합니다.
• TEXT: 가변 길이. 길이 제한이 없습니다.

길이가 항상 고정된 데이터(국가 코드, 통화 코드 등)에는 CHAR를, 최대 길이가 정해진 가변 데이터에는 VARCHAR를, 길이 제한 없는 긴 텍스트에는 TEXT를 사용합니다.

TEXT 컬럼에는 인덱스 크기 제한이 있으므로 전체 텍스트 검색이 필요하다면 전문 검색 기능을 사용해야 합니다.

CREATE TABLE products (
    country_code CHAR(2)       NOT NULL,
    currency     CHAR(3)       NOT NULL,
    name         VARCHAR(100)  NOT NULL,
    email        VARCHAR(255)  NOT NULL,
    title        VARCHAR(500)  NOT NULL,
    description  TEXT,
    content      TEXT
);

VARCHAR 길이 선택 가이드

아래는 실무에서 각 필드 유형에 권장되는 VARCHAR 크기입니다. RFC 표준이나 알고리즘 출력 길이가 고정된 경우는 그 값을 그대로 따릅니다.

한국 서버에서 정상적으로 저장된 시간이 미국 서버로 마이그레이션하자 9시간이 틀어졌습니다. DATETIME을 쓴 것이 원인이었습니다. TIMESTAMP와 DATETIME 중 어느 것을 쓰느냐에 따라 타임존 변환 동작이 완전히 다릅니다. 잘못 선택하면 글로벌 서비스에서 반드시 시간 버그가 발생합니다.

확대

날짜/시간 타입 비교

TIMESTAMP vs TIMESTAMPTZ 차이

TIMESTAMP는 타임존 정보가 없어 입력값을 그대로 저장합니다. 서울(UTC+9) 세션에서 15:00:00을 저장하면 그냥 15:00:00이 저장되고, 이 값이 어느 타임존의 15시인지 DB는 알 수 없습니다.

TIMESTAMPTZ(TIMESTAMP WITH TIME ZONE)는 입력값을 UTC로 변환해 저장하고, 조회 시 세션 타임존에 맞게 자동으로 변환해 돌려줍니다. 같은 15:00:00 KST 값이 내부적으로 06:00:00 UTC로 저장되고, 뉴욕 타임존으로 조회하면 02:00:00 EDT로 변환됩니다.

INSERT INTO events (created_at_tz)
VALUES ('2026-04-07 15:00:00');

SELECT created_at_tz FROM events;

CREATE TABLE tz_demo (ts TIMESTAMP, tstz TIMESTAMPTZ);

SET TIME ZONE 'Asia/Seoul';
INSERT INTO tz_demo VALUES ('2026-04-07 15:00:00', '2026-04-07 15:00:00');

-- 같은 세션(서울)에서 조회
SELECT * FROM tz_demo;

-- 뉴욕 타임존으로 바꿔 다시 조회
SET TIME ZONE 'America/New_York';
SELECT * FROM tz_demo;

-- 서울 세션
         ts          |          tstz
---------------------+------------------------
 2026-04-07 15:00:00 | 2026-04-07 15:00:00+09

-- 뉴욕 세션 (ts는 그대로, tstz만 변환됨)
         ts          |          tstz
---------------------+------------------------
 2026-04-07 15:00:00 | 2026-04-07 02:00:00-04

날짜 타입 실무 패턴

생년월일이나 이벤트 날짜처럼 특정 날짜만 필요한 경우에는 DATE를 사용합니다. 레코드의 생성/수정 시각에는 TIMESTAMPTZ가 맞습니다. updated_at은 UPDATE가 발생할 때마다 자동으로 갱신되도록 트리거를 걸어 두는 것이 일반적입니다.

CREATE TABLE users (
    birthdate  DATE,
    joined_on  DATE NOT NULL DEFAULT CURRENT_DATE
);

CREATE TABLE products (
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

날짜 연산에는 EXTRACT와 INTERVAL을 활용합니다. 기간별 집계에는 DATE_TRUNC로 날짜를 월/주 단위로 잘라 GROUP BY에 사용합니다.

SELECT
    EXTRACT(YEAR FROM age(birthdate)) AS age,
    birthdate + INTERVAL '18 years'   AS adult_date
FROM users;

SELECT
    DATE_TRUNC('month', created_at) AS month,
    COUNT(*)                        AS orders_count
FROM orders
GROUP BY 1
ORDER BY 1;

특수 타입 정리

BOOLEAN은 TRUE, FALSE, NULL 세 가지 값을 가집니다. 기본값을 반드시 명시하는 것이 좋습니다.

UUID는 분산 환경에서 충돌 없이 전역 고유 ID가 필요할 때 사용합니다. 16바이트(INT의 4배)이므로 내부 PK는 BIGINT, 외부 노출용으로 UUID를 별도 컬럼에 두는 패턴을 권장합니다.

JSONB는 JSON을 바이너리로 저장해 인덱스를 지원하고 조회 속도가 빠릅니다. JSON은 텍스트로 저장하며 입력 순서를 보존하지만 인덱스를 사용할 수 없어 일반적으로 JSONB를 권장합니다.

ENUM은 컬럼 값을 특정 문자열 집합으로 제한합니다. 단, 값 추가/변경이 번거롭기 때문에 CHECK 제약이 더 유연한 대안이 될 수 있습니다.

CREATE TABLE users (
    is_active   BOOLEAN NOT NULL DEFAULT TRUE,
    is_verified BOOLEAN NOT NULL DEFAULT FALSE,
    metadata    JSONB   DEFAULT '{}'
);

CREATE TYPE order_status AS ENUM ('pending', 'paid', 'shipped', 'delivered', 'cancelled');

CREATE TABLE orders (
    status order_status NOT NULL DEFAULT 'pending'
);

타입 선택은 '정확성' 이야기로 끝나지 않습니다. 컬럼 타입의 물리 크기와 값의 순서(정렬성)는 B-트리 인덱스의 모양과 삽입 패턴을 직접 좌우합니다. 특히 PK/인덱스 키에서 이 차이가 성능으로 드러납니다.

• 크기: 좁은 타입일수록 한 페이지에 더 많은 키가 들어가 fanout이 커지고 트리 레벨이 낮아져, 조회 시 읽는 페이지가 줄어듭니다. INT(4B) PK 인덱스가 UUID(16B) 인덱스보다 작고 빠른 근본 이유입니다.
• 순서: 크기보다 삽입 순서가 더 중요할 때가 많습니다. 증가하는 키(BIGSERIAL, UUID v7)는 항상 B-트리의 오른쪽 끝에 추가돼 페이지가 순차로 차고 분할이 드뭅니다. 무작위 키(UUID v4)는 트리 곳곳에 삽입돼 페이지 분할(page split)이 잦고, 매번 다른 페이지를 건드려 캐시 지역성이 나빠지며, 변경 페이지가 WAL에 통째로 기록돼(full page write) 쓰기가 증폭됩니다.
• 부가 효과: 큰 값은 TOAST로 별도 저장·압축되고, 타입마다 정렬(alignment) 패딩이 붙어 실제 저장 크기가 달라집니다.

그래서 '분산 환경 대비 UUID'처럼 타입을 고를 때도, 그 타입이 인덱스 위에서 어떻게 삽입되는지를 함께 따져야 합니다.