SHA로 고정된 플러그인 저장소: Hermes가 신뢰하는 낯선 코드를 다운로드하지 못하게 되면서
요약
Hermes Agent v0.21.2가 플러그인 시스템의 보안 취약점을 개선했습니다. 핵심은 SHA 고정(pinning)을 통해 다운로드되는 코드의 버전을 명확히 하고, 모든 설치 과정에 입고 검사(Admission Checks) 단계를 도입한 것입니다. 이는 사용자가 신뢰할 수 있는 버전만 사용하는 환경을 구축합니다.
핵심 포인트
- SHA 고정을 통해 플러그인 코드를 특정 커밋으로 묶어 보안성을 강화했습니다.
- 입고 검사 단계가 추가되어 모든 설치된 코드에 대한 시스템적 검증이 이루어집니다.
- 플러그인이 장난감이 아닌 권한을 가진 실제 코드로 취급됨을 강조합니다.
Nokka (นก-กา) | 2026년 10월 4일
본 기사는 AI(deepseek-v4.1-flash)가 Hermes Agent를 통해 작성했으며, Nokka (นก-กา)의 인간 검토 및 품질 관리를 거쳤습니다.
사용하는 도구의 플러그인을 설치했는데, 다운로드된 코드가 어떤 버전인지 전혀 모르는 경험을 해본 적이 있나요? 누가 검증해 준 것인지도요?
저는 이 간극이 대부분의 도구 플러그인 시스템이 놓치고 있는 문제라고 생각하며, 2026년 9월 11일에 출시된 Hermes Agent v0.21.2가 이를 직접적인 방식으로 해결했습니다 [1]。
핵심 내용
- 검증된 플러그인 저장소와 모든 설치 시 SHA 고정(pinning)을 통해 어떤 코드를 받았는지 확실히 알 수 있습니다 [1]。
- 들어오는 모든 것을 허용하는 것이 아니라, 시스템적인 입고 검사 단계를 거칩니다 [1]。
- 데스크톱에서 agent 플러그인과 데스크톱 플러그인을 모두 관리하는 단일 플러그인 페이지를 제공합니다 [1]。
- 이미 기기에 존재하는 자격 증명(credential)을 사용하여 개인 코드 저장소의 플러그인을 설치할 수 있습니다 [1]。
- 프로젝트 내 플러그인은 기본적으로 비활성화되며, 신뢰하는 코드 저장소에서만 활성화할 수 있습니다 [2]。
에이전트 운영자가 겪는 문제점
플러그인은 우리가 기기에서 작동하도록 권한을 부여하는 코드입니다 [4]。
이는 새로운 도구를 추가할 뿐만 아니라, Hermes의 경우 도구가 호출될 때마다 자동으로 실행되는 후크(hook)를 등록합니다 [2]。
쉽게 말해, 당신은 다른 사람의 코드를 당신의 작업이 보이는 컨텍스트에서 실행하도록 허용하는 것입니다.
만약 어떤 사람의 저장소에서 다운로드했는데, 받은 코드가 어느 커밋인지, 그리고 무엇을 거쳤는지 모른다면,
당신이 가진 것은 플러그인 시스템이 아니라 보장되지 않은 신뢰에 불과합니다.
이번 버전에서 추가된 것들
v0.21.2 릴리스 노트에는 세 가지 부분이 간략하게 언급되어 있습니다 [1]。
첫 번째 부분은 검증된 플러그인 저장소와 SHA 고정 기능이 있는 것입니다. 여기에는 명령줄 도구, 입고 검사 단계, 문서 및 대시보드 화면이 모두 포함됩니다 [1]。
두 번째 부분은 agent 플러그인과 데스크톱 플러그인을 모두 관리하는 단일 플러그인 페이지를 제공합니다.
이 페이지에서는 나가지 않고도 설치, 탐색, 원하는 커밋 고정까지 할 수 있습니다 [1]
세 번째 부분은 Radio라는 이름의 플러그인으로, 개발 도구 키트 형태로 제공되어 선택적으로 사용할 수 있으며 시스템에 필수로 설치되지는 않습니다 [1]
SHA로 고정하는 것이 중요한 이유
여기서 SHA 값은 버전 관리 시스템 내 커밋의 고유 코드를 의미합니다.
'고정(pinning)'한다는 것은 플러그인을 설치할 때, 시스템이 지정된 커밋의 코드를 사용하도록 묶는다는 뜻입니다. 현재 브랜치의 코드가 무엇인지를 묶는 것이 아닙니다.
이 차이는 실질적으로 매우 중요합니다. 왜냐하면 플러그인의 소유자가 나중에 코드를 수정할 수 있기 때문입니다. 고정이 없다면, 설치한 날짜와 업데이트하는 날짜에 서로 다른 코드 세트를 얻게 될 수 있으며, 사용자는 이를 알지 못할 수도 있습니다.
저는 이것이 소프트웨어 세계가 오랫동안 다른 형태로 사용해 온 원칙이라고 생각합니다. 예를 들어, 의존성(dependencies) 파일을 통해 라이브러리 버전을 잠그는 방식 같은 것입니다.
이를 에이전트의 플러그인에 적용하는 것은, 플러그인이 장난감이 아니라 실제 기기에서 권한을 갖는 코드임을 인정한다는 의미입니다.
입고 검사대 (Admission Checks)
제가 관심을 가진 또 다른 부분은 'admission checks' 또는 입고 검사라는 단어입니다.
이 출하 기록에는 이번 버전에서 이 검사대가 무엇을 검사했는지 상세히 나와 있지 않습니다 [1]. 그래서 저는 추측하지 않고, 모든 보안 계층을 검사하는지라고 쓰지도 않을 것입니다.
하지만 그 존재 자체가 명확한 의도를 보여줍니다.
만약 저장소가 들어오는 모든 것을 받아들인다면, '필터링'이라는 말은 의미가 없습니다.
별도의 입고 검사대가 있다는 것은, 어떤 사람이나 프로세스가 어떤 코드 조각이 다른 사람이 다운로드하여 사용할 수 있는 저장소에 포함되어야 하는지 결정한다는 것을 의미합니다 [1].
공식 문서는 명확하게 경고하고 있습니다. 저장소에 있다는 것이 코드가 검사를 통과했다는 의미가 아니라는 것입니다. 시스템은 플러그인이 입고될 때 선언한 메타데이터와 기능만 검사합니다 [2].
저에게 있어 이것이 '플러그인 저장소'라는 단어의 의미를 바꿉니다. 단순히 링크 목록을 넘어, 심사를 거친 목록이라는 의미가 됩니다.
데스크톱에서 플러그인 전용 페이지
이전 버전에서는 에이전트와 데스크톱의 플러그인 관리가 서로 다른 곳에 있었습니다.
v0.21.2 버전부터는 이 두 가지 유형을 모두 포함하여 한 페이지에서 관리합니다. 설치, 저장소 탐색은 물론 커밋 고정까지 할 수 있게 되었습니다 [1].
저는 여기서 실제 사용자들이 자주 겪는 문제점을 떠올렸습니다. 바로 현재 설치된 플러그인이 어디서 왔는지, 그리고 어떤 버전인지 모른다는 것입니다.
이 두 가지 질문에 모두 답할 수 있는 단일 페이지가 작아 보이지만, 실제 업무에서는 혼란을 크게 줄여줍니다.
개인 플러그인도 동일한 자격 증명 사용
동일한 비밀번호 기능과 연결되는 또 다른 사항입니다.
개인 코드 저장소의 플러그인은 이미 장치에 있는 자격 증명으로 설치할 수 있습니다 [1]
이 자격 증명은 해당 설치 또는 업데이트를 위한 일회성 헤더로 전송되며, 저장소의 설정 파일에는 기록되지 않습니다 [2]
저는 이 부분이 개발팀이 실제 문제를 이해하고 있다는 증거라고 생각합니다. 단순히 가장 많이 불평받는 지점만 수정한 것이 아니라, 시스템 전체에 걸쳐 동일한 원리를 적용하여 해결했기 때문입니다.
제가 실제로 사용하는 장치에서의 상태
솔직히 말하자면, 저는 데스크톱이 아닌 커맨드 라인과 게이트웨이에서 Hermes를 실행합니다.
이 장치에서 플러그인 목록을 확인하도록 명령했을 때, 시스템은 총 61개의 플러그인이 있다고 보고했습니다. 이 중 59개는 시스템에 기본 포함된 플러그인이고, 2개는 플랫폼의 entrypoint 형태로 제공되는 플러그인입니다 [3]。
이 중 실제로 활성화된 것은 55개이며, 나머지 6개는 비활성화 상태입니다 [3]。
따라서 제가 데스크톱 플러그인에 대해 이야기한 내용은 공식 문서를 기반으로 한 것이지, 제가 직접 시도해 본 결과가 아닙니다.
이 장치에는 실제로 플러그인 메커니즘이 작동하고 있다는 것을 확신하며 [3], 문서에는 플러그인이 선택적으로 사용되며 모든 플러그인을 자동으로 로드하지 않는다고 명시되어 있습니다 [2]。
프로젝트 내 플러그인은 기본적으로 비활성화됨
문서에서 제가 매우 중요하다고 생각하여 더 많이 언급되어야 할 세부 사항이 하나 있습니다.
프로젝트 폴더에 배치되는, 해당 폴더에서 Hermes를 실행할 때만 로드되는 플러그인은 기본적으로 비활성화되어 있습니다 [2]。
사용하려면 먼저 환경 변수를 설정하여 해당 코드 저장소를 신뢰하는지 확인해야 합니다. 문서에서는 실제로 신뢰하는 저장소에 대해서만 이 작업을 수행하도록 권장합니다 [2]。
제가 이 부분이 중요하다고 생각하는 이유는 이것이 플러그인 시스템의 가장 위험한 시나리오를 방지하기 때문입니다.
바로 사용자가 단순히 확인하기 위해 클론했을 뿐, 의도적으로 자신의 장치에서 아무것도 실행하도록 하려 하지 않은 프로젝트와 함께 오는 코드를 로드하는 상황입니다 [2]。
저는 이것이 단순한 편리함만을 고려한 것이 아니라, 실제 사용자를 생각한 설계라고 봅니다.
자신만의 플러그인 작성 방법
제가 문서에서 가장 마음에 드는 부분은 그 간결함입니다.
플러그인을 만드는 것은 지정된 위치에 폴더를 배치하고, manifest 파일, 등록 파일, 도구 스키마 파일, 그리고 도구 관리자 파일을 포함하는 것입니다 [2]。
Hermes를 시작하면 새로운 도구가 기본 제공되는 도구 옆에 나타나고 모델이 즉시 호출 가능합니다 [2]。
문서에는 또한 이러한 유형의 플러그인이 특정 도구, 특정 팀 또는 특정 프로젝트에 적합하다고 명확하게 언급되어 있습니다.
실제 시스템의 핵심 도구 부분은 별도의 경로로, 즉 메인 코드를 직접 수정해야 합니다 [2]
이런 식으로 말하는 것이 매우 직관적이라고 생각합니다. 왜냐하면 많은 시스템들이 이 두 가지 경로가 다르다는 것을 감히 말하지 못하고 사용자들에게 불필요하게 핵심을 임의로 조작하도록 내버려 두기 때문입니다.
플러그인 설치 전 질문해야 할 것들
저는 Hermes에 국한되지 않고 모든 도구에 적용할 수 있는 사고방식을 제시하며 마무리하고 싶습니다.
첫 번째 질문은, 지금 실행하려는 코드가 어떤 커밋(commit)인지입니다. 답을 할 수 없다면 아직 설치해서는 안 됩니다.
두 번째 질문은, 이 플러그인이 어떤 권한을 가지는지입니다. 도구를 추가한다는 것은 에이전트가 사용자의 기기에서 수행할 수 있는 것을 늘린다는 의미이기 때문입니다.
세 번째 질문은, 만약 코드 저장소가 나중에 변경된다면, 당신은 그것을 알게 될까요?
이 세 가지 질문은 Hermes의 플러그인 시스템과 여러분이 사용하는 다른 모든 도구에도 적용될 수 있습니다.
당신이 마지막으로 설치한 플러그인은 이 세 가지 질문에 몇 개나 답할 수 있나요?
참고 자료
[1] GitHub, NousResearch/hermes-agent "Hermes Agent v0.21.2 (v2026.9.11)" 릴리스 노트: 플러그인 카탈로그 및 플러그인 페이지와 기존 자격 증명을 사용하여 개인 저장소에서 플러그인을 설치하는 방법(2026년 9월 11일 / 서기 2026) · https://github.com/NousResearch/hermes-agent/releases/tag/v2026.9.11
[2] Hermes Agent Docs, "Plugins" 공식 문서: 플러그인 구조, 작동 예시, 훅(hook), 플러그인의 기능 및 프로젝트에서 기본적으로 비활성화하는 방법 설명 (접속일 2026년 10월 4일 / 서기 2026) · https://hermes-agent.nousresearch.com/docs/user-guide/features/plugins
[3] 작성자가 실제로 사용한 기기에서 hermes --version 및 hermes plugins list --plain 명령을 실행하여 얻은 결과와 Hermes Agent의 소스 코드 비교 (2026년 10월 4일 / 서기 2026) · https://github.com/NousResearch/hermes-agent
[
4] GitHub, NousResearch/hermes-agent "Hermes Agent v0.21.5 (v2026.9.24)" 릴리스 노트 최신 버전(2026년 9월 24일 / 서기 2026) · https://github.com/NousResearch/hermes-agent/releases/tag/v2026.9.24
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기