음모론: Claude는 스파게티 코드를 짜는 걸 선호하는 것 같다
Conspiracy theory: Claude prefers to write spaghetti code
핵심 요약
Claude가 근본적인 리팩토링 대신 임시방편만 제시하는 현상에 대해 사용자가 의문을 제기하며 그 원인을 분석함.
- 코드 중복 문제 — Claude가 리팩토링 대신 임시방편을 선호하여 유지보수가 어려워짐.
- LLM의 한계 — 모델이 코드 전체 구조를 파악하지 못하고 당장의 작업 완료에만 집중함.
- 학습 데이터 영향 — 평균적인 개발자들의 코드를 학습하여 우아한 코드보다 작동하는 코드를 우선시함.
- 사용자 역할 강조 — Claude를 훈련생처럼 다루며 명확한 리팩토링 계획과 가이드라인을 제시해야 함.
반쯤 농담으로 들어주길 바라지만, 이런 일이 있다. 코드베이스가 커질수록 같은 코드(심지어 간단한 코드조차)가 10군데 이상 중복되는 상황이 자주 발생한다. 유지보수가 지옥이 되는 이유는, 무언가를 수정하거나 개선하려고 할 때 거의 필연적으로 한두 군데를 놓치기 때문이다.
그런 위치 중 한 곳에서 불일치나 버그를 지적하면, Claude의 기본 사고방식(Sonnet, Opus 등 모델을 막론하고)은 임시방편을 적용하는 것이다. 근본 원인이 아니라 증상만 치료한다.
최근 이 글을 쓰게 만든 극단적인 사례를 겪었다. 9군데에 중복된 코드가 있고, 각각 조금씩 다른 구현이 되어 있는 전형적인 시나리오였다. 나는 시간을 들여 문제를 조사하고 모든 위치와 불일치를 찾아냈다. 이건 리팩토링의 교과서적인 사례였다. 코드를 중앙 집중화하고, 각 호출처가 단일 진실 공급원을 참조하도록 업데이트하는 것. 조사를 시작할 때부터 나의 의도는 명확했다.
우리는 30분에서 1시간 동안 함께 코드베이스를 파헤쳤다. 마지막에 나는 Claude(Opus 4.7)에게 조사를 검토하고 앞으로 나아갈 방향을 제안해달라고 했다. Claude는 "리팩토링은 훨씬 위험하다"는 이유를 들며 문제 지점 3곳에 임시방편을 적용하고 리팩토링은 나중으로 미루는 선택을 했다.
이런 패턴을 계속 목격한다. 계획이나 제안된 솔루션에서 말이다. 마치 근본 원인을 고치지 말고 임시방편을 적용하라는 깊게 내재된 선호가 있는 것 같다. 너무 예측 가능해져서 이런 미친 생각이 들었다. Anthropic이 우리를 더 의존하게 만들려고 의도적으로 이렇게 하는 걸까? (코드가 복잡할수록 인간이 도움 없이 탐색하기 어려우니까.) 아니면 그냥 모든 LLM이 학습한 코드에서 물려받은 특성일까?
