Copilot SDK GA, GitHub 에이전트를 앱에 넣는 API

AI 요약

• 무슨 일: GitHub가 2026년 6월 2일 Copilot SDK를 일반 제공으로 전환했습니다.
  • 지원 언어는 Node.js/TypeScript, Python, Go, .NET, Rust, Java 6개입니다.
• 제품 변화: Copilot의 planning, tool invocation, file edits, streaming, multi-turn session을 자체 앱에서 호출할 수 있습니다.
• 실무 체크: MCP, hooks, OpenTelemetry, BYOK가 붙었습니다. Copilot CLI server와 premium request 과금 경계는 확인해야 합니다.
• 의미: GitHub는 Copilot을 IDE 기능에서 외부 개발자 도구가 호출하는 에이전트 런타임으로 확장합니다.

GitHub가 Copilot을 IDE 안의 조수에서 외부 앱이 호출하는 에이전트 런타임으로 확장했습니다. GitHub Changelog는 2026년 6월 2일 Copilot SDK가 일반 제공 상태가 됐다고 공지했습니다. 공지의 첫 문장은 개발자가 GitHub Copilot의 agentic engine을 자체 애플리케이션, 서비스, 개발자 도구에 안정 API와 production-ready support로 임베드할 수 있다고 설명합니다.

이번 발표는 Copilot 앱이나 Copilot CLI처럼 사용자가 직접 보는 새 화면보다 낮은 층에 있습니다. SDK가 여는 것은 Copilot의 planning, tool invocation, file edits, streaming, multi-turn sessions입니다. 개발자가 자체 CLI, 내부 포털, CI/CD assistant, 사내 리뷰 도구를 만들 때 agent loop를 직접 구현하지 않고 Copilot 런타임을 호출하는 경로가 생긴 것입니다.

GitHub가 공개한 지원 언어는 Node.js/TypeScript, Python, Go, .NET, Rust, Java 6개입니다. Changelog는 Rust와 Java를 GA 시점에 새로 붙은 항목으로 표시했습니다. 설치 명령도 언어별로 공개됐습니다. TypeScript는 npm install @github/copilot-sdk, Python은 pip install github-copilot-sdk, Go는 go get github.com/github/copilot-sdk/go를 씁니다. .NET은 dotnet add package GitHub.Copilot.SDK, Rust는 cargo add github-copilot-sdk, Java는 Maven과 Gradle 경로를 씁니다.

지원 언어 목록은 단순한 포팅 숫자가 아닙니다. Copilot이 VS Code와 GitHub UI 중심 제품이면 TypeScript만으로도 많은 실험을 감당할 수 있습니다. SDK가 내부 개발자 플랫폼, 보안 도구, 배포 파이프라인, legacy enterprise 앱에 들어가려면 Python, Go, .NET, Java가 필요합니다. Rust 지원은 CLI 배포와 로컬 실행 경계를 다루는 팀에게 신호가 됩니다.

GitHub repository README는 아키텍처를 더 노골적으로 보여줍니다. 모든 SDK는 Copilot CLI server와 JSON-RPC로 통신합니다. 사용자의 애플리케이션이 SDK client를 부르고, SDK client가 JSON-RPC로 Copilot CLI의 server mode를 호출하는 구조입니다. SDK가 CLI process lifecycle을 관리할 수 있고, 외부 CLI server에도 연결할 수 있습니다.

이 구조는 장점과 제약을 동시에 만듭니다. 장점은 GitHub가 이미 제품에서 굴리는 CLI agent runtime을 그대로 재사용한다는 점입니다. SDK 사용자는 planner, tool loop, file edit 처리, multi-turn session을 새로 설계하지 않아도 됩니다. 제약은 Copilot SDK가 순수 라이브러리만으로 끝나는 형태가 아니라 CLI server와 프로세스 관리, 인증, 버전 호환성을 함께 봐야 하는 제품이라는 점입니다.

