Qodo의 Mined Review Rules를 코드를 작성하는 Agent에 적용하는 방법 (단계별 가이드, 2026)

코드 리뷰는 대부분의 팀에서 표준이 강제되는 곳이며, 재작업(rework)을 통해 작동합니다. 누군가 한 가지 방식으로 코드를 작성하면, 이전에 이것이 잘못되는 것을 본 적이 있는 리뷰어가 이를 지적하고, 코드가 다시 작성됩니다. 지식 전달은 실제로 일어나지만, 작업이 끝난 후에 발생합니다.

작성자가 인간일 때는 이 루프를 감당할 수 있습니다. 리뷰어가 한 번 수정해 주면 작성자는 대개 이를 기억하기 때문입니다. 하지만 Agent가 코드를 작성할 때는 이 루프가 닫히지 않습니다. 잘못된 방식으로 코드를 작성한 Agent는 다음 주에도 똑같이 잘못된 방식으로 작성할 것입니다. 리뷰 내용 중 그 어떤 것도 Agent가 아는 지식의 일부가 되지 않았기 때문입니다. 결국 재작업 비용을 한 번이 아니라 반복해서 지불하게 됩니다.

Rule Miner는 이 상황을 개선하고 더 가시적으로 만들어 줍니다. 표준이 한 시니어 엔지니어의 머릿속에 머무는 대신 명시적인 산출물이 되므로 더 나아집니다. 또한 리뷰에서 계속 잡아내는 항목들의 목록을 볼 수 있게 되므로 더 가시적입니다. Qodo는 어떤 것이 자격을 갖추는지 명확히 규정합니다. "개발자가 수락하고 코드 변경으로 이어진 댓글만 고려됩니다." 마이닝된 각 규칙은 실제로 반영된, 반복적인 수정을 나타냅니다.

신호 가중치(signal weighting)는 이러한 규칙이 무엇인지 알려줍니다. Qodo는 "변경된 코드에 대한 각 리뷰어의 소유권(ownership)을 추정하고 이에 따라 댓글에 가중치를 부여하므로, 규칙은 해당 코드에 가장 익숙한 사람들의 표준을 반영"합니다. 반복되는 피드백은 "규칙 후보로 격상"되며, "영향을 받는 코드에 대해 강력한 소유권을 가진 리뷰어의 댓글인 경우 단 하나의 댓글만으로도 자격을 얻을 수 있습니다." 클러스터링을 통해 "해당 규칙이 지배하는 경로로 범위가 지정된 영역별 규칙(area-specific rules)"이 생성됩니다. 그리고 시스템은 스스로 수정합니다. "규칙이 활성화되면, 해당 규칙이 생성한 제안 중 거부된 제안은 시간이 지남에 따라 신호를 감소시키므로 노이즈는 자연스럽게 사라집니다."

이것은 전적으로 리뷰어를 겨냥한 잘 설계된 학습 루프입니다. 하지만 작성자(점점 더 Agent가 되어가는)는 이 루프에 포함되어 있지 않습니다.

리뷰 피드백을 바탕으로 AGENTS.md 직접 작성하기. 누군가 3개월 치의 pull request를 읽고 컨벤션을 지침 파일로 정리합니다. 처음에는 작동하지만 곧 멈춥니다. 아무도 이 작업을 반복하지 않기 때문입니다. 6개월이 지나면 그 파일은 지난 봄의 표준을 설명하게 되고, 이 실패는 눈에 보이지 않습니다. 오래된 지침 파일은 최신 파일과 똑같이 생겼기 때문입니다. 이것이 바로 why agents ignore your instruction files에서 다루는 드리프트(drift) 문제입니다.

Qodo의 마이닝된 규칙을 지침 파일에 수동으로 복사하기. 소스가 유지 관리되므로 앞의 방법보다는 낫습니다. 하지만 유지 관리 측면에서는 더 나쁩니다. Rule Miner는 계속 작동하여 "2주마다 학습을 지속하며, 실행당 저장소별로 최대 5개의 새로운 규칙을 생성"하는 반면, 여러분이 복사한 파일은 그렇지 않기 때문입니다. 수동 동기화 단계가 있는 두 개의 단일 진실 공급원(source of truth)은 결국 하나의 진실 공급원과 하나의 버그가 될 뿐입니다.

