모델을 탓하기 전에 Ollama 고유의 두 가지 요소를 배제할 가치가 있다. 첫째는 컨텍스트 길이다. Ollama의 기본 num_ctx는 서브에이전트 환경에 필요한 값에 비해 작다(버전과 VRAM에 따라 다르지만 종종 수천 토큰 수준에 그친다). 컨텍스트는 조용히 잘리기 때문에 시스템 프롬프트, 도구 스키마, 파일 내용이 이 값을 초과하는 순간 모델은 편집 중인 줄을 문자 그대로 볼 수 없게 되어 들여쓰기를 추측하기 시작한다. 이는 바로 공백을 고치는 무한 루프로 나타나는 현상이다. 실행 중에 ollama ps를 확인하거나 Modelfile에 PARAMETER num_ctx 32768을 설정하거나 API 옵션으로 전달한 뒤 문제가 해결되는지 확인해 보라.

팁에 감사한다. 컨텍스트는 문제가 아니다. 이는 신중하게 관리되고 에이전트에 고정되어 있다. 다만 샘플링은 확인해 볼 만한 요소일 수 있다.

나만 그런 것이 아니다. Qwen 모델과 공백 문제로 같은 현상을 겪은 적이 있다. 이 모델들은 함수 본문에 탭 하나가 더 필요하다고 멋대로 판단한 뒤 스무 사이클 가까이 그것을 앞뒤로 고치는 데 시간을 소모한다. 이상한 점은 복잡한 리팩터링은 한 번에 완벽하게 처리하면서 세 줄짜리 YAML 파일에서는 넘어진다는 것이다. 실제 편집 범위 밖의 들여쓰기 변경이 포함된 diff를 거부하는 엄격한 pre-commit 훅을 추가하기 시작했더니 루프 문제가 크게 줄었다. GLM 4.7 Flash는 코드베이스 학습 방식 덕분인지 블록 구조에 대한 내부 감각이 더 뛰어난 것으로 보인다. Qwen은 가끔 그런 식으로 행동하는 모습을 보인다.

흠, 정말 이상하다. 그런데도 사람들은 Qwen이 코딩에 훨씬 뛰어나다고 계속 주장하는 반면, 이런 문제는 실사용을 그대로 망가뜨린다. 나는 GLM을 계속 사용하면서 약간 더 큰 모델을 구동할 수 있도록 머신 업그레이드를 위해 노력해 볼 생각이다.

혹시 탭 들여쓰기를 사용하고 있는가. JSON 기반 도구에서는 탭이 토큰을 더 소모하는 것과 별개로 일부 모델에 문제가 된다는 점을 발견했다. 공백의 경우 시험해 본 모델들은 1부터 32까지 모든 길이에 전용 토큰을 두고 있어 들여쓰기가 보통 단일 토큰으로 처리된다. 반면 JSON 문자열로 표현된 탭은 모델에게 긴 \t\t\t\t 문자열로 보인다. Qwen은 적어도 \t 토큰을 갖고 있어 백슬래시와 t를 번갈아 인식하는 Gemma보다는 낫지만 그래도 기억해야 할 부담은 더 크다. 그래서 원래 탭을 선호해 왔음에도 AI 보조 코드에서는 공백으로 전환해야 했다.