이상한 경험을 한 적 있으실 겁니다. 도구 A와 도구 B에서 똑같은 모델을 골라놓고, 똑같은 질문을 던졌는데 답의 품질이 확연히 다릅니다. 한쪽은 프로젝트의 기존 함수를 알아서 찾아 쓰는데, 다른 쪽은 없는 함수를 지어냅니다. 모델이 같은데 왜 이럴까요. 대부분의 AI 코딩 도구 비교 글은 모델 이름과 월 구독료를 나란히 놓은 표에서 끝납니다. 하지만 실제 체감 품질을 가르는 건 그 표에 없는 축입니다. 바로 도구가 내 코드를 어떻게 찾아서 모델에게 건네주는가입니다. 이 글에서는 그 축을 기준으로 도구를 비교하는 법과, 오늘 바로 확인할 수 있는 4단계 점검 순서를 정리합니다. (본 글은 작성 시점인 2026년 8월 기준이며, 각 도구의 정책은 자주 바뀝니다.)
왜 모델이 같아도 결과가 다를까
LLM은 자기가 보지 못한 코드에 대해서는 추측밖에 할 수 없습니다. 프로젝트에 수천 개의 파일이 있어도 모델의 컨텍스트 창에 실제로 들어가는 건 그중 극히 일부입니다. 그 일부를 고르는 일은 모델이 아니라 도구(하네스)가 합니다.
즉 도구를 쓴다는 건 "모델을 산다"기보다 "내 코드를 골라주는 사서를 고용한다"에 가깝습니다. 사서가 서가 배치를 미리 외워둔 사람인지, 요청받을 때마다 직접 서가를 뒤지는 사람인지에 따라 결과가 달라지는 겁니다. 그리고 현재 주요 도구들은 이 지점에서 서로 다른 설계를 택하고 있습니다.
AI 코딩 도구 비교의 첫 번째 축: 코드를 찾아오는 방식
방식 1 — 미리 색인해두기 (인덱싱형)
Cursor가 대표적입니다. 공개된 Cursor 공식 기술 블로그에 따르면, 코드베이스 인덱싱을 켜면 파일들의 해시로 머클 트리(Merkle tree)를 만들고, 파일을 조각(chunk)으로 나눠 임베딩으로 변환한 뒤 벡터 DB에 저장합니다. 이후 주기적으로 해시를 비교해 바뀐 파일만 다시 올립니다. .gitignore와 .cursorignore에 적힌 경로는 색인에서 빠집니다.
이 방식의 장점은 "이 기능 어디서 처리해?"처럼 이름을 모르는 대상을 의미로 찾을 때 강하다는 점입니다. 파일명이나 함수명을 정확히 몰라도 유사도로 후보를 끌어옵니다. 대신 색인은 본질적으로 과거의 스냅샷입니다. 방금 대규모 리팩터링을 했거나 브랜치를 갈아탄 직후라면, 갱신되기 전까지는 이미 사라진 구조를 근거로 답할 수 있습니다.
방식 2 — 그때그때 찾아 읽기 (탐색형)
Claude Code는 반대쪽 설계에 가깝습니다. Anthropic이 정리한 컨텍스트 엔지니어링 글에서는, 미리 만들어둔 색인 대신 glob·grep 같은 도구로 필요한 순간에 파일을 찾아 읽는 방식을 설명합니다. 사람 개발자가 낯선 저장소를 처음 열었을 때 하는 행동과 같습니다. 일단 디렉터리를 훑고, 키워드로 검색하고, 걸린 파일을 열어봅니다.
장점은 항상 지금 이 순간의 파일을 본다는 것입니다. 색인이 낡을 여지가 없습니다. 단점은 탐색 자체에 토큰과 시간이 든다는 점, 그리고 검색어가 빗나가면 엉뚱한 곳을 뒤진다는 점입니다. 그래서 이 방식의 도구일수록 "어디를 봐야 하는지"를 알려주는 규칙 파일의 역할이 커집니다.
| 구분 | 인덱싱형 | 탐색형 |
|---|---|---|
| 강한 질문 | "비슷한 코드 어디 있지?" | "이 파일 지금 상태 그대로 고쳐줘" |
| 최신성 | 갱신 주기에 의존 | 항상 현재 파일 |
| 첫 응답 속도 | 색인이 있으면 빠름 | 탐색 단계만큼 지연 |
| 코드 외부 전송 | 색인 대상 조각이 서버로 | 읽은 파일만 컨텍스트로 |
어느 쪽이 우월하다는 얘기가 아닙니다. 레거시가 쌓인 대형 저장소에서 "이런 기능이 이미 있었나?"를 자주 묻는다면 인덱싱형이 편하고, 브랜치를 자주 갈아타며 좁은 범위를 깊게 고치는 작업이 많다면 탐색형이 덜 답답합니다.
두 번째 축: 규칙을 어디에 적어두는가
두 번째로 자주 간과되는 축은 "프로젝트 규칙을 적어두는 파일이 다른 도구로 옮겨가느냐"입니다. 도구를 갈아탈 때마다 규칙을 다시 쓰는 건 생각보다 큰 전환 비용입니다.
GitHub Copilot은 공식 문서 기준으로 저장소 전체에 적용되는 .github/copilot-instructions.md와, 특정 경로에만 적용되는 .github/instructions/**/*.instructions.md를 지원합니다. 여기에 더해 GitHub는 2025년 8월 체인지로그를 통해 코딩 에이전트가 저장소 루트의 AGENTS.md를 읽는다고 밝혔고, 문서에는 CLAUDE.md·GEMINI.md도 함께 인식한다고 적혀 있습니다. 하위 디렉터리에 중첩해 두면 트리에서 가장 가까운 파일이 우선합니다.
한편 Claude Code는 공식 메모리 문서에서 CLAUDE.md를 세션 시작 시점에 읽어 들이는 파일로 설명합니다. 같은 문서는 파일이 200줄을 넘어가면 컨텍스트를 많이 잡아먹고 지시 준수도가 떨어질 수 있다고 안내합니다. 규칙 파일은 길게 쓸수록 좋은 게 아니라는 뜻입니다.
정리하면, AGENTS.md 같은 공용 포맷에 규칙을 모아두면 도구를 바꿔도 상당 부분이 따라옵니다. 반대로 특정 도구 전용 포맷에만 규칙을 쌓아두면, 나중에 비교 테스트를 해보려 할 때 새 도구는 "규칙 없는 상태"로 평가받아 불리해집니다. 비교가 공정하지 않게 되는 겁니다.
실전: 내 상황에 맞는 도구 고르는 4단계
1단계 — 내가 가장 자주 던지는 질문 유형을 적어본다
일주일 치 작업을 떠올리며 질문을 두 부류로 나눠보세요. ①"이런 거 이미 구현돼 있나?" 같은 탐색형 질문, ②"이 파일 이 함수 이렇게 바꿔줘" 같은 지정형 질문. ①의 비중이 높으면 의미 검색이 강한 인덱싱형이, ②가 대부분이면 탐색형이 잘 맞습니다. 이 한 장을 적는 데 10분이면 충분하고, 벤치마크 점수 열 개보다 유용합니다.
2단계 — 규칙 파일부터 공용 포맷으로 옮긴다
도구를 비교하기 전에 프로젝트 규칙(빌드 명령, 테스트 명령, 코딩 컨벤션, 건드리면 안 되는 경로)을 루트의 AGENTS.md에 한 번 정리해 두세요. 앞서 본 것처럼 Copilot 계열은 이 파일을 읽고, Claude Code는 CLAUDE.md에서 이를 참조하도록 연결해 둘 수 있습니다. 이렇게 해두면 다음 단계의 비교가 같은 출발선에서 이뤄집니다.
3단계 — 색인 범위와 제외 경로를 확인한다
인덱싱형 도구를 검토 중이라면, 무엇이 서버로 올라가는지 먼저 확인하세요. Cursor의 경우 .gitignore·.cursorignore에 걸린 경로는 색인에서 제외된다고 문서화돼 있습니다. 회사 저장소라면 이 부분은 개인 취향이 아니라 보안 검토 항목입니다. 도입 전에 팀 정책과 맞는지 확인하고, 애매하면 사내 보안 담당자와 상의하는 편이 안전합니다.
4단계 — 같은 작업 3개로 2주 병행해본다
가장 확실한 비교는 직접 돌려보는 것입니다. 다만 무작위로 써보면 인상만 남으니, 아래처럼 고정하세요.
- 작업 3종 고정: 버그 수정 1건, 신규 기능 1건, 테스트 코드 작성 1건
- 같은 프롬프트로 두 도구에 각각 던지기
- 기록 항목 3개: 첫 결과까지 걸린 시간, 사람이 손댄 줄 수, 없는 함수·API를 지어냈는지 여부
세 번째 항목이 핵심입니다. 존재하지 않는 함수를 만들어내는 빈도는 그 도구가 내 코드를 실제로 얼마나 봤는지를 가장 정직하게 보여주는 지표입니다.
흔히 하는 세 가지 실수
- 벤치마크 점수만 보고 결정 — 공개 벤치마크는 독립된 문제를 풀지만, 실무는 남의 코드가 잔뜩 얽힌 저장소에서 시작합니다. 측정 대상이 다릅니다.
- 규칙 파일 없이 비교 — 규칙을 안 준 상태의 비교는 도구가 아니라 기본값을 비교하는 것에 가깝습니다.
- 도구 하나에 전부 몰아주기 — 자동완성은 A, 큰 리팩터링은 B처럼 역할을 나눠 쓰는 조합도 충분히 현실적인 선택지입니다.
자주 묻는 질문
Q. 색인을 켜면 회사 코드가 그대로 저장되나요?
도구마다 정책이 다릅니다. Cursor는 파일을 조각내 임베딩으로 변환해 저장하는 구조를 공개하고 있으니, 도입 전 해당 문서를 직접 읽고 사내 정책과 대조하는 게 맞습니다.
Q. AGENTS.md와 CLAUDE.md를 둘 다 둬야 하나요?
내용이 갈라지면 오히려 혼선이 생깁니다. 공통 규칙은 한 파일에 두고 다른 쪽에서 참조하게 두는 편이 유지하기 쉽습니다.
Q. 규칙 파일에 뭘 적어야 할지 모르겠습니다.
신입에게 첫날 설명해야 할 것들을 적으면 됩니다. 빌드·테스트 명령, 폴더 구조 요약, 자주 쓰는 컨벤션, 손대면 안 되는 영역. 길이는 짧게 유지하세요.
결론
AI 코딩 도구 비교에서 모델 이름과 가격은 이미 잘 알려진 축입니다. 정작 매일의 체감을 가르는 건 도구가 내 코드를 어떻게 찾아오는지(색인이냐 탐색이냐), 그리고 내 규칙이 어디에 저장돼 다른 도구로 옮겨갈 수 있는지입니다. 오늘은 프로젝트 루트에 AGENTS.md 한 장을 만들어 빌드·테스트 명령과 컨벤션을 적는 것부터 시작해보세요. 그것만으로도 지금 쓰는 도구의 답이 달라지고, 다음에 다른 도구를 시험할 때 공정한 비교가 가능해집니다.
본 글은 2026년 8월 작성 시점 기준의 일반 정보 제공 목적이며, 각 도구의 기능·정책은 수시로 변경될 수 있으니 도입 전 공식 문서를 확인하시기 바랍니다.
댓글 없음:
댓글 쓰기