처음 배우는 데이터베이스 19편 | 스키마와 인스턴스 - 미소의 그림같은 삶

처음 배우는 데이터베이스 · 19편

B. 데이터 모델과 관계형 구조

처음 배우는 데이터베이스 19편 | 스키마와 인스턴스

데이터베이스를 제대로 이해하려면 먼저 ‘구조’와 ‘현재 저장된 값’을 구분해야 합니다. 스키마와 인스턴스는 관계형 데이터베이스의 설계와 운영을 이어 주는 가장 기본적인 기준입니다.

핵심 정리

스키마는 데이터베이스의 구조와 규칙을 뜻하고, 인스턴스는 특정 시점에 실제로 저장되어 있는 데이터 상태를 뜻합니다. 학생 테이블의 속성 구성, 자료형, 기본키, 외래키 같은 내용은 스키마에 속하고, 실제 학생들의 학번·이름·학과 정보는 인스턴스에 속합니다.

데이터베이스에는 변하지 않는 구조와 계속 바뀌는 값이 함께 존재합니다

데이터베이스를 처음 배울 때 많은 학습자가 테이블을 보면 곧바로 행과 열, 저장된 회원 이름, 상품 가격, 주문 날짜 같은 값부터 떠올립니다. 화면에 보이는 내용이 곧 데이터베이스라고 느끼기 쉽기 때문입니다. 하지만 데이터베이스를 학문적으로 이해하려면 눈에 보이는 값보다 먼저 보아야 할 부분이 있습니다. 어떤 데이터를 어떤 이름의 표에 담을지, 각 열에는 어떤 의미와 자료형을 줄지, 어떤 열을 기본키로 삼을지, 다른 테이블과 어떤 관계를 맺게 할지에 관한 구조입니다. 이 구조가 정리되어 있어야 데이터가 의미 있게 저장되고, 여러 사용자가 같은 기준으로 데이터를 입력하고 조회할 수 있습니다.

스키마와 인스턴스는 이 차이를 설명하는 핵심 용어입니다. 스키마는 데이터베이스의 설계도에 가깝습니다. 학생 정보를 저장하는 테이블에 학번, 이름, 학과, 입학연도라는 속성이 있어야 한다는 약속, 학번은 중복되면 안 된다는 기준, 수강신청 테이블은 학생 테이블과 과목 테이블을 참조해야 한다는 구조가 모두 스키마에 속합니다. 반면 인스턴스는 어느 한 시점에 실제로 저장되어 있는 데이터의 상태를 가리킵니다. 오늘 오전 10시에 학생 테이블에 2,500명의 학생 정보가 들어 있었다면 그 시점의 학생 테이블 인스턴스가 존재하는 셈입니다. 오후에 신입생 30명이 추가되면 인스턴스는 바뀌지만, 테이블 구조가 그대로라면 스키마는 바뀌지 않습니다.

이 구분은 데이터베이스 설계, SQL 학습, 시스템 운영, 오류 분석에서 매우 중요합니다. 예를 들어 쇼핑몰에서 주문 내역 조회가 잘못되었을 때 문제가 ‘주문 테이블 구조가 부실한 것’인지, 아니면 ‘특정 주문 데이터가 잘못 입력된 것’인지 구별해야 합니다. 병원 예약 시스템에서 환자와 진료 예약 정보가 뒤섞여 관리된다면 스키마 차원의 재설계가 필요할 수 있습니다. 반대로 특정 환자의 예약 시간이 잘못 입력된 문제라면 인스턴스 차원의 수정으로 충분합니다. 스키마와 인스턴스를 구분할 수 있어야 데이터베이스를 보며 “무엇이 구조의 문제이고, 무엇이 값의 문제인가”를 판단할 수 있습니다.

1. 스키마란 무엇인가: 데이터베이스가 따라야 할 구조적 설계도

