Linux Swap을 사용하면 서버 성능이 무조건 저하되나요?

Swap을 사용한다는 사실 자체가 서버 성능 저하나 장애를 의미하지는 않습니다. Linux 커널은 RAM을 효율적으로 활용하기 위해 당장 사용하지 않는 메모리 페이지를 Swap 영역으로 이동시킵니다. 다만, 메모리 압박이 심한 상태에서 지속적인 Swap I/O가 발생하면 응답 시간이 급격히 증가할 수 있으므로, Swap 발생 원인과 서버 성능에 미치는 영향을 분석하는 것이 중요합니다.

Swap 공간을 무조건 크게 설정하는 것이 안전한가요?

아니요, Swap을 무조건 크게 설정한다고 해서 안전한 것은 아닙니다. 메모리 압박이 심한 서버에서 Swap을 과도하게 사용하게 되면 디스크 I/O 병목으로 인해 서버가 멈춘 것처럼 느껴질 정도로 성능이 저하될 수 있습니다. 따라서 서버의 실제 메모리 사용 패턴을 고려하여 적절한 크기로 설정해야 합니다.

Linux 커널은 어떤 기준으로 데이터를 Swap 영역으로 이동시키나요?

Linux 커널은 RAM이 한정된 자원임을 고려하여, 여러 애플리케이션이 메모리를 요청할 때 어떤 데이터를 RAM에 유지하고 어떤 데이터를 Swap으로 이동시킬지 판단합니다. 이때 커널은 애플리케이션 데이터, 파일 캐시, 커널 데이터 등을 페이지 단위로 관리하며, 당장 사용하지 않는 데이터를 디스크나 SSD의 Swap 영역으로 이동시켜 RAM 공간을 확보합니다.

Linux Swap은 정말 사용하면 안 될까? Swap 동작 원리와 운영 기준

2026년 10월 8일 읽는 시간 약 13분

서버를 운영하다 보면 “Swap은 느리기 때문에 사용하면 안 된다”는 말을 자주 접하게 됩니다. 실제로 free -m이나 free -h를 확인했을 때 Swap 사용량이 증가해 있으면 메모리가 부족한 것은 아닌지 걱정하기도 합니다.

하지만 Swap을 사용하고 있다는 사실 자체가 서버 장애나 메모리 부족을 의미하지는 않습니다. Linux 커널은 물리 메모리인 RAM을 효율적으로 활용하기 위해 당장 사용하지 않는 메모리 페이지를 Swap 영역으로 이동시킬 수 있습니다.

반대로 Swap을 무조건 크게 설정한다고 안전한 것도 아닙니다. 메모리 압박이 심한 서버에서 지속적인 Swap I/O가 발생하면 응답 시간이 급격히 증가하고, 심한 경우 서버가 멈춘 것처럼 느껴질 정도로 성능이 저하될 수 있습니다.

따라서 중요한 것은 “Swap을 사용하느냐”가 아니라 “왜 Swap이 발생했고 현재 서버 성능에 어떤 영향을 주고 있는가”를 판단하는 것입니다.

이번 글에서는 Linux Swap이 실제로 어떻게 동작하는지부터 Swap 사용량을 해석하는 방법, swappiness, Swap In/Out, 메모리 압박과의 관계, 그리고 운영 서버에서의 적절한 관리 기준까지 살펴보겠습니다.

Swap이 필요한 이유

Linux 서버에서 프로세스가 사용하는 메모리는 모두 RAM에만 존재하는 것처럼 보이지만 실제 메모리 관리는 훨씬 복잡합니다.

프로세스가 메모리를 요청하면 커널은 물리 메모리를 페이지 단위로 관리합니다. 이때 RAM에는 애플리케이션 데이터뿐 아니라 파일 캐시, 커널 데이터 등 다양한 정보가 함께 존재합니다.

문제는 RAM이 한정된 자원이라는 점입니다.

