홈서버 메모리 점검 방법 : CPU 다음에 확인해야 하는 이유

 

 

※ 이 글은 운영자가 직접 Intel N100 홈서버에서 Debian과 Docker 기반 서비스를 운영하며 메모리 상태를 점검한 경험을 바탕으로 작성했습니다. 글의 문장 정리와 구성에는 AI 도구의 도움을 약간 받았지만, 최종 내용은 운영자가 직접 검토하고 확인했습니다.

홈서버 메모리 점검 방법 : CPU 다음에 확인해야 하는 이유

도입

지난 글에서는 서버 건강검진을 시작할 때 왜 CPU부터 확인하는지 살펴보았습니다.

CPU는 지금 서버가 얼마나 바쁘게 움직이고 있는지를 가장 먼저 보여주는 신호였습니다.

그렇다면 CPU를 확인한 다음에는 무엇을 보면 좋을까요?

처음에는 디스크 용량을 확인해야 할 것 같았습니다.

Docker 컨테이너 상태도 궁금했습니다.

WordPress와 n8n 같은 서비스가 정상적으로 열리는지도 확인하고 싶었습니다.

하지만 홈서버를 조금씩 운영하면서 CPU 다음에 자연스럽게 확인하게 된 항목이 있었습니다.

바로 메모리입니다.

CPU가 현재 얼마나 바쁘게 일하고 있는지를 보여준다면, 메모리는 그 작업을 처리하기 위해 사용할 수 있는 공간이 얼마나 남아 있는지 살펴보게 합니다.

그래서 이번 서버 건강검진에서는 CPU 다음 순서를 메모리로 정했습니다.

여기서 한 가지 질문이 생겼습니다.

왜 서버 건강검진은 CPU 다음에 메모리를 확인할까?

메모리는 단순히 몇 GB를 사용하고 있는지 확인하는 숫자가 아닙니다.

현재 서버가 작업을 처리할 여유가 있는지, 평소와 다른 변화가 나타나고 있는지 확인하는 중요한 단서가 될 수 있습니다.

이번 글에서는 메모리 사용량을 단순한 숫자로 보는 것이 아니라, 운영자의 입장에서 어떤 항목을 확인하고 어떻게 해석하면 좋을지 살펴보겠습니다.

CPU 점검 후 free -h 명령어를 이용해 available 메모리와 Swap 상태를 확인하고, 필요하면 top, htop, Docker 로그, OOM 기록까지 이어지는 홈서버 메모리 건강검진 흐름을 정리한 인포그래픽입니다.

※ 다이어그램은 실제 Intel N100 Debian 홈서버 메모리 점검 과정을 바탕으로 AI 도구를 활용해 제작했으며, 최종 구성과 내용은 운영자가 직접 검수했습니다.
출처: 디지털 장난감

본문

① CPU 다음에 메모리를 보는 이유

CPU와 메모리는 서로 다른 역할을 맡고 있습니다.

CPU는 계산과 처리를 담당합니다.

메모리는 그 과정에서 필요한 데이터와 프로그램의 작업 내용을 잠시 보관합니다.

역할은 다르지만 실제 서버에서는 두 자원이 함께 움직입니다.

예를 들어 WordPress에 접속자가 들어오면 PHP가 요청을 처리합니다.

데이터베이스도 필요한 정보를 찾고 결과를 돌려줍니다.

Docker 컨테이너 안의 애플리케이션도 자신의 작업을 수행합니다.

이 과정에서 CPU는 계산을 처리하고, 메모리는 실행 중인 프로그램과 필요한 데이터를 담아 둡니다.

그래서 CPU 사용률만 확인하면 서버 상태의 한쪽만 보는 셈이 될 수 있습니다.

CPU가 높다면 어떤 작업이 실행되고 있는지 확인합니다.

그다음 메모리를 살펴보면 그 작업을 처리하는 동안 사용할 수 있는 여유 공간이 충분한지도 함께 생각할 수 있습니다.

CPU는 서버가 얼마나 바쁜지 보여주고, 메모리는 그 작업을 감당할 여유가 얼마나 남아 있는지 살펴보게 합니다.

CPU는 안정적인데 서비스가 느리다면 메모리 부족이나 Swap 사용, 저장장치 또는 네트워크와 같은 다른 원인을 생각해 볼 수도 있습니다.

반대로 메모리 상태는 평소와 비슷한데 CPU만 순간적으로 높다면 일시적인 계산 작업이 진행되고 있을 가능성도 있습니다.

