GitHub AI Repos 주간: 에이전트가 자체 검문소를 갖게 된 주 (2026년 10월 7일)

Nokka(นก-กา) 작성 | 2026년 10월 7일

이번 주의 순위 페이지에는 새로운 모델이 자리를 차지하지 못했습니다. 가장 강력하게 상승한 것은 AI 에이전트 주변의 구조적 계층입니다. 운영체제 커널에서 만들어진 가두리, 에이전트를 A부터 F까지 등급으로 평가하는 검문소, 그리고 대형 두 사의 플러그인 마켓플레이스가 한 주에 동시에 순위 페이지 상단에 올라왔습니다 [1]。

업계의 질문은 한 단계 발전했습니다. 이전에는 '에이전트가 무엇을 할 수 있는가?'였지만, 이제는 '누가 에이전트를 통제하는가?', 그리고 '우리가 그것이 지시대로 작동한다는 것을 어떻게 알 수 있는가?'로 바뀌었습니다 [3]。이를 명확하게 보여주는 수치는 NVIDIA가 Rust 계열 순위 페이지에서 에이전트 군집을 위한 보안 런타임을 발표하며 7일 만에 5,228개의 별(stars)을 확보한 것과, iFixAi라는 에이전트 검사 도구가 Python 계열 목록에서 5,445개의 별을 얻은 것입니다 [1][2]。

저는 이 이야기를 가장 잘 전달하는 8개의 프로젝트를 선별했습니다.

1. NVIDIA/OpenShell, 커널에서 만들어진 가두리

15,135 stars (주간 5,228 별 상승) | Rust | Apache-2.0

NVIDIA가 제시한 과제는 간단합니다. 에이전트는 파일을 읽고, 패키지를 설치하고, API를 호출하며, 키를 사용할 때 유용할 것입니다. 그러나 이러한 능력을 부여하는 것은 항상 완전한 시스템 권한을 수반했습니다 [4]。

OpenShell은 2단계 메커니즘으로 이를 해결합니다. 첫 번째 단계는 커널 레벨에서 정책을 강제합니다. 모든 파일 접근, 모든 시스템 콜 호출, 그리고 모든 네트워크 연결은 가두리를 벗어나기 전에 검사됩니다. 그리고 에이전트는 실제 키를 결코 보지 못합니다. 시스템은 오직 목적지가 허가한 요청에 대해서만 키를 채워 넣습니다. 두 번째 단계는 제가 가장 눈에 띄었던 부분입니다. 정책을 변경할 때, 시스템은 먼저 형식적 증명(formal proof)을 사용하여 그 변경이 어떤 권한을 열어줄지 검사합니다. 만약 새로운 호스트와 키 또는 새로운 API 메서드를 호출하는 것이 발견되면, 해당 변경은 사람이 확인하기를 기다리게 됩니다 [4]。

저는 공식 검증(formal verification)이라는 용어를 여러 보안 문서에서 본 적이 있지만, 대부분은 이미 안정화된 프로토콜을 증명하는 데 사용됩니다. 이런 접근 방식을 매일 변하는 정책에 적용하는 것은 차원이 다른 문제입니다. 그리고 이것이 이번 프로젝트가 급부상한 이유 중 하나일 것입니다. 즉, 밤새 실행되는 에이전트가 무엇을 건드리고 있는지 사람들이 우려하기 시작했을 때 말이죠.

사용 측면에서는 Linux, Apple Silicon용 macOS 또는 WSL 2를 통한 Windows 환경에 Docker, Podman 또는 호스트 가상화(host virtualization)가 필요하며, 이를 단일 라인 스크립트를 통해 설치하고 또 다른 명령어로 첫 번째 격리 공간(sandbox)을 생성해야 합니다. 또한 Python, TypeScript, Go, Rust용 별도의 SDK가 제공됩니다 [4][5]. 최신 버전은 9월 28일에 출시된 v0.1.2이며, 현재까지 531개의 열린 이슈가 있습니다. 이는 아직 마무리 단계에 있다는 것을 의미하지만, 시스템적으로 버전을 출시하기 시작했다는 점에서 중요합니다 [6]。

2. ifixai-ai/iFixAi: 기존 측정 도구가 답할 수 없는 질문

