메모리 스왑이란: 클로드 코드와 코덱스를 여러 개 켜면 램이 부족한 이유

Orca나 VS Code에서 Claude Code 세션을 세 개쯤 띄우고 Codex까지 하나 더 켜면 컴퓨터가 버벅이기 시작합니다. 입력한 글자가 늦게 찍히고, 창을 바꿀 때 잠깐 멈추고, 활성 상태 보기를 열면 스왑 사용 숫자가 몇 GB씩 올라가 있습니다. 모델은 앤트로픽과 OpenAI의 데이터센터에서 돌아간다는데 왜 내 컴퓨터의 램이 모자라는지는 잘 설명되지 않습니다.

이 글은 그 이유를 단계별로 풉니다. 램과 스왑이 무엇인지, 코딩 AI 세션이 내 램을 어디에 쓰는지, 세션을 늘리면 왜 빠르게 차는지, 램이 부족하면 무슨 일이 생기는지, 스왑이 답변 품질을 떨어뜨리는지, 저장 용량과 램은 어떤 관계인지 순서대로 봅니다.

램과 저장 장치, 스왑의 뜻

램(RAM)은 컴퓨터가 지금 실행 중인 프로그램과 프로그램이 쓰는 데이터를 올려 두는 메모리입니다. 전원을 끄면 내용이 사라지지만 매우 빠릅니다. 저장 장치(SSD)는 파일을 보관하는 곳으로, 전원을 꺼도 남지만 램보다 느립니다. 처음에는 책상과 서랍장으로 생각하면 이해가 빠릅니다.

램과 저장 장치의 역할

램과 SSD≈책상과 서랍장

• 램 용량책상 넓이. 동시에 펼쳐 둘 수 있는 서류의 양
• SSD 용량서랍장 크기. 보관할 수 있는 서류의 양
• 스왑책상이 꽉 차서 펼쳐 둔 서류 일부를 서랍에 넣었다가 필요할 때 다시 꺼내는 일

비유가 맞지 않는 곳 실제 운영체제는 서랍에 넣는 것 말고도 책상 위 서류를 압축해 공간을 늘립니다. 이 방법은 뒤에서 다룹니다.

스왑(swap)은 램이 부족할 때 운영체제가 램 속 데이터 일부를 SSD의 파일로 옮겨 두는 기능입니다. 옮긴 데이터를 다시 쓰려면 SSD에서 읽어 램으로 되돌려야 하므로 그만큼 기다리게 됩니다. macOS에서는 이 파일을 스왑 파일, Windows에서는 페이징 파일(pagefile.sys), 리눅스에서는 스왑이라고 부릅니다.

모델은 데이터센터에서, 작업은 내 컴퓨터에서

Claude Code와 Codex CLI는 터미널에서 실행하는 코딩 AI 프로그램입니다. 내 컴퓨터에서 실행되는 이 프로그램이 질문과 파일 내용을 서버로 보내면, 데이터센터의 모델이 다음에 할 일을 정해 돌려줍니다. 그 지시대로 파일을 읽고 명령을 실행하는 일은 다시 내 컴퓨터에서 일어납니다. 앤트로픽의 데이터 사용 안내도 Claude Code는 내 컴퓨터에서 실행되고 모델과 대화할 때 네트워크로 데이터를 보낸다고 설명합니다.

요청 하나가 오가는 과정

1. 1요청과 파일 전송내 컴퓨터의 Claude Code가
   질문과 읽은 파일을 서버로 보냄
2. 2모델 추론데이터센터의 모델이
   다음 행동을 정함
3. 3도구 실행내 컴퓨터에서 파일 수정,
   검색, 빌드, 테스트 실행
4. 4결과 전송과 반복실행 결과를 다시 서버로 보내고
   작업이 끝날 때까지 반복

어느 쪽에서 무슨 일이 일어나는지 나눠 보면 램이 왜 필요한지 보입니다. 아래 표의 "내 컴퓨터" 열에 체크가 있는 일은 모두 내 램을 씁니다.

코딩 AI 작업이 실제로 실행되는 곳

