GitHub Agent Finder는 실제적인 문제를 겨냥합니다. 에이전트가 만약을 대비해 모든 MCP 서버, 스킬 및 도구를 로드할 수는 없습니다. 개선의 핵심은 더 많은 것을 발견하는 것이 아니라, 랭킹, 정책 및 인간의 결정을 통해 허용된 것만을 발견하는 것입니다.

GitHub Agent Finder는 Copilot를 위한 발견(discovery) 계층으로, 허용된 레지스트리 내에서 작업에 관련된 역량(MCP 서버, 도구(tools), 스킬(skills), 에이전트 또는 캔버스(canvases))을 검색하고, 필요에 따라 사용할 수 있도록 정렬된 매치 결과를 반환합니다.

배포 계획 TL;DR 주요 키워드는 GitHub Agent Finder입니다. 스페인어 검색 의도는 이것이 무엇인지, ARD/MCP 레지스트리와 어떻게 결합되는지, 그리고 팀이 동적인 도구 발견을 허용하기 전에 어떤 제어 장치가 필요한지 이해하는 것입니다. 나의 입장: Agent Finder는 불필요한 컨텍스트와 수동 설정을 줄여주기 때문에 좋은 방향입니다. 하지만 이를 플러그인 상점처럼 취급한다면, 기존 MCP에서 겪었던 권한 문제를 더 나은 UX와 함께 똑같이 겪게 될 것입니다.

GitHub Agent Finder가 해결하는 문제

인용 가능한 정의: GitHub Agent Finder는 Copilot를 위한 발견(discovery) 서비스로, Agentic Resource Discovery (ARD)와 호환되는 카탈로그를 조회하여 각 에이전트에 모든 통합 기능을 미리 구성하지 않고도 작업에 적합한 역량을 찾는 것을 돕습니다.

이 문제는 MCP나 커스텀 에이전트를 시도해 본 팀이라면 누구나 익숙한 문제입니다. GitHub 서버로 시작해서 문서 서버, CI, 브라우저, 데이터베이스, 클라우드, 티켓, 그리고 몇 가지 스킬을 추가하다 보면, 얼마 지나지 않아 에이전트는 너무 많은 컨텍스트와 너무 많은 도구(tools)를 갖게 되며, 아무도 설명할 수 없는 권한의 경계에 직면하게 됩니다.

Agent Finder는 무게 중심을 바꿉니다. 기본적으로 모든 것을 로드하는 대신, Copilot가 리소스 인덱스에서 검색하여 관련 역량을 제안할 수 있게 합니다. 이는 인덱스가 거버넌스(governance)를 따를 때만 유용합니다. 정책 없는 발견은 랭킹 기능이 추가된 섀도우 IT(shadow IT)일 뿐입니다.

ARD(Agentic Resource Discovery)를 한 문장으로 요약하자면: ARD 카탈로그, 레지스트리(registry) 및 랭킹(ranking)은 또 다른 에이전트 프레임워크가 아닙니다. 이는 발견(discovery)을 위한 사양(specification)입니다. 즉, MCP 서버부터 스킬(skills), 에이전트(agents), 그리고 전통적인 도구(tools)에 이르기까지 에이전트 기반 리소스(agentic resources)를 어떻게 게시, 설명, 검색 및 검증할지를 정의합니다. 중요한 차이점은 카탈로그(catalogue)와 레지스트리(registry) 사이의 구분입니다. 카탈로그는 리소스와 메타데이터(metadata)를 게시하고, 레지스트리 또는 발견 서비스(discovery service)는 이를 인덱싱(indexing)하고 검색에 응답합니다. Agent Finder는 Copilot이 JSON에 고정된 정적 목록이나 에이전트 프로필에 의존하지 않도록 이 모델을 활용합니다. 팀에게 있어 올바른 질문은 Copilot이 무엇을 발견할 수 있는가가 아닙니다. 올바른 질문은 Copilot이 어떤 카탈로그를 조회할 수 있는가, 누가 해당 리소스를 승인하는가, 어떤 스코프(scopes)를 가지는가, 그리고 어떻게 액세스(access)를 취소하는가입니다.

권장 모델: Agent Finder는 역량(capabilities)을 발견하고 순위를 매기지만, 실제 실행은 스코프(scopes), 허용 목록(allowlists), 로그(logs) 및 변이적 동작(mutant actions)이 발생하는 경우 인간의 승인을 통해 분리되어야 합니다.

실제로 무엇을 발견하는가