CPU와 메모리를 함께 보면 한 가지 숫자만 볼 때보다 서버의 현재 상태를 조금 더 입체적으로 이해할 수 있습니다.

② 메모리가 부족하면 어떤 일이 생길까?

메모리가 부족하다고 하면 가장 먼저 서버가 느려지는 모습을 떠올리게 됩니다.

실행 중인 프로그램이 필요한 공간을 충분히 확보하지 못하면 작업 처리 속도가 떨어질 수 있습니다.

Linux는 메모리가 부족한 상황에서 설정된 Swap 영역을 사용할 수도 있습니다.

Swap은 메모리의 일부 역할을 저장장치 공간으로 보완하는 방식입니다.

하지만 저장장치는 일반적으로 실제 메모리보다 느리기 때문에 Swap 사용이 많아지면 체감 성능이 떨어질 수 있습니다.

Docker 컨테이너가 사용할 수 있는 메모리가 부족해지면 애플리케이션이 느려지거나, 상황에 따라 프로세스가 종료될 가능성도 생각해야 합니다.

그렇다고 메모리 사용량이 높게 보인다는 이유만으로 곧바로 부족하다고 판단할 수는 없습니다.

Linux는 사용하지 않는 메모리를 무조건 비워 두기보다 파일 접근을 빠르게 하기 위한 캐시로 활용합니다.

처음에는 사용 중인 메모리 숫자가 높으면 문제가 생긴 것처럼 느껴질 수 있습니다.

하지만 캐시는 필요할 때 다른 프로그램이 사용할 수 있도록 반환될 수 있습니다.

메모리 점검에서는 단순한 used 숫자보다 실제로 새 작업에 사용할 수 있는 available 항목을 함께 보는 것이 중요합니다.

메모리가 높게 사용되고 있어도 available 공간이 충분하고 Swap 사용이 계속 늘어나지 않는다면 당장 부족하다고 단정할 필요는 없습니다.

반대로 available 공간이 계속 줄고 Swap 사용이 늘어나며 서비스까지 느려진다면 조금 더 자세히 확인할 필요가 있습니다.

③ free -h로 메모리 상태 확인하기

Debian 홈서버에서 메모리 상태를 간단하게 확인할 때 가장 먼저 사용할 수 있는 명령어는 free입니다.

free -h

-h 옵션은 메모리 용량을 사람이 읽기 쉬운 단위로 표시합니다.

결과 화면에는 여러 항목이 나타납니다.

항목	확인하는 내용
total	시스템에서 확인되는 전체 메모리 용량
used	현재 사용 중인 메모리
free	완전히 사용되지 않은 메모리
buff/cache	버퍼와 파일 캐시 등에 사용되는 메모리
available	새 프로그램이 사용할 수 있을 것으로 예상되는 메모리
Swap	Swap 전체 용량과 현재 사용량

처음에는 free 항목만 보고 남은 메모리가 거의 없다고 생각할 수 있습니다.

하지만 Linux가 캐시로 활용하고 있는 공간 가운데 필요할 때 다시 사용할 수 있는 부분이 있기 때문에 available 항목을 함께 확인해야 합니다.

첫 점검에서는 total, available, Swap 사용량 세 가지부터 확인해도 충분합니다.

처음부터 모든 숫자를 완벽하게 해석하려 하기보다, 같은 명령어를 반복해서 실행하며 평소 상태를 알아가는 것이 더 현실적입니다.

④ 더 자세한 정보는 어디에서 확인할까?

free -h보다 더 자세한 메모리 정보를 확인해야 한다면 다음 파일을 볼 수 있습니다.

cat /proc/meminfo

/proc/meminfo에는 전체 메모리와 사용 가능한 메모리, 캐시, Swap 등 여러 세부 항목이 표시됩니다.

다만 첫 번째 건강검진부터 모든 항목을 해석할 필요는 없습니다.

평소보다 메모리 여유가 크게 줄었거나, 특정 문제를 조금 더 자세히 확인해야 할 때 참고하는 자료로 생각하면 됩니다.

어떤 프로세스가 메모리를 많이 사용하고 있는지 확인할 때는 top이나 htop도 함께 활용할 수 있습니다.

top

또는 다음과 같이 실행합니다.

htop

CPU 점검에서 사용했던 도구가 메모리 점검에도 다시 등장합니다.

하나의 명령어가 CPU만 보여주는 것이 아니라 실행 중인 프로세스의 CPU와 메모리 사용 상태를 함께 보여주기 때문입니다.

⑤ 메모리 사용률은 어느 정도가 정상일까?