스키마는 데이터베이스의 전체 구조를 정의한 설계 정보입니다. 관계형 데이터베이스에서 스키마라고 할 때는 보통 테이블의 이름, 각 테이블이 갖는 속성, 속성의 자료형, 기본키와 외래키, 제약조건, 테이블 사이의 관계를 함께 떠올리면 이해하기 쉽습니다. 예를 들어 학사관리 시스템에서 학생 테이블은 학생의 기본 정보를 담고, 과목 테이블은 개설 과목 정보를 담으며, 수강 테이블은 어떤 학생이 어떤 과목을 신청했는지 나타냅니다. 이때 학생 테이블에 학번, 이름, 학과, 입학연도라는 속성을 둘 것인지, 학번을 기본키로 둘 것인지, 수강 테이블에서 학번이 학생 테이블을 참조하게 할 것인지가 스키마의 영역입니다.

스키마는 데이터베이스를 사용하는 사람과 시스템 사이의 약속입니다. 사용자는 데이터를 입력할 때 해당 테이블이 요구하는 속성 구조를 따라야 하고, DBMS는 그 구조와 제약조건에 맞지 않는 입력을 막아야 합니다. 예를 들어 주민등록번호를 관리하는 공공행정 시스템에서 주민등록번호 속성에 문자 수 제한과 고유성 제약이 없다면 같은 번호가 중복 입력되거나 형식이 다른 값이 섞일 수 있습니다. 데이터베이스가 안정적으로 운영되려면 “어떤 데이터가 어디에, 어떤 기준으로 들어가야 하는가”가 먼저 정해져야 합니다. 스키마는 바로 그 기준을 문서화하고 시스템 안에 반영한 구조입니다.

스키마를 설계한다는 말은 화면에 보이는 표를 만드는 일을 넘어 현실 세계의 업무 규칙을 데이터 구조로 번역하는 작업을 뜻합니다. 쇼핑몰의 현실 업무를 생각해 보겠습니다. 회원은 여러 번 주문할 수 있고, 하나의 주문에는 여러 상품이 포함될 수 있으며, 상품 가격은 할인 정책에 따라 시점별로 달라질 수 있습니다. 이 업무를 제대로 반영하려면 회원, 주문, 주문상세, 상품, 결제, 배송 같은 테이블을 나누고, 각 테이블의 관계를 정해야 합니다. 업무 규칙이 스키마에 잘 반영되면 데이터가 중복되거나 서로 맞지 않는 상황을 줄일 수 있습니다.

초보자가 자주 헷갈리는 지점은 스키마를 테이블 하나와 같다고 생각하는 부분입니다. 스키마는 테이블 하나의 구조를 가리킬 때도 있지만, 데이터베이스 전체 구조를 가리킬 때도 사용됩니다. 학생 테이블의 구조를 말할 때는 릴레이션 스키마라고 부를 수 있고, 학사관리 데이터베이스 전체의 테이블 구성과 관계를 말할 때는 데이터베이스 스키마라고 부를 수 있습니다. 작은 범위에서는 테이블 구조, 큰 범위에서는 시스템 전체 설계로 이해하면 좋습니다.

2. 인스턴스란 무엇인가: 어느 한 시점에 실제로 저장된 데이터 상태

인스턴스는 스키마라는 구조 안에 실제로 저장되어 있는 데이터의 현재 상태를 뜻합니다. 같은 학생 테이블 스키마를 사용하더라도 3월 개강 직후의 데이터와 9월 학기 중간의 데이터는 다를 수 있습니다. 신입생 정보가 추가되고, 휴학생 상태가 바뀌며, 전과나 복수전공 정보가 갱신되기 때문입니다. 데이터베이스는 시간이 지나면서 계속 변화합니다. 구조는 유지되지만 실제 값은 업무 활동에 따라 끊임없이 움직입니다.

인스턴스를 이해할 때 중요한 점은 “특정 시점”이라는 기준입니다. 데이터베이스는 정지된 문서가 아니라 사용자의 입력, 수정, 삭제, 조회가 계속 일어나는 운영 시스템입니다. 은행 거래 시스템을 예로 들면 오전 9시 10분의 계좌 잔액과 오전 9시 11분의 계좌 잔액은 다를 수 있습니다. 고객이 이체를 하거나 카드 대금이 빠져나가면 계좌 테이블에 저장된 값이 달라집니다. 그러나 계좌번호, 고객번호, 잔액, 개설일 같은 속성 구조가 그대로라면 스키마는 유지됩니다. 값의 변화가 곧 스키마 변화는 아닙니다.

