OpenAI Codex는 2026년 4월까지 주간 활성 사용자(Weekly Active Users) 300만 명을 돌파했으며, 이는 전월 대비 70% 성장, 1월 이후 5배 성장한 수치입니다. 제품은 4월 16일 업데이트 이후 이제 메모리(Memory) 기능을 갖추게 되었습니다. 하지만 현재 제공되는 메모리는 프로젝트 범위로 제한되어 있고(project-scoped), 클라우드 전용이며, OpenAI 내부에 갇혀 있습니다. 세션이 유지되고, 기기를 넘나들며 따라다니며, 다른 AI 도구들이 사용하는 것과 동일한 메모리에 연결되는 Codex 메모리를 제공하는 문제를 실제로 해결하는 세 가지 접근 방식이 있습니다: 프로젝트 파일이 포함된 내장 메모리(built-in memories), MCP 메모리 서버(MCP memory server), 또는 민감한 코드를 위해 OpenAI 메모리를 유지하고 그 외의 모든 것을 위해 MCP 서버를 사용하는 하이브리드 설정(hybrid setup)입니다. MCP 경로는 설정하는 데 약 30초가 소요되며, Claude, ChatGPT, Cursor 및 동일한 메모리 저장소를 사용하는 다른 7개의 클라이언트와 함께 작동합니다. Codex 사용자 수가 주간 300만 명에 도달했을 때, 여러분이 보고 있는 것은 OpenAI가 Anthropic이 18개월 전에 출시했던 생산성 스토리를 Anthropic이 결코 도달하지 못한 규모로 출시하고 있는 모습입니다. Codex Web, macOS 및 Windows용 Codex Desktop, ChatGPT iOS 내의 Codex 앱, Codex CLI, VS Code 확장 프로그램. 다섯 가지 인터페이스, 하나의 계정, 그리고 그 모든 것 뒤에 있는 동일한 모델입니다. 4월 16일, OpenAI는 Computer Use, 인앱 브라우저, 이미지 생성 및 90개 이상의 플러그인 마켓플레이스와 함께 데스크톱 앱에 지속성 메모리(persistent memory)를 추가했습니다. 만약 공지사항을 읽었다면

만약 Codex Web에서 Codex Desktop으로 전환한다면 메모리가 따라와야 하지만, 실제로 사용자들은 여전히 인터페이스(surfaces) 간의 괴리(drift)를 보고하고 있습니다. 이는 ChatGPT가 소비자용 메모리(memory) 기능에 사용하는 것과 동일한 모델입니다. 그 기능 자체로는 훌륭합니다. 하지만 대부분의 개발자가 Codex가 자신을 기억하느냐고 물을 때 의미하는 바는 아닙니다. 개발자들이 실제로 원하는 것은 세 가지 계층이 있습니다: 첫 번째는 세션 메모리 (session memory)입니다. 단일 대화 내에서 모델이 세 차례 전의 동작을 기억할 수 있는가 하는 문제입니다. 이는 2023년에는 문제였으나, 지금은 해결되었습니다. 두 번째는 프로젝트 메모리 (project memory)입니다. 동일한 작업에 대한 여러 세션에 걸쳐, 모델이 코드베이스의 컨벤션(conventions), 팀 구성원, 그리고 당신이 지난주에 내린 결정들을 회상할 수 있는가 하는 문제입니다. Codex의 내장 메모리는 작업 전체가 Codex 내부에 존재하는 프로젝트의 경우 이 문제를 해결합니다. 하지만 작업의 절반이 Claude Code나 Cursor에서 이루어진다면 이 문제는 해결되지 않습니다. 세 번째는 운영자 메모리 (operator memory)입니다. 당신이 사용하는 모든 AI 도구에 걸쳐, 모델이 당신이 누구인지, 무엇을 만드는지, 고객이 무엇을 중요하게 여기는지, 그리고 반복하고 싶지 않은 실수가 무엇인지를 기억할 수 있는가 하는 문제입니다. 이는 모델 제공업체의 누구도 해결하고 싶어 하지 않는 계층인데, 그들의 인센티브는 당신을 자신들의 스택(stack)에 가두는 것에 있기 때문입니다. 아래의 세 가지 솔루션은 두 번째와 세 번째 계층을 다룹니다. 상황에 맞는 것을 사용하세요.

