NAS 문제가 재현되지 않을 때 원인을 찾는 방법

NAS를 사용하다 보면 가장 답답한 상황이 있습니다.

분명 문제가 있었는데 지금은 아무 이상이 없는 경우입니다.

조금 전까지만 해도 파일을 여는 데 한참 걸렸는데 지금 다시 해보니 정상입니다.

접속이 안 됐는데 다시 접속해 보니 잘 됩니다.

파일 복사 속도가 갑자기 떨어졌는데 지금은 평소처럼 빠릅니다.

이럴 때 가장 흔히 하는 말이 있습니다.

“일단 정상으로 돌아왔으니 괜찮은 것 같네요.”

하지만 NAS 문제를 진단하는 입장에서는 오히려 이때부터가 중요합니다.

왜냐하면 문제가 사라졌다고 해서 원인이 없어진 것은 아니기 때문입니다.

특히 간헐적으로 발생하는 문제는 문제가 발생한 순간을 놓치면 원인을 찾기가 상당히 어려워집니다.

그래서 이번에는 지금은 문제가 재현되지 않는 NAS를 어떻게 진단해야 하는지 이야기해 보겠습니다.

문제가 재현되지 않는다고 진단할 수 없는 것은 아니다

문제를 찾을 때 흔히 생각하는 방법은 간단합니다.

문제가 발생하면 다시 똑같이 해보는 것입니다.

파일을 복사해서 느려지는지 확인하고,
폴더를 열어보고,
외부에서 접속해 보고,
같은 작업을 반복해 봅니다.

그런데 간헐적인 NAS 문제는 이 방법이 통하지 않을 때가 많습니다.

문제가 발생할 때는 분명 느렸는데 지금은 아무리 반복해도 정상입니다.

이때 중요한 것은 문제를 억지로 재현하려고 하는 것이 아니라 문제가 발생했던 당시의 흔적을 찾는 것입니다.

즉, 재현 중심의 진단에서 기록과 비교 중심의 진단으로 바꿔야 합니다.

가장 먼저 해야 할 일은 당시 상황을 적어보는 것이다

문제가 사라졌다면 기억이 생생할 때 당시 상황을 기록해 두는 것이 좋습니다.

예를 들어 다음과 같은 내용입니다.

언제 문제가 발생했는지

어떤 작업을 하고 있었는지

어떤 장치에서 문제가 발생했는지

어떤 파일이나 폴더를 사용했는지

얼마나 오래 문제가 지속됐는지

그 후 어떻게 정상으로 돌아왔는지

이런 내용은 별것 아닌 것처럼 보이지만 나중에 상당히 중요한 단서가 됩니다.

예를 들어

“오후 8시쯤 NAS에서 대용량 파일을 복사하다가 속도가 급격히 떨어졌고, 약 10분 뒤 정상으로 돌아왔다.”

정도로만 기록해도 훨씬 낫습니다.

그냥 “오늘 NAS가 느렸음.”이라고 기록하는 것과는 차이가 큽니다.

문제가 발생한 시간은 중요한 단서다

특히 시간이 중요합니다.

문제가 발생한 시간을 알 수 있다면 그 시간대의 NAS 상태와 다른 작업을 비교할 수 있기 때문입니다.

예를 들어 오후 9시 30분에 문제가 발생했다면 그 시간에

백업이 실행됐는지,

동기화 작업이 있었는지,

예약 작업이 실행됐는지,

Docker 컨테이너에서 작업이 발생했는지,

다른 장치가 NAS에 접근했는지

등을 확인할 수 있습니다.

문제가 지금 재현되지 않더라도 발생했던 시간대의 기록을 통해 과거 상황을 다시 살펴보는 것입니다.

로그가 있다면 삭제하지 말아야 한다

간헐적인 문제를 진단할 때 로그는 상당히 중요한 자료가 될 수 있습니다.

문제가 발생한 직후라면 관련 로그가 남아 있을 가능성이 있습니다.

DSM이나 개별 패키지, Docker 컨테이너 등에서 오류나 경고가 기록됐는지 확인해 볼 수 있습니다.

여기서 중요한 것은 단순히 ‘Error’라는 단어가 있는지만 보는 것이 아닙니다.

문제가 발생한 시간과 로그가 기록된 시간이 일치하는지를 확인해야 합니다.

예를 들어 오후 3시 10분에 파일 접근 문제가 발생했는데 같은 시간에 특정 서비스에서 반복적인 오류가 발생했다면 하나의 원인 후보가 될 수 있습니다.

반대로 오류가 전혀 다른 시간에 발생했다면 현재 문제와 직접적인 관련이 없을 수도 있습니다.

