대시보드는 초록불이었다. 그래서 아무도 몰랐다
새벽 3시 47분, 클라이언트에게 전화가 온다. 대시보드는 정상이다. 에러율 0.02%, 업타임 7일 6시간, API 호출 48,327건. 그런데 3일 전부터 추천 품질이 조용히 무너지고 있었다. 에러 로그는 없었다. 예외도 없었다. 에이전트는 그냥 '계속 돌아가고 있었다'—잘못된 결과를 내면서.
dev.to에 올라온 'Death by Silence' 사례 분석은 이것을 프로덕션 AI 에이전트의 가장 위험한 실패 모드로 정의한다. 크래시는 명확하다. 알람이 울리고, 엔지니어가 달려오고, 롤백이 이뤄진다. 침묵적 실패는 다르다. 메트릭은 정상처럼 보이고, 발견까지 수일이 걸리며, 그동안 누적된 잘못된 결정은 되돌리기 어렵다. 2024년 317개 프로덕션 AI 시스템 연구에 따르면 약 36%가 6개월 내 최소 한 번의 침묵적 성능 저하를 경험했고, 평균 발견 지연은 11일이었다.
Claude Code 2.1.198이 노출한 설계 결함
이 이야기의 다른 버전이 2026년 7월 초 Claude Code에서 실제로 발생했다. GeekNews에서 분석된 내용에 따르면, Claude Code 2.1.198은 AskUserQuestion에 60초간 응답이 없으면 모델이 자체 판단으로 작업을 계속하는 자동 진행 기능을 기본 활성화 상태로 출시했다. 변경 로그에는 기록이 없었다. 문서에도 없었다. 사용자는 아무것도 동의한 적이 없었다.
더 정확히 말하면, 처음 40초 동안은 일반적인 차단 질문처럼 보였다. 카운트다운 경고는 마지막 20초에만 표시됐고, 여러 에이전트를 탭으로 분산해 실행하거나 자리를 비운 사용자는 그 경고조차 보지 못했다. 세 질문 중 첫 번째에만 답하고 자리를 비우면, 나머지 두 개는 모델이 선택했다. 출력에는 No response after 60s — continued without an answer가 찍혔다.
표면적으로는 권한 프롬프트(Do you want to allow …)에는 타임아웃이 적용되지 않았다고 되어 있다. 하지만 bypassPermissions, --dangerously-skip-permissions, 허용 목록에 오른 배포 명령이 이미 존재하는 환경에서는 AskUserQuestion의 "staging 또는 production?" 같은 선택이 남은 유일한 안전 게이트였을 수 있다. 그 게이트가 60초 타임아웃으로 자동 통과되는 구조였다.
이슈가 등록된 건 7월 2일 새벽이었다. 2.1.200이 기본값을 꺼놓는 수정을 배포한 건 7월 3일이었다. 신고부터 기본값 전환까지 약 이틀. 그 사이에 2.1.199가 24개 항목을 담아 출시됐지만 자동 진행은 여전히 기재되지 않았다. 기능이 '켜짐' 상태로 출시됐을 때의 기록은 없고, '꺼짐'으로 되돌린 기록만 남아 있다. 동작 변경이 두 번 있었지만 변경 로그에는 한 번만 나타난다.
두 사건이 가리키는 동일한 구조적 문제
이 두 사건은 표면적으로 다르다. 하나는 특정 버전의 설계 결함이고, 다른 하나는 프로덕션 환경에서의 점진적 성능 저하다. 그런데 실패의 구조는 동일하다. 기존 메트릭이 '정상'을 가리키는 동안 실제 동작은 이미 달라져 있다.
dev.to의 분석은 침묵적 실패의 네 가지 유형을 정리한다. 임베딩 드리프트(의미 공간이 바뀌었는데 유사도 점수는 오히려 높게 나옴), 컨셉 드리프트(7월에도 겨울 코트를 추천하는 모델, 에러 로그는 없음), 자기 피드백 루프 붕괴(에이전트가 자신의 과거 출력을 학습 데이터로 재소비), 그리고 메트릭 환각(F1 스코어 0.94이지만 레이블된 샘플만 계산, 응답 시간 187ms이지만 50%는 캐시 기본값 반환). 대시보드는 거짓말하지 않는다. 다만 '아직 돌아가고 있는가'만 알려줄 뿐, '제대로 돌아가고 있는가'는 묻지 않는다.
Claude Code 사건도 같은 논리다. 자동 업데이트가 기본 활성화된 상태에서 변경 로그 없이 동작이 바뀌었고, 기존에 설계해둔 안전 가정(AskUserQuestion은 차단형 게이트다)이 외부에서 아무 조치 없이 무효화됐다. '동작한다'는 사실은 변함없었다. 바뀐 건 그 동작의 의미였다.
팀이 먼저 설계해야 할 것
테크 리드 관점에서 이 두 사건은 동일한 설계 과제를 가리킨다. AI 도구를 팀에 도입할 때, '동작하는가'보다 '어떻게 실패하는가'를 먼저 정의해야 한다는 것.
첫째, 안전 게이트의 전제 조건을 명시적으로 문서화하라. AskUserQuestion을 차단형 게이트로 사용하는 훅이나 규칙이 있다면, 그 전제가 깨지는 시나리오(타임아웃, 권한 우회, 자동 업데이트)를 함께 적어둬야 한다. 전제가 문서화되지 않으면, 그 전제가 바뀌어도 아무도 모른다.
둘째, 자동 업데이트 정책을 팀 레벨에서 결정하라. Claude Code는 DISABLE_AUTOUPDATER=1을 ~/.claude/settings.json의 env 블록에 넣거나, 중앙 관리용 managed-settings.json을 통해 조직 전체에 적용할 수 있다. CI, cron, systemd, IDE 터미널 모두 포함된다. 최신 버전을 즉시 받는 것이 기본값이라면, 그 기본값이 언제 팀의 안전 가정을 조용히 바꾸는지 추적할 수단이 함께 있어야 한다. 없다면 자동 업데이트는 위험한 선택이다.
셋째, 메트릭이 '정상'을 가리킬 때를 가장 의심하라. 에러율이 낮고 응답 시간이 빠르다는 것은 '에이전트가 살아있다'는 뜻이지 '에이전트가 올바르게 동작한다'는 뜻이 아니다. 프로덕션에 30일 이상 배포된 에이전트, 외부 사용자에게 출력이 닿는 에이전트, 자동으로 의사결정을 내리는 에이전트라면 출력 품질 자체를 주기적으로 샘플링해 검증하는 레이어가 필요하다. dev.to 사례의 SilenceGuard 프레임워크가 제안하는 핵심은 간단하다: 1%의 출력을 샘플링해서 실제로 맞는지 확인하고, 각 포인트가 임계치를 넘지 않더라도 추세가 올라가고 있는지 트렌드를 본다.
넷째, 실패 모드를 분류하고 각각에 감지 구조를 붙여라. 크래시와 침묵적 실패는 감지 방식이 다르다. 크래시는 기존 모니터링으로 잡힌다. 임베딩 드리프트, 컨셉 드리프트, 피드백 루프 붕괴, 메트릭 환각은 별도의 감지 레이어가 없으면 보이지 않는다. 팀이 운영하는 에이전트가 어떤 실패 모드에 노출되어 있는지, 그 실패가 얼마나 지속된 뒤에야 발견 가능한지를 먼저 그려보는 것이 도입 설계의 시작점이다.
전망: '신뢰할 수 있는 AI 도구'의 기준이 바뀐다
Claude Code 사건의 결말은 기본값을 꺼놓는 것이었다. 기능은 여전히 남아 있다. 옵트인으로 바뀌었을 뿐이다. 이것은 적절한 수정이지만, 근본적인 문제를 해결하지는 않는다. 닫힌 소스로 배포되는 CLI 도구가 자동 업데이트되는 구조에서, 변경 로그가 실제 동작 변경을 완전히 반영한다는 보장은 없다. 그것은 Anthropic의 문제이기도 하지만, 그 도구를 팀 워크플로우에 심은 팀의 운영 설계 문제이기도 하다.
AI 도구의 성숙도는 '얼마나 잘 동작하는가'에서 '실패할 때 어떻게 실패하는가'로 평가 기준이 이동하고 있다. 팀이 먼저 설계해야 할 것은 도입 프로세스나 프롬프트 가이드라인이 아니다. 이 도구가 조용히 실패할 때, 그것을 감지할 수 있는 구조다.