리뷰에서 걸러내도록 방치하기. 대부분의 팀이 처한 솔직한 기본 상태입니다. 인간에게는 괜찮지만, Agent에게는 비용이 많이 듭니다.

Agent가 코드베이스에서 컨벤션을 추론할 것이라고 가정하기. Agent는 눈에 보이는 로컬 패턴을 맞추는 데는 능숙하지만, 금지 사항을 추론하는 데는 서툽니다. 코드의 그 어디에도 "장애가 발생한 이후로는 그런 방식으로 작업하지 않기로 했습니다"라고 적혀 있지 않습니다. 패턴의 부재를 규칙으로 읽어낼 수는 없습니다.

1단계: 실제로 무엇이 마이닝되었고, 어떤 윈도우에서 마이닝되었는지 확인하기

무엇이든 연결하기 전에 먼저 무엇이 존재하는지 확인하세요. 마이닝된 규칙은 Review Standards 페이지의 Rules 탭에 "Mined Pattern 소스 유형"으로 표시되어 사람이 작성한 규칙과 구분됩니다. 저장소에 아무것도 표시되지 않는다면, 무언가 고장 났다고 가정하기 전에 트리거 조건을 확인하세요. 첫 번째 실행은 "저장소가 Qodo에 연결된 시점에 자동으로 실행되는 것이 아니라, 연결 후 첫 번째 pull request가 열릴 때 트리거"되며, 규칙은 "첫 번째 실행 후 몇 시간 이내에" 나타납니다.

규칙의 개수보다 두 가지 경계가 더 중요합니다.

첫 번째는 윈도우(window)입니다. Qodo는 "Rule Miner는 저장소가 연결되기 전의 활동을 포함하여 가장 최근에 머지된 최대 약 1,000개의 pull request로 구성된 인덱싱된 윈도우를 활용한다"고 명시한 뒤, 중요한 부분을 솔직하게 덧붙입니다. "이것은 저장소의 전체 이력이 아닙니다." 활발한 저장소의 경우, 머지된 1,000개의 pull request는 몇 달 분량에 불과할 수 있습니다. 여러분의 팀이 수립하고 성공적으로 위반을 멈춘 표준(이것이 바로 성공의 모습입니다)은 최근에 아무도 이를 지적할 필요가 없었기 때문에 이 윈도우의 완전히 바깥에 위치할 수 있습니다. Qodo는 결과물이 적은 것이 오작동이 아니라고 직접 설명합니다. "저장소가 완벽하게 건강하더라도 규칙이 몇 개만 생성되거나 전혀 생성되지 않을 수 있습니다."

두 번째는 활성화(activation)이며, 이는 날짜에 따라 다릅니다. Qodo 문서에 따르면 Rule Miner는 기본적으로 활성화되어 있으며, "2026년 9월 1일 이후 Qodo를 사용하기 시작한 조직의 경우 생성된 규칙이 자동으로 활성화"되는 반면, "그 전에 온보딩된 조직의 경우 생성된 규칙이 적용되기 전에 검토를 위해 Rules > Suggestions에 제안으로 먼저 표시"됩니다. 두 설정 모두 변경 가능합니다. "Mine rules from code review history" 및 "Auto-approve rule miner suggestions"는 포털 구성의 Context 탭 아래 Review standards 섹션에 있습니다. 하지만 어떤 기본값으로 설정되어 있는지에 따라 마이닝된 규칙이 이미 리뷰에 영향을 미치고 있는지, 아니면 대기열에서 기다리고 있는지가 결정됩니다. 지레짐작하기 전에 확인해 보세요.

2단계: Agentic Toolbox 설치 및 Get Rules 연결 확인하기

