내 자동 업데이트가 업그레이드하려던 에이전트를 죽였다

발행: (2026년 5월 7일 AM 01:25 GMT+9)
7 분 소요
원문: Dev.to

Source: Dev.to

Introduction

이론적으로는 자동 업데이트가 좋습니다. 패치된 시스템으로 깨어나고, 오래된 의존성이 줄어들며, 데몬이 업그레이드가 필요하다는 귀찮은 알림이 없다는 것은 이상적이죠.

The Incident

AI 게이트웨이에서 사용자 수준 systemd 서비스로 실행되는 OpenClaw 자동 업데이트를 활성화한 뒤, 에이전트가 응답을 멈췄습니다—한 번이 아니라 두 번이나요. 서비스에 Restart=always가 설정돼 있었기 때문에 systemd가 자동으로 복구할 것이라 기대했지만, 실제로는 게이트웨이가 다운된 상태로 남아 있었고 제가 로그인해서 수동으로 재시작하기 전까지는 복구되지 않았습니다.

Investigation

사용자‑systemd 저널에서 다음 순서를 확인했습니다:

  1. 게이트웨이가 실행 중이었다.
  2. 자동 업데이트가 시작되었다.
  3. 서비스가 중지되거나 강제 종료되었다.
  4. 분리된 재시작이 완료되기 전에 설치/재시작 경로가 실패했다.
  5. 복구할 활성 에이전트가 남아 있지 않았다.

별도의 재시작 로그에는 나중에 성공한 수동 재시작만 표시되었고, 실패한 자동 업데이트 이후의 재시작 시도에 대한 항목은 없었습니다. 이는 업데이트 흐름이 잘못된 중간 상태에 빠졌음을 의미합니다.

Root Cause

업데이트 프로세스 자체가 서비스를 중지했지만, 복구 로직도 동일한 프로세스 안에 포함돼 있었습니다. 업데이트가 실패하면 서비스를 복구할 외부 감독자가 없었고, Restart=always가 효과를 발휘하지 못했습니다.

핵심 포인트

  • 업데이트러가 의도적으로 중지하는 경우(업데이트러가 요청)와 무작위 충돌은 다릅니다; systemd는 이를 정상적인 중지로 간주합니다.
  • 업데이트러는 분리된 재시작 스크립트에 의존했으며, 해당 스크립트가 실행되지 않거나 환경을 잃어버리면 systemd는 재시작 요청을 받지 못합니다.
  • 프로세스가 실패를 보고하기 전에 사라질 수 있어, 로그에는 일반적인 “시도 실패” 항목만 남습니다.
  • 제어 평면과 워크로드가 동일한 프로세스에 있었던 것은 전형적인 설계 냄새이며, 실패 처리에 취약하게 만들었습니다.

Lessons Learned

  1. 자동 업데이트는 마법이 아니다. Restart=always가 모든 업데이트 오류를 복구해 주지는 않습니다.
  2. 감독자를 워크로드와 분리하라. 업그레이드를 수행하는 주체는 업데이트 대상 서비스와 별개여야 합니다.
  3. 실패 모드를 가시화하라. 조용히 실패하는 업데이트는 크게 소리 내어 오류를 보고하는 업데이트보다 훨씬 위험합니다.

Configuration Change

자동 업데이트는 비활성화하고, 수동 업데이트 확인은 유지했습니다:

{
  "update": {
    "auto": {
      "enabled": false
    },
    "checkOnStart": true
  }
}

이 구성을 적용하고 검증한 뒤, 게이트웨이는 다시 접근 가능해졌습니다. 이 방법은 완전 자동 셀프‑힐링 업그레이드만큼 화려하지는 않지만, 서비스가 조용히 벽돌이 되는 위험을 크게 줄여줍니다.

Safer Architecture

보다 신뢰할 수 있는 업그레이드 흐름은 감독자를 워크로드와 분리합니다:

[stable supervisor / timer]
        |
        v
[stop service]
        |
        v
[upgrade package]
        |
        v
[start service]
        |
        v
[health check + rollback / alert]

Desired Hardening Measures

  • systemd 타이머 또는 별도 업데이트 서비스 사용.
  • 게이트웨이를 중지하기 전에 명시적인 사전 검사 수행.
  • 모든 상태 전환을 기록하는 분리된 재시작 경로 구현.
  • 업데이트 후 건강 검사를 실행하고, 게이트웨이가 다운된 경우 롤백 또는 강력한 알림을 트리거.
  • 에이전트 프로세스가 자체 업그레이드 중에 살아남는 것에 의존하지 않기.

Conclusion

자동 업데이트는 복구 경로가 업데이트 경로보다 더 신뢰할 수 있을 때만 받아들여야 합니다. 그런 보장이 없을 때는 저는 수동이고 가시성이 높은 제어 모델을 선호합니다. 가장 겸손해지는 교훈은, 데몬이 스스로 사라지는 것을 순순히 자동화할 수 있다는 점이며, 이는 견고한 외부 감독이 필수임을 보여줍니다.

0 조회
Back to Blog

관련 글

더 보기 »

시스템 설계 트레이드오프

스케일링 - 수직 스케일링 vs 수평 스케일링 - 확장성 vs 성능 일관성 및 가용성 - 일관성 vs 가용성 CAP - 강한 일관성 vs 최종 일관성