코덱스 울트라 멀티세션, 맥북 메모리와 SSD 수명을 갉아먹는 이유

코덱스 울트라 세션을 3개 띄웠더니 M4 프로 맥북프로가 버벅였다는 경험담이 커뮤니티에 올라왔다. 32GB급 메모리 환경에서 세션을 과하게 돌리면 메모리 스왑이 발생한다. 그 스왑이 SSD 수명을 깎아먹는다는 우려까지 이어졌다. 실제로 OpenAI의 이슈 트래커를 뒤져보면 이 경험이 개인의 착각이 아니라는 근거가 꽤 구체적으로 남아 있다.

서브에이전트가 서브에이전트를 부르는 구조

코덱스의 울트라는 단순히 '더 오래 생각하는' 모드가 아니다. 단일 에이전트가 아니라 여러 서브에이전트를 동시에 띄워 작업을 쪼개 맡기는 방식이다. 문제는 여기에 있다. 이 서브에이전트들이 각각 부모와 같은 최고 추론 강도로 재귀 호출되면서 대형 작업 하나가 사실상 수십 개의 독립 프로세스로 증식한다.

GitHub 이슈 트래커에는 이 구조가 실제로 어떤 메모리 부담을 일으키는지 기록이 남아 있다. 24GB 메모리 맥에서 울트라 멀티에이전트 스웜을 돌리다 메모리 사용량이 130GB까지 치솟은 사례가 보고됐고, 겉보기에 평범한 단일 세션에서도 메모리가 75GB 이상 불어난 경우가 확인됐다. 완료된 서브에이전트와 MCP 자식 프로세스를 제때 회수하지 못해 좀비 프로세스가 1300개 넘게 쌓였다. 상주 메모리 37GB에 스왑 40GB까지 잡아먹은 사례도 별도로 접수됐다. OpenAI 쪽도 이 문제를 인지했다. 울트라와 높은 동시성 조합일 때 경고를 띄우는 패치를 자체적으로 반영한 바 있다.

방에서 나온 '128GB 환경에서도 세션 3개면 불안정해질 수 있다'는 우려는 과장이 아니다. 이미 문서화된 패턴과 같은 방향이다.

토큰까지 삼킨다, 한도가 20분 만에 바닥나는 구조

메모리만이 아니다. 울트라가 서브에이전트를 최고 추론 강도로 중첩 호출하는 구조는 토큰 소모에도 그대로 반영됐다. 커뮤니티에서는 이 방식이 작업당 토큰 소모를 6~12배까지 끌어올린다는 분석이 나왔다. 5시간 단위 사용 한도를 20분 만에, 주간 한도를 90분 만에 소진하는 사례까지 보고됐다. 문제가 컸던 시기는 모델 자체의 토큰 효율 이슈와 겹치기도 했다. 사용자들의 체감 소모 속도가 유독 가팔랐던 배경이다.

OpenAI는 이에 대응해 ChatGPT Work와 코덱스 구독자 전체를 대상으로 사용 한도를 초기화하는 조치를 취했다. 이후 모델을 약 18% 더 토큰 효율적으로 만드는 업데이트도 내놨다. 메모리 폭증과 토큰 폭증이 같은 뿌리, 즉 '서브에이전트가 서브에이전트를 부르는' 울트라의 기본 설계에서 나왔다는 점은 짚어둘 만하다.

스왑과는 별개로, SSD를 직접 갉아먹은 로깅 버그

방에서 나온 'SSD 수명 우려'는 메모리 스왑 얘기였다. 하지만 실제로 2026년 6월 코덱스에서 확인된 SSD 문제는 스왑과는 결이 다른 원인에서 비롯됐다. 코덱스가 TRACE 레벨로 모든 진단 로그를 로컬 SQLite 파일에 계속 기록하도록 설계돼 있었다. 최악의 경우 연간 640TB에 달하는 쓰기가 발생하는 것으로 확인됐다. 한 개발자는 21일 가동 만에 코덱스 하나가 SSD에 약 37TB를 써넣은 사실을 로그로 추적해 이슈를 접수했다. 1TB급 일반 소비자용 SSD의 보증 쓰기 총량이 대략 600TB 안팎인 점을 감안하면, 상시 가동 시 1년 안에 드라이브 수명 예산을 다 쓸 수도 있는 수치다.

