github-mcp-server 딥다이브
— AI의 요청을 GitHub의 실제 작업으로 바꾸는 연결부

1프로젝트 한줄 요약

github-mcp-server는 GitHub API를 MCP 도구로 감싸서 AI 클라이언트에 제공합니다. 이 저장소에서 배울 핵심은 외부 API를 AI가 호출할 수 있는 작고 검증 가능한 작업으로 바꾸는 방법입니다. 언어 모델이 GitHub의 HTTP 주소와 응답 형식을 매번 직접 조합하는 대신, 서버가 준비한 도구를 선택하도록 만드는 것입니다.

예를 들어 사용자가 “내 GitHub 계정을 알려줘”라고 말하면 AI 호스트는 get_me를 선택해 호출할 수 있습니다. pkg/github/context_tools.go의 GetMe는 인증된 GitHub 클라이언트를 받아 client.Users.Get(ctx, "")를 실행하고, 응답을 MinimalUser로 옮깁니다. 자연어를 이해하는 쪽은 호스트의 모델이고, 이 Go 서버는 정해진 작업을 수행하는 쪽입니다.

처음 구분할 세 가지 기능

GitHub 쪽 기능은 저장소·이슈·PR·Actions·보안 경고·Projects 등으로 넓어집니다. 모든 기능을 한꺼번에 이해할 필요는 없습니다. 먼저 get_me의 입력·클라이언트·출력 세 부분을 찾으면, 다른 도구도 비슷한 틀로 읽을 수 있습니다.

2왜 주목받는가

2-1. GitHub 작업이 에이전트의 도구가 된다

2026-10-23 GitHub Trending Go Weekly #10 선정 프로젝트이며, GitHub 기준 스타는 33,883개입니다. 저장소와 코드 검색에 머물지 않고 이슈 처리·PR 관리·CI 확인까지 연결한다는 점이 학습 대상으로 매력적입니다. 주목할 설계적 장점은 GitHub 작업을 여러 AI 호스트에서 재사용할 수 있는 공통 도구로 만든다는 데 있습니다.

이는 코드와 기능 구성에서 읽어낸 관심 요인입니다. 주간 순위의 정확한 상승 원인이나 스타 증가량은 별도 시계열 자료가 필요합니다. 최신 릴리스가 v2.0.3(2026-10-21)이고 최근 push가 2026-10-22라는 사실만으로, 특정 기능 때문에 순위가 올랐다고 단정할 수는 없습니다.

2-2. 직접 API 호출·CLI와 비교하면 무엇이 다른가

이 표는 접근 방식의 차이입니다. 응답 속도나 안정성 우열을 벤치마크한 결과는 아닙니다. 이 저장소의 교육적 가치는 API 호출 한 줄 주변에 필요한 제품 설계를 한 번에 볼 수 있다는 점입니다.

2-3. 공식 원격 서버와 로컬 서버를 함께 제공한다

README는 GitHub가 호스팅하는 원격 서버 주소를 https://api.githubcopilot.com/mcp/로 안내합니다. 로컬에서는 실행 파일이나 Docker를 이용해 stdio 방식으로 연결할 수 있습니다. 현재 소스에는 자체 호스팅을 위한 http 하위 명령도 있습니다.

공개 소스의 pkg/github/tools.go에는 원격 전용 도구 모음도 문서화되어 있습니다. copilot_spaces와 github_support_docs_search는 원격 전용으로 분리됩니다. 따라서 로컬 실행과 GitHub의 운영 서비스가 정확히 같은 기능을 제공한다고 가정하면 안 됩니다.

2-4. “공식”이라는 이름보다 구현에서 볼 것

• 선택 가능성: 필요한 도구 모음과 개별 도구만 공개할 수 있습니다.
• 경계의 명확성: 읽기 전용, 토큰 scope, 콘텐츠 필터가 서로 다른 책임을 가집니다.
• 변경 감지: 도구 스키마 스냅샷과 문서 생성 검사가 인터페이스 변경을 드러냅니다.
• 배포 연결: UI 빌드부터 Go 바이너리와 컨테이너까지 이어지는 경로가 보입니다.

3기술 스택 전체 지도

3-1. 백엔드: Go와 공식 MCP SDK

go.mod의 모듈 경로는 github.com/github/github-mcp-server/v2이고, Go 지시문은 go 1.27.3입니다. 아래 버전은 커밋 f385262의 직접 의존성 선언입니다.