병원 예약 시스템에서도 같은 원리를 확인할 수 있습니다. 환자 테이블, 의사 테이블, 진료예약 테이블의 구조는 병원 운영 규칙에 따라 미리 정해집니다. 오늘 오전에는 내과 예약이 120건, 오후에는 135건이 될 수 있고, 특정 환자가 예약을 취소하거나 진료 시간을 변경할 수 있습니다. 이런 변화는 인스턴스의 변화입니다. 다만 병원이 새로 “비대면 진료 여부”라는 항목을 예약 테이블에 추가해야 한다면 그때는 스키마 변경이 필요합니다.

실무에서 인스턴스의 변화는 로그, 백업, 감사 기록, 통계 산출과 밀접하게 맞닿아 있습니다. 공공행정 시스템에서 민원 접수 건수가 매일 쌓이면 민원 테이블의 인스턴스는 계속 커집니다. 특정 날짜의 접수 현황을 보고하려면 그 시점의 인스턴스가 필요하고, 잘못 입력된 민원 내용을 바로잡으려면 해당 행의 값을 수정해야 합니다. 데이터 품질 관리는 스키마를 제대로 설계하는 일과 함께, 인스턴스가 그 구조에 맞게 유지되는지 점검하는 일까지 포함합니다.

3. 스키마와 인스턴스의 차이: 설계의 문제와 값의 문제를 나누어 보기

스키마와 인스턴스를 구분하는 가장 쉬운 방법은 건축 설계도와 실제 건물 사용 상태를 떠올리는 것입니다. 설계도에는 방의 위치, 출입문, 창문, 전기 배선, 배관 구조가 표시됩니다. 실제 건물 안에는 책상, 의자, 사람, 물건이 들어오고 나갑니다. 가구 배치가 바뀌어도 설계도 자체가 바뀐 것은 아닙니다. 반대로 벽을 허물고 방 구조를 바꾸거나 배관 위치를 수정한다면 설계도 수준의 변경이 필요합니다. 데이터베이스에서도 같은 구분이 적용됩니다.

학사관리 시스템을 다시 보겠습니다. 학생 테이블의 스키마가 학생(학번, 이름, 학과, 입학연도)라고 정해져 있다면, 그 안에 “20260001, 김민준, 행정학과, 2026” 같은 행이 저장될 수 있습니다. 학생이 새로 입학하면 행이 추가되고, 학과를 변경하면 특정 값이 수정됩니다. 이 변화는 인스턴스 변화입니다. 반면 학교가 학생의 외국어 인증 점수를 별도로 관리하기로 하여 학생 테이블에 외국어인증점수 속성을 추가한다면 스키마가 바뀝니다.

쇼핑몰에서도 같은 구분은 매우 중요합니다. 상품 테이블에 상품번호, 상품명, 판매가, 재고수량이라는 속성이 있을 때 상품 가격이 29,000원에서 25,000원으로 바뀌는 일은 인스턴스 변화입니다. 그러나 쇼핑몰이 정기구독 상품을 새로 도입하면서 상품마다 구독주기, 자동갱신여부, 해지조건을 관리해야 한다면 기존 스키마가 업무 변화를 충분히 담지 못할 수 있습니다. 이 경우 테이블을 확장하거나 별도의 구독상품 테이블을 설계해야 합니다.

구분	스키마	인스턴스
의미	데이터베이스의 구조와 규칙	특정 시점에 저장된 실제 데이터 값
변화 빈도	업무 구조가 바뀔 때 변경	입력, 수정, 삭제가 일어날 때마다 변화
예시	학생(학번, 이름, 학과, 입학연도)	20260001, 김민준, 행정학과, 2026
관리 관점	설계, 제약조건, 구조 검토	데이터 입력 품질, 갱신, 백업, 조회