예를 들어 여러 애플리케이션이 동시에 실행되면서 메모리 사용량이 증가하면 커널은 어떤 데이터를 RAM에 계속 유지하고 어떤 데이터를 다른 곳으로 이동시킬지 판단해야 합니다.

이때 사용할 수 있는 공간이 Swap입니다.

Swap은 디스크 또는 SSD의 일부 영역을 메모리처럼 활용하는 방식입니다.

free -h

예를 들어 다음과 같이 나타날 수 있습니다.

               total        used        free      shared  buff/cache   available
Mem:            16Gi        9Gi        1Gi        500Mi        6Gi        6Gi
Swap:            4Gi      800Mi       3.2Gi

여기서 Swap 800MiB가 사용되고 있다고 해서 곧바로 RAM이 부족하다고 판단하면 안 됩니다.

과거에 메모리 압박이 발생했거나 커널이 사용 빈도가 낮은 페이지를 Swap으로 이동시킨 뒤 다시 RAM으로 가져올 필요가 없었다면 Swap 사용량이 그대로 남아 있을 수 있기 때문입니다.

따라서 Swap 사용량은 메모리 상태를 판단하는 여러 지표 중 하나일 뿐입니다.

Swap은 실제로 어떻게 동작할까?

Linux 메모리 관리에서 중요한 개념 중 하나가 **메모리 페이지(Page)**입니다.

프로세스가 사용하는 가상 메모리는 페이지 단위로 관리되며 커널은 필요한 페이지를 물리 메모리에 배치합니다.

RAM이 충분하다면 대부분의 활성 페이지를 RAM에 유지할 수 있습니다.

하지만 메모리 압박이 발생하면 커널은 메모리 확보를 위해 reclaim 작업을 수행합니다.

대표적으로 처리할 수 있는 대상은 크게 두 종류입니다.

File-backed Page
Anonymous Page

File-backed page는 파일과 연결되어 있기 때문에 필요하면 원본 파일에서 다시 읽을 수 있습니다. 대표적인 예가 Page Cache입니다.

반면 프로세스의 Heap이나 Stack 같은 Anonymous Memory는 단순히 버렸다가 파일에서 다시 읽어올 수 없습니다.

따라서 이런 페이지를 RAM에서 제거해야 한다면 내용을 보존할 공간이 필요합니다.

그 역할을 Swap이 담당합니다.

개념적으로 보면 다음과 같습니다.

Process
   ↓
Virtual Memory
   ↓
Physical RAM
   ↓
Memory Pressure
   ↓
Page Reclaim
   ↓
Inactive Anonymous Page
   ↓
Swap Area

페이지를 RAM에서 Swap으로 내보내는 것을 일반적으로 Swap Out, 다시 필요한 페이지를 Swap에서 RAM으로 읽어오는 것을 Swap In이라고 이해하면 됩니다.

문제는 RAM과 저장장치의 성능 차이입니다.

RAM 접근과 SSD 또는 디스크 접근에는 큰 성능 차이가 존재하기 때문에 Swap In/Out이 지속적으로 발생하면 애플리케이션 성능에도 영향을 줄 수 있습니다.

Swap 때문에 나타나는 실제 서버 증상

Swap 사용량이 조금 존재하는 것과 서버가 지속적으로 Swap에 의존하는 것은 전혀 다른 상황입니다.

예를 들어 다음과 같은 서버가 있다고 가정해 보겠습니다.

RAM       : 16GB
Swap      : 8GB
Application: 14GB 이상 사용

메모리 압박이 지속되면서 커널이 페이지를 Swap으로 내보내고, 애플리케이션이 다시 해당 페이지를 요청한다면 Swap In이 발생합니다.

그런데 RAM에 여유 공간이 부족하면 다른 페이지를 다시 Swap으로 내보내야 할 수도 있습니다.

이 과정이 반복되면 저장장치 I/O가 증가합니다.

