Copilot CLI 사용법: 설치부터 테스트 수정·PR까지

GitHub Copilot CLI 설치와 로그인

GitHub의 안정 버전 npm 패키지인 @github/copilot을 설치하려면 Node.js 22 이상이 필요합니다. Windows에서는 PowerShell v6 이상도 필요합니다. 조직에서 제공하는 Copilot을 사용한다면 관리자가 Copilot CLI 정책을 활성화해야 합니다. 설치 요구 사항.

터미널에서 다음 명령어를 실행합니다.

npm install -g @github/copilot

~/.npmrc에 ignore-scripts=true가 설정되어 있다면 GitHub가 안내하는 대체 명령어는 npm_config_ignore_scripts=false npm install -g @github/copilot입니다. 공식 문서에는 Windows용 winget install GitHub.Copilot, macOS 또는 Linux용 brew install --cask copilot-cli와 curl -fsSL https://gh.io/copilot-install | bash도 나와 있습니다. Node.js 요구 사항은 npm으로 설치할 때 적용됩니다. GitHub 설치 명령어.

작업할 저장소로 이동한 뒤 copilot을 입력합니다. 해당 폴더를 이번 세션에서만 신뢰할지, 이후 세션에서도 신뢰할지 확인합니다. 로그인하지 않은 상태라면 안내에 따라 Copilot 안에서 /login을 입력합니다. 첫 실행 안내.

GitHub.com 또는 데이터 레지던시가 적용된 GitHub Enterprise Cloud 호스트 이름을 선택합니다. 로컬 데스크톱에서는 브라우저 로그인 방식을 선택하고, 원격 환경이나 화면이 없는 환경에서는 보통 기기 코드 방식이 먼저 제시됩니다. 브라우저에서 인증을 마치고, 관련 조직이 SAML SSO를 사용한다면 해당 조직의 접근 권한도 승인한 뒤 GitHub Copilot CLI 애플리케이션을 승인합니다. 로그인이 끝나면 터미널로 돌아옵니다. 셸에서 copilot login을 실행해 인증을 시작할 수도 있습니다. 인증 절차.

CLI가 다른 계정을 사용한다면 기존 COPILOT_GITHUB_TOKEN, GH_TOKEN, GITHUB_TOKEN 환경 변수를 확인합니다. 명시적으로 내보낸 토큰이 저장된 로그인 정보보다 우선합니다. 자동화에는 개인 계정의 세분화된 토큰을 사용할 수 있으며, Copilot Requests 계정 권한이 필요합니다. 클래식 개인 액세스 토큰은 지원하지 않습니다. 인증과 토큰 우선순위.

첫 작업은 코드 파악, 테스트 수정, PR 생성 순서로

먼저 질문하고, 검증할 수 있는 변경을 요청한 뒤, 풀 리퀘스트를 만듭니다. CLI를 같은 작업대에서 일하는 개발자로 생각하면 이해하기 쉽습니다. 프로젝트를 살펴보고 툴을 실행할 수 있지만, 어떤 행동을 허용할지는 사용자가 결정합니다.

아래 표는 셸에서 실행하는 명령어와 대화형 copilot 세션 안에서 입력하는 내용을 구분합니다. 명령어와 프롬프트는 모두 GitHub 공식 문서에 나오는 예시입니다. 모델과 상호작용할 때마다 AI 크레딧을 사용하며, GitHub는 이 작업들에 고정된 크레딧 가격을 제시하지 않습니다. CLI 과금 방식.

코드를 바꾸기 전에 저장소부터 파악합니다

낯선 프로젝트에 합류한 개발자라면 표의 설명 요청 명령어부터 실행해 볼 수 있습니다. GitHub 예시는 Claude Haiku 4.5를 선택합니다. -p는 프롬프트를 한 번 전송한 뒤 종료하고, -s는 부가 출력을 줄이며, --model은 사용할 모델을 지정합니다. 요금제나 정책 때문에 해당 모델을 쓸 수 없다면 대화형 세션에서 /model로 사용 가능한 모델을 선택합니다. Free와 Student 계정은 Auto 선택을 사용합니다. 프로그램 방식 실행 예시, 모델 접근 범위.