위 표에서 볼 수 있듯 스키마는 데이터베이스의 뼈대에 해당하고, 인스턴스는 그 뼈대 안에서 실제로 움직이는 값에 해당합니다. 스키마가 부실하면 데이터가 아무리 많이 쌓여도 체계적으로 활용하기 어렵습니다. 반대로 스키마가 잘 설계되어 있어도 인스턴스가 잘못 관리되면 조회, 통계, 의사결정에서 오류가 생깁니다. 데이터베이스는 구조와 값이 함께 유지될 때 신뢰할 수 있는 정보 시스템이 됩니다.

4. 스키마는 왜 자주 바꾸면 안 되는가: 안정성과 확장성의 균형

인스턴스는 업무가 진행될 때마다 바뀌는 것이 자연스럽지만, 스키마는 자주 바뀌면 시스템 전체에 부담을 줍니다. 테이블 구조가 변경되면 기존 SQL, 화면, 보고서, 통계 프로그램, 외부 연동 시스템까지 함께 영향을 받을 수 있습니다. 예를 들어 주문 테이블에서 주문번호 속성 이름을 변경하면, 해당 속성을 기준으로 작성된 조회문과 정산 프로그램이 작동하지 않을 수 있습니다. 그래서 스키마 변경은 데이터베이스 운영에서 매우 신중하게 다루어야 합니다.

그렇다고 스키마를 한 번 정하면 영원히 바꿀 수 없다는 뜻은 아닙니다. 업무 환경이 달라지면 스키마도 그 변화를 받아들여야 합니다. 대학이 온라인 강의 이수 정보를 별도로 관리해야 하거나, 병원이 모바일 예약과 비대면 진료를 함께 운영해야 하거나, 행정기관이 민원 처리 과정에서 전자서명 정보를 추가로 저장해야 할 때 기존 구조만으로는 부족할 수 있습니다. 좋은 스키마는 현재 업무를 정확히 반영하면서도 앞으로의 변화에 지나치게 취약하지 않도록 설계되어야 합니다.

데이터베이스 설계자가 중요한 이유도 여기에 있습니다. 설계자는 현재 보이는 데이터만 보고 테이블을 만드는 사람이 아니라, 업무의 흐름과 변화 가능성을 함께 읽어야 합니다. 회원, 주문, 상품, 배송을 한 테이블에 모두 넣으면 처음에는 편해 보일 수 있지만, 주문이 늘어나고 배송 상태가 다양해지면 중복과 관리 부담이 커집니다. 그래서 스키마 설계 단계에서는 데이터의 의미, 반복 가능성, 관계, 변경 가능성을 충분히 따져 보아야 합니다.

실무 체크포인트
새 항목을 추가해야 할 때 기존 테이블에 속성을 더할 문제인지, 별도 테이블을 만들 문제인지 먼저 검토해야 합니다. 데이터 오류가 발생했을 때도 구조 오류인지 값 오류인지 나누어 보아야 합니다. 스키마 변경 전에는 기존 SQL, 화면, 보고서, 외부 연동 시스템에 미치는 영향을 함께 확인하는 과정이 필요합니다.

5. 함께 알아 두면 좋은 표현: 릴레이션 스키마와 데이터베이스 상태

스키마와 인스턴스를 배울 때 함께 나오는 표현이 릴레이션 스키마입니다. 관계형 데이터베이스에서 릴레이션은 보통 테이블에 대응하여 이해할 수 있고, 릴레이션 스키마는 한 릴레이션의 구조를 나타냅니다. 예를 들어 학생(학번, 이름, 학과, 입학연도)라고 표현하면 학생이라는 릴레이션의 속성 구성이 드러납니다. 여기에 학번이 기본키라는 조건이 붙으면 학생 릴레이션 스키마의 의미가 더 명확해집니다.

데이터베이스 스키마는 릴레이션 스키마보다 더 넓은 범위입니다. 학사관리 데이터베이스에는 학생, 과목, 교수, 수강, 성적 같은 여러 릴레이션이 존재할 수 있습니다. 각 릴레이션의 구조와 릴레이션 사이의 관계를 모두 포함하면 데이터베이스 스키마가 됩니다. 그래서 “학생 테이블의 스키마”라고 말할 때와 “학사관리 시스템의 스키마”라고 말할 때는 범위가 다릅니다. 전자는 하나의 테이블 구조를 보는 것이고, 후자는 여러 테이블과 관계 전체를 보는 것입니다.

