Cursor에서 일주일 사용 후 모델에 대한 신뢰를 잃게 만드는 요인은 무엇인가요?

모델을 바로 벤치에 앉히는(사용 중단하는) 경우는, 존재하지 않는 API를 지어내고는 그 함수가 실재하지 않는다는 걸 인정하는 대신 자기 환각을 디버깅할 때입니다. 잘못된 답변은 복구할 수 있지만, 틀린 걸 알면서도 우기는 루프는 답이 없죠. 또 다른 적신호는 코드가 아니라 테스트를 수정해서 실패하는 테스트를 '고치는' 경우입니다. 세션 중에 이걸 두 번만 겪으면 신뢰는 끝입니다.

아무것도 해결 안 되는데 진척되는 느낌 주는 거, 이게 제일 거슬림. 모델이 그럴듯한 코드 짜고 테스트도 통과하는데 정작 할 일은 안 끝남. 아무도 안 시킨 곁가지 문제만 해결하고 정작 핵심 이슈는 반쯤 남겨둠. 결국 diff만 커지고 티켓은 그대로 열려있음.

관련 없는 파일을 건드리는 게 제일 화나요. 그냥 함수 하나 고쳐달라고 했는데 왜 내 유틸리티 폴더 전체를 리팩토링하는 거죠?

보통 세션 길이 때문이죠. 관련 없는 파일 수정, 스타일 변경, 이미 존재하는 코드 재작성 같은 드리프트 패턴은 컨텍스트 과부하와 밀접하게 연관되어 있습니다. 복잡한 리포지토리에서 20번 정도 턴이 지나면 이런 현상이 확실히 나타나기 시작해요. 긴 세션 하나를 계속 쓰는 것보다, 짧게 세션을 끊고 마지막에 명시적인 상태 파일을 작성하는 게 신뢰 유지에 훨씬 좋습니다.

결국 인간은 항상 필요함. 여러 모델 써보니까 제일 좋은 건 Cloud LLM으로 전체 계획 짜고, Cursor한테 검토받으면서 추천받는 거더라. 빌드할 땐 싼 모델 쓰고, 디버깅이나 수정 필요할 때만 비싼 모델 쓰는 게 최고임. 90%는 싼 모델로 밀고 나가셈. 가끔은 비싼 모델 아예 안 써도 됨.