Fuwari Banner
지니제스트Tech Archive
Windows9분 소요

Windows 서비스 시작 실패 1053 오류와 세션 0 격리 문제 해결

•
ggeniezst

Windows 서비스가 '오류 1053: 서비스가 시작 또는 제어 요청에 제때 응답하지 않았습니다' 메시지와 함께 시작되지 않는 문제를 심층 분석하고, 세션 0 격리 정책 및 서비스 아키텍처 관점에서 근본 원인을 파악하여 실무적인 해결책을 제시합니다.

Sponsored

프로덕션 환경에서 Windows 서버를 운영하다 보면, 특정 서비스가 시작되지 않고 "오류 1053: 서비스가 시작 또는 제어 요청에 제때 응답하지 않았습니다." 라는 메시지를 뱉어내며 시스템 관리자를 당황하게 하는 경우가 종종 있습니다. 이 오류는 겉으로 보기에는 단순히 서비스 타임아웃 문제처럼 보이지만, 실제로는 Windows 운영체제의 서비스 관리자(SCM, Service Control Manager)와 서비스 애플리케이션 간의 복잡한 상호작용, 그리고 세션 0 격리(Session 0 Isolation) 정책과 같은 Windows 내부 아키텍처와 밀접하게 연관되어 있습니다. 특히 UI 구성 요소나 사용자 상호작용이 필요한 레거시 애플리케이션을 서비스로 등록했을 때 이러한 문제가 빈번하게 발생합니다.

이 문제는 단순히 서비스 재시작이나 서버 리부팅으로 해결되지 않는 경우가 많으며, 근본적인 원인을 파악하고 OS 수준의 설정을 변경하거나 서비스 애플리케이션 자체의 로직을 수정해야 할 수도 있습니다. 이번 포스트에서는 Windows 서비스 시작 실패 오류 1053의 발생 원인을 심층적으로 분석하고, 특히 세션 0 격리 정책이 미치는 영향을 상세히 설명하며, 실무에서 적용할 수 있는 단계별 트러블슈팅 및 해결 방안을 제시합니다.

Windows 서비스 시작 실패 1053 오류의 본질과 재현 상황

오류 1053은 Windows 서비스가 시작 요청을 받은 후, 서비스 제어 관리자(SCM)가 설정된 시간(기본 30초) 내에 서비스 상태를 SERVICE_RUNNING으로 업데이트하지 못했을 때 발생합니다. 이 시간 동안 SCM은 서비스의 ServiceMain 함수가 성공적으로 실행되고 서비스가 초기화 단계를 완료할 것으로 기대합니다. 만약 이 시간 내에 서비스가 응답하지 않으면 SCM은 서비스를 강제로 종료하고 오류 1053을 기록합니다.

이 오류는 다양한 상황에서 재현될 수 있습니다. 예를 들어, 서비스가 시작될 때 다음과 같은 작업을 수행하는 경우 발생 가능성이 높습니다.

  • 긴 초기화 시간: 데이터베이스 연결, 대용량 파일 로드, 복잡한 네트워크 리소스 초기화 등 시간이 오래 걸리는 작업을 ServiceMain 함수 내에서 직접 수행할 때.
  • 교착 상태(Deadlock): 서비스 내부에서 스레드 간의 교착 상태가 발생하여 ServiceMain 함수가 응답하지 못할 때.
  • 세션 0 격리 문제: 서비스가 사용자 인터페이스(UI) 구성 요소, 그래픽 드라이버, 또는 사용자 세션에 종속적인 리소스에 접근하려고 시도할 때. Windows Vista 및 Server 2008부터 도입된 세션 0 격리 정책으로 인해 서비스는 더 이상 사용자 세션과 직접 상호작용할 수 없습니다.
  • 권한 부족: 서비스 계정이 필요한 리소스(파일, 레지스트리, 네트워크 경로 등)에 접근할 권한이 없을 때.
  • 종속성 문제: 서비스가 의존하는 다른 서비스나 드라이버가 시작되지 않았거나, 잘못 구성되어 있을 때.

이러한 상황들은 서비스가 정상적으로 시작 상태를 SCM에 알리지 못하게 만들고, 결국 오류 1053으로 이어집니다.

