SQL Server 계정 관리 Login User Schema 생성 삭제 순서 정리

SQL Server에서 계정과 권한을 다룰 때 가장 먼저 이해해야 할 개념은 Login, User, Schema입니다. 이 세 가지는 비슷해 보이지만 역할이 서로 다르며, 서버 접속부터 데이터베이스 접근, 객체 관리까지 각 단계에서 다른 책임을 가집니다.

많은 분들이 “사용자를 삭제했는데 왜 테이블이 안 없어지지?” 혹은 “로그인을 만들었는데 왜 DB 접속이 안 되지?” 같은 문제를 겪는데, 대부분 이 구조를 정확히 구분하지 못해서 생깁니다.

 

SQL Server 보안은 단순한 계정 생성이 아니라, 어떤 주체가 서버에 들어올 수 있는지, 어떤 데이터베이스에 접근할 수 있는지, 그 안에서 어떤 객체를 사용할 수 있는지를 나눠서 관리하는 방식입니다. 이 구조를 이해하면 생성, 수정, 삭제뿐 아니라 권한 회수와 접근 차단도 훨씬 명확해집니다.

SQL Server 계정 관리 Login User Schema 생성 삭제 순서 정리

반응형

---

Login User Schema의 차이

SQL Server 보안에서 가장 중요한 것은 이 세 개념의 차이입니다.

Login

Login은 SQL Server 인스턴스 자체에 접속할 수 있는 권한입니다.
쉽게 말하면 건물의 출입증 같은 개념입니다. 서버에 들어올 자격이 있는지를 결정합니다.

User

User는 특정 데이터베이스 안에서의 실제 사용 주체입니다.
건물 안에 들어온 뒤 어떤 층을 쓸 수 있는지, 어떤 방에 들어갈 수 있는지를 정하는 것과 비슷합니다.

Schema

Schema는 데이터베이스 안에서 테이블, 뷰, 프로시저 같은 객체를 묶어두는 공간 이름입니다.
예를 들어 dbo.Users, sales.Orders처럼 객체 앞에 붙는 이름이 바로 schema입니다.

즉 흐름은 이렇게 이해하면 됩니다.

Login -> 서버 접속
User -> 데이터베이스 접근
Schema -> 객체 정리와 소유 구조

이 구조를 잘못 이해하면 계정 삭제 순서나 권한 부여 방식에서 자주 실수하게 됩니다.

---

구조를 잘못 이해하면 생기는 문제

실무에서 자주 발생하는 문제는 다음과 같습니다.

• Login은 삭제했는데 User가 남아 있는 경우.
• User는 삭제하려는데 schema 소유권 때문에 실패하는 경우.
• 테이블은 남겨야 하는데 schema를 먼저 지워서 작업이 꼬이는 경우.
• 권한을 직접 사용자에게만 줘서 관리가 어려워지는 경우.

특히 운영 환경에서는 계정을 바로 삭제하기보다, 먼저 접근을 막고 필요한 객체 소유권을 정리한 뒤 순차적으로 정리하는 것이 안전합니다.
이때 가장 중요한 원칙은 서버 레벨, 데이터베이스 레벨, 객체 레벨을 분리해서 생각하는 것입니다.

---

생성 순서

계정과 권한을 만들 때는 순서가 중요합니다. 보통 다음 순서로 진행하면 안정적입니다.

1. Login 생성
2. Database User 생성
3. Schema 생성 또는 소유권 지정
4. Role 또는 Permission 부여

이 순서를 지키면 뒤에서 막히는 일이 적습니다.
특히 User를 먼저 만들려고 하면 Login이 없어서 실패할 수 있고, schema 소유자를 잘못 지정하면 나중에 삭제할 때 문제가 생깁니다.

---

Login 생성 쿼리

SQL Server 인증 로그인 생성 예시는 아래와 같습니다.

USE [master]
GO
CREATE LOGIN [dev_user]
WITH PASSWORD = N'P@ssw0rd123!',
DEFAULT_DATABASE = [SampleDB],
CHECK_POLICY = ON,
CHECK_EXPIRATION = ON
GO

Windows 계정 기반 로그인은 이렇게 만듭니다.