설명을 바탕으로 코드 진입점과 테스트 구성을 찾은 뒤, 해당 파일을 직접 확인합니다. 디렉터리를 막연히 훑는 대신, 검토하고 질문할 수 있는 구체적인 지도를 얻는 것이 이 작업의 가치입니다.

성공 기준이 분명한 테스트 수정부터 시작합니다

테스트가 깨진 상황이라면 저장소에서 실제로 사용하는 테스트 명령어를 실행하고, 실패 출력을 Copilot에 전달한 뒤 표의 대화형 프롬프트를 입력할 수 있습니다. GitHub는 실패하는 테스트를 작성하고 검토한 다음 단계로 이 문구를 제시합니다. 기존 테스트가 실패한 경우에도 같은 맥락을 제공해야 합니다. 어떤 테스트가 실패하는지, 어떤 동작을 유지해야 하는지 알려줍니다. 변경을 받아들이기 전에 diff를 검토하고 관련 테스트를 다시 실행합니다. GitHub 테스트 워크플로.

이미 생성된 풀 리퀘스트에 연결된 자동 검사인 CI에서 테스트가 실패한다면 GitHub가 안내하는 명령어는 **/pr fix ci focus on test failures**입니다. 로그를 조사하고 수정 사항을 적용하며 변경 내용을 푸시할 수도 있으므로, 로컬 테스트 수정과는 별도의 워크플로로 다뤄야 합니다. 현재 브랜치에 기존 PR이 있어야 합니다. CI 실패 수정.

변경을 검토한 뒤 풀 리퀘스트를 만듭니다

작은 수정 사항을 배포하려는 창업자라면 변경을 검토하고 커밋한 뒤 작업 브랜치에서 /pr create를 사용할 수 있습니다. GitHub에 호스팅된 Git 저장소 안에서 실행해야 합니다. Copilot은 로컬 커밋을 푸시하고, 저장소의 PR 템플릿에 맞춰 제목과 설명을 작성해 PR을 만듭니다. 해당 브랜치에 PR이 이미 있으면 이를 업데이트합니다. 풀 리퀘스트 생성.

팀이 이미 사용하는 GitHub 워크플로 안에서 검토 가능한 형태로 작업을 넘길 수 있습니다. 브랜치에 담긴 변경 내용에 대한 책임은 여전히 사용자에게 있습니다.

Copilot은 명령어 실행 전에 무엇을 확인하나요?

폴더 신뢰와 툴 사용 권한은 별도로 판단해야 합니다. 승인이 필요한 작업은 한 번만 허용하거나, 현재 세션 동안 해당 툴을 허용하거나, 거절하면서 피드백을 줄 수 있습니다. 세션 승인은 툴과 그 옵션을 포괄합니다. 승인 안내.

읽기 전용 작업은 자동으로 실행될 수 있습니다. 파괴적일 수 있는 작업, 쓰기 작업, URL 접근은 이미 허용한 경우가 아니라면 승인이 필요합니다. 일부 승인 안내에서는 저장소나 디렉터리에 대한 권한을 저장할 수 있습니다. 영구 승인한 URL 도메인은 이후 세션에도 적용됩니다. 저장된 권한.

GitHub가 제시하는 사전 권한 설정 예시는 다음과 같습니다.

copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

Git 명령어는 허용하되 푸시는 차단하는 설정입니다. 차단 규칙은 허용 규칙과 저장된 승인보다 우선합니다. /reset-allowed-tools는 현재 위치의 세션 승인과 저장된 툴 승인을 지우고, 실행 시점에 설정한 권한으로 되돌립니다. 허용·차단 규칙.

--allow-all-tools는 사용 가능한 모든 툴을 승인합니다. --allow-all 또는 --yolo는 모든 경로와 URL까지 승인합니다. GitHub는 이처럼 광범위한 승인을 격리된 환경에서 사용하도록 권장합니다. 처음 작업할 때는 기본 승인 절차를 유지합니다. 광범위한 권한 옵션.