3-2. 프론트엔드: 채팅 안에서 사용하는 작은 React 화면

ui/package.json은 @github/mcp-server-ui를 private: true로 선언합니다. 서버 릴리스 v2.0.3과 UI 패키지 자체 버전 1.0.0은 서로 다른 번호입니다. 아래 표는 선언 범위와 ui/package-lock.json의 고정 버전을 구분합니다.

ui/scripts/build.mjs는 get-me, issue-write, pr-write, pr-edit 네 앱을 순서대로 빌드합니다. ui/vite.config.ts가 결과를 pkg/github/ui_dist/로 보내고, pkg/github/ui_embed.go의 go:embed가 Go 실행 파일에 담습니다.

이 프론트엔드는 별도 웹사이트를 운영하는 구조보다, Go 서버가 AI 호스트에 건네줄 화면을 미리 포장하는 구조에 가깝습니다. 저장소의 UI에는 실행용 코드가 있지만, MCP App을 지원하는 호스트에서 리소스로 제공되는 방식입니다.

3-3. 인프라·빌드: 세 단계 컨테이너와 다중 운영체제 검사

세 베이스 이미지는 SHA-256 digest로 고정되어 있습니다. .goreleaser.yaml의 숫자 2는 도구 설정 형식이며, GoReleaser 실행 파일의 버전 번호를 뜻하지 않습니다. 설정을 읽을 때 이름이 같은 숫자라도 무엇의 버전인지 먼저 확인해야 합니다.

4아키텍처 심화 분석

4-1. 시스템은 어디에서 어디로 연결되는가

cmd/github-mcp-server/main.go는 실행 모드를 고르는 출입구입니다. stdioCmd는 ghmcp.RunStdioServer로, httpCmd는 ghhttp.RunHTTPServer로 연결됩니다. 두 경로는 도구 정의와 github.NewMCPServer를 공유하면서, 인증 정보의 수명은 다르게 관리합니다.

4-2. 요청 하나를 끝까지 따라가기: get_me

아래는 이미 MCP 연결 초기화를 마쳤다고 가정한 도구 호출 메시지 예시입니다. 실제 전송에는 선택한 방식의 연결 절차와 헤더가 더 필요합니다.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_me",
    "arguments": {}
  }
}

1. AllTools에 포함된 GetMe 정의가 Inventory의 후보가 됩니다.
2. 도구 모음·읽기 전용·기능 설정 등의 필터를 통과하면 SDK에 등록됩니다.
3. 미들웨어가 context.Context에 의존성과 요청 상태를 넣습니다.
4. 타입 기반 래퍼가 입력을 처리하고 GetMeInput을 핸들러에 전달합니다.
5. deps.GetClient(ctx)로 클라이언트를 얻고 Users.Get(ctx, "")를 호출합니다.
6. MinimalUser를 구성해 텍스트 결과와 타입 기반 출력을 반환합니다.

pkg/github/context_tools.go에서 흐름을 확인할 핵심 구문은 다음과 같습니다. 전체 함수에서 오류 처리와 출력 필드 일부를 생략한 발췌입니다.

// GetMe 안에서 의존성 획득 → REST 요청 → 결과 생성으로 이어집니다.
client, err := deps.GetClient(ctx)
user, res, err := client.Users.Get(ctx, "")

// 실제 함수는 이 사이에서 오류를 검사하고 MinimalUser를 구성합니다.
result := MarshalledTextResult(minimalUser)
result = attachStaticIFCLabel(ctx, deps, result, ifc.LabelGetMe())
return result, minimalUser, nil

""는 이 호출에서 인증된 사용자 조회에 쓰입니다. MinimalUser라는 이름만 보고 모든 정보가 공개 프로필이라고 생각하면 안 됩니다. 이 함수의 Details에는 비공개 저장소 수 같은 필드도 포함될 수 있습니다.

4-3. 패턴 ① 어댑터: GitHub API를 MCP 도구로 번역

어댑터는 서로 다른 인터페이스를 연결하는 변환기입니다. pkg/github/dependencies.go의 NewTool[In, Out]이 타입을 가진 핸들러와 도구 메타데이터를 묶고, pkg/inventory/server_tool.go가 SDK 등록을 맡습니다.

