Codex CLI 실측:
8GB·16GB·32GB에서 어떤 프로젝트가 끝나는가

2026년 9월 9일 기준으로도 Codex 공식 설치 문서는 macOS 12+ / Ubuntu 20.04+(Windows는 WSL2), 메모리 최소 4GB, 권장 8GB를 적고 있습니다. CLI 자체는 이미 Rust 네이티브 바이너리라 유휴 시 보통 수백 MB입니다. Claude Code, Cursor와 마찬가지로 비싼 것은 「Agent 프로세스」가 아니라 Agent가 손을 댈 때마다 깨우는 로컬 툴체인입니다. 다른 Agent의 구매 등급이 궁금하면 Claude Code 16GB / 24GB / 64GB 실측을 대조하세요. 사설 PR 리뷰 서비스가 필요하면 다른 글입니다: OpenCode Review 4GB / 8GB / 16GB 선정. 이 글이 답하는 것은 한 가지입니다. Codex CLI가 8 / 16 / 32GB에서 어떤 종류의 프로젝트를 끝까지 끝낼 수 있는가.

공식 4GB / 8GB는 시작만 보장한다

「권장 8GB」를 「8GB면 어떤 프로젝트든 쓸 수 있다」로 읽는 것이 가장 흔한 오해입니다. 공식 표가 푸는 문제는 OS + Node/런타임 의존성 + Codex 프로세스 자체가 살아남느냐입니다. 아래 실제 작업은 포함되지 않습니다.

• 저장소에 node_modules, DerivedData, .next 또는 수만 개 소스가 있으면 Agent는 경로로 읽고 도구로 검색합니다;
• 「실패한 CI를 고쳐 달라」고 하면 npm test, pytest, xcodebuild를 실행합니다;
• Playwright / Chrome DevTools / XcodeBuild MCP를 켜 두면 세션마다 Node 프로세스 트리가 한 그루 더 뜹니다;
• 브라우저, IDE, 로컬 dev server도 동시에 열려 있습니다——이것들은 「최소 4GB」에 들어 있지 않습니다.

추론은 OpenAI 쪽에서 일어나므로 GPU를 키워도 도움이 되지 않습니다. 로컬 메모리가 결정하는 것은 툴체인이 서 있을 자리가 있는가입니다. 같은 공식 문구가 스크립트 저장소와 iOS 모노리스에서 완전히 반대 체감이 되는 이유이기도 합니다.

메모리 청구서: CLI, 인덱스, 자식 프로세스, MCP

대화형 세션의 상주 메모리는 네 장의 청구서로 나눌 수 있습니다. 나눠 봐야 메모리를 바로 늘리기 전에 어디를 자를지 보입니다.

