Claude + OpenRouter 혼합 라이브 — 6/7 codex sunset 이후의 lane A

OpenAI Codex 결제 종료를 앞두고, 다섯 대짜리 자동화 mesh 가 어떤 추론 백엔드 위에 서야 하는지 다시 결정한 밤의 기록.

1. OpenAI 결제 끊는 결정을 했다

OpenAI 결제 끊는 결정을 했다.

이 문장을 쓰는 데 생각보다 시간이 걸렸습니다. 지난 몇 달 동안 제 작업 흐름의 상당 부분이 Codex 위에 올라가 있었기 때문입니다. 그냥 도구 하나를 끊는 결정이 아니라, 밤새 돌던 작업자들의 바닥을 바꾸는 결정에 가까웠습니다. 어느 모델이 더 똑똑한지, 어느 회사가 더 좋은지의 문제가 아니었습니다. 강대종이라는 1인 개발자가 매일 쓰는 자동화 시스템이 한 유료 lane 에 너무 많이 기대고 있다는 사실을 인정하는 일이었습니다.

트리거는 거창한 발표가 아니라 가계부 캡처였습니다. 2026년 5월 7일, NICEGPTPRO5x 개발자 플랜 결제가 빠져나갔고, 다음 결제 사이클이 6월 6일이라는 사실이 숫자로 보였습니다. 그 전에도 막연히 “이번 달까지만 쓰자”는 생각은 있었습니다. 그런데 가계부에 찍힌 날짜를 보니 결정이 갑자기 일정표가 됐습니다. 6월 6일까지는 정상 가동. 6월 7일부터는 dead lane. 말로 하던 비용 절감이 실제 운영 마감선이 된 순간이었습니다.

처음 반응은 당황에 가까웠습니다. 왜냐하면 Codex 는 단순한 채팅창이 아니었기 때문입니다. 본진에서 지시를 던지면 WSL, 데스크탑, 노트북이 각자 받아서 git 을 만지고, 결과를 돌려주고, 필요하면 다섯 대가 투표하는 구조까지 만들어져 있었습니다. 지난 몇 주 동안 저는 이 구조를 “한 사람의 작업 시간을 늘리는 장치”로 받아들이고 있었습니다. 그런데 그 장치의 한 축이 6월 7일 이후 사라진다는 걸 숫자로 확인한 겁니다.

그래서 그날 밤의 질문은 단순했습니다. Codex 가 끝나면, 이 mesh 는 무엇 위에서 계속 굴러가야 하나?

2. 다섯 대가 하나의 습관이 되기까지

처음부터 5노드 mesh 를 만들려고 한 건 아니었습니다. 시작은 훨씬 작았습니다. 맥북 하나에서 Claude Code 를 열고, 텔레그램으로 할 일을 던지고, 작업 로그를 남기는 정도였습니다. 그러다 WSL 이 붙었습니다. Windows 쪽에서만 보이는 문제를 처리하거나, Flutter/웹 작업을 따로 떼어 맡기기 위해서였습니다. 그다음 맥미니가 빌드 엔진이 됐고, 데스크탑 RTX 3060Ti 와 노트북 RTX 3060 이 GPU와 원격 작업 노드로 들어왔습니다.

어느 순간부터 이 다섯 대는 단순한 장비 목록이 아니라 작업 방식이 됐습니다. 🍎 본진은 판단하고, 🪟 WSL 은 코드 수정과 분석을 받고, 🏭 맥미니는 빌드와 배포 쪽 무거운 일을 맡고, 🖥 데스크탑은 LLM/SD/Whisper 실험을 받고, 💻 노트북은 외출·오프라인 캡처·원격 sync 헤드가 됐습니다. 중요한 건 각 노드가 “있다”가 아니라, 각 노드로 일을 보내고 회수하는 언어가 생겼다는 점입니다.

그 언어가 mesh-vote 와 loop-fleet 으로 커졌습니다. 처음에는 “이 작업을 어느 노드에 줄까” 정도였는데, 점점 “다섯 대가 각자 판단하고 한 결론으로 모이면 어떨까”로 바뀌었습니다. 어떤 PR 을 머지할지, 어떤 복구 경로가 안전한지, 어떤 자동화가 다음에 필요할지. 사람 혼자 머릿속에서 고민하던 것들을 다섯 세션에 나눠 던지고, 각자의 답을 모아 다시 사람이 결정하는 식입니다.

