Opus 5가 소스 코드 수정에 파이썬을 너무 자주 쓰는데?
Opus 5 really likes to use Python to edit source code?
핵심 요약
Claude Opus 5가 직접 파일을 수정하는 대신 파이썬 스크립트를 생성해 실행하는 현상에 대한 사용자들의 경험과 의견 공유.
- 파이썬 의존성 — 모델이 직접 수정 대신 파이썬 스크립트를 생성해 실행하는 비효율적 방식 선호함
- 토큰 절약 논란 — 대량 수정 시 토큰을 아끼기 위한 전략이라는 의견과 단순한 모델의 판단 오류라는 의견 대립
- 대안 도구 제안 — sed, rg, ast-grep 등 더 효율적이고 안정적인 도구 활용 가능성 제기
- 최근 성능 저하 — 최근 모델이 API 호출이나 코드 수정 시 불필요한 스크립트를 남발하며 오류를 범하는 현상 보고
Claude Desktop에서 Opus 5가 파일을 직접 수정 안 하고, 지 맘대로 수정/추가/삭제할 내용을 파이썬 스크립트로 짠 다음에 그걸 실행하더라고. 왜 그냥 바로 수정 안 하고 굳이 저러는지 모르겠음. 그래서 물어봤더니 Opus 5가 이렇게 답하네:
가장 큰 약점: Bash를 전용 도구보다 우선시하라는 자동 모드 지침을 따르고 있었음. 그 지침에는 Bash로 도저히 해결이 안 될 때만 전용 도구를 쓰라고 되어 있는데, 내가 그걸 너무 융통성 없이 해석해서 파이썬을 쓸 필요도 없는 상황까지 계속 파이썬을 갖다 쓴 거임.
그러다 보니 손해를 좀 봤지.
str.replace는 패턴 매칭이 안 돼도 에러 없이 그냥 넘어가 버리거든. 아무 일도 안 일어났는데 스크립트는 성공했다고 뜨는 거지.PrefillConfirmation지울 때 딱 걸렸음. 들여쓰기 틀렸는데 아무 반응도 없어서, 나중에grep돌려보고 나서야 겨우 알아챘네.Edit썼으면 바로 에러 났을 텐데 말이야. 나중에는 스크립트에if old not in s: raise SystemExit(...)같은 안전장치를 직접 넣기 시작했는데, 이건 뭐Edit가 공짜로 해주는 기능을 내가 굳이 다시 구현하고 앉아있는 꼴이지. heredoc도 따옴표 에러 때문에 한 번 터져서 스크래치패드 파일 거쳐 가야 했고, 내가 쓴 파일은 LF로 저장되는데 이걸 다시 CRLF로 바꾸느라 쌩쇼를 했음. 내가 자초한 일이라 라인 엔딩 장점도 다 까먹은 셈이지.결론: BOM/CRLF에 민감한 수정이나 여러 파일에 걸친 리팩토링할 때는 파이썬이 제값 함. 근데 아이콘 문자열이나 경고 문구, 메서드 하나 수정하는 것처럼 타겟이 명확한 작업은
Edit가 훨씬 안전하고 빠름. 앞으로는Edit쓰는 게 맞았음.원한다면 남은 브랜치 작업은
Edit로 전환할 수 있음. 어차피 남은 건 다 자잘한 수정들이라 그게 훨씬 나을 듯.
그리고 이 지랄 때문에 내 소스 코드 수정 내역이 아니라, 내 코드를 수정하는 Claude의 파이썬 스크립트 수정 내역만 요약해서 보여줌...
이거 원래 이런 거임? 그냥 강제로 직접 수정하게 시킬 수도 있는 건 아는데, 이런 행동 양식이 좀 신기해서. Codex 같은 거 쓸 때는 중간 단계 없이 항상 바로 수정했거든.