솔루션 1: 프로젝트 파일을 활용한 Codex의 내장 메모리
Codex에는 두 가지 기억 방식이 있습니다. Memories 기능은 사용자별 선호도(preferences)를 저장합니다. 프로젝트 수준의 설정 파일(config files)은 팀이 공유하는 컨텍스트(context)를 저장합니다. Codex 내부에 완전히 존재하는 코드의 경우, 이 둘을 합치면 충분합니다. 설정 방법은 간단합니다. 모든 Codex 프로젝트 내의 레포지토리(repo) 루트에 AGENTS.md 파일을 생성하세요. Codex는 모든 작업 시 이 파일을 읽습니다. 이는 Anthropic이 확립한 CLAUDE.md 패턴과 동일한 방식입니다. 일반적인 항목: 기술 스택(tech stack), 코딩 컨벤션(coding conventions), 배포 명령(deploy commands), PR 규칙, 명명 규칙(naming rules), "X를 절대 하지 마시오"와 같은 경고 사항 등입니다.

AGENTS.md

Stack

Next.js 15, TypeScript strict, Prisma, Postgres on port 5433.

컨벤션 (Conventions)

• 가능한 경우 API 라우트 (API routes) 대신 서버 액션 (Server Actions) 사용
• Tailwind 유틸리티 우선 (utility-first) 방식 사용, CSS 모듈 (CSS modules) 사용 금지
• 단위 테스트 (unit test)는 Vitest로, 엔드 투 엔드 (e2e) 테스트는 Playwright로 수행

절대 금지 사항 (Never)

• 어떤 브랜치에서도 prisma db push --force-reset 실행 금지
• 수정 전 읽기 (read-before-edit) 훅 (hook) 건너뛰기 금지
• pnpm typecheck 없이 main 브랜치에 푸시(push) 금지

프로젝트를 관통하는 개인적인 선호 사항은 Codex 설정 (Settings) 내의 메모리 (Memories) 패널을 사용하세요. "코드를 먼저 보여주고 설명은 나중에 하는 간결한 응답을 선호함" 또는 "코드를 참조할 때는 항상 줄 번호를 인용할 것"과 같은 항목을 고정(Pin)할 수 있습니다. 이 방식의 한계는 앞서 설명한 바와 같습니다. Codex 내부에서는 작동하지만, Claude나 Cursor까지 따라가지는 않습니다. 만약 당신이 오직 Codex 내에서만 활동한다면 괜찮습니다. 그렇지 않다면, 계속 읽어주세요.

해결책 2: Codex에 연결된 MCP 메모리 서버
이것이 제가 선택한 방식입니다. 설정하는 데 30초밖에 걸리지 않으며, Codex가 Claude Code, Claude Desktop, Cursor, Codex CLI 및 기타 7개의 MCP 클라이언트가 읽고 쓰는 것과 동일한 메모리에 접근할 수 있게 해줍니다. Codex는 3월 말 업데이트를 통해 MCP 서버를 네이티브로 지원합니다. 설정은 ~/.codex/config.toml에 위치합니다. 다음과 같은 블록을 추가하세요:

[mcp_servers.memory]
url = "https://memory.studiomeyer.io/mcp"
type = "http"

그게 전부입니다. Bearer 토큰도 필요 없고, 설정 파일에 API 키를 넣을 필요도 없습니다. Codex를 재시작하고 메모리에 접근하는 도구를 실행하면, 브라우저에 매직 링크 (Magic Link) 로그인 페이지가 열립니다. 이메일을 입력하고 도착한 이메일의 링크를 클릭하면 OAuth 흐름이 조용히 완료됩니다. 이제 Codex는 당신의 다른 모든 클라이언트가 사용하는 것과 동일한 메모리 저장소에 대한 지속적인 접근 권한 (dauerhaften Zugriff)을 갖게 됩니다.