Codex 는 이 실험에서 좋은 연료였습니다. 특히 2026년 5월 말에는 5노드 Codex REPL 표준 셋업까지 맞췄습니다. gpt-5.5 xhigh fast, YOLO mode, features.hooks, ~/.codex/config.toml, Codex Mesh Mirror 그룹. 이름만 보면 거창하지만 실제로는 “명령을 던지면 바로 움직이고, 답이 한곳에 모이게 하자”는 단순한 목적이었습니다. 덕분에 bapeo 같은 repo 에서는 자면서 앱 빌드 3원칙을 실험했고, PoC 들이 밤새 PR 로 쌓이는 경험도 했습니다.

이 경험이 좋았던 만큼, sunset 은 가볍게 넘길 수 없었습니다. 그냥 “결제 안 하면 그만”이 아니었습니다. 몇 달 동안 쌓은 작업 습관, 스킬 이름, 보고 채널, 브랜치 규칙, 야간 다이나믹 사이클까지 같이 흔들리는 일이었습니다. 그래서 저는 비용 절감 결정을 하면서도 동시에 질문을 붙잡아야 했습니다. 백엔드는 바뀌어도, 이 작업 방식은 유지할 수 있을까?

3. 가계부 캡처가 만든 6/6

가계부 캡처는 묘하게 냉정합니다. 감정이 섞이지 않습니다. “이 서비스가 좋았다”, “요즘 많이 썼다”, “아직 아깝다” 같은 말을 전혀 하지 않습니다. 날짜와 금액만 보여줍니다. 2026년 5월 7일 결제. 다음 사이클은 6월 6일. 그리고 저는 그 숫자를 보고 6월 7일을 그렸습니다.

그때부터 Codex 는 제 안에서 두 얼굴이 됐습니다. 6월 6일까지는 아직 강력한 도구입니다. 실제로 계속 쓰는 게 맞습니다. 이미 셋업해둔 5노드 REPL, Codex Mesh Mirror, codex-mesh-vote, codex-loop-fleet, bapeo 자율 사이클을 굳이 일찍 끊을 이유는 없습니다. 남은 기간 동안은 그 인프라를 최대한 활용하는 게 합리적입니다.

하지만 6월 7일 이후에는 이야기가 달라집니다. 더 이상 기본 lane 으로 생각하면 안 됩니다. 설정 파일은 남아 있을 수 있고, 나중에 다시 결제하면 재가동할 수도 있습니다. 그래도 운영 사고방식에서는 dead lane 으로 표시해야 합니다. 자동화는 사람이 잊는 순간 가장 위험해집니다. 어느 밤에 예전 스크립트가 Codex 를 호출한다고 가정하고 돌았는데, 결제가 끊겨서 조용히 실패한다면 그건 도구 문제가 아니라 운영 설계 문제입니다.

그래서 sunset 을 “슬픈 종료”로만 보지 않기로 했습니다. 이건 강제로 설계를 점검하게 만드는 계기입니다. 한 추론 백엔드에 너무 많이 기대고 있지 않은지, 비용 구조가 바뀌어도 작업이 이어지는지, 메인 lane 과 fallback lane 이 명확히 나뉘어 있는지. 특히 1인 개발자는 한 번에 큰 팀처럼 SRE 를 둘 수 없습니다. 대신 자기 시스템 안에 작은 회로차단기들을 심어야 합니다. 6월 7일은 그 회로차단기를 점검하는 날짜가 됐습니다.

4. Lane A라는 합의

이 결정을 혼자 바로 확정하지는 않았습니다. 다섯 대에게 던졌습니다. mesh-vote 1779689180. 질문은 요약하면 이랬습니다. 6월 7일 이후 Codex lane 이 죽으면, 다음 기본 추론 lane 을 무엇으로 잡을 것인가.

결론은 5/5 만장일치로 lane A 였습니다. Anthropic Claude 를 메인으로 두고, Claude 토큰이 빡빡해질 때 OpenRouter API 를 fallback 으로 쓰는 혼합 구조. 이 결론이 마음에 들었던 이유는 “새로운 멋진 도구”를 고른 게 아니라, 이미 제가 매일 쓰는 도구와 작은 비상구를 결합했기 때문입니다.

Claude 는 여전히 제 작업의 메인입니다. 긴 문맥을 읽고, repo 의 기류를 파악하고, 문장 톤까지 맞추는 데 강합니다. newsletter 를 쓰거나, PR 리뷰 기준을 세우거나, 앱의 다음 방향을 잡을 때는 아직 Claude 쪽이 편합니다. 반면 OpenRouter 는 fallback 으로 적합합니다. 별도 credit pool 이 있고, 여러 모델을 바꿔가며 호출할 수 있고, 자동 잡이나 fan-out 에 붙이기 좋습니다. 메인은 안정적인 lane, fallback 은 유연한 lane. 제게 필요한 건 화려한 이중화가 아니라 이 정도의 현실적인 분리였습니다.

