MS SQL Server 로그인·User·스키마 매핑 정리 (Oracle과 비교)

1. 서론

최근 CI/CD 배포 관리 시스템 구축 프로젝트에서 TA 역할을 수행하며 일부 DBA 업무까지 맡게 되었고, 그 과정에서 MS SQL Server의 계정 관리 구조를 직접 다루게 됐다.

이전에 Oracle DB를 다뤄본 경험이 있었지만, 두 DBMS는 계정(User)·스키마(Schema)·권한 관리 개념이 크게 달라 초반에 상당한 혼란을 겪었다. 이 글에서는 Oracle에서 MS SQL Server로 넘어올 때 흔히 헷갈리는 계정·스키마·권한 구조의 차이를 정리하고, 직접 경험한 sysadmin 계정의 dbo 스키마 고정 문제와 구조적 해결 방법까지 함께 공유한다.

2. Oracle과 MS SQL Server의 계정·스키마 개념 차이

많은 Oracle 경험자가 SQL Server를 처음 접하면 가장 헷갈려하는 부분이 바로 로그인 계정과 스키마가 따로 논다는 점이다.

Oracle — User = Schema = Login

• 계정을 생성하면 자동으로 동일한 이름의 스키마가 생긴다.
• 즉 SCOTT 계정을 만들면 곧바로 SCOTT 스키마에서 작업한다.

CREATE USER SCOTT IDENTIFIED BY tiger;
-- 동시에 SCOTT 스키마 생성

MS SQL Server — Login → User → Schema (3단계)

• Login 계정 (서버 레벨) — SQL Server 인스턴스 접속용 계정. 서버 전체 관점의 인증 계정으로, ID/PW로 인스턴스에 로그인한다.
• User 계정 (DB 레벨) — 로그인 이후 특정 데이터베이스에 소속되는 사용자 계정. 하나의 Login은 각 데이터베이스 내의 User와 1:1로 매핑되어야 한다. 즉 동일한 Login이라도 DB마다 별도의 User를 가질 수 있다.
• Schema (객체 컨테이너) — 테이블·뷰·프로시저 등 DB 객체를 논리적으로 구분하는 컨테이너. User와는 별도의 개념이며, 각 User는 사용할 기본 스키마(Default Schema)를 지정할 수 있다. 처음 기본값은 dbo 스키마이며, 이를 실제 사용할 스키마로 바꿔줘야 한다.

-- 1) 서버 로그인 계정 생성
CREATE LOGIN SCOTT WITH PASSWORD = '***';

-- 2) Database 생성
CREATE DATABASE SCOTT_tiger;

-- 3) 스키마 생성
CREATE SCHEMA vdadmin AUTHORIZATION vdadmin_user;

-- 4) 특정 DB에 사용자 생성
--    MS SQL은 항상 특정 DB를 사용한다고 스위치(USE)해줘야 한다.
--    (Oracle은 schema와 계정이 1:1이라 그럴 필요가 없다)
USE SCOTT_tiger;
-- SSMS에서는 GO 명령어까지 적어준다 (DBeaver 기준 안 적어도 됨)
CREATE USER db_user FOR LOGIN SCOTT WITH DEFAULT_SCHEMA = SCOTT_tiger;
-- SCOTT_tiger DB 안에 db_user 계정을 로그인 계정 SCOTT과 매핑해 만들고,
-- 해당 db_user의 디폴트 스키마로 SCOTT_tiger를 지정한다.

정리하면, MS SQL Server는 3단계 구조(Login → User → Schema)다. 서버 레벨의 Login이 각 DB 내의 User와 매핑되고, 그 User가 DB 내 여러 Schema 중 하나를 기본 스키마로 지정해 사용한다. 반면 Oracle은 1단계 구조(User = Schema = Login)로, 로그인 계정이 곧 사용자이자 스키마로 작동하며 별도의 매핑 개념이 없다.

📘 참고 — MS SQL에서 Default Schema를 지정하더라도 다른 스키마의 객체를 못 쓰는 것은 아니다. schema.table 형식으로 명시하면 다른 스키마의 테이블에도 자유롭게 접근해 쿼리할 수 있다.

다만 외부 시스템 연동이나 애플리케이션 연결 계정을 구성할 때는 Default Schema를 명확히 지정해두는 것이 중요하다. 그렇지 않으면 연결 시 dbo 또는 지정되지 않은 기본 스키마로 자동 매핑되어 의도와 다른 객체를 참조하는 문제가 생길 수 있다. 따라서 Login → User → Default Schema 관계를 명확히 매핑하고, 스키마별로 전용 로그인 계정을 만들어 해당 스키마만 쓰도록 관리하는 것이 가장 안전하고 효율적이다. (결국 Oracle의 단일 구조가 훨씬 직관적이긴 하다.)

3. Default Schema의 차이

Oracle

• 계정으로 접속하면 해당 계정의 스키마가 자동으로 Default Schema가 된다.
• User = Schema 구조라 별도 설정이 필요 없다. SCOTT으로 로그인하면 자동으로 SCOTT 스키마에 연결된다.

SQL Server

