나는 화요일 아침, 10분 정도면 설정을 마치고 점심때쯤이면 작동하는 AI 어시스턴트를 사용할 수 있을 것이라 기대하며 Continue.dev를 설치했다. 첫 번째 유용한 코드 완성 (Completion)을 얻기까지 23분이 걸렸는데, 이는 도구가 고장 나서가 아니라 이 도구의 설계 철학이 상용 도구들이 대신 해주는 결정들을 사용자가 직접 내리도록 요구하기 때문이다. 세 가지 서로 다른 모델 제공자 (Model Provider)를 통해 설정을 완료하고, 개인 프로젝트와 클라이언트 프로젝트 모두에서 두 달 동안 매일 사용해 본 결과, Continue는 현재 사용 가능한 가장 원칙적인 AI 코딩 어시스턴트라고 말할 수 있다. 다만, 설치하기 전에 자신이 무엇을 감수해야 하는지 이해할 필요가 있다.

모델 선택 아키텍처 (Architecture)가 비용을 실질적으로 절감한다

내가 Continue에 매료된 기능은 코드 완성의 품질이나 채팅 인터페이스가 아니었다. 바로 비용 투명성(Cost Transparency)이었다. 나는 동일한 50개의 리팩토링 (Refactoring) 작업을 세 가지 서로 다른 백엔드(Backend)로 구성된 Continue를 통해 실행했다. 구성은 OpenAI의 API를 통한 GPT-4, Anthropic의 API를 통한 Claude Sonnet, 그리고 내 M2 MacBook에서 로컬로 실행되는 Code Llama였다. 그리고 그 결과를 GitHub Copilot이 동일한 작업에 대해 부과하는 비용과 비교했다.

50개의 동일한 리팩토링 작업을 수행했을 때, Continue를 통한 Sonnet 사용 비용은 API 크레딧 기준 4.67달러였다. Copilot의 번들 모델을 통해 동일한 작업을 수행했을 때는 월간 할당량의 약 65%를 소모했으며, 이는 월 19달러 기준으로 환산하면 12.35달러의 가치에 해당한다. 만약 당신이 AI 보조 코딩을 헤비하게 한다면, API 키를 직접 관리하고 사용량을 모니터링할 의사가 있다는 전제하에 Continue의 제공자 직접 결제 방식은 번들 구독 방식에 비해 모델 비용을 약 40~60% 절감할 수 있다.

처음에는 비용 차이가 그렇게 클 것이라고 믿지 않았기에, 서로 다른 업무 주간에 걸쳐 두 번의 실험을 진행했습니다. 두 번째 주에도 비슷한 수치가 나왔습니다. Copilot 할당량으로는 약 11~13달러가 소비된 반면, Continue를 통해서는 5.12달러가 지출되었습니다. 이러한 격차는 두 가지 요인에서 발생합니다. 첫째, API 과금 방식은 실제로 사용된 토큰 (Tokens)에 대해서만 비용을 청구하는 반면, 구독형 가격 책정은 모든 사용자에 걸쳐 평균화되며 플랫폼의 마진이 포함됩니다. 둘째, Continue는 저렴한 요청을 저렴한 모델로 라우팅 (Routing)할 수 있게 해줍니다. 저는 자동 완성 (Autocomplete)은 작은 로컬 모델로 보내고, 복잡한 리팩토링 (Refactoring) 작업에는 Claude를 예약해 두는 방식을 사용하지만, Copilot은 모든 작업에 동일한 모델 계층을 사용합니다.

프로젝트 중간에 모델을 전환하는 기능은 제가 예상치 못하게 가치 있게 느끼게 된 실용적인 기능이었습니다. 모든 코드가 고객의 프라이빗 네트워크 (Private Network) 내에 머물러야 했던 클라이언트 프로젝트에서, 저는 JSON 설정 파일의 한 줄을 변경함으로써 Continue를 그들의 셀프 호스팅된 Llama 엔드포인트 (Endpoint)로 지정했습니다. 2주 후, 해당 프로젝트가 끝나고 클라우드 모델을 다시 사용할 수 있는 개인 작업으로 넘어갔을 때, 저는 단 한 줄의 변경으로 다시 모델을 전환했습니다. 저는 세 개의 서로 다른 프로젝트를 진행하며 이 모델 교체를 여섯 번 수행했는데, 각 전환에는 30초도 걸리지 않았습니다. 이 마찰 (Friction)은 의식적인 절차라기보다 습관이 될 정도로 매우 낮습니다.