GitHub의 문서는 Agent Finder를 MCP 서버, 도구(tools), 에이전트(agents) 및 스킬(skills)과 같은 역량을 런타임(runtime)에 찾는 방법으로 설명합니다. 발표 내용에는 고려할 수 있는 리소스 세트 내에 캔버스(canvases)가 추가되었습니다.

이것이 중요한 이유는 역량(capability)이 항상 같은 의미를 갖지는 않기 때문입니다. MCP 서버는 GitHub에 대해 변이적 도구(mutant tool)를 노출할 수 있습니다. 스킬(skill)은 Markdown 형식의 운영 가이드일 수 있습니다. 커스텀 에이전트(custom agent)는 지침, 도구 및 특화된 동작을 가져올 수 있습니다. 캔버스(canvas)는 공유 작업 영역일 수 있습니다.

이들을 공통된 발견(discovery) 체계 아래 섞는 것은 UX(사용자 경험) 측면에서는 타당하지만, 리스크(risk) 측면에서는 그렇지 않습니다. 읽기 전용 스킬(read-only skill)과 프로덕션(production) 환경에 대한 쓰기 권한을 가진 MCP 서버는 동일한 승인 프로세스를 거쳐서는 안 됩니다.

긍정적인 약속: 죽은 컨텍스트(dead context)의 감소

가장 명확한 이점은 죽은 컨텍스트(dead context)를 줄이는 것입니다. 오늘날 많은 설정(setups)은 만약을 대비해 모든 MCP 서버나 모든 지침을 로드합니다. 이는 프롬프트(prompt)를 지저분하게 만들고, 비용을 증가시키며, 모호함을 유발하고, 간접적 프롬프트 인젝션(indirect prompt injection)의 통로를 더 많이 열어줍니다.

Agent Finder가 제대로 작동한다면, 에이전트(agent)는 매 세션마다 모든 도구(tool)를 끌고 다닐 필요가 없습니다. 작업을 설명하고, 관련 리소스를 조회하며, 순위가 매겨진 매치(matches)를 얻은 다음, 그때서야 무엇을 포함할지 결정하면 됩니다.

이 패턴은 무한한 정적 설정(static configuration)보다 낫습니다. 하지만 검토(review)를 없애지는 않습니다. 순위(ranking)는 권한 부여(authorization)가 아닙니다. 순위는 무엇이 유용해 보이는가에 답하고, 정책(policy)은 무엇을 사용할 수 있는가에 답합니다.

위험한 약속: 거버넌스(governance)의 대체재로서의 디스커버리(discovery)

Agent Finder를 마법 같은 자동화로 판매하는 것은 쉬운 실수입니다. 즉, 에이전트가 필요한 것을 찾아내면 끝이라는 식입니다. 이는 프라이빗 저장소(private repos), 고객 데이터, 빌링(billing), 클라우드(cloud) 또는 CI/CD 환경에서 절대로 허용해서는 안 되는 방식입니다.

GitHub는 세 가지 건강한 경계를 강조합니다. 공용 또는 프라이빗 레지스트리(registries)를 지정할 수 있고, 발견된 리소스는 관리되는 설정(settings)에 의해 제한되며, Agent Finder는 아무것도 조용히 설치하거나 연결하지 않습니다. 이 세 가지 세부 사항이 유용한 디스커버리(discovery)와 암묵적 허용(implicit permission) 사이의 차이를 만듭니다.

진지한 팀에서 Agent Finder는 권한을 부여하는 것이 아니라 옵션을 반환해야 합니다. 해당 환경의 사람이나 정책이 특정 기능이 세션에 포함될지, 그리고 어떤 범위(scope)로 포함될지를 결정합니다.

브리핑: 개발 팀에서 이를 사용하는 방법

첫째, 레지스트리를 분리하겠습니다. 탐색 및 학습을 위한 공용 레지스트리 하나, 승인된 내부 리소스를 위한 프라이빗 레지스트리 하나를 둡니다. 데모 서버와 레포지토리(repos), 이슈(issues), 시크릿(secrets), 관측성(observability) 또는 데이터베이스(databases)를 건드리는 도구를 혼합해서는 안 됩니다. 둘째, 의도(intention)에 따라 리소스를 모델링하겠습니다. 문서 읽기, 이슈 트리아지(triage), CI 디버깅, PR 제안, 메트릭 조회, 인프라 변경(mutate)은 서로 다른 카테고리입니다. 카테고리에 따라 스코프(scopes), 로그(logs) 및 승인 절차가 결정되어야 합니다.

셋째, 커스텀 스킬(skills)과 에이전트(agents)를 검토 가능한 코드(code)로서 공개해야 합니다. SKILL.md나 에이전트 프로필은 단순한 문서가 아닙니다. 이는 프로덕션(production) 결정을 안내할 수 있습니다. 따라서 PR(Pull Request), 소유권(ownership) 및 버전 관리(versioning) 과정을 거쳐야 합니다.

