왜 HN이 크게 반응했나

이번 글이 HN에서 강하게 먹힌 이유는 단순한 사과문이 아니라, 개발자들이 평소 의심하던 구조를 비교적 노골적으로 확인해 줬기 때문이다. 같은 모델을 쓴다고 해도 기본 reasoning effort, 세션 캐시 처리, 시스템 프롬프트 제한이 바뀌면 사용자는 “모델이 멍청해졌다”고 느낄 수 있다. 크롤링 시점 스레드는 727점, 543개 댓글이었고, 반응의 중심은 “Anthropic이 솔직했다”보다 “이제 모델 품질 논쟁에서 제품 레이어를 떼고 볼 수 없게 됐다”에 가까웠다.

Anthropic이 짚은 세 가지 원인

Anthropic은 문제를 세 갈래로 설명했다. 첫째, 3월 4일 Claude Code의 기본 reasoning effort를 high에서 medium으로 낮췄다. 긴 사고 시간이 UI를 멈춘 것처럼 보이게 만든다는 이유였지만, 사용자 반응이 나쁘자 4월 7일 되돌렸다. 둘째, 3월 26일에는 한 시간 넘게 idle 상태였던 세션에서 오래된 thinking을 한 번만 비우려는 캐시 최적화를 넣었는데, 버그 때문에 이후 모든 턴에서 계속 thinking이 잘려 나갔다. 그 결과 Claude Code가 이유를 잊고 반복하거나 이상한 tool 선택을 하는 것처럼 보였고, Anthropic은 이를 4월 10일 수정했다고 적었다. 셋째, 4월 16일에는 verbosity를 줄이기 위해 tool call 사이 문장을 25단어 이하, 최종 응답을 100단어 이하로 제한하는 시스템 프롬프트 규칙을 추가했는데, 추가 실험에서 한 평가셋 기준 3% 하락이 확인돼 4월 20일 롤백했다.

HN이 특히 물고 늘어진 지점

댓글에서 가장 많이 반복된 지적은 “설명이 그럴듯하냐”가 아니었다. “왜 UI 문제를 reasoning 축소로 해결했느냐”가 핵심이었다. 한 댓글은 요지를 이렇게 잡는다. 화면이 멈춘 것처럼 보이면 인터페이스를 고쳐야지, 기본 지능을 낮추는 쪽으로 가는 건 우선순위가 뒤집힌 대응이라는 것이다. 다른 댓글들은 이 사건을 더 크게 읽었다. 코딩 에이전트의 품질이 default effort, context retention, prompt 압축 규칙으로 크게 흔들릴 수 있다면, 외부에서 보는 ‘모델 품질’ 평가는 실제 스택의 절반도 설명하지 못할 수 있다는 얘기다. 몇몇 사용자는 Opus 4.6에 high effort를 강제로 고정하는 설정을 공유했고, 어떤 댓글은 “이 정도도 내부에서 못 잡았는데 진짜로 소프트웨어 일자리 절반이 대체되겠느냐”는 식으로 신뢰 문제를 정면에서 건드렸다.

왜 중요한가

이 postmortem의 진짜 의미는 Anthropic이 실패 지점을 모델이 아니라 기본 계산 예산, 이전 reasoning 유지 방식, 시스템 프롬프트 제약으로 나눠서 보여줬다는 데 있다. 셋 다 연구실 데모보다 제품 운영에서 더 자주 만나는 문제다. Anthropic은 세 이슈가 모두 4월 20일 기준 v2.1.116에서 해결됐고, 4월 23일 구독자 usage limit을 초기화했다고 밝혔다. 하지만 HN의 더 큰 결론은 따로 있다. 앞으로 코딩 에이전트 품질을 말할 때는 모델 가중치만이 아니라, 그 위에 얹힌 default와 cache, prompt policy까지 한 덩어리로 봐야 한다는 것이다.

출처: Anthropic engineering post · Hacker News 토론

#postmortem

Claude Code postmortem에 HN이 꽂힌 이유, 모델이 아니라 제품 레이어