M3 벤치마크 점수는 좋아 보이지만, 난 Cursor가 없는 파일 좀 안 만들어냈으면 좋겠어

Cursor 쓰면서 이 빌어먹을 오류 때문에 진짜 미치겠다.

레거시 프로젝트에서 Node를 TypeScript로 리팩토링 중인데, 작업 자체는 간단함. 내부 API 업데이트하고, 호출부 수정하고, 테스트 통과하게 만드는 거. 근데 Composer에서 한 4턴 정도 지나면 모델이 아주 자신만만하게 이런 소리를 함.

‘import { standardLogger } from 'untils/logger';’

그딴 파일은 존재하지도 않음. 애초에 있지도 않았다고. 실제 로거는 3년 전부터 ‘lib/logging/logger.ts’에 박혀 있었는데, import 경로가 그럴싸해 보이니까 모델이 그냥 지어낸 거임.

이제 LLM한테 import 경로가 그럴싸하다고 해서 없는 모듈을 멋대로 만들어내지 말라고 설명하고 앉아있음.

내가 M3한테 바라는 건 딱 하나임. "더 깔끔한 패치 작성"이나 "SWE-Bench 점수 높이기" 같은 거 말고, 그냥 없는 파일 좀 제발 지어내지 말라고.

M3 벤치마크 점수가 SWE-Bench Pro에서 59.0, BrowseComp에서 83.5 나온다는데 뭐 어쩌라고. 내가 유일하게 궁금한 건 1M 컨텍스트 윈도우임. M3가 Composer 세션 내에서 레포지토리 구조를 더 많이 기억할 수 있다면, 로거가 ‘untils/logger’가 아니라 ‘lib/logging’에 있다는 걸 기억할지도 모르지. 6턴 전에 스크롤 밖으로 밀려난 스키마 때문에 중복 인터페이스 파일 만드는 짓도 안 할 거고. 그럼 내가 파일 경로 탐정 노릇 하는 시간 줄이고, 코드 짜는 데 더 집중할 수 있겠지.

별거 아닌 거 같아 보여도, 이거 진짜 큰 문제임.

Cursor 쓰면서 시간 절반은 "모델이 코딩을 못 해서"가 아니라, "아니, 그 헬퍼 함수 없다고", "새 래퍼 만들지 마", "일단 기존 서비스 파일부터 읽어"라고 계속 잔소리하는 데 다 씀.

내가 말하는 "레포지토리 메모리 체크"가 바로 이거임. 평소 쓰던 Cursor 워크플로우를 M3로 바꾸겠다는 게 아님. 프로젝트가 개판이고, 의존성 꼬여있고, 모델이 뭐가 있는지 자꾸 헛다리 짚을 때 꺼내 쓸 카드가 필요한 거임.

지금은 모델한테 손전등 비춰주면서 건물 안내하듯이 u/file이랑 u/folder를 너무 많이 입력해야 함. M3의 긴 컨텍스트가 이 짓거리를 조금이라도 줄여준다면, 그게 Cursor에서 진짜 차별점이지. 화려한 거 필요 없음. 그냥 손 덜 가게 해달라고.

물론 주의할 점 두 가지는 있음.

후속 질문마다 레포지토리 절반씩 끌어다 쓰면 토큰 비용 감당 안 될 수도 있음. 그리고 솔직히 데이터 처리 정책 확실해지기 전까진 회사 코드를 새 모델에 넣을 생각 없음. 이건 M3만의 문제는 아니고, 에디터에서 새 모델 테스트할 때 감수해야 할 리스크지.

근데 내가 진짜 테스트해보고 싶은 건 간단함.

없는 파일 좀 그만 지어내나?

추측하기 전에 부족한 컨텍스트부터 확인하나?

u/file로 일일이 떠먹여 주는 횟수가 줄어드나?

혹시 M3 실무 워크플로우에서 써본 사람 있음? 장난감 레포나 깔끔한 벤치마크 말고, 진짜 개판인 다중 파일 수정 작업에서 모델이 헛소리하면서 오후 시간 다 날려 먹을 기회가 충분한 그런 환경에서 말이야.