# AI 코딩툴 오류를 전부 “모델이 멍청해서”라고 보면 원인을 놓침 Claude Code, Codex, Gemini CLI 같은 도구를 쓰다...
Canonical: https://social-archive.org/yena/7let6dfQ9I
Original URL: https://x.com/cso6709/status/2068885667518816536
Author: 돈미새
Platform: x
## Content
AI 코딩툴 오류를 전부 “모델이 멍청해서”라고 보면 원인을 놓침 Claude Code, Codex, Gemini CLI 같은 도구를 쓰다 보면 답변보다 실행 단계에서 문제가 터지는 경우가 많음 명령이 실패하고, API 키가 꼬이고, 터미널 출력이 끊기고, 파일 권한이 맞지 않는 식임 이때 모델만 바꾸면 해결될 것처럼 보이지만 실제 병목은 도구 연결 구조일 때가 많음 AI 코딩툴을 실무에서 볼 때는 답변 품질과 실행 안정성을 분리해야 함 모델이 좋은 코드를 제안해도 파일 수정, 패키지 설치, 테스트 실행, Git 상태 확인 과정이 깨지면 결과물은 불안정해짐 판단 기준은 세 가지임 첫째, 오류가 “생각”에서 났는지 “도구 호출”에서 났는지 나눠야 함 잘못된 로직을 제안한 건 추론 문제임 하지만 명령 실행 실패, 경로 오류, 인증 실패, 패키지 충돌은 도구 계층 문제임 둘째, 한 번에 고치는 범위를 줄여야 함 AI에게 “전체 리팩터링하고 테스트까지 해줘”라고 맡기면 어디서 깨졌는지 추적하기 어려움 파일 1개 수정, 테스트 1개 실행, diff 1회 확인처럼 단계를 작게 잘라야 함 셋째, 로그를 결과물보다 먼저 봐야 함 성공했다는 요약보다 실제로 어떤 명령이 실행됐고 어떤 파일이 바뀌었는지가 더 중요함 특히 Cursor나 CLI 기반 도구에서는 터미널 출력, 실패 코드, 변경 diff가 검수 기준이 됨 나쁜 사용법은 에러가 날 때마다 더 강한 모델로 바꾸는 방식임 좋은 사용법은 실패 위치를 모델, 도구 호출, 환경 설정, 권한 문제로 분해하는 방식임 실전 프레임은 “요청 → 변경 → 실행 → 로그 → diff → 테스트” 순서임 AI 코딩툴을 잘 쓰는 사람은 프롬프트를 길게 쓰는 사람이 아니라 실패가 난 계층을 빨리 찾는 사람임