Claude가 오래 사용할수록 "멍청해지는" 이유: "비용 절감"의 숨겨진 대가, 100배의 API 비용

2026년 4월 13일

Claude가 오래 사용할수록 "멍청해지는" 이유: "비용 절감"의 숨겨진 대가, 100배의 API 비용

며칠 전, AMD AI 책임자인 Stella Laurenzo는 공식 Claude Code 리포지토리에 매우 기술적인 문제를 제기했습니다. "2월 업데이트 이후 Claude Code는 복잡한 엔지니어링 작업에 사용할 수 없습니다." 단순히 느낌만으로 불평한 것이 아닙니다. 이는 실제 워크플로우에서 수집된 6,852번의 세션, 17,871개의 사고 블록, 234,760번의 도구 호출을 기반으로 한 정량적인 사후 검토였습니다. 원본 보고서는 여기에서 확인할 수 있습니다: GitHub 이슈 #42796.

암호화폐 분야에서 개발하고 있다면 이 문제에 관심을 가져야 합니다. "복잡한 엔지니어링"은 Web3에서 기본 설정과 같기 때문입니다. 스마트 계약은 불변이며, 공격 표면은 조합 가능하고, 단 하나의 환각적인 변경으로도 익스플로잇이 발생할 수 있습니다. AI 제품의 사소한 오류처럼 보이는 것이 실제로는 소프트웨어 공급망 위험이며 비용 함정입니다.

1) 불편한 데이터: 품질 저하, 비용 급증 (엄청난 급증)

이 보고서는 확장된 사고 및 사고 편집과 관련된 서버 측 구성 변경 (특히 redact-thinking-2026-02-12로 라벨링된 롤아웃)과 가시적인 품질 저하를 연관 짓습니다. 핵심 주장은 "결과가 나빠졌다"는 것뿐만 아니라 모델의 행동이 연구 중심에서 편집 중심으로 측정 가능하게 전환되었다는 것입니다. 이는 고위험 엔지니어링에는 정반대 방향입니다.

다음은 이슈 스레드의 지표를 기반으로 한 단순화된 스냅샷입니다.

신호 (세션 원격 측정 데이터 기준)	"좋았던" 기간	"저하된" 기간	암호화폐에 왜 중요한가
추정된 사고 깊이 (중앙값)	~2,200자	~560–720자	추론 부족 → "틀렸다고 확신하는" 패치 증가
읽기 : 편집 비율	6.6	2.0	이해 전에 편집하면 불안정한 차이 발생
중단 후크 위반	0	173	다단계 리팩토링에서 조기 중단은 치명적
추정 비용 (Bedrock Opus 비교)	$345 (2월)	$42,121 (3월)	"저렴한 사고"는 재시도 및 스래싱 증가 유발 가능

출처: GitHub 이슈의 원본 원격 측정 데이터 및 비용 별첨.

암호화폐와 가장 관련 있는 교훈은 직관에 반합니다. 추론을 제한한다고 해서 항상 비용이 줄어드는 것은 아닙니다. 장기적인 작업에서 약한 에이전트는 더 많은 재시도, 수정, 도구 호출을 유발할 수 있으며, 더 나쁜 안정성을 제공하면서도 100배 이상 청구서를 올릴 수 있습니다.

2) 왜 이것이 일반적인 소프트웨어 팀보다 블록체인 팀에 더 큰 영향을 미치는가

스마트 계약은 "이 정도면 충분하다"를 용납하지 않는다

Web2에서는 회귀를 패치하고 다시 배포할 수 있습니다. Web3에서는 잘못된 가정이 영구화될 수 있습니다.

Ethereum 자체의 설명서는 단호합니다. 배포된 코드는 변경하기 어렵고 손실은 종종 복구할 수 없습니다. Ethereum 스마트 계약 보안 설명서 및 광범위한 보안 가이드를 참조하십시오.

Claude Code 원격 측정 데이터와 연결해 보겠습니다. 파일 읽기 감소, 더 성급한 편집, 더 잦은 조기 중단. 이는 정확히 다음과 같은 패턴을 생성합니다.

불완전한 확인 (권한 부여, 재현 방지, 도메인 분리)
모듈 간 깨진 불변성
토큰 소수점, 수수료 부과, 반올림 주변의 엣지 케이스 처리 누락
안전하지 않은 외부 호출 또는 잘못 배치된 상태 업데이트

DeFi 및 온체인 인프라에서 "거의 정확함"은 종종 악용 가능함과 동일합니다.

2025–2026년 복잡성 동향은 폭발 반경을 증폭시킨다

두 가지 산업적 변화는 "AI 에이전트 회귀" 이야기가 암호화폐에서 보이는 것보다 더 위험하게 만듭니다.

