기술자료

적용 환경

1. 가장 먼저 서비스 상태와 자동 시작 여부 확인

먼저 실제 서비스 이름을 확인한 뒤 현재 실행 상태와 부팅 자동 시작 상태를 구분해서 확인합니다. 다음 예시에서는 쉘 변수에 서비스 이름을 지정하여 이후 명령어에서 동일하게 사용합니다.

SERVICE=nginx.service
systemctl status "$SERVICE" --no-pager
systemctl is-active "$SERVICE"
systemctl is-enabled "$SERVICE"

is-active는 현재 서비스가 실행 중인지 확인하고, is-enabled는 재부팅 시 자동 시작하도록 연결되어 있는지 확인합니다. 서비스가 현재 active여도 disabled라면 다음 부팅에서 자동으로 시작되지 않을 수 있습니다.

유닛 파일이 어느 경로에서 로드되는지와 systemd가 인식한 상태도 함께 확인하면 설정 파일 혼동을 줄일 수 있습니다.

systemctl show "$SERVICE" -p FragmentPath -p UnitFileState -p ActiveState -p SubState
systemctl cat "$SERVICE"

2. disabled 서비스의 부팅 자동 시작 활성화

서비스 상태가 disabled라면 다음 명령으로 자동 시작을 활성화합니다. --now를 함께 사용하면 자동 시작 설정과 현재 서비스 시작을 한 번에 수행할 수 있습니다.

sudo systemctl enable --now "$SERVICE"

설정 후 다시 확인합니다.

systemctl is-enabled "$SERVICE"
systemctl is-active "$SERVICE"
systemctl status "$SERVICE" --no-pager

일반적으로 자동 시작이 정상적으로 설정되었다면 is-enabled에서 enabled를 확인할 수 있습니다. 다만 일부 소켓 활성화 서비스나 static 유닛은 동작 방식이 다르므로 상태 문자열만 보고 무조건 변경해서는 안 됩니다.

3. masked 또는 static 상태인 경우

masked 상태 해제

서비스가 masked로 표시되면 먼저 누가 왜 마스킹했는지 확인하는 것이 좋습니다. 의도하지 않게 마스킹된 것이 확실한 경우에만 마스킹을 해제한 뒤 자동 시작을 활성화합니다.

sudo systemctl unmask "$SERVICE"
sudo systemctl enable --now "$SERVICE"

static 상태는 무조건 enable하지 않기

static은 일반적으로 유닛 파일의 [Install] 섹션에 WantedBy= 또는 RequiredBy= 같은 enable용 정보가 없음을 의미할 수 있습니다. 이런 유닛은 다른 서비스, 소켓, 타이머 또는 target의 의존성에 의해 시작되는 구조일 수 있습니다.

static 유닛이 부팅 시 필요하다면 먼저 어떤 유닛이 해당 서비스를 불러오는지 확인합니다.

systemctl list-dependencies --reverse "$SERVICE"
systemctl cat "$SERVICE"

직접 작성한 사용자 정의 서비스이고 부팅 자동 시작이 필요한데 [Install] 섹션이 없다면, 서비스 특성을 검토한 후 유닛 파일에 다음과 같은 설치 정보를 둘 수 있습니다.

[Install]
WantedBy=multi-user.target

유닛 파일을 수정했다면 systemd 설정을 다시 읽은 뒤 활성화합니다.

sudo systemctl daemon-reload
sudo systemctl enable "$SERVICE"

4. 부팅 로그에서 자동 시작 실패 원인 확인

서비스가 enabled인데도 재부팅 후 실행되지 않는다면, 단순 활성화 문제가 아니라 실제 부팅 과정에서 시작 작업이 실패했을 가능성이 높습니다. 현재 부팅에서 해당 서비스 로그를 확인합니다.

sudo journalctl -b -u "$SERVICE" --no-pager

문제가 재부팅 직후 발생했고 현재는 수동으로 서비스를 다시 시작한 상태라면, 직전 부팅의 로그를 별도로 확인하는 것이 중요합니다.

sudo journalctl --list-boots
sudo journalctl -b -1 -u "$SERVICE" --no-pager

부팅 전체에서 실패한 유닛을 빠르게 찾으려면 다음 명령도 사용할 수 있습니다.

systemctl --failed

로그에서는 실행 파일을 찾지 못하는 문제, 권한 오류, 설정 파일 오류, 필요한 디렉터리 또는 파일 부재, 포트 충돌, 의존 서비스 실패, timeout 등의 실제 원인을 확인해야 합니다.

5. 유닛 파일과 부팅 의존성 점검

유닛 파일 내용 확인

systemd가 실제로 읽는 유닛 파일과 drop-in 설정을 확인합니다.

systemctl cat "$SERVICE"
systemctl show "$SERVICE" -p FragmentPath -p DropInPaths

사용자 정의 서비스라면 ExecStart=에서 실행 파일의 절대 경로가 올바른지, User=에 지정된 계정에 파일 접근 권한이 있는지, WorkingDirectory=가 실제로 존재하는지 확인하십시오. 터미널에서 실행할 때만 존재하는 셸 환경변수나 PATH에 의존하면 부팅 시 실패할 수 있습니다.

사용자 정의 유닛 파일 문법 검사

직접 만든 유닛 파일이라면 수정 후 systemd-analyze verify로 문법과 일부 참조 오류를 점검할 수 있습니다. 아래 경로는 예시이므로 실제 사용자 정의 유닛 파일 경로로 변경합니다.

sudo systemd-analyze verify /etc/systemd/system/example.service

오류를 수정한 다음 systemd에 변경 내용을 다시 로드합니다.

sudo systemctl daemon-reload

네트워크나 다른 서비스가 먼저 필요한 경우

