데이터베이스와 스키마, 뭐가 다를까? — MySQL·Oracle·PostgreSQL별 차이와 DB 전환 시 주의점

데이터베이스를 처음 공부하면 데이터베이스와 스키마라는 말이 섞여 나와서 헷갈리기 쉽습니다. 어떤 글에서는 같은 것이라고 하고, 어떤 글에서는 전혀 다른 것이라고 하죠.

결론부터 말씀드리면, 둘 다 맞습니다. 사용하는 데이터베이스 제품(DBMS)에 따라 의미가 다르기 때문입니다. 이 글에서는 개념을 쉽게 정리하고, 실무에서 DB를 다른 제품으로 옮길 때 이 차이가 왜 중요한지도 함께 설명해 드릴게요.

먼저 비유로 이해하기

도서관을 떠올려 보세요.

• 데이터베이스 서버: 도서관 건물 전체
• 데이터베이스: 건물 안의 각 열람실
• 스키마: 열람실 안의 주제별 책장
• 테이블: 책장에 꽂힌 한 권 한 권의 책

데이터베이스는 데이터를 담는 큰 공간이고, 스키마는 그 안에서 테이블 같은 객체들을 논리적으로 묶어 정리하는 단위입니다. 또 다른 의미로, 스키마는 "테이블과 컬럼, 관계를 어떻게 구성할지 정한 설계도"를 가리키기도 합니다. "DB 스키마를 설계한다"고 할 때가 바로 이 뜻입니다.

제품마다 다른 '데이터베이스'와 '스키마'

DBMS	구조	한 줄 요약
MySQL / MariaDB	서버 → 데이터베이스(=스키마) → 테이블	데이터베이스와 스키마가 같은 말
Oracle	데이터베이스 → 스키마(=사용자) → 테이블	스키마는 사용자 계정과 짝을 이룸
PostgreSQL	클러스터 → 데이터베이스 → 스키마 → 테이블	데이터베이스 안에 여러 스키마
SQL Server	인스턴스 → 데이터베이스 → 스키마 → 테이블	기본 스키마는 dbo

MySQL: 데이터베이스 = 스키마

MySQL에서는 CREATE DATABASE shop;과 CREATE SCHEMA shop;이 완전히 같은 명령입니다. 그래서 MySQL만 써 본 분이라면 "둘은 같은 것"이라고 이해해도 실무에 지장이 없습니다.

또 MySQL은 같은 서버 안이라면 다른 데이터베이스의 테이블을 shop.orders처럼 이름 앞에 데이터베이스명을 붙여 바로 조회할 수 있습니다.

Oracle: 스키마 = 사용자의 공간

Oracle에서는 사용자 계정을 만들면 같은 이름의 스키마가 자동으로 생깁니다. HR 사용자가 만든 테이블은 HR 스키마에 속하고, 다른 사용자는 HR.EMPLOYEES처럼 스키마 이름을 붙여 접근합니다(권한이 있을 때).

하나의 Oracle 데이터베이스 안에 업무별, 애플리케이션별로 여러 스키마를 두고 운영하는 것이 일반적입니다.

PostgreSQL: 데이터베이스 안에 여러 스키마

PostgreSQL은 데이터베이스 안에 여러 스키마를 만들 수 있고, 따로 정하지 않으면 public 스키마를 씁니다.

중요한 차이가 하나 있습니다. 같은 데이터베이스 안의 다른 스키마는 sales.orders처럼 바로 조회할 수 있지만, 다른 데이터베이스의 테이블은 기본적으로 한 쿼리에서 함께 조회할 수 없습니다. 그래서 서로 자주 함께 조회하는 데이터는 같은 데이터베이스의 다른 스키마로 나누는 것이 일반적입니다.

스키마는 언제 나눠 쓰면 좋을까?

• 업무 영역 분리: 주문(sales), 회원(member), 정산(billing)처럼 영역별로 정리하면 테이블이 수백 개가 되어도 찾기 쉽습니다.
• 권한 관리: "정산 담당자는 billing 스키마만 볼 수 있다"처럼 스키마 단위로 권한을 주면 보안 관리가 단순해집니다.
• 여러 고객사 데이터 분리: 하나의 서비스에서 고객사마다 스키마를 따로 두는 방식도 있습니다.

실무 팁: DB를 다른 제품으로 옮길 때 꼭 확인하세요

비용 절감이나 클라우드 전환 때문에 Oracle에서 MySQL로 옮기는 프로젝트가 많습니다. 이때 스키마 개념의 차이가 생각보다 많은 작업을 만듭니다.

① Oracle의 스키마는 MySQL의 데이터베이스로 옮겨집니다 Oracle에서 HR, SALES 두 스키마를 쓰고 있었다면, MySQL에서는 보통 hr, sales 두 데이터베이스로 만듭니다. 다행히 MySQL도 sales.orders 형식의 조회를 지원해서 쿼리 구조는 크게 바뀌지 않는 경우가 많습니다.

② 대소문자 규칙이 달라집니다 Oracle은 따옴표 없이 쓴 이름을 대문자로 저장합니다. 반면 MySQL은 운영체제와 설정(lower_case_table_names)에 따라 테이블 이름의 대소문자를 구분하기도 합니다. 리눅스 서버에서 Orders와 orders를 다른 테이블로 인식해 "테이블이 없다"는 오류가 나는 경우가 흔합니다. 전환 전에 이름 규칙을 소문자로 통일해 두는 것을 권장합니다.

③ 권한 체계를 다시 설계해야 합니다 Oracle에서 "사용자 = 스키마"였던 구조가 MySQL에서는 "사용자"와 "데이터베이스"로 분리됩니다. 어떤 계정이 어떤 데이터베이스에 접근할지 권한을 새로 정리해야 합니다.

④ 쿼리 문법 차이도 함께 점검하세요 스키마뿐 아니라 날짜 함수(SYSDATE → NOW()), 문자열 연결(|| → CONCAT()), 페이징(ROWNUM → LIMIT) 등 자주 쓰는 문법도 다릅니다. 전환 대상 쿼리를 목록으로 만들어 하나씩 검증하는 것이 안전합니다.

정리

• 일반적으로 데이터베이스는 큰 공간, 스키마는 그 안의 정리 단위(또는 설계도) 입니다.
• MySQL에서는 둘이 같은 말, Oracle에서는 스키마 = 사용자, PostgreSQL·SQL Server에서는 데이터베이스 안에 여러 스키마가 있습니다.
• DB 제품을 바꿀 때는 스키마 구조, 대소문자 규칙, 권한, 쿼리 문법을 함께 점검해야 합니다.

용어 하나의 차이가 실제 프로젝트에서는 일정과 비용의 차이가 됩니다. 레거시 DB 전환이나 클라우드 이전을 고민 중이라면 Springuptech에 문의해 주세요. 실제 전환 프로젝트 경험을 바탕으로 함께 점검해 드리겠습니다.