작은 로컬 모델에 코딩 에이전트를 실행할 때 실제로 고장나는 점에 대한 노트

지난 몇 주 동안 작은 로컬 모델과 무료 티어에 있는 작은 클라우드 모델을 통해 실제 다중 파일 코딩 작업을 수행했습니다. 일부는 나를 놀라게 했기 때문에, 커뮤니티와 공유하여 누군가에게 도움이 되기를 바라는 마음으로 일관되게 나타났던 실패 지점을 공유하고 싶습니다.

마크다운 펜스 (Markdown fences) 는 제가 테스트한 모든 작은 모델에서 가장 흔한 오류입니다.

시스템 프롬프트에 "출력은 원본 코드만, 마크다운 포맷팅 없이"라고 넣을 수 있습니다. 모델이 동의합니다. 하지만 모델은 여전히 응답을 삼중 역따옴표 (triple backticks) 로 감싸버립니다. 특히 코드를 설명하는 것처럼 보이는 요청이 포함되면 더욱 그렇습니다. Qwen3.5:9b 와 gemma4:e4b 는 지시를 따르는 데 가장 일관되지만, 가끔씩도 실수합니다. 제 테스트 결과 다른 모델들은 이 규칙을 자주 위반하여 펜스가 있을 것이라고 기본적으로 가정해야 할 정도입니다.

해결책은 더 나은 프롬프팅이 아닙니다. 기본값으로 포스트-프로세싱에서 펜스를 제거하는 것입니다. 작은 모델을 사용하는 모든 코드 편집 도구는 이를 수행해야 합니다.

제 테스트 결과, 7B 파라미터 미만에서는 구조화된 출력 (structured output) 이 신뢰할 수 없습니다.

에이전트가 작업 목록 (예: 제 사례), 행동 유형 (action types), 또는 기계가 판독 가능한任何东西를 반환하도록 모델을 요구하는 경우, 작은 모델은 벤치마크가 시사하는 것보다 훨씬 더 자주 이러한 작업을 실패합니다. 벤치마크는 모델이 유효한 JSON 을 생성할 수 있는지 측정합니다. 복잡한 다단계 지시사항과 엣지 케이스 (edge cases) 가 포함된 상황에서 유효한 JSON 을 생성하는지 측정하지는 않습니다.

제 테스트 결과, 로컬 모델 중 Gemma4:e4b 가 구조화된 출력에서 가장 신뢰할 만했습니다. Qwen3.5:9B 가 그 뒤를 쫓고 있습니다. Codellama (모든 버전이나 오래됨) 는 어려움을 겪습니다. 클라우드 측면에서는 Groq 의 Llama 3.3 70B 가 구조화된 출력에 있어 매우 견고했습니다 (가장 일관성이 있었습니다). OpenRouter 의 다른 모델들 (예: Nemotron 3 super) 은 일부 특이점을 보였습니다. 예: Nemotron 3 super 는 매우 좋았지만, 토큰 사용량이 100k 에 도달했을 때 openrouter 에서 응답을 멈췄습니다.

실용적인 우회책은 JSON 을 검증하고, 더 명시적인 지시로 한 번 재시도한 다음, 산문으로 감싸진 응답에서 JSON 을 추출할 수 있는 관대 (permissive) 한 파서로 회귀하는 것입니다.

모델이 수정할 파일을 허용하면 잘못된 파일을 편집합니다.
작은 모델에 함수 이름을 언급하고, 유사한 함수 이름을 나열하는 프로젝트 맵 (project map), 그리고 "validateToken 을 verifyToken 으로 이름 변경"과 같은 요청을 주는 경우 (제 테스트의 실제 예시). validateToken 을 올바르게 이름 변경할 수도 있습니다. 하지만 validateUser 를 이름 변경하거나, 해당 함수를 언급하는 주석을 수정하거나, 완전히 잘못된 파일에 이름 변경을 적용할 수도 있습니다. 모델은 프로젝트 맵을 제약조건이 아닌 제안으로 취급합니다.

해결책은 프롬프트가 아니라 오케스트레이션 레이어 (orchestration layer) 에 있습니다. 모델이 언급한 파일 경로가 실제로 존재하는지 검증하세요. 모델이 조작한다고 주장하는 함수 이름이 그들이 있다고 주장하는 파일에 실제로 있는지 검증하세요. 불일치가 있을 때 명확한 오류를 발생시키세요. 작은 모델은 자신감 있게 거짓말을 하고 에이전트는 그들을 신뢰해서는 안 됩니다.

질문과 행동 분류 (question vs action classification) 는 생각보다 어렵습니다.
"utils 에 몇 줄이 있는지"라고 물을 경우...