공급사는 조용히 바꾸고, 팀은 나중에 청구서로 안다
지난 4월, Claude Code를 헤비하게 쓰는 개발자들 사이에서 이상한 일이 벌어졌다. API 비용이 갑자기 두 배 가까이 뛰었는데, Anthropic의 공식 changelog에는 아무것도 없었다. dev.to에 올라온 실측 데이터가 실마리를 제공했다. 4월 9일을 기점으로 Claude Code의 서브 에이전트 캐시 TTL이 1시간에서 5분으로 조용히 고정된 것이다. 17일 연속, 15,727건의 API 호출, 1시간 TTL 기록은 단 한 건도 없었다.
숫자만 보면 단순한 설정 변경처럼 보인다. 하지만 서브 에이전트 워크플로우의 특성을 감안하면 이야기가 달라진다. 서브 에이전트는 LLM 응답을 기다리고, 툴 결과를 파싱하고, 다음 턴으로 넘어가는 과정에서 자연스럽게 5분 이상의 공백이 생긴다. TTL이 5분이면 매 턴마다 캐시를 다시 쓰게 된다. 실측 비용 계산을 해보면 이렇다: 기존 1시간 TTL 기준으로 총비용이 2.4배수였다면, 5분 TTL로 바뀐 후엔 5.1배수다. 무거운 서브 에이전트 파이프라인을 돌리던 팀이라면 $10짜리 작업이 $21이 됐다는 뜻이다.
Anthropic이 버그를 인정했다—하지만 그건 또 다른 문제를 드러낸다
같은 시기, Anthropic은 4월 23일 기술 보고서를 통해 Claude의 성능 저하를 공식 인정했다. 모델 자체의 문제가 아니라 운영 레이어의 변경이 원인이었다고 밝혔다. 세 가지였다. 3월 초 추론 설정을 'high'에서 'medium'으로 낮춘 것, 3월 말 캐싱 버그로 thinking trace가 매 요청마다 리셋된 것, 4월 중순 중간 툴 응답을 25단어, 최종 응답을 100단어로 제한한 것.
팀 입장에서 이 공식 인정이 안심 신호가 아니라는 점을 짚고 싶다. 문제가 수정됐다는 사실보다, 이 세 가지 변경이 사전 공지 없이 배포됐다는 사실이 더 중요하다. Anthropic은 내부 테스트 강화와 투명성 개선을 약속했지만, 팀 입장에서 공급사의 약속을 신뢰 체계의 기반으로 삼는 건 위험하다. 오늘 약속한 투명성이 다음 릴리즈에 지켜진다는 보장이 없다.
감사 시스템이 자기 오류를 잡았다—그리고 그게 핵심 교훈이다
같은 주에 dev.to에 올라온 또 다른 글이 이 맥락과 정확히 맞물린다. AI 생성 코드를 감시하는 거버넌스 시스템 CORE를 만들던 개발자가 감사 룰이 작동하지 않는다는 진단을 내렸다. 그런데 그 진단이 틀렸다. 감사 룰은 제대로 작동하고 있었다. 문제는 진단 과정에서 Rich 라이브러리의 터미널 출력을 데이터 소스로 썼다는 것이다. Rich는 컬럼 너비에 맞게 긴 문자열을 잘라낸다. autonomy.tracing.mandatory가 autonomy.tracing.mandat…으로 잘렸고, grep은 당연히 매칭을 못 찾았다.
이 사례가 캐시 TTL 변경과 성능 저하 버그 인정과 같은 맥락에서 중요한 이유가 있다. AI 도구의 신뢰성 문제는 두 층위에서 동시에 발생한다. 하나는 공급사 레벨의 스텔스 변경이고, 다른 하나는 팀 내부 검증 도구 자체의 신뢰성이다. CORE 사례는 '검증 레이어도 검증해야 한다'는 원칙을 증명한다. 렌더링된 출력이 아니라 JSON 원본을 봐야 한다. 디스플레이 라이브러리는 데이터 소스가 아니다.
팀이 먼저 감지하려면: 실용 대응 프레임
이 세 사례를 엮으면 AI-First 워크플로우를 운영하는 팀에게 즉각 적용 가능한 대응 프레임이 나온다.
첫째, AI 도구의 비용·동작을 직접 모니터링하라. Anthropic의 changelog가 아니라 팀의 로그가 먼저 진실을 말한다. Claude Code를 쓴다면 ~/.claude/projects/*.jsonl에서 ephemeral_1h_input_tokens와 ephemeral_5m_input_tokens를 직접 파싱하라. 캐시 TTL 변경은 changelog보다 비용 청구서가 먼저 알려준다—원한다면 청구서보다 로그가 먼저 알게 설계할 수 있다.
둘째, 성능 기준선을 팀 내부에서 직접 운영하라. Anthropic이 추론 설정을 'medium'으로 낮췄을 때, 이를 먼저 감지한 건 내부 벤치마크를 돌리던 팀이었다. 공급사 공식 발표를 기다린 팀은 수주 뒤에 알았다. AI 도구의 출력 품질을 주기적으로 측정하는 골든 셋을 팀이 직접 관리해야 한다.
셋째, 검증 도구 자체를 검증하라. CORE 사례의 교훈이다. AI가 생성한 코드를 감사하는 시스템이 있다면, 그 시스템의 출력을 맹신하지 마라. 렌더링 레이어와 데이터 레이어를 분리하고, 진단의 1차 소스는 항상 원본 구조화 데이터(JSON, 로그 파일)여야 한다.
전망: 공급사 신뢰에서 팀 관측 역량으로
캐시 TTL 변경 이슈에서 주목할 대목이 하나 더 있다. Honeycomb의 엔지니어링 디렉터가 직접 grep 원라이너를 공유하고 redacted 로그를 Anthropic에 제출했다. 커뮤니티가 공급사보다 먼저, 더 정확하게 문제를 파악하고 있었다. AI 도구 생태계에서 앞으로 이 패턴은 더 강화될 것이다.
AI-First로 워크플로우를 설계한 팀이라면 이제 공급사의 투명성에 기대는 것만으로는 부족하다. 팀 스스로 관측 가능성(observability)을 확보해야 한다. API 호출 로그, 비용 추이, 응답 품질 기준선—이 세 가지를 팀이 직접 모니터링하는 구조를 만들어야 한다. 스텔스 변경을 막을 수는 없다. 하지만 그것을 공급사 공지보다 먼저 팀이 감지할 수는 있다. 그 차이가 비용 리스크와 품질 리스크를 통제 가능한 범위로 유지하는 핵심이다.