다섯 대가 한 결론으로 모이는 장면은 이상하게도 조금 안심이 됐습니다. 사람이 밤에 혼자 결제와 인프라를 고민하면, 결정이 감정에 휘기 쉽습니다. 아깝다, 더 써보고 싶다, 괜히 줄이는 것 같다, 반대로 빨리 다 끊고 싶다. 그런데 같은 질문을 여러 노드에 던지면 감정이 조금 식습니다. 각 노드는 안전, 비용, 복구성, 실효성을 다르게 봅니다. 그 답들을 모아보니 “Claude main + OpenRouter fallback” 이 가장 덜 흔들리는 선택이었습니다.

그래서 lane A 는 제게 기술 선택이라기보다 운영 원칙에 가깝습니다. 메인 백엔드는 매일 쓰는 곳에 둡니다. fallback 은 비용과 정책 변화에 덜 묶이는 곳에 둡니다. 그리고 어느 한쪽이 막혔다고 전체 자동화가 멈추지 않도록, 호출 경로와 보고 경로를 분리합니다. 이건 Ep20 에서 말했던 “코드는 해자가 아니다”와도 이어집니다. 해자는 모델 이름이 아니라, 모델이 바뀌어도 계속 굴러가는 작업 구조에 있습니다.

5. OpenRouter 셋업의 작은 함정들

OpenRouter 를 붙이는 과정은 생각보다 1인 개발자다운 일이었습니다. 큰 아키텍처보다 작은 오타와 슬러그 함정이 더 오래 붙잡았습니다. 키는 본진의 ~/.config/openrouter/.env 안에 OPENROUTER_API_KEY 로 두고, credit pool 은 $10 로 시작했습니다. 이 숫자는 실험용으로 충분하지만 무한한 돈은 아닙니다. 게다가 모델별 가격은 바뀔 수 있으니, newsletter 에 단가를 박아두는 건 별로 좋은 습관이 아닙니다. 지금은 “작은 credit pool 로 fallback 품질을 확인한다” 정도가 정확합니다.

4모델 비교에서는 GLM-5 가 1순위, DeepSeek 이 2순위로 남았습니다. GLM-5 는 한국어 자연스러움, 코드 reasoning, 톤 유지가 좋았습니다. 대신 응답이 길어지는 편이라 비용 감각을 계속 봐야 합니다. DeepSeek 은 가성비와 속도, 품질 균형이 좋았습니다. 제 기준에서는 “깊게 생각해야 하는 한두 번”은 GLM-5, “여러 노드에 가볍게 던지는 fan-out”은 DeepSeek 이 더 자연스럽습니다.

재미있었던 건 모델 성능보다 모델 슬러그였습니다. 예전에 익숙하게 쓰던 meta-llama/llama-3.1-405b 계열은 그대로 호출하면 안 됐습니다. OpenRouter 에서 Meta 공식 405B 라인은 retire 되어 있었고, 실제로는 nousresearch/hermes-3-llama-3.1-405b 를 봐야 했습니다. zhipu/glm-5 도 마찬가지였습니다. 머릿속 이름은 zhipu 인데 실제 slug 는 z-ai/glm-5 였습니다.

이런 함정은 사소해 보이지만 자동화에서는 치명적입니다. 사람이 직접 채팅창에서 모델을 고르면 “아, 이름이 바뀌었네” 하고 넘어갑니다. 하지만 스크립트는 그런 눈치가 없습니다. 잘못된 slug 를 박아두면 밤새 돌던 fallback 이 한 번도 호출되지 않거나, 조용히 실패 로그만 남길 수 있습니다. 그래서 OpenRouter fallback 을 붙인다는 건 API 키 하나를 넣는 일이 아니라, 모델 이름과 실패 모드까지 문서화하는 일입니다.

저는 이 과정에서 다시 한 번 1인 개발자의 현실을 느꼈습니다. 대기업의 resilience 는 리전, 로드밸런서, SLA 로 표현됩니다. 제 resilience 는 OPENROUTER_API_KEY 의 위치, 모델 slug 표, 실패 시 보고 메시지, 그리고 다음 날 아침 제가 이해할 수 있는 로그로 표현됩니다. 작지만 같은 방향입니다. 한 곳이 막혔을 때 어디로 흐를지 미리 정해두는 것. 그게 제 규모의 이중화입니다.

