Cursor의 BYOK 지원은 의도적으로 망가진 것 같음 — 이걸 "설계상 어쩔 수 없다"고 하는 건 더 최악임
Cursor’s BYOK support feels deliberately crippled — and calling it “by design” makes it worse
핵심 요약
Cursor가 BYOK 기능을 의도적으로 제한하고 있으며, 이를 '설계'라고 정당화하는 태도를 비판함.
- BYOK 기능 제한 — 외부 API 키 사용 시 Cursor 전용 모델 사용이 강제로 차단됨.
- 일관성 없는 대응 — 과거에는 버그라고 인정했으나 현재는 의도된 설계라고 주장함.
- 라우팅 문제 — Auto 모드에서는 정상 작동함에도 불구하고 수동으로 키를 끄게 만드는 것은 불합리함.
- 경쟁력 약화 — 모델 선택의 자유를 보장하지 않아 Cursor의 가치를 떨어뜨림.
Cursor가 BYOK(Bring Your Own Key)를 지원한다고는 하는데, 실제 구현 상태를 보면 일부러 이렇게 만든 게 아닌가 싶을 정도로 엉망이야. Composer와 BYOK 문제를 처리하는 Cursor의 태도를 보면, 이게 단순한 실수라고 믿기가 점점 어려워지네.
관련 Cursor 포럼 스레드:
문제는 이거야:
OpenAI나 Anthropic BYOK 키를 활성화한 상태에서 Composer 2.5 같은 Cursor 자체 모델을 선택하면, 요청이 실패하면서 이런 메시지가 떠.
“This model does not support custom API keys.”
Cursor 측 설명은 Composer가 Cursor 독자 모델이라 외부 API 키로는 서비스할 수 없다는 건데,
이건 아무도 안 물어본 소리야.
누가 OpenAI, Anthropic, Moonshot, OpenRouter 키로 Composer 비용을 내겠다고 기대하겠어? 당연히 이렇게 작동해야지:
- 외부 제공자 모델 → 해당 제공자의 API 키 사용
- Cursor 자체 모델 → Cursor 인프라와 사용자 구독권 사용
- 모델 전환 → 요청마다 적절하게 라우팅
설정에 서드파티 키가 있다고 해서, 아무 상관 없는 Cursor 자체 모델까지 먹통이 되면 안 되는 거잖아.
라우팅 레이어는 Cursor가 통제하고 있고, 이미 'Auto' 모드에서는 제대로 작동하고 있어. Auto가 요청을 Composer로 보낼 때는 BYOK 자격 증명을 붙이지 않거든. 그래서 BYOK가 켜져 있어도 Composer는 잘만 돌아가.
즉, 이건 Composer 자체의 기술적 한계가 아니라, 명백히 라우팅 설계 문제라는 거지.
더 열받는 건 Cursor 측의 설명이 계속 바뀐다는 거야.
초기에는 Cursor 직원들도 이걸 "알려진 문제"라고 했고, 커스텀 키가 "모든 모델에 잘못 적용된 것"이라며 버그라고 인정했었어. 심지어 "기술적 한계가 아니라 우리 쪽 라우팅 설계 문제"이며, Auto 모드에서 이미 해결에 필요한 라우팅 패턴을 보여주고 있다고까지 했지.
근데 최근에는 똑같은 현상을 두고 "예상된 의도"라느니, "설계상 어쩔 수 없다", "버그가 아니다"라며 말을 바꾸고 있어. 모델별 라우팅은 그냥 "삶의 질(QoL) 개선 사항" 정도로 격하됐고.
이게 어떻게 QoL 문제야?
BYOK랑 Cursor 독자 모델을 같은 워크플로우에서 같이 쓸 수 있느냐 없느냐가 달린 문제인데.
Composer 쓸 때마다 설정 들어가서 BYOK 끄라는 건 해결책이 아니야. 그 수동 토글 자체가 바로 우리가 고쳐달라고 하는 결함이라고.
Cursor가 Cursor 측 과금이나 더 비싼 플랜으로 유도하려고 일부러 불편함을 방치하는 건지 내가 증명할 순 없지. 하지만 사용자들이 이런 의심을 하는 건 당연해:
- Auto 모드에는 이미 올바른 라우팅 로직이 구현되어 있음
- Cursor 스스로도 예전엔 이걸 버그라고 불렀음
- 기술적 한계가 아니라고 인정했음
- 몇 달째 사용자들이 계속 문제를 제기함
- Composer를 쓰려면 BYOK를 끄라는 게 "해결책"이라고 함
- 이 현상 때문에 외부 모델이나 개인이 비용을 부담하는 모델을 쓰기가 불편해짐
- 이제 와서 이 고장 난 작동 방식을 의도된 설계라고 주장함
