Cursor, Cline, Roo Code에 서드파티 모델 연결하기: 설정 매트릭스 한 장

결론부터

세 도구 모두 연결할 수 있고, 차이는 세 군데입니다:

한 줄로 구분하면 이렇습니다: Cursor는 IDE에 내장된 AI이고, Cline / Roo Code는 플러그인 형태의 agent입니다. 전자는 여러분과 편집기를 두고 경쟁하고, 후자는 여러분의 편집기 안에서 일을 대신합니다.

설정 매트릭스

세 도구에 입력하는 값은 동일한 한 세트입니다:

• Base URL: https://api.kimiseek.app/v1
• API Key: ks-로 시작하는 key
• Model ID: catalog의 전체 id, 예: deepseek-v4-pro-0813

Base URL에 /v1이 들어가는 점에 주의하세요. 세 도구 모두 /chat/completions를 스스로 붙입니다.

Cursor

1. 설정을 열고 Models 패널로 들어갑니다.
2. OpenAI API Key를 입력하고, Override OpenAI Base URL을 켠 뒤 https://api.kimiseek.app/v1을 입력합니다.
3. Base URL 덮어쓰기를 켜면 Cursor는 사용자 정의 모델을 OpenAI 호환 모델로 처리하므로, 이때는 모델명을 직접 추가해야 합니다.
4. 저장한 뒤 새 대화를 열고 「너는 무슨 모델이야」라고 물어 링크를 검증합니다.

Cursor의 함정은 모델명입니다. 내장 모델 목록이 따로 있어서, 목록에 없는 이름은 입력은 되지만 동작하지 않는 경우가 있습니다. 「저장은 되는데 질문에 반응이 없다」면 표준 명명 규칙을 따르는 id로 먼저 바꿔 보세요.

Cline

1. Cline 패널의 Settings를 엽니다.
2. API Provider에서 OpenAI Compatible을 선택합니다.
3. Base URL에 https://api.kimiseek.app/v1, API Key에 ks-로 시작하는 key를 입력합니다.
4. Model ID에 deepseek-v4-pro-0813을 입력합니다.
5. 저장한 뒤 메시지를 하나 보내 검증합니다.

Cline의 함정은 context 길이입니다. 모델명으로 context window를 추측하고, 추측하지 못하면 보수적인 값(흔히 128K, 심하면 64K)을 넣습니다. 그래서 1M context가 있는데도 클라이언트가 먼저 잘라 버립니다. 커뮤니티에 이 문제를 다루는 이슈가 따로 있습니다. 「작업 도중 context가 부족하다」는 안내를 만나면 모델을 의심하기 전에 설정에서 수동으로 늘리세요.

Roo Code

Roo Code는 Cline의 포크이며 절차가 거의 같습니다:

1. API Provider에서 OpenAI Compatible을 선택합니다.
2. Base URL, API Key, Model ID는 Cline과 동일합니다.
3. 모델 설정에서 context window와 최대 출력 tokens를 직접 지정합니다.

Roo Code에서 추가되는 것은 모드 설정(Code / Architect / Ask 등)이고, 모드마다 다른 모델을 지정할 수 있습니다. 비용을 아끼려면 가벼운 모드를 deepseek-v4.1-flash로 지정하세요.

피할 수 없는 두 가지 문제

context window가 클라이언트에 하드코딩됨

세 도구에 공통된 문제이고, 증상은 「모델은 분명히 1M을 지원하는데 클라이언트가 128K에서 자른다」입니다.

원인은 이렇습니다. 클라이언트는 언제 기록을 압축할지 정하려면 context 길이를 알아야 합니다. 대부분의 클라이언트는 모델명을 내장 표와 대조하고, 대조에 실패하면 보수적인 기본값을 씁니다.

대응책은 수동 지정입니다. Cline과 Roo Code는 설정에서 바꿀 수 있습니다. Cursor는 모델명으로 추론하므로, context 표기가 더 큰 모델명을 골라 덮어쓰는 방법을 씁니다.

tool call 형식 비호환

agent는 tool call로 일합니다: 파일 읽기, 파일 쓰기, 명령 실행. 모델마다 tool call 형식에 미세한 차이가 있고, 게이트웨이가 이를 정규화해야 합니다.

증상은 오류가 아니라 「모델이 파일을 고쳤다는데 엉뚱한 파일을 고쳤다」거나 「같은 파일을 계속 다시 읽는다」입니다. 그럴 때는 먼저 네이티브 프로토콜 경로인지 확인하고, 그다음 다른 모델로 시도해 보세요. 모델별 tool call 품질 차이가 크고, reasoning형 모델이 대체로 더 안정적입니다.

검증 체크리스트

설정을 마친 뒤 순서대로 검증합니다:

1. 평범한 질문을 보내 답이 옴 → 인증과 네트워크 통과.
2. 파일 하나를 읽게 함 → tool call 통과.
3. 파일 하나를 수정하게 함 → 쓰기 권한과 diff 통과.
4. 테스트 명령 하나를 실행하게 함 → 실행 체인 통과.

어느 단계든 실패하면 오류 대조표를 보세요.

언제 도구를 바꿔야 하는가

• 자동 완성과 단일 파일 수정만 필요 → Cursor로 충분하고 가볍습니다.
• 파일 간 리팩터링과 테스트 루프가 필요 → Cline / Roo Code가 더 적합합니다. 애초에 다단계 작업을 위해 설계된 도구입니다.
• 터미널에서 긴 작업을 돌려야 함 → Claude Code 또는 Codex를 쓰세요.

적용 버전과 검증

• Cursor 1.x, Cline 3.x, Roo Code 3.x
• 검증 날짜: 2026-10-26
• 사실 출처: 세 도구의 공식 설정 문서와 실제 UI 필드; context 하드코딩 문제는 커뮤니티 이슈 논의 참고