Claude Code, 복잡한 작업에서 성능이 떨어졌다? — 사용자 피드백이 쏟아지는 이유

AI 코딩 도구의 현주소

AI 코딩 어시스턴트가 개발자 일상에 깊숙이 들어왔어요. GitHub Copilot, Cursor, 그리고 Anthropic의 Claude Code까지. 특히 Claude Code는 터미널에서 직접 코드를 읽고, 수정하고, 커밋까지 해주는 에이전트형 도구로 주목받았는데요, 최근 사용자들 사이에서 꽤 심각한 불만이 터져 나왔어요.

Anthropic의 공식 GitHub 저장소에 올라온 이슈를 보면, 복잡한 엔지니어링 작업에서 Claude Code의 성능이 이전보다 눈에 띄게 저하됐다는 보고가 이어지고 있어요. 단순한 "좀 느려졌다" 수준이 아니라, 실무에서 쓰기 어려울 정도라는 피드백이 나오고 있는 거죠.

구체적으로 어떤 문제들이 보고됐을까요

사용자들이 지적하는 핵심 문제는 몇 가지로 정리돼요.

첫 번째는 컨텍스트 유지 능력의 저하예요. AI 코딩 도구에서 "컨텍스트"란 현재 대화에서 AI가 기억하고 있는 정보의 범위를 말해요. 예를 들어 "이 파일의 함수를 수정해줘"라고 했을 때, 그 파일이 어떤 구조인지, 앞에서 어떤 대화를 나눴는지를 AI가 기억하고 있어야 제대로 된 수정이 가능하잖아요. 그런데 복잡한 프로젝트에서 여러 파일을 오가며 작업하다 보면, Claude Code가 앞에서 논의한 내용을 잊어버리거나 엉뚱한 방향으로 코드를 수정하는 경우가 잦아졌다는 거예요.

두 번째는 불필요한 반복과 루프에 빠지는 현상이에요. 한 번에 해결할 수 있는 문제를 같은 접근으로 반복해서 시도하거나, 에러가 나면 근본 원인을 파악하지 않고 비슷한 변경을 계속 반복한다는 보고가 있어요. 개발자 입장에서는 이게 정말 답답하죠. AI가 삽질하는 걸 지켜보면서 토큰(사용량)은 계속 소비되니까요.

세 번째는 대규모 코드베이스에서의 이해력 문제예요. 파일 몇 개짜리 작은 프로젝트에서는 잘 동작하지만, 실제 프로덕션 수준의 코드베이스 — 수백, 수천 개의 파일이 복잡하게 얽힌 환경에서는 코드 간의 의존 관계를 제대로 파악하지 못한다는 거예요. 한 파일을 고치면서 그 변경이 다른 파일에 미치는 영향을 고려하지 못하는 상황이 발생하는 거죠.

왜 이런 일이 생긴 걸까요

이 문제의 원인에 대해 여러 가설이 나오고 있는데요, 몇 가지를 살펴볼게요.

하나는 모델 업데이트에 따른 회귀(regression) 가능성이에요. 회귀란 소프트웨어를 업데이트했더니 이전에 잘 되던 게 안 되는 현상을 말해요. AI 모델도 마찬가지인데, 새 버전을 배포하면서 특정 영역의 성능이 의도치 않게 떨어질 수 있어요. 특히 LLM(대규모 언어 모델)은 워낙 복잡한 시스템이라, 한쪽을 개선하면 다른 쪽에서 예상치 못한 영향이 나타나기도 하거든요.

또 하나는 시스템 프롬프트나 도구 연동 방식의 변경이에요. Claude Code는 단순히 모델에 질문하는 게 아니라, 파일 읽기, 쓰기, 검색, 셸 명령 실행 등 다양한 도구를 조합해서 작업해요. 이 도구들을 연결하는 방식이 바뀌면 결과물의 품질에 직접적인 영향을 줄 수 있어요.

사용자들 중에는 "같은 프롬프트를 줘도 예전과 결과가 다르다"고 보고하는 분들이 많은데, 이건 모델 자체의 변화든 시스템 레벨의 변화든 뭔가가 바뀌었다는 강한 신호예요.

AI 코딩 도구 시장의 맥락에서 보면

이 이슈는 더 넓은 맥락에서 봐야 해요. 지금 AI 코딩 도구 시장은 정말 치열하거든요. Cursor는 자체 IDE로 개발자 경험을 통합하고 있고, GitHub Copilot은 에이전트 모드를 강화하고 있고, Windsurf(구 Codeium), Augment Code 같은 새로운 플레이어들도 계속 등장하고 있어요.

이 경쟁 속에서 한 가지 공통된 도전 과제가 있어요. 바로 "짧은 데모는 인상적인데, 실제 복잡한 작업에서 일관되게 잘 동작하느냐"라는 질문이에요. 10줄짜리 함수를 완성하는 건 대부분의 도구가 잘 하지만, 여러 모듈에 걸친 리팩토링이나 복잡한 버그 디버깅은 아직 어느 도구도 완벽하게 해내지 못하고 있어요.

Claude Code의 이번 이슈가 주목받는 이유 중 하나는, Claude Code가 기존에 이런 복잡한 작업에서 상대적으로 잘 동작한다는 평가를 받아왔기 때문이에요. 기대치가 높았던 만큼 실망도 큰 거죠.

한국 개발자에게 어떤 의미가 있을까요

국내에서도 AI 코딩 도구를 업무에 도입하는 팀이 빠르게 늘고 있어요. 이 사례에서 배울 수 있는 점이 몇 가지 있어요.

AI 도구에 대한 의존도 관리가 중요해요. AI 코딩 어시스턴트가 아무리 좋아도, 모델 업데이트 하나로 성능이 달라질 수 있다는 걸 이번 사례가 보여주고 있어요. 핵심 워크플로우를 특정 AI 도구에 완전히 의존하는 건 리스크가 있어요. 도구가 도와주는 건 좋지만, 도구 없이도 일할 수 있는 역량은 계속 유지해야 해요.

피드백 루프의 가치를 생각해볼 수 있어요. 이번 이슈가 GitHub에 공개적으로 논의되고, 다양한 사용자가 재현 사례를 공유하면서 문제의 윤곽이 잡혀가고 있어요. 오픈소스 커뮤니티에서의 이런 피드백 문화는 도구 개선에 직접적으로 기여하죠. 한국 개발자분들도 AI 도구를 쓰면서 느끼는 점을 적극적으로 리포팅하면, 개선에 영향을 줄 수 있어요.

도구 선택은 계속 재평가해야 해요. 3개월 전에 최고였던 도구가 지금은 아닐 수 있어요. 여러 도구를 번갈아 써보면서 자신의 워크플로우에 맞는 조합을 찾아가는 게 현실적인 전략이에요.