서비스가 늘어나자 업데이트 관리가 일이 되기 시작했다
NAS에 Docker 서비스를 하나씩 추가할 때는 새로운 기능을 만들어가는 과정이 재미있었다. WordPress를 운영하고, Vaultwarden과 Jellyfin을 설치하고, AdGuard Home과 Uptime Kuma까지 추가하면서 NAS의 활용도도 조금씩 높아졌다.
처음에는 서비스를 설치하고 정상적으로 작동하는지 확인하는 것만으로도 충분했다. 문제가 생기면 설정을 살펴보고, 필요한 내용을 찾아 수정하면 됐다.
그런데 운영하는 서비스가 많아지면서 새로운 고민이 생겼다. 바로 업데이트였다.
Docker 컨테이너는 실행 중이라고 해서 항상 최신 버전인 것은 아니다. 개발자가 새로운 기능을 추가하거나 버그를 수정해도, NAS에서 실행 중인 컨테이너가 자동으로 그 버전으로 바뀌는 것은 아니다.
새로운 이미지를 확인하고, 내려받고, 기존 컨테이너를 교체한 다음, 서비스가 제대로 실행되는지 확인해야 한다.
컨테이너가 몇 개 없을 때는 직접 관리해도 괜찮았다. 하지만 서비스가 늘어나면 이 작업도 매번 반복해야 하는 일이 된다.
그래서 눈을 돌린 도구가 Watchtower였다.
Watchtower는 Docker 이미지에 업데이트가 있는지 확인하고, 조건에 맞으면 새 이미지를 내려받아 컨테이너를 교체해 주는 도구다. 잘 구성하면 반복적인 업데이트 작업을 줄일 수 있다.
하지만 자동 업데이트를 사용한다고 해서 모든 문제가 해결되는 것은 아니었다. 업데이트가 자동으로 된다는 것과 업데이트 이후에도 서비스가 정상적으로 작동한다는 것은 서로 다른 이야기이기 때문이다.
이번 글에서는 Watchtower가 어떤 일을 해주는지, 어디까지 자동화해도 괜찮은지, 그리고 현재 새로 구성하는 환경에서 무엇을 확인해야 하는지 정리해 보려고 한다.
1. Watchtower는 무엇을 자동으로 처리할까?
Watchtower의 기본 역할은 실행 중인 컨테이너가 사용하는 이미지에 업데이트가 있는지 확인하는 것이다.
새 이미지가 발견되면 Watchtower는 다음 과정을 자동으로 진행한다.
- 이미지 레지스트리에 새 버전이 있는지 확인한다.
- 업데이트가 필요한 이미지를 내려받는다.
- 기존 컨테이너를 정상 종료 절차에 따라 중지한다.
- 새 이미지로 컨테이너를 다시 생성하고 실행한다.
일반적인 구성에서는 기존 컨테이너가 사용하던 실행 옵션을 유지하면서 새 이미지로 교체한다. 따라서 매번 컨테이너를 직접 중지하고, 새 이미지를 내려받고, 다시 실행하는 수고를 줄일 수 있다.
예를 들어 매일 새로운 이미지를 확인하도록 설정해 두면, 업데이트가 필요한 컨테이너를 사람이 일일이 확인하는 작업을 줄일 수 있다.
그렇다고 Watchtower가 모든 유지보수 작업을 대신해 주는 것은 아니다.
Watchtower는 컨테이너의 이미지 업데이트를 자동화하는 도구이지, 해당 애플리케이션의 새로운 기능이나 데이터베이스 변경 사항을 모두 검증하는 도구는 아니다. 업데이트 이후 로그인, 데이터 저장, 외부 접속 같은 기능이 실제로 정상 작동하는지까지 사람이 확인해야 할 때가 있다.
또한 기존 컨테이너를 어떻게 생성했는지, 볼륨과 환경 변수를 어떻게 구성했는지에 따라 업데이트 이후 확인할 항목이 달라질 수 있다.
결국 Watchtower가 줄여주는 것은 반복적인 업데이트 작업이지, 서비스 운영에 필요한 판단과 검증까지는 아니다.
2. 자동 업데이트가 편리한 만큼 주의할 점도 있다
자동 업데이트를 적용하면 가장 먼저 체감하는 장점은 관리 부담이 줄어든다는 것이다.
여러 컨테이너의 업데이트를 직접 확인하지 않아도 되고, 새 이미지가 배포됐을 때 정해진 주기에 따라 업데이트를 진행하도록 할 수 있다. 서비스에 따라서는 최신 수정 사항을 빠르게 적용하는 데에도 도움이 된다.
그러나 자동 업데이트에는 분명한 위험도 있다.
업데이트가 항상 좋은 결과로 이어지는 것은 아니다
새 버전에는 버그 수정뿐 아니라 설정 방식의 변경, 기능 제거, 데이터 구조 변경 등이 포함될 수 있다. 이미지 자체는 정상적으로 내려받아 실행되더라도, 이전 설정과 호환되지 않거나 서비스 내부에서 오류가 발생할 수 있다.
예를 들어 데이터베이스가 사용하는 파일 형식이나 애플리케이션의 설정 방식이 바뀌었다고 생각해 보자. 컨테이너를 새 이미지로 교체하는 작업이 성공했다고 해도, 서비스의 모든 기능이 이전과 동일하게 작동한다는 보장은 없다.
따라서 중요한 서비스일수록 업데이트 전에 변경 사항을 확인하고, 백업을 확보하는 과정이 필요하다.
자동 업데이트는 백업을 대신하지 못한다
컨테이너 이미지와 실제 데이터는 구분해서 생각해야 한다.
이미지는 애플리케이션을 실행하는 데 필요한 파일을 포함한다. 반면 게시글, 계정 정보, 데이터베이스 내용, 사용자 설정 같은 데이터는 볼륨이나 별도의 저장 위치에 남아 있는 경우가 많다.
새 이미지로 컨테이너를 교체한다고 해서 저장된 데이터까지 자동으로 백업되는 것은 아니다.
더욱이 업데이트 과정에서 데이터 구조가 변경되면 이전 이미지로 되돌리는 것만으로 문제가 해결되지 않을 수도 있다.
그래서 자동 업데이트를 적용하기 전에 다음 사항을 확인하는 습관이 중요하다.
- 중요한 데이터가 별도 위치에 백업되어 있는가?
- 컨테이너의 설정과 볼륨 구성을 다시 확인할 수 있는가?
- 업데이트 이후 문제가 발생했을 때 복구 절차를 알고 있는가?
자동화 범위를 넓힐수록 이런 준비가 더 중요해진다.
3. 기존 Watchtower 프로젝트의 유지보수 상태가 달라졌다
이번 글에서 반드시 짚고 넘어가야 할 내용이 있다.
기존 Watchtower 프로젝트의 공식 GitHub 저장소인 containrrr/watchtower는 2025년 12월 17일 보관 처리되었으며, 읽기 전용 상태로 전환됐다. 기존 저장소에는 더 이상 새로운 변경 사항이 반영되지 않는다.
이 사실은 Watchtower가 갑자기 작동하지 않는다는 뜻은 아니다. 기존 이미지를 사용하고 있는 환경에서 당장 모든 컨테이너를 변경해야 한다는 의미도 아니다.
다만 Docker 엔진이 바뀌거나 새로운 보안 문제가 발견되었을 때, 기존 프로젝트에서 수정 사항을 계속 제공해 줄 것이라고 기대하기는 어렵다.
따라서 지금 새로 Watchtower를 구성한다면 예전 설치 안내서만 보고 이미지 이름을 그대로 복사하기보다는 프로젝트의 현재 상태를 확인해야 한다.
커뮤니티 포크도 확인할 수 있다
기존 프로젝트와 별도로 Nicholas Fedor가 관리하는 커뮤니티 포크가 있다.
이 프로젝트는 기존 Watchtower와 비슷한 방식으로 Docker 이미지 업데이트를 자동화하며, 문서와 코드 변경 사항도 별도로 관리하고 있다. 컨테이너 이미지 이름은 nickfedor/watchtower를 사용한다.
다만 이것은 기존 저장소 자체가 다시 유지보수되고 있다는 뜻은 아니다. 별도의 관리자가 운영하는 커뮤니티 프로젝트이므로 릴리스와 변경 사항, 지원하는 Docker API 버전 등을 확인한 뒤 선택하는 편이 좋다.
현재 공개된 문서에는 Docker API 버전 호환성에 관한 안내도 있다. 오래된 Docker 환경이라면 이미지가 정상적으로 실행되는지, 현재 NAS의 Container Manager 환경과 호환되는지를 먼저 확인해야 한다.
중요한 점은 특정 도구를 무조건 설치하는 것보다, 지금도 유지보수되고 있는지, 어떤 이미지가 실제로 배포되는지, 내 환경에서 지원되는지를 확인하는 습관이다.
4. 모든 컨테이너를 자동 업데이트해야 할까?
결론부터 말하면 그렇지 않다.
Watchtower는 기본 설정에 따라 실행 중인 컨테이너를 폭넓게 감시할 수 있다. 하지만 자동 업데이트를 적용할 대상을 명확하게 선택하는 방식이 더 안전할 수 있다.
자동 업데이트를 적용할 때는 서비스의 중요도, 데이터의 민감도, 복구 난이도 등을 함께 고려해야 한다.
| 서비스 유형 | 권장 관리 방식 | 이유 |
|---|---|---|
| 중요 데이터가 거의 없고 복구가 쉬운 서비스 | 자동 업데이트 검토 | 문제가 생겨도 복구 부담이 상대적으로 작음 |
| Uptime Kuma 같은 상태 확인 서비스 | 백업과 테스트 후 자동 업데이트 검토 | 감시 기능 자체가 중단될 수 있다는 점은 고려해야 함 |
| Jellyfin 같은 미디어 서비스 | 업데이트 방식과 호환성 확인 후 선택 | 플러그인, 하드웨어 가속, 설정 호환성을 확인할 필요가 있음 |
| WordPress와 데이터베이스 | 백업 후 직접 업데이트 권장 | 애플리케이션과 데이터베이스의 호환성 및 데이터 변경 위험 |
| Vaultwarden 같은 비밀번호 관리 서비스 | 백업 후 신중하게 직접 업데이트 | 계정 데이터와 접근 가능성이 중요함 |
| NAS 접속이나 네트워크에 핵심적인 서비스 | 별도 검토 후 결정 | 업데이트 실패 시 다른 서비스에 대한 접근까지 영향을 받을 수 있음 |
이 표는 절대적인 규칙이 아니라 관리 기준을 정할 때 참고할 수 있는 예시다. 자동 업데이트를 적용해도 괜찮은 서비스인지 판단하려면 실제 설정과 데이터 보존 방식을 확인해야 한다.
특히 데이터베이스와 연결된 서비스는 컨테이너만 새 이미지로 교체한다고 끝나지 않는다. 서비스 버전과 데이터베이스 버전 사이의 호환성, 백업 상태, 복구 방법까지 고려해야 한다.
나에게 중요한 서비스일수록 업데이트 작업 자체를 자동화하는 것보다 문제가 발생했을 때 복구할 수 있는 구조를 먼저 갖추는 것이 중요하다.
5. 업데이트 대상을 선택적으로 관리하는 방법
Watchtower의 유용한 기능 중 하나는 컨테이너별 라벨을 통해 업데이트 대상을 구분하는 것이다.
모든 컨테이너를 자동으로 감시하는 대신, 자동 업데이트를 허용할 컨테이너에만 라벨을 추가하도록 설정할 수 있다.
커뮤니티 포크의 문서에서도 WATCHTOWER_LABEL_ENABLE 설정과 com.centurylinklabs.watchtower.enable 라벨을 이용한 선택 방식이 안내되어 있다.
Watchtower 서비스의 Compose 설정은 다음과 같은 형태로 구성할 수 있다.
services:
watchtower:
image: nickfedor/watchtower:latest
container_name: watchtower
restart: unless-stopped
environment:
TZ: Asia/Seoul
WATCHTOWER_SCHEDULE: "0 17 3 * * *"
WATCHTOWER_LABEL_ENABLE: "true"
volumes:
- /var/run/docker.sock:/var/run/docker.sock위 예시는 커뮤니티 포크를 사용해 매일 오전 3시 17분에 업데이트를 확인하고, 라벨이 지정된 컨테이너만 대상으로 삼는 구성이다. 스케줄은 초·분·시·일·월·요일의 여섯 항목을 사용한다.
latest 태그는 이해하기 쉬운 예시로 넣었다. 실제 운영 환경에서는 배포 전에 프로젝트의 릴리스와 이미지 태그를 확인하고, 검증한 버전을 고정해 사용할지 결정하는 것이 좋다. 이 예시를 그대로 기존 NAS에 적용하라는 의미는 아니다.
자동 업데이트 대상으로 선택하려는 컨테이너에는 다음 라벨을 추가한다.
labels:
- "com.centurylinklabs.watchtower.enable=true"Watchtower의 WATCHTOWER_LABEL_ENABLE 설정이 켜져 있으면 라벨이 true인 컨테이너만 업데이트 대상으로 선택된다. 라벨이 없는 컨테이너는 자동 업데이트 대상에서 제외된다.
물론 라벨을 추가했다고 해서 무조건 안전해지는 것은 아니다. 각 서비스가 자동 업데이트에 적합한지 먼저 판단해야 한다. 중요한 데이터가 있는 서비스는 백업과 복구 계획을 마련한 뒤에 대상에 포함하는 편이 좋다.
그리고 Watchtower가 Docker 소켓을 사용한다는 사실도 기억해야 한다. /var/run/docker.sock을 컨테이너에 연결하면 해당 프로그램이 Docker 엔진을 관리할 수 있게 되므로, 사실상 호스트에 대한 매우 강력한 권한을 부여하는 셈이다.
따라서 신뢰할 수 있는 이미지와 출처를 선택하고, Docker API를 외부 인터넷에 무방비로 노출하지 않는 것이 중요하다.
6. 자동 업데이트 이후에는 무엇을 확인해야 할까?
업데이트가 끝났다는 메시지만으로 서비스가 정상이라고 판단해서는 안 된다.
가능하다면 업데이트 이후 다음 항목을 확인하는 습관을 들이는 것이 좋다.
첫째, 컨테이너가 실행 상태인지 확인한다. 컨테이너가 실행 중이어도 애플리케이션 내부에서 오류가 발생할 수 있으므로 로그도 함께 살펴봐야 한다.
둘째, 실제 서비스를 열어본다. 웹서비스라면 로그인과 주요 페이지 표시, 데이터 저장 같은 핵심 기능을 직접 확인할 수 있다. 미디어 서비스라면 라이브러리 접근이나 재생 기능처럼 해당 서비스에서 중요한 항목을 검사하면 된다.
셋째, 문제가 발견되면 원인을 확인하고 복구한다. 이때 이전 이미지가 남아 있다는 사실만으로 모든 문제가 해결되는 것은 아니다. 데이터베이스나 애플리케이션이 이미 데이터를 변경했다면 별도의 복구 작업이 필요할 수 있다.
또한 Watchtower의 이미지 정리 옵션을 활성화하면 사용하지 않는 이전 이미지가 제거될 수 있다. 저장 공간을 절약하는 데는 도움이 되지만, 이전 이미지로 되돌리는 선택지가 줄어들 수 있으므로 처음부터 무조건 켜기보다는 관리 방식에 맞춰 판단하는 것이 좋다.
자동 업데이트를 도입할 때는 업데이트 자체뿐 아니라 실패를 어떻게 감지하고 복구할 것인지까지 함께 설계해야 한다.
7. 업데이트 알림만 받고 직접 관리하는 방법도 있다
모든 업데이트를 자동으로 적용하는 것이 부담스럽다면, 새 이미지가 나왔다는 사실만 알려주는 도구를 사용하는 방법도 있다.
대표적인 예가 Diun이다.
Diun은 Docker 이미지에 업데이트가 있는지 감시하고 알림을 전달하는 데 초점을 둔다. Watchtower처럼 컨테이너 업데이트를 직접 수행하는 방식과는 다르다.
이런 도구를 사용하면 업데이트가 나왔다는 사실을 먼저 확인한 다음, 변경 내역과 호환성을 살펴보고 직접 업데이트할 수 있다.
특히 데이터가 중요하거나 서비스 중단에 민감한 환경에서는 자동으로 전부 업데이트하는 방식보다 알림을 받고 사람이 결정하는 방식이 더 적합할 수 있다.
자동화를 얼마나 적용할지는 결국 편리함과 안정성 사이의 균형 문제다.
마무리: 업데이트도 자동화하되, 판단까지 맡기지는 말자
NAS에 서비스를 하나씩 추가할 때는 새로운 기능을 설치하는 것에 집중했다. 하지만 서비스가 늘어나면서 설치 이후의 유지관리도 중요해졌다.
Watchtower는 이러한 반복 작업을 줄여주는 유용한 도구다. 정해진 주기에 따라 업데이트를 확인하고, 새 이미지로 컨테이너를 교체하는 과정을 자동화할 수 있다.
그러나 모든 컨테이너를 무조건 자동 업데이트하는 것이 항상 최선은 아니다. 서비스마다 데이터의 중요도와 복구 난이도가 다르기 때문이다.
이번에 다시 확인한 기존 Watchtower 프로젝트의 유지보수 종료 소식도 중요한 교훈이었다. 이미 설치해서 잘 사용하고 있는 도구라도, 시간이 지나면 프로젝트의 상태와 유지보수 방식이 달라질 수 있다.
그래서 이제는 도구를 설치할 때 기능만 보는 것이 아니라 다음과 같은 질문도 함께 하려고 한다.
- 현재도 유지보수되고 있는가?
- 업데이트 대상과 시점을 선택할 수 있는가?
- 문제가 발생했을 때 데이터를 복구할 수 있는가?
- 업데이트 결과를 확인하고 알림을 받을 수 있는가?
NAS를 직접 운영하면서 느낀 것은 자동화가 모든 일을 대신해 주는 마법은 아니라는 점이다. 반복 작업을 줄여주는 대신, 관리자는 어떤 일을 자동으로 맡기고 어떤 일은 직접 확인할지 정해야 한다.
자동화의 목적은 관리할 필요를 없애는 것이 아니라, 꼭 확인해야 할 일에 더 집중할 수 있도록 만드는 것이라고 생각한다.
서비스를 계속 추가하다 보니 정상적으로 작동하는지 확인할 방법이 필요했다. 이제는 업데이트도 같은 관점에서 바라보게 됐다. 자동으로 처리할 일과 직접 확인할 일을 구분하는 것, 그것이 여러 서비스를 운영하는 NAS에서 점점 더 중요해지고 있다.