설정 경험은 인내심을 시험할 것입니다

설치 경험에 대해서는 솔직해질 필요가 있습니다. 왜냐하면 바로 이 지점에서 사용자들이 Continue를 포기하기 때문입니다. 확장은 다른 VS Code 확장 프로그램과 마찬가지로 설치되지만, 처음 실행하면 빈 채팅 패널과 모델 제공자 (Model Provider)를 추가하라는 프롬프트가 나타납니다. 기본으로 구성된 모델은 없습니다. 확장은 모델을 제안하지도 않습니다. 그저 문서 링크를 건네주고 기다릴 뿐입니다.

저는 이미 OpenAI와 Anthropic의 API 키를 가지고 있었기에 설정이 더 빨랐습니다. 그럼에도 불구하고, 처음 Continue를 구성할 때 config.json 문서를 읽고, 두 개의 프로바이더(하나는 채팅용, 하나는 자동 완성용)를 설정하며, 두 기능 모두가 응답하는지 확인하는 데 23분이 걸렸습니다. 제가 Continue를 추천해 준 동료 — API 프로바이더 관리에 경험이 적은 사람 — 는 동일한 단계에 도달하는 데 41분이 걸렸으며, 그 과정에서 두 개의 서로 다른 모델 프로바이더에 계정을 생성해야 했습니다.

~/.continue/config.json에 위치한 config.json 파일은 Continue가 수행하는 모든 작업의 제어 인터페이스 (control surface)입니다. 문서화가 잘 되어 있지만 장황합니다. 세 가지 모델 — 탭 자동 완성 (tab autocomplete)을 위한 빠른 로컬 모델, 채팅을 위한 Claude Sonnet, 그리고 코드베이스 인덱싱을 위한 임베딩 (embeddings) 모델 — 을 구성하려면 엔드포인트 URL, API 키 참조, 모델 이름, 컨텍스트 윈도우 (context window) 파라미터를 포함하여 약 35줄의 JSON이 필요합니다. 제공되는 템플릿이 도움이 되긴 하지만, 이는 사용자가 어떤 모델 이름을 입력해야 하는지, 어떤 컨텍스트 윈도우 크기가 적절한지 알고 있다는 것을 전제로 합니다. LLM 엔드포인트를 한 번도 구성해 본 적이 없다면, 첫 세션은 위협적으로 느껴질 수 있습니다.

초기 설정 이후의 지속적인 유지보수는 최소한입니다. 저는 두 달 동안 세 번 설정 파일을 업데이트했습니다. 한 번은 새로운 프로바이더를 추가하기 위해, 한 번은 모델 업데이트가 지원될 때 컨텍스트 윈도우 크기를 늘리기 위해, 그리고 한 번은 여행 중 인터넷 연결이 불안정할 때 자동 완성을 클라우드 모델에서 Ollama로 전환하기 위해 업데이트했습니다. 각 설정 변경에는 2분 미만이 소요되었습니다.

자동 완성 품질은 전적으로 모델 선택에 달려 있습니다

이것이 Continue가 사용자에게 수용하도록 요구하는 트레이드오프 (trade-off)입니다. 즉, 자동 완성의 품질은 사용자의 책임이라는 점입니다. 상용 도구들은 자신들의 추론 스택 (inference stack)에 맞춰 완성 모델을 구체적으로 튜닝합니다. 반면 Continue는 사용자가 구성한 모델로 커서 위치와 주변 코드를 보낼 뿐이며, 결과가 잘 나오기를 바랄 뿐입니다.

저는 TypeScript 파일에서 100회의 편집 세션을 통해 Copilot 및 Cursor와 Continue의 자동 완성 (autocomplete) 성능을 벤치마킹했습니다. Ollama를 통해 로컬에서 실행되는 Code Llama 7B로 Continue를 구성했을 때, 수락률 (acceptance rate) — 즉 제안을 그대로 유지한 비율 — 은 48%였으며, 키 입력부터 제안이 나타날 때까지의 평균 지연 시간 (latency)은 940ms였습니다. Cursor의 호스팅된 Tab 모델로 동일한 테스트를 진행했을 때는 73%의 수락률과 120ms의 지연 시간을 기록했습니다.

