알짜게시판

반복 실행 프로그램을 서비스로 전환한 배경

운영 환경에서 특정 exe를 주기적으로 실행해야 하는 경우가 있었다. 로그 수집이나 데이터 정리 작업처럼 사람이 직접 실행하지 않아도 되는 작업이었는데, 매번 수동으로 실행하거나 작업 스케줄러에 의존하는 방식은 관리 비용이 계속 쌓였다. 특히 재부팅 이후 자동으로 실행되지 않거나, 프로세스가 중간에 종료되면 다시 시작되지 않는 문제가 반복적으로 발생했다. 이 문제는 하루 기준 약 20~30회 정도 수동 개입을 유도했고, 서버 환경에서는 더 큰 부담으로 이어졌다.

이 상황에서 서비스 형태로 등록하는 방식을 검토했다. 윈도우 서비스는 시스템 부팅 시 자동으로 실행되고, 별도의 사용자 로그인 없이도 동작한다는 점에서 요구사항에 맞았다. 다만 일반 exe는 서비스 인터페이스를 따르지 않기 때문에 그대로 등록하는 방식은 바로 적용할 수 없었다. 이 지점에서 NSSM을 선택하게 된다.

sc create 방식의 한계와 NSSM 선택 이유

처음에는 Windows 기본 명령인 sc create를 사용해 exe를 서비스로 등록하려고 했다. 명령 자체는 단순하다. binPath에 실행 파일 경로를 넣으면 서비스가 생성된다. 하지만 이 방식은 서비스 형태로 설계된 프로그램에서만 정상 동작한다. 일반 exe를 넣으면 시작 직후 종료되거나, 상태가 stopped로 유지되는 경우가 대부분이었다.

이 문제의 원인은 서비스 실행 구조에 있다. Windows 서비스는 Service Control Manager(SCM)와 통신하며 상태를 보고해야 하는데, 일반 exe는 이러한 인터페이스를 구현하지 않는다. 입력은 단순 실행 경로지만, 출력으로 요구되는 상태 보고가 없기 때문에 서비스로 인정되지 않는 구조다. 이 구조적 차이를 해결하기 위해 NSSM을 사용한다.

NSSM은 일반 프로세스를 감싸는 래퍼 역할을 한다. 입력으로 exe 경로와 인자를 전달받고, 내부적으로 서비스 인터페이스를 대신 처리한다. 실행 결과는 서비스 상태로 변환되어 SCM에 전달된다. 이 방식으로 기존 exe를 수정하지 않고도 서비스 형태로 실행할 수 있다.

Windows exe 서비스 등록을 한 번에 구성하는 방법

서비스 등록 과정은 실제로 세 단계로 나뉘지만, 반복적으로 작업하다 보니 하나의 흐름으로 묶는 것이 관리에 유리했다. 입력은 서비스 이름, 실행 파일 경로, 작업 디렉터리, 로그 경로 정도이며, 출력은 서비스 등록과 동시에 실행 가능한 상태다. 아래 명령 세트를 한 번에 적용하면 대부분의 설정이 완료된다.

nssm install MyService "C:\app\myapp.exe"
nssm set MyService AppDirectory "C:\app"
nssm set MyService Start SERVICE_AUTO_START
nssm set MyService AppStdout "C:\logs\out.log"
nssm set MyService AppStderr "C:\logs\err.log"
nssm set MyService AppRestartDelay 5000
nssm start MyService

입력 단계에서는 실행 파일 경로와 디렉터리를 지정한다. 이 값이 정확하지 않으면 실행 자체가 실패한다. 이후 설정 단계에서는 서비스 시작 유형과 로그 위치, 재시작 조건을 지정한다. 실행 단계에서는 서비스가 즉시 시작되며, 결과적으로 부팅 시 자동 실행 + 장애 시 재시작 + 로그 기록까지 동시에 적용된다.

이 과정을 분리하지 않고 한 번에 구성하면 작업 단계가 기존 6~7단계에서 2~3단계 수준으로 줄어든다. 실제로 여러 서버에 동일한 설정을 적용할 때 스크립트 형태로 묶어두면 적용 시간이 평균 10분에서 2분 이내로 줄어들었다.

코드 동작 방식과 실행 흐름 분석

NSSM 기반 서비스 실행 흐름은 입력 → 실행 → 상태 변환 → 결과 반환 구조로 동작한다. 입력은 exe 경로와 인자, 작업 디렉터리, 환경 변수 등이다. 이 값들은 서비스 설정으로 저장된다.

서비스가 시작되면 NSSM은 내부적으로 CreateProcess를 호출해 exe를 실행한다. 실행 결과로 생성된 프로세스 ID를 추적하며, 상태 변화를 감지한다. 프로세스가 정상 종료되면 종료 코드를 읽고, 설정된 정책에 따라 재시작 여부를 판단한다. 이 단계에서 조건 판단이 이루어진다.

nssm set MyService AppRestartDelay 5000

이 설정은 프로세스 종료 시 5초 후 재실행하도록 지정한다. 입력은 재시작 지연 시간이며, 결과는 프로세스가 중단된 이후 자동으로 다시 실행되는 형태다. 이 구조 덕분에 외부 장애나 내부 오류로 프로세스가 종료되더라도 서비스는 지속적으로 유지된다.

마지막 단계는 상태 반환이다. NSSM은 실행 상태를 SCM에 전달하고, 서비스 상태를 running 또는 stopped로 표시한다. 이 과정이 있기 때문에 일반 exe도 서비스처럼 관리된다.

Windows exe 서비스 등록 시 고려해야 할 조건

서비스로 등록할 exe는 반드시 콘솔 기반 또는 백그라운드 실행이 가능한 구조여야 한다. GUI 프로그램은 사용자 세션과 연결되지 않기 때문에 정상 동작하지 않는 경우가 많다. 또한 상대 경로 파일을 사용하는 경우 AppDirectory 설정이 없으면 실행 실패로 이어진다.

권한 문제도 자주 발생한다. 기본적으로 서비스는 LocalSystem 계정으로 실행되는데, 특정 파일이나 네트워크 자원에 접근할 때 권한이 부족할 수 있다. 이 경우 별도의 계정을 지정해야 한다.

nssm set MyService ObjectName ".\user" "password"

로그 파일 경로 역시 미리 생성되어 있어야 한다. 존재하지 않는 디렉터리를 지정하면 로그 기록 자체가 실패한다. 운영 환경에서는 로그 파일 크기가 증가하므로 rotation 설정을 함께 고려하는 것이 필요하다.

이 방식은 반복 실행이 필요한 작업, 서버 상주 프로세스, 장시간 실행되는 배치 프로그램에 적합하다. 반면 단순 일정 기반 작업이라면 작업 스케줄러가 더 단순한 선택이 될 수 있다. 상황에 따라 선택 기준이 달라진다.