OpenCodex Bun 메모리 문제
전체 해결 과정

결론부터

[OpenCodex Windows Bun 메모리 폭증 — 해결 결론]

1. 이 문제는 Codex 앱을 재시작해서 해결한 것이 아닙니다. 최종 검증 동안 Codex 앱과 현재 OpenCodex 설치본·PATH·config를 변경하거나 재시작하지 않았습니다.
2. GitHub의 최신 OpenCodex 업데이트만으로도 해결되지 않았습니다. 2026-08-01 확인 기준 OpenCodex 2.8.0도 Bun 1.3.14(JavaScript 실행기)를 사용했고, 메모리 관련 Bun 수정이 병합됐어도 사용 중인 정식 런타임(실제 실행 환경)에는 포함되지 않았습니다.
3. 원인은 Bun 1.3.14 fetch(데이터 수신) 역압력 문제와 OpenCodex ReadableStream.tee()(스트림 복제)의 느린 검사 분기 버퍼가 결합한 대형 선읽기·임시 할당 폭증입니다.
4. 해결 방식은 tee() 복제를 피하고 relaySseEagerBounded(제한 큐 단일 읽기) + 8MiB 제한 큐를 사용하며, SSE(조각 단위 응답) JSON(데이터 문자열)을 이벤트당 한 번만 파싱해 로그·종료·응답 복원이 공유하도록 하는 것입니다.
5. 첫 유효 출력 뒤 반복되는 정확한 response.output_text.delta, response.reasoning_summary_text.delta, response.reasoning_text.delta는 JSON 객체 생성을 생략합니다. 종료·도구·usage(사용량)·model(모델)·service_tier(처리 등급)·error(오류)·incomplete(미완료)·디버그·비표준 입력은 기존 파싱으로 되돌립니다. 클라이언트 전달 바이트는 변경하지 않습니다.
6. 최신 격리 시험은 같은 OpenCodex 프로세스에서 64MiB 요청 5회를 5/5 완료했습니다. 송신=수신 335,217,630B, stderr(오류 출력) 0B, 최고 private(프로세스 전용 메모리) 397.4MB, 최고 RSS(실제 RAM 사용량) 320.9MB, 응답 상태 365B, 취소 뒤 proxy(중계 프로그램) 생존, 현재 설치 변경 false입니다.
7. 이전 단일 파싱 후보 486.2MB보다 88.8MB, 약 18.3% 개선됐습니다. 요청 4 이후 요청 5 메모리가 내려가고 유휴 바닥이 약 200MB로 복귀해 단순 누적 누수 가설도 기각됐습니다.
8. 관련 focused test(변경 기능 집중 시험)는 green(통과)이지만 full suite(전체 시험)는 6384 pass / 5 skip / 9 fail / 2 errors로 완전 green이 아닙니다. 알려진 Windows 환경 원인은 7건이고 실패 2건+오류 2건, 총 4건은 추가 진단이 필요합니다.
9. Claude Opus 5 독립 검증은 해시 8개와 핵심 수치를 모두 재현해 "조건부 통과 — 추가 시험 필요"로 판정했습니다. 치명적 코드 결함은 찾지 못했습니다.
10. 적용 전 필수 조건은 미귀속 full-suite 4건 진단, 병렬 요청 검증, 최신 후보 2~3회 반복, 실제 백업·롤백 실연, 깨진 JSON 델타 오류 기록 예외의 문서·회귀 시험입니다.

따라서 소스 해결 후보는 유효하지만 현재 설치에는 아직 적용하면 안 됩니다. 별도 승인, 검증 릴리스(독립 실행본), 전체 백업, validation certificate(검증 인증서), 롤백(되돌리기) 실연을 통과한 뒤에만 적용해야 합니다.

기존 OpenCodex 코드에서 고칠 부분