그다음 Continue의 자동 완성을 OpenAI의 API를 통한 GPT-4로 전환했습니다. 수락률은 61%로 뛰었지만, 프롬프트 조립 (prompt assembly)에 더 오랜 시간이 걸리고 API 왕복 (round-trip)으로 인한 오버헤드가 추가되어 지연 시간은 1,400ms로 증가했습니다. 이 정도의 지연 시간에서는 제가 이미 다음 줄을 타이핑한 후에 제안이 도착하는 경우가 많아, 실시간 완성 (real-time completion) 용도로는 기능적으로 무용지물이었습니다.

제가 찾아낸 최적의 지점 (sweet spot)은 자동 완성을 중간 크기의 로컬 모델인 Code Llama 13B 또는 Mistral 7B로 라우팅하고, 클라우드 모델은 채팅 (chat) 및 리팩터링 (refactoring) 용도로 남겨두는 것이었습니다. 이 설정으로 약 520ms의 지연 시간과 55%의 수락률로 완성을 수행할 수 있습니다. 이는 Cursor보다 느리고 정확도도 낮지만, API 비용이 전혀 들지 않으며 제 코드를 기기 외부로 절대 보내지 않습니다. 코드 기밀성이 중요한 고객 프로젝트 작업을 수행할 때, 이러한 트레이드오프 (trade-off)는 받아들일 가치가 있습니다. 비용보다 속도가 더 중요한 개인 프로젝트의 경우, 자동 완성에는 여전히 Cursor를 사용하고 채팅 및 컨텍스트 (context) 기능은 Continue를 사용하도록 구성해 둡니다.

@ 멘션 시스템은 조용히 탁월하다

Continue의 @ 멘션 (mention) 구문은 제가 가장 많이 사용하는 기능이자, 제가 테스트한 다른 모든 어시스턴트와 차별화되는 지점입니다. 세 개의 파일에 걸쳐 있는 함수를 리팩터링해 달라고 Continue에 요청할 때, 채팅 메시지에 @src/database/schema.ts와 @src/utils/auth.ts를 입력하면, Continue는 응답을 생성하기 전에 해당 파일들의 전체 내용을 모델의 컨텍스트 (context)에 주입합니다.

이것이 중요한 이유는 AI 코딩 어시스턴트(AI coding assistants)가 작업에 어떤 파일이 관련되어 있는지 추측하는 데 매우 서툴기 때문입니다. 어시스턴트들은 너무 많은 컨텍스트 (context)를 가져와 토큰 (tokens)을 낭비하거나, 반대로 너무 적은 정보를 가져와 프로젝트의 나머지 부분과 통합되지 않는 코드를 생성하곤 합니다. @ 멘션 (mention) 시스템을 사용하면 모델이 보는 내용을 명시적으로 제어할 수 있으며, 도구가 무엇을 인덱싱 (index)할지 결정하게 두는 것보다 잘 선택된 5~10개의 파일 참조를 제공하는 것이 더 나은 결과를 만든다는 것을 확인했습니다.

저는 @ 멘션을 사용하는 Continue와 Copilot의 자동 컨텍스트 선택 (automatic context selection) 기능을 10개의 다중 파일 리팩토링 (refactoring) 작업에 대해 비교했습니다. Continue를 사용할 때는 관련이 있다고 판단되는 파일들을 명시적으로 태깅 (tagging)했으며, 10개 중 8개의 생성된 솔루션이 첫 번째 시도에 올바르게 컴파일 (compile)되었습니다. 반면, 열려 있는 탭과 시맨틱 검색 (semantic search)을 조합하여 컨텍스트를 구축하는 Copilot의 경우, 10개 중 6개의 솔루션만이 첫 번째 시도에 컴파일되었습니다. 이러한 차이는 시맨틱 검색이 찾아내지 못한 파일들을 건드리는 작업에서 가장 두드러졌습니다. 즉, 리팩토링 중인 함수와 의미론적으로는 유사하지 않지만 구조적으로는 반드시 필요한 유틸리티 모듈 (utility modules), 타입 정의 파일 (type definition files), 그리고 설정 상수 (configuration constants) 등이 이에 해당합니다.

Continue가 더 강력했으면 하는 부분

