5월 한 달, Claude는 열 번 넘게 장애를 냈다. 21일 오류가 난 다음 날 또 났고, Opus 4.7이 복구되는 사이 Haiku 4.5가 쓰러졌다. 디지털데일리 보도에 따르면 두 모델이 이달 가장 반복적으로 문제를 일으킨 모델로 꼽혔다. 그리고 이 장애가 반복될 때마다 나는 팀 채널에서 같은 질문을 받았다. "지금 Claude 안 돼요, 다른 거 써도 돼요?"
그 질문 자체가 문제다. 팀이 그 질문을 나한테 하고 있다는 건, 플랜 B가 개인의 머릿속에만 있다는 뜻이다. AI를 인프라로 쓰기 시작한 팀이라면 장애 대응은 이미 시스템 안에 설계되어 있어야 한다. 국가AI전략위원회 산업AX 분과 송호철 위원이 정확히 짚었다. "한 회사, 한 모델에만 의존하는 구조는 그 서비스가 멈추는 순간 전체가 멈추는 단일장애점(SPOF)이 된다." AI가 기능이 아니라 인프라가 된 순간, 의존성 관리는 선택이 아니라 설계 의무다.
그런데 여기서 멈추면 얕은 진단이다. 멀티모델 전략, 즉 Claude가 죽으면 GPT-4o로 전환한다는 플랜은 필요하지만 충분하지 않다. 진짜 리스크는 장애보다 훨씬 조용한 곳에서 온다. dev.to에 올라온 'Shadow Manager' 분석이 이걸 잘 보여준다. AI 에이전트가 ERP, 구매 승인, 인벤토리 워크플로우 안으로 들어오는 순간, 그 시스템은 더 이상 '어시스턴트'가 아니다. 리드 우선순위를 정하고, 구매 경로를 설정하고, 리스크를 분류한다. 최종 승인은 여전히 사람이 하지만, 그 사람이 보는 선택지의 구조는 이미 AI가 만든 것이다. 이걸 논문에서는 '보이지 않는 위임(invisible delegation)'이라 부른다. 권한은 워크플로우 안으로 이동했지만 책임은 여전히 사람에게 남아 있는 구조.
여기에 아키텍처 선택이 끼어든다. dev.to의 Copilot vs Agent 아키텍처 분석이 실용적으로 유용한 이유가 여기 있다. 코파일럿은 사람이 루프 안에 있다. 제안하고 기다린다. 에이전트는 목표를 받으면 스스로 계획을 짜고, 툴을 호출하고, 시스템 상태를 바꾼다. 코파일럿의 잘못된 제안은 개발자가 탭을 안 누르면 그만이다. 에이전트의 잘못된 판단은 구매 발주가 나가고 나서야 보인다. 아키텍처 결정이 곧 리스크 모델 결정이라는 얘기다.
그렇다면 AI-First 팀이 지금 설계해야 할 것은 무엇인가. 세 층위로 나눠 생각한다.
첫째, 모델 추상화 레이어를 코드베이스에 박아라. 특정 모델 API에 직접 붙지 말고 중간 레이어를 둬야 한다. Claude가 죽었을 때 GPT-4o로 라우팅하는 게 설정 파일 한 줄 수준이어야 팀이 그 질문을 나한테 안 한다. LiteLLM이든 자체 래퍼든, 모델 교체가 코드 수정 없이 가능한 구조가 기본값이 되어야 한다.
둘째, 에이전트에 위임하는 권한의 경계를 명시적으로 설계하라. 에이전트가 '제안'을 넘어 '실행'으로 들어오는 지점을 팀이 명확히 인식해야 한다. 워크플로우 어디서부터 에이전트가 시스템 상태를 바꿀 수 있는지, 그 경계에 휴먼 게이트를 둘 것인지를 기능 설계 전에 결정해야 한다. 코파일럿 패턴이 맞는 곳에 에이전트를 밀어 넣는 순간 shadow manager 리스크가 시작된다.
셋째, AI 장애를 인프라 장애로 취급하는 운영 문화를 만들어라. LLM 서비스 상태 페이지를 모니터링 대시보드에 붙이고, 오류율 임계치에서 알림이 오도록 해야 한다. 장애 발생 시 fallback 모델로 자동 전환되는 로직이 있더라도, 그 전환이 언제 일어났는지 팀이 추적할 수 있어야 품질 이슈를 나중에 디버깅할 수 있다.
솔직히 말하면, 지금 대부분의 AI-First 팀은 이 세 가지 중 하나도 제대로 갖추지 못한 채 달리고 있다. Claude가 빠르고 좋으니까 거기 전부 걸고, 잘 되는 동안은 아무도 의존성 구조를 따지지 않는다. 장애가 나면 그때 허둥댄다. 5월의 Claude 장애 패턴이 경고하는 건 단순히 '앤트로픽 인프라가 불안정하다'가 아니다. AI를 진지하게 쓰는 팀일수록, 단일 모델 의존성이 쌓이는 속도가 빠르다는 것이다.
앞으로 이 문제는 더 복잡해진다. 에이전트가 워크플로우 깊숙이 들어올수록, 어느 모델이 어느 판단에 개입했는지 추적하기 어려워진다. 멀티모델 전략이 fallback 용도에서 시작해 성능 최적화, 비용 분산, 역할 분리로 확장될수록 오케스트레이션 복잡도도 함께 올라간다. 그 복잡도를 다루는 설계 역량이, 앞으로 AI-First 팀의 실질적인 경쟁력 차이를 만들 것이다. 지금 당장 시작할 수 있는 건 단순하다. 팀 코드베이스에서 특정 모델 API가 직접 노출된 곳을 전부 찾아내는 것. 그게 의존성 지도의 첫 번째 줄이다.