코드베이스가 커질수록 AI 코딩 에이전트가 더 나빠지는 이유
Source: Dev.to
대부분의 사람들은 코드베이스가 커짐에 따라 AI 코딩 에이전트가 점점 나빠지는 것을 눈치채지 못합니다.
모델 자체가 퇴화해서가 아니라, 컨텍스트가 한계에 도달하기 때문입니다.
패턴
50개 파일: Claude Code 또는 Cursor가 코드베이스의 충분한 부분을 파악해 컨벤션을 따르고, 유틸리티를 재사용하며, 중복을 피합니다. 출력이 일관됩니다.
500개 파일: 이제는 불가능합니다. 이미 세 폴더 떨어진 곳에 존재하는 헬퍼를 다시 구현하고, 나머지와 충돌하는 네이밍 컨벤션을 도입하며, 아무도 호출하지 않을 함수를 생성하고, “버그를 고친다”는 식으로 우회책을 겹겹이 쌓아버립니다.
모델이 더 똑똑해진 것이 아니라, 전체 프로젝트를 머릿속에 담아둘 수 없게 된 것입니다.
결과: 코드베이스는 처음엔 빠르게 배포되지만, 곧 자체 무게에 짓눌려—죽은 코드, 숨겨진 중복, 선택적인 베스트 프랙티스 적용 등—AI‑지원 코딩이 약속한 것과는 정반대의 상황에 빠집니다.
왜 아무도 이를 잡지 못하는가
- 린터는 문법을 잡아냅니다.
- 타입 체커는 타입을 잡아냅니다.
- 테스트 러너는 깨진 계약을 잡아냅니다.
하지만 아키텍처 부패와 같이 AI가 만든 코드가 초래할 수 있는 문제는 잡아내지 못합니다.
문제를 드러내는 전형적인 질문들:
- “이 함수가 어디서든 사용되고 있나요?”
- “다른 이름으로 이미 존재하는 코드가 있나요?”
- “우리가 이 문제를 세 가지 다른 방식으로 해결한 적이 있나요?”
- “이 코드가 나머지 코드베이스의 컨벤션을 따르고 있나요?”
이 질문에 답하려면 전체 프로젝트에 대한 전체적인 이해가 필요합니다—전통적인 도구로는 제공할 수 없는 것이죠. 코드를 만든 AI에게 리뷰를 요청하는 것은 여우에게 닭장을 지키게 하는 것과 같습니다.
처음에 시도한 것
다음과 같이 실험했습니다:
- 더 큰 컨텍스트 윈도우
- 더 엄격한 시스템 프롬프트 (예: “새 함수를 만들기 전에 이 함수가 이미 존재하는지 확인해 주세요.”)
때때로 도움이 되긴 했지만, 대부분의 경우 에이전트는 자신의 주장을 검증할 신뢰할 만한 방법이 없었기 때문에 조용히 실패했습니다. 이미 존재하는 함수를 새 것으로 착각하고 자신 있게 독창성을 주장하곤 했습니다.
만든 것
Anatoly 라는 오픈‑소스 감사 에이전트를 만들었습니다. 이 에이전트는 코드베이스의 모든 파일을 순회하며 증거 기반 리뷰를 생성합니다.
핵심 규칙: 모든 발견은 보고되기 전에 반드시 증명되어야 합니다. 에이전트가 어떤 함수가 죽은 코드라고 주장하면, 두 번째 에이전트가 읽기 전용 도구 (grep, glob, read)를 사용해 전체 프로젝트를 검사해 확인합니다. 증거 없는 주장은 허용되지 않으므로, 환각에 의한 잘못된 발견이 사라집니다.
내부 동작
- AST 파싱: Tree‑sitter 사용
- 읽기 전용 도구 (Glob, Grep, Read)를 갖춘 Claude 에이전트가 프로젝트 전체를 조사
- 로컬 의미론적 RAG 인덱스 (Xenova 임베딩 + LanceDB)로 grep으로는 찾기 힘든 파일 간 중복을 탐지
- Zod를 이용한 스키마 검증 및 잘못된 JSON을 자동 교정하는 루프
사용법
npx anatoly run다음 단계
원격 감사 워크플로우를 개발 중입니다. Anatoly가 원격 서버에서 여러분이 잠든 사이에 실행되고, 구조화된 보고서를 GitHub 저장소에 직접 게시합니다(이슈 또는 PR 코멘트 형태). 그리고 다음 날 아침에 바로 처리할 수 있는 깔끔한 발견 리스트를 제공합니다. 로컬 비용 없이, 대기 시간 없이, 컨텍스트 전환 없이 진행됩니다.
레포 찾고 있습니다
Anatoly는 AGPL‑3 라이선스로 공개된 오픈‑소스 프로젝트입니다. 모델을 정교화하고 엣지 케이스를 발굴하기 위해 무료로 스캔해줄 코드베이스를 찾고 있습니다. 감사받고 싶은 프로젝트가 있다면—조건 없이—댓글을 남기거나 레포에 이슈를 열어 주세요.
Repository:
팀에서 AI‑생성 코드 부패를 어떻게 다루고 있나요? 다른 사람들도 같은 패턴을 겪고 있는지 궁금합니다.