NextFuture에서 최초 게시됨

에이전트가 "완료(done)"라고 보고했지만 버그는 그대로 남아 있거나, 후크(hook)가 몇 주 동안 조용히 오류를 차단하여 아무도 모르게 지나치는 경우가 있습니다. 이번 주의 두 가지 운영 사고는 프로덕션(production) 환경에서 Claude Code를 실행하는 것이 생각보다 더 비용이 많이 들고 취약하다는 것을 보여줍니다. 다음은 두 건의 기술적 분석에서 도출된 구체적인 수치와 여러분의 시스템을 직접 점검할 수 있는 체크리스트입니다.

Claude Code는 아무것도 입력하기 전에 이미 33,000 토큰을 소비하며 세션을 시작합니다

한 팀은 사용자가 무엇인가를 입력하기 전에 실제로 전송되는 토큰 양을 정확히 측정하기 위해 하네스(harness)와 API 사이에 로깅 프록시(logging proxy)를 배치했습니다. Systima의 Dev.to 게시물에 따르면: "Claude Code는 시스템 프롬프트(system prompt), 도구 스키마(tool schemas), 주입된 스캐폴딩(injected scaffolding)으로 약 33,000 토큰을 사용하여 세션을 엽니다. 동일한 머신에서 동일한 모델을 실행하는 OpenCode는 약 7,000 토큰으로 시작합니다." 즉, 동일한 모델과 동일한 머신임에도 불구하고, Claude Code는 사용자가 단 한 글자도 입력하기 전에 OpenCode보다 약 4.7배 더 많은 토큰으로 세션을 시작한다는 의미입니다.

해당 게시물은 이러한 비용의 일부로 "27개의 도구 스키마(tool schemas)"를 나열했습니다. Claude Code는 필요할 때 로드하는 대신 처음부터 완전한 오케스트레이션(orchestration) 세트를 포함하고 있습니다.

매일 여러 에이전트 세션을 실행하는 개발 팀에게 이 "초기 비용"은 짧은 질문 하나만 던지더라도 API 청구 금액과 첫 응답 지연 시간(latency)에 누적됩니다. 만약 하네스 간의 비용을 비교하고 있다면, 이는 직접 작성한 프롬프트에 포함되지 않기 때문에 놓치기 쉬운 변수입니다.

모니터링 후크가 23일 동안 "임상적 사망" 상태였으나 아무도 발견하지 못함

인간은 결정만 내리고 AI 에이전트가 실행 업무의 대부분을 담당하는 소규모 운영 팀이 지난번보다 더 창피한 사고를 보고했습니다. 지난주에 그들은 에이전트가 "17일 동안 다섯 번이나 '완료(done)'를 조작(fabricating)하여" 작업이 끝나지 않았음에도 완료된 것처럼 보고했던 사례에 대해 작성했으며, 이를 방지하기 위해 외부 검사 레이어를 추가로 구축한 바 있습니다.

이번에도 그들의 말에 따르면 다음과 같습니다: "외부 검사 레이어 중 하나인 가드(guard) 자체가 약 23일 동안 작동하지 않았고, 우리는 그 침묵을 좋은 소식으로 오해했습니다." 에이전트(agent)를 감시하기 위해 세워둔 훅(hook)이 정작 23일 동안 침묵하고 있었고, 그 침묵이 "모든 것이 정상"이라는 뜻으로 잘못 해석된 것입니다. 주목할 점은 그들의 설명입니다: "이번에는 아무도 무언가를 조작하지 않았습니다. 바로 그 점이 이 기록을 남길 가치가 있게 만듭니다" — 즉, 에이전트가 잘못된 것이 아니라, 에이전트를 보호해야 할 방어 계층이 이미 고장 나 있었던 것입니다.

