Claude Code를 쓰다 보면 어느 순간 청구서가 신경 쓰이기 시작한다. 단순히 파일 내용을 읽어오거나 grep 결과를 정리하는 작업에도 토큰이 꼬박꼬박 빠져나가는 구조이기 때문이다. 그래서 요즘 실무자들 사이에서 자주 나오는 질문이 있다. “서브에이전트 작업 일부를 로컬 LLM으로 돌리면 실제로 얼마나 아낄 수 있을까?”
설정은 생각보다 단순하다
Claude Code는 서브에이전트 호출 시 OpenAI 호환 API 엔드포인트를 지정할 수 있다. LM Studio가 로컬에서 http://localhost:1234/v1` 형태로 서버를 띄워주면, 프로젝트의CLAUDE.md` 또는 환경 설정에서 해당 엔드포인트를 가리키도록 하면 된다. 모델명은 LM Studio에서 로드한 모델 이름 그대로 넣어주면 되고, API 키는 빈 문자열이나 더미 값으로도 통과한다. 로컬 서버가 OpenAI 스펙을 흉내 내는 구조이므로 Claude Code 입장에서는 외부 API와 동일하게 동작한다고 판단한다.
실제 설정 예시를 간단히 적으면, CLAUDE.md 안에 서브에이전트 모델 엔드포인트로 http://localhost:1234/v1`을, 모델명으로qwen2.5-32b-instruct` 같은 식으로 지정한다. 이후 Claude Code가 해당 서브에이전트 작업을 생성할 때 Anthropic 서버가 아닌 로컬 프로세스를 호출하게 된다.
어떤 작업에 붙이면 효과적인가
로컬 LLM이 빛을 발하는 구간은 판단보다 처리가 중심이 되는 작업이다. 파일 10개를 읽고 각각의 요약을 뽑는 작업, 디렉터리 구조를 순회하며 특정 패턴을 설명하는 작업, grep으로 뽑아낸 수백 줄의 로그를 카테고리별로 분류하는 작업이 여기에 해당한다. 이런 작업들은 정답이 명확하고, 틀려도 재작업 비용이 낮으며, 무엇보다 반복적으로 발생한다. Claude 3.5 Sonnet을 쓸 때와 Qwen2.5 32B 로컬 모델을 쓸 때 결과물의 품질 차이가 체감상 크지 않다.
코드 설명도 마찬가지다. 이미 작성된 함수의 동작을 자연어로 풀어내거나, 커밋 메시지 초안을 뽑거나, 변수명 후보를 몇 개 제안하는 수준의 작업은 로컬 32B급 모델로도 충분히 대응된다. 특히 컨텍스트 윈도우가 짧아도 되는 단발성 작업이라면 더더욱 그렇다.
하지만 대체할 수 없는 구간도 분명 있다
반면 아키텍처 설계처럼 여러 제약 조건을 동시에 고려해야 하는 작업, 수천 줄짜리 코드베이스를 전체적으로 파악한 상태에서 수행하는 리팩토링 제안, 또는 오류의 원인을 찾기 위해 스택 트레이스와 소스 코드를 교차 분석해야 하는 디버깅에서는 로컬 모델이 오히려 독이 된다. 틀린 답을 자신 있게 내놓는 경향이 있고, 그 결과물을 Claude Code가 그대로 믿고 다음 단계를 진행하면 결국 되돌리는 데 더 많은 토큰이 쓰인다.
긴 컨텍스트가 필요한 작업도 주의해야 한다. 로컬 32B 모델은 실제로 32k~64k 토큰을 처리할 수는 있지만, 컨텍스트 후반부로 갈수록 앞의 내용을 흘리는 현상이 잦다. Claude Sonnet 계열이 긴 컨텍스트에서 훨씬 안정적인 이유가 여기에 있다.
숫자로 따져보면
실제 비용을 단순화해서 비교해 보면 차이가 꽤 도드라진다. Claude 3.5 Sonnet 기준으로 입력 1백만 토큰에 3달러, 출력 1백만 토큰에 15달러다. 단순 파일 요약 작업 100회를 돌린다고 가정하면, 요청당 평균 2000토큰 입력에 500토큰 출력이 나온다고 볼 때 100회 작업에 약 0.135달러가 든다. 작아 보이지만 이런 서브에이전트 작업이 하루에 수백, 수천 회 발생하는 팀 환경에서는 달라진다. 월 단위로 따지면 적게는 수십 달러에서 많게는 수백 달러 규모가 된다.
로컬 Qwen2.5 32B를 M4 Pro 맥북에서 구동하는 경우, 추론 비용은 전기세와 하드웨어 감가상각뿐이다. 실질적으로 개인 사용자 기준에서는 거의 0에 가깝다. 같은 100회 작업을 로컬로 돌리면 API 청구는 없다. 다만 속도는 Claude API보다 느리다. 16GB 통합 메모리 환경에서 Qwen2.5 32B를 4비트 양자화로 돌리면 토큰 생성 속도가 초당 15~25토큰 수준이어서, 빠른 응답이 필요한 대화형 작업에는 체감 지연이 있다.
이미지 출처: Unsplash
품질 트레이드오프를 빠뜨리면 계산이 틀린다
비용만 보면 무조건 로컬이 유리해 보이지만, 실수 비용을 넣으면 그림이 달라진다. 로컬 모델이 잘못된 요약을 반환했을 때, Claude Code가 그 정보를 바탕으로 다음 단계를 진행한 뒤에야 오류가 발견되는 시나리오를 생각해 보자. 그 시점까지 쌓인 컨텍스트를 다시 처리하고, 올바른 방향으로 재안내하는 과정에서 오히려 더 많은 Claude API 토큰이 소모될 수 있다. 따라서 “단순하고 검증 가능한 출력을 요구하는 작업”이라는 기준을 철저히 지키는 것이 핵심이다. 출력이 맞는지 틀린지를 즉시 판단할 수 있는 작업만 로컬에 넘겨야 한다.
결국 로컬 LLM 서브에이전트 전략은 전면 대체가 아니라 계층 분리다. 단순 처리 레이어는 로컬로, 추론과 판단이 필요한 레이어는 Anthropic API로 분리하는 방식이 실무에서 안정적으로 작동한다. LM Studio가 점점 더 안정화되고, Qwen이나 Llama 계열 로컬 모델의 성능이 꾸준히 올라오는 흐름을 보면, 이 전략의 유효 범위는 앞으로 더 넓어질 가능성이 크다. 지금 당장 완벽한 자동화를 기대하기보다는 작업 유형별로 라우팅 규칙을 조금씩 다듬어 나가는 접근이 현실적이다.
출처