Agentic Toolbox는 이러한 기능을 이미 사용 중인 Agent 내부에 배치하기 위한 Qodo의 메커니즘입니다. 자체 설명에 따르면, 이는 "Qodo의 코드 이해, 코딩 표준 및 리뷰 기능을 기존 코딩 Agent에 가져다주며", "코딩 Agent를 대체하거나 Qodo와 직접 상호작용할 필요가 없게" 만듭니다.

설치는 Qodo의 설치 엔드포인트에서 제공하는 한 줄짜리 스크립트로 진행되며(문서에서 macOS, Linux, Windows PowerShell 형식을 제공함), Node.js 20 이상이 필요합니다. 파이프를 통한 설치가 늘 그렇듯 실행하기 전에 스크립트를 읽어보세요. 다음 단계에 대해 알아두어야 할 두 가지가 있습니다. "설치 프로그램이 Toolbox를 설치하고 지원되는 Agent 환경에 맞게 사용 가능한 Qodo 도구를 구성"하며, "Qodo 계정 없이도 Agentic Toolbox를 설치할 수 있지만, Agent가 실제로 도구를 실행하려면 Qodo에 가입하거나 로그인해야 합니다." Toolbox와 Get Rules는 모두 베타(Beta) 버전으로 문서화되어 있습니다.

Get Rules는 Claude Code 플러그인, Codex 플러그인, Kiro 플러그인, CLI, Agent 스킬, 그리고 "모든 MCP 호환 클라이언트 또는 Agent"를 위한 MCP Server 등 여러 인터페이스를 통해 제공됩니다. 팀원들이 모두 동일한 클라이언트를 사용하는 것이 아니라면, 설정을 특정 에디터의 플러그인 시스템에 종속시키지 않는 MCP 경로를 선호하는 것이 좋습니다.

Qodo에 연결된 저장소에서 Agent에게 곧 시작할 작업에 어떤 규칙이 적용되는지 물어봄으로써 작동 여부를 확인하세요. 반환되는 결과에는 여러 범위(scope)가 결합되어 있어야 합니다. Qodo 문서에 따르면 Get Rules는 "글로벌 규칙, 저장소별 규칙 및 컨텍스트 가이드를 결합"하며, FAQ에서는 "저장소별 규칙 외에도 적용 가능한 글로벌 규칙을 포함한다"고 명시하고 있습니다. 저장소 규칙만 보인다면 조직 수준(organization-level)의 범위가 아직 연결되지 않았을 가능성이 큽니다.

수행하지 않는 작업도 알아둘 가치가 있습니다. "Get Rules가 코드를 수정하나요? 아닙니다. Get Rules는 Agent에게 적용 가능한 가이드를 제공할 뿐입니다." 즉, 읽기 전용 작업입니다.

3단계: 지침 파일에 언제 질문해야 하는지 알려주기

Agent가 한 번도 호출하지 않는 도구는 설치하지 않은 도구나 다름없습니다. 이 단계는 사람들이 가장 많이 건너뛰고는 기능이 작동하지 않는다고 결론 내리는 단계입니다.

Qodo 문서에서는 이에 대해 직접적으로 언급하고 있습니다. "코딩 Agent는 Agent 지침 파일에 지침이 포함되어 있을 때 Agentic Toolbox를 더 효과적으로 사용할 수 있습니다. AGENTS.md 또는 CLAUDE.md와 같은 Agent 지침 파일에 Qodo Agentic Toolbox 지침을 추가하여 Agent가 워크플로 전반에서 Toolbox를 효과적으로 사용할 수 있도록 하세요." Qodo는 이를 위한 기본 템플릿을 제공합니다.

중요한 선은 트리거입니다. 규칙은 첫 번째 실패 이후가 아니라 구현이 시작되기 전에 로드되어야 합니다. Qodo의 FAQ는 그 의도를 명확히 밝히고 있습니다. "구현이 시작되기 전에 규칙이 로드되므로, Agent는 리뷰 중에 문제를 발견하는 대신 코드를 생성하는 동안 이를 사용할 수 있습니다." 지침 파일 항목의 요점은 이것을 여러분의 잔소리가 아니라 Agent의 습관으로 만드는 것입니다. 이를 단순히 '사용 가능한 기능'이 아니라 '코드를 작성하기 위한 전제 조건'으로 작성하세요.