GetMe는 GetMeInput → MinimalUser, SearchRepositories는 SearchRepositoriesInput → *SearchRepositoriesOutput의 형태입니다. 후자는 pkg/github/search.go에서 client.Search.Repositories를 호출합니다. API 응답 전체를 그대로 넘길지, 모델에 필요한 필드만 정리할지가 이 계층의 중요한 결정입니다.

SearchRepositories의 minimal_output 기본값은 true입니다. 설명에는 최신 클라이언트에서 false를 주어도 선별된 상세 필드를 반환하며, 예전 클라이언트와 동작이 다를 수 있다고 명시됩니다. 입력 옵션 이름만으로 출력 계약을 추측하지 않는 연습이 됩니다.

4-4. 패턴 ② 빌더와 레지스트리: 도구 정의와 공개 정책 분리

pkg/github/inventory.go의 NewInventory는 도구·리소스·프롬프트를 모읍니다. pkg/inventory/builder.go의 Builder는 설정을 누적하고, Build가 최종 Inventory를 만듭니다.

// internal/ghmcp/server.go의 구성 방식에서 핵심만 발췌
inventoryBuilder := github.NewInventory(cfg.Translator, github.WithHost(hostType)).
    WithDeprecatedAliases(github.DeprecatedToolAliases).
    WithReadOnly(cfg.ReadOnly).
    WithToolsets(github.ResolvedEnabledToolsets(cfg.EnabledToolsets, cfg.EnabledTools)).
    WithTools(github.CleanTools(cfg.EnabledTools)).
    WithExcludeTools(cfg.ExcludeTools).
    WithServerInstructions().
    WithFeatureChecker(featureChecker)

기본 모음은 context, repos, issues, pull_requests, users, copilot로 표시됩니다. 실제 도구는 추가 조건을 더 통과해야 합니다. 모르는 개별 도구 이름은 Build에서 오류가 되지만, 모르는 모음은 경고 대상으로 기록됩니다.

도구를 정의하는 코드와 그 도구를 누구에게 공개할지 결정하는 코드를 분리하면, 기능을 늘려도 정책을 한곳에서 검토할 수 있습니다.

4-5. 패턴 ③ 의존성 주입: 같은 도구, 다른 클라이언트 수명

ToolDependencies는 REST·GraphQL·Raw 클라이언트, 로깅, 기능 설정 등을 얻는 인터페이스입니다. BaseDeps는 로컬 서버에서 미리 만든 클라이언트를 보관합니다. RequestDeps.GetClient(ctx)는 HTTP 요청의 토큰 정보를 꺼내 해당 인증 정보로 클라이언트를 만듭니다.

InjectDepsMiddleware와 ContextWithDeps가 의존성을 전달하고, NewToolWithSchemaOptions의 래퍼가 MustDepsFromContext로 꺼냅니다. 테스트에서는 이 인터페이스의 구현을 바꿔 네트워크 없이 성공·실패 응답을 제공할 수 있습니다.

4-6. 패턴 ④ 미들웨어와 데코레이터: 공통 처리를 겹쳐 붙이기

들어오는 HTTP 요청에는 Handler.RegisterMiddleware가 본문 크기 제한 → 토큰 추출 → 요청 설정 → MCP 메시지 파싱 → PAT scope 처리를 순서대로 붙입니다. 개별 도구마다 같은 코드를 반복하지 않도록 만드는 구조입니다.

밖으로 나가는 요청에는 http.RoundTripper를 감싼 전송 계층이 쓰입니다. 로컬 REST 경로는 BearerAuthTransport → UserAgentTransport → ETagTransport → http.DefaultTransport로 이어집니다. 인증 헤더가 설정된 뒤 캐시 키를 계산해야 사용자별 응답을 구분할 수 있으므로 순서가 중요합니다.

pkg/http/handler.go의 ServeHTTP는 요청마다 MCP 서버를 만들고 mcp.NewStreamableHTTPHandler에 Stateless: true를 전달합니다. 대신 mcp.SchemaCache는 Handler에서 공유해 요청마다 반복되는 스키마 처리 비용을 줄입니다.

5디렉토리 구조 해부

위 트리는 학습에 필요한 부분을 추린 것입니다. internal은 Go의 가져오기 제한을 받는 내부 구현이고, pkg는 공개 패키지를 모으는 관례입니다. pkg라는 이름 자체가 API 안정성을 보장하지는 않습니다.

5-1. 처음 읽는 사람을 위한 파일 순서

5-2. 코드 규모는 어떻게 읽어야 할까

