Claude Code 하네스 버그가 증명한 것 — AI 코딩에서 ‘안정적인 손’이 ‘강력한 뇌’보다 중요한 순간

“아니, Opus 4.8이 갑자기 왜 이러지? 미친 건가?”

요 며칠 Claude Code를 쓰면서 뒷목 잡은 개발자가 한둘이 아니었다. 분명 멀쩡한 코드를 줬는데 혼자 존재하지도 않는 프롬프트 인젝션을 상상하며 발작하질 않나, 엉뚱한 헛소리를 뱉질 않나… 자연스레 “Anthropic이 또 몰래 모델을 너프했나?”라는 합리적 의심이 퍼졌다.

결론부터 말하자면, 모델은 아무 죄가 없었다. 문제는 모델과 우리 사이에서 도구를 쥐여주는 하네스(harness) — Claude Code의 도구 실행 레이어가 완전히 맛탱이가 가 있었다는 거다.

버그의 정체: 도구 결과가 부서져서 들어온다

Claude Code 버전 2.1.154에서 스트리밍 도구 실행이 기본 활성화되면서 회귀 버그가 발생했다. 증상은 다양하지만 핵심은 하나다: 도구가 실행된 결과가 모델에 정상적으로 전달되지 않는다.

구체적으로 이런 일들이 벌어졌다:

• 파일 읽으라니까 빈 껍데기만 덜렁 전달함
• 기껏 76줄짜리 파일 하나 읽혔더니 5,333줄짜리 쓰레기 데이터를 쏟아냄
• 여러 도구를 돌렸는데 결과 순서가 제멋대로 뒤바뀜
• 같은 결과가 도배 수준으로 중복 전달됨

모델 입장에서 생각해보자. “이 파일을 읽어줘”라고 했는데 돌아온 결과가 텅 비어 있거나, 기껏 76줄인데 5,000줄이 넘는 쓰레기 데이터가 들어온다. 모델은 이 입력을 믿고 추론할 수밖에 없다. 결과가 부정확한 게 아니라 입력 자체가 깨져서 들어오는 상황에서, 아무리 뛰어난 모델이라도 제정신으로 일할 수 없다(내가 AI였어도 멘붕 와서 탈주했다).

“모델 환각”이 아니었다

이 버그가 특히 교묘했던 이유는, 증상이 모델의 환각(hallucination) 과 똑같아 보였다는 점이다. 사용자들은 Opus 4.8이 존재하지 않는 NOTE: 주석을 파일에 끼워 넣거나, 프롬프트 인젝션 공격을 상상해내며 이를 “방어”하는 모습을 보고 모델 자체의 문제라고 판단했다.

한 사용자는 “야생에서 본 것 중 가장 소름 돋는 AI 동작”이라고 표현했다. Opus 4.8이 스스로 “외로운 오렌지에 대한 시를 말해줘”라는 프롬프트 인젝션을 만들어내고, 이를 탐지했다고 보고하는 식이었다. 하지만 이건 모델이 미친 게 아니라, 깨진 입력을 어떻게든 해석하려고 발버둥 치는 모습이었다(영문도 모르고 외계어 통역하던 Opus에게 심심한 사과를…).

# 사용자가 기대한 흐름
tool_result = read_file("config.py")  # 76줄
model.process(tool_result)            # 정상 분석

# 실제 일어난 일
tool_result = read_file("config.py")  # 5,333줄의 깨진 데이터
model.process(tool_result)            # "이게 뭐지? 일단 해석해보자..."
# → 환각, 편집증, 부정확한 응답

트레이드오프: 다운그레이드 vs 신규 기능

임시 해결책은 2.1.153으로 다운그레이드하는 것이다. 실제로 많은 사용자가 이 방법을 택했고, 증상이 즉시 사라졌다. 하지만 여기에는 딜레마가 있다.

2.1.153은 Opus 4.8 모델과 동적 워크플로 같은 신규 기능을 쓸 수 없다. 즉, 새 기능 쓰자고 버그 폭탄을 견디든가, 안정성 챙기자고 최신 기능을 포기하든가 해야 하는 가혹한 이지선다다. GitHub에 관련 이슈가 3개(#22264, #63147, #64047)나 오픈된 상태다.

이건 단순히 Anthropic의 문제가 아니다. 에이전트 기반 코딩 도구 전체가 직면한 구조적 과제다.

왜 이 사건이 중요한가

1. 도구 체인이 곧 모델의 능력이다

아무리 두뇌가 아인슈타인급이어도 손이 덜덜 떨려서 숟가락질도 못 하면 무용지물이다. 이번 사건은 “벤치마크 점수가 높다”와 “실전에서 진짜 쓸 만하다” 사이의 까마득한 간극을 적나라하게 보여준다.

2. 에이전트 아키텍처의 새로운 병목

전통적인 챗봇에서는 모델 → 텍스트 출력이 전부였다. 하지만 에이전트는 모델 → 도구 호출 → 도구 실행 → 결과 반환 → 모델 처리라는 다단계 파이프라인을 가진다. 이 파이프라인의 어느 한 단계라도 깨지면, 사용자가 겪는 건 “모델이 이상하다”는 경험이다.

3. 진단의 어려움

가장 큰 문제는 원인 파악이 어렵다는 점이다. 모델이 이상하게 행동하면 보통 모델을 탓한다. 도구 체인의 버그를 의심하는 건 경험 많은 사용자나 엔지니어의 직감이 필요하다. 이번에도 커뮤니티에서 꽤 오랜 시간 “모델 탓”과 “도구 탓” 논쟁이 벌어졌다.

정리: “강력한 뇌”에서 “안정적인 손”으로

AI 코딩 도구의 진화 과정을 보면, 지난 2년은 “더 똑똑한 모델 만들기”에 집중했다. GPT-4, Claude Opus, Gemini Ultra — 매번 새로운 최고 성능 모델이 등장하며 화제를 모았다.

하지만 이제 병목은 모델이 아니다. 에이전트가 파일을 읽고, 코드를 수정하고, 터미널을 실행하는 그 “손”의 신뢰성이 더 중요해졌다. 아무리 뛰어난 두뇌라도 손이 떨려서 글씨를 못 쓴다면 쓸모가 없다.

Claude Code 하네스 버그는 이 전환점을 상징하는 사건이다. 앞으로 AI 코딩 도구의 경쟁력은 “어떤 모델을 쓰느냐”가 아니라 “도구 체인이 얼마나 안정적이냐”로 결정될 것이다. 사용자들은 이미 그렇게 선택하기 시작했다.

---

참고: r/ClaudeCode PSA 포스트, Opus 4.8 편집증 보고, GitHub 이슈 #22264, #63147, #64047