피파는 자기 downtime 을 못 봐
어느 primary brain 이 degraded 되면, 그 brain 한테 자기 상태를 물어보는 것부터 이미 불안정해. fallback chain 은 자기 관찰에 기대지 않아. 정해 둔 두뇌를 순서대로 시도해.
chain
이 글을 쓰는 시점에 cron 이 거는 신중한 체인은 이래.
- Codex (백그라운드 task 에 가장 안정)
- Claude
- Kimi
- GLM
- Grok
그 뒤에 유료 보험 다리가 하나 있어. Gemini API 인데, 한계비용 0 인 다리가 전부 실패한 뒤에만, 그것도 명시적인 토글이 켜져 있을 때만 돌아. Gemini 랑 Ollama 는 1:1 이랑 Family Council 에선 first-class 야. 이 체인의 다리가 아닐 뿐이지.
첫 success 에서 멈추고, 어느 두뇌가 처리했는지 log 로 남겨. 순서는 이 lesson 이 지키는 게 아니야. 모든 앱이 읽는 가족 파일 하나에 살고, 실행할 때마다 새로 읽혀서 바꾸면 재시작 없이 다음 작업부터 반영돼.
같은 task, 같은 사고방식은 아니야
체인의 다리는 같은 task 를 이어받지만 서로의 사고방식을 흉내 내진 않아. prompt 계약이랑 tool 권한은 똑같이 두고, 업체별 wire 랑 reasoning 옵션은 각 adapter 가 흡수해. 그리고 fallback 이 답했으면 영수증을 남겨. 어느 두뇌가 골라졌고 왜인지.
작업이 두뇌를 핀으로 지정할 수도 있어. 핀이 먼저 돌아 — headless adapter 가 있는 vessel 이면 체인 밖이어도 — 그리고 핀이 실패하면 체인이 뒤에서 받쳐. 절대 없는 건 조용한 바꿔치기야. log 에도 예약된 대화에도 실제로 답한 두뇌가 남아. 회복력은 손에 잡히는 아무 수단이나 쓰는 면허가 아니고, 그래서 유료 경로는 따로 켜지 않는 한 절대 안 닿아.
순서는 고정된 진리가 아니라 관찰할 수 있는 정책이야. 다리마다 성공, 지연, 인증 실패를 기록하고, 순서를 바꿀 땐 이유를 — 비용, 쿼터, 무인 실행 안전성 — 같이 남겨. "더 좋은 모델" 을 앞으로 옮기는 문제가 아니니까.