README의 "Quick steps"도 이 경계를 확인합니다. Node.js, Python, .NET SDK는 Copilot CLI가 자동 번들링돼 별도 설치가 필요 없다고 적습니다. Go, Java, Rust는 Copilot CLI를 수동 설치하거나 copilot이 PATH에 있어야 합니다. Go와 Rust는 애플리케이션 수준 CLI bundling 기능도 노출한다고 설명합니다. 사내 도구에 넣을 때는 배포 대상 OS, CLI binary update, 보안 스캐닝, 네트워크 정책이 SDK 선택과 같이 움직입니다.

Copilot SDK의 기능 목록은 에이전트 앱을 만들 때 필요한 운영면을 겨냥합니다. Changelog는 custom tools와 MCP, fine-grained system prompt customization, OpenTelemetry tracing, flexible authentication, cloud and remote sessions, hook system을 핵심 기능으로 적었습니다. 여기서 MCP는 외부 도구 연결, hooks는 tool use 전후와 permission request를 가로채는 정책 지점, tracing은 production debugging의 출발점입니다.

MCP 지원은 Copilot SDK가 다른 에이전트 프레임워크와 경쟁하는 지점입니다. LangChain이나 Vercel AI SDK처럼 tool abstraction을 직접 설계하는 경로와 달리, GitHub는 Copilot이 이미 쓰는 agent runtime에 MCP server 연결과 built-in tool override를 붙입니다. 사내 플랫폼 팀은 기존 Jira, PagerDuty, Datadog, internal deploy tool을 MCP 또는 custom tool로 붙이고, permission handler에서 허용 범위를 좁히는 방식으로 접근할 수 있습니다.

fine-grained system prompt customization도 눈에 띕니다. Changelog는 identity, tone, tool instructions, safety rules 같은 개별 섹션을 수정할 수 있다고 적습니다. 전체 system prompt를 새로 쓰는 방식은 모델 업데이트와 충돌하기 쉽습니다. 반대로 섹션 단위 수정은 Copilot 기본 동작을 유지하면서 회사의 코드 스타일, 보안 규칙, 리뷰 언어, 금지 도구를 덧붙이는 쪽에 가깝습니다.

OpenTelemetry는 이번 GA에서 과소평가하기 어려운 항목입니다. GitHub Docs의 SDK 튜토리얼은 telemetry config를 client 생성 시 넘기면 CLI process trace export와 SDK, CLI 사이의 W3C Trace Context propagation을 사용할 수 있다고 설명합니다. 예시는 OTLP endpoint와 local JSON-lines file export를 모두 다룹니다. 에이전트가 파일을 읽고, 셸을 실행하고, 외부 API를 호출하는 제품에서는 "왜 이 답이 늦었나"보다 "어느 tool call이 실패했고 어느 permission request가 막혔나"를 추적해야 합니다.

다만 telemetry는 보안 질문도 같이 만듭니다. Docs는 message content capture 옵션을 표로 보여줍니다. AI agent trace에는 prompt, 파일 경로, diff, tool argument, error log가 섞일 수 있습니다. 내부 개발자 도구에 Copilot SDK를 붙이는 팀은 trace sampling, content capture 기본값, OTLP endpoint 보존 기간, 민감 저장소에서의 export 금지를 별도 정책으로 정해야 합니다.

BYOK는 Copilot SDK의 시장 위치를 넓히는 기능입니다. README FAQ는 표준 사용에는 GitHub Copilot 구독이 필요하지만, BYOK를 쓰면 GitHub authentication 없이 지원 LLM provider API key로 SDK를 사용할 수 있다고 설명합니다. 예시 provider에는 OpenAI, Azure AI Foundry, Anthropic이 들어갑니다. 같은 FAQ는 Microsoft Entra ID, managed identities, third-party identity providers는 BYOK에서 지원하지 않는다고 못박습니다.

BYOK가 있다고 해서 과금 질문이 사라지는 것은 아닙니다. README는 SDK usage billing이 Copilot CLI와 같은 모델이고 각 prompt가 premium request quota에 계산된다고 설명합니다. BYOK에서는 provider 쪽 비용이 따로 생길 수 있습니다. 2026년 6월 1일 GitHub Copilot이 사용량 기반 과금으로 전환된 직후라, SDK를 제품에 넣는 팀은 사용자당 prompt budget, 모델별 quota, BYOK가 premium request와 어떻게 상호작용하는지 계약 문서와 관리자 화면에서 확인해야 합니다.