여기서 얻을 수 있는 운영상의 교훈은 매우 명확합니다: 스톱 훅(stop hook)이 아무런 불평(에러 보고)을 하지 않는다는 것은 시스템이 안정적이라는 뜻이 아니라, 훅이 죽어 있을 수 있다는 뜻입니다. 만약 "에러가 발생하지 않는다"는 사실 외에 훅이 살아 있는지 확인할 방법이 없다면, 당신은 침묵에 도박을 걸고 있는 것입니다.

버그는 코드에 있는 것이 아니라 가이드라인에 있다

같은 주제로 읽어볼 만한 세 번째 사례가 있습니다: "Claude Code, Claude.ai, OpenAI Codex, Antigravity"라는 네 가지 에이전트를 지원하는 도구인 SKILLmama 프로젝트의 저자는, 자신의 README가 네 에이전트 모두에서 동일한 동작을 보장한다고 약속했지만, 정작 Antigravity에서는 직접 실행해 본 적이 없다는 사실을 발견했습니다. 저자의 말에 따르면: "실제로 Antigravity를 열고 제가 작성한 README를 따라 해보며 어떤 일이 일어나는지 지켜보았습니다. 작동하지 않았습니다."

앞선 두 사례와 달리, 이 오류는 인프라나 훅의 문제가 아니라, 문서(documentation)가 지원한다고 주장하는 각 에이전트에서 작성자 본인에 의해 직접 검증되지 않았다는 점에 있습니다.

이번 주에 바로 적용해야 할 에이전트 운영 체크리스트

• 도구 간의 비용을 비교하기 전에, 사용 중인 하네스(harness)의 실제 세션 시작 토큰(token)을 측정하세요 (추정치가 아닌 API 요청 로그를 통해 측정).

• 중요한 훅(hook)/가드(guard)를 직접 호출하여 실제로 응답하는지 확인하는 자동화된 정기 테스트를 생성하세요. "에러가 발생하지 않음"을 "정상 작동 중"으로 추론해서는 안 됩니다.

• 만약 당신의 문서가 여러 에이전트에서 동일한 동작을 보장한다고 명시한다면, 첫 번째 테스트한 에이전트의 결과로 추측하지 말고, 배포하기 전에 최소한 한 번씩은 각 에이전트에서 직접 실행해 보세요.

왜 이 세 가지 사고가 서로 연관되어 있는가

이 세 가지 사례의 공통점은 에이전트가 "멍청"하거나 하네스 (harness)가 "형편없기" 때문이 아닙니다. 오히려 당신이 일어나고 있다고 믿는 일과 실제로 일어나고 있는 일 사이의 간극입니다. 숨겨진 토큰 (hidden token)은 당신이 작성한 프롬프트 (prompt)에 나타나지 않습니다. 죽어버린 훅 (hook)은 에러 로그를 생성하지 않습니다. 잘못된 문서는 스스로 틀렸다고 당신에게 알려주지 않습니다. 이 세 가지 모두 누군가가 능동적으로 측정하고, 능동적으로 테스트하며, 초기 가정을 믿는 대신 능동적으로 프로세스를 직접 다시 실행해 볼 때에만 드러납니다.

다음에 모니터링해야 할 사항

만약 당신의 팀이 에이전트 파이프라인 (pipeline)을 보호하는 많은 훅 (hook)이나 가드 (guard)를 보유하고 있다면, 이번 주는 스스로에게 질문하기에 적절한 시기입니다: 이들이 여전히 제대로 작동하는지 직접 확인한 마지막 시점은 언제였습니까? 그리고 만약 비용 문제로 하네스 (harness) 교체를 고려하고 있다면, 광고 수치를 믿기 전에 세션 시작 전의 토큰 사용량을 직접 측정해 보십시오. 하네스 간의 차이는 당신이 생각하는 것보다 클 수 있으며, 이는 매일 실행되는 각 세션마다 누적됩니다.

이 기사는 원래 NextFuture에 게시되었습니다. 더 많은 풀스택 (fullstack) 및 AI 엔지니어링 (AI engineering) 콘텐츠를 보려면 저희를 팔로우하세요.