지도가 먼저, 리뷰는 그다음

풀 리퀘스트의 양쪽에는 서로 다른 두 가지 일이 있습니다. 에이전트가 쓰기 전에는 곧 바꿀 트리의 지도가 필요합니다. 에이전트가 PR을 연 뒤에는, 그 변경을 시스템의 나머지와 대조해 읽고 사람이 행동할 수 있는 코멘트를 남기는 무언가가 있어야 합니다.

이 두 일은 둘 다 “코드베이스를 이해하는 것”을 포함하기 때문에 멀리서 보면 비슷해 보입니다. 같은 제품이 아닙니다. 하나는 “이 변경이 어디에 착륙해야 하는가”에 답합니다. 다른 하나는 “줄 단위 린터가 놓칠, 이 diff가 무엇을 망가뜨렸는가”에 답합니다. 이 둘을 섞으면 더 나쁜 초안과 더 시끄러운 리뷰가 나옵니다.

이 글은 공동 워크플로 가이드입니다. Maguyva는 에이전트가 먼저 질의하는 지도입니다. Greptile은 그다음 PR에 코멘트를 다는 리뷰 에이전트입니다. 이 짝은 구조적으로 상호 보완적입니다: Maguyva는 풀 리퀘스트를 리뷰하지 않고, Greptile은 에이전트가 그것들을 쓰는 데 사용한 컨텍스트 레이어를 대체하지 않습니다.

이 분리가 유용한 이유

훈련 사전 지식과 붙여넣은 몇 개의 파일에서 출발하는 코딩 에이전트는 그럴듯한 경로를 지어내 편집할 것입니다. 그것이 잘못된 파일 실패이며, 검색 문제입니다. Maguyva는 원격 MCP 코드베이스 컨텍스트 레이어입니다: 시맨틱, 구조적(AST), 그래프/의존성, 텍스트 검색이 순위화된 결과로 융합되며, 심볼 조회와 파일 조회도 있습니다. 근거 있는 답변은 path/file.ext:line 형태로 돌아오므로, 패치가 존재하기 전에 실패를 거부할 수 있습니다. 주장은 겸손함을 유지합니다: 더 적은 환각 편집. 모델은 여전히 추측할 수 있습니다. 다만 첫 단계가 더 이상 추측이 아닐 뿐입니다.

Greptile은 AI 코드 리뷰 에이전트입니다. 그들 자신의 표현으로, 코드베이스에 대한 완전한 이해로 모든 풀 리퀘스트를 자동으로 리뷰하며, 시스템 전체가 아니라 파일을 개별적으로 확인하는 전통적인 린터와 대비시킵니다. 설정은 GitHub 또는 GitLab 앱을 설치하고 저장소를 선택하는 것입니다. 운영할 로컬 인덱스가 없습니다. 호스팅은 Greptile Cloud이며(요청 시 제공되는 보고서와 함께 SOC 2 Type II 준수를 표명합니다), 기업을 위한 자체 호스팅 옵션도 제공됩니다.

그들 자신의 번호 매긴 흐름은 이렇습니다: 연결하고 모든 함수, 클래스, 의존성의 의존성 그래프를 구축한다; 모든 풀 리퀘스트에서, 그 전체 저장소 그래프를 사용해 변경을 분석하고 약 3분 안에 제안된 수정과 함께 PR 코멘트로 결과를 게시한다; 각 코멘트는 팀이 이미 사용하는 코딩 에이전트에게 문제를 넘길 수 있다. 그들은 또한 팀의 코딩 표준을 학습하고 시끄러운 제안을 줄이기 위해 시간이 지남에 따라 이전 사람의 PR 코멘트를 읽는다고 밝히고 있습니다. 그들의 학습 시스템은 적응하는 데 2~3주가 필요하다고 밝히고 있습니다.

이것은 리뷰이지 초안 작성이 아닙니다. Greptile의 강점은 이미 PR에 착륙한 변경에 대한 전체 저장소 그래프 컨텍스트이며, 그다음 그 결과를 Claude Code, Codex, Conductor, Cursor, 또는 Devin에게 보내는 닫힌 루프입니다. Maguyva의 강점은 그 변경이 쓰이기 전에 에이전트가 질의한 순위화된 지도입니다. 둘 다 사용하세요. 어느 쪽에게도 다른 쪽의 일을 시키지 마세요.

Maguyva–Greptile의 퍼스트파티 제품 통합은 명시되어 있지 않습니다. 그럴 필요도 없습니다. Maguyva는 MCP를 통해 에이전트와 대화합니다. Greptile은 그들의 앱을 통해 GitHub나 GitLab과 대화합니다. 둘은 풀 리퀘스트에서 만납니다. 접착용 스크립트도, 하나를 다른 하나로 연결하는 크론도 없습니다. 각 제품이 이미 자기 소유의 표면에 앉아 있기 때문에 이 짝에는 bash가 필요 없습니다.

