MS SQL Server 로그인 계정, DB 사용자(User), 스키마 매핑 정리 (Oracle과 비교)

1. 서론 (Introduction)

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

저는 이전에 Oracle DB를 다뤄본 경험이 있었지만, 두 DBMS는 계정(User), 스키마(Schema), 권한 관리 개념이 크게 달라 초반에 상당한 혼란을 겪었습니다.

이번 글에서는 Oracle에서 MSSQL로 넘어올 때 흔히 헷갈리는 계정·스키마·권한 구조의 차이점을 정리하고, 제가 직접 경험한 sysadmin 계정의 dbo 스키마 고정 문제와 구조적 해결 방법까지 함께 공유하려 합니다.

2. Oracle과 MSSQL의 계정/스키마 개념 차이

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

Oracle

User = 스키마 = 로그인 계정

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

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

MS SQL Server

Login 계정 (서버 레벨 계정)

• SQL Server 인스턴스 접속용 계정입니다.
• 서버 전체 관점의 인증 계정으로, ID/PW를 통해 인스턴스에 로그인합니다.

User 계정 (로그인후, DB 레벨 계정)

• 로그인 이후, 특정 데이터베이스에 소속되는 사용자 계정입니다.
• 하나의 Login 계정은 각 데이터베이스 내의 User 계정과 1:1로 매핑되어야 합니다.
• 즉, 동일한 Login이라도 DB마다 별도의 User를 가질 수 있습니다.

Schema (객체 컨테이너)

• 테이블, 뷰, 프로시저 등 데이터베이스 객체를 논리적으로 구분하는 컨테이너입니다.
• 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를 사용한다고 스위치 해줘야 한다
--    Oracle은 shcema와 계정이 1:1매핑되어 있기때문에 그럴 필요가 없다)
USE SCOTT_tiger;
-- SSMS에서는 GO 명령어까지 적어준다 (DBeaver기준 안적어줘도 됨)
CREATE USER db_user FOR LOGIN SCOTT WITH DEFAULT_SCHEMA = SCOTT_tiger;
-- mydb 데이터베이스 안에 db_user 계정을 로그인 계정인 SCOTT과 매핑해서 만듭니다.
-- 그리고 해당 db_user계정의 디폴트 스키마로 SCOTT_tiger를 지정합니다.

즉, MSSQL은 3단계 구조(Login → User → Schema) 로 구성되어 있습니다. 서버 레벨의 Login 계정이 존재하고, 이 로그인은 각 데이터베이스 내의 User(사용자 계정) 와 매핑됩니다. 그 후, 해당 User는 DB 내 여러 Schema(객체 컨테이너) 중 하나를 기본 스키마(Default Schema) 로 지정하여 사용하게 됩니다.

반면, Oracle은 이와 달리 1단계 구조(User = Schema = Login) 로 되어 있습니다. 즉, Oracle에서는 로그인 계정이 곧 사용자이자 스키마로 작동하며, MSSQL처럼 별도의 매핑 개념이 없습니다.

따라서 Login → User → Default Schema 관계를 명확히 매핑하고, 각 스키마별로 전용 로그인 계정을 만들어 해당 스키마만 사용하도록 관리하는 것이 가장 안전하고 관리 효율적입니다. (결국… Oracle의 단일 구조가 훨씬 직관적이긴 합니다..)

3. Default Schema의 차이

앞서 언급했던 Default Schema에 대한 Oracle과 SQL Server의 차이점을 정리하면 다음과 같습니다.

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)

Oracle과 SQL Server 모두 데이터베이스 접근과 작업을 제어하기 위해 권한과 역할(Role)을 제공하지만, 구조와 적용 범위에서 차이가 있습니다.

Oracle에서는 권한이 크게 System 권한과 Object 권한으로 나뉩니다.

• System 권한은 데이터베이스 전체에 영향을 미치는 권한으로, 예를 들어 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 또한 Role을 제공하며, db_datareader, db_datawriter, db_ddladmin 등 기본 제공 역할을 통해 권한을 묶어 관리할 수 있습니다.

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

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

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

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

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에서는 계정 = 스키마 = 로그인
• MSSQL은 Login, User, Schema가 각각 따로 존재하며 매핑 필요
• sysadmin(DBA) 계정은 항상 dbo 스키마로 매핑 → Default Schema 변경 불가
• 따라서 업무별 Default Schema를 사용하려면 별도의 Login-User 계정을 생성해야 함

---

📦 블로그 이전 글입니다. 원본: taehyuklee.tistory.com/29