계정 추상화 및 스마트 계정이 대중화되면서 보안에 중요한 로직의 양이 EOA보다 계약 내에 더 많이 존재하게 됩니다. 제품이 AA를 다룬다면 ERC-4337과 ERC-4337 문서의 실제 생태계 문서를 시작점으로 삼으십시오.
AI 지원 사기 및 사회 공학이 확대되고 있습니다. Chainalysis는 AI 공급업체와 관련된 사기가 평균적으로 운영당 더 많은 수익을 올린다고 지적합니다. 2026년 암호화폐 범죄 보고서의 사기에 대한 내용을 참조하십시오. 최종 사용자가 AI에게 "이것을 서명해도 안전한가요?"라고 묻는 경우가 점점 늘어남에 따라, 모델의 신뢰성은 엔지니어링 선호도를 넘어 소비자 보호 문제가 됩니다.

3) 진정한 교훈: LLM은 이제 프로덕션 종속성입니다. 그렇게 취급하십시오.

암호화폐 팀은 이미 중요한 종속성의 버전을 관리하는 방법을 (어렵게) 배웠습니다. 컴파일러 버전, RPC 제공업체, 수탁 모듈, 서명 라이브러리. LLM 에이전트도 이제 동일한 범주에 속합니다.

실용적인 Web3 플레이북:

A) 프로토콜 테스트 제품군을 구축하듯이 "LLM 회귀 테스트"를 구축하십시오.

대표적인 작업 캡처: 계약 업그레이드 흐름, 크로스체인 메시징, 인덱서 백필, 수수료 계산 리팩토링.
매주 동일한 프롬프트를 실행하고 결과를 비교합니다.
단위 테스트, 불변성, 시뮬레이션 및 정적 분석과 같은 결정론적 검사를 통해 병합을 게이트합니다.

Solidity를 배포하는 경우, Ethereum의 지침 페이지는 Slither / Echidna 스타일 분석 워크플로우와 같은 도구를 명시적으로 참조합니다. 스마트 계약 보안 가이드에서 시작하십시오.

B) 중요한 리포지토리에서 "자동 편집 수락"을 제거하십시오.

이슈 보고서는 변경 사항이 자동 수락된 워크플로우를 언급합니다. 이는 에이전트가 조용히 신중함에서 무모함으로 전환될 때까지는 생산성 향상입니다.

스마트 계약의 경우 AI를 주니어 기여자처럼 취급하십시오.

인간의 코드 검토 필요
테스트 및 로컬 시뮬레이션 통과 필요
권한 변경, 새 외부 호출 또는 저장소 레이아웃 변경에 대한 명시적 승인 필요

C) 스래싱에 하드 상한선 설정 (비용 통제는 보안 통제)

품질이 떨어지면 에이전트는 더 많은 작업을 수행하여 보상합니다. 더 많은 도구 호출, 더 많은 재시도, 더 많은 토큰 소모. 회로 차단기가 필요합니다.

작업당 최대 재시도 횟수
세션당 최대 도구 호출 횟수
최대 컨텍스트 성장
"병합된 PR당 비용" 또는 "해결된 티켓당 비용"에 대한 알림

이것이 "컴퓨팅 절약"이 100배의 예상치 못한 청구서로 바뀌는 것을 방지하는 방법입니다.

D) 프롬프트 템플릿뿐만 아니라 LLM 위협 모델을 사용하십시오.

프로덕션 키, RPC 엔드포인트 또는 서명 흐름을 다루는 에이전트를 구축하는 경우 대규모 언어 모델 애플리케이션을 위한 OWASP 상위 10과 같은 보안 프레임워크와 일치시키고 프롬프트 삽입 / 도구 오용을 최우선 위험으로 취급하십시오.

4) 일상적인 사용자에게: AI는 암호화폐를 이해하는 데 도움이 될 수 있지만, 키를 제어해서는 안 됩니다.

AI 어시스턴트가 지갑, 거래 및 고객 지원의 기본 인터페이스가 됨에 따라 가장 가능성 있는 실패 모드는 "잘못된 코드 생성"이 아니라 잘못된 서명 결정입니다. 특히 피싱 압력 하에서 그렇습니다.

두 가지 협상 불가능한 사항:

절대 시드 구문을 AI 채팅, "지원 봇" 또는 브라우저 양식에 붙여넣지 마십시오.
"조언"과 "권한 부여"를 분리하십시오. AI가 요약하도록 하되, 자금 이동에는 물리적 확인을 요구하십시오.

이 분리는 하드웨어 지갑이 제 역할을 하는 곳입니다.

5) OneKey의 역할: AI는 선택 사항으로, 서명은 명시적으로

워크플로우 (또는 사용자)가 (거래 설명, 계약 상호 작용, 온체인 "에이전트" 자동화 등) AI에 점점 더 의존하게 된다면 가장 안전한 아키텍처는 다음과 같습니다.

AI가 제안할 수 있습니다.
귀하의 앱이 시뮬레이션할 수 있습니다.
하드웨어 지갑이 승인해야 합니다.

AI로 포화된 암호화폐 스택에서 OneKey의 실질적인 가치는 간단합니다. 개인 키를 오프라인으로 유지하고 명시적인 서명 단계를 강제하여, 저하된 모델, 손상된 프롬프트 또는 설득력 있는 딥페이크 "지원 메시지"가 돌이킬 수 없는 온체인 손실로 이어질 가능성을 줄입니다.