GitHub 원격 MCP 서버 확장의 교훈
📺 원본 영상: Lessons from Scaling GitHub’s Remote MCP Server — Sam Morrow, GitHub 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-04-28 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
GitHub에서 MCP(Model Context Protocol) 서버 개발을 이끌고 있는 Sam Morrow가 AI Engineer Europe 컨퍼런스에서 GitHub 원격 MCP 서버를 실제로 구축하고 수백만 건의 도구 호출을 처리하는 규모로 확장하면서 마주쳤던 실전 도전 과제들을 공유한다. 도구 수 폭증으로 인한 에이전트 성능 저하, OAuth 인증 도입 과정의 예상치 못한 난관, 프롬프트 인젝션(Prompt Injection) 보안 위협, 그리고 무상태(Stateless) 서버 아키텍처로의 전환까지 — 이론이 아닌 운영 현장에서 도출된 인사이트들이다.
1. 출발점: 공개 오픈소스와 빠른 성장의 역설
GitHub의 MCP 여정은 2024년 4월 로컬 MCP 서버를 오픈소스로 공개하면서 공식적으로 시작되었다. 공개 첫 주에 GitHub 전체에서 가장 많은 스타를 받는 저장소가 될 만큼 반응은 폭발적이었고, 커뮤니티의 대규모 기여가 쏟아지면서 저장소(repos), 이슈(issues), PR(Pull Requests), Actions, Projects 등 GitHub 플랫폼의 넓은 영역에 걸쳐 도구들이 빠르게 추가되었다. 그러나 약 한 달이 지났을 무렵, 역설적인 현상이 나타났다. 새로운 기능이 추가될수록 에이전트가 GitHub를 더 잘 활용하는 게 아니라, 오히려 더 나쁘게 사용하게 된 것이다. 컨텍스트 윈도우(Context Window)는 더 빨리 포화 상태에 이르렀고, 100개가 넘는 도구가 등록된 상황에서 에이전트는 혼란을 겪었다.
Morrow는 이 시기에 LangChain이 2024년 2월에 발표한 연구를 언급한다. 그 연구의 핵심 결론은 간결했다. “더 많은 도구가 더 나은 에이전트를 만들지 않는다.” 정확하게는, 더 많은 컨텍스트와 더 많은 도구를 컨텍스트에 직접 쑤셔 넣는 것이 문제의 본질이었다. GitHub는 지극히 광범위한 플랫폼이기에 각 영역별 도구가 필요하다는 논리는 타당하지만, 그 모든 도구를 동시에 에이전트에 제공하는 방식은 결국 실패였다.
2. 도구 과부하 문제와 해결 시도들
문제를 해결하기 위해 Morrow 팀이 처음 시도한 접근은 도구 세트(Tool Sets) 개념이었다. 연관된 도구들을 그룹으로 묶고, 사용자가 필요한 그룹만 선택해 활성화하도록 하는 방식이다. 나아가 에이전트가 직접 사용 가능한 도구 세트를 탐색하고 필요한 것만 묶음으로 활성화하는 동적 도구 선택(Dynamic Tool Selection) 기능도 구현했으며, 시맨틱 도구 검색을 위한 RAG(Retrieval-Augmented Generation) 기반 버전도 내부적으로 제작했다 — 다만 이 버전은 결국 공개 릴리즈로 이어지지 않았다.
그런데 이 모든 정교한 솔루션에도 불구하고 결과는 실망스러웠다.
04:01 - 대부분의 사용자가 기본 설정을 그대로 사용한다는 데이터를 보여주는 슬라이드
대부분의 사용자는 그냥 기본 설정을 그대로 사용했다. JSON 설정 파일을 조금만 수정하면 되는 일이었지만, 현실에서 대다수의 사용자는 그 작은 수고를 하지 않는다. Morrow는 이것이 어느 정도는 MCP 명세(Specification) 자체의 공백에서 비롯된 문제일 수도 있다고 지적한다. 도구 그룹화에 대한 여러 차례의 명세 수정 제안이 있었지만 모두 거부되었고, 결과적으로 서버 단에서의 모드나 설정 추가는 클라이언트 구현의 공백을 메우는 임시방편에 가까워진다. 실례로, 읽기 전용(Read-only) 모드를 도입해 약 17%의 사용자가 이를 이용하고 있지만, 이는 MCP의 read-only 힌트 어노테이션(Annotation)과 1대1로 대응된다 — 그러나 정작 이를 필터링 수단으로 노출하는 클라이언트는 거의 없다는 것이다.
3. 컨텍스트 최적화: 숫자로 보는 개선 성과
사용 패턴 분석을 통해 팀은 보다 실질적인 최적화에 착수했다. 도구 설명을 일반적인 사용 사례에 집중하고 범위를 좁히는 것만으로 초기 컨텍스트 로드를 약 49% 절감하는 데 성공했다. 이후 CRUD 도구들을 그룹화하여 추가로 줄인 결과, 현재 기본 설정으로는 약 40개의 도구만 활성화되며 사용자가 필요에 따라 확장하거나 축소할 수 있다.
05:21 - 컨텍스트 최적화를 통한 약 49% 로드 감소 수치를 보여주는 차트 또는 표
출력 토큰(Output Tokens) 최적화 역시 주목할 만한 성과를 냈다. PR(Pull Request) 목록 조회 결과를 정확히 필요한 필드만 반환하도록 개선한 것만으로, 해당 도구의 출력 토큰이 75% 이상 감소했다.
06:00 - PR 목록 도구의 출력 토큰 75% 이상 감소 사례를 보여주는 비교 자료
Morrow는 “몇 달 전에 사용하다가 최근에 다시 접한다면 전혀 다른 서버처럼 느껴질 것”이라고 말할 만큼, 이 최적화는 지속적으로 진행 중인 작업이다.
4. 도구 실패율 감소와 에이전트 의도 인코딩
컨텍스트 절감과 별개로 팀은 도구 호출 실패율 감소에도 집중했다. 현재 성공률은 95% 이상에 달한다.
06:46 - 도구 호출 성공률 95% 이상을 나타내는 메트릭 화면
완전한 예방이 불가능한 실패도 있다 — 에이전트는 자신이 특정 저장소에 쓰기 권한이 있는지 알지 못하고, 여전히 할루시네이션(Hallucination)을 일으킨다. 그러나 상당수의 오류는 에이전트의 의도(Intent)를 도구 인터페이스에 인코딩함으로써 해결할 수 있었다.
예를 들어, 하나의 도구 호출을 안정적으로 처리하기 위해 서버 측에서 내부적으로 5번의 API 호출이 필요하더라도 그 모든 과정을 서버가 처리한다. 라운드 트립(Round-trip)을 줄임으로써 컨텍스트를 절약하고, 처리 시간을 단축하며, 에이전트의 성공률을 높이는 세 가지 효과를 동시에 얻는다. 또한 팀은 에이전트가 도구를 적절한 시점에 호출하고 부적절한 시점에는 호출하지 않도록 도구 설명을 서로 비교 검증하는 에발(Evals, Evaluations) 체계를 구축했다. 동료 Xenia가 작성한 블로그 글에 그 방법론이 상세히 소개되어 있다고 Morrow는 언급한다. 개별 도구 설명을 미시적으로 최적화하는 것이 아니라, 도구들이 서로의 풀 안에서 경쟁하며 적절한 역할 분담이 이루어지는지를 검증하는 것이 핵심이다 — 모든 에이전트가 항상 호출하고 싶어 하는 “완벽한” 도구 설명은 사실 최악의 설명이기 때문이다.
5. 보안: 상시적인 위협과 OAuth 2.1 도입
보안 문제는 MCP 생태계 전반에 걸쳐 “상시적인 위협(Constant Menace)“이라고 Morrow는 말한다. 현실에서는 여전히 많은 사람들이 평문(Plain Text) 액세스 토큰을 MCP 설정에 직접 사용하고 있다. 이 토큰들은 대체로 에이전트가 접근 가능한 위치에 저장되어 있고, 유효 기간이 길며, 필요 이상의 권한을 가지고 있어 악용에 취약하다. Morrow는 사용자들이 의도적으로 이런 선택을 하는 게 아니라고 지적한다 — 설정을 쉽고 안전하게 동시에 만드는 것 자체가 어렵기 때문이다.
이 문제를 근본적으로 해결하기 위해 GitHub MCP는 MCP 명세가 제공하는 원격 HTTP 방식을 적극 수용했다. 구체적으로는 OAuth 2.1을 지원하며, Morrow 팀은 GitHub의 인증 서버에 **PKCE(Proof Key for Code Exchange, 이하 “Pixie”라고도 불림)**를 추가하는 작업에도 직접 기여했다. PKCE는 클라이언트 앱의 보안 자세를 강화하는 표준 메커니즘이다.
09:08 - OAuth 2.1 및 PKCE(Proof Key for Code Exchange) 인증 흐름 다이어그램
그러나 OAuth를 도입하면서 뜻밖의 난관이 있었다. 많은 사용자와 클라이언트들이 **동적 클라이언트 등록(Dynamic Client Registration)**을 기대했던 것이다. 팀이 이를 검토한 결과, 올바르게 구현할 경우 앱 데이터베이스의 무한 증가, 이에 따른 속도 제한(Rate Limiting) 버킷팅 문제, 그리고 신뢰할 수 있는 앱 아이덴티티 부재 등 해결하기 어려운 문제들이 발생한다는 결론에 이르렀다. GitHub만이 이 결정을 내린 것은 아니며, MCP 자체도 최근 클라이언트 ID 메타데이터(Client ID Metadata) 방식을 대안으로 검토하기 시작했다. Morrow는 이 방식을 지원하는 방향으로 노력 중이라고 밝혔다.
6. 프롬프트 인젝션과 “치명적인 삼각형”
보안 측면에서 가장 주목할 만한 사건은 Invariant Labs가 공개한 **프롬프트 인젝션 기반 데이터 탈취 공격(Prompt Injection Exfil Attack)**이었다. 이 공격은 GitHub의 비공개 데이터를 외부로 유출하는 방식으로 정교하게 구성되었고, 보고서에서는 GitHub MCP 서버를 명시적으로 지목했다. Morrow는 이 취약점을 부정하지 않는다. 다만, 이것은 GitHub MCP만의 문제가 아니라 MCP 사용 여부와 무관하게 에이전트 기반 시스템 대부분이 공유하는 구조적 취약점이라고 설명한다.
이른바 “치명적인 삼각형(Lethal Trifecta)“으로 알려진 이 문제 — Simon Willison의 블로그 포스트가 탁월한 참고 자료라고 언급한다 — 는 에이전트의 유용성과 데이터 보호 사이의 근본적인 긴장에서 비롯된다. 에이전트가 더 많은 것을 할수록, 악의적인 콘텐츠가 그 능력을 악용할 여지도 커진다. 이 문제는 아직 완전히 해결되지 않았으며, 업계 전체가 해법을 모색하는 활발한 영역이다. GitHub의 사용자 기반은 보안 요건이 극단적으로 다양하다 — 물리적으로 격리된(Air-gapped) GitHub Enterprise Server 인스턴스를 운영하는 기업부터, 에이전트에 전체 토큰 접근 권한을 부여하고 직접 GitHub에 연결하는 개인 사용자까지 공존한다.
7. 인증 기반 도구 필터링과 단계적 권한 상승
보안과 사용성을 동시에 개선한 접근 중 Morrow가 특히 만족스럽다고 꼽는 것은 인증 기반 도구 필터링이다. 사용자가 PAT(Personal Access Token)로 GitHub MCP에 로그인하면, 서버는 해당 토큰의 스코프(Scope)를 즉시 확인하고 그 권한 범위에 해당하는 도구들만 활성화한다. 사용자가 별도로 설정할 것은 없다 — 토큰을 제공하는 것만으로 충분하다.
OAuth를 통한 연결에서는 단계적 권한 상승(Step-up Auth) 메커니즘도 제공한다. 현재 스코프로는 특정 도구를 호출할 수 없는 경우, 서버는 도구 호출을 실패로 처리하는 대신 스코프 요청 챌린지를 반환하고, 클라이언트(예: VS Code)가 사용자에게 권한 확장 여부를 대화형으로 묻는다. 사용자가 승인하면 해당 도구 호출이 중단 없이 계속된다. 이 기능은 VS Code와의 협업으로 처음 구현되었는데, 클린 인스톨 상태에서 기본 제공되는 GitHub 토큰으로 시작해 필요에 따라 점진적으로 권한을 확장할 수 있는 경험을 만들기 위해서였다. 또한 Actions 등에서 사용되는 서버 토큰은 연결된 사용자 계정이 없기 때문에 사용자 특정 도구를 자동으로 제거함으로써, 반복적인 실패와 불필요한 컨텍스트 낭비를 사전에 차단한다.
8. 무상태(Stateless) 아키텍처와 대규모 운영
13:52 - Redis 세션 스토리지를 포함한 무상태 서버 아키텍처 다이어그램
GitHub MCP의 서버 운영 방식은 철저하게 무상태(Stateless) 구조다. 세션 저장소로는 Redis를 활용하며, 표준적인 관찰 가능성(Observability) 및 디버깅 스택을 갖추고 있다. 많은 팀들이 단일 상태 보존(Stateful) MCP 서버 프로세스를 운영하다가 이 구조로의 전환에 어려움을 겪는다고 Morrow는 언급한다.
GitHub가 택한 접근 방식의 핵심은 매 요청마다 새로운 서버 인스턴스를 생성한다는 점이다. SDK 의미론(Semantics) 상 완전히 새로운 서버 인스턴스를 만들고, 요청 시작 시점에 해당 사용자의 설정과 정책에 따라 도구들을 동적으로 추가한다. 사용자가 설정한 것, 또는 허용된 것만이 정확히 제공된다. 세션은 주로 클라이언트 아이덴티티를 식별하는 데 사용된다 — MCP를 통해 자기 보고(Self-reported)되는 클라이언트 신원 정보가 세션을 통해서만 추적 가능하기 때문에, 어떤 클라이언트들이 서버를 사용하는지 파악하는 데 유용하다.
이 구조를 통해 GitHub MCP는 현재 주당 약 700만~800만 건의 도구 호출을 처리하는 수준으로 확장되었다.
9. 실험적 기능: Insider’s Mode와 MCP Apps
팀은 아직 정식 릴리즈하지 않은 기능들을 빠르게 사용자에게 제공하기 위해 Insider’s Mode를 운영한다. 특정 피처 플래그와 실험적 기능들을 활성화해 이를 원하는 누구에게나 제공하는 방식이다.
Insider’s Mode를 통해 현재 제공되는 대표적인 기능 중 하나가 MCP Apps다. Morrow는 에이전트와 대화하다가 AI가 생성한 이슈를 직접 편집할 기회를 갖는 것이 실제로 매우 유용하다고 설명한다. 특히 전문적인 오픈소스 프로젝트에서 활동할 때, 봇이 작성한 것으로 보이는 이슈가 닫혀버리는 상황을 방지하기 위해 최종 내용을 직접 확인하고 싶은 경우가 있다. 이것이 MCP가 가능하게 하는 Human-in-the-Loop 경험의 좋은 사례다.
10. 향후 전망: 수천 개의 도구가 일상이 될 미래
Morrow가 그리는 가까운 미래의 MCP 생태계는 지금과 상당히 다르다. 서버 탐색(Server Discovery)은 자동화될 것이고, 도구 사용 방식은 bash의 파이프라인처럼 **합성적(Compositional)**으로 발전할 것이다 — 도구를 다른 도구로 파이핑하거나, 스트리밍 방식으로 데이터를 처리하는 방향이다. Cloudflare의 코드 모드 접근 방식이나 Anthropic이 Claude Code에 최근 탑재한 도구 검색(Tool Search) API, 그리고 OpenAI의 유사한 API가 이 방향을 가리키는 신호들이다.
이러한 발전이 현실화되면, 수천 개의 도구가 동시에 존재하는 것이 전혀 이상하지 않은 환경이 된다 — 그리고 그것이 가능해지면, 오늘날 맥락 효율성을 위해 내렸던 “도구 수 줄이기” 결정들이 많은 부분 역전될 것이다. 더 나아가, 사용자는 MCP가 무엇인지조차 알 필요가 없어질 수 있다. 자신이 원하는 것을 전달하면 서버 탐색, 인증 설정, 도구 선택이 모두 자율적으로 이루어지는 세계다. Morrow는 이것이 그리 멀지 않은 미래라고 보면서도, 아직 실험적 단계를 벗어나지 못했음을 솔직하게 인정한다.
마무리 / 핵심 정리
GitHub MCP 서버의 지난 1년은 빠른 성장과 그에 따른 복잡성 폭증, 그리고 실전 최적화의 반복이었다. 도구 100개를 단순히 제공한다고 해서 에이전트가 더 똑똑해지지 않는다는 교훈은 강렬하다. 도구의 숫자보다는 에이전트가 올바른 맥락에서 올바른 도구를 호출하도록 설계하는 것, 불필요한 컨텍스트 소비를 줄이는 것, 그리고 실패를 예방하는 서버 사이드 로직이 핵심이다.
보안에서는 편의성과 안전성의 긴장이 여전히 해소되지 않은 과제로 남아 있다. OAuth는 올바른 방향이지만, 동적 클라이언트 등록과 같은 세부 설계 선택에서 현실적인 운영 문제가 발생하고, 프롬프트 인젝션은 어느 에이전트 시스템도 완전히 자유로울 수 없는 구조적 위협이다.
주당 700~800만 건의 도구 호출을 처리하면서도 팀은 성장을 멈추지 않았다 — 126명의 기여자, 30,000개에 가까운 스타, 1,100만 건 이상의 Docker 다운로드, 그리고 하루 7건 이상의 이슈·PR이 1년 넘게 이어졌다는 숫자들이 이 프로젝트의 활기를 말해준다.
18:10 - GitHub MCP 서버의 전체 통계 — Docker 다운로드 수, 스타, 기여자, 주간 도구 호출 수 등
Morrow의 말처럼, “모든 것이 불타고 있지만(Mildly on fire), 그게 바로 흥미롭고 재미있는 이유”다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Lessons from Scaling GitHub’s Remote MCP Server — Sam Morrow, GitHub |
| 채널 | AI Engineer |
| 강연자 | Sam Morrow (GitHub MCP 서버 개발 리드) |
| 리포트 작성 | 2026-04-28 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.