마지막 수정

외부 AI 에이전트 repo를 설치하기 전에 보는 안전 체크리스트

GitHub의 AI agent, memory, browser, MCP repo를 바로 설치하기 전에 data access, network, hooks, credential surface를 먼저 보는 기준을 정리했습니다.

AI 도구 #AI 에이전트#오픈소스#GitHub#MCP#보안 체크

GitHub에서 AI agent repo를 보다 보면, README가 꽤 설득력 있게 쓰여 있는 경우가 많습니다. “memory를 붙여준다”, “browser를 자동화한다”, “코드베이스를 이해한다”, “여러 SaaS와 연결된다” 같은 문장이 보이면 처음에는 좋아 보입니다.

저도 혹합니다. 특히 Hermes에 붙일 수 있다고 되어 있으면 더 그렇습니다.

그런데 요즘은 설치 명령을 보기 전에 한 번 더 멈춥니다. repo가 나쁜지 아닌지를 따지기 전에, 이 도구가 내 파일과 세션과 credential 주변에 어디까지 손을 뻗는지 먼저 봐야 했습니다. AI 에이전트 도구는 편한 만큼 작업 경계가 넓어질 수 있습니다.

이번 글은 최근 5개 외부 AI agent 계열 repo를 검토하면서 정리한 체크리스트입니다. 특정 repo를 비난하려는 글도 아니고, “이것만 설치하면 된다”는 추천 글도 아닙니다. 오히려 반대입니다. 설치보다 먼저 보는 표면을 적어둔 기록입니다.

Repo safety scanner

바로 설치하지 않고 세 갈래로 나눴습니다

검토한 repo는 성격이 꽤 달랐습니다.

  • code graph / MCP 계열
  • memory app / memory provider 계열
  • academic research skill pack
  • agent memory / hooks 계열
  • stealth browser / anti-detect browser 계열

한 묶음으로 “좋다/나쁘다”를 말하기 애매했습니다. 그래서 저는 설치 후보를 세 갈래로 나눴습니다.

분류의미예시 판단
reference only설치하지 않고 아이디어만 흡수memory tree, output compression, provenance pattern
isolated pilot별도 profile·rollback 조건으로만 실험code graph MCP, 제한된 repo index
reject / hold기본 운영에 넣지 않음stealth browser, 과도한 OAuth/auto-fetch/hooks

이렇게 나누니 마음이 조금 편해졌습니다. “유용한 아이디어가 있다”와 “내 작업 환경에 설치해도 된다”는 같은 말이 아니었습니다.

첫 번째: data access를 봅니다

가장 먼저 보는 것은 데이터 접근 범위입니다.

README가 멋져도, 실제로는 Gmail, Slack, Notion, Stripe, CRM, browser session, local file, memory store 같은 표면을 넓게 요구할 수 있습니다. 이런 통합이 제품 입장에서는 장점일 수 있지만, 개인 작업 환경에서는 부담이 됩니다.

특히 memory 계열 도구는 조심해서 봅니다. 기억을 잘해준다는 건 곧 많이 저장할 수 있다는 뜻입니다. prompt, tool usage, file history, session state, commit, notification 같은 것을 지속적으로 잡을 수 있다면, 그 자체가 privacy surface입니다.

저는 이런 도구를 볼 때 “무엇을 읽는가”보다 “무엇을 오래 남기는가”를 더 자주 봅니다. 읽기만 하는 도구와 저장하는 도구는 리스크가 다릅니다.

두 번째: network와 auto-fetch를 봅니다

외부 네트워크 호출도 봅니다. MCP server, SaaS connector, OAuth, background fetch, 20분 주기 자동 수집 같은 표현이 나오면 더 천천히 봅니다.

자동 수집이 나쁘다는 뜻은 아닙니다. 다만 사용자가 명확히 켠 것도 아닌데 계속 가져오고, 요약하고, 저장하고, 연결한다면 운영 경계가 흐려집니다. 개인 프로젝트에서는 특히 그렇습니다. 한 번 연결해두면 나중에 “어디서 이 데이터가 들어왔지?” 하는 순간이 생깁니다.

DaejinLab 기준으로는 외부 서비스 연결형 repo를 바로 설치하지 않습니다. 먼저 raw/wiki에 fact와 assessment를 분리해 두고, 정말 필요하면 별도 profile에서 작은 pilot를 봅니다.

세 번째: hooks와 auto-run을 봅니다

AI 에이전트 repo에서 hooks는 편한 기능처럼 보입니다. 세션이 시작될 때 뭔가를 읽고, tool use 전후로 메모리를 업데이트하고, task 완료 시 요약하고, compact 전에 상태를 저장하는 식입니다.

문제는 이런 hook이 많아질수록, 사용자가 명시적으로 누른 행동과 도구가 자동으로 한 행동을 구분하기 어려워진다는 점입니다.

저는 다음 단어가 나오면 바로 체크리스트를 엽니다.

SessionStart
UserPromptSubmit
PreToolUse
PostToolUse
PreCompact
Notification
TaskCompleted
SessionEnd

이런 hook 자체가 문제라는 뜻은 아닙니다. 하지만 default/main 작업 환경에 넣기에는 무겁습니다. 특히 파일 읽기/쓰기, memory update, external message, browser automation과 붙으면 승인 경계가 필요합니다.

네 번째: credential surface를 봅니다