세션 0 격리(Session 0 Isolation)와 서비스 아키텍처 원인 규명

오류 1053의 가장 흔하고 이해하기 어려운 원인 중 하나는 바로 세션 0 격리입니다. Windows XP 및 Server 2003 이전 버전에서는 모든 서비스와 첫 번째 사용자 세션(콘솔 세션)이 '세션 0'이라는 동일한 세션에서 실행되었습니다. 이로 인해 서비스가 사용자 인터페이스와 직접 상호작용하거나, 사용자 세션의 리소스에 접근하는 것이 가능했습니다. 그러나 이는 보안 취약점(Shatter Attack)과 안정성 문제를 야기했습니다. 악의적인 프로그램이 서비스의 권한을 이용하여 사용자 세션에 접근하거나, 서비스가 사용자 세션의 오류로 인해 함께 충돌할 수 있었기 때문입니다.

Windows Vista 및 Server 2008부터 Microsoft는 세션 0 격리 정책을 도입했습니다. 이 정책에 따라 모든 서비스는 더 이상 사용자 세션과 분리된 '세션 0'에서 실행됩니다. 사용자 세션은 이제 '세션 1' 이상에서 시작됩니다. 이 격리 조치는 서비스의 보안과 안정성을 크게 향상시켰지만, 동시에 레거시 애플리케이션이나 UI 구성 요소를 포함하는 서비스들에게는 큰 변화를 가져왔습니다.

세션 0에서 실행되는 서비스는 더 이상 사용자 데스크톱과 상호작용할 수 없습니다. 즉, 서비스가 메시지 박스를 띄우거나, GUI 창을 생성하거나, 사용자 세션의 특정 드라이브나 프린터에 직접 접근하려고 시도하면 실패하게 됩니다. 이러한 시도는 서비스의 ServiceMain 함수 내에서 예외를 발생시키거나, 무한 대기 상태에 빠뜨려 SCM에 SERVICE_RUNNING 상태를 알리지 못하게 만듭니다. 결과적으로 SCM은 타임아웃으로 간주하고 오류 1053을 보고하게 되는 것입니다.

이 문제를 해결하려면 서비스가 세션 0 환경에 맞게 재설계되거나, UI 상호작용이 필요한 부분을 별도의 사용자 모드 애플리케이션으로 분리해야 합니다.

실무 검증 터미널 명령어 및 설정 파일

오류 1053 문제를 진단하고 해결하기 위해 몇 가지 유용한 터미널 명령어와 설정 방법을 알아봅니다.

1. 서비스 타임아웃 값 조정

서비스 초기화 시간이 길어서 발생하는 문제라면, SCM의 기본 타임아웃 값을 늘려볼 수 있습니다. 이는 근본적인 해결책은 아니지만, 임시방편으로 서비스가 시작될 충분한 시간을 벌어줄 수 있습니다.

POWERSHELL 
# 관리자 권한으로 PowerShell 실행
# HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control 레지스트리 경로에 ServicesPipeTimeout DWORD 값 생성 또는 수정
# 값 데이터는 밀리초 단위 (예: 60000ms = 60초)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control" -Name "ServicesPipeTimeout" -Value 60000 -Force

# 레지스트리 변경 후에는 시스템을 재부팅해야 적용됩니다.
# 재부팅 없이 적용하려면 서비스 제어 관리자(SCM)를 다시 시작해야 하지만, 이는 시스템 서비스에 영향을 줄 수 있으므로 재부팅이 권장됩니다.

2. 서비스 계정 및 권한 확인

서비스가 특정 리소스에 접근하지 못해 시작되지 않는 경우, 서비스 계정의 권한을 확인해야 합니다.

POWERSHELL 
# 특정 서비스의 현재 계정 정보 확인
# 'MyProblematicService'를 실제 서비스 이름으로 변경하세요.
Get-WmiObject win32_service | Where-Object {$_.Name -eq 'MyProblematicService'} | Select-Object Name, StartName, State