커밋 f385262의 파일을 대상으로 빈 줄과 주석을 포함해 집계했습니다. .git, node_modules, vendor, third-party, ui_dist는 제외했습니다. JSON 잠금 파일과 스냅샷 파일도 위 언어별 합계에 넣지 않았습니다.

Go 테스트가 전체 Go 줄 수의 약 59.2%입니다. 이 비율은 테스트 코드가 많다는 뜻이며, 실행 경로의 59.2%가 검증됐다는 커버리지 수치와는 다릅니다. 구현을 읽다 막히면 대응하는 *_test.go 파일의 입력 사례로 돌아가 보세요.

6학습 포인트 (기술별)

6-1. Go: 인터페이스·제네릭·context를 함께 보기

ToolDependencies는 “어떤 객체인가”보다 “무엇을 제공하는가”로 도구를 연결합니다. NewTool[In, Out]의 타입 매개변수는 도구별 입력·출력을 표현합니다. context.Context는 취소 신호와 함께 요청의 인증·설정 정보를 전달하는 통로로 쓰입니다.

// pkg/github/dependencies.go의 메서드 선언 중 일부
GetClient(ctx context.Context) (*gogithub.Client, error)
GetGQLClient(ctx context.Context) (*githubv4.Client, error)

// 같은 파일의 컴파일 시 인터페이스 구현 확인
var _ ToolDependencies = (*BaseDeps)(nil)

해볼 일: BaseDeps.GetClient와 RequestDeps.GetClient를 나란히 적고, 반환 타입은 같지만 토큰을 얻는 위치가 어떻게 다른지 표시하세요. 이어서 nil 슬라이스와 빈 슬라이스가 도구 선택에 서로 다른 뜻을 갖는 이유를 설명해 보세요.

6-2. API 설계: REST와 GraphQL을 문제에 맞게 선택하기

GetMe와 SearchRepositories는 REST 클라이언트를 사용합니다. 반면 pkg/github/issues.go의 fetchIssueIDs는 GraphQL로 이슈의 내부 ID를 조회합니다. 중복 이슈가 주어지면 별칭 duplicateIssue를 사용해 두 이슈의 ID를 한 질의에 담습니다.

해볼 일: fetchIssueIDs의 duplicateOf == 0 분기와 나머지 분기를 비교하세요. 필요한 필드가 ID뿐일 때, 이슈 전체 본문을 요청하는 것과 어떤 차이가 있는지 써 보세요.

6-3. 입력 계약과 오류: 통신 실패와 업무 실패 구분

pkg/inventory/typed_output.go의 wrapTypedHandler는 기본값 적용과 스키마 검증을 거쳐 입력 타입으로 디코딩합니다. 디코더에는 DontMatchCaseInsensitiveStructFields를 설정합니다. 필드 이름 대소문자까지 계약의 일부로 취급하는 사례입니다.

GetMe의 GitHub API 실패는 NewGitHubAPIErrorResponse를 통해 도구 오류 결과로 변환될 수 있습니다. Go의 error가 nil이라고 해서 업무가 성공한 것은 아닙니다. pkg/github/context_tools_test.go는 result.IsError도 따로 검사합니다.

해볼 일: “클라이언트 획득 실패”, “GitHub 응답 실패”, “정상 조회”의 세 경로를 표로 만드세요. 각 경로의 Go 오류와 MCP 결과 오류를 별도 열로 기록하면, 호출 경계마다 오류 표현이 바뀐다는 점이 보입니다.

6-4. 보안 설계: 세 층의 질문을 섞지 않기

ServerTool.IsReadOnly는 Tool.Annotations.ReadOnlyHint를 확인하고, Inventory의 읽기 전용 모드는 이를 기준으로 쓰기 도구를 걸러냅니다. 따라서 도구를 새로 추가하는 개발자는 이 표시를 정확히 지정해야 합니다.

pkg/http/transport/bearer.go의 AllowedHosts는 목록이 비어 있지 않을 때 토큰을 붙일 호스트와 포트를 제한합니다. 리다이렉트 이후에도 전송 계층이 인증 헤더를 다시 붙일 수 있으므로, 표준 HTTP 클라이언트의 기본 동작만 믿지 않는 설계입니다.

RepoAccessCache.IsSafeContent는 비공개 저장소, push 권한이 있는 작성자, 신뢰하는 봇, 조회자 본인의 콘텐츠 등을 구분합니다. 이는 콘텐츠 작성자의 신뢰도를 판단하는 정책이며, 모든 문장의 의미를 분석해 악성 지시를 알아내는 장치는 아닙니다.