GitHub Copilot 가격과 CLI 과금은 어떻게 되나요?

모든 Copilot 요금제에 CLI가 포함됩니다. Free, Student, Pro, Pro+, Max, Business, Enterprise가 모두 해당합니다. 기존 Copilot 시트에 별도의 CLI 구독을 추가할 필요는 없습니다. 아래는 GitHub 요금제 페이지에 나오는 현재 월 구독료와 제공량입니다. Copilot 요금제.

Flex는 변동되는 할당량이므로 현재의 총량이 영구적으로 보장되는 것은 아닙니다. AI 크레딧 한 개는 $0.01 USD에 해당합니다. 선택한 모델의 가격과 입력·출력·캐시 토큰 수에 따라 사용량이 결정됩니다. 채팅과 CLI는 같은 제공량을 사용합니다. 유료 요금제의 코드 자동 완성과 다음 편집 제안은 계속 무제한이며 AI 크레딧을 차감하지 않습니다. 개인 요금제 과금.

기존 Pro 구독자의 월 구독료는 $10으로 유지됩니다. 터미널에서 모델을 사용하는 작업은 현재 제공되는 1,500 크레딧을 다른 작업과 나눠 씁니다. 비용을 판단할 때 핵심은 이미 보유한 이용 권한으로 먼저 써 보고, 공유 크레딧이 실제 업무량을 감당하는지 확인하는 것입니다. 개인 유료 구독자는 추가 사용 예산을 설정하거나, 상위 요금제로 변경하거나, 월별 초기화까지 기다릴 수 있습니다. 공개 가격표상 Free에서는 추가 크레딧을 구매할 수 없습니다. 개인 제공량, Free 요금제 구매 제한.

Business와 Enterprise 크레딧은 과금 주체 단위로 통합 관리됩니다. 추가 유료 사용은 기본적으로 활성화되어 있으며 관리자가 비활성화할 수 있습니다. 다른 제공량이 남아 있어도 사용자 예산이나 엔터프라이즈 지출 한도에 도달하면 접근이 중단될 수 있습니다. GitHub는 과금과 사용량을 정확하게 표시하려면 CLI 1.0.48 이상을 사용하도록 권장합니다. 조직 과금.

작업을 마친 뒤 /usage로 세션 크레딧과 모델 토큰 사용량을 확인합니다. 대화형 세션에서는 /limits set max-ai-credits NUMBER의 NUMBER를 원하는 제공량으로 바꿔 한도를 설정할 수 있습니다. 최솟값은 30 크레딧입니다. 이 기능은 공개 프리뷰이며 소프트 한도로 작동합니다. 진행 중인 응답은 끝까지 처리되므로 한도를 조금 넘길 수 있습니다. 사용량 표시, 세션 한도.

Copilot CLI에서 어떤 모델을 사용할 수 있나요?

Copilot 안에서 **/model**을 입력하면 선택 가능한 모델을 확인할 수 있고, 셸에서 실행할 때는 --model로 지정합니다. GitHub의 현재 클라이언트 표에는 아래 모델이 CLI 지원 모델로 표시되어 있습니다. 요금제와 관리자 정책에 따라 실제 이용 범위는 좁아질 수 있습니다. 지원 모델.

GitHub가 별도로 제공하는 CLI Auto 표에는 GPT-6.1 Sol도 포함되어 있습니다. Free와 Student는 Auto만 사용할 수 있습니다. 지원 범위는 바뀔 수 있으므로 계정의 현재 선택지는 모델 선택기에서 확인합니다. Auto와 요금제별 이용 범위.

프로젝트 지침과 MCP 툴을 추가하는 방법

