데이터베이스 스키마란?

데이터베이스 스키마는 클래스, 열, 타입, 관계처럼 데이터가 구성되는 방식을 정의하되 데이터 자체는 담지 않는 설계도입니다. 외워 둘 만한 한 줄짜리 삼각 구도가 있습니다. 스키마는 설계도이고, 인스턴스는 한 시점의 데이터이며, 데이터베이스는 건물 전체입니다. 설계도는 드물게 그리고 의도적으로 바뀌지만, 방은 끊임없이 다시 채워집니다.

핵심 요약

글로 적은 설계도

스키마를 그 본래의 언어로 적은 것입니다. 테이블 두 개, 키, 제약 조건 하나, 인덱스 하나, 뷰 하나로, 핵심 어휘 대부분이 여기에 있습니다:

CREATE TABLE users (
  id     bigserial PRIMARY KEY,
  email  text NOT NULL UNIQUE,               -- 제약 조건: 중복 불가
  role   text NOT NULL DEFAULT 'member'
);

CREATE TABLE orders (
  id      bigserial PRIMARY KEY,
  user_id bigint NOT NULL REFERENCES users(id),   -- 관계
  total   numeric(10,2) CHECK (total >= 0),       -- 데이터가 따라야 하는 규칙
  placed  timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX orders_by_user ON orders (user_id, placed);  -- 물리 계층
CREATE VIEW recent_orders AS                              -- 뷰 계층
  SELECT * FROM orders WHERE placed > now() - interval '30 days';

스키마가 유연한 플랫폼에서는 같은 설계도가 저장하는 데이터로부터 자라납니다. 첫 쓰기에서 타입이 지정된 열이 추론되고, 대시보드에 즉시 표시됩니다:

// JavaScript / Node.js — Back4app JS SDK
// The schema grows typed columns from what you save
const event = new Parse.Object('Event');
event.set('name', 'Launch day');                          // String
event.set('seats', 120);                                  // Number
event.set('startsAt', new Date('2026-09-01T18:00:00Z'));  // Date
event.set('venue', new Parse.GeoPoint(38.72, -9.14));     // GeoPoint
await event.save(); // columns exist, typed, visible in the dashboard

// Flutter / Dart — Back4app Flutter SDK
// The schema grows typed columns from what you save
final event = ParseObject('Event')
  ..set('name', 'Launch day')                          // String
  ..set('seats', 120)                                  // Number
  ..set('startsAt', DateTime.parse('2026-09-01T18:00:00Z')) // Date
  ..set('venue', ParseGeoPoint(latitude: 38.72, longitude: -9.14));
await event.save(); // columns exist, typed, visible in the dashboard

// iOS / Swift — Back4app Swift SDK
// The schema is a typed struct — columns mirror the model
struct Event: ParseObject {
  var objectId: String?; var createdAt: Date?
  var updatedAt: Date?; var ACL: ParseACL?; var originalData: Data?
  var name: String?          // String column
  var seats: Int?            // Number column
  var startsAt: Date?        // Date column
  var venue: ParseGeoPoint?  // GeoPoint column
}
var event = Event(); event.name = "Launch day"; event.seats = 120
event.save { _ in } // columns exist, typed, visible in the dashboard

// Android / Kotlin — Back4app Android SDK
// The schema grows typed columns from what you save
val event = ParseObject("Event").apply {
  put("name", "Launch day")                          // String
  put("seats", 120)                                  // Number
  put("startsAt", Date())                            // Date
  put("venue", ParseGeoPoint(38.72, -9.14))          // GeoPoint
}
event.saveInBackground() // columns exist, typed, visible in the dashboard

논리 vs. 물리 vs. 뷰

세 번째 행은 대부분의 설명 글이 건너뛰는 실제 모호함을 해소합니다. 일부 엔진에서 이 단어는 테이블을 담고 권한이 걸린 컨테이너인 네임스페이스도 가리키므로, “스키마”는 앱의 설계도일 수도 있고 데이터베이스 안의 폴더일 수도 있으며, 어느 쪽인지는 문맥이 정합니다.

쓰기 시점 스키마 vs. 읽기 시점 스키마

“스키마리스” 데이터베이스에도 스키마가 있습니다. 비용을 다른 방식으로 청구할 뿐입니다. 쓰기 시점 스키마(schema-on-write)는 데이터가 들어오기 전에 구조를 검증합니다. 잘못된 타입, 누락된 필드, 깨진 참조는 입구에서 거부됩니다. 읽기 시점 스키마(schema-on-read)는 쓰기를 유연하게 받아들이고 데이터를 사용할 때 기대를 강제합니다. 반복은 빨라지지만, 모든 읽는 쪽이 검증자가 됩니다. 현대의 입장은 전쟁이 아니라 다이얼입니다. 문서 플랫폼은 검증을 추가하고, 관계형 엔진은 JSON 열을 추가하며, 관리형 백엔드는 그 중간을 택합니다. 열마다 타입이 추론되고 강제되면서도, 새 열은 마이그레이션 절차 없이 생깁니다. 엄격함의 문제는 사실 소유권의 문제입니다. 잘못된 레코드를 누가 찾아내는가, 쓰기 시점의 데이터베이스인가, 새벽 2시에 돌아가는 애플리케이션 코드인가?

스키마는 어떻게 진화하는가

설계도는 첫 초안보다 오래 살아남으며, 마이그레이션은 설계도가 혼란 없이 바뀌는 방법입니다. 각 스키마 변경은 버전이 매겨진 스크립트입니다. 열을 추가하고, 값을 채우고(backfill), 제약 조건을 강화하는 작업을 순서대로, 모든 환경에서, 그것에 의존하는 코드처럼 리뷰를 거쳐 적용합니다. 가치의 대부분은 두 가지 규율에서 나옵니다. 이전 코드와 새 코드가 겹치는 기간에는 변경을 하위 호환으로 만들고(추가 → 마이그레이션 → 제거의 순서를 따르며, 제자리 이름 변경은 하지 않음), 스키마 버전을 저장소에 두어 코드와 구조가 함께 이동하게 하는 것입니다. 대시보드로 관리하는 플랫폼에서도 도구만 다를 뿐 같은 규율이 적용됩니다. 시각적으로 발전시키되 의도적으로 진행하고, 프로덕션에서는 클라이언트 주도의 스키마 변경을 비활성화합니다.

일반적인 사용 사례

• 새 백엔드 설계. 스키마는 데이터 모델링의 산출물입니다. 엔터티와 연결이 클래스, 열, 키가 됩니다.
• 무결성 강제. 음수가 아닌 합계, 고유한 이메일처럼 실행 가능한 규칙으로서의 제약 조건은 버그 리포트가 아니라 엔진이 잡아냅니다.
• 팀 간 계약. 스키마는 백엔드, 프론트엔드, 분석 사이의 공용 어휘이며, ER 다이어그램은 실제와 어긋날 수 없는 문서입니다.
• 성능의 기초 작업. 스키마의 아래층인 인덱스와 물리 레이아웃이 어떤 쿼리가 대규모에서도 빠르게 유지될지를 결정합니다.
• 보안 표면. 스키마 수준의 권한이 클래스별로 누가 무엇을 할 수 있는지 통제합니다. 구조와 접근 제어가 한곳에 있습니다.

스키마는 얼마나 엄격해야 할까? 결정 매트릭스

앱 백엔드를 위한 실용적인 기본값은 배우는 동안은 유연하게, 출시하면서 강화하는 것입니다. 개발 중에는 스키마를 추론하게 하고, 실제 사용자가 오는 날 스키마를 고정합니다(클라이언트의 스키마 변경 금지, add-field 비활성화).

한계와 트레이드오프

• 스키마는 가정을 고정합니다. 열 타입과 카디널리티에 관한 모든 결정은 오늘은 저렴하지만 내일은 마이그레이션이 됩니다. 한 단계 더 큰 규모를 위해 설계해야 합니다.
• 엄격함은 반복에 비용을 부과합니다. 모든 실험이 마이그레이션 통행료를 냅니다. 이는 결함이 아니라 보장의 대가입니다.
• 유연함은 읽는 쪽에 비용을 부과합니다. 읽기 시점 스키마는 검증을 모든 소비자에게 옮깁니다. 규율이 없으면 “유연함”은 “같은 레코드의 다섯 가지 모양”이 됩니다.
• 물리 계층은 문제가 생기기 전까지 보이지 않습니다. 인덱스와 레이아웃은 정확성을 바꾸지 않습니다. 쿼리가 성장을 견디는지만 바꿉니다.
• 네임스페이스 권한은 설계가 아닙니다. CREATE SCHEMA는 객체를 정리하고 접근을 통제하지만, 설계도를 좋게 만들어 주지는 않습니다.

Back4app에서의 스키마

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 여기서 스키마는 눈에 보이는 일급 화면입니다. 대시보드에서 클래스와 타입이 지정된 열을 정의하거나, 첫 저장으로 추론되게 할 수 있습니다. 위의 코드 탭은 실제로 타입이 지정된 열을 만들며, 모든 클래스에는 기본적으로 objectId, createdAt, updatedAt과 ACL이 추가됩니다. 스키마가 선언하는 모든 것은 자동 생성 API에 즉시 반영되고, 클래스 수준 권한으로 보호되며, 시각적 대시보드에서 둘러볼 수 있습니다. 설계도, 강제, 문서가 하나의 결과물로 합쳐집니다.