중요한 수치: 저희 테스트 결과 "설정 파일 열기"부터 "Codex가 메모리 쿼리하기"까지 30초가 소요되었습니다. OAuth 리프레시 토큰 (refresh token)은 Codex의 보안 자격 증명 저장소 (secure credential store)에 저장됩니다. 어떤 토큰도 git 저장소에 남지 않습니다. 동일한 메모리에 Claude Desktop, Claude Code, Cursor, Codex CLI 및 Goose에서 동일한 원클릭 로그인으로 접근할 수 있습니다.

메모리가 연결된 후 Codex에 물어볼 수 있는 것들: "인증(authentication)에 관한 과거 결정 사항을 내 메모리에서 찾아줘.", "지난달에 속도 제한기(rate limiter)에 대해 무엇을 결정했지?", "나는 작은 커밋(small commits)을 배포하는 것을 선호한다는 걸 기억해 둬.", "4월에 어떤 고객들을 온보딩(onboard)했지?" 이제 모델은 여러 인터페이스(surfaces)에 걸쳐 유지되는 백엔드에 사실 관계를 읽고 씁니다. 만약 화요일에 Claude Code에서 속도 제한기에 대한 생각을 바꾼다면, Codex는 수요일에 그 새로운 결정을 확인하게 됩니다.

주의 깊게 살펴봐야 할 부분: 현재 Codex Desktop에는 여러 채팅이 스레드당 전체 MCP 프로세스 스택을 생성하는 알려진 버그 유형이 있습니다 (GitHub 이슈 11324, 14548, 18333, 20980이 모두 변형된 사례들을 추적하고 있습니다). 메모리는 열려 있는 채팅 수에 따라 선형적으로 증가합니다. 만약 10개 이상의 Codex 탭을 동시에 실행한다면 이 문제를 겪게 될 것입니다. 해결 방법은 stdio 서버 대신 (위의 예시와 같은) HTTP-transport MCP 서버를 사용하는 것입니다. HTTP 서버는 탭마다 실행되는 것이 아니라 네트워크에서 한 번만 실행됩니다.

해결책 3: 대부분의 팀이 실행해야 할 하이브리드 설정
준수 사항(compliance requirements)이 있는 고객 코드로 Codex를 사용하여 개발하면서 동시에 개인 프로젝트에도 Codex를 사용한다면, 아마도 두 가지 방식 모두를 원할 것입니다. OpenAI의 환경 내에 격리되어 있어야 하는 고객 프로젝트를 위한 내장 메모리(Built-in memory)와, 그 외 모든 것을 위한 MCP 메모리(MCP memory)입니다.

이를 연결하는 방법: 개인적인 프로젝트 간 선호 사항에는 Codex의 Memories 패널을 사용하세요. 프로젝트 컨벤션(conventions)에는 AGENTS.md 파일을 사용하세요. 도구 전반에 걸쳐 사용자를 따라다니는 운영자 수준(operator-level)의 메모리에는 MCP 메모리 서버를 사용하세요. 이 세 가지 계층은 서로 충돌하지 않습니다. 각기 다른 범위(scopes)를 다루기 때문입니다.

구체적으로, 저희 팀의 설정에서는 MCP 메모리가 이전 세션에서의 학습 내용, 아키텍처(architecture)에 대한 결정, 고객 프로필, 배포 패턴(deployment patterns), 그리고 "다시는 이렇게 하지 마시오"와 같은 경고 사항을 보유합니다. AGENTS.md 파일은 프로젝트별 스택(stack)과 규칙을 보유합니다. Memories 패널은 개인적인 커뮤니케이션 선호도를 보유합니다. Codex가 작업을 시작할 때, 이 세 가지 모두에 접근할 수 있습니다.

솔직한 한계점
MCP 메모리 경로를 택한다면, 반드시 알아야 할 세 가지가 있습니다.

