systemd Wants와 Requires 기준 정리

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

systemd Wants와 Requires 기준 정리

Wants=와 Requires=는 둘 다 다른 unit을 함께 끌어오는 dependency 설정이지만, 실패와 중지 상황을 다루는 강도가 다르다. 2026년 7월 29일 확인 기준 freedesktop.org의 최신 systemd.unit 문서는 Wants=를 weak requirement dependency, Requires=를 그보다 강한 requirement dependency로 설명한다.

실무에서 자주 헷갈리는 지점은 두 가지다. 첫째, 둘 다 "같이 시작하자"에 가깝지 "먼저 시작하자"는 아니다. 둘째, Requires=를 쓴다고 해서 상대 unit이 항상 살아 있어야 하는 것은 아니다. 이 글은 공식 문서 기준으로 Wants=, Requires=, After=를 어떻게 조합해야 안전한지 정리한다.

핵심만 먼저 보면

대부분의 서비스 연결에는 Wants=가 더 무난하다. systemd 공식 문서는 다른 unit이 시작에 실패하거나 transaction에 추가되지 못해도, Wants=를 선언한 현재 unit의 시작 자체는 계속 유효하다고 설명한다.

반면 Requires=는 더 강하다. 현재 unit을 시작할 때 대상 unit도 함께 시작하려고 시도하고, 대상 unit이 명시적으로 stop 또는 restart 되면 현재 unit도 함께 stop 또는 restart 된다. 다만 시작 순서가 중요하면 After= 또는 Before=를 별도로 적어야 한다.

Wants=는 언제 충분할까?

Wants=는 "가능하면 같이 올리자"에 가깝다. 예를 들어 애플리케이션 서비스가 캐시 서비스나 보조 워커를 함께 올리면 좋지만, 그 보조 서비스 하나가 실패했다고 해서 메인 서비스 자체까지 막고 싶지 않은 경우에 잘 맞는다.

공식 문서는 이것을 start-up hook의 권장 방식으로 설명한다. 즉 다른 unit을 부수 효과로 함께 당겨오되, 상대 실패 때문에 전체 부팅이나 상위 서비스 시작이 과도하게 깨지지 않게 하려면 Wants= 쪽이 보수적인 기본값이다.

[Unit]
Wants=redis.service
After=redis.service

[Service]
ExecStart=/usr/local/bin/example-app

위 예시는 Redis가 있으면 먼저 올리고, 없더라도 메인 앱의 기동 자체는 가능한 구조다. 물론 실제 애플리케이션이 Redis 없이는 동작하지 않는다면 이 설정은 약하다. 그 경우에는 Requires= 또는 애플리케이션 자체의 실패 처리가 더 맞을 수 있다.

Requires=는 무엇이 더 강할까?

Requires=는 대상 unit을 더 강하게 묶는다. 공식 문서 기준으로 현재 unit이 활성화되면 listed unit도 함께 활성화된다. 또 대상 unit이 명시적으로 stop 또는 restart 되면 현재 unit도 함께 stop 또는 restart 된다.

다만 여기서 흔히 오해하는 부분이 있다. 공식 문서는 대상 unit이 조건 검사 실패로 start job이 생기지 않거나, 서비스가 스스로 정상 종료하거나, 장치가 외부 이유로 사라지는 상황은 Requires=만으로는 모두 전파되지 않는다고 설명한다. 상대가 항상 active여야 한다는 보장이 필요하면 BindsTo=와 After= 조합까지 가야 한다.

[Unit]
Requires=postgresql.service
After=postgresql.service

[Service]
ExecStart=/usr/local/bin/example-api

이 조합은 데이터베이스가 명시적으로 내려가거나 재시작될 때 API도 영향을 받게 만들고 싶을 때 검토할 수 있다. 대신 systemd 공식 문서도 실패 서비스에 대한 강한 결합은 복원력을 떨어뜨릴 수 있으므로, 많은 경우 Wants=가 더 낫다고 안내한다.

왜 After=를 같이 적어야 할까?

이 부분이 가장 중요하다. 공식 문서는 requirement dependencies와 ordering dependencies가 서로 독립적이라고 명시한다. 즉 Wants=나 Requires=를 적어도 시작 순서는 자동으로 정해지지 않는다.

따라서 foo.service가 bar.service를 Wants=로 당겨오더라도, After=bar.service나 Before=bar.service가 없으면 두 unit은 같은 transaction 안에서 동시에 시작될 수 있다. 상대 서비스가 준비된 뒤에만 현재 서비스가 올라와야 한다면 dependency와 ordering을 둘 다 써야 한다.

 

 

자주 쓰는 선택 기준

첫째, 상대 unit이 실패해도 현재 서비스는 독립적으로 살아야 하면 Wants=를 먼저 본다. 둘째, 상대 unit의 명시적 stop 또는 restart가 현재 서비스에도 전파돼야 하면 Requires=를 검토한다. 셋째, 준비 완료 순서가 중요하면 거의 항상 After=를 함께 적는다.

넷째, 상대 unit이 예기치 않게 inactive가 되는 상황까지 강하게 묶어야 하면 Requires=만으로는 부족할 수 있다. 이 경우 공식 문서가 안내하는 BindsTo=와 After= 조합이 더 직접적이다.

언제 Wants=가 더 안전한 기본값일까?

메인 서비스의 핵심 기능은 유지하되, 보조 구성요소가 있으면 더 좋아지는 구조에서는 Wants=가 대체로 낫다. systemd 공식 문서가 "더 robust한 시스템을 위해서는 Wants가 더 나은 선택일 때가 많다"고 설명하는 이유도 여기에 있다.

예를 들어 캐시, 메트릭 수집기, 사전 준비용 원샷 서비스처럼 실패 시 전체 서비스를 막을 필요가 없는 대상이라면 Requires=는 과한 결합이 될 수 있다. 이런 경우에는 Wants=와 애플리케이션 내부의 graceful degradation이 더 자연스럽다.

FAQ

Q. Requires=를 쓰면 상대 서비스가 죽었을 때 항상 같이 내려가나?

항상 그렇지는 않다. 공식 문서는 명시적 stop 또는 restart 전파를 설명하지만, 조건 검사 실패나 일부 unit의 자발적 비활성화는 그대로 전파되지 않을 수 있다고 적고 있다.

Q. Wants=만 쓰면 상대 서비스가 먼저 준비된 뒤 시작되나?

아니다. Wants=는 requirement 축이고, 순서는 After= 또는 Before=가 담당한다. 준비 완료 이후에만 시작해야 한다면 After=를 함께 선언해야 한다.

Q. WantedBy=와 Wants=는 같은 뜻인가?

같은 방향의 설정은 아니다. Wants=는 [Unit] 섹션에서 직접 dependency를 선언하는 값이고, WantedBy=는 [Install] 섹션에서 enable 시 어떤 unit의 .wants/ 아래에 심볼릭 링크를 만들지 정하는 값이다.

정리

Wants=와 Requires=의 차이는 단순히 "약한가 강한가"에서 끝나지 않는다. 상대 실패를 어디까지 현재 서비스의 실패로 볼지, 명시적 stop과 restart를 전파할지, 그리고 시작 순서를 별도로 제어할지가 함께 판단 포인트다.

대부분의 경우에는 Wants=를 기본값으로 두고, 정말 강한 결합이 필요한 부분에만 Requires=를 쓰는 편이 운영상 덜 거칠다. 그리고 준비 완료 순서가 중요할 때는 dependency 종류와 별개로 After=를 빠뜨리지 않는 것이 핵심이다.

참고 자료

• systemd.unit
• systemd.service