보안 코드를 공부할 때는 장치의 이름보다, 무엇을 검사하고 어디까지 효력이 있는지부터 확인해야 합니다.

6-5. TypeScript·React: 새 요청이 오면 이전 결과를 지우기

ui/src/hooks/useMcpApp.ts의 useMcpApp는 호스트에서 도구 입력과 결과를 받아 상태에 저장합니다. app.ontoolinput에서 setToolResult(null)을 호출해 이전 실행의 성공 화면이 새 입력 폼 위에 남는 문제를 막습니다. 작은 상태 초기화가 실제 사용 흐름을 바꿉니다.

callTool은 app.callServerTool로, setModelContext는 app.updateModelContext로 이어집니다. 화면에서 보이는 상태와 모델에게 전달되는 문맥을 구분해서 읽어 보세요. pkg/github/ui_capability.go의 shouldDeferToForm은 UI 지원 여부와 제출 상태 등을 함께 판단합니다.

해볼 일: 입력 A → 결과 A → 입력 B → 결과 B 순서로 상태 표를 그리세요. 입력 B 시점에 결과 A를 남겨두면 어떤 오해가 생기는지 설명하면 React 상태 관리의 목적을 이해한 것입니다.

6-6. 테스트·CI: 함수의 결과와 도구 계약을 함께 지키기

Test_GetMe는 스키마 스냅샷, 읽기 전용 표시, 테이블 기반 행동 테스트를 함께 확인합니다. REST는 MockHTTPClientWithHandlers, GraphQL은 internal/githubv4mock로 대체합니다. script/test에 적힌 실제 명령은 go test -race ./...입니다.

internal/toolsnaps/toolsnaps.go의 Test는 JSON 스키마와 기준 파일을 비교합니다. CI에서 기준 파일이 없으면 실패하지만, 로컬에서 없으면 파일을 만들 수 있습니다. 테스트도 파일을 쓸 수 있으므로 명령의 이름만 보고 부작용이 없다고 생각하지 않는 습관이 중요합니다.

해볼 일: 필수 입력 하나를 추가했다고 가정하고, 구현·스키마·스냅샷·문서 중 무엇을 함께 검토해야 하는지 적으세요. .github/workflows/docs-check.yml이 문서를 생성한 뒤 README 차이를 검사하는 이유도 연결해 보세요.

7하드웨어 / 시스템 요구사항

이 서버의 자원 계획은 모델 추론보다 GitHub API 통신·동시 요청·응답 크기를 중심으로 세워야 합니다. 이 저장소의 서버는 GitHub 연결을 담당합니다. 모델을 실행하는 AI 호스트의 메모리와 GPU 요구는 별도로 계산해야 합니다.

7-1. 실습 환경은 어느 정도로 잡을까

코드 열람은 일반 노트북으로 시작할 수 있습니다. 직접 빌드까지 공부한다면 메모리 8GB 이상, 2~4코어급 개발 환경을 출발점으로 고려할 수 있습니다. 이는 편의를 위한 제안이며, 측정한 최소 사양이 아닙니다. Docker·편집기·AI 호스트를 함께 띄우면 필요한 메모리가 늘어납니다.

실행 서버의 메모리는 동시 요청 수와 결과 크기를 정한 뒤 측정해야 합니다. 의존성 다운로드, UI 번들, Go 빌드 캐시에도 디스크 공간이 들어갑니다. 바이너리 크기·실사용 RSS·처리량은 실제 실행 환경에서 측정해야 구체적인 운영 용량을 정할 수 있습니다.

7-2. 숫자가 보이는 곳은 먼저 읽기

또한 HTTP의 --listen-host 기본값은 빈 문자열이며 모든 인터페이스에 바인딩합니다. 개인 실습에서 로컬 연결만 필요하다면 127.0.0.1을 지정하는 설정을 검토하세요. Dockerfile의 EXPOSE 8082가 기본 모드가 HTTP라는 뜻은 아닙니다. 실제 기본 명령은 stdio입니다.

8직접 해볼 수 있는 실습 과제

실습의 완료 기준은 명령을 실행했다는 사실보다, 입력 하나가 어떤 판단을 거쳐 어떤 결과가 되는지 설명할 수 있는가입니다. 1·2번은 토큰이나 네트워크 없이 파일만 읽어도 끝낼 수 있습니다. 3~5번의 구현은 별도 연습용 프로젝트에서 가짜 응답으로 시작하세요.