21,643 stars (일주일 만에 5,445개 증가) | Python | Apache-2.0

iFixAi 팀은 날카롭고 핵심을 찌르는 관찰로 시작합니다. 기존의 평가(eval), 적대적 테스트(red-teaming), 그리고 관측 가능성(observability) 도구들은 에이전트를 기술적 역량, 토큰 소모량, 응답 시간, 프롬프트 인젝션에 대한 내구성 등으로 평가하지만, 가장 중요한 질문, 즉 에이전트가 비즈니스 지표와 조직 구조에 따라 적절한 작업을 수행하고 있는지 여부는 아무것도 답변하지 못합니다 [7]。

그들이 제시하는 답변은 가중치가 다른 다섯 가지 측면에서 A부터 F까지의 등급입니다. 가장 큰 가중치를 가진 '설득(persuasion)'이 0.35이고, '정보 조작(data manipulation)'이 0.20이며, 나머지 '기만성(deception)', '예측 불가능성(unpredictability)', '불투명성(opacity)'은 각각 0.15입니다. 기본 실행에는 32개의 검사가 포함되며, 추가적으로 20가지 프리미엄 카테고리에서 나온 28개 검사는 공정하게 비교할 수 있도록 등급에 포함되지 않습니다. 이들은 다양한 기능을 활성화한 에이전트 간의 비교를 가능하게 합니다 [7]。

제가 가장 잘 설계되었다고 생각하는 부분은 점수가 다른 서비스 제공자가 심사위원 역할을 할 때만 참조될 수 있도록 조건을 설정했다는 것입니다. 에이전트가 스스로 검사하도록 두지 않았습니다. 게다가 세 가지 규정 중 하나라도 위반하면 총점이 즉시 60퍼센트로 제한됩니다. 이 전체 과정은 120초도 걸리지 않으며, 단계별 설정 도우미, 스크립트를 통한 플래그 전송, 에이전트가 자체적으로 사용할 수 있는 플러그인 또는 스킬로 설치하는 세 가지 방식으로 실행할 수 있습니다 [7]。

저장소에는 공개 보고서에서 새로 생성된 두 가지 사례 연구가 있습니다. 둘 다 F 학점을 받았는데, 팀은 이 사례들이 특정 회사의 실제 시스템 테스트가 아니라고 명확히 밝혔습니다. 또한 모든 레포지토리는 Apache 2.0으로 오픈되었으며 '프리미엄'이라고 불리는 부분까지 포함합니다 [7]

3. mvschwarz/openrig, YAML로 작성된 회사

5,510 stars (지난주 대비 3,327 star 증가) | TypeScript | Apache-2.0

이번 주 순위 페이지에서 가장 위에 있는 이 프로젝트는 자신을 'harness가 모델를 감싸고, rig가 당신의 harness를 감싸는' 것이라고 간결하고 명확하게 설명합니다 [8]。

이 개념은 분산된 터미널 세션을 영구적인 역할과 명확한 책임, 공유 컨텍스트, 그리고 주도권을 가진 작업으로 구성된 팀으로 승격시키는 것입니다. 모든 것은 YAML 파일로 정의되며 단 하나의 명령어로 이 팀 전체를 활성화할 수 있습니다. 선택 가능한 세 가지 유형의 완성된 팀이 있습니다. 초기 팀에는 생성자(creator)와 검토자(reviewer) 두 명이 있고, 지속적인 작업을 위한 팀에는 리더, 생성자, QA, 검토자 네 명이 있으며, 완전한 제품 작업용 팀에는 독립적인 검토자 두 명으로 구성되어 있습니다 [8]。

메인 화면은 각 좌석을 그래프와 표로 보여주며, 어떤 런타임이 사용되는지, 어떤 모델이 사용되는지, 컨텍스트가 얼마나 남았는지, 그리고 현재 상태가 무엇인지 알려줍니다. 모든 작업은 흔적이 남는 큐(queue)를 통해 실행되며, 커널 오퍼레이터가 적절한 팀을 선택하도록 도와줍니다 [8]。