애플 실리콘 맥은 SSD가 로직보드에 납땜돼 있어 교체가 사실상 불가능하다. 드라이브가 닳으면 부품 교체가 아니라 로직보드 수리나 기기 교체로 이어진다. 이 때문에 같은 쓰기량이라도 애플 실리콘에서 체감 위험이 더 크다는 지적이 나왔다. OpenAI는 문제가 접수된 지 열흘 안팎 만에 로그 레벨을 낮추는 패치를 배포했다. 자체 측정으로 로그량을 약 85% 줄였다고도 밝혔다. 최신 버전으로 업데이트하면 상당 부분 해소되는 문제라는 뜻이다.

한편 메모리 스왑이 SSD를 갉아먹는다는 우려 자체는 일반론으로는 틀리지 않는다. 애플 실리콘의 통합 메모리 구조에서는 CPU·GPU·뉴럴엔진이 메모리 풀을 공유하기 때문에 무거운 로컬 작업이 몰리면 스왑 압박이 더 빨리 온다. 다만 스왑으로 인한 SSD 마모는 대체로 기기 교체 주기보다 느리게 누적되는 편이다. 그만큼 코덱스 사례처럼 로깅 버그가 별도로 작동한 경우와는 체감 속도가 다르다.

클로드 코드는 정말 더 안정적인가

방에서는 클로드가 세션 20개 이상을 돌려도 상대적으로 안정적이었다는 대조 경험이 나왔다. 이 인상이 완전히 근거 없는 얘기는 아니다. 다만 클로드 코드 쪽 이슈 트래커에도 장시간 세션에서 RSS 메모리가 시간당 수백MB에서 많게는 시간당 45GB까지 늘어난 사례, 유휴 상태에서도 분당 400~500MB씩 메모리가 새는 사례가 여럿 보고돼 있다. 클로드 코드도 메모리 문제로부터 자유롭지는 않다.

차이는 문제가 커지는 방식에 있어 보인다. 클로드 코드의 메모리 증가는 대체로 세션 하나, 프로세스 하나 안에서 시간에 비례해 누적되는 선형적 패턴이다. 반면 코덱스 울트라는 서브에이전트가 서브에이전트를 부르는 구조 자체가 프로세스 수를 기하급수적으로 늘릴 수 있다. 세션 수가 적어도 순간적인 폭증이 훨씬 두드러지는 이유다. 방에서 세션 3개로도 버벅였다는 경험과 세션 20개도 버틴다는 경험이 같은 하드웨어에서 동시에 나올 수 있는 이유이기도 하다.

작업 특성별로 두 도구를 나눠 쓰는 방식도 커뮤니티에서 자주 관찰된다. 시간이 걸려도 정확도가 중요한 작업은 코덱스, 대화형으로 빠르게 처리할 작업은 클로드로 나누는 식이다. 실제 벤치마크에서도 코덱스가 같은 작업을 3~4배 느리게 처리하는 대신 토큰은 훨씬 적게 쓰는 경우가 확인됐다. 속도와 자원 소모가 반비례하는 경향이 있다는 뜻이다.

로컬에서 멀티에이전트 작업을 상시로 돌릴 계획이라면 하드웨어 선택 단계부터 고려할 부분이 있다. M4 프로 라인업은 통합메모리를 24GB 또는 48GB 중에서 고르는 구성이다. 구매 후에는 늘릴 수 없다. 울트라처럼 서브에이전트를 다수 띄우는 모드를 자주 쓸 계획이라면 스왑 의존을 줄이기 위해 여유 있는 메모리 구성과, 코덱스라면 최신 패치 버전을 유지하는 쪽이 안전하다.