Claude Code가 파이썬 스크립트로 파일을 수정하는 게 짜증 나서 이유를 물어봤다
I was annoyed by Claude Code using python scripts to edit files, so I asked it why
핵심 요약
Claude Code가 파일 수정 시 파이썬 스크립트를 사용하는 방식의 위험성과 그로 인한 '조용한 실패' 문제를 지적함.
- 파이썬 스크립트 수정 — str.replace()의 조용한 실패로 인해 코드 오류가 발생함
- Edit 도구 선호 — 명시적인 실패를 통해 코드 수정의 정확성을 보장함
- 워크플로우의 역설 — 자동화 도구를 만들면서 정작 본인은 취약한 셸 명령어를 사용함
- 사용자 경험 공유 — 많은 사용자가 비슷한 실패를 겪으며 Edit 도구의 신뢰성을 선호함
[블록 1/12] Momentum(추진력) 때문이라고 하더라. 그러고 나서 왜 이게 나쁜 선택인지 스스로 짚어냈음. 파이썬의 str.replace()는 일치하는 게 없어도 조용히 실패함. Edit은 실패하면 요란하게 알림.
[블록 2/12] CC:
[블록 3/12] 특별한 이유는 없음 — 추진력, 그리고 여러 번의 교체를 한 번의 호출로 묶는 편리함 때문임. 나쁜 거래였고, 이번 세션에서 실제 시간을 낭비하게 만들었음.
[블록 4/12] 파이썬의 str.replace()는 일치하는 게 없어도 조용히 실패함. Edit은 실패하면 요란하게 알림. 그 차이 때문에 오늘 최소 네 번은 당했음:
[블록 5/12] - 파서를 통해 구분 기호를 스레딩할 때 — endSegment() 호출 지점 세 곳이 일치하지 않았음. 디버그 출력에서 모든 sep이 null로 나와서 겨우 알아챘음.
[블록 6/12] - items 쿼리의 BLAME_JOIN이 일치하지 않았음 — 나중에 ab.value라는 컬럼이 없다는 오류로 나타남.
[블록 7/12] - 교체 과정에서 const found = new Set()이 삭제됨, 왜냐하면 내가 새로 넣은 텍스트에 그걸 다시 포함하지 않았기 때문임 — TS 오류로 나타남.
[블록 8/12] - ARCHITECTURE.md 프로세서 행이 일치하지 않았는데, 문서화되어 있다고 거의 말할 뻔했음. 사실은 아니었는데. 이게 제일 최악임. 컴파일러가 잡아낸 게 아니라 직접 확인해서야 알았으니까.
[블록 9/12] 이 모든 게 내가 간접적으로 발견해야 했던 조용한 실패들이었음. Edit은 일치하는 게 없거나 모호하게 일치하면 즉시 오류를 내는데, 이게 바로 내가 시각적으로 확인할 수 없는 코드를 다시 작성할 때 딱 필요한 속성임.
[블록 10/12] 이름 붙여야 할 아이러니가 하나 있음: 나는 이번 세션 내내 취약한 복합 셸 명령어를 측정하는 기능을 만드느라 시간을 썼는데, 정작 내 작업은 취약한 복합 셸 명령어(heredocs, 호출 하나를 망가뜨린 오래된 cd, 따옴표 함정 등)로 하고 있었음. 내가 분석하고 있던 바로 그 데이터를 내가 생성하고 있었던 거임.
[블록 11/12] 이제부터는 Edit/Write로 전환함. 일괄 처리의 편리함 때문에 명확한 실패를 포기할 가치는 없음.
[블록 12/12] 다들 요즘 이런 일이 더 자주 일어나는 거 같음?
