지금은 AI 코딩 에이전트가 아주 많고, 마케팅은 대부분 소음이다. 모두가 “당신의 전체 코드베이스를 이해한다”고 말한다. 그래서 나는 세 제품의 소스를 읽었고, 이들은 코드를 모델의 컨텍스트에 넣는 방식이라는 한 가지 설계 선택에 따라 세 진영으로 명확히 갈렸다. Aider는 코드의 정적 그래프에 순위를 매긴다. Continue는 코드를 벡터 인덱스에 임베딩한 뒤 검색한다. Cline은 인덱스를 전혀 만들지 않고 모델이 도구를 통해 필요할 때 파일을 읽게 한다. 이 한 가지 선택, 즉 미리 선택할지 모델이 가져오게 할지가 이후의 거의 모든 것을 결정한다. 동작이 결정적인지, 토큰 비용이 얼마인지, 코드가 기기 밖으로 나가는지, 대규모 저장소를 어떻게 감당하는지가 여기서 갈린다. 이 글은 Aider v0.86.3.dev, Continue v2.1.0, Cline v4.0.5를 읽은 기준으로 지형과 당신의 위치를 그린다.
하나의 질문
모든 것은 이 질문으로 귀결된다. 모델이 코드를 봐야 할 때, 무엇을 볼지 누가 결정하는가? 에이전트가 미리 결정하는가, 아니면 그 순간 모델이 직접 결정하는가?
- 인덱스 우선 에이전트는 저장소 위에 구조를 만들고, 주입할 관련 부분을 미리 선택한다. 모델은 선별된 뷰를 받는다. (Aider, Continue.)
- 에이전틱 에이전트는 아무것도 만들지 않고 모델에 도구를 건넨다. 모델은 진행하면서 코드를 가져온다. 모델은 자신이 가져와야 한다고 판단한 것을 받는다. (Cline.)
그리고 두 인덱스 우선 에이전트는 어떤 종류의 인덱스인지에 따라 다시 갈린다. 정적 분석 그래프인지, 시맨틱 임베딩인지가 다르다. 이렇게 세 진영이 생긴다.
핵심 구분은 코드 컨텍스트를 누가 선택하느냐다. 정적 그래프, 시맨틱 검색 인덱스, 도구를 통해 파일을 가져오는 모델로 나뉜다.
진영 1 — 정적 그래프(Aider)
Aider는 저장소 맵을 만든다. tree-sitter로 코드를 파싱하고, 어떤 파일이 어떤 심벌을 참조하는지 그래프를 만든 다음, 그 위에서 PageRank를 실행해 구조적으로 중심적인 항목의 순위를 매긴다. 이후 이진 탐색으로 순위가 높은 시그니처를 토큰 예산에 맞춰 채운다(repomap.py:525, :666). 이 경로에는 임베딩도 네트워크도 없다. 순위는 결정적이며, 당신이 이름을 언급한 파일을 선호한다. 저렴하고 오프라인으로 작동하며 예측할 수 있다. 하지만 코드를 의미가 아니라 이름과 중심성으로 찾기 때문에, 원하는 것을 언급해서 방향을 잡아줘야 한다. (전체 메커니즘은 Aider 저장소 맵 티어다운에서 다룬다.)
진영 2 — 임베딩과 검색(Continue)
Continue는 사람들이 “코드베이스를 이해한다”는 말을 들을 때 대개 떠올리는 일을 한다. 파일을 청크로 나누고, 청크를 임베딩한 뒤, 유사도로 검색한다. 기본적으로 이 임베딩은 번들로 제공되는 all-MiniLM-L6-v2로 로컬에서 계산되며, SQLite 전문 검색 인덱스와 함께 로컬 LanceDB에 저장된다(load.ts:424, LanceDbIndex.ts:203). 쿼리는 벡터 검색 결과, 전문 검색 결과, 리랭커를 혼합해 약 25개 청크로 추려 답한다(retrieval.ts:9). 이름을 모를 때도 “날짜를 파싱하는 함수”를 찾을 수 있는 유일한 진영이다. 대신 유지해야 할 인덱스가 생기고, 실질적인 프라이버시 선택지가 하나 따른다. 원격 임베딩 제공자를 지정하면 코드 청크가 외부로 POST된다(OpenAI.ts:717). (전체 메커니즘은 Continue 인덱싱 티어다운에서 다룬다.)
진영 3 — 에이전틱, 인덱스 없음(Cline)
Cline은 코드베이스 인덱스를 전혀 유지하지 않는다. 임베딩도, 벡터 저장소도, 순위가 매겨진 개요도 없다. 나는 모든 벡터/임베딩 라이브러리를 grep했지만 코드를 인덱싱하는 것은 아무것도 찾지 못했다. 대신 모델은 도구를 통해 필요할 때 코드를 가져온다. read_file은 디스크의 경로를 매번 새로 읽고(ReadFileToolHandler.ts:362), search_files는 ripgrep을 셸로 실행하며(ripgrep/index.ts:64), list_code_definition_names는 호출할 때마다 tree-sitter로 디렉터리를 파싱한다. 소스에는 말 그대로 TODO: implement caching이 남아 있다(tree-sitter/index.ts:9, ListCodeDefinitionNamesToolHandler.ts:79). Cline이 자동으로 주입하는 것은 코드가 아니라 상태뿐이다. 열린 탭, 터미널, 항목 200개로 제한된 재귀적 파일 목록을 담은 <environment_details> 블록이며, 작업 시작 시 한 번 보여준다(task/index.ts:4189, :4341, :1719). 대화가 길어져도 인덱스 순위를 다시 매기지 않는다. 슬라이딩 윈도우로 오래된 턴을 삭제하며, 요약도 할 수 있다(ContextManager.ts:299). Cline도 Aider처럼 tree-sitter를 사용한다는 점에 주목하자. 하지만 미리 구축한 순위 개요로 쓰는 것이 아니라, 모델이 요청할 때 반응적으로 쓴다.
비교
| Aider — 정적 그래프 | Continue — 임베딩 | Cline — 에이전틱 | |
|---|---|---|---|
| 코드 선택 방식 | 참조 그래프에 PageRank 적용 | 벡터 유사도 + 전문 검색 + 리랭킹 | 모델이 턴마다 도구 호출 |
| 사전 구축 인덱스 | 임시 개요(mtime 캐시) | 있음 — LanceDB + FTS, 갱신됨 | 없음 |
| 관련성 신호 | 그래프 중심성 + 당신의 언급 | 시맨틱 유사도 | 모델의 판단 |
| 결정적인가? | 그렇다 | 임베딩 모델에 따라 다르다 | 모델의 선택에 따라 다르다 |
| 의미로 코드를 찾는가? | 아니다 — 이름/중심성 기준 | 그렇다 | 그렇다 — 모델이 grep하고 읽는다 |
| 상시 인프라 | 없음(파싱뿐) | 구축하고 최신 상태로 유지할 인덱스 | 없음 |
| 토큰 비용 형태 | 컨텍스트 예산으로 제한 | 제한됨(상위 N개) | 읽을수록 증가하며 압축이 필요 |
| 프라이버시 노출면 | 외부로 나가는 것 없음 | 기본은 로컬, 원격 제공자는 코드를 전송 | 모델이 읽는 만큼 코드가 외부로 나감 |
| 최신성 | 파일 변경 시 재계산 | 해시 차이로 갱신 | 항상 실시간 — 현재 파일을 읽음 |
이 구분이 모든 것을 결정하는 이유
어느 행을 골라도 각 진영은 메커니즘이 정한 바로 그 위치에 놓인다. 결정성: Aider의 PageRank는 같은 코드에 같은 개요를 내놓지만, Cline의 컨텍스트는 모델이 무엇을 열기로 했는지에 따라 달라진다. 토큰 비용: 인덱스 우선 에이전트는 인덱스를 만드는 비용을 한 번 지불한 뒤 제한된 부분을 주입한다. 에이전틱 에이전트는 턴마다 비용을 지불하며, 긴 작업에서는 압축이 읽은 파일을 쳐낼 때까지 내용이 누적된다. 프라이버시: Aider는 아무것도 보내지 않고, Continue는 원격 임베더를 선택하기 전까지 로컬이며, Cline의 노출 범위는 단순히 “모델이 읽는 모든 것”이다. 대규모 저장소: 그래프와 벡터 인덱스는 모두 사전 계산으로 확장한다. 에이전트는 탐색으로 확장한다. 그래서 Cline은 파일 목록을 200개로 제한하고 모델이 list_files로 더 깊이 들어가기를 기대한다.
어느 하나가 엄격히 더 낫지는 않다. 실패하는 방식이 서로 다르며, 그것이 이 비교의 핵심이다.
당신은 어디에 맞는가?
- 저렴하고 결정적이며 오프라인인 컨텍스트를 원하고, 중요한 것의 이름을 언급할 의향이 있다 → 정적 그래프 진영(Aider). 인덱스 서버가 필요 없고 아무것도 외부로 나가지 않지만, 파일과 심벌을 언급해 방향을 잡아줘야 한다.
- 대규모 저장소에서 의미로 코드를 찾고 싶고, 인덱스를 유지할 의향이 있다 → 임베딩 진영(Continue). 시맨틱 재현율은 실제로 얻을 수 있다. 다만 원격 임베딩과 로컬 임베딩 중 무엇을 쓸지는 의식적으로 선택해야 한다. 이것이 데이터 반출을 결정하기 때문이다.
- 관리할 인덱스 없이 최신 모델에서 실시간으로 읽고 편집하는 자율 에이전트를 원한다 → 에이전틱 진영(Cline). 항상 현재 파일을 대상으로 작업하지만, 긴 작업에서는 토큰 비용을 지켜봐야 한다. 그리고 그 “이해”는 무엇을 열어야 한다고 판단했는지만큼만 좋다는 점을 알아야 한다.
범위와 정직성
이 진영은 각 에이전트의 기본이자 정체성을 규정하는 메커니즘을 말하며, 가두는 틀이 아니다. 현대 에이전트는 방식을 섞는다. Continue에도 도구를 쓰는 에이전트 모드가 있고, Cline에는 서브에이전트와 포커스 체인이 있다. 여기 표시만 해두고 이번 글에서는 읽지 않은 네 번째 형태도 있다. 관리형 검색 서버(Sourcegraph Cody, Tabby)로, 2번 진영의 임베딩을 공유 백엔드로 옮긴 형태다. 비교표에 놓기 전에 하나는 직접 읽어보고 싶다. 그리고 이 모든 내용은 버전에 고정되어 있다. Aider v0.86.3.dev, Continue v2.1.0, Cline v4.0.5 기준이다. Aider와 Continue의 메커니즘은 링크한 티어다운에서 각각 소스와 대조해 검증했다. Cline의 “인덱스 없음, 주문형 도구” 주장은 커밋 9da3c59에서 적대적 검증을 거쳤다. 잠금 파일까지 확인했는데, 확장 프로그램에서 SQLite를 쓰는 유일한 곳은 파일 잠금 테이블이며 인덱스가 아니다.
