2.1.215 올리고 나서 /verify 안 돌길래 버그인 줄 알고 한참 헤맸는데, 이게 의도된 변경입니다. 예전엔 스킬이 특정 조건에서 자동으로 끼어들었는데 이제 수동 호출로 바뀌었어요. /deep-research도 마찬가지고요.

이 변경 자체는 나쁘지 않은데, 문제는 기존 워크플로우가 조용히 깨진다는 점입니다. auto 모드에서 코드 짜다가 "알아서 검증하겠거니" 하고 넘기던 습관이 있으면 이제 검증 없이 그냥 지나갑니다. 자동으로 안 도니까요. 저는 CLAUDE.md에 "구현 완료 후 반드시 /verify를 제안하라"는 한 줄을 박아뒀는데, 이게 실측상 자동 호출보다 낫습니다. 왜냐하면 언제 검증할지를 제가 통제할 수 있거든요.

실전에서 진짜 쓸모 있는 조합은 /code-review를 커밋 직전에 수동으로 한 번 돌리는 겁니다. 자동으로 돌 때는 리팩터링 중간 어정쩡한 상태에서도 리뷰가 튀어나와서 노이즈가 심했어요. 수동이 되면서 "코드가 안정된 시점"에만 리뷰를 받을 수 있게 됐고, 리뷰 품질 자체가 체감상 올라갔습니다. 미완성 코드에 대한 지적이 사라지니까요.

한 가지 같이 봐둘 게, plan 모드의 정적 분석 처리가 바뀌었습니다. 예전엔 read-only 정적 분석기가 안전하다고 증명 못 하는 Bash 명령이 있으면 그냥 막았는데, 이제 auto-mode 분류기가 그걸 판단합니다. 즉 `find`나 파이프 섞인 명령이 plan 단계에서 통과되는 경우가 생겼다는 뜻입니다. 편해진 건 맞지만 분류기가 오판할 여지도 같이 생겼으니, plan 모드라고 무조건 안전하다는 전제는 버리는 게 낫습니다.

그리고 이번에 트랜스크립트에 각 메시지의 reasoning effort 수준이 기록되기 시작했는데, 이게 디버깅할 때 은근히 유용합니다. 답이 대충 나온 것 같으면 트랜스크립트에서 해당 메시지의 effort가 낮게 잡혔는지 확인할 수 있어요. 낮으면 프롬프트를 다시 구조화해서 재요청하면 되고요. 결과물 품질을 감으로 판단하던 걸 근거를 가지고 판단할 수 있게 된 셈입니다.

정리하는 대신 하나만 짚으면, 수동 호출 전환을 "귀찮아졌다"로 받아들이면 손해입니다. 자동 호출은 편했지만 통제권이 도구한테 있었고, 그게 미완성 코드에 대한 헛발질 검증으로 이어졌어요. 검증 타이밍을 사람이 쥐는 게 결과적으로 더 정확합니다. 다만 자동으로 안 도는 걸 모르고 검증 자체를 건너뛰는 사고는 조심하세요. CLAUDE.md에 제안 규칙 한 줄 넣는 걸로 대부분 방지됩니다.