Synology NAS가 갑자기 꺼졌다. 전원 문제인가 싶었지만 다시 켜진 DSM에는 NVMe 캐시 과열로 보호 종료를 시작했다는 기록이 남아 있었다. 처음에는 Docker 컨테이너를 많이 돌려 CPU가 과열된 줄 알았다. 로그를 따라가 보니 직접적인 원인은 다른 곳에 있었다.
1. 종료 시각부터 로그를 따라갔다
이번 종료는 2026년 8월 11일 오전 9시 41분에 시작됐다. DSM 시스템 로그에는 원인이 꽤 직접적으로 적혀 있었다.
2026/08/11 09:41:41
Disk overheat: Disk [Cache device 2] had reached 70°C, shutdown system now.
2026/08/11 09:41:45
Server started counting down to shutdown.나는 온도가 내려가기를 기다린 뒤 약 한 시간 반 후 NAS의 전원을 직접 켰다. DSM이 자동으로 재부팅한 것은 아니다.
2026/08/11 11:06:51
System started to boot up.CPU나 일반 하드디스크가 아니라 2번 NVMe 캐시 SSD가 70°C에 도달했고, DSM이 보호 종료 절차를 시작한 것이었다. 전원이 갑자기 끊긴 사건과는 구분해야 했다.
여기서 70°C를 모든 NVMe SSD의 공통 안전 기준이라고 말할 수는 없다. 내가 확인한 사실은 이 DS920+와 당시 DSM 환경에서 Cache device 2가 70°C에 도달했을 때 해당 로그와 보호 종료가 발생했다는 것까지다.
2. 같은 SSD에서 이미 한 번 발생했다
로그를 더 거슬러 올라가 보니 일회성 문제가 아니었다. 7월 2일에도 같은 장치가 똑같이 70°C에 도달했다.
2026/07/02 04:20:53
Disk overheat: Disk [Cache device 2] had reached 70°C, shutdown system now.두 번 모두 Cache device 2였고 장치 시리얼도 같았다. 단순히 그날 방이 더웠던 것으로 넘기기 어려웠다. 2번 SSD 자체의 발열 특성, M.2 슬롯 주변의 공기 흐름, 캐시 쓰기 부하를 함께 의심해야 하는 상황이었다.
다만 당시 실내 온도와 NVMe 온도 변화, 작업별 I/O가 연속 기록된 것은 아니었다. 로그는 반복 과열을 증명하지만, 그 직전 무엇이 온도를 끌어올렸는지까지 보여주지는 않았다.
3. 여러 서비스가 같은 NVMe 캐시를 사용하고 있었다
사용 중인 NAS는 Synology DS920+다. 하단 M.2 슬롯에는 같은 모델의 SK hynix 256GB NVMe SSD 두 개가 들어 있다.
- NAS: Synology DS920+
- DSM: 7.2.2-72806 Update 9
- NVMe: SK hynix HFS256GD9TNG-L2A0A 256GB 두 개
- 구성: NVMe RAID1
- 저장 경로: /volume1이 cachedev_0 캐시 계층을 통해 연결
Synology 설명에 따르면 SSD 캐시는 주로 임의 I/O 작업을 가속한다. 내 환경에서는 GitLab, WordPress, 데이터베이스, 여러 Docker 컨테이너와 Hermes의 세션·로그가 모두 /volume1 위에서 움직이고 있었다.
캐시를 사용한다고 모든 작업이 같은 방식으로 SSD에 기록된다고 단순화할 수는 없다. 캐시 정책과 작업 부하에 따라 실제 효과와 쓰기 패턴은 달라진다. Synology는 모델과 호환되는 SSD 사용을 권장하고 있으므로, 장치를 교체한다면 공식 호환성 목록도 함께 확인해야 한다.
4. Hermes가 온도를 올렸을까
가능성은 있다. Hermes를 NAS에서 계속 실행하면 대화 세션, 도구 실행 결과, 캐시, 로그, 임시 파일이 지속적으로 저장된다. 에이전트가 파일을 다루거나 빌드와 분석을 반복하는 날에는 쓰기 작업이 더 늘어난다. 이런 I/O가 NVMe 캐시를 통과한다면 발열에 보탬이 될 수 있다.
그렇다고 이번 종료의 원인을 Hermes 하나로 단정할 수는 없다. DSM 로그가 증명하는 것은 2번 NVMe SSD가 70°C에 도달했다는 사실까지다. 당시 컨테이너별 디스크 쓰기량과 NVMe 온도 추이가 남아 있지 않았고, GitLab과 데이터베이스처럼 원래 쓰기가 많은 서비스도 같은 볼륨을 사용한다.
지금 내 판단은 이렇다. Hermes의 지속적인 I/O가 기여 요인일 수는 있지만, 같은 SSD에서 두 번 반복된 만큼 장치 자체, 슬롯 위치, 냉각 구조도 함께 확인해야 한다. 직접 원인과 가능성 있는 기여 요인을 구분해서 기록하는 것이 중요했다.
5. 재부팅 뒤 상태와 6일 후 상태를 따로 봤다
재부팅 직후에는 읽기 전용으로 상태를 점검했다. 당시 측정값은 다음과 같았다.
| 항목 | 8월 11일 점검 결과 |
|---|---|
| 시스템/CPU 센서 | 약 62~64°C |
| HDD 1 | 45°C |
| HDD 2 | 47°C |
| HDD RAID | 정상 |
| NVMe RAID | [UU], 두 장치 모두 연결됨 |
| 현재 온도 경고 | 없음 |
| 팬 모드 | 냉각 모드(cool), 과열 후 수동 변경 |
보호 종료 기준에 걸린 상태는 아니었지만 전체적으로 아주 시원한 상태도 아니었다. 여기서 시스템/CPU 센서와 HDD 온도는 NVMe 온도가 아니다. 재부팅 후 다른 센서가 정상이라고 해서 과거의 Cache device 2 과열 기록이 사라지는 것도 아니다.
NVMe SMART 정보도 읽어 보려 했지만 DSM에 포함된 smartctl 6.5가 해당 NVMe의 Identify Controller 요청을 처리하지 못했다. 이 오류를 SSD 고장으로 해석하지 않고, SMART 상태는 확인하지 못한 항목으로 남겼다.
8월 17일에 다시 로그와 현재 상태를 확인했다. 8월 11일 이후 새로운 NVMe 과열 이벤트는 없었고, 시스템 센서는 48°C, 온도 경고는 없었다. 팬은 과열 이후 내가 수동으로 바꾼 냉각 모드(cool)를 유지하고 있었다. 다만 6일 동안 재발하지 않았다는 사실만으로 문제가 해결됐다고 결론 내리기에는 이르다.
6. 다음에는 추측보다 기록을 남기기로 했다
과열 전에는 무음 팬 모드를 사용하고 있었다. 온도를 조금이라도 낮추기 위해 내가 직접 팬 설정을 한 단계 높은 냉각 모드(cool)로 변경했다. DSM이 자동으로 바꾼 설정은 아니다. 이후 다음 조치는 위험이 낮은 것부터 순서대로 진행하려고 한다.
- NAS 후면과 하단의 먼지, 주변 공간, 실내 온도 확인
- 두 캐시 SSD의 DSM 상태·남은 수명·펌웨어·온도 이력 비교
- 컨테이너별 디스크 읽기·쓰기량과 NVMe 온도를 같은 시간축으로 기록
- 이번에 관측한 70°C보다 충분히 앞서 알 수 있도록 사전 경고 설정
- 중요 데이터의 백업과 실제 복원 가능 여부 확인
- 재발하면 DSM에서 SSD 캐시를 안전하게 제거한 뒤 장치와 슬롯을 분리 진단
마지막 단계는 특히 주의해야 한다. 캐시 SSD를 본체에서 바로 뽑으면 안 된다. 먼저 DSM 저장소 관리자에서 SSD 캐시를 정상적으로 제거하고 작업 완료를 확인해야 한다. Synology의 SSD 캐시 관리 절차를 확인한 뒤, 전원을 끄고 장치를 다뤄야 한다.
그다음 두 SSD의 위치를 바꿔 같은 조건에서 관찰하면 문제를 조금 더 좁힐 수 있다. 과열이 SSD를 따라가면 장치 쪽을, 계속 같은 슬롯에서 발생하면 슬롯과 공기 흐름을 더 의심할 수 있다. 얇은 방열판이나 써멀패드도 선택지지만, DS920+ 내부 공간과 부품 간섭, 제품 호환성을 먼저 확인하지 않고 붙이지는 않으려고 한다.
7. 자동화는 소프트웨어 밖에도 흔적을 남겼다
Hermes를 NAS에 올린 뒤에는 에이전트가 쉬지 않고 일할 수 있다는 점만 생각했다. 그런데 계속 일한다는 말은 CPU와 메모리뿐 아니라 저장장치에도 계속 일을 시킨다는 뜻이었다.
이번에는 DSM이 70°C에서 먼저 멈췄다. 같은 일이 두 번 있었다는 사실은 그냥 넘길 수 없다. 앞으로는 에이전트가 무엇을 했는지만 기록하지 않고, 그 작업이 NAS의 I/O와 온도에 어떤 흔적을 남겼는지도 같이 보려고 한다.
답글 남기기