# 서비스 계정을 Local System 계정으로 변경 (일반적으로 가장 높은 권한을 가짐)
# 'MyProblematicService'를 실제 서비스 이름으로 변경하세요.
# Local System 계정은 대부분의 시스템 리소스에 접근할 수 있지만, 네트워크 리소스 접근 시 제약이 있을 수 있습니다.
sc.exe config "MyProblematicService" obj= "LocalSystem" password= ""

# 또는 특정 사용자 계정으로 변경 (도메인 사용자 등)
# 'MyProblematicService'를 실제 서비스 이름으로, 'Domain\User'와 'Password'를 실제 값으로 변경하세요.
sc.exe config "MyProblematicService" obj= "Domain\User" password= "Password"

3. 상호 작용하는 서비스(Interactive Service) 옵션 확인 (레거시 해결책)

세션 0 격리 이전의 레거시 서비스 중 일부는 "데스크톱과 상호 작용 허용(Allow service to interact with desktop)" 옵션이 활성화되어 있을 수 있습니다. 이 옵션은 세션 0 격리 이후에는 더 이상 정상적으로 작동하지 않지만, 서비스가 이 옵션에 의존하고 있다면 문제가 될 수 있습니다. 이 옵션은 보안상의 이유로 사용하지 않는 것이 강력히 권장됩니다.

POWERSHELL 
# 특정 서비스의 설정 정보 확인
# 'MyProblematicService'를 실제 서비스 이름으로 변경하세요.
Get-WmiObject win32_service | Where-Object {$_.Name -eq 'MyProblematicService'} | Select-Object Name, InteractWithDesktop

# 서비스의 'InteractWithDesktop' 속성을 변경하는 예시 (권장하지 않음)
# 이는 레거시 시스템에서만 고려될 수 있으며, 현대 Windows에서는 작동하지 않거나 보안 위험을 초래합니다.
# sc.exe config "MyProblematicService" type= interact

단계별 조치 방법 및 적용 후 검증

오류 1053 해결을 위한 단계별 조치 방법은 다음과 같습니다.

1. 이벤트 로그 분석

가장 먼저 서비스가 시작되지 않을 때 Windows 이벤트 로그(특히 시스템 및 애플리케이션 로그)를 확인해야 합니다. 오류 1053 외에 다른 오류나 경고 메시지가 있는지 확인하여 근본 원인을 파악합니다. 서비스 자체의 로그 파일도 확인하는 것이 중요합니다.

2. 서비스 타임아웃 값 증가 (임시 조치)

위에서 설명한 대로 ServicesPipeTimeout 레지스트리 값을 충분히 큰 값(예: 60초 또는 120초)으로 늘리고 시스템을 재부팅합니다. 서비스가 이전에 비해 긴 초기화 시간을 필요로 하는 경우, 이 조치만으로도 문제가 해결될 수 있습니다.

3. 서비스 계정 권한 검토

서비스가 실행되는 계정(Local System, Network Service, Local Service 또는 특정 사용자 계정)이 서비스가 필요로 하는 모든 리소스(파일 시스템 경로, 레지스트리 키, 네트워크 공유, 데이터베이스 등)에 대한 적절한 권한을 가지고 있는지 확인합니다. 가장 안전하고 권장되는 방법은 최소 권한 원칙에 따라 필요한 권한만 부여하는 것입니다.

4. 서비스 종속성 확인

서비스 관리자(services.msc)에서 해당 서비스의 속성을 열고 "종속성" 탭을 확인합니다. 서비스가 의존하는 다른 서비스가 정상적으로 시작되었는지, 또는 문제가 없는지 확인합니다.

5. 세션 0 격리 호환성 검토 및 수정

이것이 가장 중요하고 근본적인 해결책입니다.

  • UI/사용자 상호작용 제거: 서비스 코드에서 메시지 박스, GUI 창 생성, 사용자 세션 드라이브 접근 등 사용자 인터페이스와 관련된 모든 로직을 제거하거나, 별도의 사용자 모드 애플리케이션으로 분리합니다. 서비스는 백그라운드에서만 작동하도록 설계되어야 합니다.
  • 디버깅: 서비스가 시작될 때 어떤 부분에서 지연되거나 실패하는지 파악하기 위해 디버거를 연결하거나, 자세한 로그를 남기도록 서비스를 수정합니다. OutputDebugString 함수를 사용하여 디버그 출력을 남기고 DebugView와 같은 도구로 확인할 수 있습니다.
  • CreateProcessAsUser 사용: 만약 서비스가 사용자 세션에서 애플리케이션을 실행해야 한다면, CreateProcessAsUser 함수를 사용하여 특정 사용자 세션에서 프로세스를 시작하도록 구현해야 합니다. 이는 복잡하며, 사용자 세션의 토큰을 얻는 등 추가적인 보안 및 권한 관리가 필요합니다.