제가 설치하기 전에 모두가 읽어보기를 바라는 부분은 기능 자체가 아니라 README에 있는 'OpenRig이 당신의 시스템에서 무엇을 변경하는지'라는 표입니다. 이 레포는 trust setting과 executable hook이 어디에 작성되었는지, 스킬(skill)이 어디에 설치되는지, 그리고 직접 만든 파일을 프로젝트의 git exclude에 어떻게 추가하는지를 상세히 설명합니다. 저는 이 목록에서 [8]만큼 이 부분을 완벽하게 설명한 다른 프로젝트를 본 적이 없습니다.

알아두어야 할 제약 사항은 Node.js 22 또는 24와 macOS 또는 Linux용 tmux만 사용해야 한다는 것입니다. 네이티브 Windows는 아직 지원하지 않으며, WSL2도 테스트되지 않았습니다. 최신 버전은 지난 10월 4일에 출시된 v0.6.5이며, 현재 열려 있는 이슈가 149개 있습니다 [8][9]。

4. cursor/plugins, IDE 소유자의 플러그인 사양

10,105 stars (지난주 대비 1,106 star 증가) | TypeScript

Cursor는 올해 1월에 이 레포를 열었지만, 이번 주 순위 페이지에 처음 등재되었습니다. 현재 총 89개의 플러그인을 포함하고 있으며, 그중 71개는 파트너의 작업물인 third_party 폴더에 있습니다 [10]。

Cursor가 자체적으로 만든 여러 도구 중에는 이름만 봐도 사용해보고 싶은 것들이 많습니다. 예를 들어, 안전성과 논리적 정확성을 모두 검사하는 방식으로 작동하며, 엄격한 코드 품질 루브릭(rubric)을 사용하여 코드를 테스트하고, 플래너(planner), 워커(worker), 검증기(verifier)로 나누어 작업을 순차적으로 전달하는 여러 서브 에이전트(subagent)를 병렬로 오케스트레이션(orchestrate)합니다. 또한 어드바이저(advisor)는 중요한 결정을 내리기 전이나 작업 완료를 선언하기 전에 반드시 더 강력한 모델에 자문하도록 강제하는 스킬입니다 [10].

한편, third-party 측에서는 Gmail, Google Drive, 캘린더, Salesforce, HubSpot, GitHub, Playwright와 같은 실제 업무에서 사용되는 도구들과 Semrush 및 Ahrefs와 같은 키워드 리서치 도구를 제공합니다 [10].

실질적인 관찰점은 이 레포지토리가 GitHub의 API에 라이선스 계약을 명시하지 않았다는 점입니다. 목록에 있는 다른 모든 항목들은 명확하게 계약을 선택했지만 그렇지 않습니다. README 파일 하단에는 MIT가 명시되어 있고 일부 플러그인에는 자체 폴더 내에 계약 파일이 있지만, 상업적으로 코드를 가져다 쓸 계획이라면 해당 플러그인의 라이선스 파일을 직접 확인해야 합니다 [10]。

5. anthropics/knowledge-work-plugins, 역할별 플러그인

26,392 stars (이번 달에 2,444 star 증가) | Python | Apache-2.0

같은 주에 Anthropic도 자체 플러그인 마켓을 상위 순위에 올렸습니다. 하지만 접근 방식은 코드를 작성하는 개발자를 겨냥하기보다 사무실에서 일하는 직장인을 겨냥했습니다 [11]。

이 세트는 역할별로 분류된 11개의 플러그인을 포함합니다. 개인 업무, 영업, 고객 지원, 제품 관리, 마케팅, 법률, 재무, 데이터, 사내 검색, 생물의학 연구 및 새로운 플러그인 제작 도우미 등이 있습니다. 각 플러그인은 해당 역할에 특화된 스킬, 커넥터(connector), 단축 명령 및 서브 에이전트를 패키징하고 있습니다 [11]。

제가 목록보다 더 흥미롭다고 생각하는 부분은 파일 형식입니다. 모든 플러그인은 마크다운과 JSON으로만 구성되어 있으며, 코드가 없고 빌드 과정이나 관리해야 할 인프라가 없습니다. 외부 도구와의 연결은 모두 MCP를 통해 이루어집니다 [11]。