작업	데이터센터앤트로픽, OpenAI 서버	내 컴퓨터로컬 CLI, 앱, IDE
모델 추론과 답 생성	제공	제공하지 않음
대화 기록 보관과 화면 표시	제공하지 않음	제공
파일 읽기, 검색, 수정	제공하지 않음	제공
빌드, 테스트, 개발 서버 실행	제공하지 않음	제공
MCP 서버 실행	제공하지 않음	제공
브라우저 자동 조작	제공하지 않음	제공
클라우드 세션 작업	제공	제공하지 않음

MCP 서버는 AI가 외부 도구(브라우저, 깃허브, 문서 조회 등)를 쓸 수 있게 연결해 주는 작은 프로그램입니다. 내 컴퓨터에서 실행하는 방식의 MCP 서버는 Claude Code가 세션을 시작할 때 자식 프로세스로 함께 띄웁니다. 이 점이 여러 세션을 켤 때 램이 빠르게 차는 가장 큰 이유입니다.

세션 하나가 쓰는 램

세션 하나는 Claude Code 본체 하나로 끝나지 않습니다. 본체가 띄운 프로그램과 AI가 작업 중에 실행한 프로그램이 함께 돌아갑니다. 흔한 예는 네 가지입니다.

• MCP 서버: 브라우저를 조작하는 Playwright MCP, 깃허브 저장소를 다루는 GitHub MCP, 라이브러리 문서를 찾아 주는 문서 조회 MCP처럼 연결해 둔 도구마다 프로그램이 하나씩 뜹니다.
• 브라우저: Playwright MCP로 화면을 확인하라고 하면 크롬 계열 브라우저가 한 개 더 뜹니다. 브라우저는 그 자체로 메모리를 많이 쓰는 프로그램입니다.
• 언어 서버: 코드의 함수 정의, 타입 오류, 참조 위치를 알려 주는 프로그램입니다. VS Code가 코드에 빨간 밑줄을 긋는 것도 언어 서버 덕분이고, Claude Code도 언어 서버 플러그인을 설치하면 세션마다 띄웁니다.
• 개발 서버와 테스트: 웹 프로젝트에서 AI가 npm run dev로 미리보기 서버를 켜거나 테스트를 돌리면, 작업이 끝난 뒤에도 서버가 계속 켜져 있는 경우가 많습니다.

아래는 웹 프로젝트에서 이런 도구를 함께 쓰는 세션 하나를 가정한 예시입니다. 실제 크기는 연결한 도구와 프로젝트 크기에 따라 달라지지만, 본체보다 함께 뜬 프로그램의 합이 더 큰 경우가 흔합니다.

웹 프로젝트 세션 하나의 메모리 구성 예시(합계 3GB)

• Claude Code 본체0.5GB대화 기록, 화면 표시, 도구 호출 관리
• MCP 서버 3개0.3GBPlaywright, GitHub, 문서 조회
• Playwright가 띄운 브라우저0.7GB화면 확인을 시킬 때 뜸
• 타입스크립트 언어 서버1GB큰 프로젝트를 열수록 커짐
• AI가 켠 개발 서버0.5GB작업이 끝나도 남아 있는 경우가 많음

Claude Code의 공식 설치 안내는 램 4GB 이상을 요구합니다. 이 값은 본체를 실행하기 위한 조건이고, 세션을 여러 개 띄우거나 MCP 서버를 연결했을 때의 합계는 아닙니다.

본체도 오래 켜 두면 커질 수 있습니다. Claude Code 공식 저장소에는 세션 하나의 메모리가 100GB 넘게 늘었다는 사용자 보고가 올라와 있습니다. #4953은 120GB 이상으로 늘다가 메모리 부족으로 종료된 사례이고, #56960은 108GB까지 늘면서 스왑이 41.62GB 쌓인 사례입니다. 오래 켠 세션 하나가 유난히 크다면 종료하고 다시 시작하는 편이 확실합니다.

여러 세션을 켜면 곱해지는 메모리