로그는 내용뿐만 아니라 시간까지 함께 봐야 합니다.

정상으로 돌아왔다면 정상 상태도 기록한다

문제가 해결된 것처럼 보일 때도 기록이 필요합니다.

예를 들어 오후 2시부터 2시 10분까지 문제가 발생했고 2시 11분부터 정상으로 돌아왔다면 정상으로 돌아온 시점도 적어두는 것입니다.

이렇게 하면 문제의 시작과 종료 구간을 만들 수 있습니다.

예를 들어

14:00 문제 발생

14:05 증상 지속

14:10 정상 회복

이라는 기록이 있다면 10분 동안 어떤 작업이 있었는지를 집중적으로 확인할 수 있습니다.

반대로 정확한 시간이 없다면 하루 전체의 기록을 뒤져야 하기 때문에 원인을 찾기가 훨씬 어려워집니다.

‘무엇이 바뀌었는가’도 확인해야 한다

문제가 재현되지 않는 상황에서는 최근 변경 사항도 확인할 필요가 있습니다.

예를 들어 문제가 발생하기 전에

새로운 패키지를 설치했는지,

Docker 컨테이너를 업데이트했는지,

설정을 변경했는지,

새로운 PC를 연결했는지,

백업 작업을 추가했는지,

저장된 데이터가 갑자기 크게 증가했는지 등을 살펴봅니다.

다만 여기서 주의할 점이 있습니다.

최근에 변경한 것이 있다고 해서 그것이 바로 원인이라는 뜻은 아닙니다.

최근 변경 사항은 원인이 아니라 단순히 시점이 겹친 것일 수도 있습니다.

따라서 변경 사항은 ‘원인’이 아니라 확인해야 할 후보로 생각하는 것이 좋습니다.

정상 상태와 문제가 발생했던 상황을 비교한다

문제가 다시 발생하지 않는다면 현재의 정상 상태를 기준으로 삼아보는 것도 좋은 방법입니다.

예를 들어 지금은

CPU 사용률 20%

디스크 사용량 낮음

네트워크 사용량 낮음

파일 접근 정상

이라고 해보겠습니다.

그렇다면 나중에 같은 문제가 다시 발생했을 때 이 상태와 비교할 수 있습니다.

“지난번에도 느렸을 때 CPU가 높았나?”

“디스크 작업이 증가했나?”

“네트워크 사용량도 같이 올라갔나?”

이런 식으로 비교할 수 있게 됩니다.

한 번의 장애만으로 원인을 찾지 못하더라도 정상 상태의 기준을 만들어 놓으면 다음 장애에서 훨씬 많은 정보를 얻을 수 있습니다.

문제가 다시 발생할 때까지 관찰하는 것도 방법이다

문제가 재현되지 않는다고 해서 계속 설정을 변경할 필요는 없습니다.

오히려 아무것도 바꾸지 않고 관찰하는 것이 더 좋은 경우도 있습니다.

특히 문제가 하루에 한 번 또는 일주일에 몇 번 정도 발생하는 수준이라면 변경을 최소화하고 다음 발생을 기다리는 편이 좋습니다.

왜냐하면 설정을 계속 바꾸면 다음에 문제가 발생했을 때 이전 상황과 비교할 수 없게 되기 때문입니다.

간헐적인 문제에서는 변경하지 않는 것도 하나의 진단 방법입니다.

다시 문제가 발생하면 이번에는 바로 확인해야 한다

그리고 문제가 다시 발생하면 이번에는 바로 확인합니다.

평소와 무엇이 달라졌는지 보는 것입니다.

CPU 사용률이 올라갔는지

메모리 사용량이 달라졌는지

디스크 작업이 증가했는지

네트워크 사용량이 변했는지

특정 서비스가 실행되고 있는지

특정 Docker 컨테이너가 작업 중인지

이전과 같은 파일이나 폴더에서 문제가 발생했는지

등을 확인합니다.

여기서 앞서 기록해 둔 첫 번째 장애와 비교하면 훨씬 유용합니다.

예를 들어 두 번의 장애에서 모두 디스크 작업량이 증가했다면 디스크와 관련된 원인을 우선적으로 살펴볼 수 있습니다.

반대로 첫 번째 장애에서는 디스크가 바빴지만 두 번째 장애에서는 네트워크 사용량만 증가했다면 두 현상이 같은 문제인지부터 다시 생각해야 합니다.

같은 증상이라고 같은 원인은 아니다

이 부분은 상당히 중요합니다.

‘NAS가 느려졌다’는 결과가 같다고 해서 원인까지 같은 것은 아닙니다.

