SQLite STRICT 테이블 2026, 데이터 적재 전 타입 검증·마이그레이션 기준

SQLite STRICT 테이블 데이터 품질 검증 워크스테이션 장면 — SQLite STRICT 테이블은 가벼운 내장 DB를 쓰면서도 타입 오류를 더 이른 단계에서 드러내는 선택지다.

SQLite를 데이터 적재 파이프라인의 임시 저장소로 쓰는 팀은 보통 “일단 넣고 나중에 정제하자”는 이유로 시작한다.

이 방식은 초기 비용을 줄이지만, INTEGER로 기대한 열에 텍스트가 섞이고 CSV 빈 문자열이 숫자 컬럼에 남는 순간부터 운영 비용이 뒤로 밀린다.

SQLite STRICT 테이블은 이 지점을 겨냥한다.

이 글은 GeekNews의 발견 신호를 출발점으로 삼되, SQLite 공식 문서를 기준으로 STRICT 테이블을 데이터 플랫폼 구축과 마이그레이션 관점에서 다시 정리한다.

결론부터 말하면 신규 핵심 테이블은 SQLite STRICT 테이블을 기본 후보로 놓고, 원본 보존용 landing table과 탐색용 scratch DB만 예외로 분리하는 편이 안전하다.

핵심 요약

SQLite STRICT 테이블은 테이블 단위로 더 엄격한 타입 규칙을 켜며, 컬럼 타입은 INT, INTEGER, REAL, TEXT, BLOB, ANY로 제한된다.
손실 없이 변환 가능한 값은 허용하지만, 맞지 않는 타입은 SQLITE_CONSTRAINT_DATATYPE 오류로 막아 데이터 품질 문제를 빨리 드러낸다.
기존 느슨한 테이블을 ALTER 하나로 바꾸는 흐름이 아니므로, 새 STRICT 테이블 생성과 데이터 복사, 검증, 교체 절차가 필요하다.
ANY는 무조건 피할 타입이 아니라 raw payload나 partner metadata처럼 형식이 바뀌는 값을 격리하는 안전판으로 쓰는 편이 낫다.

이 글이 필요한 사람

SQLite를 edge device, 모바일 앱, 로컬 캐시, ETL 중간 저장소로 쓰는 데이터 플랫폼 담당자.
CSV와 JSON 적재 후 타입 오류가 분석 쿼리나 리포트 단계에서 늦게 터지는 문제를 줄이고 싶은 개발자.
Postgres나 DuckDB로 가기 전 SQLite 기반 프로토타입의 운영 경계를 정해야 하는 테크 리드.
데이터 품질, 보안 감사, 장애 재현성을 이유로 가벼운 DB에도 스키마 기준을 넣어야 하는 운영팀.

SQLite STRICT 테이블이 바꾸는 것

SQLite 공식 문서는 기본적으로 유연한 타입을 SQLite의 특징으로 설명한다.

그러나 SQLite 3.37.0부터는 CREATE TABLE 정의 끝에 STRICT를 붙여 더 전통적인 타입 검사를 테이블 단위로 켤 수 있다.

차이는 단순한 문법 취향이 아니다.

느슨한 테이블은 데이터 수집 단계에서 오류를 숨기고, STRICT 테이블은 저장 단계에서 오류를 보이게 한다.

항목	일반 SQLite 테이블	SQLite STRICT 테이블	운영 의미
컬럼 타입	타입 이름을 유연하게 받아들임	INT, INTEGER, REAL, TEXT, BLOB, ANY만 허용	오타와 관습적 타입명을 생성 단계에서 걸러냄
값 삽입	컬럼 affinity에 따라 느슨하게 저장 가능	손실 없는 변환만 허용하고 불일치는 오류	나쁜 CSV와 API 응답을 조기에 드러냄
ANY 타입	유연한 저장이 기본 특성에 가까움	해당 컬럼에 한해 여러 타입을 보존	raw payload를 명시적으로 격리
무결성 검사	구조 오류 중심으로 확인	STRICT 컬럼의 저장 타입도 점검 대상	배포 후 품질 gate로 쓰기 쉬움
호환성	오래된 SQLite에서도 동작	SQLite 3.37.0 이상 필요	앱 내장 라이브러리 버전 확인 필수

데이터 플랫폼 구축에서 먼저 적용할 위치