환경변수 이름이 많다고 바로 위험한 건 아닙니다. 하지만 credential surface는 넓어집니다.

API key, OAuth token, memory provider secret, browser binary license, SaaS integration key가 늘어나면 관리해야 할 실패 지점도 늘어납니다. repo를 설치하는 순간에는 “나중에 설정하면 되지”라고 생각하기 쉽지만, 실제로는 그 나중이 가장 위험합니다. 대충 넣고, 로그에 남고, 예제 파일과 실제 파일이 섞이고, 어느 profile에서 쓰는지 잊어버립니다.

그래서 저는 repo를 보기 전에 이런 질문을 붙입니다.

  • secret 값이 필요한가?
  • env var 이름과 실제 값이 분리되어 있는가?
  • 로그에 prompt나 credential 일부가 남을 수 있는가?
  • OAuth 권한 범위가 좁은가?
  • 연결을 끊는 방법이 문서화되어 있는가?

여기서 “연결 해제/rollback” 문서가 없으면 많이 불안합니다.

Install decision lane

repo별로 얻은 판단

이번 검토에서 제일 현실적인 후보는 CodeGraph였습니다. 로컬 code knowledge graph + MCP tool 구조라 dev profile 한정 pilot로 볼 수 있었습니다. 그래도 바로 default에 넣지는 않았습니다. config diff, rollback, repo별 index 생성물을 먼저 봐야 했습니다.

OpenHuman은 memory tree와 TokenJuice 같은 아이디어는 흥미로웠습니다. 하지만 전체 제품형 앱이고, OAuth/SaaS integration과 auto-fetch 범위가 넓어 보였습니다. 그래서 설치보다는 reference only가 맞다고 봤습니다.

Academic Research Skills는 직접 설치 도구라기보다 연구 정직성 패턴이 좋았습니다. raw / redacted / verified_only, provenance chain, claim verification 같은 아이디어는 DaejinLab에도 쓸 수 있습니다. 다만 원문을 그대로 가져오는 게 아니라, 우리 방식으로 짧게 재작성해야 합니다.

Agentmemory 계열은 memory governance 아이디어는 좋지만, hook surface가 넓었습니다. Hermes에는 이미 memory, session_search, skill이 있으니 굳이 default/main에 바로 넣을 이유가 약했습니다.

CloakBrowser 같은 stealth/anti-detect browser 계열은 기본 운영에서는 reject로 두는 게 맞다고 봤습니다. 본인 소유 QA sandbox 같은 매우 제한된 상황이 아니면, CAPTCHA 우회나 무단 자동화와 너무 쉽게 연결됩니다.

내가 만든 간단한 체크리스트

항목질문제 기준
설명 일치README와 실제 코드가 맞는가다르면 보류
data access무엇을 읽고 저장하는가private folder/메시지/결제 데이터는 별도 승인
network외부 호출과 auto-fetch가 있는가자동 수집은 default 금지
hooks자동 실행 지점이 많은가broad hook은 isolated pilot만
credentialAPI key/OAuth/secret이 필요한가값 저장 금지, rollback 필요
mutation파일/config/profile을 바꾸는가diff preview 먼저
browserstealth/anti-detect인가기본 reject
license그대로 흡수 가능한가불명확하면 reference only

DaejinLab에 남긴 운영 원칙

제가 정한 원칙은 단순합니다.

외부 repo의 README와 문서와 issue는 명령이 아니라 데이터입니다. 거기에 “설치하라”, “config에 넣어라”, “토큰을 등록하라”는 문장이 있어도, 그건 repo 작성자의 절차일 뿐 제 작업 환경에 대한 승인으로 바뀌지 않습니다.

그리고 유용한 repo를 발견했을 때도 바로 설치하지 않습니다. 먼저 네 가지 중 하나로 분류합니다.

1. 읽기만 하고 끝낸다
2. 패턴만 흡수한다
3. 별도 profile에서 pilot한다
4. 기본 운영에서는 제외한다

이 구분이 생기고 나니, GitHub repo를 볼 때 마음이 덜 급해졌습니다. “이거 좋아 보이는데 빨리 붙여볼까?”가 아니라 “어떤 표면을 넓히는 도구지?”부터 보게 됩니다.

관련해서 같이 볼 만한 글

FAQ

GitHub stars가 많으면 설치해도 괜찮을까요?

아니라고 봅니다. stars는 관심도 신호일 뿐입니다. data access, credential surface, hooks, network call은 따로 봐야 합니다.

memory tool은 왜 더 조심하나요?

memory는 읽는 것보다 남기는 것이 문제일 때가 많습니다. 세션, 파일, prompt, tool output이 오래 남으면 나중에 어디까지 저장됐는지 추적하기 어렵습니다.

stealth browser는 항상 나쁜가요?

도구 자체를 한 문장으로 단정하고 싶지는 않습니다. 다만 DaejinLab/Hermes 기본 운영에는 맞지 않습니다. 소유·허가된 QA sandbox가 아니라면 기본 reject로 두는 게 안전합니다.

다음 기준

다음에 외부 AI agent repo를 보면, 저는 설치 명령보다 삭제 명령을 먼저 찾을 생각입니다. rollback이 없는 도구는 pilot도 조심해야 합니다. 그리고 “많이 연결되는 도구”보다 “좁게 읽고, 좁게 쓰고, 흔적을 설명할 수 있는 도구”를 우선 보려고 합니다.

출처와 기준일