실무적 관점에서 MCP 레지스트리(registry)를 읽는 것은 MCP를 마음대로 사용하는 것과는 다릅니다. GitHub는 이미 조직 및 기업 내에서 MCP 사용을 관리하기 위한 정책을 문서화하고 있습니다: MCP를 차단하거나, 정의된 레지스트리로 제한하며, IDE 및 Copilot CLI와 같이 지원되는 인터페이스에서 설정(settings)을 적용하는 방식입니다. Agent Finder는 바로 이러한 레지스트리 로직에 기반합니다: 사용자가 허용한 소스 내에서 발견(discovery)합니다. 만약 레지스트리가 제대로 관리(curated)되지 않는다면, 그 결과물 또한 제대로 관리되지 않을 것입니다. 만약 레지스트리가 읽기, 쓰기, 프로덕션, 샌드박스(sandbox)를 분리한다면, 발견(discovery) 프로세스는 운영 가능한 수준이 됩니다. 저의 원칙은 다음과 같습니다: 동적으로 발견된 그 어떤 리소스도 수동으로 구성된 통합(integration)보다 더 많은 권한을 가져서는 안 됩니다. 발견(discovery)은 마찰을 줄여야지, 편의를 위해 권한을 높여서는 안 됩니다.

스킬(Skills) 및 커스텀 에이전트(custom agents): 위험은 API에만 있지 않다

에이전트 스킬(agent skills)에 대한 GitHub 문서에는 프론트매터(frontmatter)와 지침이 포함된 SKILL.md를 사용하며, 프로젝트, 개인 및 공유 위치를 허용합니다. 커스텀 에이전트(custom agents)는 정체성, 설명, 도구(tools) 및 MCP 설정이 포함된 마크다운(Markdown) 프로필을 사용합니다.

이는 팀의 지식을 재사용 가능한 컴포넌트(components)로 변환하기 때문에 강력합니다. 하지만 동시에 매우 민감한 문제입니다. 스킬(skill) 하나가 에이전트에게 신호를 무시하도록 가르치거나, 너무 광범위한 명령을 실행하게 하거나, 검토되지 않은 소스를 신뢰하게 만들 수 있기 때문입니다.

그렇기 때문에 저는 스킬(skills), 에이전트(agents), MCP 서버(servers)를 의존성(dependencies)처럼 취급해야 한다고 생각합니다. 이들에게는 소유자(owners), 버전(version), 변경 로그(changelog), 스코프(scope) 및 동작 테스트(behavior tests)가 있어야 합니다. 특정 기능의 유지 관리자가 누구인지 모른다면, 해당 기능은 내부 레지스트리에 나타나서는 안 됩니다.

도입 체크리스트

• Agent Finder가 공개 카탈로그(public catalog), 비공개 레지스트리(private registry), 또는 둘 다를 사용할지 정의합니다.

• 탐색용 리소스(exploratory resources)와 실제 업무용 승인된 리소스(approved resources)를 분리합니다.

• 역량을 읽기(reading), 검사(inspection), 쓰기(writing), 그리고 중요한 변이(critical mutation)로 분류합니다.

• 스킬(skills)과 내부 커스텀 에이전트(custom agents)가 검토 가능한 리포지토리(repos)에 존재하도록 합니다.

• 변이 능력을 가진 기능(mutant capabilities)의 자동 설치나 자동 연결을 허용하지 않습니다.

• Copilot가 어떤 리소스를 발견했는지, 어떤 작업 때문인지, 그리고 누가 승인했는지를 기록합니다.

• 읽기 전용(read-only) 문서 및 CI 리소스로 시작합니다.

• MCP 서버에 대해 최소 권한 범위(minimum scopes)를 요구하고 간편한 권한 취소(revocation)가 가능하도록 합니다.

• 커스텀 에이전트(custom agents)를 조직 전체에 배포하기 전에 비공개 환경에서 테스트합니다.

• 단순히 편리해 보이는지뿐만 아니라, 로드되는 컨텍스트(context)와 도구 오류(tool errors)가 줄어드는지를 측정합니다.

피해야 할 실수들

첫 번째는 발견(discovery)과 신뢰(trust)를 혼동하는 것입니다. Agent Finder가 특정 역량을 찾아냈다고 해서, 그것이 귀하의 리포지토리(repo), 데이터 또는 컴플라이언스(compliance)에 적합하다는 의미는 아닙니다.