• User 생성 시 DEFAULT_SCHEMA를 지정하지 않으면 기본값은 항상 dbo다.
• 원하는 스키마를 기본으로 쓰려면 명시적으로 지정해야 한다.

ALTER USER a_user WITH DEFAULT_SCHEMA = a_schema;

이렇게 설정하지 않으면 객체 생성 시 dbo.table_name 형태로 자동 생성되어, 의도와 다르게 dbo 스키마 아래에 객체가 쌓이는 문제가 발생할 수 있다.

4. 권한 관리 비교 (Oracle vs SQL Server)

두 DBMS 모두 접근·작업 제어를 위해 권한과 역할(Role)을 제공하지만, 구조와 적용 범위가 다르다.

Oracle — 권한이 크게 System 권한과 Object 권한으로 나뉜다.

• System 권한 — DB 전체에 영향을 미치는 권한 (예: CREATE SESSION, CREATE TABLE).
• Object 권한 — 특정 테이블·뷰 등 개별 객체에 대한 접근 권한 (SELECT, INSERT, UPDATE, DELETE).
• 여러 권한을 묶는 Role을 제공해 DBA, RESOURCE, CONNECT 같은 사전 정의 역할을 활용하거나 사용자 정의 역할을 만들 수 있다.

SQL Server — 권한 체계가 더 계층화되어 있다.

• 서버 레벨 권한 — sysadmin, serveradmin, securityadmin 등 서버 전체에 영향.
• DB 레벨 권한 — CONNECT, CONTROL, ALTER 등 데이터베이스 단위.
• 스키마/객체 레벨 권한 — 특정 스키마나 객체에 권한 부여.

GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::X TO user;

• SQL Server도 db_datareader, db_datawriter, db_ddladmin 등 기본 제공 Role로 권한을 묶어 관리할 수 있다.

정리하면, Oracle은 권한을 시스템 전체 vs 객체 단위로 구분하고 Role 중심으로 관리하는 반면, SQL Server는 서버 → DB → 스키마/객체 수준으로 계층화된 권한 체계를 가지며 역할도 이 계층과 결합되어 있다.

5. 실무에서 겪는 혼동 포인트

sysadmin 계정으로 MS SQL에 로그인했을 때, 아무리 Default Schema를 변경해도 항상 dbo 스키마로 들어가는 현상을 겪었다. 이유는 명확하다. MS SQL에서 sysadmin 계정은 항상 dbo 스키마에 매핑되도록 설계되어 있으며, 이는 보안·권한 관리 정책상 고정된 동작이다.

즉 DBA(sysadmin) 계정은 Default Schema를 자유롭게 바꿀 수 없고 항상 dbo에서 시작한다. 따라서 실무에서는 sysadmin과 별도로 각 스키마별 로그인 아이디를 만들어 매핑해 사용하는 것이 일반적이며, 이렇게 하면 Oracle처럼 계정별 스키마를 운영할 수 있다.

6. 해결 방법 — 업무용 계정과 스키마 분리

DBA 권한 계정은 운영·관리 전용으로 두고, 특정 스키마를 디폴트로 쓰려면 별도의 로그인 계정을 만들어야 한다.

• 서버 관리용 계정 — sysadmin (dbo 스키마 고정)
• 업무별 계정 — a_user → a_schema, b_user → b_schema를 기본 스키마로 사용

-- A 업무용 계정
CREATE LOGIN a_user WITH PASSWORD = '***';
USE mydb;
CREATE USER a_user FOR LOGIN a_user WITH DEFAULT_SCHEMA = a_schema;

-- B 업무용 계정
CREATE LOGIN b_user WITH PASSWORD = '***';
USE mydb;
CREATE USER b_user FOR LOGIN b_user WITH DEFAULT_SCHEMA = b_schema;

이렇게 하면 DBA 계정은 관리 전용으로 두고, 업무별 User 계정을 통해 각 스키마를 디폴트로 사용하게 설계할 수 있다. 전체 개략도는 다음과 같다.

[Server Level]
   ├── Logins
   │     ├── sysadmin
   │     ├── a_user
   │     ├── b_user
   │     ├── c_user
   │     └── d_user
   │
[Database Level]
   ├── Users
   │     ├── dbo              ← sysadmin 또는 db owner의 대표 User
   │     ├── a_user
   │     ├── b_user
   │     ├── c_user
   │     └── d_user
   │
   └── Schemas
         ├── dbo              ← 기본 스키마 (Default Schema)
         ├── a_user
         ├── b_user
         ├── c_user
         └── d_user

7. 정리 (Oracle 대비)

8. 결론

• Oracle은 계정 = 스키마 = 로그인.
• MS SQL Server는 Login·User·Schema가 각각 따로 존재하며 매핑이 필요하다.
• sysadmin(DBA) 계정은 항상 dbo 스키마로 매핑되어 Default Schema를 변경할 수 없다.
• 따라서 업무별 Default Schema를 쓰려면 별도의 Login–User 계정을 생성해야 한다.

---

📦 이 글은 제가 운영하던 티스토리 블로그에서 옮겨온(migration) 글입니다. 원문: taehyuklee.tistory.com/29