한 가지 운영상의 세부 사항은 Toolbox가 스스로 업데이트된다는 점입니다. "대화형 사용 중에 Agentic Toolbox는 주기적으로 업데이트를 확인하고 백그라운드에서 최신 버전을 설치"하며, 기본적으로 "이미 Qodo 스킬을 설치한 코딩 Agent 환경에 새로 출시된 권장 스킬을 추가"합니다. "사용자가 소유하거나 맞춤 설정한 스킬은 덮어쓰지 않으므로" 이는 올바른 동작이지만, 사용자가 아무것도 하지 않아도 도구의 영역이 확장될 수 있습니다.

Get Rules는 코드 리뷰를 거친 표준에 대한 루프를 닫아줍니다. 하지만 이 도구가 도달하지 못하는 두 번째 카테고리가 있으며, 이는 팀에 가장 큰 비용을 초래하는 영역입니다.

Qodo 자체의 프레임워크가 그 경계를 명확히 해줍니다. Rule Miner는 머지된 약 1,000개의 pull request라는 제한된 윈도우 내에서 "개발자가 수락하고 코드 변경으로 이어진 댓글"에 대해서만 작동합니다. 리뷰 댓글의 형태를 취하지 않은 팀의 모든 결정사항은 이 범위 밖에 있습니다. 회의에서 결정된 아키텍처 방향, 장애 사후 분석(postmortem)의 결론, 고객이 부과한 벤더 제약 조건, diff 기록에는 남지 않는 이유로 두 번 시도했다가 포기한 접근 방식 등이 그렇습니다. 이 중 어느 것도 리뷰 규칙으로 강제할 수 없으며, 그 어떤 것도 윈도우 내에 존재하지 않습니다.

MemoryLake는 그 나머지 절반을 보관합니다. 저장소나 리뷰 플랫폼 외부에 존재하는 저장소로서, 작업 중인 어떤 Agent든 MCP나 API를 통해 읽을 수 있으며, 소리 없이 낡아버리는 대신 지속적으로 수정되도록 구축되었습니다.

1단계: API 키 생성하기

키를 생성하고 약 30초 만에 첫 번째 요청을 완료하세요. 하나의 키로 팀이 사용하는 모든 Agent 환경을 커버할 수 있으므로, 지식이 특정 플랫폼의 전유물이 되지 않도록 방지합니다.

2단계: 첫 번째 기억 업로드하기

리뷰에서는 결코 볼 수 없었던 결정사항들(사후 분석 문서, 아키텍처 결정 기록(ADR), 모두가 언급하지만 아무도 다시 읽지 않는 디자인 리뷰 등)이 담긴 문서, 이미지, 파일을 업로드하세요.

3단계: AI 및 Agent 연결하기

Claude, Codex, OpenClaw 및 기타 Agent에게 MCP 또는 API를 통해 액세스 권한을 부여하세요. Get Rules와 결합하면, Agent는 리뷰가 강제하는 표준과 리뷰에서 한 번도 논의되지 않은 결정사항이라는 두 가지 절반을 모두 가지고 작업을 시작할 수 있습니다.

리뷰 지적 사항이 감소하는 이유는 아주 단순합니다. Agent가 코드를 작성하기 전에 미리 지침을 전달받았기 때문에 리뷰어들이 잡아내던 실수를 더 이상 저지르지 않기 때문입니다. Qodo는 이를 목표로 정의합니다. 즉, "코드의 첫 줄부터 가드레일 역할을 하는" 규칙입니다.

2주 간격의 마이닝 주기는 단순히 쌓이는 것을 넘어 복리 효과를 내기 시작합니다. 새로운 규칙은 누군가 지침 파일을 업데이트할 때까지 기다리지 않고 작성자에게 자동으로 전달되므로, "우리가 배운 것"과 "Agent가 아는 것" 사이의 격차는 자원봉사자 한 명의 노력이 아니라 단 한 번의 마이닝 주기에 불과하게 됩니다.

