작은 로컬 모델에서 코딩 에이전트를 실행할 때 발생하는 문제점

몇 주 동안 소형 로컬 모델(sub-7B)과 무료 티어의 소형 클라우드 모델로 실제 다중 파일 코딩 작업을 실행한 결과, Reddit 사용자는 일반적인 벤치마크 노이즈를 넘어서는 일관된 실패 지점을 문서화했습니다. 실제로 무엇이 문제인지 살펴보겠습니다.

마크다운 펜스가 가장 흔한 실패

시스템 프롬프트에 "원시 코드만 출력하고 마크다운 형식은 사용하지 마십시오"라고 명시해도, 대부분의 모델은 응답을 삼중 백틱으로 감쌉니다. Qwen3.5:9b와 Gemma4:e4b는 지침을 가장 일관되게 따르지만 여전히 가끔 실수합니다. 해결책은 더 나은 프롬프팅이 아니라 후처리에서 펜스를 기본적으로 제거하는 것입니다.

7B 미만에서는 구조화된 출력이 신뢰할 수 없음

에이전트가 작업 목록이나 작업 유형에 JSON이 필요할 때, 소형 모델은 벤치마크가 시사하는 것보다 훨씬 더 자주 실패합니다. 벤치마크는 유효한 JSON을 테스트하지만 실제 사용에서는 엣지 케이스가 포함된 복잡한 다단계 지침이 추가됩니다. Gemma4:e4b는 로컬 모델 중 가장 신뢰할 수 있고 Qwen3.5:9B가 그 뒤를 따릅니다. Codellama는 어려움을 겪습니다. 클라우드에서는 Groq의 Llama 3.3 70B가 매우 안정적입니다. 실용적인 해결 방법: JSON을 검증하고, 명시적 지침과 함께 한 번 재시도한 다음, 산문에서 JSON을 추출하는 관대한 파서로 폴백합니다.

모델이 잘못된 파일을 편집함

비슷한 이름의 프로젝트 맵과 함께 validateToken을 verifyToken으로 이름을 바꾸는 작업을 소형 모델에 주면, validateUser를 이름을 바꾸거나 완전히 다른 파일을 수정할 수 있습니다. 모델은 프로젝트 맵을 제약 조건이 아닌 제안으로 취급합니다. 오케스트레이션 계층에서 수정: 파일 경로가 존재하고 함수 이름이 주장된 파일에 있는지 확인합니다. 불일치 시 오류를 발생시킵니다. 소형 모델은 자신있게 거짓말을 합니다.

질문과 작업 분류

"utils.js의 줄 수는 얼마입니까?"와 같은 질문은 읽기 전용이어야 합니다. 그러나 실행기가 편집 모드 하나만 가지고 있다면, 답변을 포함하도록 파일을 편집할 것입니다. 해결 방법: 플래너는 실행 전에 요청을 작업 유형으로 분류해야 합니다. 읽기 전용 쿼리는 디스크에 절대 접촉하지 않는 별도 코드 경로로 라우팅됩니다.

예상보다 잘 작동한 것

• 코드 내 토큰 예산 강제: 매 호출 전에 토큰을 계산합니다. 소형 모델은 컨텍스트 제한 개념이 없으며 신뢰하면 간결해지지 않습니다.
• 파일별 격리: 한 번에 하나의 파일을 보내는 것이 두 개를 보내는 것보다 훨씬 안정적입니다. 모델이 수정 사항을 혼동합니다.
• 종합형 메모리: 전체 작업 목록 대신 모델이 수행한 작업에 대한 한 문장 요약을 저장합니다. 실행 취소 및 추가 요청에 효과적입니다.

아직 해결 중

7B 미만의 로컬 모델이 에이전트 역할에 적합한지 여부 — 저자는 구조화된 출력에서 충분히 자주 실패하지 않는 모델을 아직 찾지 못했습니다. 기여를 위한 오픈소스 테스트 도구는 github.com/razvannec에 있습니다.