메모리를 확인하기 시작하면 CPU 때와 비슷한 질문이 생깁니다.

몇 퍼센트까지 사용해야 정상일까요?

70%를 넘으면 부족한 것일까요?

90%가 되면 바로 메모리를 추가해야 할까요?

하지만 메모리도 모든 서버에 똑같이 적용할 수 있는 하나의 정상 숫자로 판단하기 어렵습니다.

서비스의 종류와 개수, 작업 시간, 캐시 사용 방식에 따라 메모리 상태는 달라질 수 있습니다.

WordPress와 데이터베이스, n8n과 여러 Docker 컨테이너가 함께 실행되는 환경은 가벼운 서비스 하나만 실행하는 환경과 다릅니다.

그래서 이번 점검에서도 숫자 하나보다 변화의 흐름을 먼저 살펴봅니다.

상황	운영 관점
used 값은 높지만 available 공간이 충분함	캐시 사용을 포함한 정상적인 상태일 수 있음
available 공간이 계속 줄어듦	어떤 프로세스가 메모리를 늘려 사용하는지 확인
Swap 사용량이 일시적으로 나타남	발생 시점과 이후 변화 관찰
Swap 사용량이 계속 늘고 서비스가 느려짐	메모리 부족과 관련 프로세스를 자세히 점검
재시작 후에도 메모리 사용량이 빠르게 증가함	애플리케이션 또는 컨테이너의 반복적인 증가 여부 확인

평소 available 메모리가 충분했던 서버에서 특별한 변경 없이 여유 공간이 크게 줄었다면 원인을 살펴봅니다.

새로운 컨테이너를 추가했는지 확인합니다.

업데이트 이후 변화가 생겼는지 생각합니다.

백업이나 데이터 처리처럼 일시적으로 메모리를 많이 사용하는 작업이 진행 중인지 확인합니다.

그리고 이 변화가 잠깐 나타났는지, 시간이 지날수록 계속 커지고 있는지 관찰합니다.

메모리 건강검진의 핵심은 높은 숫자를 발견하는 것이 아니라, 평소와 다른 감소와 증가가 계속되는지 알아차리는 것입니다.

⑥ Swap은 사용되면 무조건 문제일까?

free -h를 실행하면 메모리 아래에 Swap 항목이 표시될 수 있습니다.

처음 Swap 사용량을 발견하면 메모리가 부족해진 것은 아닐까 걱정할 수 있습니다.

하지만 Swap이 조금 사용되었다는 사실만으로 바로 장애라고 단정할 수는 없습니다.

Linux는 사용 빈도가 낮은 메모리 페이지를 Swap으로 옮길 수 있고, 이후 실제 메모리에 여유가 생겨도 Swap 사용량이 바로 0으로 돌아오지 않을 수 있습니다.

따라서 Swap 숫자 하나보다 다음 내용을 함께 살펴봅니다.

• available 메모리가 충분한가?
• Swap 사용량이 계속 증가하고 있는가?
• 서비스 반응 속도가 평소보다 느려졌는가?
• 특정 프로세스의 메모리 사용량이 계속 늘고 있는가?

Swap이 조금 사용되고 있지만 시스템이 안정적이고 사용량도 더 늘지 않는다면 기록해 두고 지켜볼 수 있습니다.

반대로 available 공간이 거의 없고 Swap 사용량이 계속 늘며 서비스까지 느려진다면 메모리 부족 가능성을 조금 더 적극적으로 확인해야 합니다.

⑦ 5분 메모리 건강검진 흐름을 만들어 보자

이번 목요일 점검의 목적도 복잡한 메모리 분석이 아닙니다.

짧은 시간 안에 현재 상태를 확인하고 평소와 달라진 부분이 있는지 살펴보는 것입니다.

CPU 상태 확인

↓

free -h 실행

↓

total과 available 확인

↓

Swap 사용 여부 확인

↓

평소와 다른 변화 비교

↓

필요한 경우 프로세스 확인

큰 변화가 없다면 점검을 마칩니다.

available 공간이 평소보다 크게 줄었거나 Swap 사용량이 계속 늘어난다면 top이나 htop으로 어떤 프로세스가 메모리를 사용하고 있는지 확인합니다.

그리고 새로운 컨테이너 설치나 업데이트, 백업 작업처럼 변화가 발생한 시점과 연결되는 항목이 있는지 생각해 봅니다.

한 번 확인한 결과를 정답으로 여기지 않고 다음 점검에서도 같은 항목을 다시 비교합니다.

