Claude 사용량이 막혔을 때 Codex로 이어받는 1인 개발 워크플로우

Claude를 메인 구현 도구로 쓰다 보면 속도는 확실히 좋아져요. 그런데 사용량이 다 찼거나 일시적으로 호출이 안 되면, 그 순간 회사 전체가 멈춘 것처럼 느껴질 때가 있어요. 혼자 운영하는 작은 시스템일수록 더 그래요. 사람이 한 명이고, 자동화도 한 대의 로컬 컴퓨터에 모여 있으니까요.

이번에 바꾼 핵심은 단순해요. Claude가 가능하면 먼저 일하고 Claude가 막히면 Codex가 이어받습니다. 둘 다 막히면 자동으로 멈추고요. 이런 구조예요.

한 모델에 모든 책임을 두지 않기

처음에는 Claude가 구현하고 Codex가 리뷰하는 방식이 자연스러웠어요. 역할도 분명했어요.

• Claude: 빠르게 구현하는 손
• Codex: 결과를 의심하고 검토하는 눈

이 분리는 여전히 맞아요. 다만 운영 관점에서는 한 가지 구멍이 있었어요. Claude가 한도에 걸리면 "손"이 사라지고, Codex는 리뷰 역할에만 묶여 있어서 실제 일을 이어받지 못했어요. 구조상 Codex가 충분히 처리할 수 있는 작업도, 규칙이 없어서 멈추는 거죠.

그래서 구현 역할과 검토 역할을 고정된 이름이 아니라 상태에 따라 이동할 수 있는 책임으로 바꿨어요. 기본은 Claude가 구현하지만, Claude가 실패하면 Codex가 구현까지 맡습니다.

fallback은 안전 우회가 아니에요

중요한 건 fallback이 "검증을 건너뛰는 길"이 아니라는 점이에요. Claude가 막혔다고 해서 아무 모델이나 결과를 내고 자동 완료시키면 위험해요.

그래서 저는 provider runner를 따로 두었어요. 이 runner는 프롬프트를 받고 순서대로 provider를 시도합니다.

1. Claude 호출
2. 실패하면 Codex 호출
3. 둘 다 실패하면 rc=2로 종료

여기서 rc=2가 중요해요. 시스템이 "대충 됐다"고 말하지 않고, 지금은 처리할 수 없다고 명확히 멈추는 신호니까요. 자동화에서 제일 피하고 싶은 건 조용한 실패예요. 실패했는데도 noop처럼 보이면, 사람은 한참 뒤에야 문제를 봅니다.

Codex가 만든 결과를 Codex가 바로 승인하지 않기

또 하나의 경계가 있어요. Codex가 fallback으로 구현한 결과를 같은 Codex가 다시 평가해서 자동 close하면, 구현자와 검토자가 사실상 같아져요. 그래서 기본값은 이 경우 자동 완료를 막고 사람 검토로 올리게 했어요.

Claude가 만들고 Codex가 검토하는 경우에는 독립성이 어느 정도 생깁니다. 반대로 Codex가 만들었고 Codex만 검토할 수 있다면, 그건 독립 검토라고 보기 어려워요. 이때는 자동화가 멈추는 게 맞아요.

저는 이 원칙을 이렇게 정리했어요.

• Claude 생성 + Codex 평가: 자동 close 가능
• Codex 생성 + Codex 평가: 기본은 human review
• Claude와 Codex 모두 실패: 작업 중단 및 알림

조금 느려도 이 구조가 더 낫습니다. 1인 개발에서 자동화의 목표는 사람을 완전히 빼는 게 아니라, 사람이 봐야 할 순간만 선명하게 남기는 것이니까요.

하드코딩을 줄여야 하는 이유

이번 문제의 원인 중 하나는 "Claude를 호출한다"가 여러 스크립트에 흩어져 있었다는 점이에요. claude -p가 여기저기 박혀 있으면 나중에 Codex fallback을 붙이려 할 때 전부 찾아 바꿔야 해요. 더 나쁜 건, 어떤 곳은 바꿨는데 어떤 곳은 그대로 남는 상태예요.

그래서 직접 호출을 llm-runner.sh 하나로 모았어요. 각 스크립트는 더 이상 "Claude를 어떻게 부를지" 알 필요가 없고, runner에게 "이 프롬프트를 처리해줘"라고만 말합니다. provider 순서, timeout, sandbox 같은 정책은 runner와 환경변수에서 조절해요.

하드코딩은 전부 나쁘다고 말하긴 어려워요. 안전상 절대 바뀌면 안 되는 값은 코드에 고정하는 편이 맞을 때도 있어요. 예를 들어 위험 라벨 목록처럼 환경변수로 바뀌면 안전 경계가 약해지는 값은 hardcoded safety set이 더 낫습니다.

하지만 provider 이름, 모델 선택, timeout, 실행 모드처럼 운영 중 바뀔 수 있는 건 하드코딩보다 설정으로 빼는 게 좋아요. 그래야 장애가 났을 때 코드를 뜯지 않고 경로만 바꿀 수 있어요.

혼자 운영할수록 멈추는 기준이 필요해요

이번에 얻은 결론은 하나예요.

자동화는 계속 달리는 힘보다, 제대로 멈추는 기준이 먼저 있어야 해요.

Claude가 되면 Claude로 가고, 안 되면 Codex로 이어받고, 둘 다 안 되면 멈추기. 단순하지만 이 구조가 있어야 24시간 돌아가는 1인 회사가 한 모델의 사용량에 묶이지 않아요.

저는 라이프케어로그를 만들면서 이런 운영 실수를 계속 줄여가고 있어요. 작은 도구를 만드는 일도 결국은 작은 운영 체계를 만드는 일이더라고요.