이 지점에서 Copilot SDK는 "개발자 경험 기능"보다 "플랫폼 조달 항목"에 가까워집니다. 개인 개발자는 SDK로 작은 CLI assistant를 만들 수 있습니다. 기업은 다릅니다. 내부 앱에 Copilot 런타임을 심으면 인증 주체, repository access, agent tool permission, audit log, model selection, billing owner가 함께 따라옵니다. GitHub가 GitHub Apps, environment tokens, OAuth, BYOK를 모두 언급한 이유도 이 배포면이 넓기 때문입니다.

GitHub의 같은 날 발표들과 나란히 보면 의도가 더 선명합니다. 6월 2일 Changelog에는 Copilot SDK GA 외에도 cloud and local sandboxes public preview, agent apps, /chronicle이 올라왔습니다. 같은 목록에는 cloud agent scheduling, Copilot Memory, Gemini models in Copilot도 들어갔습니다. 최근 Copilot은 "IDE 채팅" 하나가 아니라 app, CLI, cloud agent, code review, marketplace agent, SDK를 묶은 실행면으로 재편되고 있습니다.

Cloud and local sandboxes 발표는 SDK와 직접 같은 제품은 아니지만, 에이전트 런타임을 외부화할 때 필요한 안전장치입니다. GitHub는 Copilot이 로컬과 클라우드의 isolated sandbox 안에서 도구 실행을 할 수 있다고 설명했습니다. 로컬 sandbox는 /sandbox enable로 세션의 shell command execution을 filesystem, network, system capabilities 제한 안에 둡니다. Cloud sandbox는 copilot --cloud로 GitHub가 호스팅하는 ephemeral Linux sandbox를 띄웁니다.

이 실행 경계는 SDK 도입에도 영향을 줍니다. 자체 앱에서 Copilot agent runtime을 호출할 수 있다면, 에이전트가 어느 머신에서 명령을 실행하는지, 어느 저장소를 볼 수 있는지, 어느 네트워크에 나갈 수 있는지가 다음 질문입니다. GitHub가 sandbox, SDK, agent apps를 같은 날짜에 발표한 것은 우연한 묶음보다 실행 권한을 제품 단위로 나누는 설계에 가깝습니다.

Agent apps 발표도 같은 방향입니다. GitHub는 agent apps를 GitHub Marketplace에서 설치하는 AI agents로 설명했습니다. 첫 wave에는 Amplitude, Bright Security, Endor Labs, LaunchDarkly, Miro, Sonar, PagerDuty, Packfiles, Octopus Deploy가 들어갔습니다. 사용자는 issue assign, pull request comment mention, Agents UI prompt로 외부 agent를 GitHub workflow 안에 부를 수 있습니다. SDK는 이런 agent가 GitHub 밖의 앱과 내부 도구에서도 Copilot runtime을 호출하게 만드는 하부 경로로 볼 수 있습니다.

경쟁 구도는 빠르게 복잡해집니다. OpenAI Codex는 앱과 CLI, 원격 실행, computer use, Sites preview로 개발 워크플로를 넓히고 있습니다. Anthropic Claude Code는 CLI 중심의 장기 작업과 SDK, managed policy, enterprise deployment로 확장합니다. Microsoft는 Agent Framework와 Foundry, GitHub Copilot, Windows sandbox 계열을 묶습니다. GitHub Copilot SDK의 차별점은 GitHub issue, PR, code review, Actions, Copilot CLI에서 이미 발생하는 개발 작업의 중심에 붙어 있다는 점입니다.

개발자 도구 회사 입장에서는 선택지가 늘었습니다. 자체 agent runtime을 만들면 모델 provider 선택, tool loop, context packing, patch application, permission UI, tracing을 모두 직접 책임집니다. Copilot SDK를 쓰면 GitHub 런타임과 Copilot 과금, CLI server, GitHub 정책을 받아들입니다. LangChain, Vercel AI SDK, OpenAI Responses API, Claude Code SDK 같은 경로는 더 낮은 수준의 모델·도구 제어를 주지만, Copilot의 GitHub-native workflow와는 다른 비용을 요구합니다.