이것이 아닌 것

이것은 Greptile을 깎아내리는 글이 아닙니다. “리뷰어를 바꾸라”는 글도 아닙니다. Greptile은 2024년 3월 5일 Y Combinator W24 기업으로 Hacker News에 출시되었고, 그 스레드는 많은 사람이 처음으로 이 제품을 알게 된 방법입니다. 그렇게 알게 되었다면 계속 쓰세요. 이 페이지는 그 루프에서 빠진 앞부분입니다: Greptile이 보는 PR이 이미 올바른 파일을 겨냥하도록 에이전트를 먼저 근거 있게 만드는 것.

Greptile의 마케팅 자료는 리뷰 속도와 버그 포착 주장을 앞세웁니다. 이를 독립적으로 검증된 수치가 아니라 Greptile 자신의 주장으로 취급하세요. 이 글은 그것들을 사실로 반복하지 않습니다.

언어 커버리지도 같은 종류의 정직함입니다. Greptile은 나열된 목록이 아니라 모든 프로그래밍 언어를 커버한다는 프레임을 지원에 씌우며, 정확한 숫자는 명시되어 있지 않습니다. Maguyva는 279개 이상의 언어와 텍스트 기반 기술을 공개하며, 질문이 기술적일 때는 사이트에 기술적 구분(파서 기반 AST 대 텍스트 전용)도 함께 공개합니다. 서로 다른 제품이 서로 다른 주장을 하는 것입니다. 섞지 마세요.

Greptile의 가격은 이 글이 사용할 수 있는 자료에 명시되어 있지 않습니다. 유료 플랜은 존재합니다. 그들의 가격 페이지를 참고하세요. Maguyva는 좌석이 아니라 워크스페이스 단위로 과금합니다. 플랜은 무료로 시작합니다. 워크스페이스 수치가 필요하다면 가격 페이지에 공개된 등급이 나와 있습니다.

워크플로

세 개의 이름 붙은 단계입니다. 이 순서대로 실행하세요. 이 짝을 처음 시도할 때는 어느 것도 건너뛰지 마세요.

1. Maguyva 컨텍스트

이미 아는 저장소 하나를 색인하세요. 이미 코드를 쓰는 MCP 클라이언트를 연결하세요 — Claude Code, Cursor, Codex CLI, VS Code, Windsurf, 또는 다른 MCP 호환 클라이언트. Maguyva는 24개의 문서화된 MCP 클라이언트에 대한 설정 가이드가 있으며, 표준 MCP 설정을 지원하는 다른 클라이언트에도 연결할 수 있습니다.

누군가 한 줄이라도 쓰기 전에 평가할 수 있는 질문을 하세요. “세션 만료는 어디서 처리되고, 무엇이 그것을 호출하는가?“는 “인증을 고쳐줘”보다 더 나은 첫수입니다. 인용을 요구하세요. file.ext:line 결과를 여세요. 심볼을 따라가세요. 곧 건드릴 의존성을 확인하세요.

Maguyva는 검색, 심볼, 의존성 분석, 파일 조회, 저장소 컨텍스트, 결정론적 유틸리티 워크플로에 걸친 11개의 고객용 MCP 도구를 제공합니다. 네 가지 검색 모드가 순위화된 결과로 융합되며, 이름을 이미 알고 있을 때는 find_symbol가 별도의 도구입니다. 문서는 가장 짧은 경로를 설명합니다: 무료로 시작하고, 이미 아는 저장소를 색인하고, 클라이언트를 연결한 다음, 검증할 수 있는 질문을 하세요.

스냅샷에는 타임스탬프가 찍혀 있어 에이전트가 어떤 버전의 트리를 읽고 있는지 알 수 있습니다. 정직한 한계는 동기화되지 않은 로컬 작업입니다. 변경 사항이 작업 트리에만 존재하고 푸시되지 않았다면, 호스팅된 지도는 아직 그것을 담고 있지 않습니다. 지시 파일(CLAUDE.md, AGENTS.md)은 여전히 관례와 건드리지 말아야 할 것을 위해 여기 속합니다. 그것들은 살아있는 지도가 아닙니다. 행동에는 그것들을 쓰고, 사실에는 Maguyva를 쓰세요.

인용이 저장소와의 접촉에서 살아남기 전에는 에이전트가 PR을 열게 하지 마세요. 그 게이트가 이 단계의 전체 목적입니다.