커뮤니티에는 이미 무시하기 어려운 신호가 있습니다. 약 1.2GB 로컬 저장소에서 Codex 네이티브 런타임 익명 RSS가 18GB, 심지어 29GB까지 올라 cgroup에 죽은 사례가 있습니다(openai/codex#21233). 다른 계열은 MCP 수명주기입니다. 세션을 일시 정지하거나 자식 Agent가 끝난 뒤에도 npx / Playwright / xcodebuildmcp 프로세스 트리가 남습니다. 16GB 머신은 고아 프로세스에 스왑으로 끌려갑니다. 그래서 「32GB면 안전하다」도 성립하지 않습니다——반응할 시간이 길어질 뿐입니다.

이것이 「몇 GB 컴퓨터를 살까」류 글과의 차이입니다. 칩 코드네임으로 완제품을 추천하지 않고, 프로젝트 툴체인으로 장부를 잡습니다.

실측 방법: 3단계 상한, 6개 프로젝트

같은 Codex CLI(ChatGPT 로그인, 기본 코딩 모델)로 고정된 6개 작업을 각각 8 / 16 / 32 GiB 가용 메모리에 캡을 걸어 돌렸습니다. Linux는 systemd-run --scope -p MemoryMax=, macOS는 활성 상태 보기의 메모리 압력과 스왑을 대조했습니다. 지표는 네 가지뿐입니다. Codex + 자식 프로세스 피크 RSS, 격한 스왑이 시작됐는지, 작업을 끝냈는지, 벽시계 시간.

6개 프로젝트는 개발자가 실제로 Agent에게 던지는 일을 고의로 골랐습니다. Hello World가 아닙니다.

1. P0 빈 세션: codex를 콜드 스타트하고 저장소 구조를 한 번 묻습니다. 테스트는 돌리지 않습니다.
2. P1 소형 Python CLI: 약 180개 소스 파일. 파싱 버그를 고치고 pytest -q를 돌립니다.
3. P2 중형 Next.js: 약 800개 소스 파일. API 라우트를 하나 추가하고 npm test(E2E 브라우저 없음).
4. P3 P2 + Docker Compose: Postgres + 앱 컨테이너. Codex가 마이그레이션을 고치고 스택을 재시작하게 합니다.
5. P4 iOS App: 중형 UIKit 프로젝트. 화면 한 곳을 고치고 xcodebuild를 실행합니다(시뮬레이터 풀세트는 띄우지 않음).
6. P5 P2 + Playwright MCP: 브라우저 MCP를 열고 페이지를 보며 컴포넌트를 고치게 합니다.

숫자는 피크 구간이지 계측기 교정값이 아닙니다. 환경에는 OS와 얇은 터미널을 남겼고, Chrome 탭 40개는 동시에 열지 않았습니다. Slack, Figma, dev server 세 개가 아직 올라가 있다면 아래 표의 각 등급을 한 단계 위로 잡으세요.

등급별 결과: 성공, 멈춤, 강제 종료

이 표에서는 두 가지를 잡으세요. 첫째, P2는 이미 8GB 천장에 가깝습니다——Codex가 8GB를 먹은 것이 아니라 node 테스트 프로세스와 파일 읽기가 남은 여유를 비웁니다. 둘째, P4 / P5 실패의 대부분은 「모델이 Swift를 못 쓰거나 페이지를 못 클릭해서」가 아닙니다. 컴파일러와 브라우저가 먼저 머신을 짓누르고 Agent가 마지막 한 걸음에 닿지 못합니다.

8GB에서 돌릴 수 있는 프로젝트

8GB는 공식 「권장」 등급이자, 슬림 노트북, 입문 VPS, 구형 통합 메모리 Mac의 현실이기도 합니다. 끝낼 수 있는 프로젝트의 특징은 분명합니다. 소스가 적고, 컨테이너가 없고, IDE 시뮬레이터가 없고, 테스트가 프로세스 안에서 끝납니다.

8GB에 맡겨도 되는 프로젝트

• 스크립트, 크롤러, 작은 도구, 단일 파일 리팩터;
• 문서 사이트(Astro / VitePress / Docusaurus)의 문구와 설정 수정;
• 소형 Flask / Express / FastAPI. 테스트는 pytest 또는 소량 Node 단위 테스트. 브라우저는 띄우지 않음;
• codex exec로 일회성 패치: 파일 몇 개를 읽고 고친 뒤 종료. 대화형 TUI는 걸지 않음;
• 코드 리뷰 주석, 커밋 메시지, 오류 로그를 패치 초안으로 번역.

8GB에서 처음부터 포기할 프로젝트

• Docker Desktop / Compose가 필요한 풀스택;
• Xcode, iOS 시뮬레이터, Android 에뮬레이터;
• Playwright, Cypress, Chrome DevTools MCP;
• pnpm / npm 대형 모노레포 전체 테스트;
• 「VS Code와 탭 열몇 개를 연 채로 Codex에게 저장소를 고치게」——시스템이 먼저 페이징을 시작하고, Agent가 느려진 줄 알면 디스크가 메모리 일을 대신하고 있는 것입니다.

8GB에서 가장 효과적인 쓰임은 「큰 저장소를 참으며 돌리는」 것이 아니라 큰 저장소를 작은 작업으로 쪼개는 것입니다. 하위 디렉터리만 열고, MCP를 끄고, codex exec로 끝내고 떠납니다. 대화형 긴 세션은 8GB의 천적입니다. 세션이 길수록 내부 상태와 자식 프로세스가 남기 쉽습니다.

16GB에서 돌릴 수 있는 프로젝트

16GB는 우리가 권하는 일상 Web 기본 등급입니다. P2 같은 「중형 프론트 / 풀스택 + 단위 테스트」가 이 등급에서야 스왑과 시간을 다투지 않습니다. Nuvcloud 클라우드 Mac mini 입문 사양도 16GB 통합 메모리로 이 등급에 맞춰 있습니다. 본기 슬림 노트북이 부족하면 Codex 세션을 툴체인째 전용 노드로 옮기는 편이 8GB 노트북에서 버티는 것보다 낫습니다.

16GB가 편한 프로젝트

• 중형 Next.js / Nuxt / Rails / Django. 단위 테스트 + 로컬 dev server;
• 데이터베이스 컨테이너 하나, 또는 매우 얇은 docker-compose(Redis + Elasticsearch + 브라우저는 겹치지 않음);
• VS Code / Zed + 터미널 Codex. 시스템에 2–3GB를 남김;
• 중형 Python 데이터 스크립트(pandas 중형 표. 로컬 대형 모델은 올리지 않음);
• 짧은 시간 MCP 하나를 켬(예: Git 또는 문서 검색). 쓰면 바로 끔.

16GB에서 가능하지만 규칙을 지켜야 하는 프로젝트

P3는 16GB에서 「끝낼 수 있습니다」. 전제는 메모리 압력이 노랑인 것을 받아들이고, 두 번째 컨테이너 세트를 병렬하지 않는 것입니다. iOS 소규모 수정에서 xcodebuild 단일 타깃만 돌리면 가끔 밀어 넣을 수 있습니다. 시뮬레이터를 여는 순간 「스왑 + 멈춤」 구간으로 돌아갑니다. Playwright MCP의 짧은 세션(십여 분)은 가능합니다. 한 번 Ctrl+Z로 세션을 멈추거나 연속 spawn_agent를 하면 고아 Node가 16GB를 뚫습니다. 커뮤니티는 16GB + 8GB zram 머신에서 기기를 통째로 못 쓰게 되는 재현을 이미 가지고 있습니다.

한 줄로: 16GB는 「메인 프로젝트 하나 + 테스트 한 세트」용입니다. 「메인 + 컨테이너 풀세트 + 브라우저 Agent + IDE 인덱스」용이 아닙니다.

32GB가 필요한 프로젝트

32GB는 과시용 사양이 아니라 아래 프로젝트의 입장권입니다. 공통점은 Codex는 청구서의 일부일 뿐이고, 컴파일러와 런타임이 본전이라는 점입니다.

• 모노리포 / 멀티패키지 저장소: 한 번의 npm test나 turbo run test가 Node worker를 한 줄 띄웁니다;
• iOS / macOS 프로젝트: xcodebuild, DerivedData, 코드 인덱스. 피크는 쉽게 십수 GB. 화면을 보며 시뮬레이터까지 열면 32GB로 계획하세요;
• Codex + Docker 다서비스: 앱, DB, 메시지 큐가 동시에 있고 Agent가 마이그레이션을 고치고 스택을 재시작합니다;
• 브라우저 MCP / E2E: Playwright나 Chrome DevTools가 프로세스 트리를 한 그루 더 복제합니다. 짧은 세션은 32GB로 충분하고, 긴 세션은 그래도 손으로 회수해야 합니다;
• 다중 세션 병렬: Codex 두 개가 저장소 두 개를 보거나, 대화 세션 하나에 codex exec 배치를 더합니다.

32GB도 알려진 무한 증가를 막지 못합니다. 작업 공간 자체가 1GB급이면 Codex에 메모리 상한을 거세요. 작업이 실패하는 편이 데스크톱까지 얼어붙는 것보다 낫습니다. Linux에서는 이렇게 한 겹 감쌀 수 있습니다.

# 32GB 머신에서 Codex에 20G를 남기고, 나머지는 시스템 / IDE / 컨테이너에
systemd-run --user --scope \
  --same-dir \
  --unit="codex-$(date +%H%M%S)" \
  -p MemoryMax=20G \
  -p MemorySwapMax=2G \
  -p CPUQuota=300% \
  codex

macOS에는 그만큼 쓰기 쉬운 사용자 공간 cgroup이 없습니다. 현실적인 방법은 무거운 일을 전용 클라우드 Mac으로 보내는 것입니다. 본기는 편집기와 열람만. Nuvcloud가 현재 공개하는 베어메탈 등급은 16GB와 24GB입니다. 24GB는 대부분의 P3를 덮습니다. P4에서 시뮬레이터까지 동시에 열면 Xcode와 Codex를 상시 켜 둔 원격 머신에 두고, 16GB 노트북이 양쪽을 겸하지 않게 하세요. Agent 노드를 따로 과금하면 GitHub Actions macOS Runner의 호스티드와 셀프호스트 비용과도 대조하기 쉽습니다. CI는 일회성 runner, 대화형 Codex는 일 단위 임대 Mac mini. 두 장부를 포화 상태의 노트북 한 대에 섞지 마세요.

저장소와 툴체인으로 등급 고르기

먼저 「16을 살지 32를 살지」 묻지 마세요. 먼저 물을 것은 저장소가 무엇을 깨우느냐입니다. 아래 표는 결정 순서입니다. 위에서 아래로, 처음 걸리는 행에서 멈추세요.

자주 놓치는 변수가 하나 더 있습니다. 디스크와 파일 디스크립터입니다. MCP가 누수하면 macOS 기본 소프트 리밋 256개에서 먼저 Too many open files가 납니다. 「Codex가 고장 난」 것처럼 보이지만 파이프와 고아 프로세스가 한도를 먹은 것입니다. 메모리가 충분한지 보기 전에 ulimit -n과 ps 안의 npx / mcp 개수를 보세요.

작은 메모리 머신에서 살아남는 설정

당분간 8GB, 또는 빠듯한 16GB에서만 일해야 한다면 먼저 행동을 바꾸고 그다음에 증설을 이야기하세요. 아래 목록은 「이득 / 고통」 순입니다.

1. 기본은 MCP 제로. 브라우저나 Xcode 도구가 필요할 때만 켜고, 끝나면 ~/.codex/config.toml에서 빼세요. xcodebuildmcp, Playwright를 전역 기본값에 쓰지 마세요.
2. 대화 세션은 짧게, 배치는 codex exec. 일회성 패치에 TUI는 필요 없습니다. 배치는 UI 상태를 한 겹 덜 먹습니다.
3. Codex를 Ctrl+Z로 멈추지 마세요. 멈춘 뒤에도 MCP 자식이 계속 사는 경우가 많습니다. 종료하거나 tmux에서 detach하세요.
4. 작업 디렉터리를 좁히세요. 4만 파일 모노레포 루트가 아니라 서브패키지에서 시작하세요. dist, coverage, .next를 읽기 범위에서 빼세요.
5. 도구 출력을 제한하세요. 커뮤니티 관행은 tool_output_token_limit에 상한을 걸어, 로그 한 번 읽기로 컨텍스트와 로컬 버퍼를 동시에 터뜨리지 않는 것입니다.
6. 「느리다」만 보지 말고 프로세스를 보세요. ps aux | egrep 'codex|npx|mcp|node'에 MCP 트리가 열몇 세트면 고아를 죽인 뒤 이어가세요.

ps aux | egrep 'codex|npx|playwright|mcp-server|xcodebuildmcp' | grep -v egrep
# 세션이 끝난 뒤에도 남아 있으면 회수한 다음 다음 라운드를 여세요
# macOS는 활성 상태 보기에서 「메모리」로 정렬하고 node와 Codex를 보세요

이 단계들은 P4를 8GB 친화 프로젝트로 바꾸지 못합니다. 다만 P1 / P2를 「켤 수 있음」에서 「끝낼 수 있음」으로 바꿉니다. 메모리 증설이 푸는 것은 피크, 설정 변경이 푸는 것은 누수와 동시성입니다.

Codex를 클라우드 Mac으로 옮길 때

아래 중 아무거나 두 가지가 맞으면 Codex와 무거운 툴체인을 노트북에서 분리하세요.

• 본기는 8GB 또는 16GB인데 일은 이미 P3 / P4 / P5;
• 출퇴근, Windows 호스트, 공유 PC에서 같은 세션을 이어가야 함;
• Xcode 버전을 본기 일상 개발과 격리해야 함(SDK 주, 베타 주에 특히 뚜렷함);
• 누군가 MCP를 전역 기본으로 넣어 공유 머신이 오후에 고아로 가득 참.

클라우드 Mac mini의 가치는 「더 비싼 Codex」가 아닙니다. 전용 통합 메모리, 네이티브 Unix 툴체인, 일 단위로 버릴 수 있는 더러운 환경입니다. 본기 8GB 노트북은 메일과 문서를 쓰고, 16GB 또는 24GB 원격 노드가 Codex, 테스트, Xcode를 전담합니다. Apple Silicon은 대기 전력이 낮아 밤새 작업을 걸어 두기 좋습니다. SSH / VNC는 이미 페이징 중인 노트북에서 돌아가는 원을 보는 것보다 정직합니다.