SQLite STRICT 테이블은 모든 SQLite 파일을 기업 데이터베이스처럼 바꾸자는 주장이 아니다.

가장 좋은 시작점은 원본을 받은 뒤 비즈니스 의미를 부여하는 첫 번째 정제 테이블이다.

원본 보존용 landing table은 깨진 값까지 보존해야 할 수 있으므로, STRICT를 바로 켜면 감사와 재처리 근거를 잃을 수 있다.

반대로 집계, 청구, 리포트, 모델 입력처럼 downstream 비용이 큰 테이블은 타입 오류를 초기에 멈추는 편이 싸다.

테이블 위치	STRICT 기본값	이유	예외 조건
raw landing	보류	외부 원본을 손실 없이 보존해야 함	사전 validator가 있고 원본 백업이 별도 존재
staging 정제	검토	문자열 숫자와 빈 값 정리가 드러남	파트너마다 필드 타입이 매일 바뀜
core event	권장	분석·청구·알림이 직접 의존함	SQLite 3.37.0 미만 런타임이 섞임
local cache	권장	앱 버그와 캐시 오염을 빨리 잡음	완전 임시 캐시이며 재생성 비용이 낮음
scratch notebook	보류	탐색 단계에서는 유연성이 더 중요함	결과를 운영 테이블로 승격하기 직전

타입 설계에서 많이 틀리는 지점

STRICT 테이블에서는 컬럼 타입 이름을 자유롭게 적을 수 없기 때문에, 기존 SQL 습관을 그대로 가져오면 생성 단계에서 막힌다.

DATETIME, JSON, UUID 같은 이름은 운영 의도를 설명하는 데 익숙하지만, SQLite STRICT 테이블의 선언 타입으로는 그대로 쓰지 않는 편이 안전하다.

시간은 INTEGER epoch, TEXT ISO 8601, REAL Julian day 중 팀 기준을 정하고, JSON은 TEXT나 ANY와 검증 함수를 함께 설계해야 한다.

ID와 외부 식별자는 숫자로 보여도 TEXT로 두는 경우가 많다. 앞자리 0, 하이픈, 파트너별 prefix가 사라지면 복구 비용이 크다.
금액은 SQLite REAL의 부동소수점 특성을 이해해야 한다. 정밀한 회계가 필요하면 정수 cent 단위나 별도 검증 로직을 검토한다.
날짜는 DATETIME이라는 타입명을 기대하지 말고 INTEGER 또는 TEXT 저장 규칙과 CHECK 제약을 같이 문서화한다.
payload는 ANY로 둘 수 있지만, 핵심 조회 조건에 쓰는 값은 별도 TEXT, INTEGER, REAL 컬럼으로 승격한다.
BLOB은 실제 바이너리만 담고, JSON 문자열이나 base64를 편의상 숨기는 용도로 쓰지 않는다.

마이그레이션은 ALTER가 아니라 복사 전략으로 본다

기존 비엄격 테이블을 한 줄 ALTER로 STRICT 테이블로 바꾸는 운영 흐름을 기대하면 안 된다.

안전한 절차는 새 STRICT 테이블을 만들고, CAST와 정제 규칙을 명시한 뒤, 데이터 복사와 integrity_check를 통과시켜 교체하는 쪽이다.

이 과정에서 실패한 행은 성가신 예외가 아니라, 지금까지 downstream 쿼리가 조용히 떠안던 품질 부채다.

현재 SQLite 런타임과 배포 대상 앱의 SQLite 버전이 3.37.0 이상인지 확인한다.
대상 테이블의 typeof() 분포를 뽑아 기대 타입과 실제 저장 타입의 차이를 먼저 본다.
새 STRICT 테이블을 만들고, 허용할 ANY 컬럼과 CHECK 제약을 리뷰한다.
복사 SQL에는 CAST, NULL 처리, 기본값 정책을 명시하고 실패 행을 별도 파일이나 테이블에 남긴다.
PRAGMA integrity_check와 샘플 쿼리, 애플리케이션 회귀 테스트를 통과한 뒤 이름을 교체한다.
백업 테이블과 롤백 명령은 첫 배포 때 삭제하지 않고, 검증 기간이 끝난 뒤 정리한다.

마이그레이션 SQL 스켈레톤