운영 환경에서는 다음과 같은 증상이 함께 나타날 수 있습니다.

API 응답 시간 증가
웹 요청 처리 지연
DB 쿼리 지연
SSH 접속 및 명령 실행 지연
Disk I/O 증가
Load Average 증가
애플리케이션 처리량 감소

특히 심한 메모리 압박 아래에서 페이지를 Swap으로 내보내고 다시 읽어오는 작업이 반복되면 Thrashing 상태로 이어질 수 있습니다.

이때 CPU 사용률만 보면 원인을 바로 찾기 어려울 수도 있습니다.

CPU가 100%가 아니더라도 서버 전체 반응이 매우 느려질 수 있기 때문입니다.

따라서 서버가 느려졌을 때는 CPU와 RAM 사용률만 확인하는 것이 아니라 Swap 활동과 I/O 상태까지 함께 분석해야 합니다.

Swap 문제는 어떻게 분석해야 할까?

가장 먼저 확인할 명령은 다음과 같습니다.

free -h

여기서 단순히 free 값만 보면 안 됩니다.

Linux는 사용하지 않는 RAM을 Page Cache 등으로 적극적으로 활용하기 때문에 free가 작더라도 실제로 사용할 수 있는 메모리가 충분할 수 있습니다.

따라서 다음 항목을 함께 봐야 합니다.

available
Swap used

하지만 이것만으로도 부족합니다.

현재 Swap In/Out이 발생하는지 확인해야 합니다.

대표적으로 vmstat를 사용할 수 있습니다.

vmstat 1

출력에서 중요한 항목은 다음입니다.

si
so

si는 Swap In, so는 Swap Out과 관련된 값입니다.

여기서 중요한 것은 한 번의 값보다 지속적인 변화입니다.

Swap 사용량이 2GB라고 하더라도 si, so가 거의 움직이지 않고 서버 응답도 정상이라면 과거에 이동한 페이지가 그대로 Swap에 남아 있는 상황일 수 있습니다.

반대로 Swap 사용량 자체는 크지 않더라도 si, so가 지속적으로 발생하면서 애플리케이션 지연과 I/O 증가가 함께 나타난다면 메모리 압박을 의심해야 합니다.

보다 자세히 확인하려면 다음 명령도 활용할 수 있습니다.

sar -W 1 10

프로세스별 Swap 사용 상태를 조사할 때는 /proc 정보나 smem 같은 도구도 활용할 수 있습니다.

또한 메모리 상태를 볼 때는 다음 정보도 중요합니다.

cat /proc/meminfo

특히 다음 항목을 함께 확인하면 좋습니다.

MemAvailable
SwapTotal
SwapFree
Active
Inactive
AnonPages
Cached

즉, Swap 문제를 분석할 때는 단순히

Swap Used = 많음

이라는 기준으로 판단하면 안 됩니다.

메모리 여유 → Swap 사용량 → Swap In/Out → Disk I/O → 애플리케이션 지연

순서로 연결해서 분석해야 실제 원인을 찾기 쉽습니다.

swappiness를 낮추면 Swap 문제가 해결될까?

Linux Swap을 검색하면 자주 등장하는 설정이 vm.swappiness입니다.

현재 값은 다음과 같이 확인할 수 있습니다.

sysctl vm.swappiness

또는

cat /proc/sys/vm/swappiness

swappiness는 커널의 메모리 reclaim 과정에서 anonymous memory의 swapping과 file-backed page reclaim 사이의 판단에 영향을 주는 설정입니다.

여기서 흔한 오해가 있습니다.

swappiness 값을 특정 숫자로 설정하면 RAM 사용률이 그 수준에 도달했을 때 Swap을 시작한다는 의미가 아닙니다.

예를 들어

vm.swappiness = 10

이라고 해서 RAM 사용률 90%까지 절대로 Swap을 사용하지 않는다는 뜻은 아닙니다.

