결정: 올바른 데이터 유형 선택

데이터 유형 선택은 나중에 고치기 가장 비용이 큰 결정 중 하나다: 잘못된 유형은 잘못된 결과(예: 금액에 float), 공간 낭비, 느린 쿼리를 낳는다. 이 트리는 숫자, 텍스트, 날짜/시간, 키(PK), 반정형(JSON), 카테고리(ENUM) 필드에 맞는 유형을 안내하며, 금액과 문자 집합 같은 대표적인 함정을 짚는다.

어떤 종류의 데이터를 저장하는가?

올바른 유형은 데이터의 성격으로 결정된다. 필드가 어느 범주에 속하는가: 숫자, 텍스트, 날짜/시간, 테이블의 기본 키, 유연/반정형(JSON) 데이터, 아니면 제한된 카테고리 집합인가?

• 숫자 값(수량, 금액, 측정값, 카운터)
• 텍스트(이름, 설명, 코드)
• 날짜 및/또는 시간
• 기본 키(PK)를 설계 중
• 유연/중첩/가변 필드(반정형 데이터)
• 제한되고 알려진 카테고리 집합(상태, 유형, 우선순위)

숫자가 정수인가 소수인가 — 그리고 금액인가?

숫자에서 가장 중요한 구분은 정확성이다. 값이 정수(수량, ID, 카운터)인가, 소수인가? 소수라면 금액/재무 금액인가? 이진 부동소수점(FLOAT/DOUBLE)은 반올림 오차를 만들므로 금액이나 정확성이 필요한 곳에는 절대 사용하지 않는다.

• 정수(수량, 카운터, id)
• 금액 또는 정확한 소수(가격, 잔액, 비율)

권장: 정수(SMALLINT / INT / BIGINT)

정수에는 필요한 범위를 포괄하는 가장 작은 유형을 선택한다. 불필요하게 큰 유형은 공간과 인덱스 크기를 낭비한다. 그러나 카운터/PK처럼 증가할 수 있는 필드에는 오버플로를 막기 위해 충분한 폭이 필수다.

권장: NUMERIC / DECIMAL — 금액에 FLOAT는 절대 금지

금액과 정확한 소수에는 고정소수점(정확한) NUMERIC/DECIMAL을 사용한다. FLOAT/DOUBLE은 이진 부동소수점이라 0.1 같은 값을 정확히 저장할 수 없다. 덧셈/곱셈에서 센트 단위 오차, 잘못된 잔액, 감사 문제가 발생한다.

권장: 텍스트 — VARCHAR vs TEXT vs CHAR

텍스트에는 가변 길이에 VARCHAR/TEXT를, 정말 고정된 길이에 CHAR를 사용한다. 최신 엔진에서 VARCHAR와 TEXT의 저장 차이는 대부분 무시할 수준이다. 실제 결정은 의미상의 한도(길이 제약)를 둘지 여부다.

권장: 날짜/시간 — 시간대를 포함한 TIMESTAMP

시점(이벤트 시각)을 저장한다면 시간대를 인식하는 유형을 선택한다. 시간대 없이 저장하면 리전/일광 절약 시간 변경 시 계산과 비교가 잘못된다.

권장: 기본 키 — BIGINT vs UUID

PK에는 두 가지 주요 옵션이 있다: 증가하는 숫자(BIGINT identity/sequence) 또는 UUID. 숫자 PK는 작고 인덱스 친화적이지만 예측 가능하고 중앙에서 생성해야 한다. UUID는 분산 생성이 가능하지만 더 크고 무작위 순서가 인덱스에 악영향을 줄 수 있다.

권장: JSON / JSONB — 적절히 사용

JSON 유형은 유연한 스키마, 중첩 또는 희소 필드에 강력하지만 관계형 규율(제약 조건, 인덱스, 타입 안전성)을 잃을 수 있다. 규칙: 고정적이고 자주 조회되는 필드는 일반 컬럼으로 옮기고, 정말 가변적인 부분만 JSON에 둔다.

권장: ENUM vs 룩업(참조) 테이블

제한된 카테고리 집합에는 두 가지 옵션이 있다: 엔진의 ENUM 유형, 또는 룩업 테이블 + 외래 키. ENUM은 간결하고 단순하지만 값 추가에 스키마 변경이 필요하다. 룩업 테이블은 유연하며 추가 속성(설명, 활성 플래그, 순서)을 가질 수 있다.