세션을 하나 더 켜면 본체만 하나 더 뜨는 것이 아닙니다. 그 세션이 쓰는 MCP 서버, 브라우저, 언어 서버, 개발 서버도 새로 하나씩 뜹니다. 앞의 예시처럼 세션 하나가 3GB이고, 운영체제와 브라우저, 메신저 같은 상시 앱이 6GB를 쓰는 램 16GB 노트북을 가정해 보겠습니다.

램 16GB 노트북에서 세션을 늘릴 때(예시)

• 상시 앱만6GB
• 세션 1개9GB
• 세션 2개12GB
• 세션 3개15GB램이 거의 참
• 세션 4개18GB램보다 2GB 많음. 압축과 스왑이 늘어남

세 번째 세션까지는 버티다가 네 번째 세션에서 갑자기 느려지는 경험은 이 계산으로 설명됩니다. 세션 수가 늘수록 필요한 메모리가 계단처럼 올라가고, 램 용량을 넘는 순간부터 스왑이 생깁니다.

MCP 서버가 세션마다 따로 뜨는 것은 연결 방식 때문입니다. MCP 서버는 세션이 직접 띄워 표준 입출력(stdio)으로 대화하는 방식과, 이미 실행 중인 서버에 주소로 접속하는 HTTP 방식이 있습니다. MCP 공식 사양에 따르면 앞의 방식은 클라이언트가 서버를 자식 프로세스로 띄웁니다. 그래서 세션 수만큼 프로그램이 생깁니다. 뒤의 방식은 서버 하나를 여러 세션이 나눠 쓰고, 회사가 운영하는 원격 주소에 접속하면 내 컴퓨터에는 아무것도 뜨지 않습니다.

MCP 서버 연결 방식에 따른 차이

항목	stdio 방식세션이 직접 띄움	HTTP 방식주소로 접속
세션 4개, MCP 3개일 때 내 컴퓨터의 서버 수	12개	0~3개
세션을 끄면	함께 종료	계속 실행
설정 예	command, args	url

본체 크기도 도구마다 다릅니다. Codex CLI는 Rust라는 프로그래밍 언어로 만든 실행 파일이라 본체가 가벼운 편입니다. 다만 세션 전체로 보면 본체보다 함께 뜨는 MCP 서버, 브라우저, 언어 서버의 영향이 더 큰 경우가 많습니다.

Orca와 VS Code 같은 데스크톱 앱도 따로 메모리를 씁니다. 두 앱은 일렉트론(Electron)이라는 방식으로 만든 앱으로, 크롬과 같은 엔진으로 화면을 그리며 메인, 화면 표시 등 여러 프로세스를 나눠 실행합니다. 터미널 창을 여러 개 열고 긴 출력을 쌓아 둘수록 화면을 그리는 프로세스가 커집니다. VS Code에서는 확장 프로그램이 확장 호스트(Extension Host)라는 별도 프로세스에서 돌기 때문에 Claude Code나 Codex 확장도 이 프로세스의 메모리를 씁니다.

램이 부족할 때 운영체제가 하는 일

램이 모자란다고 바로 스왑만 쓰는 것은 아닙니다. macOS는 다시 읽을 수 있는 파일 캐시를 내보내고, 당장 안 쓰는 데이터를 램 안에서 압축하고, SSD의 스왑 파일로도 옮깁니다. 세 방법은 데이터를 다시 꺼내 쓸 때 걸리는 시간이 다릅니다.

macOS가 램 공간을 만드는 세 가지 방법

방법	데이터가 가는 곳	다시 쓸 때
파일 캐시 내보내기	램에서 지움 (원본 파일은 SSD에 있음)	파일을 다시 읽음
메모리 압축	램 안에 작게 보관	압축을 풀어서 씀
스왑	SSD의 스왑 파일	SSD에서 읽어 옴 (가장 느림)

스왑으로 나간 데이터는 다시 쓸 때 SSD에서 읽어 와야 합니다. 그래서 한동안 쓰지 않던 세션으로 돌아가 질문을 보내면 첫 반응이 늦습니다. 그 세션의 본체와 함께 뜬 프로그램의 데이터가 압축되거나 스왑으로 나가 있다가 다시 램으로 돌아오는 시간이 필요하기 때문입니다.