아래 SQL은 느슨한 event 테이블을 SQLite STRICT 테이블로 옮길 때 검토할 수 있는 구조 예시다.

-- sqlite-strict-migration.sql
-- 목적: 느슨한 SQLite 적재 테이블을 STRICT 테이블로 옮기기 전 타입 오류를 노출한다.
-- 실제 컬럼명, 기본값, CHECK 제약, 인덱스, 트리거는 운영 스키마에 맞게 재작성한다.

PRAGMA foreign_keys = OFF;
BEGIN IMMEDIATE;

CREATE TABLE events_strict (
  event_id TEXT PRIMARY KEY,
  device_id TEXT NOT NULL,
  event_ts INTEGER NOT NULL,
  amount REAL,
  payload ANY,
  schema_version INTEGER NOT NULL DEFAULT 1,
  inserted_at TEXT NOT NULL
) STRICT;

INSERT INTO events_strict (
  event_id, device_id, event_ts, amount, payload, schema_version, inserted_at
)
SELECT
  CAST(event_id AS TEXT),
  CAST(device_id AS TEXT),
  CAST(event_ts AS INTEGER),
  CASE
    WHEN amount IS NULL OR amount = '' THEN NULL
    ELSE CAST(amount AS REAL)
  END,
  payload,
  COALESCE(CAST(schema_version AS INTEGER), 1),
  CAST(inserted_at AS TEXT)
FROM events_loose;

PRAGMA integrity_check;

ALTER TABLE events_loose RENAME TO events_loose_backup;
ALTER TABLE events_strict RENAME TO events;
COMMIT;
PRAGMA foreign_keys = ON;

이 예시는 운영 SQL을 대신하지 않는다.

핵심은 타입 변환 규칙을 SELECT 안에 숨기지 말고, 실패 행이 왜 실패했는지 티켓과 로그로 남기는 것이다.

사전 타입 감사 Python 스켈레톤

Python sqlite3 문서는 SQLite가 서버 프로세스 없이 파일 기반 DB로 동작하며 프로토타입과 내부 저장소에 쓰일 수 있다고 설명한다.

그 장점 때문에 더더욱 마이그레이션 전 읽기 전용 복제본에서 타입 분포를 먼저 확인해야 한다.

#!/usr/bin/env python3
# sqlite_strict_audit.py
# 목적: 마이그레이션 전에 SQLite 컬럼별 typeof() 분포를 확인한다.
# 이 스크립트는 점검용 스켈레톤이며, 운영 DB에서는 백업과 읽기 전용 복제본에서 먼저 실행한다.

from __future__ import annotations
import sqlite3
import sys

TARGET_TABLES = {
    "events_loose": ["event_id", "device_id", "event_ts", "amount", "payload"],
    "metrics_loose": ["metric_id", "metric_ts", "value", "tags"],
}


def quote_identifier(name: str) -> str:
    if not name.replace("_", "").isalnum():
        raise ValueError(f"unsafe identifier: {name}")
    return '"' + name + '"'


def audit_table(con: sqlite3.Connection, table: str, columns: list[str]) -> None:
    print(f"# table={table}")
    qtable = quote_identifier(table)
    for col in columns:
        qcol = quote_identifier(col)
        sql = f"SELECT typeof({qcol}) AS t, COUNT(*) FROM {qtable} GROUP BY typeof({qcol}) ORDER BY COUNT(*) DESC"
        rows = con.execute(sql).fetchall()
        print(col, rows)
    print()


def main() -> int:
    if len(sys.argv) != 2:
        print("usage: sqlite_strict_audit.py path/to/database.sqlite")
        return 2
    con = sqlite3.connect(f"file:{sys.argv[1]}?mode=ro", uri=True)
    for table, columns in TARGET_TABLES.items():
        audit_table(con, table, columns)
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

운영 DB에서는 이 스크립트를 직접 쓰기 전에 백업, 파일 잠금, WAL 모드, 장기 쿼리 영향을 확인해야 한다.

타입 분포 결과는 “몇 행이 실패했는가”보다 “어떤 upstream이 잘못된 값을 만들었는가”를 찾는 출발점이다.

운영 정책 YAML 스켈레톤

SQLite STRICT 테이블을 팀 표준으로 넣으려면 코드 리뷰 체크리스트보다 rollout 정책이 먼저 필요하다.