데이터베이스 상태라는 표현도 인스턴스와 매우 가깝습니다. 어느 시점에 데이터베이스 전체에 저장된 실제 값들의 집합을 데이터베이스 상태라고 부를 수 있습니다. 학생 테이블의 현재 행들, 과목 테이블의 현재 행들, 수강 테이블의 현재 행들이 모두 모여 특정 시점의 데이터베이스 상태를 이룹니다. 시간이 흐르며 새로운 수강신청이 들어오거나 성적이 입력되면 데이터베이스 상태가 바뀝니다. 이때 스키마가 그대로 유지될 수도 있고, 업무 변화에 따라 나중에 스키마까지 바뀔 수도 있습니다.

자주 묻는 질문

Q1. 스키마는 테이블과 같은 뜻인가요?

완전히 같은 뜻은 아닙니다. 테이블은 데이터를 담는 구조적 단위이고, 스키마는 그 테이블이 어떤 속성과 제약조건을 갖는지 설명하는 설계 정보입니다. 문맥에 따라 데이터베이스 전체 구조를 가리킬 때도 있습니다.

Q2. 행 하나도 인스턴스라고 부를 수 있나요?

엄밀하게는 어느 시점의 전체 데이터 상태를 인스턴스라고 보는 편이 적절합니다. 다만 설명 과정에서 특정 테이블 안의 실제 행들을 인스턴스의 일부로 이해할 수 있습니다.

Q3. SQL을 배울 때 왜 스키마와 인스턴스를 알아야 하나요?

SELECT문으로 조회하는 대상은 실제 저장된 인스턴스이지만, 어떤 열을 조회할 수 있는지와 어떤 테이블을 조인할 수 있는지는 스키마가 정합니다. SQL은 구조와 값을 함께 이해할 때 훨씬 선명해집니다.

스키마와 인스턴스를 구분하면 데이터베이스가 훨씬 선명하게 보입니다

이번 글에서 살펴본 스키마와 인스턴스는 관계형 데이터베이스를 이해하는 데 필요한 가장 중요한 관점 중 하나입니다. 스키마는 데이터가 들어갈 자리를 정하는 구조이며, 인스턴스는 그 구조 안에 특정 시점에 저장된 실제 값입니다. 학생 테이블의 속성 구성, 기본키, 외래키, 자료형, 제약조건은 스키마에 속하고, 실제 학생들의 학번과 이름, 학과 정보는 인스턴스에 속합니다. 구조와 값을 분리해 생각하면 데이터베이스의 작동 방식이 한층 분명해집니다.

이 구분은 학습용 개념에 머물지 않습니다. 실무에서 데이터 오류를 찾거나 시스템을 개편하거나 보고서를 작성할 때도 스키마와 인스턴스의 구분은 계속 등장합니다. 잘못된 값 하나를 고치는 문제인지, 테이블 구조 자체를 바꾸어야 하는 문제인지 판단하지 못하면 작은 오류가 큰 시스템 수정으로 번지거나, 반대로 구조적 문제를 임시 데이터 수정으로 덮어 버릴 위험이 있습니다. 데이터베이스를 신뢰할 수 있는 정보 기반으로 만들기 위해서는 설계와 운영을 함께 보아야 합니다.

다음 단계에서는 차수와 카디널리티를 살펴보게 됩니다. 차수는 릴레이션이 갖는 속성의 수와 관련되고, 카디널리티는 릴레이션 안에 들어 있는 튜플의 수와 관련됩니다. 스키마와 인스턴스를 배운 뒤 차수와 카디널리티를 공부하면, 테이블의 구조적 크기와 실제 데이터 규모를 더 정확히 구분할 수 있습니다. 데이터베이스 학습은 용어를 외우는 과정이 아니라, 현실 세계의 정보를 어떤 구조로 정리하고 어떤 기준으로 관리할지 익혀 가는 과정입니다.

마지막 한 문장 정리: 스키마는 데이터베이스의 설계된 틀이고, 인스턴스는 그 틀 안에 현재 담겨 있는 실제 데이터입니다.