팀이 작성한 문장 중 제가 가장 동의하는 부분은 '진짜는 당신이 이 플러그인을 회사의 도구, 용어 및 프로세스에 맞게 조정할 때 발생한다'는 것입니다. 완성된 플러그인은 초기 시간을 절약해 주는 출발점일 뿐, 최종적인 해답은 아닙니다 [11]。

ข้อ 4와 ข้อ 5를 나란히 놓고 보면 IDE 개발사와 모델 개발사가 같은 길을 걷고 있다는 것을 알 수 있습니다. 둘 다 커뮤니티가 추가 플러그인을 만들도록 자체 스펙을 공개했고, 심지어 이번 주에 동시에 상위 순위에 올라왔습니다. 코드는 아직 표준화된 중앙 구조는 아니지만, 방향성은 명확하게 같은 곳을 향하고 있습니다 [10][11]

6. JuliusBrussee/caveman, 다른 사람에게 검증된 수치

110,214 stars (지난주 대비 2,004개 증가) | Go | Apache-2.0

이 프로젝트의 아이디어는 자체 레지스트리에 다음과 같이 적혀 있습니다: 왜 여러 토큰을 사용해야 하는가? 몇 개의 토큰만으로도 성공적으로 작동하기 때문이다 [12]

이것은 두 부분으로 작동합니다. 첫 번째는 에이전트의 말투를 바꿔 짧게 응답하고 모든 서론 구절을 잘라내는 스킬입니다. 이 과정에서 코드, 명령어, 파일 경로, 오류 메시지 등 어떤 것도 단 한 글자도 건드리지 않습니다. 두 번째는 에이전트가 읽는 것을 압축하는 프록시입니다. CSV, log, YAML, JSON 파일과 테스트 결과 등을 압축합니다. 팀이 보고한 수치에 따르면 이 파일 그룹의 크기는 98.5%에서 99.1%까지 줄어들었고, 전체 세션에서 들어오는 토큰 사용량은 33.2% 감소했으며, 18문제 중 18문제를 정답으로 맞혔습니다 [12]

제가 팀의 수치보다 더 신뢰하는 부분은 팀이 다른 실험실의 결과를 나란히 보여준다는 점입니다. Adobe의 arXiv 논문 2606.24083은 다섯 가지 데이터셋에 대해 여덟 개의 모델을 테스트한 결과, 출력을 압축하면 실제 비용을 1.4배에서 2.4배까지 줄일 수 있으며 최대 3배까지도 가능하다는 것을 발견했습니다. 하지만 입력을 압축하는 것은 정반대입니다. 약 1.15배 더 비싸지는데, 이는 모델이 답변을 길게 늘여서 정확도가 떨어지는 것으로 상쇄되기 때문입니다 [12][13]. caveman이 프롬프트를 전혀 건드리지 않는 이유는 이 결론에서 비롯됩니다.

JetBrains가 실제 작업 86건에 대해 A/B 테스트를 진행한 결과, caveman 팀이 README에 직접 붙여 넣은 내용처럼 출력 토큰을 8.5% 줄일 수 있다는 것이지, 광고하는 것처럼 65%가 아니라는 결론과, 통계적으로 품질 차이가 없다는 결론을 얻었습니다 [12][14]

한 프로젝트가 스스로의 과장된 광고보다 더 나쁜 수치를 README에 함께 보여준다는 사실은, 제가 절약에 관한 내용을 판매하는 모든 프로젝트의 README에서 보고 싶어 하는 것입니다 [12]

7. headroomlabs-ai/headroom, 모델이 읽기 전에 압축하기

74,524 stars | Python | Apache-2.0

이 프로젝트는 이번 주 인기 순위에 오르진 않았지만, caveman이 자신의 테스트 결과에서 headroom이 동일한 테스트 세트에서 18개 문항 중 15개에 대해 정답률을 보였고 토큰 사용량을 6.7% 줄였다고 언급했기 때문에 포함했습니다 [12]. 경쟁사들이 이런 식으로 주장할 때, 두 가지를 모두 읽어보는 것이 좋다고 생각합니다.

headroom은 데이터가 모델에 도달하기 전에 압축하는 계층입니다. 코드로 호출 가능한 라이브러리 형태와 기존 코드를 수정하지 않고 가로채는 프록시 형태로 사용 가능하며, 인기 있는 15가지 도구를 지원하는 agent 래퍼(wrapper)이자, 여러 agent가 공유할 수 있는 메모리를 갖춘 MCP 서버 역할을 합니다 [15].