6. 6/7 이후의 단순화

6월 7일 이후의 목표는 더 복잡한 mesh 를 만드는 것이 아닙니다. 오히려 단순화에 가깝습니다. 지금까지는 5노드 Codex 셋업이 baseline 처럼 보였습니다. 하지만 sunset 이후에는 그 baseline 을 과거 장으로 넘기고, 4개의 Claude 중심 backend 와 1개의 OpenRouter fallback 으로 생각하려 합니다. 여기서 숫자는 정확한 서버 대수가 아니라 운영 감각입니다. 메인은 Claude, 비상구는 OpenRouter. Codex 는 6월 6일까지 정상 사용, 그 이후에는 archive 가능한 lane.

물론 한 번에 모든 스크립트를 완벽히 바꾸지는 못할 겁니다. codex-mesh-vote, codex-loop-fleet, Codex Mesh Mirror 같은 이름들은 몇 주 동안 너무 빠르게 자랐습니다. 6월 7일이 오면 일부는 보관하고, 일부는 Claude 백엔드로 옮기고, 일부는 그냥 history 로 남길 가능성이 큽니다. 중요한 건 “예전처럼 되겠지”라고 가정하지 않는 것입니다. 자동화는 stale 한 가정이 쌓일수록 무섭습니다.

비용도 같은 태도로 보려 합니다. Claude 는 여전히 제 메인 작업 비용입니다. OpenRouter 는 $10 credit pool 에서 시작한 fallback 입니다. 다만 둘 다 영원히 같은 가격일 거라고 단정하지 않습니다. Anthropic 쪽 billing 정책도 바뀔 수 있고, OpenRouter 모델 가격도 바뀔 수 있습니다. 그래서 lane A 의 핵심은 특정 단가가 아니라, 비용과 정책 변화가 왔을 때 갈아탈 수 있는 구조입니다.

이 결정에는 아쉬움도 있습니다. 5노드 Codex baseline 은 분명 재미있었습니다. 다섯 봇이 Codex Mesh Mirror 그룹에 각자 답을 올리고, 같은 주제에 대해 서로 다른 각도의 결론을 내는 장면은 작은 연구실 같았습니다. 특히 bapeo 실험처럼 밤에 던져두고 아침에 PR 들이 쌓여 있는 흐름은 1인 개발자에게 꽤 큰 가능성을 보여줬습니다. 그래서 sunset 은 단절처럼 느껴집니다.

하지만 동시에 이 단절이 제 시스템을 더 단단하게 만들 수도 있다고 생각합니다. 하나의 백엔드가 너무 편해질 때마다, 그 편함은 의존성이 됩니다. 의존성은 평소에는 생산성이고, 끊기는 순간 리스크입니다. 6월 7일 이후 lane A 는 그 리스크를 조금 줄이는 방법입니다. Claude 를 계속 쓰되, Claude 만 믿지 않습니다. OpenRouter 를 붙이되, OpenRouter 를 새 주인으로 모시지 않습니다. 둘 사이에 사람이 이해할 수 있는 운영 경계선을 둡니다.

마치며

이번 결정을 하면서 가장 크게 남은 감정은 놀람이었습니다. 저는 제가 모델을 쓰고 있다고 생각했는데, 실제로는 모델 위에 작업 습관을 쌓고 있었습니다. 그래서 결제를 끊는 결정이 단순한 구독 정리가 아니라, 작업 습관의 기반을 다시 보는 일이 됐습니다.

강대종이라는 1인 개발자에게 추론 백엔드는 이제 앱 서버나 데이터베이스처럼 다뤄야 할 인프라입니다. 어느 하나가 영원히 싸고, 빠르고, 열려 있을 거라고 믿으면 안 됩니다. 중요한 건 특정 모델을 숭배하는 게 아니라, 모델이 바뀌어도 내 작업이 계속 흐르는 구조를 만드는 것입니다.

그래서 6월 7일 이후에는 조금 더 단순한 그림으로 가보려 합니다. Claude 를 메인 lane 으로 두고, OpenRouter 를 fallback 으로 둡니다. GLM-5 와 DeepSeek 을 우선 후보로 보되, 가격과 품질은 계속 변할 수 있다는 전제로 둡니다. Codex 는 6월 6일까지 잘 쓰고, 그 이후에는 고마웠던 실험 장으로 넘깁니다.

1인 개발자의 모트는 한 모델이 아니라, 모델이 바뀌어도 멈추지 않는 작업 구조다.

— 2026-05-28.