이 글의 목적은 Windows 10과 Windows 11에서 자주 발생하는 DistributedCOM DCOM 10016 권한 오류의 의미를 정확히 이해하고, 로그만 조용히 숨기는 방법부터 고급 권한 수정까지 실무에서 바로 적용 가능한 해결 절차를 정리하는 것이다.
1. DCOM 10016 권한 오류가 의미하는 것
DCOM 10016 오류는 이벤트 뷰어 시스템 로그에서 다음과 유사한 메시지로 나타나는 경고 또는 오류이다.
원본: Microsoft-Windows-DistributedCOM 이벤트 ID: 10016 설명: 응용 프로그램별 권한 설정이 CLSID {…} 및 APPID {…} COM 서버 응용 프로그램에 대한 로컬 활성화 권한을 사용자 <계정>에게 부여하지 않았다. 이 보안 권한은 구성 요소 서비스 관리 도구를 사용하여 수정할 수 있다.이 메시지가 의미하는 핵심 포인트는 다음과 같다.
- CLSID는 특정 COM 서버 프로그램(예: RuntimeBroker, Immersive Shell 등)에 대한 고유 ID이다.
- APPID는 해당 COM 응용 프로그램에 대한 응용 프로그램 ID이다.
- SID와 사용자는 권한이 부족한 계정(LOCAL SERVICE, SYSTEM, 현재 로그인 사용자 등)을 의미한다.
- Local Activation 권한이 없어 DCOM이 첫 시도에서 실패했고, 이 상황을 이벤트 로그에 남긴 것이다.
1-1. DistributedCOM(DCOM) 동작 개요
DCOM은 Windows에서 프로세스 간·원격 컴퓨터 간에 COM 객체를 호출하기 위한 통신 계층이다. 프로그램이 DCOM 서버를 통해 기능을 요청할 때, 시스템은 보안 서브시스템을 통해 “해당 계정에 이 COM 서버를 로컬에서 시작·활성화할 권한이 있는지”를 검사한다.
권한이 부족한 계정으로 COM 서버를 호출하면 10016 이벤트가 기록된다. 이때 Windows는 다른 매개변수 조합으로 재시도하는 패턴을 사용하므로, 실제 기능은 정상 동작하면서 경고만 남는 경우가 많다 한다.
1-2. 왜 10016 이벤트가 자주 발생하는지
Microsoft는 여러 버전의 Windows에서 특정 CLSID·APPID 조합의 10016 이벤트가 “설계에 따른 동작이며 기능에 악영향을 주지 않는다”고 공식적으로 설명한다. 이러한 이벤트는 코드가 우선 낮은 권한으로 시도한 뒤 실패하면 더 넓은 권한으로 재시도하는 패턴 때문에 반복 기록되는 것이다.
따라서 모든 10016 이벤트를 무조건 “고쳐야 하는 오류”로 볼 수는 없으며, 상황에 따라 단순히 로그를 숨기는 것만으로 충분한 경우가 많다.
주의 : DCOM 10016 이벤트는 설계상 발생하는 경고인 경우가 많으며, 기능 장애가 없다면 권한을 억지로 수정하는 것보다 필터링으로 숨기는 편이 안전하다.
2. 수정이 필요한 경우와 그냥 둬도 되는 경우 구분
실무에서는 10016 이벤트가 생겼다는 이유만으로 즉시 레지스트리와 DCOM 권한을 수정하는 것은 바람직하지 않다. 다음 기준으로 우선 판단한다.
| 상황 유형 | 주요 증상 | 예시 | 권장 조치 |
|---|---|---|---|
| 단순 경고형 | 이벤트 뷰어에 경고만 누적되고 체감 성능·오류 없음 | 부팅 시마다 10016 경고가 1~2건 기록되지만 시스템은 정상 동작한다. | Microsoft가 “기능에 영향 없음, 무시해도 된다”고 안내한 CLSID·APPID 조합이면 이벤트 필터로 숨기고 시스템 설정은 건드리지 않는다. |
| 특정 앱 연계형 | 특정 프로그램 실행 시마다 10016 이벤트가 쌓이고 그 앱만 오류 발생 | 사내 서비스·서드파티 서버 프로그램 실행 시 10016 경고와 함께 해당 서비스 기능이 실패한다. | 해당 CLSID·APPID가 가리키는 COM 서버의 권한을 분석하고, 필요한 경우에 한해 권한을 최소 범위로 수정한다. |
| 시스템 불안정 의심형 | 잦은 멈춤·BSOD·강제 재부팅 등이 발생하며 직전에 10016 이벤트가 있다. | RuntimeBroker, Immersive Shell 관련 10016 직후 화면이 멈추거나 재부팅되는 현상이 반복된다. | 10016 이벤트 자체가 직접 원인은 아닐 수 있으나, 관련 프로세스와 드라이버, 시스템 파일 무결성까지 함께 점검한다. |
| 서버·업무 중요 시스템 | DCOM 기반 서비스가 실제로 시작에 실패하거나 클라이언트 요청을 처리하지 못한다. | 백업 서버, 업무용 웹 애플리케이션 서버에서 DistributedCOM 10016과 동시에 서비스 장애가 발생한다. | 벤더 문서와 Microsoft 공식 문서를 기반으로 DCOM 권한을 명시적으로 설계하고, 변경 이력을 관리한다. |
주의 : 단순 경고형 10016 이벤트를 “완전히 없애겠다”고 레지스트리를 무작정 수정하면, 오히려 시스템 앱이 시작되지 않거나 Windows 업데이트 이후 알 수 없는 오류가 발생할 수 있다.
3. 이벤트 뷰어에서 DCOM 10016 상세 정보 확인
3-1. 이벤트 뷰어 열기와 필터링
- Win + R을 눌러 실행 창을 연다.
eventvwr.msc를 입력하고 Enter 키를 눌러 이벤트 뷰어를 연다.- 좌측 트리에서 [Windows 로그] → [시스템]을 선택한다.
- 우측 [현재 로그 필터] 또는 [필터 현재 로그]를 클릭한다.
- [이벤트 ID]에
10016을 입력하고 확인을 눌러 DistributedCOM 10016 이벤트만 보이도록 한다.
이제 목록에서 10016 이벤트를 더블 클릭하면 일반 탭에 CLSID, APPID, 사용자, 프로세스 정보가 포함된 상세 메시지가 표시된다. 대표적인 예시는 다음과 같다.
… COM 서버 응용 프로그램 CLSID {D63B10C5-BB46-4990-A94F-E40B9D520160} 및 APPID {9CA88EE3-ACB7-47C8-AFC4-AB702511C276} … 사용자: NT AUTHORITY\LOCAL SERVICE …3-2. CLSID·APPID로 실제 COM 서버 식별
CLSID와 APPID는 레지스트리에서 COM 서버 이름과 실제 실행 파일(RuntimeBroker.exe 등)을 역추적하는 키이다. 실무에서는 다음 순서로 확인한다.
- Win + R →
regedit입력 → Enter로 레지스트리 편집기를 연다. - 상단 주소 표시줄에 다음과 같이 입력하고 CLSID 위치로 이동한다.
HKEY_CLASSES_ROOT\CLSID\{D63B10C5-BB46-4990-A94F-E40B9D520160} - 우측 창에서 AppID 값이 이벤트 뷰어에 찍힌 APPID와 일치하는지 확인한다.
- 좌측 CLSID 키 하위나 관련 키에서 RuntimeBroker와 같은 친숙한 이름을 확인할 수 있다. 이 CLSID는 RuntimeBroker.exe와 연결된 것으로 많이 보고된다.
- 마찬가지로 Immersive Shell, ShellExperienceHost 등 다른 CLSID도 레지스트리를 통해 어떤 시스템 구성 요소인지 확인할 수 있다.
자주 등장하는 CLSID·APPID 조합과 알려진 구성 요소 예시는 다음과 같다.
| CLSID | APPID | 관련 구성 요소(예) | Microsoft 설명 |
|---|---|---|---|
| {D63B10C5-…0160} | {9CA88EE3-…C276} | RuntimeBroker.exe | Windows 내부 설계상 발생하는 10016 이벤트로 기능에 영향이 없다고 안내한다. |
| {C2F03A33-…F239} | {316CDED5-…CC97} | Immersive Shell, 타일·시작 메뉴·UWP UI 관련 구성 요소 | 권한을 조정해도 다시 발생하는 사례가 많으며, 설계상 로그인 경우가 많다. |
| {6B3B8D23-…2C52} | {4839DDB7-…0D7D} | 일부 Windows 서비스 관련 COM 서버 | 마찬가지로 설계상 10016 이벤트로 문서화되어 있다. |
주의 : 위와 같이 문서화된 CLSID·APPID 조합이며 시스템이 정상 동작한다면, 권한을 수정하기보다는 “보이는 로그만 정리하는 방향”이 안전하다.
4. 권장 방식: 이벤트 뷰어에서 10016 로그 숨기기
Microsoft는 기능에 영향을 주지 않는 10016 이벤트에 대해 “무시하거나, 필요하다면 이벤트 뷰어에서만 숨기라”고 안내한다.
4-1. 간단 필터로 10016만 별도 보기
앞서 만든 필터를 그대로 사용해도 되지만, 10016 이벤트만 따로 모아 확인하고 나머지 작업 시에는 눈에 띄지 않도록 분리하는 방법도 있다.
- 이벤트 뷰어에서 [사용자 지정 보기] → [사용자 지정 보기 만들기]를 선택한다.
- 로그 선택에서 [시스템]만 체크한다.
- [이벤트 ID]에
10016을 입력한다. - 이름을 “DCOM 10016 로그” 등으로 지정하고 저장한다.
이제 시스템 로그를 볼 때는 기본 [시스템] 로그에서 작업하고, DCOM 관련 노이즈는 필요할 때만 사용자 지정 보기를 열어 확인할 수 있다.
4-2. XML 필터로 특정 CLSID·APPID 조합만 숨기기
문서에서 예시로 든 CLSID·APPID 조합 네 가지는 설계상 발생하는 이벤트이므로, 이 조합만 시스템 로그에서 숨기도록 XML 필터를 구성할 수 있다.
- [사용자 지정 보기 만들기] 창에서 상단 [XML] 탭을 선택한다.
- [수동 편집] 체크 후 기본 쿼리를 다음과 같이 응용한다(실제 환경에 맞게 CLSID·APPID를 조정한다).
<QueryList> <Query Id="0" Path="System"> <Select Path="System">*[System[(EventID=10016)]]</Select> <Suppress Path="System"> *[System[(EventID=10016)]] and *[EventData[ (Data[@Name='param4']='{D63B10C5-BB46-4990-A94F-E40B9D520160}' and Data[@Name='param5']='{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}') ]] </Suppress> </Query> </QueryList>위 예시는 RuntimeBroker 관련 CLSID·APPID에 대한 10016 이벤트만 숨기는 패턴이다. 실제로는 여러 조합을 or 조건으로 추가해 자신에게 불필요한 이벤트만 억제하면 된다.
주의 : XML 필터는 오타가 나면 로그가 전혀 표시되지 않을 수 있으므로, 먼저 테스트 환경이나 보조 PC에서 쿼리를 검증한 뒤 운영 PC에 적용하는 것이 안전하다.
5. 고급 해결: 실제 DCOM 권한 수정으로 10016 제거
특정 COM 서버가 실제로 시작에 실패하거나, 업무용 서버에서 10016과 동시에 서비스 장애가 발생한다면 해당 CLSID·APPID에 대한 DCOM 권한을 조정해야 할 수 있다. 이 작업은 잘못 수행 시 시스템 부팅 불가, Windows 앱 동작 불능 등 심각한 부작용을 초래할 수 있으므로, 반드시 백업·복원 지점을 만든 뒤 진행해야 한다.
주의 : 레지스트리와 DCOM 보안 설정 변경은 고급 작업이다. 서버·업무용 PC에서는 사전에 전체 이미지 백업 또는 시스템 상태 백업을 반드시 수행한다.
5-1. 사전 준비
- 관리자 권한이 있는 계정으로 로그인한다.
- 제어판 또는 설정 앱에서 복원 지점 만들기 기능으로 시스템 복원 지점을 하나 생성한다.
- 문제가 되는 10016 이벤트에서 CLSID, APPID, 사용자 계정을 정확히 기록한다.
5-2. 레지스트리에서 CLSID·APPID 키의 소유자·권한 변경
일반적으로 RuntimeBroker, Immersive Shell 관련 10016을 해결할 때는 CLSID 키와 APPID 키의 소유자를 TrustedInstaller에서 Administrators로 잠시 변경한 뒤, DCOM 설정에서 권한을 수정하는 절차를 거친다.
- Win + R →
regedit실행. - 다음 예시와 같이 CLSID 키로 이동한다.
HKEY_CLASSES_ROOT\CLSID\{C2F03A33-21F5-47FA-B4BB-156362A2F239} - 해당 키를 오른쪽 클릭 → [사용 권한] → [고급]을 연다.
- 상단 [소유자]를 Administrators로 변경하고, 하위 항목에도 적용하도록 체크한다.
- 다시 권한 창으로 돌아와 Administrators 그룹에 [모든 권한](Full Control)을 부여한다.
- 이제 다음 경로의 APPID 키에서도 동일하게 소유자와 권한을 조정한다.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{316CDED5-E4AE-4B15-9113-7055D84DCC97}
5-3. 구성 요소 서비스(DCOM 구성)에서 시작·활성화 권한 수정
레지스트리에서 소유자·권한을 조정했다면 이제 DCOM 구성에서 실제 보안 설정을 변경할 수 있다. RuntimeBroker, Immersive Shell 등에서 이 절차가 활용된다.
- Win + R →
dcomcnfg입력 → Enter. - [구성 요소 서비스] → [컴퓨터] → [내 컴퓨터] → [DCOM 구성]으로 이동한다.
- 우측 목록에서 문제 APPID에 해당하는 응용 프로그램을 찾는다.
- 이름이 GUID로 보이면 속성을 열어 [응용 프로그램 ID]가 이벤트의 APPID와 일치하는 항목을 찾는다.
- RuntimeBroker, Immersive Shell처럼 이름이 보이는 경우도 있다.
- 대상을 오른쪽 클릭 → [속성] → [보안] 탭으로 이동한다.
- [시작 및 활성화 권한]을 [사용자 지정]으로 선택하고, [편집] 버튼을 누른다.
- 이벤트 메시지에 표시된 계정(예:
LOCAL SERVICE,SYSTEM, 특정 도메인 계정 등)을 [추가]로 등록하고, 다음 권한을 부여한다.- [로컬 시작]: 허용
- [로컬 활성화]: 허용
- 확인 후 DCOM 구성 창을 닫고 시스템을 재부팅한다.
5-4. 레지스트리 소유자 복원
일부 가이드에서는 권한 수정이 끝난 뒤 CLSID·APPID 키의 소유자를 다시 NT SERVICE\TrustedInstaller로 돌려두도록 권장한다. 이는 향후 Windows 업데이트와 보안 모델을 최대한 기본 상태에 가깝게 유지하기 위함이다.
5-5. 적용 결과 확인
- 재부팅 후 이벤트 뷰어에서 10016 필터를 다시 적용한다.
- 같은 CLSID·APPID, 같은 사용자에 대해 더 이상 10016 이벤트가 발생하지 않는지 확인한다.
- 해당 COM 서버를 사용하는 프로그램·서비스를 여러 번 실행해 실제 기능이 정상 동작하는지 검증한다.
주의 : 권한을 넓게 주어 10016을 없애는 것은 단기적으로 로그를 깨끗하게 보이게 할 수 있으나, 보안 관점에서는 “원래 의도보다 높은 권한”을 허용하는 결과를 낳을 수 있다. 가능한 한 필요한 계정에만 최소 권한을 부여한다.
6. 10016 오류가 계속될 때 추가 점검 항목
6-1. Windows 업데이트 및 드라이버 최신화
- Windows 업데이트를 통해 누적 업데이트·.NET·기타 구성 요소가 최신 상태인지 확인한다.
- 그래픽·칩셋·스토리지 등 주요 드라이버도 제조사 최신 버전으로 맞추면, DCOM과 직접 관계가 없어 보이는 문제라도 간접적으로 해소되는 경우가 있다.
6-2. 시스템 파일 무결성 검사
시스템 파일 손상으로 인해 COM 구성 요소가 비정상 동작하는 경우, 10016을 포함한 다양한 이벤트가 함께 발생할 수 있다. 이때는 SFC와 DISM으로 기본 무결성을 먼저 복구하는 것이 좋다.
관리자 권한 명령 프롬프트 또는 PowerShell 실행 후: sfc /scannow DISM /Online /Cleanup-Image /RestoreHealth6-3. 보안 소프트웨어·튜닝 유틸리티 영향 점검
- 일부 보안 솔루션이나 튜닝 유틸리티는 서비스 계정 권한을 강제로 조정하거나, 기본 DCOM 정책을 변경하기도 한다.
- 10016이 특정 제품 설치 이후부터 발생했다면, 해당 제품의 보호 기능·하드닝 설정을 검토하거나 일시 제거 후 재현 여부를 확인한다.
6-4. 서버·업무 환경에서의 권장 절차
- 서버 환경에서는 이벤트 로그를 장기간 모니터링해 10016 이벤트와 실제 서비스 장애 사이의 상관관계를 먼저 분석한다.
- 벤더 기술 문서와 Microsoft 공식 지침을 함께 확인하고, 변경한 DCOM 권한·레지스트리 키를 문서로 남겨 재설치·마이그레이션 시 재현 가능하도록 관리한다.
7. 실무용 DCOM 10016 점검 체크리스트
마지막으로 실무에서 바로 활용할 수 있도록, DCOM 10016 이벤트가 발생했을 때의 기본 점검 순서를 체크리스트 형태로 정리한다.
| 순서 | 점검 항목 | 핵심 확인 내용 | 다음 단계 |
|---|---|---|---|
| 1 | 증상 분류 | 이벤트 외에 체감 장애(멈춤, 오류, 서비스 실패)가 있는지 여부를 확인한다. | 장애가 없다면 우선 “단순 경고형”으로 분류하고 필터링 위주로 접근한다. |
| 2 | CLSID·APPID 식별 | 이벤트 뷰어에서 10016 일반 탭을 확인해 CLSID·APPID·사용자 계정을 기록한다. | 문서화된 설계상 이벤트인지 여부를 확인한다. |
| 3 | 구성 요소 매핑 | 레지스트리에서 CLSID·APPID가 어떤 COM 서버(RuntimeBroker, Immersive Shell 등)인지 확인한다. | 시스템 기본 구성 요소라면 권한 수정 전에 필터링으로 충분한지 재검토한다. |
| 4 | 로그 필터링 적용 | 사용자 지정 보기 또는 XML 필터로 특정 CLSID·APPID 10016 이벤트를 숨긴다. | 장애가 없다면 이 단계에서 종료한다. |
| 5 | 권한 수정 결정 | 반복적인 서비스 실패·앱 오류와 직접 연관된 경우에만 권한 수정 필요성을 인정한다. | 복원 지점 생성, 레지스트리 소유자·권한 조정, DCOM 구성 보안 탭 수정 순으로 진행한다. |
| 6 | 사후 검증 | 수정 이후 이벤트 로그·서비스 동작을 일정 기간 모니터링한다. | 재발 시 변경 사항을 되돌리고, 상위 버전 Windows나 벤더 패치 적용도 검토한다. |
FAQ
Q1. DCOM 10016 권한 오류가 있으면 시스템이 반드시 불안정한가?
A1. 그렇지 않다. Microsoft는 특정 CLSID·APPID 조합에 대한 10016 이벤트가 설계상 발생하며 기능에 영향을 주지 않는다고 명시한다. 이러한 경우에는 로그 경고일 뿐이며, 실제 기능은 두 번째 시도에서 정상적으로 처리되므로 무시하거나 이벤트 뷰어에서만 숨겨도 된다.
Q2. RuntimeBroker 관련 10016(RuntimeBroker CLSID) 오류는 어떻게 처리해야 하나?
A2. RuntimeBroker.exe는 Windows 스토어 앱·UWP 앱의 권한을 중계하는 핵심 프로세스이다. 이와 관련된 CLSID·APPID 조합에서 10016이 발생하는 것은 잘 알려진 패턴이며, 대부분 설계상 경고로 간주된다. 단순 경고라면 필터링으로 충분하며, 서버나 특정 애플리케이션에서 RuntimeBroker 권한 부족으로 실제 기능이 실패하는 것이 확인된 경우에만 레지스트리와 DCOM 구성에서 해당 계정에 로컬 시작·로컬 활성화 권한을 최소 범위로 부여하는 것이 좋다.
Q3. Immersive Shell, ShellExperienceHost 관련 10016은 왜 권한을 수정해도 다시 생기는가?
A3. Immersive Shell 및 관련 UI 구성 요소는 Windows가 내부적으로 제어하는 시스템 앱이다. 일부 사용자는 CLSID·APPID 권한을 바꾸어 10016을 제거하려 했지만, 업데이트나 다른 내부 프로세스 때문에 다시 같은 이벤트가 발생하는 사례가 많다. 이들 구성 요소에 대해서는 Microsoft가 설계상 이벤트라고 안내하며, 실질적인 기능 장애가 없다면 권한을 유지한 채 이벤트만 필터링하는 것이 장기적으로 안정적이다.
Q4. 그룹 정책(gpedit.msc)으로 DCOM 10016을 해결하는 방법도 있나?
A4. 일부 Windows 버전에서는 “Distributed COM → Application Compatibility” 정책에서 로컬 활성화 보안 검사 예외를 허용하고, 문제 AppID를 예외 목록에 추가하는 방식으로 특정 10016 이벤트를 우회할 수 있다. 이 방법은 특히 도메인 환경·서버에서 사용되지만, 잘못 구성하면 과도한 예외가 적용되어 보안 모델이 약해질 수 있다. 따라서 서버 환경에서는 그룹 정책 변경 전·후 구성을 문서화하고, 관련 AppID의 의미와 영향을 충분히 검토한 뒤 적용하는 것이 바람직하다.
Q5. Windows를 재설치하면 10016 오류가 완전히 사라지는가?
A5. 재설치 직후에는 이벤트 로그가 깨끗해 보일 수 있지만, 기본 설계상 발생하는 10016 이벤트(예: RuntimeBroker, Immersive Shell 관련)는 일정 시간이 지나면 다시 기록되는 것이 일반적이다. 따라서 10016 자체를 “0건으로 만드는 것”을 목표로 하기보다는, 실제 기능 장애와 연관된 이벤트만 선별적으로 분석·조치하고, 나머지는 필터링으로 관리하는 운영 관점이 더 현실적이다.