코드 리뷰 도중 Cursor가 몰래 모델을 바꿨습니다. 덕분에 밤샘 작업한 수정 사항을 거의 다 날리고 돈만 버렸네요.
Cursor silently switched models while I was deep in a code review. I lost most of a real fix and burned a night and lost some money.
핵심 요약
Cursor의 예고 없는 모델 전환으로 인해 작업 흐름이 끊기고 공들인 코드 수정 사항을 손실한 사용자의 불만 섞인 후기입니다.
- 모델 자동 전환 — 고성능 모델에서 기본 모델로 조용히 전환되어 코드 품질과 논리적 일관성이 급격히 저하됨.
- UI 알림 부족 — 모델 변경 시 명확한 경고 없이 하단에 작은 텍스트로만 표시되어 사용자가 인지하기 어려움.
- 작업 손실 — 모델 성능 저하로 인한 잘못된 코드 적용으로 인해 결국 밤샘 작업 결과물을 롤백하게 됨.
- 제품 신뢰도 문제 — 유료 도구임에도 사용자 동의 없는 성능 변경은 심각한 설계 결함이자 신뢰 문제라고 비판함.
Cursor의 제품 설계와 신뢰도에 심각한 문제가 있다고 생각하여 이 글을 올립니다. 제가 잘못한 부분과 제 잘못이 아닌 부분에 대해 공정하게 짚고 넘어가고 싶습니다.
Context
저는 속도보다 정확성이 훨씬 중요한 코드베이스에서 작업합니다. 까다로운 동시성 문제, 취약한 불변성, 누군가 너무 과감하게 "도와주려" 할 때 발생하는 미묘한 회귀 버그 등이 있는 곳이죠. 이건 전형적인 시니어 엔지니어링의 영역입니다. 장난감 데모가 아니라, 잘못된 수정이 쌓이면 치명적인 시스템이죠.
처음에 잘 진행된 부분
강력한 모델 세션(여기서는 "고성능" 경로라고 부르겠습니다)을 사용 중이었습니다. 몇 시간 동안 아주 까다로운 버그를 잡는 데 실질적인 진전이 있었죠. 솔직히 말해서 올바른 수정까지 약 90% 정도 도달한 상태였습니다.
나의 실수 (이건 제 책임입니다)
git commits로 그 진행 상황을 충분히 일찍 체크포인트로 남기지 않았습니다.
그건 제 잘못입니다. 진행하면서 작고 안전한 단위로 커밋을 해서 언제든 검증된 중간 상태로 돌아갈 수 있게 했어야 했습니다.
제 평소 워크플로우는 어시스턴트와 처음부터 끝까지 함께하며 변경 사항을 같이 이해하고, 전체 스토리가 일관성이 생겼을 때 커밋하고 문서화하는 방식이었습니다. 지금까지는 연속성이 유지되었고 어시스턴트의 동작이 우리가 해결하려는 문제와 일관성을 유지했기 때문에 괜찮았습니다.
Cursor에서 발생한 문제
제 세션이 조용히 다른 모델 경로로 라우팅되었습니다. 실제로는 제가 여전히 사용 중이라고 생각했던 고성능 경로가 아니라, Cursor의 기본 에이전트(보통 "항상 사용 가능한" 티어)처럼 동작했습니다.
외부에서 보면 이건 항상 똑같은 지루한 이유로 설명됩니다. 사용량 제한, 쿼터, 공정 사용 정책, 세션 라우팅 또는 프리미엄 측의 가용성 문제 같은 것들이죠. 저는 Cursor의 정확한 내부 규칙을 안다고 주장하는 게 아닙니다. 제가 아는 건 사용자에게 보이는 결과입니다:
- 제품이 세션을 중단하지 않고 더 강력한 경로에서 더 저렴하거나 가용성이 높은 기본값으로 폴백(fallback)할 수 있습니다.
- UI는 여전히 "동일한 채팅, 동일한 레포, 동일한 작업"처럼 보일 수 있으며, 이때가 바로 뇌가 라벨을 다시 확인하는 것을 멈추는 시점입니다.
- 그래서 밑바닥의 엔진은 더 이상 같은 종류의 에디터가 아님에도 불구하고 계속해서 "적용(apply)"과 "계속(continue)"을 클릭하게 됩니다.
제가 받은 유일한 신호는 채팅창 아래의 작은 UI 디테일뿐이었습니다.
한 시간 넘게 눈치채지 못했습니다.
그건 제가 부주의해서가 아닙니다. 저는 diff를 읽고, 호출 경로를 추적하고, 동작을 가설과 대조하고, 왜 수정 사항이 이미 우리가 추론한 시스템과 일치하지 않는지 묻는 등 완전한 복구 모드에 있었습니다. 그런 종류의 리뷰는 주의력을 엄청나게 소모합니다. 속삭이듯 조용한 라우팅 표시기는 역량과 리스크를 변화시키는 변경 사항을 전달하기에는 부적절한 장소입니다.
제한에 걸려 제품이 기본 에이전트로 라우팅되어야 한다면 좋습니다. 그렇다면 제품은 하드 스톱(hard-stop)을 하고 명확한 언어로 다시 동의를 구해야 합니다: "더 이상 X를 사용하지 않습니다. 그래도 Y로 계속하시겠습니까?" 침묵은 중립이 아닙니다. 침묵은 연속성을 이용한 기만입니다.
일단 저하된 경로가 장악하자, 우리가 해오던 것과 비교해 수정 패턴이 엉망이 되었습니다. 더 광범위한 코드 휘저음(churn), 제약 조건과의 약해진 정렬, 그리고 의도에 대한 부실한 세션 문서화가 발생했습니다. 여전히 같은 워크플로우처럼 느껴졌지만 갑자기 나빠졌을 뿐이라, 상황을 파악하는 게 늦어졌습니다.
증분 예산을 유지하는 이유 (그리고 왜 그것이 이번 밤을 구하지 못했는가)
이 사건과는 별개로, 저는 이미 도구 비용을 증분 예산으로 관리합니다. 소액 버퍼, 한도 설정, 또는 "여유분 남기기" 습관을 통해 하나의 잘못된 세션이 저를 놀라게 하지 않도록 말이죠.
이건 개인적인 리스크 관리입니다. 조용한 라우팅을 옹호하는 게 아닙니다. 오히려 그 반대죠. 자신의 프로세스가 대체로 훌륭하더라도 벤더의 UX가 당신을 실망시킬 수 있기 때문에 예산을 짜는 것입니다.
