SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 느슨한 타입, 편하긴 한데 실수도 조용히 통과함

• 글쓴이의 핵심 주장은 간단함. SQLite를 쓸 때는 가능하면 STRICT 테이블을 기본으로 쓰자는 것임

  • SQLite는 기본적으로 타입에 꽤 관대해서, INTEGER 컬럼에 텍스트를 넣는 식의 실수도 받아줄 수 있음
  • 글쓴이는 이걸 “편의”라기보다 “나중에 디버깅 지옥을 여는 구멍”에 가깝게 봄

• STRICT 테이블을 만들려면 테이블 정의 끝에 STRICT만 붙이면 됨

  • 별도 확장이나 복잡한 설정이 아니라, CREATE TABLE ... STRICT 형태로 끝남
  • 이후 INSERT나 UPDATE에서 컬럼 타입이 맞지 않으면 SQLite가 에러를 냄

• 다만 SQLite가 완전히 꽉 막힌 타입 검사를 하는 건 아님

  • 예를 들어 문자열 '123'은 손실 없이 정수로 바꿀 수 있으니 INTEGER 컬럼에 들어갈 수 있음
  • 핵심은 “명백히 잘못된 타입”을 조용히 저장하지 않게 만드는 쪽에 가까움

테이블 만들 때부터 이상한 타입 선언을 막아줌

• SQLite 기본 모드에서는 말도 안 되는 컬럼 타입 이름도 테이블 생성 시 통과될 수 있음

  • 글쓴이는 이런 케이스를 오타, SQLite 타입 시스템에 대한 오해, 혹은 그냥 심각한 실수로 봄
  • STRICT를 붙이면 이런 선언은 바로 에러가 나므로, 문제를 스키마 작성 단계에서 잡을 수 있음

• STRICT 테이블에서는 컬럼 타입을 아예 생략하는 것도 안 됨

  • 예를 들어 CREATE TABLE tbl (name)처럼 타입 없는 컬럼을 만드는 방식은 허용되지 않음
  • 팀 프로젝트에서는 이런 제약이 오히려 문서화 효과를 냄. 스키마만 봐도 의도가 더 분명해지기 때문임

• 그래도 완전한 경직성만 강요하는 건 아니고, ANY라는 탈출구가 있음

  • ANY 타입 컬럼은 STRICT 테이블 안에서도 어떤 값이든 받을 수 있음
  • 키-값 저장소나 여러 타입의 잡다한 속성을 담는 컬럼이라면 이쪽이 맞을 수 있음
  • 글쓴이는 본인은 아직 쓸 일이 없었다고 하지만, SQLite 개발진이 말하는 유연한 타입의 사용처와 맞닿아 있음

단점도 있음. 특히 기존 테이블 마이그레이션이 귀찮음

• 이미 만들어진 일반 테이블을 ALTER TABLE로 바로 STRICT로 바꾸는 방법은 없어 보인다고 함

  • 현실적인 방법은 새 STRICT 테이블을 만들고, 기존 데이터를 복사하는 식의 마이그레이션임
  • 문제는 기존 데이터 안에 이미 잘못된 타입 값이 섞여 있으면 복사 과정에서 에러가 난다는 것

• 그래서 기존 SQLite DB에 뒤늦게 도입할 때는 데이터 청소가 먼저 필요할 수 있음

  • 숫자 컬럼에 문자열이 들어가 있으면 변환하거나 제거해야 함
  • “새 테이블부터만 STRICT로 하자”는 규칙도 가능하지만, 테이블마다 검증 강도가 달라져서 오히려 헷갈릴 수 있음

SQLite 개발진의 철학과는 살짝 결이 다름

• 흥미로운 지점은 SQLite 개발진이 유연한 타입 시스템을 단순한 실수로 보지 않는다는 점임

  • SQLite 공식 문서에는 “유연한 타입의 장점”을 설명하는 페이지가 있음
  • 순수 키-값 저장소, 여러 타입의 속성 저장, 지저분한 CSV를 원본 손실 없이 가져오는 경우 같은 예시를 듦

