스키마 (Schema)

스키마(Schema)는 데이터가 어떤 필드와 값 형식으로 이루어져야 하는지 선언해, 실제 데이터가 그 구조에 맞는지 검사하는 기준으로 쓰는 명세입니다. JSON 데이터용으로는 JSON Schema가 있으며 type, properties, required 같은 키워드로 객체의 모양을 적습니다. PostgreSQL 같은 데이터베이스에서는 같은 낱말이 테이블과 함수 등을 묶는 이름 공간을 가리키므로 문맥으로 구분합니다.

JSON Schema로 적는 데이터 구조

JSON은 같은 개념을 여러 방식으로 표현할 수 있습니다. JSON Schema 공식 입문서의 개념 설명은 사람 정보를 name 한 필드에 담고 생일을 "February 22, 1732"로 쓴 레코드와, first_name·last_name으로 나누고 생일을 "1732-02-22"로 쓴 레코드를 함께 예로 듭니다. 둘 다 올바른 표현입니다. 다만 애플리케이션이 사람 레코드를 요구할 때는 어떤 필드가 오고 값이 어떻게 표현되는지 정확히 알아야 하며, 이 문서는 그때 JSON Schema가 쓰인다고 설명합니다.

JSON Schema 자체도 JSON으로 쓰는 데이터이며, 다른 데이터의 구조를 기술하는 선언형 형식입니다. 입문서는 type을 object로 두고 properties에 이름·생일·주소의 구조를 정의합니다. 생일을 어떤 문자열로 표현하고 주소를 어떻게 나눌지 선언하면 데이터를 보내는 쪽과 받는 쪽이 같은 형식을 따르는지 확인할 기준이 생깁니다.

JSON Schema의 object 참조 문서에 따르면 properties는 속성 이름마다 그 값을 검증할 하위 스키마를 짝지어 둡니다. 기본 설정에서는 정의한 속성을 빠뜨려도, 정의하지 않은 속성을 더해도 유효합니다. 필수 속성은 required 배열에 적고, additionalProperties를 false로 두면 정의하지 않은 속성이 들어간 객체를 거부합니다. 값이 null인 속성은 속성이 없는 것과 같지 않아서, 문자열로 정의한 필수 속성에 null을 넣으면 검증에 실패합니다.

구조 검증과 의미 검증의 범위

JSON Schema 공식 입문서의 개념 설명은 데이터의 겉 구조를 간결하게 기술하고 검증을 자동화하기 쉽다는 점을 JSON Schema의 강점으로 듭니다. 반대로 임의의 코드를 담을 수 없어서 데이터 요소 사이의 일부 관계는 표현하지 못합니다. 그래서 복잡한 데이터 형식의 검증 도구는 스키마 수준의 구조 검증과 범용 프로그래밍 언어로 구현하는 의미 수준 검증의 두 단계를 거칠 가능성이 높다고 같은 문서는 적었습니다.

스키마를 통과한 데이터는 구조 검증까지 끝난 상태입니다. 필드 이름, 자료형, 필수 여부, enum으로 정한 허용 값은 스키마로 확인하지만, 주문 항목 가격의 합이 합계 필드와 같은지처럼 여러 값 사이의 관계는 별도 코드로 검사합니다.

스키마를 합칠 때도 제약이 있습니다. object 참조 문서에 따르면 additionalProperties는 같은 하위 스키마에 선언된 속성만 알아봅니다. 그래서 기존 스키마에 additionalProperties: false가 있으면 allOf로 확장할 때 새로 더한 속성이 추가 속성으로 취급되어 검증에 실패합니다. draft 2019-09에 추가된 unevaluatedProperties는 하위 스키마에서 선언된 속성까지 인식해 속성을 다시 선언하지 않고도 이 문제를 피합니다.

PostgreSQL의 이름 공간 스키마

PostgreSQL 문서의 스키마 장에서 스키마는 데이터베이스 안에 이름을 붙여 만든 묶음이며, 테이블과 함께 데이터 타입, 함수, 연산자 같은 이름 붙은 객체를 담습니다. 한 스키마 안에서는 같은 종류의 객체가 같은 이름을 가질 수 없지만, schema1과 myschema가 각각 mytable이라는 테이블을 가질 수는 있습니다. 문서는 스키마를 운영체제의 디렉터리에 비유하면서 스키마끼리는 중첩할 수 없다고 덧붙입니다.

객체는 myschema.mytable처럼 스키마 이름과 테이블 이름을 점으로 이은 한정 이름으로 가리킵니다. 스키마를 지정하지 않은 새 테이블은 search_path에서 처음 존재하는 스키마에 만들어집니다. 기본 경로에서 사용자 이름과 같은 스키마가 없을 때는 public이 생성 위치가 됩니다. 테이블 이름만 쓰면 시스템은 search_path에 나열된 스키마를 차례로 찾아 처음 일치하는 테이블을 쓰고, 기본값은 "$user", public입니다.

같은 문서는 search_path에 스키마를 넣는 것이 그 스키마에 CREATE 권한을 가진 모든 사용자를 신뢰하는 일이라고 경고합니다. 경로에 든 스키마에 객체를 만들 수 있는 악의적 사용자는 일반 쿼리를 실행하는 다른 사용자의 권한으로 임의의 SQL 함수를 실행할 수 있습니다. PostgreSQL 15 이상의 기본 구성은 사용자별 전용 스키마 패턴을 지원하지만, 14 이하에서 업그레이드한 데이터베이스에는 모든 사용자의 public 스키마 CREATE 권한이 남을 수 있으므로 실제 권한을 확인해야 합니다.