변경을 반복해서 요청하기 전에 저장소의 작업 규칙부터 작성합니다. 사용자 지정 지침은 Copilot이 맥락으로 읽는 Markdown 파일입니다. 프로젝트 전체의 빌드 명령어, 테스트 명령어, 작업 관례는 .github/copilot-instructions.md에 작성합니다. 특정 경로에 적용할 규칙은 .github/instructions/**/*.instructions.md에 작성하고 applyTo 패턴을 사용합니다. 사용자 지정 지침.

CLI는 AGENTS.md, CLAUDE.md, .claude/CLAUDE.md, GEMINI.md도 찾아 읽습니다. 사용자 전체에 적용할 설정은 ~/.copilot/copilot-instructions.md 또는 ~/.copilot/instructions/**/*.instructions.md에 둘 수 있습니다. 적용 대상인 지침은 함께 사용되며, GitHub는 지침 간의 일반적인 우선순위를 정해 두지 않았습니다. 서로 충돌하지 않게 작성하고, /instructions로 발견된 파일을 확인하거나 비활성화합니다. 지침 탐색과 상호작용.

MCP(Model Context Protocol)는 에이전트를 외부 툴과 데이터에 연결합니다. 작업대에 서비스 연결을 추가한다고 생각하면 됩니다. GitHub MCP 서버는 이미 내장되어 있습니다. 다른 서버를 추가하려면 /mcp add를 입력하고, Tab으로 입력란을 이동한 뒤 Ctrl+S로 저장합니다. 로컬 또는 stdio 서버는 프로세스를 실행하고, HTTP 서버는 원격 엔드포인트에 연결합니다. 기존 SSE 방식도 지원합니다. MCP 서버 추가.

GitHub의 터미널 예시는 copilot mcp add --transport http sentry https://mcp.sentry.dev/mcp입니다. 사용자 설정은 ~/.copilot/mcp-config.json에 저장하며, 프로젝트 설정에는 .mcp.json 또는 .github/mcp.json을 사용할 수 있습니다. MCP 전용 가이드에 따르면 조직에 설정된 레지스트리와 허용 목록 정책은 CLI에도 적용됩니다. 터미널 예시, 설정과 정책.

CLI, IDE, 다른 에이전트 중 무엇을 선택해야 하나요?

저는 작업이 이미 터미널 중심이고 Copilot 시트를 보유하고 있다면 Copilot CLI부터 시작할 것을 권합니다. 편집 중인 파일 옆에서 작업하고, 변경 내용을 시각적으로 확인하며, 에디터 안에 머물고 싶다면 IDE 확장을 선택합니다. 에디터 선택에는 Cursor와 GitHub Copilot 비교가 도움이 됩니다.

첫 작업에 익숙해진 뒤에는 다음과 같은 활용도 생각해 볼 수 있습니다.

• 리뷰를 준비하는 메인테이너는 작업 브랜치의 코드 리뷰를 요청하고, 발견된 문제를 조사한 뒤, diff를 사람 리뷰어에게 전달할 수 있습니다. 발견 사항을 검증할 수 있다면 검토할 지점을 좁힌 체크리스트를 얻을 수 있습니다. GitHub는 로컬 리뷰 워크플로를 문서로 안내합니다. 리뷰 가이드.
• PR 피드백을 반영하는 개발자는 /pr fix feedback을 사용하고, 제안된 수정 사항을 살펴본 뒤, 그에 따른 푸시를 승인할 수 있습니다. 수정 요청과 논의를 한곳에서 이어 갈 수 있다는 장점이 있습니다. 이 명령어는 처리한 리뷰 스레드에 답변하고 해결 상태로 바꿀 수도 있으므로 승인 전에 범위를 확인합니다. 피드백 처리 워크플로.

다른 구독 제공량이나 제공사 구성, 에이전트 자체에 대한 제어가 필요하다면 다른 터미널 에이전트를 고려합니다. 구독을 결정할 때는 Claude Code 대안과 터미널 비용 비교를 참고할 수 있습니다. 먼저 Copilot 자체의 모델 선택지가 요구 사항을 충족하는지 확인합니다. GitHub는 호환되는 로컬 모델을 포함해 사용자가 직접 제공사를 연결하는 방법도 안내합니다. 이 방식은 별도의 제공사 설정이 필요하고 툴 호출과 스트리밍을 지원해야 하며, Copilot 제공량을 사용하는 구성과는 다릅니다. 자체 모델 연결.