• 글쓴이는 이 철학을 이해하긴 하지만, 대부분의 경우에는 엄격한 타입이 낫다고 봄

  • 예상 못 한 데이터 타입 때문에 미묘한 버그를 겪은 경험이 많다고 함
  • 조용히 잘못 저장되는 것보다, 삽입 시점에 크게 터지는 편이 낫다는 입장임

• 이건 정적 타입 대 동적 타입 논쟁과도 닮아 있음

  • 빠르게 아무거나 넣을 수 있는 유연함이 좋은 상황도 있음
  • 반대로 장기 유지보수나 팀 개발에서는 “안 되는 건 안 된다”고 DB가 말해주는 편이 더 싸게 먹힐 때가 많음

버전 호환성과 성능은 체크해야 함

• STRICT 테이블은 SQLite 3.37.0부터 들어간 기능임

  • 해당 버전은 2021년 11월에 나왔음
  • 더 오래된 SQLite를 쓰는 환경이라면 이 기능 자체를 쓸 수 없음

• 더 중요한 건 구버전 SQLite가 STRICT 테이블이 포함된 DB를 읽지 못한다는 점임

  • 최신 SQLite에서 STRICT 테이블을 만든 뒤, SQLite 3.36.0 같은 구버전으로 열면 에러가 남
  • 모바일 앱, 임베디드 환경, 오래된 런타임에 SQLite가 묶여 있는 경우에는 배포 대상 버전을 꼭 확인해야 함

• 성능은 이론상 약간 느려질 수 있음

  • INSERT나 UPDATE 때 타입 검사를 추가로 해야 하기 때문임
  • 하지만 글쓴이가 100개 컬럼짜리 테이블에 수백만 행을 넣는 간단한 스크립트를 여러 머신에서 돌려봤을 때는 뚜렷한 차이가 없었다고 함
  • 디스크 파일 크기도 같았다고 함. 아주 엄밀한 벤치마크는 아니지만, 보통의 사용에서는 큰 부담으로 보기 어렵다는 쪽임

• 결론은 꽤 실용적임. SQLite를 대충 쓰지 말고, 실수를 줄이는 기본값을 고르자는 이야기임

  • STRICT는 만능 해결책은 아니지만, 잘못된 타입 저장이라는 흔한 버그 클래스를 줄여줌
  • 새 테이블을 만들 때 붙이는 비용은 낮고, 나중에 데이터가 오염된 뒤 치르는 비용은 훨씬 큼

---

기술 맥락

• SQLite는 원래 “값의 타입”을 더 중요하게 보는 쪽이라서, 다른 SQL 데이터베이스처럼 컬럼 타입을 강하게 강제하지 않아요. 이 설계는 작은 도구나 임시 데이터 저장에는 편한데, 앱이 커지면 잘못된 값이 조용히 누적될 수 있거든요.

• STRICT 테이블은 이 지점을 스키마 레벨에서 바꾸는 선택이에요. 애플리케이션 코드에서 매번 검증하는 대신, DB가 INSERT와 UPDATE 시점에 타입을 확인하게 해서 실수를 더 이른 단계에서 잡자는 거예요.

• 마이그레이션이 까다로운 이유도 여기 있어요. 기존 일반 테이블에는 이미 INTEGER 컬럼 안의 텍스트처럼 느슨한 데이터가 들어가 있을 수 있으니, 새 STRICT 테이블로 복사하는 순간 그동안 묵혀둔 문제가 한꺼번에 드러나요.

• 그래서 팀에서 SQLite를 실서비스 저장소로 쓴다면, 새 스키마부터 STRICT를 기본값으로 둘지 정하는 게 중요해요. 나중에 바꾸려면 코드 수정만이 아니라 데이터 정리, 배포 대상 SQLite 버전 확인, 구버전 호환성까지 같이 봐야 하거든요.