운영체제마다 이름과 확인 위치는 다르지만 원리는 같습니다.

운영체제별 스왑 이름과 확인 위치

항목	macOS	Windows	Linux
스왑을 부르는 이름	스왑 파일	페이징 파일	스왑
파일 위치	/System/Volumes/VM	pagefile.sys	스왑 파티션이나 스왑 파일
쉽게 확인하는 곳	활성 상태 보기 메모리 탭	작업 관리자 성능, 메모리	free -h 명령

램과 SSD의 속도 차이

스왑이 느린 이유는 SSD가 램보다 훨씬 느리기 때문입니다. 아래는 초당 옮길 수 있는 데이터의 양(대역폭)을 제조사 사양으로 비교한 것입니다.

초당 옮길 수 있는 데이터 양(대역폭)

• M4 Pro 통합 메모리273GB/s애플 공식 사양
• M4 통합 메모리120GB/s애플 공식 사양
• 삼성 990 PRO SSD7.45GB/s제조사 사양의 순차 읽기 최대치

애플 실리콘 맥의 통합 메모리는 CPU와 GPU가 같은 메모리를 나눠 쓰는 구조입니다. 화면을 그리는 GPU, 브라우저, 동영상 재생도 같은 램 안에서 공간을 나눕니다. 그래서 맥에서 "그래픽 메모리는 따로 있겠지"라고 생각하고 계산하면 실제 여유보다 넉넉하게 보입니다.

저장 용량과 램의 관계

저장 용량이 1TB여도 램이 늘어나지는 않습니다. 저장 용량은 스왑 파일을 둘 수 있는 공간과 관련이 있을 뿐입니다.

저장 용량과 램을 둘러싼 흔한 오해

• SSD 용량이 크면 램이 부족해도 괜찮다

  SSD 용량은 스왑 파일을 둘 공간을 줄 뿐, 스왑의 느림은 그대로입니다. 램 부족은 램 용량으로만 해결됩니다.

• 스왑이 생기면 컴퓨터가 고장 난다

  스왑은 운영체제의 정상 기능입니다. 스왑 숫자가 있어도 메모리 압력이 초록이면 체감 문제는 적습니다.

• 저장 공간이 거의 차도 램만 넉넉하면 된다

  스왑 파일도 저장 장치의 빈 공간에 만들어집니다. 빈 공간이 부족하면 데이터를 옮겨 둘 곳도 줄어듭니다.

스왑은 SSD에 쓰기를 반복합니다. SSD에는 제조사가 보증하는 총 쓰기량(TBW, 테라바이트 단위)이 정해져 있으므로, 스왑이 많은 상태가 계속되면 그만큼 쓰기 양도 늘어납니다.

스왑이 답변 성능을 떨어뜨릴까요?

스왑이 생기면 Claude Code의 답이 덜 똑똑해진다는 말을 종종 듣습니다. 사실과 다른 부분과 맞는 부분이 섞여 있습니다.

스왑과 답변 성능 팩트체크

• 스왑이 생기면 클로드나 GPT 모델의 답 품질이 떨어진다

  원격 모델은 데이터센터의 GPU와 메모리에서 답을 만듭니다. 같은 모델에 같은 내용을 보내면 내 컴퓨터의 스왑과 상관없이 같은 조건에서 답을 만듭니다.

• 램을 늘리면 컨텍스트 창이 커져 긴 작업을 더 잘한다

  컨텍스트 창은 모델이 한 번에 읽을 수 있는 토큰 한도로, 내 램을 늘려도 커지지 않습니다. 대화 자동 압축(compact)이 일어나는 시점도 이 토큰 한도가 정합니다.

• 스왑은 속도만 늦출 뿐 결과에는 전혀 영향이 없다

  메모리가 바닥나 테스트나 MCP 서버 같은 프로세스가 종료되면 AI는 실패한 실행 결과를 받고 그 결과를 근거로 다음 행동을 정합니다. 이때 작업 결과가 달라질 수 있습니다.