이 값은 메모리 reclaim 과정에서 커널의 선택에 영향을 주는 조정값으로 이해하는 것이 더 정확합니다.

운영 서버에서는 워크로드 특성에 따라 값을 조정할 수 있지만 무조건 낮게 만드는 것이 정답은 아닙니다.

특히 데이터베이스, JVM 애플리케이션, 캐시 서버처럼 메모리 사용 패턴이 다른 서비스는 동일한 값을 일괄 적용하기보다 실제 메모리 압박과 latency 특성을 기준으로 판단해야 합니다.

운영 서버에서는 Swap을 어떻게 관리해야 할까?

가장 위험한 접근은 다음 두 가지입니다.

Swap은 느리니까 무조건 끈다.
Swap이 있으니까 메모리가 부족해도 괜찮다.

둘 다 적절한 운영 기준이라고 보기 어렵습니다.

Swap이 없고 물리 메모리가 부족해지면 커널은 reclaim을 시도한 뒤 상황에 따라 OOM(Out Of Memory) 처리 단계로 들어갈 수 있습니다.

이 과정에서 OOM Killer가 특정 프로세스를 종료할 수 있습니다.

반대로 Swap을 매우 크게 구성했다고 해서 메모리 부족 문제가 해결되는 것도 아닙니다.

예를 들어 애플리케이션이 실제 필요한 working set보다 RAM이 지속적으로 부족한 상태라면 Swap은 부족한 물리 메모리를 근본적으로 해결하지 못합니다.

오히려 서버가 프로세스를 즉시 종료하지 않은 채 심각한 I/O 지연 상태에 오래 머무르는 상황도 발생할 수 있습니다.

따라서 운영 환경에서는 다음 관계를 보는 것이 중요합니다.

RAM 사용량
        ↓
MemAvailable
        ↓
Memory Pressure
        ↓
Page Reclaim
        ↓
Swap In / Swap Out
        ↓
Disk I/O
        ↓
Application Latency

Swap 사용량만 모니터링하기보다는 이 흐름 전체를 관찰해야 합니다.

메모리 부족이 반복된다면 애플리케이션의 메모리 누수 여부, 프로세스별 RSS, 캐시 크기, 컨테이너 메모리 제한, JVM Heap 설정 등을 먼저 점검하고 필요하다면 RAM 증설이나 서비스 구조 변경까지 고려해야 합니다.

정리

Linux에서 Swap은 단순한 비상용 메모리 공간이 아니라 커널 메모리 관리 전략의 일부입니다.

따라서 Swap이 사용되고 있다는 사실만으로 서버 상태가 나쁘다고 판단할 수 없습니다.

운영자가 더 중요하게 봐야 하는 것은 현재 메모리 압박이 존재하는지, Swap In/Out이 지속적으로 발생하는지, 그리고 그 과정이 실제 서비스 latency와 I/O에 영향을 주고 있는지입니다.

핵심 흐름을 정리하면 다음과 같습니다.

메모리 사용 증가
      ↓
메모리 압박 발생
      ↓
커널의 Page Reclaim
      ↓
필요에 따라 Anonymous Page Swap Out
      ↓
페이지 재접근 시 Swap In
      ↓
지속적인 Swap I/O 발생
      ↓
응답 지연 및 성능 저하 가능

결국 운영 환경에서 중요한 질문은 “Swap을 사용하고 있는가?”가 아닙니다.

“현재 서버가 Swap에 지속적으로 의존하고 있는가?”

이 질문을 기준으로 MemAvailable, vmstat의 si/so, Disk I/O, 애플리케이션 응답 시간을 함께 분석해야 합니다.

Swap은 무조건 제거해야 하는 기능도 아니고, 부족한 RAM을 대신하는 해결책도 아닙니다. 정상적인 메모리 관리와 실제 메모리 부족을 구분하기 위한 하나의 중요한 관찰 지표로 보는 것이 가장 적절합니다.