MSSQL 오류 15023 원인

mssql error 15023

오류 15023은 SQL Server에서 로그인/사용자/역할(Principal) 관련 작업(생성·매핑·권한·소유자 변경 등)을 수행할 때 이미 존재하는 Principal과의 충돌 또는 SID/매핑 불일치로 실패하는 상황에서 자주 등장한다.

개요

SQL Server의 보안 객체는 크게 서버 수준(Login)과 DB 수준(User)로 나뉘며, 이 둘은 내부적으로 SID를 통해 매핑된다. 백업/복원, 서버 이관, AlwaysOn/복제, 스크립트 배포 과정에서 “같은 이름이 이미 있는데 SID가 다르다”거나 “DB에는 사용자가 있는데 서버 로그인과 매핑이 끊어졌다(orphaned user)” 같은 상태가 생기면 Principal 관련 DDL이 15023으로 막히는 경우가 많다.

실무 기준으로 보면
15023은 단일 원인이라기보다 보안 객체의 정합성(SID/소유권/권한)이 깨졌다는 신호다.
“삭제 후 재생성”으로 끝내기보다, 어느 범위(서버/DB)에서 무엇이 중복 또는 불일치인지를 먼저 잡는 게 안전하다.

환경

• SQL Server: 온프레미스/클라우드/Managed Instance 등 전반에서 발생 가능
• 트리거 상황: 계정/권한 배포, DB 복원 후 계정 정리, 서버 이관, CI/CD에서 보안 스크립트 실행
• 관련 작업 예: CREATE LOGIN, CREATE USER, ALTER AUTHORIZATION, 역할/권한 부여, 소유자 변경

증상

에러 메시지는 작업 종류에 따라 다르지만, 공통적으로 “Principal이 이미 존재한다/충돌한다/연결할 수 없다”는 흐름으로 나타난다. 예를 들어 다음과 같은 작업 중 실패한다.

• 동일 이름 로그인/사용자 생성 시도
• 복원된 DB 사용자와 서버 로그인 매핑 시도
• DB 소유자/스키마 소유자 변경(Authorization) 시도
• 권한/역할 부여 스크립트 실행 중 일부 단계에서 중단

포인트는 “오류 번호”만 보지 말고, 어떤 T-SQL 문에서 터졌는지를 함께 보는 것이다. 같은 15023이라도 원인은 중복일 수도, SID 불일치일 수도, 소유권 문제일 수도 있다.

1차 점검

1) 서버(Login)과 DB(User) 존재 여부 확인

서버 로그인 존재 확인:

SELECT name, type_desc, is_disabled
FROM sys.server_principals
WHERE name = N'대상계정명';

DB 사용자 존재 확인(대상 DB에서 실행):

SELECT name, type_desc, authentication_type_desc, sid
FROM sys.database_principals
WHERE name = N'대상계정명';

2) SID 매핑 일치 여부 확인

서버 로그인 SID:

SELECT name, sid
FROM sys.server_principals
WHERE name = N'대상계정명';

DB 사용자 SID(대상 DB):

SELECT name, sid
FROM sys.database_principals
WHERE name = N'대상계정명';

해석
서버에 Login은 있는데 DB User의 SID가 다르거나(또는 User만 있고 Login이 없으면),
흔히 말하는 orphaned user 또는 이관/복원 후 SID 불일치 상태다.

3) 소유자(Owner) 충돌 여부(특히 DB Owner/Schema Owner)

DB 소유자 확인:

SELECT name AS database_name, SUSER_SNAME(owner_sid) AS owner
FROM sys.databases
WHERE name = DB_NAME();

스키마 소유자 확인(대상 DB):

SELECT s.name AS schema_name, dp.name AS owner
FROM sys.schemas s
JOIN sys.database_principals dp ON s.principal_id = dp.principal_id
ORDER BY s.name;

심화 분석

케이스 A) “이름이 이미 존재” 중복 충돌

배포 스크립트가 CREATE LOGIN 또는 CREATE USER를 매번 실행하면서, 이미 존재하는데도 예외 처리를 하지 않으면 15023 계열로 튕길 수 있다.

-- 존재 여부 가드(서버)
IF NOT EXISTS (SELECT 1 FROM sys.server_principals WHERE name = N'대상계정명')
BEGIN
  CREATE LOGIN [대상계정명] WITH PASSWORD = '...';
END;

-- 존재 여부 가드(DB)
IF NOT EXISTS (SELECT 1 FROM sys.database_principals WHERE name = N'대상계정명')
BEGIN
  CREATE USER [대상계정명] FOR LOGIN [대상계정명];
END;

케이스 B) 복원/이관 후 orphaned user(SID 불일치)

DB를 다른 서버로 복원하면, DB 내부 사용자는 기존 SID를 유지하지만 새 서버의 로그인 SID와 달라질 수 있다. 이 상태에서 매핑/권한 작업을 진행하면 실패가 이어진다.