긴 세션에서 답이 점점 엉뚱해지는 느낌을 받는다면 램보다 대화 길이를 먼저 의심합니다. 앤트로픽의 컨텍스트 창 안내는 대화가 길어질수록 앞쪽 내용을 정확히 다루기 어려워질 수 있다고 설명합니다. 이 경우에는 새 세션을 열거나 /compact로 대화를 요약하는 편이 효과가 있습니다.

스왑이 생겼을 때 실제로 느려지는 곳을 나눠 보면 다음과 같습니다.

스왑이 많을 때 느려지는 것과 그대로인 것

항목	스왑이 많을 때램 부족 상태
모델의 생각과 답의 내용	그대로
서버에서 답이 오는 속도	그대로
입력한 글자와 답이 화면에 찍히는 속도	느려짐
파일 검색, 빌드, 테스트 시간	느려짐
오래 쉬던 세션의 첫 응답	느려짐
프로세스가 강제로 종료될 위험	커짐

로컬 LLM은 이야기가 다릅니다. 로컬 LLM은 Ollama나 LM Studio처럼 모델 자체를 내 컴퓨터에서 실행하는 방식입니다. 이때는 모델의 가중치(학습으로 정해진 수십억 개의 숫자)가 램에 올라가야 하므로, 램이 모자라 일부가 SSD를 오가면 답을 만드는 속도 자체가 떨어집니다.

램이 부족할 때 원격 모델과 로컬 모델의 차이

항목	원격 모델Claude Code, Codex	로컬 모델Ollama, LM Studio
모델이 올라가는 메모리	데이터센터	내 램
답 생성 속도	그대로	느려짐
답 품질	그대로	같은 모델이면 그대로
램에 맞추려고 할 수 있는 일	세션과 도구 정리	더 작은 모델이나 더 강한 양자화

양자화는 모델의 숫자를 더 낮은 정밀도로 줄여 메모리 부담을 낮추는 방법입니다. 자세한 내용은 로컬 AI 하드웨어 기초에서 다룹니다.

잠깐 확인Codex 세션 하나만 켰는데 스왑이 많습니다. 원인을 찾을 때 가장 먼저 볼 곳은 어디일까요?

A활성 상태 보기에서 메모리를 많이 쓰는 프로그램BCodex가 쓰는 모델의 이름과 버전C대화의 컨텍스트 창 사용량

내 컴퓨터의 메모리 상태 확인 방법

맥에서는 활성 상태 보기에서 바로 확인할 수 있습니다. 애플의 메모리 사용량 안내에 나오는 항목을 아래 순서로 봅니다.

활성 상태 보기에서 메모리 확인하기

1. 1앱 열기Spotlight에서
   활성 상태 보기 검색
2. 2메모리 탭위쪽 탭에서
   메모리 선택
3. 3메모리 압력 색아래쪽 그래프가
   초록, 노랑, 빨강 중 무엇인지
4. 4큰 프로그램 찾기메모리 열을 눌러
   큰 순서로 정렬

정렬한 목록에 node, npm, python 같은 이름이나 브라우저 이름이 여러 개 보이면 세션들이 띄운 MCP 서버, 개발 서버, 브라우저일 가능성이 큽니다. 터미널에서는 sysctl vm.swapusage를 입력하면 used 항목에 지금 스왑 파일에 들어 있는 양이 나옵니다.

Windows에서는 작업 관리자의 성능 탭에서 메모리를 누르면 사용 중, 압축됨, 커밋됨 값이 나옵니다. 커밋 한도는 램과 페이징 파일을 합친 크기입니다. 커밋됨 값이 램 용량을 크게 넘으면 페이징 파일을 많이 쓰는 상태입니다.

램을 아끼며 여러 세션을 쓰는 방법

세션 수 자체보다 세션마다 함께 뜨는 프로그램이 메모리를 좌우합니다. 아래 순서로 정리하면 효과가 큽니다.

