오늘은 넷입니다 — 코딩 에이전트 경쟁, 새 모델 프로모, 인프라 장애 부검, LLM 신뢰성 연구. 묶고 보니 결이 하나예요: 능력 자랑보다 ‘무엇을 못 믿고 어디서 검증·정산할지’를 먼저 정한 쪽이 오래 갑니다. 각 항목은 ‘한 줄 판단’부터 던집니다.

오늘의 핵심

1. ZCode — GLM 진영의 ‘Claude Code 드롭인 대체’가 본격화

• 한 줄 판단: 코딩 에이전트는 이제 하네스(도구)와 모델이 분리되는 국면입니다. 같은 워크플로에 백엔드만 갈아끼울 수 있으니, 잠금(lock-in)보다 비용·검증 결과로 고르는 시대로 가고 있어요.
• 사실: Z.ai가 코딩 모델 GLM-5.2용 공식 에이전트 ZCode를 내놨고, GLM을 Claude Code의 드롭인 대체 백엔드로 쓰는 구성(엔드포인트·키만 교체)도 널리 공유됩니다. (⚠️ 1M 컨텍스트·성능은 Z.ai 발표 기준, 실제 코드베이스 품질은 직접 검증 필요.)
• 이번 주 할 일: 반복·저위험 작업 한 종류만 골라 대체 백엔드로 A/B 해 보시길 권합니다. 단, 비용은 줄어도 프롬프트·툴 연동을 다시 다듬는 비용이 따르니, 전체를 옮기기보다 한 갈래에서 재보는 편이 균형이 맞습니다.

2. Claude Fable 5 — 7일짜리 한시 무료 프로모 (오늘 진행 중)

• 한 줄 판단: 새 상위 모델을 공짜 구간에 실전 부하로 재보라는 초대입니다. 다만 한도를 더 빨리 태우니, 체감 성능만이 아니라 ‘같은 한도로 몇 번 돌리나’까지 함께 보는 게 실속 있어요.
• 사실: Anthropic이 최신 모델 Claude Fable 5를 웹·앱·데스크톱·Claude Code에서 제공하며, 7월 1~7일(PT) 동안 Pro·Max·Team과 프리미엄 좌석 Enterprise 구독자에게 *주간 한도의 최대 50%*를 추가 비용 없이 엽니다. 무료 플랜·API는 제외, 공식 안내상 다른 모델보다 한도를 더 빨리 소모합니다. (Anthropic 공식 문서.)
• 이번 주 할 일: 실제 과제 한둘을 Fable 5로 돌려 기존 모델과 결과·소모량을 나란히 기록해 두시길 권합니다. 단, 상시 주력으로 삼으면 주중 후반 고갈을 부를 수 있어, 난도 높은 작업에 선택 배치하는 편이 안전합니다.

3. 쿠버네티스 1.36 kubelet 메모리 누수 — 한 줄 실수가 91만 개 컨텍스트로

• 한 줄 판단: 규모가 실수를 증폭한다는 교과서 사례입니다. 취소 함수를 한 번 안 부른 코드가, 매 Pod 조정 루프마다 쌓여 노드를 잡아먹었어요 — 핫 루프에서는 사소한 리소스 정리 누락도 재앙이 됩니다.
• 사실: 쿠버네티스 1.36의 kubelet에서 startPodSync가 context.WithCancel을 조건 없이 재할당해 이전 취소 함수를 안 부르고, Pod 조정 루프마다 컨텍스트가 누수됐습니다. 2GiB 클러스터를 pprof로 부검하니 약 91.8만 개·115MB 이상을 점유했고, 수정이 1.36.3에 백포트됐습니다.
• 이번 주 할 일: 1.36 계열을 쓰신다면 kubelet 메모리 추이를 확인하고 필요 시 패치 버전으로 올리시길 권합니다. 코드 관점에선 반복 루프 안 context·타이머·구독의 정리(cancel/close) 경로를 리뷰 체크리스트에 넣어 두시면 좋습니다. 단, 방어 코드는 가독성을 조금 내주니 실제 핫 루프에 한정하는 편이 균형이 맞습니다.

4. 표를 ‘대충 읽는’ LLM — 이해는 해도 값을 잘못 인용

• 한 줄 판단: 최종 답만 맞으면 됐다는 안심이 위험하다는 신호입니다. LLM이 표 구조는 이해해도 개별 값 인용을 틀리는 오류가 전 크기 모델에서 나타나니, 표·수치가 걸린 파이프라인엔 별도 검증 단계가 사실상 필수예요.
• 사실: ACL 2026 구두 발표 논문이 LLM의 데이터 인용 오류(DRE) — 표 값을 잘못 인용·누락하는 문제 — 를 1.7B~20B 전 모델에서 측정했습니다. 경량 4B ‘크리틱’으로 검증·재표집을 붙이니 정확도가 최대 12%p 오르고, 크리틱은 오류 탐지에서 *평균 F1 78.2%*를 기록했습니다.
• 이번 주 할 일: 재무·로그 등 표를 LLM에 태우는 흐름이 있다면, 출력 셀 값을 원본과 대조하는 자동 점검 한 겹을 붙여 보시길 권합니다. 단, 크리틱·재표집은 지연·비용을 더하니 오답 대가가 큰 수치 흐름에 우선 적용하시면 균형이 맞습니다.

그래서, 무엇이 바뀌나

넷을 관통하는 한 가지 — ‘무엇을 못 믿고 어디서 정산·검증할지’를 먼저 정한 쪽이 이긴다는 흐름입니다. 코딩 에이전트는 비용·검증 경계가 선택 기준이 됐고, Fable 5는 한도 정산을, kubelet 누수는 핫 루프의 정리 경계를, 표 인용 오류는 AI 출력의 검증 경계를 요구합니다. 그럼의 편집 기준(규모=난이도, AI도 역할·입출력·검증·복구 경계가 있어야 제품)으로 보면, 공개된 분산 시스템사가 ‘못 믿을 노드를 가정에 먼저 넣어’ 살아남았듯 능력보다 경계를 먼저 그은 설계가 오래 갑니다. (어제의 ‘아래 계층에 안전·복구 내장’, 데일리 트렌드를 고르는 기준도 같은 렌즈입니다.)

참고 / 출처

• ZCode — GLM-5.2용 공식 에이전트 · GLM 코딩 플랜(GLM-5.2) — Z.ai 공식 (1M 컨텍스트·성능은 벤더 발표)
• Claude Fable 5 Promotional Access — Anthropic 공식 지원 문서
• Fixing a kubelet memory leak in Kubernetes 1.36 — 부검 블로그 + 코드
• When LLMs Read Tables Carelessly: Measuring and Reducing Data Referencing Errors — ACL 2026 발표 논문
• 함께 보기: Gossamer 새 시스템 언어·공격 견디는 다중 에이전트 제어