운영노트

처음 메모리 상태를 확인했을 때는 사용 중인 숫자에만 눈이 갔습니다.

전체 메모리 가운데 많은 부분이 사용되고 있으면 서버가 곧 느려질 것처럼 느껴졌습니다.

그래서 사용량을 줄이기 위해 무엇을 종료해야 할지 먼저 생각했습니다.

하지만 Linux가 남는 메모리를 캐시로 활용한다는 점을 알고 나니 화면이 조금 다르게 보이기 시작했습니다.

사용 중이라는 숫자 안에는 프로그램이 직접 사용하는 메모리만 있는 것이 아니었습니다.

파일 접근을 빠르게 하기 위한 캐시도 포함되어 있었습니다.

필요한 프로그램이 생기면 다시 사용할 수 있는 공간도 있었습니다.

그때부터 단순한 free 숫자보다 available 항목을 함께 보기 시작했습니다.

Swap이 조금 사용되었다고 바로 문제라고 판단하지도 않게 되었습니다.

대신 사용량이 계속 늘어나는지, 서비스가 느려졌는지, 특정 프로세스가 평소보다 많은 메모리를 차지하고 있는지 살펴보려고 합니다.

메모리 점검은 비어 있는 공간을 찾는 일이 아니라, 서버가 필요한 작업을 계속 감당할 여유가 있는지 알아가는 과정이었습니다.

CPU부터 확인한 뒤 메모리를 살펴보니 두 숫자가 따로 떨어져 있는 정보가 아니라는 점도 조금씩 보였습니다.

서버가 바쁘게 일하는 순간에는 메모리 상태도 함께 달라질 수 있습니다.

CPU는 안정적인데 서비스가 느릴 때는 메모리와 Swap을 다시 확인해 볼 수도 있습니다.

이렇게 하나씩 연결해서 바라보는 것이 이번 서버 건강검진에서 만들고 싶은 운영 습관입니다.

에디터의 해석노트

사용하지 않는 메모리가 많으면 좋은 서버일까요?

처음에는 그렇게 생각하기 쉽습니다.

메모리가 많이 비어 있으면 여유가 많고, 사용량이 높으면 부족한 상태처럼 보입니다.

하지만 운영체제의 입장에서는 사용하지 않는 자원을 그대로 비워 두는 것보다 성능을 높이는 데 활용하는 것이 더 효율적일 수 있습니다.

그래서 Linux는 남는 메모리를 캐시로 활용합니다.

문제가 되는 것은 메모리를 사용한다는 사실 자체가 아닙니다.

필요한 순간에 사용할 수 있는 여유가 부족한지, 그 부족한 상태가 계속되고 있는지가 더 중요합니다.

Swap 사용량도 같은 방식으로 바라볼 수 있습니다.

조금 사용되었다는 사실만으로 장애라고 판단하기보다, 계속 증가하는지와 실제 서비스 상태를 함께 봐야 합니다.

좋은 메모리 상태는 항상 많이 비어 있는 상태가 아니라, 필요한 작업이 생겼을 때 사용할 수 있는 여유를 안정적으로 유지하는 상태에 더 가깝습니다.

숫자는 현재 상태를 보여줍니다.

하지만 그 숫자의 의미는 서버가 어떤 작업을 하고 있는지에 따라 달라집니다.

그래서 서버 건강검진은 숫자에 점수를 매기는 일이 아닙니다.

내 서버의 평소 모습을 알아가고, 이전과 달라진 순간에 질문을 던지는 과정입니다.

참고 링크 (References)

1. Linux manual page : free
2. Linux manual page : /proc/meminfo
3. Linux Kernel Documentation : The /proc Filesystem
4. Debian Reference : System tips
5. Docker Documentation : Resource constraints

트러블슈팅

문제 1. free 값이 거의 없어서 메모리가 부족해 보인다

free -h 결과에서 free 숫자만 보지 않습니다.

Linux는 남는 메모리를 캐시로 활용하기 때문에 완전히 비어 있는 메모리가 적게 표시될 수 있습니다.

available 항목을 함께 확인해 새 프로그램이 사용할 수 있는 것으로 예상되는 공간이 얼마나 남아 있는지 살펴봅니다.

문제 2. Swap이 사용되고 있다

Swap 사용량이 있다는 이유만으로 바로 장애라고 판단하지 않습니다.

available 메모리와 Swap 사용량의 변화, 서비스 반응 속도를 함께 확인합니다.

