로컬 인덱서 없이 AI 에이전트에게 대규모 저장소의 컨텍스트 주기

대규모 저장소는 컨텍스트 창에 들어가지 않으며, 진짜 모노레포에 노트북 인덱서를 돌려본 적이 있다면 거기에도 편하게 들어가지 않는다는 걸 압니다 — RAM이 치솟고, 첫 인덱싱에 한 시간이 걸리고, 에이전트는 다음 세션을 시작할 때도 여전히 어떤 파일이 중요한지 추측합니다.

흔한 답은 에디터 옆에 인덱서를 돌리는 것이고, 한 대의 머신에 편하게 들어가는 저장소라면 좋은 답입니다. 모노레포가 이미 Cursor에서 빠르게 색인되고, 지도가 필요한 곳이 거기뿐이라면, 이 글은 더 보탤 게 없습니다 — 건너뛰세요.

이 글은 다른 경우 — 에이전트가 대규모 저장소의 질의 가능한 지도가 필요하고, 그것을 얻기 위해 로컬 인덱서를 돌리고 싶지 않을 때 — 에 관한 것입니다.

로컬 인덱서가 잘못된 도구인 경우

로컬 인덱스는 코드가 그것을 질의할 머신 위에 산다고 가정하며, 진짜 모노레포 규모에서는 이 가정이 단일 에디터 안에서조차 팽팽해집니다. 저장소는 노트북에 계속 데워둘 만한 크기를 그저 넘어섭니다: 하나의 패키지에서 작업하는 동안 영향 범위은 세 디렉터리 너머에 있고, 200만 줄짜리 트리의 첫 콜드 인덱싱은 두 번 겪고 싶은 일이 아닙니다 — 여러분의 머신에서도, 그 트리를 한 번도 클론한 적 없는 CI 러너에서도. 아니면 팀 동료가 자기 머신이 같은 인덱스를 힘겹게 통과하기를 기다리지 않고, 여러분과 같은 지도를 질의할 수 있어야 할 수도 있습니다.

이 중 어느 것도 좋은 에디터 인덱서를 버릴 이유는 아닙니다. 여러분의 어떤 에이전트든 MCP를 통해 질의할 수 있는 호스팅된 지도도 함께 가질 이유입니다.

그리고 규모의 문제는 “붙여넣기엔 파일이 너무 많다”는 것보다 더 깊습니다. 큰 트리에서 흥미로운 질문은 거의 “이 파일을 보여줘”가 아닙니다 — 어떤 파일인지, 어떤 심볼인지, 어떤 호출자인지, 어떤 테스트인지입니다. src/을 나열하고 처음 세 개의 결과를 읽는 것으로 시작하는 에이전트는 apps/api에 있는 핸들러와 packages/sdk에 있는 생성된 클라이언트를 아무렇지 않게 놓칠 것입니다. 필요한 것은 전체 트리로부터 구축되고, 순위가 매겨지고, 인용된 검색입니다.

“대규모 저장소의 컨텍스트”가 실제로 의미하는 것

프롬프트에 파일을 쏟아붓는 것은 컨텍스트가 아닙니다 — 트리의 더 작고 더 나쁜 사본일 뿐입니다. 여러분의 에이전트가 실제로 필요한 것은 질문을 하고 인용된 답을 돌려받는 것입니다: 이 심볼은 어디에 정의되어 있고 누가 호출하는지, 지금 바꾸려는 모듈에 무엇이 의존하는지, 어떤 테스트 파일이 이 동작을 커버하는지, 그리고 트리가 지난 분기가 아니라 지금 어떻게 생겼는지.

이 답들은 다른 사람들의 저장소에 대한 모델의 기억이 아니라 여러분의 저장소로부터 구축된 인덱스에서 나와야 하고, 그 인덱스는 에이전트의 컨텍스트 창이 아닌 다른 어딘가에 살아야 합니다. 이 문제에서는 여러분의 노트북이 아닌 다른 어딘가에도 살아야 합니다.

지시 파일이 여러분을 위해 해줄 수 없는 또 하나: CLAUDE.md와 AGENTS.md는 관례와 행동을 위한 올바른 자리지만, 200만 줄짜리 트리의 살아있고, 순위화되고, 질의 가능한 지도는 아닙니다. 행동에는 규칙을 쓰고, 사실에는 저장소 인텔리전스를 쓰세요.

클라우드에서 지도를 만들고, 어떤 클라이언트에서든 질의하기

Maguyva는 원격 MCP 코드베이스 컨텍스트 레이어입니다. GitHub를 연결하고, 저장소를 선택하면, 클라우드 파이프라인이 트리를 파싱하고 심볼과 그래프 엣지를 구축하고 순위화된 지도를 유지하는 동안 자리를 뜨면 됩니다 — 로컬 인덱서는 결코 없습니다.