# 저장소 루트에서 내용을 찾기 위한 읽기 전용 명령 예시
rg -n 'GetMe\(|Users.Get|MinimalUser' pkg/github/context_tools.go
rg -n 'GetMe\(' pkg/github/tools.go
rg -n 'Test_GetMe|ReadOnlyHint|IsError' pkg/github/context_tools_test.go

9관련 기술 심화 학습 로드맵

Go 문법이 처음이라면 1주차를 더 길게 잡아도 괜찮습니다. 한 번에 저장소 전체를 읽기보다, 매주 설명 가능한 요청 경로를 하나씩 늘리는 방식이 학습 진도를 확인하기 좋습니다. 시간은 학습 계획용 제안이며, 선수 지식에 따라 달라집니다.

9-1. 다음 단계는 관심 분야에 따라 고르기

• 백엔드: fetchIssueIDs에서 시작해 REST와 GraphQL을 섞는 도구 설계를 읽습니다.
• 에이전트 연동: ToolsetMetadata, 도구 설명, 최소 출력이 모델의 도구 선택에 주는 영향을 실험 설계로 정리합니다.
• 프론트엔드: ui/src/apps/issue-write/App.tsx의 입력 폼과 호스트 알림을 연결해 봅니다.
• 플랫폼: HTTP 요청별 의존성과 공유 스키마 캐시를 통해 여러 사용자 요청의 격리를 공부합니다.
• 보안: 콘텐츠 정제·작성자 정책·정보 흐름 라벨이 각각 놓치는 경우를 구분해 봅니다.

9-2. 스스로 답해 볼 마지막 질문

1. 도구 목록에 보이지만 실제 호출에서 권한 오류가 날 수 있는 이유는 무엇인가?
2. 도구 정의에는 토큰을 저장하지 않고 의존성은 요청 문맥에서 꺼내는 이유는 무엇인가?
3. 스키마·캐시·UI 결과 중 어떤 것은 공유하고 어떤 것은 요청마다 갱신해야 하는가?
4. 읽기 전용 표시나 스키마가 잘못 바뀌면 어떤 테스트가 이를 알려줄 수 있는가?

10핵심 키워드 사전

11참고 링크

11-1. 저장소·실행 방식·도구 설계

• GitHub 공식 저장소 · 프로젝트 개요와 현재 문서
• 커밋 f385262의 소스 트리 · 이 글의 코드 기준
• CLI 진입점과 설정 · 모드·기본값·인증 분기
• 로컬 서버 구성 · 클라이언트와 Inventory 조립
• HTTP 요청 처리 · 미들웨어와 상태 없는 전송
• GetMe 도구 구현 · 가장 먼저 따라갈 API 호출
• 의존성 인터페이스와 구현 · BaseDeps와 RequestDeps
• 도구 필터 · 공개 여부가 결정되는 순서
• Streamable HTTP 설명 · 인증 메타데이터·헤더·요청 상태
• 로컬 OAuth 로그인 · 브라우저 흐름과 대체 경로
• 테스트 지침 · 대역·행동 테스트·스냅샷
• MCP App React 훅 · 입력·결과·호스트 문맥 관리
• Go 의존성 · UI 잠금 파일 · 컨테이너 빌드
• v2.0.3 릴리스 · 버전별 배포물과 변경 설명

11-2. 관련 기술 공식 자료

• Go 공식 문서 · 언어·패키지·모듈의 기본 개념
• MCP Go SDK · 서버와 전송 계층 API
• MCP Apps 확장 · 도구 화면과 호스트의 연결
• GitHub REST API · 엔드포인트와 인증·응답 형식
• GitHub GraphQL API · 필드 선택과 질의·변경
• GitHub CLI · 터미널 중심의 다른 접근 방식
• React 공식 학습 자료 · 상태와 이벤트 처리
• TypeScript 공식 문서 · 타입과 컴파일 설정

현재 상태 (2026-10-23 확인)

활동 수치는 분석일의 GitHub 기준이며, 코드 규모와 구현 설명은 커밋 f385262 기준입니다. 최신 릴리스와 분석한 HEAD는 별개입니다. 이 글에서 본 기능·의존성이 모두 v2.0.3 배포물과 같다고 보장하지 않습니다.