요즘 Claude Code로 긴 작업을 시키다 보면 “잘 가다가 왜 또 죽었지?”라는 생각이 들 때가 있습니다. 응답이 멈추고, 컨텍스트 압축이 길어지고, 갑자기 터미널을 다시 열어야 하거나, 멀쩡하던 모델이 529 Overloaded와 429를 내놓기도 합니다.
반면 Codex는 같은 종류의 작업에서 프로세스가 좀 더 오래 버티고, 중간 상태를 관리하면서 끝까지 이어 가는 느낌을 줄 때가 있습니다. 그래서 한동안은 “안정성만 보면 Codex가 더 낫지 않나?”라는 생각이 들 수 있습니다.
그런데 최근에는 오히려 결론이 조금 달라졌습니다. Claude가 중간에 더 자주 멈추는 것처럼 보여도, 세션을 되살리고 다시 맥락을 이어 갔을 때 나오는 결과까지 포함하면 결국 Claude가 더 안정적이고 좋은 도구처럼 느껴질 수 있습니다.
이 글에서는 Claude가 “죽는” 현상을 서비스 장애, 로컬 프로세스 문제, 컨텍스트 압축, 사용 한도, 외부 도구 실패로 나누고, 공개된 통계로 Claude Code와 Codex의 안정성을 어디까지 비교할 수 있는지 살펴보겠습니다.
그림: 프로세스가 멈추는 것과 작업 전체가 사라지는 것은 서로 다른 문제다.
먼저 ‘죽는다’는 말을 네 가지로 나눠야 한다
사용자가 보는 현상은 모두 비슷하지만 원인은 전혀 다를 수 있습니다.
| 사용자가 보는 증상 | 실제로 가능한 원인 | 확인할 위치 |
| 응답이 갑자기 끊긴다 | 모델 API 장애, 스트리밍 연결 종료, 네트워크·프록시 문제 | 상태 페이지, 오류 코드 |
| Claude Code가 버벅이거나 멈춘다 | 로컬 CPU·메모리 사용량, 큰 저장소, 과도한 도구 출력 | Activity Monitor, /doctor, /context |
| 한참 동안 압축 중이다 | 컨텍스트가 커져 auto-compaction 수행 | /context, /compact |
| 모델 선택이나 호출이 거절된다 | 사용 한도, 잘못된 entitlement, 429·529 | 오류 메시지, 요금제·상태 페이지 |
| 명령은 살아 있는데 일을 진행하지 못한다 | MCP 서버, hook, shell 명령, 권한 요청이 대기·실패 | MCP·hook 로그, 터미널 |
따라서 “Claude 모델이 불안정하다”와 “Claude Code 프로세스가 불안정하다”는 같은 문장이 아닙니다. 모델 서비스가 정상이어도 로컬 CLI가 큰 로그를 처리하다 멈출 수 있고, CLI가 멀쩡해도 Anthropic API에서 오류가 발생할 수 있습니다.
그림: 같은 ‘멈춤’으로 보여도 원인은 서비스, API, 로컬 자원, 외부 도구 계층으로 나뉜다.
첫 번째 원인: 실제 Claude 서비스 장애
Claude가 죽는 이유 가운데 일부는 분명히 서비스 쪽에 있습니다. Anthropic은 Claude Status에서 claude.ai, Claude API, Claude Code를 별도 컴포넌트로 공개합니다.
2026년 7월 30일 확인한 Claude Code의 공개 uptime은 다음과 같습니다.
| 기간 | Claude Code 공개 uptime |
| 2026년 5월 | 99.49% |
| 2026년 6월 | 99.45% |
| 2026년 7월 | 99.43% |
| 최근 90일 | 99.44% |
99.44%는 높은 숫자처럼 보이지만, 90일로 환산하면 약 12시간의 비정상 상태에 해당합니다. 물론 이 계산은 상태 페이지의 컴포넌트 수준 집계일 뿐이며, 특정 사용자·지역·요금제의 실제 경험과 정확히 같지는 않습니다.
7월 incident history에는 모델별 elevated errors뿐 아니라 Claude Code와 웹·원격 기능에 함께 영향을 준 서비스 disruption도 여러 차례 기록돼 있습니다. 특히 7월 14일, 21일, 22일에는 Claude Code나 컨테이너 생성 등 에이전트 작업에 직접 영향을 줄 수 있는 장애가 공개됐습니다.
즉 “내 Claude만 이상한가?”라는 느낌이 들 때 실제로 전체 서비스 문제가 섞여 있을 가능성은 충분합니다. 같은 시간대에 여러 저장소와 세션에서 비슷한 오류가 난다면 로컬 설정을 고치기 전에 Claude Status부터 확인하는 편이 빠릅니다.
두 번째 원인: 429, 529와 사용 한도
Claude Code는 모델 응답을 위해 Claude API를 호출합니다. 공식 오류 문서는 CLI에 보이는 런타임 오류 대부분이 API 오류 코드와 연결된다고 설명합니다.
대표적인 사례는 다음과 같습니다.
429 Too Many Requests
→ 짧은 시간의 요청량 또는 계정 사용 한도와 관련
529 Overloaded
→ Anthropic 서비스가 과부하 상태
500·502·503
→ 서버 또는 중간 네트워크 계층 오류 가능성
사용자 관점에서는 모두 “Claude가 멈췄다”로 보이지만 대응은 달라야 합니다. 429라면 무작정 재실행하는 것이 오히려 상황을 악화할 수 있고, 529라면 잠시 기다린 뒤 재시도하는 편이 낫습니다.
요금제에 포함된 모델이 갑자기 usage credit을 요구하는 문제도 있었습니다. Anthropic은 2026년 7월 Fable 5가 일부 Max 사용자에게 잘못된 크레딧 요구를 표시한 incident를 공개했고, 복구 후 Claude Code를 다시 시작하라고 안내했습니다.
따라서 “프로세스를 다시 켜니 해결됐다”는 경험이 항상 로컬 버그가 고쳐졌다는 뜻은 아닙니다. 재시작하는 동안 서버의 entitlement나 모델 라우팅 상태가 정상화됐을 수도 있습니다.
세 번째 원인: 큰 저장소와 과도한 도구 출력
Anthropic의 Claude Code 공식 troubleshooting 문서는 고 CPU·메모리 사용량, hang, auto-compact thrashing을 별도 안정성 문제로 다룹니다.
Claude Code는 단순 채팅창이 아닙니다. 저장소 검색, 파일 읽기, diff 생성, shell 실행, MCP 호출, hook 실행 결과를 하나의 에이전트 루프에서 처리합니다.
사용자 요청
↓
저장소 검색
↓
여러 파일 읽기
↓
명령 실행과 대량 로그
↓
도구 결과를 대화 컨텍스트에 추가
↓
다음 판단
대형 monorepo에서 범위를 지정하지 않은 검색을 시키거나 수만 줄의 빌드 로그를 그대로 전달하면 로컬 메모리와 모델 컨텍스트가 동시에 커집니다. 여기에 여러 MCP 서버와 hook이 붙으면 시작할 때부터 도구 정의와 지속 지침이 컨텍스트를 차지합니다.
공식 문서는 이런 경우 다음 대응을 권장합니다.
- /compact로 큰 출력과 오래된 대화를 요약합니다.
- 큰 작업이 끝날 때마다 Claude Code를 재시작합니다.
- /compact keep only the plan and the diff처럼 남길 내용을 지정합니다.
- 큰 파일 작업은 별도 subagent의 컨텍스트로 분리합니다.
- 앞 대화가 필요 없다면 /clear를 사용합니다.
- /doctor로 설치, 설정, MCP, 컨텍스트 사용량을 점검합니다.
여기서 중요한 것은 “Claude에게 더 많은 맥락을 주면 항상 좋아진다”가 아니라는 점입니다. 관계없는 로그, 오래된 실패, 중복된 지침이 쌓이면 속도뿐 아니라 판단 품질도 떨어질 수 있습니다.
네 번째 원인: Auto-compaction이 죽은 것처럼 보인다
컨텍스트 윈도우가 커지면 Claude Code는 이전 대화를 요약해 공간을 확보합니다. 사용자는 이때 긴 대기 시간이나 응답 정지처럼 느낄 수 있습니다.
긴 대화와 도구 출력 누적
↓
컨텍스트 한계에 접근
↓
이전 기록 요약
↓
중요 지침과 현재 상태 재구성
↓
작업 계속
문제는 압축 자체만이 아닙니다. 압축 직후 Claude가 방금 전의 세부 조건을 놓치거나, 다시 파일을 읽고, 재차 압축하는 상태가 반복되면 사용자는 에이전트가 죽었다고 느낍니다.
/context로 무엇이 공간을 차지하는지 확인하고 자연스러운 작업 경계에서 직접 /compact를 실행하는 것이 좋습니다. 대형 빌드 로그를 처리한 뒤에는 다음 기능 개발로 넘어가기 전에 요약하도록 만들면 갑작스러운 auto-compaction보다 예측 가능해집니다.
프로젝트 루트의 CLAUDE.md는 압축 후 다시 읽히지만, 대화에서만 전달한 지침이나 아직 다시 접근하지 않은 하위 디렉터리의 지침은 체감상 사라질 수 있습니다. 반드시 유지돼야 하는 규칙은 대화 한 번에만 적지 말고 적절한 CLAUDE.md에 두는 편이 안정적입니다.
그림: 컨텍스트는 압축되지만 세션 기록과 체크포인트를 이용해 작업을 다시 이어 갈 수 있다.
다섯 번째 원인: Claude가 아니라 MCP·hook·shell이 죽는다
에이전트는 연결된 구성 요소 가운데 가장 약한 고리만큼 안정적입니다.
Claude Code
├─ shell
├─ Git
├─ ripgrep
├─ MCP server A
├─ MCP server B
├─ pre-tool hook
└─ post-tool hook
MCP 서버가 응답하지 않거나 hook이 종료되지 않으면 Claude Code 화면은 모델이 멈춘 것처럼 보일 수 있습니다. 권한 확인창이 다른 창 뒤에 숨어 있어도 비슷합니다.
이 경우 모델을 여러 번 바꾸는 것은 큰 도움이 되지 않습니다. 다음 순서가 더 효율적입니다.
- Ctrl+C로 현재 작업을 취소할 수 있는지 확인합니다.
- /doctor로 MCP와 설정 상태를 점검합니다.
- 최근 추가한 MCP 서버와 hook을 잠시 비활성화해 재현 여부를 봅니다.
- 오래 걸리는 shell 명령은 별도 터미널에서 실행해 종료 여부를 확인합니다.
- proxy, VPN, TLS inspection 환경이라면 API와 패키지 다운로드 경로를 점검합니다.
Claude Code의 공식 문서도 command hang이 풀리지 않으면 터미널을 닫고 다시 시작할 수 있다고 설명합니다.
중요한 사실: 프로세스가 죽어도 세션은 대개 살아 있다
Claude Code는 대화를 진행하면서 세션을 로컬 transcript에 계속 저장합니다. 공식 문서에 따르면 CLI 세션은 프로젝트별 JSONL 파일로 기록됩니다.
따라서 터미널을 닫았다고 작업 기록까지 반드시 사라지는 것은 아닙니다.
# 현재 프로젝트의 최근 세션 이어서 열기
claude --continue
# 세션 선택기 열기
claude --resume
# 이름이나 세션 ID로 이어서 열기
claude --resume auth-refactor
Claude Code가 멈췄을 때 공식 troubleshooting도 “터미널을 닫고 재시작하더라도 대화를 잃지 않으며, 같은 디렉터리에서 claude --resume으로 복구할 수 있다”고 안내합니다.
이 부분이 Claude를 다시 안정적으로 느끼게 만드는 핵심입니다. 프로세스 생존율과 작업 복구 가능성은 다른 지표입니다.
Codex는 정말 더 안정적인가
체감상 Codex가 더 안정적으로 보일 수 있는 이유는 있습니다. 긴 작업을 단계와 상태로 관리하고, 도구 실행 중간에 사용자와 계속 소통하며, 작업을 별도 환경이나 스레드로 분리하는 제품 구조가 “한 프로세스가 멈췄다”는 인상을 줄여 줍니다.
그러나 Codex도 공개 incident가 적지 않습니다. 2026년 5월부터 7월까지 OpenAI 상태 페이지에는 다음과 같은 사례가 기록됐습니다.
| 시기 | 공개된 Codex 관련 사례 |
| 5월 | Codex Cloud·Code Review high failure rate, Codex 5.5 high error rate, context compaction latency, rate limit 문제 |
| 6월 | Codex capacity 오류, Cloud task 오류, access token 문제, usage limit이 예상보다 빨리 소진되는 문제 |
| 7월 | 5.6-sol overload, Desktop·CLI access denied, GitHub 의존 workflow 오류, Codex Review 오류 |
2026년 6월 2일 장애에서는 rate-limiting 의존성이 비정상 상태가 되면서 Codex 요청이 잘못된 HTTP 429로 거절됐습니다. 7월 19일에는 지역 데이터베이스 용량 문제로 일부 Codex 요청이 실패했습니다.
즉 Codex가 구조적으로 절대 죽지 않는다는 결론을 내릴 근거는 없습니다. 다만 오류가 발생했을 때 UI가 상태를 보여 주는 방식, 작업을 분리하는 방식, 재시도와 중간 결과를 보존하는 방식 때문에 더 안정적으로 느껴질 수 있습니다.
통계로 Claude와 Codex를 직접 비교할 수 있을까
결론부터 말하면 현재 공개 자료만으로 공정한 직접 비교는 어렵습니다.
Anthropic은 Claude Code라는 개별 컴포넌트의 월별·90일 uptime을 공개합니다. 반면 OpenAI 상태 페이지는 Codex 컴포넌트와 incident history를 공개하지만, 같은 화면에서 비교 가능한 Codex 월별 uptime 백분율을 제공하지 않습니다.
또 incident 등록 기준도 회사마다 다릅니다.
| 비교 항목 | Anthropic | OpenAI |
| 제품별 상태 | Claude Code 컴포넌트 별도 제공 | Codex 컴포넌트 별도 제공 |
| 월별 uptime 백분율 | Claude Code에 공개 | 공개 페이지에서 같은 형식의 Codex 수치 확인 불가 |
| incident history | 모델별·제품별 세분화가 매우 많음 | 여러 제품을 묶은 incident와 Codex 전용 incident가 혼재 |
| 사용자별 차이 | 요금제·지역·모델에 따라 다를 수 있음 | tier·모델·기능에 따라 다를 수 있다고 명시 |
따라서 incident 개수만 세어 “Claude가 더 불안정하다”고 말하면 공개 정책이 더 세분화된 회사를 불리하게 평가할 수 있습니다. 반대로 Claude Code 99.44%만 보고 개별 세션이 안정적이라고 단정해도 안 됩니다. 상태 페이지는 로컬 프로세스 crash, MCP hang, 큰 로그 때문에 생긴 메모리 문제를 모두 포착하지 못합니다.
공정한 비교를 하려면 같은 팀에서 다음을 직접 측정해야 합니다.
- 시작한 작업 중 사람 개입 없이 완료된 비율
- 세션당 강제 재시작 횟수
- 429·5xx·stream disconnect 횟수
- context compaction 시간과 실패율
- 재시작 후 원래 작업을 복구한 비율
- 테스트 통과와 리뷰까지 끝낸 비율
- 사람이 수정한 코드량과 되돌린 변경량
이런 데이터가 있어야 “서비스 uptime”이 아니라 “업무 성공률”을 비교할 수 있습니다.
그림: 실무 안정성은 uptime 하나가 아니라 복구 가능성, 결과 품질, 사람의 재작업까지 함께 측정해야 한다.
왜 결국 Claude가 더 안정적이고 좋게 느껴질까
안정성을 단순히 프로세스가 한 번도 멈추지 않는 것으로 정의하면 Codex가 더 좋아 보이는 날이 있습니다. 그러나 실제 개발 업무에서는 다음 질문이 더 중요합니다.
한 번도 멈추지 않았는가?
보다
멈춰도 작업을 잃지 않았는가?
오래 실행됐는가?
보다
원하는 수준의 결과를 만들었는가?
Claude Code는 세션을 지속적으로 저장하고, --resume으로 복구하며, /compact, /clear, subagent로 컨텍스트를 관리할 수 있습니다. Claude의 코드 이해와 결과물이 자신의 업무 방식에 더 잘 맞는다면 중간 재시작 비용을 감수하고도 전체 생산성은 더 높을 수 있습니다.
결국 최근의 결론은 이렇습니다.
Codex는 더 오래 버티는 것처럼 보일 때가 있지만, Claude는 멈춘 뒤에도 작업을 복구하기 쉽고 결과에 대한 신뢰가 높아 결국 더 안정적이고 좋은 도구처럼 느껴진다.
이 결론은 모든 사용자에게 적용되는 객관적 순위가 아닙니다. 공개 통계만으로 어느 쪽이 더 안정적이라고 단정할 수도 없습니다. 다만 안정성을 “프로세스 uptime”이 아니라 “작업을 잃지 않고 원하는 결과까지 도달하는 능력”으로 정의하면, Claude를 계속 선택하는 이유가 설명됩니다.
Claude가 자주 죽을 때 사용하는 현실적인 운영법
마지막으로 실제 운영 방법을 정리하면 다음과 같습니다.
작업을 작게 나눈다
한 세션에서 조사, 구현, 대규모 테스트, 문서화까지 모두 처리하지 않습니다. 기능 경계마다 commit이나 checkpoint를 만들고 다음 세션으로 넘어갑니다.
큰 출력은 파일로 저장한다
수만 줄의 로그를 대화에 직접 넣지 말고 파일로 저장한 뒤 오류 부분만 검색하게 합니다.
pytest -vv > /tmp/test-output.log 2>&1
rg -n "FAILED|ERROR|Traceback" /tmp/test-output.log
자연스러운 시점에 직접 압축한다
작업이 끝난 뒤 다음 요청 전에 다음처럼 압축합니다.
/compact 구현된 파일, 남은 실패 테스트, 다음 단계만 유지
세션에 이름을 붙인다
/rename auth-refactor
멈춘 뒤에도 다음 명령으로 찾기 쉬워집니다.
claude --resume auth-refactor
상태 페이지와 로컬 진단을 분리한다
여러 세션이 동시에 실패하면 상태 페이지를 먼저 봅니다. 한 저장소에서만 재현되면 /doctor, /context, MCP와 hook 설정을 확인합니다.
결과 안정성을 직접 기록한다
Claude와 Codex를 같은 종류의 작업에 사용하고 완료율, 재시작, 테스트 통과, 수정량을 간단히 기록합니다. 체감은 중요하지만 기록이 있으면 어느 도구가 자신의 워크플로에 맞는지 더 빨리 판단할 수 있습니다.
마무리
Claude가 자꾸 죽는다는 느낌은 틀리지 않습니다. 실제 서비스 장애가 있었고, 공식 문서도 높은 CPU·메모리, hang, auto-compaction 문제를 인정하며 재시작과 resume을 대응 방법으로 안내합니다.
하지만 그것만으로 Claude가 덜 안정적인 도구라고 결론 내리기는 어렵습니다. Codex에도 overload, access denied, compaction latency, rate limit, Cloud task 실패가 있었고 두 회사가 동일한 기준의 uptime 통계를 공개하지도 않습니다.
그래서 실무에서의 안정성은 다음 식에 더 가깝습니다.
실무 안정성
= 서비스 가용성
+ 로컬 프로세스 안정성
+ 세션 복구 가능성
+ 결과 품질
+ 사람이 다시 해야 하는 작업의 양
이 기준으로 보면 Claude가 가끔 멈추더라도 세션을 복구해 좋은 결과를 계속 만들어 낸다면, 사용자에게는 결국 Claude가 더 안정적이고 좋은 도구일 수 있습니다.
참고 자료
'일반IT > AI' 카테고리의 다른 글
| Agent Skills 완전 정리 — 공개 사양부터 SKILL.md 실무 설계, skills.sh 보안까지 (0) | 2026.07.31 |
|---|---|
| MCP 서버는 실제로 어떻게 통신할까 — JSON-RPC, stdio, Streamable HTTP를 로우레벨에서 이해하기 (0) | 2026.07.30 |
| LLM은 이전 토큰을 어떻게 참고할까 — Q·K·V와 KV Cache의 동작 원리 (0) | 2026.07.30 |
| LLM의 응답 생성 원리 이해 — 토큰화와 컨텍스트 윈도우 (0) | 2026.07.28 |
| 생성형 AI 보안은 완벽한 통제가 아니라 피해 제한에서 시작된다 (0) | 2026.07.28 |
