[분석] Cursor의 Tab은 왜 대형 리팩터링에서 손해를 보는가

Cursor의 Tab(예측 자동완성)은 다음 편집 위치까지 점프해 연쇄 수정을 제안하는 모델로, 변수명 일괄 변경이나 import 정리 같은 국소적·반복적 작업에서 압도적으로 빠르다. 문제는 이 강점이 그대로 함정이 되는 지점이다. 시그니처를 바꾸는 광역 리팩터링에서 Tab은 '바로 다음 한 곳'을 그럴듯하게 채워주지만 전체 호출부의 정합성을 보장하지 않아, 컴파일은 통과하는데 의미가 어긋난 코드가 분산 누적된다. 반면 Composer 에이전트 모드는 grep으로 호출부를 전수 수집하고 한 번에 일관 변경을 시도하지만 그만큼 토큰과 시간이 든다. 실무 결론은 도구 분할이다. 타입이 잡아주는 기계적 변경은 Tab, 동작 의미가 바뀌는 변경은 에이전트에 맡기고 diff를 통째로 리뷰한다. Tab을 리팩터링 엔진으로 착각하면 '초록불인데 틀린' 코드가 PR에 섞여 들어온다.