USE [master]
GO
CREATE LOGIN [DOMAIN\dev_user]
FROM WINDOWS
WITH DEFAULT_DATABASE = [SampleDB]
GO

Login은 서버에 들어올 수 있는 자격이므로, 보안 측면에서는 강한 비밀번호 정책과 비밀번호 만료 정책을 함께 쓰는 것이 좋습니다.

---

User 생성 쿼리

Login을 만든 뒤에는 데이터베이스 안에 User를 만들어 연결해야 합니다.

USE [SampleDB]
GO
CREATE USER [dev_user]
FOR LOGIN [dev_user]
WITH DEFAULT_SCHEMA = [dbo]
GO

Windows 로그인도 같은 방식으로 연결할 수 있습니다.

USE [SampleDB]
GO
CREATE USER [DOMAIN\dev_user]
FOR LOGIN [DOMAIN\dev_user]
GO

User는 데이터베이스 단위이기 때문에, 같은 Login이라도 데이터베이스마다 User를 따로 만들어야 합니다.
이 점이 많은 분들이 가장 헷갈리는 부분입니다.

---

Schema 생성 쿼리

Schema는 객체를 담는 공간입니다. 보통 User와 연결해서 생성하거나, 특정 팀별로 나눠 관리합니다.

USE [SampleDB]
GO
CREATE SCHEMA [dev]
AUTHORIZATION [dev_user]
GO

schema를 따로 나누면 테이블 관리가 쉬워지고, 권한도 훨씬 깔끔하게 묶을 수 있습니다.
예를 들어 개발팀, 운영팀, 분석팀별로 schema를 나누면 객체 이름 충돌을 줄일 수 있습니다.

---

수정 쿼리

Login 수정

비밀번호를 바꾸려면 아래와 같이 작성합니다.

ALTER LOGIN [dev_user]
WITH PASSWORD = N'NewP@ssw0rd123!'
GO

로그인을 잠시 막고 싶다면 disable을 사용합니다.

ALTER LOGIN [dev_user] DISABLE
GO

다시 허용하려면 enable을 사용합니다.

ALTER LOGIN [dev_user] ENABLE
GO

User 수정

기본 schema를 바꾸고 싶다면 다음과 같이 합니다.

USE [SampleDB]
GO
ALTER USER [dev_user]
WITH DEFAULT_SCHEMA = [dev]
GO

Schema 수정

Schema 자체의 이름을 직접 바꾸는 방식은 제한적이므로, 보통 객체를 다른 schema로 이동시키거나 소유권을 바꾸는 방식으로 관리합니다.

ALTER AUTHORIZATION ON SCHEMA::[dev]
TO [dbo]
GO

이 명령은 schema의 소유자를 바꾸는 데 유용합니다.
삭제 전에 소유권을 정리할 때 매우 자주 사용됩니다.

---

삭제 쿼리

삭제는 생성보다 더 조심해야 합니다. 순서를 틀리면 에러가 나거나, 소유 객체가 남아서 삭제가 막힐 수 있습니다.

Login 삭제

Login을 지우면 서버 접속 자격이 없어집니다.

USE [master]
GO
DROP LOGIN [dev_user]
GO

User 삭제

User를 지우기 전에 해당 사용자가 schema를 소유하고 있지 않은지 확인해야 합니다.

USE [SampleDB]
GO
DROP USER [dev_user]
GO

Schema 삭제

Schema 안에 객체가 남아 있으면 삭제되지 않습니다.

USE [SampleDB]
GO
DROP SCHEMA [dev]
GO

schema를 지우기 전에 테이블과 뷰를 먼저 옮기거나 삭제해야 합니다.

---

삭제 순서

계정을 정리할 때는 보통 아래 순서가 가장 안전합니다.

1. Role에서 사용자 제거
2. Schema 소유권 변경
3. Schema 안의 객체 정리
4. Schema 삭제
5. User 삭제
6. Login 삭제

예시로 보면 더 이해가 쉽습니다.