소규모 팀이라면 어떤 서비스를 만들 수 있을까요?

저장소 온보딩 패키지가 가장 유망한 출발점입니다. 개발자들은 “how to understand a new codebase”나 “ai tool to understand codebase.” 같은 검색어로 정보를 찾습니다. 팀은 아키텍처 노트, 검증된 빌드 지침, 범위가 명확한 온보딩 작업을 꾸준히 관리하는 패키지로 묶어 엔지니어링 리더에게 판매할 수 있습니다. 최소한의 유용한 버전이라면 고객의 저장소를 대상으로 코드 설명, 테스트, PR 워크플로를 보여 줘야 합니다. 다만 범용 프롬프트는 쉽게 복제됩니다. 구매자가 비용을 지불할 대상은 지속적으로 관리되는 프로젝트 지식입니다.

리뷰 준비 워크플로도 가능합니다. “ai code review tools”, “ai powered code review platform” 같은 검색어는 이 수요를 보여 줍니다. 프로젝트 지침과 연결된 이슈 맥락을 묶어 변경 사항, 테스트 근거, 미해결 질문을 담은 리뷰 자료를 만드는 서비스입니다. 작업 인계 방식을 표준화하려는 팀 리더가 구매자가 될 수 있습니다. 다만 생성된 발견 사항은 검증해야 하고, GitHub의 기존 리뷰 기능과 함께 사용할 만큼 가치가 있어야 합니다. 이는 제품 아이디어이며, 입증된 성과는 아닙니다.

도입 전에 알아둘 한계

CLI는 그럴듯하지만 잘못된 변경을 만들 수 있습니다. GitHub의 책임 있는 사용 가이드는 생성 결과가 부정확하거나 불완전할 수 있다고 설명하며, CLI가 만든 코드와 명령어를 검증하도록 안내합니다. 관련 테스트를 통과시키고 diff를 검토하는 과정은 여전히 필요합니다. 책임 있는 사용.

폴더를 신뢰한다고 격리가 보장되는 것은 아닙니다. GitHub는 디렉터리 권한 범위 설정이 휴리스틱에 기반하며, 신뢰하는 디렉터리 밖의 모든 파일을 보호한다고 보장하지 않습니다. 작업하려는 저장소 안에서 시작합니다. 더 엄격한 제한이 필요하면 /sandbox enable로 툴의 로컬 샌드박싱을 활성화합니다. GitHub의 로컬·클라우드 샌드박스는 공개 프리뷰입니다. 디렉터리 신뢰와 샌드박싱.

이용 권한과 지출 한도도 그대로 적용됩니다. 문서에 나오는 모델이라도 현재 요금제에서 사용할 수 없거나 정책으로 비활성화되어 있을 수 있습니다. CLI는 다른 Copilot 작업과 크레딧을 공유하며, 프리뷰 세션 한도는 조금 초과될 수 있습니다. 조직 예산에 도달하면 더 저렴한 모델로 자동 전환되지 않은 채 사용이 중단될 수 있습니다. 모델 접근 범위, 세션 한도, 예산 적용 방식.

다음 작업 세션에서는 검토할 수 있는 브랜치에서 실제로 실패하는 테스트를 하나 고릅니다. 관련 코드를 설명하게 하고, 수정에 필요한 툴 요청을 승인한 뒤, 테스트를 다시 실행합니다. /usage를 확인하고 PR을 생성합니다. 이렇게 하면 워크플로가 업무에 맞는지, 사용량은 어느 정도인지 구체적으로 판단할 수 있습니다.

팀의 검사 절차와 연결된 툴을 바탕으로 저장소 워크플로를 구축하고 싶다면 AI 자동화 개발 서비스를 이용할 수 있습니다.