온보딩의 형태가 바뀝니다. 신입 엔지니어의 Agent는 첫날부터 다른 모든 사람들과 동일하게 마이닝된 표준을 제공받을 뿐만 아니라, 마이닝 윈도우 이전의 결정사항들까지 함께 제공받습니다. 이것이 바로 "암묵적 지식(tribal knowledge)"이라는 말이 존재하는 이유에 가깝고, keeping AI context when someone leaves에서 다루는 문제와 동일한 문제입니다.

그리고 마이닝 윈도우는 더 이상 숨겨진 부채가 되지 않습니다. 오래된 결정사항들이 pull request 인덱스가 아닌 다른 곳에 보관되면, 그것들이 최근 1,000개의 머지 내역에서 사라졌는지는 더 이상 중요하지 않기 때문입니다.

어떤 활성화 기본값으로 설정되어 있는지 확인하세요. 자동 승인(Auto-approve)이 켜져 있으면 마이닝된 규칙이 이미 적용되고 있는 것이고, 꺼져 있으면 Suggestions 대기열에 있는 것입니다. 이 동작은 조직이 온보딩된 시점에 따라 다릅니다.

일괄 승인하기 전에 Suggestions 대기열을 읽어보세요. 마이닝된 규칙은 리뷰 동작을 반영하므로, 표준으로 삼고 싶지 않은 리뷰어 개인의 선호도가 포함되어 있을 수 있습니다.

단일 클라이언트 플러그인보다 MCP를 선호하세요. Get Rules는 Claude Code, Codex, Kiro 플러그인 및 MCP 서버로 제공됩니다. MCP는 에디터가 변경되어도 그대로 유지됩니다.

도구 호출을 전제 조건으로 만드세요. Agent가 사용할 수도 있는 '기능'이 아니라, 코드를 작성하기 전에 반드시 수행해야 하는 '작업'으로 AGENTS.md에 명시하세요.

마이닝된 규칙을 지침 파일에 수동으로 복사하지 마세요. Rule Miner는 계속해서 규칙을 생성하지만, 복사본은 그렇지 않습니다. 중복해서 복사하는 대신 검색(retrieve)하여 사용하세요.

Rule Miner는 대부분의 엔지니어링 표준이 "리뷰어의 기억 속에만 존재한다"는 정확한 관찰을 바탕으로 구축되었으며, 수락되고 반복된 리뷰 피드백을 합리적인 가중치와 자가 수정 신호를 갖춘 명시적인 규칙으로 변환하는 유용한 작업을 수행합니다. 아쉬운 점은 배치 시점입니다. 리뷰 표준은 리뷰 시점에 실행되는데, 이는 수정을 기억하지 못하는 Agent가 작성자일 때 루프의 잘못된 끝부분에 해당하는 시점입니다.

Get Rules는 이 문제를 해결하는 조각이며, 설정은 세 가지 실질적인 단계로 이루어집니다. 무엇이 어떤 윈도우에서 마이닝되었는지 확인하고, Toolbox를 설치하여 다음 분기에도 계속 사용할 인터페이스를 통해 Get Rules에 연결할 수 있는지 확인하고, 지침 파일에서 이 호출을 옵션이 아닌 전제 조건으로 만드는 것입니다.

그다음에는 윈도우의 한계를 솔직하게 인정해야 합니다. 머지된 1,000개의 pull request는 많은 리뷰 이력이지만, 팀이 알고 있는 지식 중 극히 일부에 불과합니다. 리뷰 댓글이 되지 못한 결정사항들(회의, 장애, 고객 제약 조건, 두 번의 실패한 시도 등)이야말로 사람들이 가장 자주 다시 설명해야 하는 것들입니다. 이러한 결정사항들은 자체적인 저장소가 필요하며, 일단 저장소가 마련되면 리뷰가 강제하는 표준과 리뷰에서 한 번도 다루지 않은 결정사항들이 코드의 첫 줄을 작성하기 전이라는 동일한 시점에 동시에 도달하게 됩니다.