핵심은 데이터를 더 빨리 버리는 것이 아니라, 같은 대형 SSE(조각 단위 응답) 조각을 여러 갈래에 보관하고 여러 번 JSON 객체(프로그램이 다루는 데이터 덩어리)로 만드는 구조를 없애는 것이다.

2-1. tee() 대신 단일 reader + 제한 큐

const DEFAULT_MAX_QUEUE_BYTES = 8 * 1024 * 1024;
const DEFAULT_DRAIN_MS = 15_000;
const DEFAULT_DRAIN_BYTES = 32 * 1024 * 1024;

const eagerBody = relaySseEagerBounded(upstreamResponse.body, turnAc, {
  inspectChunk: chunk => inspector.feed(chunk),
  finishInspection: () => inspector.finish(),
  sawTerminal: () => inspector.reported(),
  onSynthetic: kind => { /* incomplete / failed 기록 유지 */ },
  onClientCancel: () => options.onNativePassthroughCancel?.(),
  onDone: () => unregisterTurn(turnAc),
});

이 구조는 상류(원본 응답 서버)를 한 번만 읽는다. 읽은 조각은 즉시 검사하고 클라이언트 큐(잠시 대기하는 데이터 줄)에 넣는다. 큐가 8MiB를 넘으면 생산자가 멈추므로 느린 클라이언트 뒤에 무제한 데이터가 쌓이지 않는다.

2-2. SSE 이벤트는 한 번만 파싱

type SseParseResult = { ok: true; value: unknown } | { ok: false };

function parseSsePayloadOnce(payload: string | null): SseParseResult {
  if (!payload || payload === "[DONE]") return { ok: false };
  try {
    return { ok: true, value: JSON.parse(payload) };
  } catch {
    return { ok: false };
  }
}

const parsed = parseSsePayloadOnce(payload);
// parsed.value를 request log, first output, terminal, completed response가 공유한다.

수정 전 일반 델타(응답 한 조각) 1개는 JSON.parse(문자열을 객체로 바꾸는 처리)가 5회, 델타+완료 2개 이벤트는 총 9회 호출됐다. 공유 파싱 후 각각 1회와 2회로 줄었다.

2-3. 첫 출력 뒤 반복 표준 델타 객체 생성 생략