적용 후 검증 (Verification)

각 조치를 적용한 후에는 반드시 서비스를 다시 시작하여 문제가 해결되었는지 확인해야 합니다.

POWERSHELL 
# 서비스 중지
Stop-Service -Name "MyProblematicService" -Force

# 서비스 시작
Start-Service -Name "MyProblematicService"

# 서비스 상태 확인
Get-Service -Name "MyProblematicService" | Select-Object Name, Status

서비스 상태가 Running으로 표시되고, 이벤트 로그에 더 이상 1053 오류가 기록되지 않는다면 문제가 해결된 것입니다.

실무 엔지니어들이 자주 겪는 사이드 이펙트 방지 트러블슈팅 FAQ

Q. ServicesPipeTimeout 값을 너무 크게 설정하면 어떤 문제가 발생할 수 있나요?

ServicesPipeTimeout 값을 지나치게 크게 설정하면, 실제로 문제가 있는 서비스가 무한히 대기하여 시스템 리소스를 점유하거나, 시스템 종료 시 서비스 종료를 기다리는 시간이 길어져 전체 시스템 종료 시간이 지연될 수 있습니다. 이 값은 서비스의 실제 초기화 시간을 고려하여 합리적인 수준으로 설정해야 합니다. 예를 들어, 1분(60000ms) 또는 2분(120000ms) 정도가 일반적이며, 그 이상은 서비스 코드 자체의 최적화가 필요하다는 신호일 수 있습니다.

Q. 서비스 계정을 Local System으로 변경하는 것이 항상 좋은 해결책인가요?

Local System 계정은 로컬 컴퓨터에서 가장 높은 권한을 가지므로, 권한 부족으로 인한 많은 문제를 해결할 수 있습니다. 그러나 이는 보안상 위험할 수 있습니다. 서비스가 필요로 하는 최소한의 권한만 부여하는 **최소 권한의 원칙(Principle of Least Privilege)**을 따르는 것이 좋습니다. Local System 계정은 또한 네트워크 리소스에 접근할 때 컴퓨터 계정으로 인증되므로, 특정 네트워크 공유나 도메인 리소스에 접근할 때 문제가 발생할 수 있습니다. 이 경우 Network Service 계정이나 특정 도메인 사용자 계정을 사용하는 것을 고려해야 합니다.

Q. 서비스가 UI 상호작용 없이 백그라운드에서 실행되도록 수정했는데도 여전히 1053 오류가 발생합니다. 다른 원인이 있을까요?

세션 0 격리 문제를 해결했음에도 오류가 발생한다면, 다른 원인을 의심해봐야 합니다.

  1. 초기화 로직의 버그: 서비스의 ServiceMain 함수 내에서 예외가 발생하거나, 무한 루프에 빠지는 등 코드 자체에 버그가 있을 수 있습니다. 디버거를 연결하거나 상세한 로그를 추가하여 문제 지점을 찾아야 합니다.
  2. 외부 종속성 실패: 서비스가 의존하는 파일, 레지스트리 키, 네트워크 경로, 데이터베이스 연결 등이 사용할 수 없는 상태일 수 있습니다. 서비스 시작 시 이러한 외부 리소스에 대한 접근이 실패하면 서비스가 SERVICE_RUNNING 상태로 전환되지 못할 수 있습니다.
  3. 리소스 부족: 시스템 메모리 부족, 디스크 공간 부족, 포트 충돌 등 시스템 리소스가 부족하여 서비스가 정상적으로 시작되지 못할 수도 있습니다. 이벤트 로그를 통해 이러한 경고나 오류를 확인하세요.
CODE
Sponsored