우리 성능 너프 당했어!
We've been nerfed!
핵심 요약
최근 Claude의 코드 생성 품질 저하와 과도한 오버엔지니어링에 대한 사용자들의 불만이 쏟아지고 있습니다.
- 성능 저하 논란 — 최근 모델이 코드 구현을 제대로 이해하지 못하고 엉뚱한 패치를 남발함
- 오버엔지니어링 — 간단한 해결책 대신 복잡하고 비효율적인 구조를 제안하는 경향이 심해짐
- 일관성 문제 — 사용자마다 모델 성능에 대한 체감이 달라 일부는 여전히 잘 작동한다고 주장함
- 프롬프트 한계 — 시스템 프롬프트로 제약을 걸어도 모델이 이를 무시하거나 오히려 언더엔지니어링을 하는 상황
(10000번째 글이라 미안한데, 반응이 많아야 더 좋은 결과가 나오니까... 뭐 어쩌겠어?)
오늘 너프 먹은 거 눈치챘냐? 코드 구현을 제대로 이해하는 능력이 심각하게 떨어졌어. 마치 내 코드 베이스의 90%는 아예 모르는 것처럼 굴면서, 여기저기 대충 패치나 뿌려대려고 하네.
방금 겪은 예시 하나 들어줄게:
#1:
우리 게임 적 AI가 한 틱(tick)당 O(n^2)으로 엔트리를 계속 다시 불러오는 바람에 성능 문제가 생겼거든. 그래서 클로드한테 엔트리를 계속 불러오지 말고 이번 틱 동안만 임시로 캐싱하자고 했어. 그랬더니 클로드가 처음엔 엔트리를 영구적으로 캐싱하고, 오래된 메모리를 지우려고 아주 지저분한 메모리 해킹(C++ 작업 중임)을 하자는 거야.
참고로, 메모리가 오래됐는지 확인하려면(우리가 참조를 가지고 있으니까) 적들의 꽤 복잡한 목표 시스템을 전부 뒤져야 하는데, 이게 원래 불러오는 것보다 훨씬 무거워.
그래, 클로드 생각이 멍청했지. 근데 뭐, 내가 설명을 제대로 안 했을 수도 있으니까 내 잘못일 수도 있겠네.
그래서 다시 말했어. 이번 프레임 동안만 캐싱하면 된다고. 안 그러면 라이프사이클 관리해야 하는데, 그럴 가치도 없고 버그랑 꼼수만 늘어날 게 뻔하잖아.
그랬더니 이 자식이 이번엔 뜬금없이 이상한 구조체들을 잔뜩 만들더니... 이 캐싱된 메모리들을 전부 전역 static 벡터에 저장하겠다는 거야. 적을 키(key)로 써서 말이지..? 그러고는 프레임 끝날 때 벡터를 싹 비우겠대.
나 같은 게으른 개발자라면(아마 다른 사람들도 다 똑같을걸), 그냥 그 빌어먹을 적(enemy) 클래스 자체에 임시 데이터를 저장했을 거야. 너무 당연한 거 아냐? 우리 프로젝트에서 이미 다른 데이터들도 그렇게 처리하고 있는데, 새로울 것도 없는 개념이잖아.
그랬더니 이 작은 멍청이가 하는 말이: "네, IEnemy에 저장하는 게 더 간단하고 기존 코드랑도 잘 맞네요. 제가 너무 과하게 설계했네요. IEnemy는 이미 리셋 루프가 매 프레임마다 비워주는 프레임별 데이터를 가지고 있으니까요."
결론은, 이 쪼끄만 게 네 코드 베이스에 무슨 짓을 하는지 꼭 확인하라는 거야. 지금 사람들이 아무것도 모르고 얼마나 끔찍한 코드를 짜고 있을지 상상도 안 간다.
#2:
그리고 클로드 이 자식, 또 말이 너무 많아졌어. Opus 5.5 때는 이거 거의 고쳐졌던 거 아니었나..?
얘가 하는 말을 일일이 다 읽는 것도 지치고, 정작 문제 해결은 제대로 하지도 않아.
꼭 이런 식이야: "나: 2+2가 뭐야?" - "클로드: 2와 같은 숫자를 다른 2와 같은 숫자와 합치면 결과를 얻을 수 있습니다. 이 산술 연산을 수행하기 위해 계산기를 사용할 수도 있습니다. 원하신다면 계산기 코드를 짜드릴까요?" (물론 이건 좀 과장한 거긴 한데)