const SKIPPABLE_POST_FIRST_OUTPUT_DELTA =
  /^(?:\{"type":"response\.(?:output_text|reasoning_summary_text|reasoning_text)\.delta",)(?![\s\S]*(?:\\u|"(?:type|response|model|service_tier|usage|error|last_error|incomplete_details)"\s*:))/;

if (firstOutputObserved && isSkippablePostFirstOutputDelta(payload)) return;

첫 유효 출력은 반드시 파싱한다. 이후에도 type, response, model, service_tier, usage, error, last_error, incomplete_details, Unicode 이스케이프가 보이면 빠른 경로를 쓰지 않는다.

여기까지 온 전체 과정

처음부터 정답을 알고 수정한 것이 아니다. 재시작·업데이트·런타임(실제 실행 환경)·스트림(연속 데이터) 방식·응답 저장·JSON 파싱 가설을 하나씩 분리하고, 실패 결과를 다음 실험 설계에 사용했다.

1. 현상 확인

   Windows에서 OpenCodex Bun 프로세스 private 메모리(프로세스 전용 메모리)가 수 GiB(기비바이트)까지 커졌다. 핸들(열린 파일·소켓 표식)은 약 321~325로 안정적이어서 파일·소켓 핸들 누수 하나가 단독 원인이라는 가설은 약했다. 모델 수가 28개에서 30개로 늘어도 메모리 변화와 직접 비례하지 않아 모델 본체 적재 가설도 제외했다.

2. 재시작을 해결책으로 사용하지 않음

   Codex 데스크톱 앱을 재시작해서 해결한 것이 아니다. 프로세스 상태 변화 뒤 메모리가 크게 내려가는 현상은 “영구 보관 하나”보다 “대형 임시 버퍼와 늦은 회수”가 중심이라는 진단 단서로만 사용했다. 최종 후보 시험과 문서·Claude 검증 동안 Codex 앱과 현재 설치본을 중지·재시작하지 않았다.

3. GitHub 최신 업데이트 확인 — 업데이트만으로 미해결

   2026-08-01 기준 OpenCodex 최신 2.8.0도 Bun 1.3.14를 고정했고 MIN_FIXED_BUN_VERSION=null이었다. Bun의 관련 수정 #29831과 #32120은 병합됐지만 사용 중인 정식 Bun에는 들어오지 않았다. #31654는 open이었다. 따라서 GitHub에서 OpenCodex를 최신으로 받는 것만으로 런타임 결함과 tee() 구조가 함께 해결되지 않았다.

4. Canary(시험판)를 설치하지 않고 격리 다운로드

   1.4.0-canary.1+f68e504ae를 D 드라이브 검증 폴더에만 내려받고 공식 ZIP SHA-256(파일 내용 지문)과 EXE SHA-256을 대조했다. PATH(명령 검색 경로), 현재 Bun, 현재 OpenCodex는 바꾸지 않았다.

5. Strict A/B(한 조건만 바꾸는 비교)로 런타임과 스트림 방식 분리

   Node 원본 서버, 느린 클라이언트, 데이터 크기·시간·포트를 고정하고 proxy(중계 프로그램) Bun과 스트림 방식만 바꿨다. 정식 Bun eager(적극 읽기)는 815.7MB까지 급증했지만 Canary에서는 direct(검사 없이 직접 전달) 122.0MB, eager 168.2MB, pull(클라이언트 속도에 맞춰 읽기) 226.1MB, tee(스트림 복제) 258.1MB였다. 기능 손실이 있는 direct를 제외하면 eager가 최선이었다.

6. 이름과 실제 코드 경로 불일치 발견

   설정 이름은 eager-relay였지만 실제 응답 분기는 pull-paced 경로를 호출하는 상태가 있었다. 설정·문서·간이 A/B의 최선 방식과 실제 실행 코드가 일치하도록 relaySseEagerBounded 경로를 고정했다.

7. 기능 손실 없는 단일 reader 후보

   tee()를 제거하면서 완료·실패·불완전, 402·429, 첫 출력, 요청 로그, 대화 연속성, 취소 뒤 늦은 terminal, turn 등록 해제를 같은 inspector에 연결했다. 큐는 기본 8MiB로 제한했다.

8. 독립 프로세스 64MiB 3회 통과

   새 격리 OpenCodex 프로세스를 매번 시작한 64MiB 시험은 최고 private 500.2/489.4/486.0MB로 3회 완료했다. 그러나 매번 새 프로세스였기 때문에 누적 여부를 증명하지 못했다.

9. 같은 프로세스 연속 3회에서 실패

   같은 시험 프로세스에 요청을 연속으로 보내자 요청 1과 2는 완료했지만 요청 3 도중 519.3MB로 512MB 선제중단선에 도달했다. 안전장치는 정상 동작했지만 후보는 반복 사용 조건을 통과하지 못했다. 128MiB 확대는 중단했다.

10. 응답 저장 누수 가설 기각

    시험용 완료 응답 저장량은 69B뿐이고 64MiB 델타 본문은 응답 상태 Map(키와 값을 보관하는 저장소)에 들어가지 않았다. 대신 일반 델타 1개에서 JSON 파싱 5회, 완료까지 2개 이벤트에서 9회가 확인됐다.

11. 단일 파싱 수정

    한 번 파싱한 객체를 요청 로그, 종료 판정, 첫 출력, 완료 응답 복원에서 공유했다. 파싱 횟수는 5→1, 9→2로 줄었다. 같은 프로세스 5×64MiB를 486.2MB에서 5/5 완료했지만 512MB까지 여유가 25.8MB뿐이었다.

12. 내부 계측 장치 보강

    200ms마다 JS heap(JavaScript 객체 메모리), external(런타임 외부 메모리), arrayBuffers(바이트 배열 메모리), JSC heap, 응답 상태, 활성 요청 수를 기록했다. 표준출력 방식은 강제 종료 때 샘플이 사라졌고, JSC 상세 객체는 PowerShell의 대소문자 키 충돌로 JSON 변환에 실패했다. 전용 JSONL(한 줄에 JSON 하나) 즉시 쓰기와 JSC 숫자 3개 축소로 해결했다.

13. 첫 출력 뒤 반복 델타 파싱 생략

    첫 출력은 파싱하되 이후 정확한 표준 텍스트·추론 델타만 객체 생성을 생략했다. 메타데이터·종료·도구·오류·디버그·비표준 입력은 기존 경로로 복귀시켰다. 집중 20/20, Canary 58/58·64/64·136/136, 정식 Bun 64/64, 타입 검사와 바이트 동일 시험이 통과했다.

14. 최종 같은 프로세스 5×64MiB

    최신 후보는 5/5, 송신=수신 335,217,630B, 최고 private 397.4MB, 최고 RSS 320.9MB로 완료했다. 이전 486.2MB보다 88.8MB·18.3% 낮고 512MB까지 여유는 114.6MB였다. 완료 뒤 private는 268.9MB로 내려갔다.

15. 전체 시험과 환경 실패 분리

    관련 focused 시험(변경 기능 집중 시험)은 green(통과)이었지만 full suite(전체 시험)는 6384 pass / 5 skip / 9 fail / 2 errors였다. doctor(환경 진단) 5건, Windows codex.cmd 기대 차이 1건, symlink(파일 연결) EPERM(권한 거부) 1건은 환경성으로 진단했다. 나머지 실패 2건과 오류 2건은 아직 개별 원인이 필요하다.

16. Claude Opus 5 독립 교차검증

    Claude가 해시 8개, 원본 표본, 정규식 반례 14개, 코드 소비자 함수를 다시 확인했다. 핵심 수치는 모두 맞고 치명적 코드 결함은 없다고 판단했지만, 미귀속 full-suite 4건·병렬 요청·실제 백업/롤백·반복 측정 등을 이유로 조건부 통과를 내렸다.

17. 배포는 준비만, 적용하지 않음

    기존 폴더를 덮어쓰지 않고 새 릴리스를 만든 뒤 Junction만 전환하는 백업·적용·롤백 스크립트를 준비했다. 가짜 Junction 전환·거부·실패 자동 원복은 통과했지만 실제 릴리스·백업·적용·롤백은 실행하지 않았다.

안 된 방법과 버리지 말아야 할 교훈

수치와 시험 증거

최종 부하 결과

후보 진화 비교

시험 판정

Claude가 다시 확인한 것

Claude는 128MiB 확대에 대해서도 반대 결론을 냈다. 64MiB 요청의 private 증분 약 127MB가 현재 512MB 안전선 여유 114.6MB보다 커서 단순 외삽 시 약 524MB가 될 수 있다. 현 상한 그대로 128MiB를 실행하지 말고 96MiB 중간 단계 또는 안전선 재설계가 먼저다.

백업·적용·롤백 명령

사용자는 Git(코드 버전 관리 도구)을 몰라도 된다. 아래 스크립트는 현재 경로가 이미 입력돼 있다. 단, 실제 적용은 Claude 조건과 validation certificate(검증 인증서)를 모두 해소한 뒤 별도 승인으로만 실행한다.

지금 실행 가능한 DRY_RUN(실제 변경 없는 점검)

& 'D:\nextcoco_work_ALL\01_work_claude_codex\_verify\opencodex_deployment\00-build-standalone-release.ps1'

& 'D:\nextcoco_work_ALL\01_work_claude_codex\_verify\opencodex_deployment\01-backup-current-opencodex.ps1'

별도 승인 뒤 실행 — 현재 실행 금지

& 'D:\nextcoco_work_ALL\01_work_claude_codex\_verify\opencodex_deployment\00-build-standalone-release.ps1' -Execute

& 'D:\nextcoco_work_ALL\01_work_claude_codex\_verify\opencodex_deployment\01-backup-current-opencodex.ps1' -Execute

& 'D:\nextcoco_work_ALL\01_work_claude_codex\_verify\opencodex_deployment\02-apply-validated-opencodex.ps1' -ConfirmNoActiveRequests

& 'D:\nextcoco_work_ALL\01_work_claude_codex\_verify\opencodex_deployment\02-apply-validated-opencodex.ps1' -Execute -ConfirmNoActiveRequests

& 'D:\nextcoco_work_ALL\01_work_claude_codex\_verify\opencodex_deployment\03-rollback-opencodex.ps1' -Execute -ConfirmNoActiveRequests -RestoreConfig

다음 문제 해결에도 재사용할 절차

1. 현재 설치를 동결한다. PATH·config·실행파일·PID·health·해시를 기록하고 원인 조사 중 업데이트하지 않는다.
2. 재시작을 해결로 부르지 않는다. 재시작 뒤 회수는 누수 형태를 판단하는 증거일 뿐 코드 수정 증거가 아니다.
3. GitHub 버전과 실제 포함 런타임을 분리한다. 최신 앱이라도 오래된 Bun·Node·라이브러리를 묶고 있을 수 있다.
4. 한 번에 변수 하나만 바꾼다. 원본 서버·클라이언트·크기·시간을 고정하고 런타임 또는 스트림 방식만 교체한다.
5. 기능 손실이 있는 저메모리 결과를 버린다. direct가 낮아도 로그·종료·대화 연속성을 잃으면 해결이 아니다.
6. 독립 프로세스 시험 뒤 같은 프로세스 반복 시험을 한다. 실제 누적 문제는 새 프로세스 1회 시험에서 보이지 않는다.
7. 저장 누수와 임시 할당을 분리한다. Map 크기, heap, external, arrayBuffers, RSS, private를 함께 기록한다.
8. 실패한 계측도 기록한다. stdout 유실, JSON 변환 충돌처럼 측정 도구 오류가 제품 오류로 오해되지 않게 한다.
9. 안전 상한을 제품 시작 메모리보다 높게 설계한다. 선제중단·하드 상한·시스템 여유 하한·감시 간격을 함께 둔다.
10. focused와 full suite를 분리해 보고한다. focused green을 전체 green으로 과장하지 않고 실패 이름·원인을 모두 귀속한다.
11. 원본 로그와 SHA-256(파일 내용 지문)을 보존한다. 요약값이 아니라 원본 표본으로 제3자가 재계산할 수 있어야 한다.
12. 다른 모델·사람이 반대 입장에서 검증한다. 수치 재현, 반례, 누락 위험, 배포 복구성을 따로 확인한다.
13. 적용은 새 릴리스(독립 실행본) + 전체 백업 + Junction(폴더 연결) 전환으로 한다. 기존 폴더를 덮어쓰지 않고 실패 시 즉시 원래 대상을 연결한다.

원본 증거와 해시

현재 설치 확인값

• OpenCodex 2.7.30, PID 15464, health ok, 모델 30개
• Junction 대상: C:\Users\USER\Documents\Codex\2026-07-21\d-nextcoco-codex-gil\opencodex-test
• 현재 relay SHA-256: B5C9EB824F6A2FFCD53A1F098B9FCDF7FBAD51461D6CE9F94C747687E64A5DE9
• config SHA-256: BD9D5D2569CAC892D4A18B00E6F438F57C0DD443FDCC1B8E8663A10BE0577FE2
• 후보 relay 해시와 현재 relay 해시가 다르므로 후보가 현재 설치에 적용되지 않았음

최종 체크리스트