자동 완성 (autocomplete) 지연 시간 (latency)은 여전히 가장 큰 실질적인 한계로 남아 있습니다. 제가 최적화한 로컬 모델 (local model) 설정에서도 520ms가 소요되는데, 이는 Cursor의 120ms 고스트 텍스트 (ghost text)보다 눈에 띄게 느린 속도입니다. 뇌가 이 타이밍에 적응하여 줄 끝에서 잠시 멈추는 법을 배우게 되긴 하지만, 상용 대안 제품들만큼 매끄러운 경험을 주지는 못합니다. 저는 문서에서 제안하는 모든 최적화 방법, 즉 더 작은 모델, 더 짧은 컨텍스트 윈도우 (context windows), 더 낮은 정밀도의 추론 (lower-precision inference) 등을 모두 시도해 보았습니다. 격차는 줄어들었지만 완전히 해소되지는 않았습니다.

JetBrains 확장 프로그램은 VS Code 확장 프로그램에 비해 눈에 띄게 적은 관심을 받고 있습니다. 제가 컨설팅 중인 Java 프로젝트를 위해 IntelliJ에서 Continue를 테스트해 본 결과, 자동 완성 지연 시간 (autocomplete latency)은 VS Code에서 측정된 것보다 대략 두 배 정도 길었으며, @ 멘션 파일 탐색 (file resolution) 기능은 덜 안정적이었습니다. 중첩된 모듈 디렉토리 내의 파일을 찾는 데 약 15%의 확률로 실패했습니다. 만약 JetBrains가 주력 IDE라면, AI 작업에는 Continue가 설치된 VS Code를 사용하고, 수동 코딩에는 IntelliJ를 사용하는 방식을 권장합니다. 이는 Continue의 마케팅이 제안하는 워크플로우와는 다릅니다.

문서 품질은 엇갈립니다. 핵심 설정 가이드는 철저하고 잘 관리되고 있지만, 문제 해결 (troubleshooting) 섹션은 빈약합니다. macOS 업데이트 이후 저의 로컬 Ollama 설정이 작동을 멈췄을 때, 문서는 적용할 수 없는 두 가지 일반적인 제안(Ollama 재시작, 포트 확인)만을 제공했습니다. 저는 결국 4개월 전의 GitHub 이슈에서 모델 디렉토리에 대한 권한 변경이라는 해결책을 찾아냈습니다. 커뮤니티는 활발하고 응답이 빠르지만, 사용자에게 직접 인프라를 구성하도록 요구하는 도구임에도 문제 해결을 위해 GitHub 이슈에 의존해야 한다는 점은 이상적이지 않습니다.

Continue를 설치해야 하는 대상

모델 선택이 단순한 선호도를 넘어 필수 요구 사항인 환경에서 일한다면 Continue가 올바른 선택입니다. 만약 고객 계약상 코드가 VPN을 벗어날 수 없다면, Ollama를 결합한 Continue가 사용 가능한 가장 강력한 독립형 (self-contained) 옵션입니다. 만약 조직이 특정 제공업체와 대량 API 가격 협상을 마쳤다면, Continue를 통해 플랫폼 중간 수수료를 지불하지 않고 해당 가격을 직접 사용할 수 있습니다. 또한 서로 다른 모델로부터 이득을 얻을 수 있는 사이드 프로젝트를 운영 중이라면 — Claude에 잘 반응하는 Python 코드베이스, GPT-4가 더 정확한 React 프로젝트, API 비용이 전혀 들지 않기를 원하는 로컬 프로젝트 등 — Continue를 사용하면 도구를 변경하지 않고도 프로젝트별로 모델을 전환할 수 있습니다.

확장 프로그램을 설치하고 30초 이내에 바로 코딩을 시작하고 싶다면 잘못된 선택이 될 수 있습니다. 설정 비용 (setup tax)은 실제로 존재합니다. 만약 API 키 (API key)와 엔드포인트 URL (endpoint URL)의 차이를 모르거나, LLM 제공자 (LLM provider)를 설정해 본 적이 없다면 초기 경험이 좌절감을 줄 수 있습니다. 우선 상용 도구를 몇 달간 사용하며 기준점을 파악한 다음, Continue의 비용 절감 및 모델 유연성이 설정 오버헤드 (configuration overhead)를 감수할 만큼 가치가 있는지 평가해 보십시오. 저의 경우, 실제 API 사용량을 바탕으로 수치를 계산해 본 결과, 충분한 가치가 있었습니다.