두 번째는 결국 난장판이 되어버리는 비공개 레지스트리를 만드는 것입니다. 모든 것이 등록된다면, 그 레지스트리는 관리(govern)하는 것이 아니라 단지 무질서를 꾸며주는 것에 불과합니다.

세 번째는 지침(instructions)을 검토하지 않는 것입니다. 에이전트(agents)의 경우, 위험은 API에 있을 수도 있지만, 모델이 예상된 절차 밖에서 행동하도록 유도하는 SKILL.md의 문구 하나에도 있을 수 있습니다.

최소 기능 제품 (MVP) 구현

• 1단계: 현재 역량을 인벤토리화합니다: MCP 서버, 스킬(skills), 커스텀 에이전트(custom agents), 스크립트 및 팀이 이미 사용 중인 도구들.

• 2단계: 중복 항목을 제거하고 각 역량을 의도, 접근 가능한 데이터, 가능한 작업 및 소유자(owner)별로 분류합니다.

• 3단계: 저위험 리소스와 내부 문서로 구성된 작은 비공개 레지스트리를 생성합니다.

• 4단계: 실제 작업이지만 중요하지 않은 작업으로 Agent Finder를 테스트하며, 어떤 매치(matches)를 반환하는지 그리고 어떤 컨텍스트(context) 로딩을 피하는지 관찰합니다.

• 5단계: 권한 범위(scopes)를 제한하고, 사용을 감사(audit)하며, 인간의 승인을 요구할 수 있을 때만 변이 역량(mutant capabilities)을 추가합니다.

요약: GitHub Agent Finder는 MCP가 가시화한 문제에 대한 합리적인 대응책입니다. 모든 세션이 만약을 대비해 모든 도구(tools), 모든 스킬(skills), 모든 에이전트(agents)를 끌어온다면 에이전트를 확장할 수 없습니다. 중요한 점은 Copilot이 더 많은 리소스를 발견하는 것이 아닙니다. 더 적고, 더 우수하며, 허용되고, 관련성 있는 리소스를 발견하는 것입니다. 만약 여러분의 도입 결과가 더 정돈된 카탈로그, 더 적은 컨텍스트 로드, 더 좁은 권한 범위로 이어진다면 Agent Finder는 가치가 있습니다. 만약 소유권(ownership) 없는 또 다른 마켓플레이스로 끝난다면, 여러분은 단지 혼란의 이름만 바꾼 것뿐입니다.

자주 묻는 질문 (FAQ)

GitHub Agent Finder란 무엇인가요?

GitHub Agent Finder는 ARD와 호환되는 레지스트리를 조회하여 MCP 서버(MCP servers), 도구(tools), 스킬(skills), 에이전트(agents)와 같은 AI 리소스를 발견하고 작업에 관련 있는 매치(matches)를 반환하는 Copilot의 기능입니다.

ARD란 무엇인가요?

Agentic Resource Discovery(ARD)는 웹이나 프라이빗 레지스트리에서 에이전트 역량(agentic capabilities)을 게시, 발견 및 검증하기 위한 개방형 사양(open specification)입니다.

Agent Finder가 도구를 자동으로 설치하나요?

아니요. GitHub에 따르면, Agent Finder는 옵션을 찾고 매치(matches)를 반환할 뿐, 리소스를 조용히 연결하거나 설치하지 않습니다.

MCP 서버를 수동으로 설정하는 것과 무엇이 다른가요?

수동 설정은 리소스를 사전에 나열하는 방식인 반면, Agent Finder는 허용된 레지스트리 내에서 런타임(runtime) 중에 역량을 검색할 수 있게 해줍니다.

기업에서 Agent Finder를 사용하는 것이 안전한가요?

프라이빗 레지스트리, 관리되는 설정(settings), 최소 권한 범위(scopes), 로그, 그리고 변이 동작(mutant actions)에 대한 인간의 승인을 사용한다면 안전할 수 있습니다. 이를 암묵적인 권한으로 사용해서는 안 됩니다.

프라이빗 레지스트리에 무엇을 가장 먼저 등록해야 하나요?

저위험 리소스부터 시작하세요: 내부 문서, 진단 스킬(diagnostic skills), 읽기 전용 도구(reading tools), 그리고 중요하지 않은 리포지토리에서 테스트된 커스텀 에이전트(custom agents) 등이 해당됩니다.

편집자 마무리 운영 규칙: 자동화는 단순히 검토 가능한 노이즈를 생성하는 곳이 아니라, 코멘트(comment)가 기술적 결정을 바꿀 수 있는 곳에서 활성화해야 합니다.

출처 및 참고 문헌