# sqlite-strict-rollout-policy.yaml
# 목적: SQLite STRICT 테이블을 데이터 적재 표준으로 넣기 전 운영 조건을 고정한다.
# 실제 값은 팀의 백업, 배포, 보안 감사 요구사항에 맞게 바꾼다.

scope:
  first_apply_to:
    - new_event_tables
    - edge_device_cache
    - csv_import_after_validation
  hold_for:
    - raw_landing_zone
    - schema_unknown_partner_feed
    - exploratory_notebook_scratch_db

migration:
  backup_required: true
  run_on_copy_first: true
  type_distribution_audit: required
  integrity_check_after_copy: required
  rollback_table_suffix: _backup

schema_rules:
  allowed_types:
    - INT
    - INTEGER
    - REAL
    - TEXT
    - BLOB
    - ANY
  use_any_only_for:
    - raw_payload
    - partner_metadata
  check_constraints_review: required

operations:
  owner: data-platform
  failure_ticket_required: true
  dashboard_metric: sqlite_strict_migration_failed_rows
  publish_after_rehearsal: true

이 정책은 STRICT 적용 범위를 작게 시작하게 만들고, raw landing과 탐색 DB를 무리하게 막지 않도록 균형을 잡는다.

보안팀에는 원본 보존과 실패 행 처리 기준을 설명하고, 데이터팀에는 downstream 품질 비용을 줄이는 기준으로 보여주는 편이 설득력이 높다.

실무 시나리오 1: 엣지 장비 이벤트 캐시

공장 장비나 매장 단말이 네트워크 불안정 때문에 SQLite에 이벤트를 임시 저장한 뒤 중앙 서버로 보내는 구조를 생각해보자.

device_id, event_ts, amount 같은 핵심 필드가 느슨하게 저장되면 중앙 적재가 늦게 실패하고, 현장 장애 시점에는 원인을 재현하기 어렵다.

이 조건이면 SQLite STRICT 테이블을 검토한다.

앱 배포판의 SQLite 버전이 통제되고, 이벤트 스키마가 명확하며, 실패 행을 로컬 quarantine 테이블에 남길 수 있는 경우다.

이 경우는 보류한다.

파트너 장비가 임의 payload를 계속 바꾸고, 원본을 절대 손실하면 안 되며, 중앙에서 한 번 더 정제할 체계가 이미 있는 경우다.

실무 시나리오 2: CSV 분석 프로토타입의 운영 승격

분석가가 CSV를 SQLite에 넣어 빠르게 대시보드를 만든 뒤, 그 파일이 어느 순간 팀 운영 리포트의 근거가 되는 경우가 있다.

처음에는 유연한 타입이 속도를 주지만, 운영 승격 후에는 빈 문자열과 숫자 문자열이 지표 차이를 만들 수 있다.

이 조건이면 승격 직전에 SQLite STRICT 테이블로 복사한다.

컬럼 의미가 고정됐고, 대시보드가 같은 쿼리를 반복 실행하며, 실패 행을 사람이 정리할 시간이 있는 경우다.

이 경우는 보류한다.

탐색 중인 데이터셋이고, 컬럼 자체가 자주 바뀌며, 버리는 실험 파일까지 STRICT 마이그레이션으로 관리하려는 경우다.

비용·보안·운영 리스크

SQLite STRICT 테이블의 비용은 성능 오버헤드보다 사람과 절차에서 더 자주 생긴다.

타입 오류가 빨리 보이면 좋지만, 실패 행을 누가 처리할지 정하지 않으면 배포 파이프라인이 멈춘 이유만 늘어난다.

리스크	실패 징후	사전 통제	담당자
마이그레이션 실패	CAST 중 오류가 나고 배포가 중단됨	typeof() 감사와 실패 행 quarantine	데이터 엔지니어
원본 손실	STRICT 복사 과정에서 깨진 값을 버림	raw landing과 백업 파일 유지	플랫폼 운영
앱 호환성	구버전 SQLite 런타임에서 파일을 열지 못함	배포 대상 SQLite 버전 inventory	클라이언트 개발
보안 감사	payload에 개인정보가 섞인 채 ANY로 방치됨	ANY 컬럼 용도와 보존 기간 정의	보안팀
분석 오류	숫자 문자열과 실제 숫자가 섞여 지표가 흔들림	STRICT core table과 지표 회귀 테스트	BI 담당자