Simon의 AI 시대에 살아남는 법
설치를 마쳤으니 이제 실측이다. Aider가 설치된 ~/Projects/pipeline-test 저장소에서, 모델별로 git 브랜치를 나눠 완전히 동일한 프롬프트를 던졌다.
간단한 계산기 모듈을 만들어줘. add, subtract, multiply, divide 함수와
각각의 pytest 테스트 코드도 함께 작성해줘.
의도적으로 아주 쉬운 작업을 골랐다. 이 정도도 제대로 못 하면 더 복잡한 작업은 아예 시도할 이유가 없기 때문이다.
결과 요약
| 모델 | 소요 시간 | 결과 | 비고 |
|---|---|---|---|
| Qwen3-Coder-30B | ~30분 | ✅ 성공 | flake8 자동 수정까지 완료. 요청하지 않은 거듭제곱·나머지·제곱근·팩토리얼 함수를 임의로 추가함 |
| Qwen2.5-Coder-7B | — | ❌ 실패 | whole·diff 포맷 둘 다 신뢰 불가 (아래 상세) |
| DeepSeek-Coder-V2-16B | 9분 30초 | ✅ 성공 | 가장 빠름. flake8 일부 미해결 |
| Qwen2.5-Coder-14B | 27분 43초 | ✅ 성공 | 가장 느림. flake8은 완전히 깨끗하게 해결 |
7B가 두 번 다 무너진 이유
가장 작은 모델인 Qwen2.5-Coder-7B는 흥미로운 실패 방식을 두 개나 보여줬다.
1차 시도 (whole 포맷): 채팅창에는 그럴듯한 코드가 출력됐다. 사람이 읽으면 “잘 됐네"라고 생각할 만한 결과물이었다. 그런데 실제로는 파일이 디스크에 전혀 쓰이지 않았고 커밋도 없었다. git log를 확인하니 브랜치가 main과 완전히 동일했다. 채팅 응답의 겉모습만으로는 성공 여부를 판단할 수 없다는 걸 이때 알았다 — 무인 자동화에서는 특히 위험한 실패 패턴이다.
2차 시도 (diff 포맷): 이번엔 SEARCH/REPLACE 방식으로 재시도했는데, 무한 재시도 루프에 빠졌다. 원인은 모델이 **실제 파일 내용을 정확히 재현하지 못하고 살짝 다르게 “환각”**했기 때문이다.
<<<<<<< SEARCH
def add(a, b):
"더하기"
return a + b
=======
def add(a, b):
"""두 수를 더하는 함수"""
return a + b
>>>>>>> REPLACE
실제 파일에는 docstring이 없는데, 모델은 자기가 방금 썼다고 착각한 버전을 SEARCH 블록에 넣어버린 것이다. Aider의 diff 포맷은 SEARCH 블록이 기존 파일과 한 글자도 틀리지 않고 일치해야 적용되기 때문에, 이 불일치가 반복되면서 재시도만 쌓였다.
두 실패 모두 “느려서"가 아니라 “믿을 수 없어서” 탈락한 케이스다. 결국 이 모델은 삭제했다.
ollama rm qwen2.5-coder:7b
DeepSeek 테스트에서 겪은 “멈춘 줄 알았던” 순간
DeepSeek 테스트 중에는 이런 메시지가 반복해서 떴다.
/Users/simon/Projects/pipeline-test/calculator.py: file not found error
Dropping calculator.py from the chat.
처음엔 “이거 모델 성능 문제 아니야?“라는 의심이 들었다. 그런데 원인을 추적해보니 완전히 다른 문제였다. 이전 테스트에서 파일을 rm으로만 지우고 git 커밋을 안 한 상태였던 것 — git은 여전히 파일이 있다고 기록하고 있는데 실제 디스크엔 없으니, Aider의 whole 편집 포맷이 “수정할 파일이 존재하지 않는다"며 거부한 것이다.
git add -A && git commit -m "chore: clean up for deepseek test"
이렇게 삭제를 제대로 커밋하고 Aider를 새로 시작하니 곧바로 정상 동작했다. 모델은 죄가 없었고, git 상태 정리를 빼먹은 내 실수였다.
zsh는 #을 주석으로 안 읽는다
테스트 도중 모델을 내려주려고 아래 명령을 실행했는데,
ollama stop deepseek-coder-v2:16b # 명시적으로 언로드
이런 에러를 만났다.
Error: accepts 1 arg(s), received 4
bash와 달리 대화형 zsh는 인라인 # 주석을 기본으로 지원하지 않는다. 뒤에 붙인 한글 설명이 그대로 명령어 인자로 파싱되어버린 것. 이후로는 명령어 뒤에 절대 주석을 붙이지 않는 습관을 들였다.
14B는 느렸지만 제일 깔끔했다
Qwen2.5-Coder-14B는 27분 43초로 가장 오래 걸렸지만, 결과물의 완성도는 가장 높았다. flake8 검사에서 다른 세 모델은 크고 작은 스타일 오류를 남겼는데, 14B만 유일하게 에러 0건으로 마무리됐다. 다만 이 과정에서 auto-lint 재시도 루프가 걸리며 llama-server가 재시작되는 걸 목격했는데 — 이 현상이 왜 일어나는지, 그리고 이게 실전 규모 작업에 어떤 의미인지는 다음 글에서 다룬다.
💬 댓글