2. 에이전트 PR

같은 에이전트가 이제 이미 비용을 지불하고 있는 클라이언트에서 변경을 씁니다. Maguyva는 에디터도 리뷰어도 아닙니다. 에이전트는 여전히 diff를 만듭니다. 여러분은 여전히 이미 하던 대로 GitHub나 GitLab에서 풀 리퀘스트를 엽니다.

달라져야 할 것은 첫 파일입니다. PR은 실제로 그 동작을 구현하는 핸들러, 깨질 호출자, 변경이 잘못되었을 때 실패할 테스트를 명시해야 합니다. 1단계를 건너뛰었다면, 3단계는 잘못된 패키지에 착륙한 변경에 코멘트를 쓰느라 시간을 씁니다. Greptile은 여전히 체계적인 문제는 찾을 수 있습니다. 그것이 환각 경로에서까지 회복해야 하는 것은 아닙니다.

PR의 범위를 좁게 유지하세요. 근거 있는 첫 파일이 모듈을 다시 쓸 면허는 아닙니다. 이 상호 보완적인 짝은 에이전트가 지도를 가지고 하나의 일을 하고, 그다음 리뷰어에게 한정된 diff에서 다른 일을 해달라고 요청할 때 작동합니다.

3. Greptile 리뷰

Greptile은 이미 GitHub나 GitLab 앱을 통해 저장소에 연결되어 있습니다. 새 풀 리퀘스트에서 자신이 구축한 전체 저장소 그래프를 사용해 변경을 분석하고, 제안된 수정과 함께 코멘트로 결과를 게시합니다. 그들 자신의 자료는 이 과정을 약 3분으로 잡습니다.

코멘트는 신중한 팀원을 읽듯이 읽으세요: 인용된 위치를 열고, 발견이 진짜인지 판단한 다음, 행동하세요. Greptile이 “Fix with your Agent”를 제공하는 곳에서는, 파일 경로, 줄 번호, 제안된 코드를 담은 문제를 Claude Code, Codex, Conductor, Cursor, 또는 Devin에게 보냅니다. “Fix All”은 리뷰의 모든 문제를 한 번에 보냅니다. 그들은 또한 이 인계를 위해 Greptile MCP와 Claude Code 플러그인도 제공합니다. Maguyva는 그 이름 붙은 대상 목록에 없습니다. 그 부재는 문제가 아닙니다. Maguyva는 이미 1단계에서 자기 일을 마쳤습니다. PR을 쓴 코딩 에이전트가 수정 페이로드를 받아야 할 대상입니다.

Greptile의 학습 시스템이 팀이 실제로 남기는 코멘트에 적응하는 처음 2~3주 동안은 잡음을 예상하세요. 그것이 그들이 밝힌 일정이지, 이 짝의 결함이 아닙니다. 사람의 리뷰는 여전히 루프 안에 있습니다. Greptile은 자동화된 첫 통과이지, 머지 버튼이 아닙니다.

Greptile 코멘트가 에이전트가 1단계에서 한 번도 질의하지 않은 파일을 가리킨다면, 그것은 유용한 신호입니다. 지도가 호출자를 놓쳤거나, 에이전트가 인용을 건너뛴 것입니다. 코멘트에 맞춰 초안을 고치세요. 리뷰어를 끄지 마세요.

이 보완 관계를 정직하게 유지하는 법

• Maguyva가 항상 먼저입니다. 잘못된 파일에 대한 PR 리뷰는 여전히 잘못된 파일에 대한 리뷰입니다.
• Greptile은 항상 그다음입니다. 잘 인용된 초안이라도 여전히 시스템 전체 수준의 diff 읽기가 필요합니다.
• Maguyva에게 PR 코멘트를 게시해 달라고 요청하지 마세요. 그렇게 하지 않습니다.
• Greptile에게 에이전트가 여전히 경로를 고르는 중일 때의 첫 검색 레이어가 되어 달라고 요청하지 마세요. 그것은 그들의 GitHub나 GitLab 앱이 위해 만들어진 일이 아닙니다.
• 둘을 “동기화”하는 bash 파이프라인을 지어내지 마세요. PR이 인터페이스입니다.
• 양쪽을 독립적으로 검증하세요. 이미 아는 저장소를 색인하세요. 검증할 수 있는 질문을 하세요. 그다음 작은 PR을 열고 Greptile이 실제로 뭐라고 코멘트하는지 읽으세요.

이름을 붙이고 나면 이 루프는 평범합니다. 지도가 먼저. 에이전트 PR. 리뷰가 그다음. 각 제품은 자신이 잘하는 풀 리퀘스트 쪽에 남습니다.

// map first. review second. in that order.