Continue가 멈춘 뒤, VSCode에서 로컬 LLM 쓰는 법 (2026년 정리)

안녕하세요, 자바파커입니다.

이번 글은 질문 하나에서 시작합니다.

"그동안 VSCode에서 Continue.dev로 로컬 LLM을 잘 쓰고 있었는데, 개발이 멈춘 것 같다. 이제 뭘 써야 하나?"

결론부터 말씀드리면, 걱정하실 일은 아닙니다. Continue가 멈춘 건 맞지만, 로컬 LLM을 VSCode에 붙이는 선택지는 오히려 예전보다 더 좋아졌습니다. 다만 지형도가 한 번 크게 바뀌었기 때문에, 지금 시점에서 무엇이 살아있고 무엇이 사라졌는지 정리가 필요합니다.

왜 Continue를 떠나야 하나

먼저 상황부터 짚겠습니다. Continue.dev를 잘 쓰던 분이라면 알아둘 만한 소식입니다.

• Continue를 만든 팀은 2026년 6월 Cursor에 인수되었습니다.
• 오픈소스 익스텐션은 v2.0.0을 마지막 릴리스로 사실상 개발이 멈췄고, 저장소도 더 이상 활발히 관리되지 않습니다.
• 마지막 버전에서는 텔레메트리와 강제 로그인이 빠져서, 남은 기능은 오프라인·로컬 환경에서 계속 쓸 수는 있습니다.
• 다만 클라우드에 저장돼 있던 사용자 데이터는 2026년 7월 15일 이후 삭제되었습니다.

즉, 지금 당장 Continue가 안 켜지는 건 아닙니다. 하지만 새 모델·새 기능·버그 픽스가 더 이상 들어오지 않는 도구를 주력으로 쓰긴 어렵습니다.

그런데 여기서 한 가지 더. 많은 분들이 Continue 대안으로 떠올리는 Roo Code도 사정이 비슷합니다.

• Roo Code는 원래 Cline에서 갈라져 나온 포크로, VS Code 설치 155만 건까지 갔던 인기 프로젝트였습니다.
• 하지만 2026년 4월 21일 서비스를 종료했고, 익스텐션은 5월 15일 아카이브 처리됐습니다. 팀은 클라우드 에이전트(roomote.dev)로 방향을 틀었습니다.

정리하면 이렇습니다.

이제 살아있는 선택지들을 하나씩 보겠습니다.

먼저: 로컬 LLM 준비 (Ollama)

어떤 익스텐션을 쓰든 공통으로 필요한 건 로컬에서 모델을 돌려줄 런타임입니다. 가장 무난한 건 Ollama입니다.

# 설치 후 코딩용 모델을 받아둡니다
ollama pull qwen2.5-coder:7b      # 메인 (채팅/편집)
ollama pull qwen2.5-coder:1.5b    # 자동완성(FIM)용 경량 모델

모델 선택 가이드는 대략 이렇습니다. (2026년 기준, 개인 장비 기준)

최소 사양은 RAM 8GB + 최근 5년 내 CPU 정도면 소형 모델은 돌아갑니다. 다만 14B 이상, 특히 에이전트 작업을 제대로 시키려면 GPU(VRAM)가 넉넉할수록 좋습니다.

⚠️ 가장 흔한 함정 — 컨텍스트 길이(num_ctx) Ollama는 모델 컨텍스트를 기본 2K~4K 토큰으로 잡습니다. 채팅용으론 괜찮지만, 에이전트(Cline 등)는 도구를 몇 번 호출하면 금방 이 한도를 넘겨서 조용히 실패하거나 무한 루프에 빠집니다. 에이전트로 쓸 거면 컨텍스트를 최소 32K(가능하면 64K)로 올려두세요. 아래 Cline 섹션에서 방법을 다룹니다.

1. Cline — 에이전트형 코딩, 가장 무난한 1순위

한 줄 요약: Continue의 "채팅+편집"을 넘어, 파일을 직접 고치고 터미널 명령까지 실행하는 자율 에이전트. Continue 이후 사실상 가장 많이 쓰이는 오픈소스 선택지입니다.

• 성격: 에이전트형(멀티파일 편집, 터미널 실행, MCP 툴 연동)
• 로컬 지원: Ollama, LM Studio, llama.cpp, OpenAI 호환 API 모두 지원
• 강점: 활발한 유지보수, VS Code + JetBrains 지원, MCP 생태계
• 주의: 에이전트 작업을 안정적으로 하려면 14B 이상(신뢰성 있게는 32B) 권장

설정 요약

1. VS Code 마켓플레이스에서 Cline 설치
2. API Provider를 Ollama로 선택
3. Base URL: http://localhost:11434, 모델 ID 지정

컨텍스트 늘리기(중요). 앞서 말한 num_ctx 함정을 피하려면, 환경변수보다 Modelfile에 값을 굽는 방식이 가장 확실합니다.

# Modelfile
FROM qwen3-coder:32b
PARAMETER num_ctx 32768

ollama create qwen3-coder-32k -f Modelfile

이렇게 만든 qwen3-coder-32k를 Cline에서 모델로 선택하면 됩니다. (16GB VRAM이면 16K 정도가 현실적인 상한이니, 장비에 맞춰 조정하세요.)