첫 번째에는 백업 작업 때문에 느려졌을 수도 있고,

두 번째에는 네트워크 문제 때문에 느려졌을 수도 있습니다.

세 번째에는 특정 Docker 컨테이너가 CPU를 많이 사용했을 수도 있습니다.

사용자가 보기에는 모두 “NAS가 느리다.”라는 하나의 증상으로 보입니다.

하지만 실제 원인은 완전히 다를 수 있습니다.

그래서 증상만 기록하는 것이 아니라 증상이 발생했을 당시의 조건까지 기록해야 합니다.

재부팅은 마지막 단서까지 없앨 수 있다

문제가 발생했을 때 바로 NAS를 재부팅하는 것이 습관처럼 되어 있다면 한 번 생각해 볼 필요가 있습니다.

재부팅으로 문제가 해결되는 경우는 분명 있습니다.

하지만 진단이라는 관점에서는 재부팅 전에 확인할 수 있었던 정보가 사라질 수 있습니다.

어떤 프로세스가 CPU를 사용하고 있었는지,

디스크 작업이 많았는지,

특정 서비스가 응답하지 않았는지,

메모리 사용량이 비정상적이었는지

등의 당시 상태를 확인하지 못할 수 있기 때문입니다.

따라서 급한 상황이 아니라면 재부팅하기 전에 현재 상태를 먼저 기록하는 습관을 만들어 두는 것이 좋습니다.

물론 NAS가 정상적으로 동작하지 않거나 데이터에 위험이 있는 상황이라면 안정성을 우선해야 합니다.

간헐적인 문제는 ‘증거를 모으는 과정’이다

문제가 재현되지 않을 때 조급해질 필요는 없습니다.

오히려 이때는 다음 문제가 발생했을 때 확인할 수 있도록 환경을 준비하는 것이 좋습니다.

간단한 기록표를 만들어 놓는 것도 방법입니다.

항목	기록 내용
발생 시간	문제가 시작된 시간
종료 시간	정상으로 돌아온 시간
작업	당시 수행하던 작업
장치	사용한 PC·스마트폰 등
파일	특정 파일·폴더 여부
CPU	문제 발생 당시 사용량
디스크	디스크 작업량
네트워크	네트워크 사용량
변경 사항	최근 설치·업데이트·설정 변경
결과	재부팅·시간 경과 후 정상 등

처음에는 귀찮아 보일 수 있습니다.

하지만 같은 문제가 두세 번 발생하면 이 기록이 상당히 큰 차이를 만들어냅니다.

결국 중요한 것은 ‘다음 발생’을 준비하는 것이다

현재 문제가 재현되지 않는다면 지금 당장 해결책을 찾아내지 못할 수도 있습니다.

그렇다고 해서 아무것도 할 수 없는 것은 아닙니다.

오히려 다음 문제가 발생했을 때 놓치지 않도록 준비할 수 있습니다.

문제가 발생한 시간을 기록하고,

당시 수행하던 작업을 기록하고,

NAS의 상태를 확인하고,

관련 로그를 확인하고,

최근 변경 사항을 정리해 두는 것입니다.

그리고 같은 문제가 다시 발생했을 때 이전 기록과 비교합니다.

이렇게 한 번, 두 번 데이터를 쌓다 보면 처음에는 전혀 보이지 않았던 공통점이 나타날 수 있습니다.

마무리

NAS 문제가 재현되지 않을 때 가장 먼저 해야 할 일은 문제를 억지로 다시 발생시키는 것이 아닙니다.

문제가 발생했던 순간을 최대한 정확하게 복원하는 것입니다.

언제 발생했는지,

얼마나 지속됐는지,

무엇을 하고 있었는지,

어떤 장치에서 발생했는지,

NAS의 자원 사용량은 어땠는지,

그 시간에 어떤 작업이나 서비스가 실행됐는지를 확인합니다.

그리고 현재의 정상 상태와 비교할 수 있도록 기준을 만들어 둡니다.

간헐적인 NAS 문제는 한 번에 해결되지 않는 경우가 많습니다.

하지만 기록이 쌓이면 이야기가 달라집니다.

처음에는 “가끔 NAS가 이상하다.”였던 문제가 “특정 시간대에 특정 작업이 실행될 때 디스크 사용량이 증가하면서 문제가 발생한다.” 처럼 구체적으로 바뀌게 됩니다.

결국 NAS 진단에서 중요한 것은 문제를 무조건 다시 발생시키는 것이 아니라,

문제가 발생했을 때의 흔적을 놓치지 않는 것입니다.