리눅스를 설치해 본 사람이라면 파티션을 나누는 단계에서 별도의 스왑 영역을 지정한 경험이 있을 것이다. 오랫동안 배포판 설치 관리자는 디스크의 일부를 잘라 스왑 파티션으로 할당하도록 권장해 왔고, 이는 사실상 관례처럼 굳어졌다. 그런데 최근 다시 회자되는 한 개발자의 주장은 이 관례에 정면으로 의문을 제기한다. 요지는 간단하다. 스왑 파티션 대신 스왑 파일을 쓰라는 것이다.
주장의 핵심 근거는 성능이다. 원문에 따르면 스왑 파일은 20년 넘게 스왑 파티션과 동일한 성능 특성을 보여 왔다. 즉 파일 형태로 스왑을 두더라도 파티션 방식과 비교해 체감할 만한 속도 저하가 없다는 것이다. 그럼에도 리눅스 배포판들은 설치 과정에서 여전히 스왑 파티션을 권하고 있고, 사용자는 별다른 고민 없이 그 기본값을 따라간다. 성능 차이가 사라진 지 오래인데도 옛 방식이 관성으로 유지되고 있다는 지적이다.
왜 파일이 더 유연한가
스왑 파티션의 가장 큰 불편은 경직성이다. 파티션은 설치 시점에 디스크 레이아웃을 확정하면서 크기가 정해지고, 나중에 이를 늘리거나 줄이려면 인접 파티션 구조 전체를 건드려야 한다. 실제 운영 환경에서 파티션 크기 조정은 데이터 손실 위험을 동반하는 작업이라 쉽게 손대기 어렵다. 반면 스왑 파일은 파일 시스템 위에 존재하는 하나의 파일일 뿐이다. 원문의 표현대로 설치 이후에 추가하고, 제거하고, 수정하고, 확장하기가 훨씬 쉽다. 메모리 압박이 심해지면 파일을 하나 더 만들어 붙이고, 필요 없어지면 비활성화한 뒤 지우면 된다.
이 유연성은 특히 서버와 클라우드 환경에서 가치가 크다. 트래픽 패턴이 바뀌거나 워크로드가 달라지면서 필요한 스왑 용량은 얼마든지 변할 수 있는데, 파티션 방식이라면 이런 변화에 대응하기가 번거롭다. 스왑 파일은 이런 조정을 재부팅 없이, 디스크 구조를 흔들지 않고 처리할 수 있게 해 준다. 이것이 원문이 스왑 파일을 두고 모든 면에서 더 낫다고 단언하는 이유다.
만드는 방법과 도구 선택
원문은 구현 팁도 함께 제시한다. 스왑 파일을 만들 때 전통적으로는 dd 명령으로 지정한 크기만큼 파일을 채워 왔지만, 파일 시스템이 지원한다면 fallocate가 더 빠르다는 것이다. dd는 실제로 0으로 채운 블록을 디스크에 써 내려가는 방식이라 파일이 클수록 시간이 오래 걸린다. fallocate는 파일 시스템에 필요한 공간을 예약하도록 요청하는 방식이라 훨씬 신속하게 원하는 크기의 파일을 확보할 수 있다. 다만 원문도 전제하듯 이 방식은 파일 시스템의 지원 여부에 달려 있으므로, 지원하지 않는 환경에서는 dd로 되돌아가는 선택지가 여전히 유효하다.
실무자 입장에서 알아 둘 점은 원문이 다루지 않은 맥락에도 있다. 예컨대 일부 파일 시스템에서는 스왑 파일을 운용할 때 별도의 주의가 필요하고, 최대 절전 모드(하이버네이션)처럼 스왑 영역을 특정한 방식으로 참조하는 기능은 파일 기반 스왑과 상성이 다를 수 있다. 원문은 이런 세부 조건까지 짚지는 않으므로, 실제 적용 전에는 자신이 쓰는 배포판과 파일 시스템의 문서를 확인하는 편이 안전하다. 짧은 글의 강점이자 한계이기도 하다.
관례를 다시 볼 시점
이 글이 던지는 진짜 메시지는 특정 명령어의 우열이 아니라, 기본값을 의심하라는 태도에 가깝다. 스왑 파티션은 성능상의 이점이 사라진 뒤에도 오랫동안 표준처럼 남아 있었다. 설치 관리자가 권한다는 이유만으로 무비판적으로 따라온 셈이다. 물론 스왑 파티션이 잘못된 선택이라고 단정하기는 어렵고, 기존 구성이 문제없이 돌아가는 시스템을 굳이 갈아엎을 이유도 없다. 다만 새로 시스템을 구성하거나 스왑 용량을 손봐야 하는 상황이라면, 파일 방식이 주는 운용상의 자유를 진지하게 고려할 만하다. 성능이 같다면 더 다루기 쉬운 쪽을 택하는 것이 합리적이기 때문이다.