1. 쓰지 않는 세션은 종료합니다. 터미널 창만 닫아 두지 말고 Claude Code에서는 /exit, Codex에서는 /quit으로 끝냅니다. 세션을 끝내면 그 세션이 stdio 방식으로 띄운 MCP 서버도 함께 종료됩니다. 이어서 할 작업이면 나중에 claude --resume으로 대화를 다시 불러올 수 있습니다.
2. AI가 켠 개발 서버와 브라우저를 확인합니다. 작업이 끝나면 "켜 둔 개발 서버와 브라우저를 모두 종료해 줘"라고 요청합니다. 세션 여러 개가 각자 개발 서버를 켜 두면 같은 프로젝트의 서버가 여러 개 돌기도 합니다.
3. 오래 켠 세션은 정리합니다. Claude Code의 문제 해결 안내는 /compact를 실행하면 메모리도 줄어든다고 설명합니다. /compact 뒤에도 메모리가 큰 세션은 종료하고 새로 시작합니다.
4. MCP 서버는 필요한 폴더에만 연결합니다. Claude Code와 Codex에서 /mcp를 입력하면 지금 연결된 MCP 서버 목록이 나옵니다. 모든 프로젝트에 적용되는 사용자 설정에 넣은 서버는 모든 세션에서 뜨므로, 특정 프로젝트에서만 쓰는 서버는 그 프로젝트의 설정으로 옮깁니다. 원격 주소를 제공하는 서버는 주소로 연결하면 내 컴퓨터에 프로세스가 생기지 않습니다.
5. 코드 작업이 없는 폴더에서는 언어 서버를 끕니다. 언어 서버 플러그인을 설치했다면 문서 작업이나 영상 작업 폴더의 .claude/settings.json에서 그 플러그인을 꺼 둡니다. 그 폴더에서 연 세션은 처음부터 언어 서버를 띄우지 않습니다.
6. 큰 작업은 클라우드 세션으로 보냅니다. 빌드와 테스트가 무거운 작업은 Claude Code on the web이나 Codex 클라우드 작업으로 실행하면 회사 서버의 환경에서 돌아갑니다. 내 컴퓨터는 결과를 확인하는 데만 씁니다.
7. 브라우저와 다른 앱도 같은 램을 씁니다. 세션을 늘리기 전에 크롬 탭과 상시 실행 앱부터 정리합니다.

동시에 몇 개까지 켤 수 있는지는 세션 하나의 크기로 계산합니다. 활성 상태 보기에서 세션 하나를 켜기 전과 후의 메모리 사용량 차이를 보면 세션 하나의 크기를 알 수 있습니다. 그다음 상시 앱의 메모리 + 세션 하나의 크기 × 세션 수가 램 용량을 넘지 않게 맞춥니다. 앞의 예시라면 6GB + 3GB × 3 = 15GB이므로 램 16GB에서는 세 개가 한계입니다.

마무리로 짚어 볼 것

1. 모델은 데이터센터에서 돌지만 파일 작업, 명령 실행, MCP 서버, 화면 표시는 세션마다 내 램을 씁니다.
2. 세션을 하나 늘리면 그 세션의 MCP 서버, 브라우저, 언어 서버, 개발 서버도 하나씩 늘어납니다.
3. 스왑은 답의 품질이 아니라 속도와 도구 실행의 안정성에 영향을 줍니다.

직접 해 보기

• 활성 상태 보기 메모리 탭에서 메모리 압력 색과 스왑 사용 숫자 확인하기
• 메모리 열을 큰 순서로 정렬해 상위 다섯 개 프로그램 이름 적기
• Claude Code에서 /mcp를 입력해 지금 연결된 MCP 서버 수 확인하기
• 쓰지 않는 세션 하나를 /exit으로 종료한 뒤 스왑 숫자 다시 보기

여러 코딩 AI를 함께 다루는 화면 구성은 Orca 시작하기에서, 내 컴퓨터 밖에서 작업을 실행하는 방법은 클로드 코드 클라우드 세션 크레딧에서 이어서 볼 수 있습니다.