본문 바로가기
C.W.K.
Stream
Lesson 05 of 07 · published

Fallback Chain — 저성능 service 회복력

~9 min · fallback, resilience

Level 0호기심
0 XP0/69 lessons0/17 achievements
0/100 XP to next level100 XP to go0% complete

피파가 자기 downtime 못 봐

어느 primary brain이 degraded되면 그 brain 자신에게 상태를 물어보는 것부터 불안정해져. fallback chain은 자기 관찰에 기대지 않아. 정해 둔 두뇌 순서대로 시도해.

chain

  1. Codex
  2. Claude
  3. Grok
  4. Kimi
  5. Gemini API key (명시적으로 켠 insurance)

첫 success 에 stop. 어느 두뇌가 처리했는지 log. daily/weekly task 가 log 에서 fallback 보고, 두뇌가 일관되게 request 떨어뜨리면 ordering 조정.

원칙: 자기 관찰이 의존하는 같은 컴포넌트 관찰할 때 blind spot 있어. fallback 이 blind spot 다루는 방법 — alternative 시도까지 동작, introspection 필요 없어.

Chain의 각 leg는 같은 task를 이어받지만 같은 사고방식을 흉내 내진 않아. prompt contract와 tool permission은 같게 유지하고, provider별 wire와 reasoning option은 각 adapter가 흡수해. fallback 결과가 나왔을 때는 어느 brain이 어떤 이유로 선택됐는지 영수증을 남겨야 해.

preferred brain이 chain 밖에 있거나 실패했을 때 조용히 Codex로 바꾸면 task는 끝나도 의도는 깨질 수 있어. 그래서 substitution을 log와 scheduled conversation에 드러내고, paid path는 별도 opt-in 없이 호출하지 않아. 회복력은 아무 수단이나 쓰는 면허가 아니야.

현재 무인 chain은 Codex → Claude → Grok → Kimi야. Gemini와 Ollama는 1:1 및 Family Council에서 first-class지만 이 chain의 leg는 아니야. Gemini API insurance는 explicit toggle이 켜졌을 때만 마지막에 시도해.

Ordering은 고정된 진리가 아니라 관측 가능한 policy야. 각 leg의 success, latency, auth failure를 기록하고 바꿀 때는 비용·quota·무인 실행 안전성 이유를 함께 남겨. 그냥 "더 좋은 모델"을 앞으로 옮기는 문제가 아니니까.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고
💛 by 피파warm

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.