코드를 푸시하면, 변경된 파일은 점진적으로 파싱되고, 그래프와 랭킹 레이어는 일정에 따라 재구축됩니다: 무료 플랜에서는 매일, 유료 플랜에서는 매시간. 모든 스냅샷에는 타임스탬프가 찍혀 있어 에이전트가 어떤 버전의 트리를 읽고 있는지 알 수 있습니다. 여기서 정직한 한계는 동기화되지 않은 로컬 작업입니다 — 작업 트리에만 존재하고 한 번도 푸시된 적 없는 변경 사항은 아직 호스팅된 지도에 없습니다.

그다음 이미 사용하는 클라이언트의 MCP 설정에 API 키를 추가해 연결합니다. 24개의 문서화된 MCP 클라이언트에 대한 설정 가이드가 있으며, 표준 설정을 지원하는 다른 MCP 호환 클라이언트도 연결할 수 있습니다. Cursor가 여러분의 근거지라면 Cursor 페이지가 그 경로를 안내합니다. 같은 서버가 Claude Code, VS Code, Windsurf, Codex CLI 등에도 응답합니다.

에디터를 바꾸지 않습니다. 검색, 심볼, 의존성 분석, 파일 조회, 저장소 컨텍스트에 걸친 도구 표면 — 11개의 MCP 도구 — 을 279개 이상의 언어와 텍스트 기반 기술을 아우르는 커버리지와 함께 에이전트에게 제공합니다. 이는 몇 년 전에 이미 단일 언어가 아니게 된 모노레포에서 생각보다 더 중요합니다.

답변은 줄 번호가 붙은 파일 경로로, 근거를 갖춘 채 돌아옵니다. 시맨틱, 구조적, 그래프, 텍스트 검색이 순위화된 결과로 융합되어, “parseConfig에 무엇이 의존하는가” 같은 질문이 grep 덤프나 단일 시맨틱 조각이 아니라 실제로 중요한 몇 곳을 돌려줍니다.

구체적인 방법

회사 전체를 색인하는 것으로 시작하지 마세요. 실제로 통하는 경로는 이렇습니다:

1. 이미 잘 아는 저장소 하나를 고르세요 — 손으로 평가할 수 있는 패키지가 가진 가장 큰 트리보다 낫습니다.
2. 무료로 시작하세요: 저장소 3개, 색인 5만 줄, 11개 도구 전부, 월간 질의 한도 없음. 대표 저장소가 그보다 크다면, 가격 페이지에 색인된 규모별 워크스페이스 등급($0, $19, $49, $149)이 좌석 수가 아니라 나와 있습니다.
3. GitHub를 연결하고 첫 색인이 끝나기를 기다리세요. 로컬에서 아무것도 컴파일하지 않습니다.
4. MCP 클라이언트를 연결하세요 — 몇 줄의 설정. Maguyva는 원격 MCP 서버이므로 플러그인도, 확장도, 채택해야 할 두 번째 에디터도 없습니다.
5. 검증할 수 있는 질문을 하나 하세요. “parseConfig에 무엇이 의존하는가?” 또는 “로그인 세션 만료는 어디서 처리되는가?” 그런 다음 인용된 file.ext:line 결과를 열어 눈앞의 트리와 대조하세요.
6. 인용이 그 대조를 견뎌낸 뒤에야 에이전트가 편집하게 하세요.

첫 저장소가 잘 맞고 트리가 크다면, 색인된 줄 수와 재구축 주기에 맞춰 워크스페이스를 올리세요. 사람과 에이전트는 같은 사용자 수를 공유합니다 — Maguyva는 좌석이 아니라 워크스페이스 단위로 과금하므로 — 세 번째 에이전트를 루프에 추가해도 비용이 들지 않습니다.

활성화 테스트는 문서가 모든 첫 실행에 권장하는 것과 같습니다: 이미 아는 저장소를 색인하고, 검증할 수 있는 질문을 하세요. 대규모 저장소라고 테스트가 달라지지 않습니다. 다만 잘못된 첫 파일의 대가가 더 커질 뿐입니다.

연결한 뒤 지켜볼 것

세 가지를 지켜보세요. 최신성: 유료 플랜은 매시간, 무료 플랜은 매일 재구축되며, 푸시되지 않은 로컬 작업은 지도에 없을 것입니다 — 그것이 여러분이 감수하는 거래입니다. 범위: 보관된 모든 포크가 아니라 대표적인 저장소 집합을 색인하세요. 무료 등급은 답이 유지할 가치가 있는지 알아보도록 의도적으로 규모가 잡혀 있습니다. 그리고 검증: 경로와 줄 번호를 인용하지 못하는 대규모 저장소 지도는 그저 더 느린 추측 엔진일 뿐이니, 에이전트가 패치를 내놓기 전에 위치를 보여주게 하세요.

그런 다음 작은 저장소에서 하던 것과 같은 테스트를 실행하세요. 이미 아는 저장소를 색인하세요. 검증할 수 있는 질문을 하세요. 지도가 진짜라면, 여러분의 에이전트는 더 이상 차가운 트리에서 출발하지 않습니다.

// no laptop got hot building this map.