첫째, 메모리 백엔드 (memory backend)가 중요합니다. 저희는 직접 구축했기 때문에 memory.studiomeyer.io에서 자체 백엔드를 운영하고 있습니다. 대안으로는 Mem0, Letta, Zep, MemNexus 등이 있습니다. 각 서비스는 무엇을 저장할지, 어떻게 검색할지, 그리고 어떻게 과금할지에 대해 서로 다른 견해를 가지고 있습니다. 확정하기 전에 최소 두 가지는 시도해 보십시오. 둘째, 검색 품질 (retrieval quality)은 공짜가 아닙니다. 좋지 않은 메모리 백엔드는 Codex에 오래되었거나 부적절한 컨텍스트 (context)를 제공하여 출력 품질을 저하시킬 수 있습니다. 의미론적 검색 (semantic search, 벡터 검색)과 전체 텍스트 검색 (full-text search), 그리고 지식 그래프 (knowledge graph)를 모두 지원하는 백엔드를 찾으십시오. 단일 모달리티 (single-modality) 검색은 너무 취약합니다. 셋째, OpenAI의 메모리 기능은 빠르게 출시되고 있습니다. 2026년 12월까지는 Codex의 내장 메모리 기능이 MCP 백엔드가 제공하는 기능에 훨씬 더 가까워질 것으로 예상합니다. 만약 장기적인 설정을 고려하고 있다면, 질문은 "지금 당장 무엇이 더 나은가"가 아니라 "지형이 다시 변할 때 무엇이 이식 가능 (portable)한가"가 되어야 합니다. MCP 기반 메모리는 제공업체 간에 이식 가능합니다. OpenAI 메모리는 그렇지 않습니다.

빌더들을 위한 시사점
매주 300만 명의 Codex 사용자는 두 그룹으로 나뉩니다. 한 그룹은 내장 메모리에 만족하며 MCP에 대해 전혀 생각하지 않습니다. 다른 그룹은 자신의 AI 워크플로우가 단일 제공업체의 울타리 안에서만 작동하지 않는다는 사실을 깨달은 사람들입니다. 이들은 어떤 작업에는 Claude를, 다른 작업에는 Codex를, 코드 작성에는 Cursor를, 리서치에는 ChatGPT를 사용합니다. 두 번째 그룹에게 MCP 메모리는 파편화된 워크플로우를 일관성 있게 만들어 주는 핵심적인 지지대 (load-bearing piece) 역할을 합니다. 만약 여러분이 첫 번째 그룹에 속한다면 괜찮습니다. Memories 기능은 다루는 범위 내에서 견고합니다. 만약 여러분이 두 번째 그룹에 속한다면, 위에서 언급한 30초 설정이 2026년 남은 기간 동안 복리로 작용할 핵심적인 움직임이 될 것입니다. 메모리는 컨텍스트가 거주하는 레이어 (layer)입니다. 일단 연결되면, 나중에 추가하는 모든 AI 도구는 제로 상태가 아니라 이미 존재하는 컨텍스트를 가지고 시작하게 됩니다.

시도해 보세요
저희의 백엔드로 MCP 메모리 경로를 테스트하고 싶다면, memory.studiomeyer.io에서 OAuth 로그인을 사용할 수 있습니다. 무료 티어는 월 200회의 메모리 작업(memory operations)을 제공하며, 이는 평가하기에 충분한 양입니다.

위의 설정 블록(config block)을 ~/.codex/config.toml에 넣고, Codex를 재시작한 뒤, 한 번만 로그인하면 모든 연결이 완료됩니다. 만약 다른 백엔드(backend)를 사용하고 싶다면, 동일한 Codex 설정 패턴을 MCP(Model Context Protocol)를 준수하는 모든 메모리 서버에 적용할 수 있습니다. 이 프로토콜은 공개되어 있습니다. 종속성(lock-in)은 메모리 계층(memory layer)에 있는 것이 아니라, 그 상위의 모델 계층(model layer)에 있습니다. 다음 모델 제조사가 어떤 메모리를 약속하는지가 아니라, 이식성(portability)을 기준으로 메모리 백엔드를 선택하십시오. 이 글은 원래 studiomeyer.io 에 게시되었습니다. StudioMeyer는 기업을 위한 프리미엄 웹사이트와 지능형 자동화(intelligent automation)를 구축하는 AI 우선(AI-first) 디지털 스튜디오입니다.