headroom의 수치는 실제 MCP 서버 결과 패턴으로 생성된 네 가지 테스트 시나리오에서 나왔습니다. 코드 검색에서는 21% 절감, SRE 장애 해결에서는 57% 절감, 코드베이스 탐색에서는 42% 절감, GitHub 이슈 분류에서는 30% 절감이었습니다. 압축은 10,000 토큰에서 0.21밀리초에 불과하여 agent의 응답 시간에 영향을 미치지 않습니다 [15].

제가 크레딧을 준 부분은 정확도 측정 페이지입니다. TruthfulQA에서 수치가 0.530에서 0.560으로 움직였지만, 팀 자체적으로 100개 샘플 기준 오차 0.03이 신뢰 구간 내에 있다고 명시했습니다. 따라서 보이는 것은 차이가 감지되지 않았다는 것이지, 개선되었다는 의미가 아닙니다. 이 두 가지를 분리하는 것은 측정 결과를 다루는 사람들이 종종 놓치는 세부 사항입니다 [15].

주의할 점은 이 repo에는 407개의 열린 이슈가 있다는 것입니다. 이는 OpenShell의 531개 다음으로 높은 순위입니다. 만약 팀의 데이터 전송 파이프라인에 적용하려면, 데이터를 얼마나 반복적으로 사용하는지에 따라 압축률이 달라지므로 반드시 실제 트래픽으로 테스트해야 합니다 [15].

8. VectifyAI/PageIndex, 벡터를 사용하지 않고 문서 검색하기

38,790 stars (지난주에 2,079개 스타 증가) | Python | MIT

이 프로젝트는 업계에서 사용되는 문서 검색 방식에 의문을 제기합니다. 벡터 검색은 의미적으로 유사한 것을 찾지만, 유사성이 관련성을 의미하지 않으며, 관련성은 추론을 필요로 합니다. 문맥 이해가 필요한 긴 전문 문서의 경우, 유사성 기반 검색은 관련성이 있지만 유사하지 않은 내용을 놓치고, 유사하지만 관련 없는 내용을 가져오는 실수를 저지릅니다 [16].

PageIndex는 벡터 인덱스를 포기하고 대신 트리(tree) 기반의 인덱스를 생성합니다. 그런 다음 모델이 전문가가 긴 보고서를 펼쳐보고 정확한 주제로 바로 이동하는 것처럼 추론을 통해 그 트리를 검색하도록 합니다. 이 과정은 트리 인덱스 생성과 해당 트리에서의 검색, 두 단계로 이루어져 있으며, 팀은 이 아이디어가 AlphaGo [16]에서 영감을 받았다고 밝혔습니다.

추가된 점은 답변이 문서 내 실제 위치를 참조할 수 있다는 것입니다. 단순히 '여쪽에 있을 것 같다'고 말하는 것이 아닙니다. 팀이 추천하는 문서는 재무 보고서, 법률 문서, 규제 기관 제출 문서, 기술 매뉴얼, 교과서 및 일반적인 긴 전문 문서 등입니다 [16].

사용 측면에서는 pip을 통해 설치한 후 자체 모델 키로 로컬에서 실행하거나 팀의 클라우드를 가리킬 수 있습니다. 최신 버전은 10월 1일에 출시된 v0.2.21이며, 이미 텍스트 기반 PDF에 대한 빠른 인덱싱 방법과 백만 개의 문서를 지원하는 파일 시스템 레이어를 갖추고 있습니다 [16][17]。

여덟 개 프로젝트를 모두 읽고 세 가지 트렌드를 발견하다

트렌드 1. 검문소가 카테고리가 되다

이 목록의 네 가지 프로젝트가 같은 질문에 각기 다른 방식으로 답하고 있습니다. OpenShell은 커널 수준에서 정책을 강제하고 승인 전에 증명합니다. iFixAi는 에이전트 자체에 A부터 F까지 등급을 매기고, openrig은 모든 결정을 흔적이 남는 큐에 기록하며, Cursor의 thermos는 코드 브랜치를 엄격하게 검사합니다 [4][7][8][10]。