이런 분께: "AI에게 이슈 하나 통째로 맡기고 싶다", "여러 파일을 오가며 리팩터링·버그 수정을 자동으로 시키고 싶다".

2. Twinny — Copilot 같은 자동완성 + 채팅, 가장 "로컬 퍼스트"

한 줄 요약: GitHub Copilot을 그대로 로컬로 옮긴 듯한 도구. 인라인 자동완성과 사이드바 채팅을 100% 무료·비공개로 제공합니다. Continue를 "가볍게, 자동완성 위주로" 쓰던 분께 가장 자연스러운 대체재입니다.

• 성격: 실시간 인라인 자동완성(FIM) + Copilot Chat 스타일 채팅
• 로컬 지원: Ollama, llama.cpp 등 OpenAI 호환 엔드포인트
• 강점: 설정이 단순함, 완전 로컬/비공개, 코드 완성 diff 미리보기, 워크스페이스 임베딩 기반 문맥 인식
• 주의: 에이전트형 자동 편집은 Cline보다 약함(자동완성·대화가 주력)

설정 요약

1. 마켓플레이스에서 twinny 설치
2. Ollama가 켜져 있으면 대부분 자동 인식 (엔드포인트/포트 설정 가능)
3. 자동완성용은 경량(qwen2.5-coder:1.5b), 채팅용은 7b처럼 역할별로 모델을 분리하는 게 정석

이런 분께: "복잡한 에이전트는 필요 없고, Copilot처럼 타이핑하면 착착 붙는 자동완성 + 옆에서 물어볼 채팅만 있으면 된다".

3. Kilo Code — Roo Code가 익숙했다면

한 줄 요약: 문을 닫은 Roo Code의 사실상 후속. Roo의 강점이던 모드 분리(Code/Architect/Ask/Debug) 를 그대로 잇는 활발한 포크입니다.

• 성격: 에이전트형 + 모드 분리(작업 성격별로 모델·행동을 다르게)
• 로컬 지원: Ollama 등 로컬 모델 연결
• 강점: 기존 Roo의 .roomodes / .roo/rules/ 설정을 그대로 읽어 옴 → Roo 쓰던 분이 갈아타기 쉬움
• 모드 분리의 매력: 예를 들어 Code 모드엔 큰 로컬 모델, Ask 모드엔 작은 로컬 모델을 물려 작업별로 자원을 배분할 수 있습니다.

이런 분께: "Roo Code의 모드 워크플로우가 손에 익었다", "작업 종류에 따라 모델을 갈아 끼우고 싶다".

4. Tabby — 자동완성 전용, 팀/사내 서버 시나리오

한 줄 요약: 익스텐션이라기보다 셀프호스트 자동완성 서버. VS Code는 물론 JetBrains·Vim·Neovim·Emacs까지 붙습니다.

• 성격: 자동완성(FIM) 특화
• 로컬 지원: Ollama와 별개로 자체 추론 서버를 띄우는 구조
• 강점: 매우 빠른 완성(1~3B 특화 모델로 200ms 이하), 여러 에디터 공용, 팀 단위로 서버 한 대 세워 공유하기 좋음
• 주의: 전용 서버(혹은 성능 좋은 장비)가 필요, 채팅/에이전트보다는 완성에 집중

이런 분께: "개인 자동완성을 넘어, 팀이 공유하는 사내 코드 자동완성 서버를 두고 싶다".

그래서 뭘 골라야 하나

성향별로 정리하면 이렇습니다.

가장 무난한 조합을 하나만 꼽자면, Ollama + Cline(에이전트) + Twinny(자동완성) 를 함께 쓰는 구성입니다. 무거운 작업은 Cline에게 맡기고, 평소 타이핑은 Twinny가 받쳐주는 식이죠.

정리

Continue.dev가 멈추고 Roo Code까지 문을 닫으면서, "내가 쓰던 도구가 사라졌다"는 불안이 있을 수 있습니다. 하지만 로컬 LLM을 VSCode에 붙이는 흐름 자체는 오히려 성숙해졌습니다.

• Continue / Roo Code → 유지보수 중단·종료. 주력에서 내려놓을 때.
• Cline → 에이전트형 1순위. 파일 편집·터미널·MCP까지.
• Twinny → Copilot 대체용 자동완성+채팅. 가장 가볍고 로컬 퍼스트.
• Kilo Code → Roo 후속. 모드 분리가 강점.
• Tabby → 팀 공용 자동완성 서버.

핵심은 지난 Kimi K3 글에서 던졌던 질문과 이어집니다.

내 개발 워크플로우는 모델(그리고 도구)을 바꿔 끼울 수 있는 구조인가?

도구 하나에 종속되기보다, Ollama로 모델을 로컬에 두고 그 위에 익스텐션을 갈아 끼우는 구조로 가면, 이번처럼 도구 하나가 사라져도 워크플로우는 흔들리지 않습니다. 그게 이번 Continue 사태가 주는 진짜 교훈이라고 생각합니다.

참고자료

• Cline - GitHub
• Twinny - Open VSX
• Kilo Code
• Tabby - GitHub
• Ollama
• Continue.dev Docs (레거시)