AI 코딩 에이전트의 숨겨진 성능 저하 곡선
처음 AI 에이전트를 팀에 도입했을 때 체감하는 생산성 향상은 실제다. 파일 50개짜리 프로젝트에서 Claude Code나 Cursor는 기존 유틸리티를 잘 재사용하고, 네이밍 컨벤션을 따르며, 중복을 피한다. 숫자로도 나온다—초기 개발 속도 2~3배 향상, 보일러플레이트 작성 시간 80% 절감. 팀 리드 입장에서 ROI 계산이 쉬워 보이는 구간이다.
그런데 파일이 500개를 넘어서는 순간, 문제가 시작된다. dev.to의 분석에 따르면 이건 모델이 나빠져서가 아니다. 컨텍스트가 무너지기 때문이다. AI 에이전트는 전체 프로젝트를 '머릿속에 담을' 수 없는 상태가 되고, 그 결과 세 폴더 건너편에 이미 존재하는 헬퍼를 다시 구현하고, 나머지 코드베이스와 충돌하는 네이밍 컨벤션을 도입하며, 아무도 호출하지 않을 함수를 생성한다. 버그를 '고치는' 척하면서 사실은 워크어라운드를 워크어라운드 위에 쌓는다.
기존 툴이 잡지 못하는 '아키텍처 로트'
더 나쁜 건, 이 문제를 기존 품질 도구가 감지하지 못한다는 점이다. 린터는 문법을 잡고, 타입 체커는 타입을 잡고, 테스트 러너는 깨진 계약을 잡는다. 하지만 "이 함수가 이미 다른 이름으로 존재하는가?", "같은 문제를 세 가지 방식으로 세 번 풀고 있지는 않은가?" 같은 질문은 파일 하나가 아니라 전체 프로젝트를 이해해야 답할 수 있다. 그리고 그 코드를 작성한 AI 에이전트에게 리뷰를 맡기는 건—원문의 표현대로—"여우에게 닭장을 지키게 하는 것"이다.
이 문제의 해답으로 등장한 것이 Anatoly 같은 별도의 감사(audit) 레이어다. 코딩 에이전트와 독립된 별도 에이전트가 코드베이스 전체를 순회하며, 모든 발견 사항에 증거를 요구하는 방식이다. tree-sitter로 AST를 파싱하고, 읽기 전용 도구(Grep, Glob, Read)로 검증하며, 로컬 시맨틱 RAG 인덱스로 grep이 잡지 못하는 크로스 파일 중복까지 탐지한다. 팀에 이런 독립적인 검증 레이어가 없다면, AI가 빠르게 쌓은 기술부채는 조용히 누적된다.
비용 압력: 토큰 소모와 로컬 LLM의 현실적 트레이드오프
코드베이스가 커지면 컨텍스트 문제만 생기는 게 아니다. 토큰 비용도 폭증한다. Claude Code는 파일을 많이 읽는 도구다. 프로젝트가 복잡해질수록 에이전트가 소비하는 컨텍스트 윈도우는 커지고, API 비용은 선형이 아니라 기하급수적으로 늘어나는 느낌을 준다.
이 비용 압력의 현실적 대안으로 Docker Model Runner를 활용한 로컬 LLM 연결이 주목받고 있다. 설정 자체는 단순하다—ANTHROPIC_BASE_URL을 로컬 엔드포인트로 오버라이드하면 Claude Code의 인터페이스를 그대로 유지하면서 Phi4 같은 로컬 모델을 백엔드로 쓸 수 있다. 클라우드 비용 제로, 프라이빗 코드베이스 보호, 인터넷 없는 환경 대응까지 세 가지 문제를 동시에 해결한다.
그러나 팀 리드로서 이 선택의 트레이드오프를 냉정하게 봐야 한다. 로컬 모델은 비용은 줄이지만 품질도 줄인다. Phi4 14B는 Claude 3.5 Sonnet이 아니다. 특히 코드베이스가 커질수록 더 강한 추론 능력이 필요한 상황에서, 비용 절감을 위해 모델 품질을 낮추면 앞서 말한 컨텍스트 붕괴 문제가 더 빨리, 더 심각하게 나타난다. 컨텍스트 크기 설정(--context-size 32000 같은 옵션)을 적극적으로 튜닝해야 하는 이유가 여기 있다.
Anthropic의 인프라 확장이 주는 신호
Anthropicl은 스페이스X의 Colossus 1 데이터센터 전체 연산 용량 확보로 300MW 이상, 엔비디아 GPU 22만 개 규모의 컴퓨팅을 추가했다. 그 직접적인 결과가 Claude Code 사용 한도 2배 확대다. Pro·Max·Team·Enterprise 요금제 모두 5시간 기준 사용량이 두 배로 늘었고, 피크 시간 제한도 폐지됐다.
이 뉴스를 단순한 용량 업그레이드로 읽으면 절반만 본 것이다. Anthropic이 Amazon·Google·Microsoft·NVIDIA와 수 GW급 인프라 계약을 잇달아 체결하는 흐름은, 클라우드 기반 AI 코딩 에이전트의 단위 비용이 구조적으로 낮아지는 방향을 가리킨다. 지금 로컬 LLM으로 비용을 절감하는 전략이 6개월 뒤에도 최선인지는 다시 계산해봐야 한다.
팀 리드가 지금 당장 설계해야 할 것
세 가지 데이터 포인트를 합치면 하나의 실용적 결론이 나온다. AI 에이전트의 ROI는 코드베이스 규모에 따라 비선형으로 변한다. 초기엔 빠르게 오르고, 특정 임계점 이후엔 컨텍스트 붕괴·비용 폭증·품질 로트가 동시에 찾아온다.
지금 팀에 필요한 설계는 세 가지다:
- 감사 레이어 분리: 코딩 에이전트와 독립된 감사 에이전트를 워크플로우에 삽입한다. Anatoly처럼 증거 기반으로 작동하는 도구를 CI 파이프라인에 연결해 아키텍처 로트를 조기에 탐지한다.
- 비용·품질 트레이드오프 매핑: 로컬 LLM은 탐색·프로토타이핑 단계에서 쓰고, 코드베이스 전체를 이해해야 하는 리팩터링·설계 작업에는 클라우드 모델을 유지한다. 작업 유형별로 모델을 분기하는 워크플로우가 필요하다.
- 컨텍스트 예산 관리: 에이전트에게 넘기는 태스크의 컨텍스트 범위를 명시적으로 제한한다. 전체 코드베이스를 한 번에 읽히는 게 아니라, 작업 단위로 격리된 컨텍스트를 주입하는 설계가 규모가 커져도 품질을 유지하는 핵심이다.
AI 에이전트는 코드베이스가 작을 때 가장 빛난다. 하지만 팀이 실제로 가치를 뽑아야 하는 건 코드베이스가 커진 이후다. 그 구간을 설계하지 않으면, AI는 빠른 속도로 틀린 방향을 달리는 도구가 된다.