Swap 사용량이 계속 늘고 서비스가 느려진다면 어떤 프로세스가 메모리를 많이 사용하는지 확인합니다.

문제 3. 메모리 사용량이 계속 증가한다

top이나 htop을 실행해 메모리를 많이 사용하는 프로세스를 확인합니다.

새로운 Docker 컨테이너나 서비스가 추가되었는지 살펴봅니다.

업데이트 또는 설정 변경 이후부터 증가하기 시작했는지도 확인합니다.

일시적인 작업이 끝난 뒤에도 사용량이 계속 늘어나는지 관찰합니다.

문제 4. Docker 컨테이너가 메모리 부족으로 종료된 것 같다

먼저 컨테이너 상태를 확인합니다.

docker ps -a

관련 로그를 확인합니다.

docker logs --tail 100 컨테이너이름

호스트의 커널 로그에서 OOM 관련 기록이 있는지도 확인할 수 있습니다.

journalctl -k | grep -i -E "out of memory|oom"

원인을 확인하기 전에 컨테이너를 무조건 삭제하거나 재설치하지 않습니다.

문제 5. 어떤 숫자를 기록해야 할지 모르겠다

처음부터 모든 항목을 기록하지 않습니다.

• 전체 메모리
• available 메모리
• Swap 사용량
• 평소와 다른 프로세스 유무

이 네 가지부터 같은 시간대에 반복해서 확인하면 평소 상태를 비교하기 쉬워집니다.

문제 상황	먼저 확인할 방향
free 메모리가 거의 없음	available과 캐시 상태 확인
Swap이 사용되고 있음	증가 추세와 서비스 체감 속도 확인
메모리 사용량이 계속 증가함	상위 프로세스와 최근 변경 사항 확인
컨테이너가 종료됨	컨테이너 로그와 OOM 기록 확인
기록할 항목을 모르겠음	total·available·Swap·상위 프로세스부터 기록

핵심 체크포인트 10

1. CPU 다음에 메모리를 확인하면 서버 자원의 현재 상태를 조금 더 입체적으로 볼 수 있다.
2. 메모리 사용량이 높다고 해서 항상 메모리 부족을 의미하는 것은 아니다.
3. Linux는 남는 메모리를 파일 캐시 등에 활용한다.
4. free -h에서는 단순한 free 값보다 available 항목을 함께 확인한다.
5. 처음에는 total, available, Swap 사용량부터 확인해도 충분하다.
6. 메모리 상태도 절대적인 정상 숫자보다 평소와 달라진 흐름을 비교하는 것이 중요하다.
7. Swap이 조금 사용되었다는 사실만으로 장애라고 단정하지 않는다.
8. available 공간이 계속 줄고 Swap 사용량이 늘어난다면 관련 프로세스를 확인한다.
9. Docker 컨테이너가 종료되었다면 컨테이너 로그와 OOM 기록을 함께 살펴본다.
10. 같은 항목을 반복해서 확인하면 내 홈서버의 평소 메모리 상태를 이해하는 기준이 쌓인다.

마무리

이번 글에서는 CPU 다음에 메모리를 확인하는 이유를 살펴보았습니다.

CPU는 서버가 얼마나 바쁘게 일하고 있는지 보여주는 첫 번째 신호였습니다.

메모리는 그 작업을 계속 처리할 수 있는 여유가 얼마나 남아 있는지 살펴보게 하는 두 번째 신호였습니다.

메모리 화면에서는 사용 중인 숫자가 먼저 눈에 들어옵니다.

하지만 Linux는 남는 공간을 캐시로 활용하기 때문에 used나 free 숫자 하나만으로 상태를 판단하기 어렵습니다.

그래서 available 메모리를 함께 확인합니다.

Swap 사용량도 살펴봅니다.

평소와 비교해 여유 공간이 크게 줄었는지 확인합니다.

특정 프로세스가 메모리를 계속 늘려 사용하고 있는지도 관찰합니다.

중요한 것은 메모리가 얼마나 많이 비어 있는지 경쟁하는 것이 아닙니다.

필요한 작업이 생겼을 때 서버가 그 일을 안정적으로 처리할 여유가 있는지 알아가는 것입니다.

CPU와 메모리를 함께 확인하는 짧은 습관은 서버가 바쁜 이유와 그 작업을 감당할 여유를 연결해서 바라보는 출발점이 됩니다.

이번 목요일에는 CPU 다음에 메모리 상태까지 확인해 보았습니다.

같은 항목을 꾸준히 살펴보며 내 홈서버의 평소 모습을 하나씩 알아가 보려고 합니다.