서비스가 부팅 후 수동 시작하면 정상인데 부팅 중에만 실패한다면, 필요한 네트워크나 다른 서비스가 준비되기 전에 시작되고 있는지 확인합니다. 현재 선언된 의존성과 시작 순서는 다음 명령으로 살펴볼 수 있습니다.

systemctl show "$SERVICE" -p After -p Before -p Wants -p Requires
systemctl list-dependencies "$SERVICE"
systemd-analyze critical-chain "$SERVICE"

사용자 정의 서비스가 실제로 네트워크 연결이 준비된 이후에만 시작되어야 한다면, 서비스 특성에 따라 network-online.target에 대한 의존성과 순서 지정이 필요할 수 있습니다.

[Unit]
Wants=network-online.target
After=network-online.target

6. 재부팅 후 정상 작동 확인

설정을 완료했다면 먼저 현재 상태에서 서비스가 정상 시작되는지 확인한 뒤 재부팅합니다.

sudo systemctl restart "$SERVICE"
systemctl is-active "$SERVICE"
systemctl is-enabled "$SERVICE"

이상이 없다면 서버를 재부팅합니다.

sudo reboot

서버가 다시 올라온 뒤 새 SSH 세션에서 다음 항목을 확인합니다.

systemctl is-enabled "$SERVICE"
systemctl is-active "$SERVICE"
systemctl status "$SERVICE" --no-pager
sudo journalctl -b -u "$SERVICE" --no-pager

enabled 상태이면서 서비스의 성격에 맞게 active 상태를 유지하고, 현재 부팅 로그에 시작 실패가 없다면 자동 시작 설정이 정상적으로 적용된 것입니다. Type=oneshot 등 일부 서비스는 작업 완료 후 active (exited) 또는 다른 상태를 보일 수 있으므로 유닛의 동작 방식도 함께 확인해야 합니다.

7. 자주 발생하는 문제와 해결 방법

8. 원상복구 방법

이번 작업에서 자동 시작만 새로 활성화했다면 다음 명령으로 부팅 자동 시작을 다시 비활성화할 수 있습니다. disable만 실행하면 현재 실행 중인 서비스가 즉시 중지되는 것은 아닙니다.

sudo systemctl disable "$SERVICE"
systemctl is-enabled "$SERVICE"

사용자 정의 유닛 파일 또는 drop-in 설정을 수정했다면 변경 전 백업 파일을 복원한 다음 systemd 설정을 다시 읽고 서비스를 재시작합니다.

sudo systemctl daemon-reload
sudo systemctl restart "$SERVICE"

원래 서비스가 의도적으로 masked 상태였고 그 상태로 되돌려야 한다는 것이 명확한 경우에만 다음과 같이 다시 마스킹할 수 있습니다.

sudo systemctl mask "$SERVICE"

9. 자주 묻는 질문

systemctl start와 enable의 차이는 무엇인가요?

start는 현재 실행 중인 시스템에서 서비스를 시작하는 명령이고, enable은 일반적으로 다음 부팅 때 지정된 target 등이 해당 서비스를 불러오도록 연결을 구성합니다. 현재 시작과 자동 시작을 동시에 적용하려면 systemctl enable --now 서비스명을 사용할 수 있습니다.

enabled인데도 부팅 후 서비스가 실행되지 않는 이유는 무엇인가요?

enabled는 부팅 과정에서 서비스 시작 작업이 요청되도록 구성되었다는 의미이지, 실제 프로그램이 반드시 성공적으로 실행된다는 뜻은 아닙니다. journalctl -b -u 서비스명 또는 직전 부팅의 journalctl -b -1 -u 서비스명으로 실행 실패 원인을 확인해야 합니다.

static이라고 나오면 문제가 있는 것인가요?

반드시 문제는 아닙니다. static 유닛은 다른 유닛의 의존성이나 소켓·타이머 등의 방식으로 활성화되도록 설계될 수 있습니다. 패키지에서 제공하는 static 유닛을 임의로 수정하기보다 어떤 상위 유닛이 이를 필요로 하는지 먼저 확인하십시오.

서비스 유닛 파일을 수정한 뒤 꼭 daemon-reload가 필요한가요?

systemd 유닛 파일 또는 drop-in 설정을 변경했다면 systemctl daemon-reload로 systemd가 변경 내용을 다시 읽도록 해야 합니다. 이후 필요한 서비스의 재시작 또는 자동 시작 설정을 적용합니다.

부팅 직후 실패했지만 지금은 정상이라면 어떤 로그를 봐야 하나요?

현재 부팅에서 수동 복구한 뒤에는 실패 당시 로그가 섞여 보일 수 있습니다. 직전 부팅 문제가 재현된 상황이라면 journalctl -b -1 -u 서비스명을 사용해 이전 부팅의 해당 서비스 기록을 확인하는 것이 유용합니다.

10. 공식 참고자료

• Canonical Ubuntu - Ubuntu release cycle: Ubuntu 22.04 LTS의 표준 보안 유지보수 기간 확인. 조회일: 2026-08-09.
• Ubuntu Manpages - systemd.unit(5): [Install], WantedBy=, 유닛 의존성과 enable 시 생성되는 연결 구조 확인. 조회일: 2026-08-09.
• Ubuntu Manpages - daemon(7) - Writing and packaging system daemons: 부팅 시 서비스 활성화와 WantedBy=multi-user.target 또는 graphical.target 사용 원칙 확인. 조회일: 2026-08-09.
• Ubuntu Manpages - journalctl(1): --boot, --unit, 이전 부팅 로그 조회 방법 확인. 조회일: 2026-08-09.
• Ubuntu Manpages - systemd-analyze(1): 유닛 검증 및 부팅 의존성 분석 명령 확인. 조회일: 2026-08-09.