USE [SampleDB]
GO
ALTER ROLE [db_datareader] DROP MEMBER [dev_user]
GO
ALTER ROLE [db_datawriter] DROP MEMBER [dev_user]
GO
ALTER AUTHORIZATION ON SCHEMA::[dev]
TO [dbo]
GO
DROP SCHEMA [dev]
GO
DROP USER [dev_user]
GO
USE [master]
GO
DROP LOGIN [dev_user]
GO

이 순서를 지키면 삭제 과정에서 막힐 가능성이 크게 줄어듭니다.

---

접근 차단 방법

계정을 완전히 지우지 않고 잠시 못 들어오게 하고 싶을 때도 있습니다. 운영에서는 이 방법이 더 안전한 경우가 많습니다.

Login 비활성화

가장 자주 쓰는 방법입니다.

ALTER LOGIN [dev_user] DISABLE
GO

이 방법은 계정을 보존하면서 접속만 막을 수 있어서, 나중에 다시 살리기 쉽습니다.

권한 회수

데이터베이스 내 권한을 제거하면 접근 범위를 줄일 수 있습니다.

USE [SampleDB]
GO
ALTER ROLE [db_datareader] DROP MEMBER [dev_user]
GO
ALTER ROLE [db_datawriter] DROP MEMBER [dev_user]
GO

User 삭제

DB 자체 접근을 제거하려면 User를 삭제합니다.

USE [SampleDB]
GO
DROP USER [dev_user]
GO

---

권한을 줄 때 자주 쓰는 방식

개별 권한을 하나씩 주는 것보다 role 기반으로 관리하는 방식이 훨씬 편합니다.
예를 들어 읽기 전용 사용자라면 db_datareader 역할만 주면 됩니다.

USE [SampleDB]
GO
ALTER ROLE [db_datareader] ADD MEMBER [dev_user]
GO

쓰기 권한이 필요하면 db_datawriter를 추가합니다.

USE [SampleDB]
GO
ALTER ROLE [db_datawriter] ADD MEMBER [dev_user]
GO

이 방식은 관리가 단순하고, 사용자 수가 많아져도 운영이 편합니다.

---

실무에서 추천하는 운영 방식

실무에서는 다음 원칙이 가장 좋습니다.

• Login은 서버 접속용으로만 사용합니다.
• User는 데이터베이스별로 분리합니다.
• Schema는 업무 단위나 팀 단위로 나눕니다.
• 권한은 직접 부여보다 Role 중심으로 관리합니다.
• 계정 차단은 삭제보다 disable을 먼저 고려합니다.
• 삭제할 때는 항상 소유권과 객체 존재 여부를 먼저 확인합니다.

특히 분석계나 운영계가 분리된 환경에서는 schema 설계를 잘해두면 나중에 권한 관리와 배포가 훨씬 쉬워집니다.

---

자주 헷갈리는 포인트

많이 혼동하는 부분만 다시 정리하면 다음과 같습니다.

• Login은 서버 접속 권한입니다.
• User는 데이터베이스 안의 사용자입니다.
• Schema는 객체를 담는 이름 공간입니다.
• Login이 있다고 해서 DB 접근이 자동으로 되지는 않습니다.
• User가 있다고 해서 테이블 권한이 자동으로 생기지는 않습니다.
• Schema를 지운다고 해서 안의 테이블이 자동으로 함께 지워지지 않을 수 있습니다.

이 차이만 정확히 알아도 SQL Server 보안 관리의 절반은 이해한 셈입니다.

---

SQL Server의 보안 관리는 결국 Login, User, Schema를 분리해서 이해하는 것에서 시작합니다.

Login은 서버 접속, User는 데이터베이스 접근, Schema는 객체 구조를 담당합니다. 이 흐름을 이해하면 생성과 삭제 순서도 자연스럽게 정리되고, 운영 중 계정 관리도 훨씬 안정적으로 할 수 있습니다.

 

블로그 글로 정리할 때는 이 세 개념의 차이를 먼저 설명하고, 그 다음 생성, 수정, 삭제, 차단 순서로 이어가면 독자가 이해하기 쉽습니다.

실무에서도 가장 중요한 것은 복잡한 권한을 외우는 것이 아니라, 어디에서 막히고 어디에서 열리는지 구조를 아는 것입니다.