최신 환경에서는 orphaned user 자동 진단/복구 패턴을 ALTER USER ... WITH LOGIN로 가져가는 것이 일반적이다.

케이스 C) 소유자/권한 구조 충돌

특정 스키마/객체의 소유자가 문제 계정으로 설정되어 있는데, 해당 계정을 삭제/재생성하거나 권한 구조를 바꾸는 과정에서 충돌이 발생할 수 있다. 특히 ALTER AUTHORIZATION 단계에서 15023이 뜨면 “소유권 정합성”을 먼저 의심한다.

케이스 D) Windows 그룹/도메인 계정, SID 재발급/변경

도메인 이관, AD 재구성 등으로 동일 표시명이라도 SID가 달라지는 케이스가 있다. 이 경우 “같은 이름인데 다른 실체”가 되어 충돌이 반복될 수 있다.

복구

1) 중복이면: 생성 스크립트에 가드 추가

CI/CD나 운영 배포에서 가장 많이 쓰는 방식이다. 동일 환경에 여러 번 실행해도 안전하게 넘어가도록 만든다.

-- 서버: 로그인
IF NOT EXISTS (SELECT 1 FROM sys.server_principals WHERE name = N'대상계정명')
  CREATE LOGIN [대상계정명] WITH PASSWORD = '...';

-- DB: 사용자
USE [대상DB];
IF NOT EXISTS (SELECT 1 FROM sys.database_principals WHERE name = N'대상계정명')
  CREATE USER [대상계정명] FOR LOGIN [대상계정명];

2) orphaned user면: 로그인 매핑 복구

DB 사용자와 서버 로그인을 다시 연결한다. 대상 DB에서 실행한다.

USE [대상DB];
ALTER USER [대상계정명] WITH LOGIN = [대상계정명];

만약 서버에 로그인 자체가 없다면, 먼저 로그인 생성(또는 도메인 계정/그룹 확인)이 선행되어야 한다.

3) 소유권 충돌이면: DB/스키마 소유자 정리

계정 정리 전에 소유자를 sa 같은 안정적인 Principal로 옮기면 충돌이 줄어든다.

-- DB Owner 변경(대상 DB가 아니라 master에서 실행해도 됨)
ALTER AUTHORIZATION ON DATABASE::[대상DB] TO [sa];

-- 특정 스키마 소유자 변경(대상 DB)
USE [대상DB];
ALTER AUTHORIZATION ON SCHEMA::[dbo] TO [dbo];

4) “삭제 후 재생성”이 필요한 경우의 순서

운영에서는 권한/소유권 의존성이 얽혀 있어 순서가 중요하다.

1. 대상 계정이 소유한 스키마/객체 소유권을 다른 Principal로 이전
2. DB 역할/권한 제거(필요 시)
3. DB USER 삭제
4. SERVER LOGIN 삭제
5. LOGIN 재생성(필요 시 SID 유지 옵션 검토)
6. USER 재생성 및 권한/역할 재부여

운영 팁
단순히 “DROP LOGIN”부터 치면, 소유권/권한 종속 때문에 더 큰 장애로 번질 수 있다.
먼저 누가 무엇을 소유/참조하는지를 점검한 뒤 순서를 잡는 게 안전하다.

재발 방지

1) 계정/권한 배포를 멱등성(idempotent) 있게

• IF NOT EXISTS 가드로 “이미 있으면 통과” 구조 만들기
• 역할/권한 부여도 중복 실행에 안전한 패턴으로 구성

2) 백업/복원·이관 표준 절차에 orphaned user 점검 포함

• 복원 후 바로 sys.database_principals / sys.server_principals SID 비교
• 필요 계정은 ALTER USER ... WITH LOGIN로 즉시 재매핑

3) DB/스키마 소유자는 특정 개인 계정 대신 안정적인 Principal로

개인 계정이 소유자가 되면 퇴사/권한 변경/도메인 이관 때 장애가 반복된다. 운영 환경에서는 DB Owner와 주요 스키마 Owner를 표준 Principal로 고정하는 것이 사고를 줄인다.

결론
15023은 “계정 만들기 실패”가 아니라 보안 객체(Principal) 정합성 문제로 보는 게 맞다.
중복/매핑(SID)/소유권을 분리해서 점검하면 대부분 빠르게 복구된다.

한 번에 정리

• 가장 흔한 원인: 같은 이름 Principal 중복 또는 복원/이관 후 SID 불일치(orphaned user)
• 즉시 점검: sys.server_principals, sys.database_principals에서 존재/SID 확인
• 대표 조치: 중복 가드(멱등 스크립트), ALTER USER ... WITH LOGIN, 소유권(ALTER AUTHORIZATION) 정리
• 재발 방지: 배포 스크립트 표준화 + 복원 절차에 SID 점검 포함 + 소유자 고정