초기 도입에 적합한 사용처는 사내 개발자 포털과 반복형 코드 작업입니다. 예를 들어 "서비스 이름을 입력하면 관련 repository를 찾고, migration checklist를 만들고, PR template을 채운다"는 내부 도구는 Copilot SDK와 custom tool 조합으로 만들 수 있습니다. CI/CD assistant는 실패 로그를 읽고, 담당 repository의 최근 변경을 보고, 재현 명령을 제안할 수 있습니다. 보안팀은 Bright Security나 Endor Labs 같은 agent app과 별개로 자체 policy checker를 Copilot SDK tool로 붙일 수 있습니다.

반대로 무리한 사용처도 있습니다. 사용자가 작성한 prompt를 곧바로 production deploy tool에 연결하거나, permission handler 없이 file edit과 shell execution을 허용하거나, trace content를 통째로 외부 observability endpoint에 보내는 방식은 위험합니다. README는 기본적으로 Copilot CLI의 first-party tools를 노출할 수 있고 tool execution은 SDK permission handler가 지배한다고 설명합니다. 제품 설계자는 이 permission handler를 단순 confirm dialog가 아니라 정책 엔진으로 봐야 합니다.

문서 상태도 확인해야 합니다. 검색 결과의 일부 GitHub Docs 페이지에는 "public preview" 문구가 남아 있었고, Changelog와 repository README는 GA와 semantic versioning을 말합니다. 이는 문서 전환이 발표 직후 완전히 정리되지 않았을 가능성이 있습니다. 실제 도입 전에는 현재 사용하려는 언어 SDK의 README, package version, changelog, docs 페이지가 모두 같은 상태를 가리키는지 확인해야 합니다.

한국 개발자에게 이 발표가 주는 가장 실용적인 질문은 "우리가 에이전트 기능을 직접 만들 것인가, Copilot 런타임을 제품 안에 넣을 것인가"입니다. VS Code 안에서 Copilot을 쓰는 경험과, 사내 시스템에서 Copilot SDK를 호출하는 경험은 권한 모델이 다릅니다. 후자는 사용자가 어느 GitHub identity로 실행되는지, agent가 어느 repository context를 받는지, tool call이 어느 감사 로그에 남는지를 설계해야 합니다.

이번 GA의 제목은 SDK지만, GitHub가 실제로 연 것은 Copilot의 배포면입니다. IDE, CLI, 앱, cloud agent, marketplace agent, SDK가 같은 주에 같은 Changelog 안에서 나열됐습니다. Copilot은 코드 자동완성 제품에서 "개발 작업을 실행하는 에이전트 런타임"으로 이동하고 있습니다. SDK는 그 런타임을 GitHub 바깥의 앱과 내부 도구가 호출하는 API입니다.

앞으로 볼 지표는 네 가지입니다. 첫째, SDK 사용량이 Copilot premium request 과금에서 얼마나 투명하게 분리되는지입니다. 둘째, BYOK가 enterprise identity와 audit requirement를 충분히 만족하는지입니다. 셋째, CLI server와 SDK version mismatch가 production app에서 얼마나 자주 문제가 되는지입니다. 넷째, GitHub가 SDK 기반 앱과 Marketplace agent apps 사이의 개발자 경로를 어떻게 연결하는지입니다.

Copilot SDK GA는 화려한 데모보다 운영 질문이 많은 발표입니다. 그러나 developer tools 시장에서는 이런 발표가 더 오래 남습니다. 에이전트 앱을 직접 만들려는 팀이 늘수록 모델 호출보다 권한, 도구, trace, 비용, 배포가 병목이 됩니다. GitHub는 그 병목을 Copilot 런타임으로 묶어 팔기 시작했습니다. 이제 비교 대상은 "어느 모델이 코드를 더 잘 쓰는가"만이 아니라 "어느 런타임이 조직의 개발 작업 안에서 안전하게 실행되는가"입니다.