github-copilot-cli

15 개의 포스트

github

GitHub 법무팀이 Copilot CLI를 활용해 업무 흐름을 간소화한 방법 (새 탭에서 열림)

GitHub 법무팀은 엔지니어가 아니어도 Copilot CLI를 활용해 반복적인 법무 업무를 자동화하고, 자신의 판단 기준을 반영한 도구를 직접 만들 수 있음을 보여준다. 계약서 작성·검토와 DMCA 통지 분석 같은 업무를 평문 지침, 정책 자료, 템플릿으로 구조화해 일관성과 처리 속도를 높였다. 다만 AI는 법률적 판단을 대체하는 것이 아니라, 사람이 최종 검토하는 의사결정 지원 시스템으로 활용됐다. ## 반복 업무를 AI 도구로 전환한 배경 - 법무팀의 업무에는 유사 계약 검토, 반복적인 법률 질의 응답, 기존 가이드 재활용 등 반복 작업이 많았다. - 구성원들은 전통적인 프로그래밍 경험이 부족했지만, 자신의 업무 방식과 판단 기준은 명확히 알고 있었다. - Copilot CLI에 자연어로 원하는 기능을 설명하고 저장소와 연결하면서, 프롬프트를 일회성으로 사용하는 대신 재사용 가능한 내부 도구로 발전시켰다. - 지침과 자료를 저장소에서 관리해 버전 관리, 일관성 확보, 협업이 가능해졌다. ## `terms-ai`: 계약 작성 스타일 가이드 구축 - Ngandu Kasuku는 데이터·인프라·제품 통합 관련 파트너십 계약이 급증하자 계약 작성 도구 `terms-ai`를 만들었다. - 저장소에 다음 자료를 정리했다. - AI 작업 지침 - 계약 작성 리소스 - 업무 흐름 - 기존에 승인된 계약서 - 평문 중심의 계약 작성 원칙을 내부 스타일 가이드로 만들었다. - 불필요하게 고어체인 법률 용어를 줄임 - 더 명확하고 읽기 쉬운 문장 사용 - 계약 전반에 동일한 문체와 기준 적용 - 기존 파트너와의 과거 계약 및 승인된 문서를 참고해 새 계약서나 부속합의서 초안을 작성할 수 있게 했다. - 민감한 계약서와 내부 정보는 공개 저장소에 포함하지 않고, 접근 제어가 적용된 내부 환경에 보관했다. - 결과적으로 계약 검토와 작성 시간이 약 절반으로 줄었고, 조항의 일관성과 개인의 작성 스타일 반영 수준이 향상됐다. - 핵심은 AI가 단순히 초안을 생성한 것이 아니라, 변호사의 경험과 판단 방식을 도구에 내장했다는 점이다. ## DMCA 통지 분석을 위한 평문 기반 워크플로 - Jesse Geraci는 DMCA 통지를 처리하기 위해 소스 코드를 빠르고 정확하게 분석해야 하는 문제에서 출발했다. - 처음에는 팀원들이 각자 작성하던 일회성 프롬프트를 다음과 같은 반복 가능한 지침으로 정리했다. - DMCA 통지 분류 - 코드 비교 - 라이선스 확인 - 우회 행위 검토 - 분석 결과 보고서 작성 - 전통적인 소스 코드 대신 다음과 같은 평문 파일을 중심으로 워크플로를 구성했다. - 업무 절차 지침 - 정책 및 법률 참고 자료 - 보고서 템플릿 - 변호사가 가진 언어 구성 능력과 법률적 방법론을 구조화된 업무 로직으로 활용했다. - 고객용과 변호사용 분석 모드를 분리했다. - 고객용: 빠른 결과와 에스컬레이션 권고 제공 - 변호사용: 심층 검토와 양측 주장 분석 제공 - 외부 데이터 소스를 연동하면서 팀이 재사용할 수 있는 표준 워크플로로 확장됐다. ## 데스크톱 앱과 재사용 가능한 법무 에이전트 - 초기 평문 워크플로는 이후 사전 정의된 법무 작업을 실행하는 데스크톱 앱으로 발전했다. - 앱 자체를 구축하려면 상당한 코드가 필요했지만, 실제 업무 동작을 바꾸는 지침은 여전히 Markdown과 자연어로 편집할 수 있다. - DMCA 코드 분석을 넘어 다음 업무로 범위가 확대됐다. - 계약서 검토 - NDA 분류 - 위험 평가 - 컴플라이언스 점검 - 답변 초안 작성 - 내부적으로는 다음과 같은 재사용 가능한 스킬과 에이전트로 업무를 나눌 수 있다. - 접수 및 초기 분류 - 플레이북 기준 대조 - 위험 점수 산정 - 증거 검증 - 에스컬레이션 경로 결정 - 보고서 조립 - 기술적 구현이 복잡해져도 법무팀은 읽기 쉬운 Markdown을 통해 AI의 동작과 기준을 직접 통제할 수 있다. ## 인간의 법률 판단을 중심에 둔 AI 활용 - 법무 Copilot은 변호사를 대체하는 시스템이 아니라 구조화된 의사결정 지원 도구다. - AI 활용의 목적은 다음과 같다. - 법률 분석의 일관성 향상 - 판단 과정의 투명성 확보 - 반복 업무의 확장성 강화 - 사람이 중요한 쟁점과 최종 판단에 집중하도록 지원 - 조직은 완벽한 상용 솔루션이나 전문 개발자를 기다리지 않고, 먼저 자신의 방법론·기준·결과 형식을 명확히 정의할 수 있다. 작게는 반복되는 계약 검토나 자료 분류처럼 시간을 가장 많이 빼앗는 업무 하나를 골라, 자연어 지침과 내부 자료를 재사용 가능한 워크플로로 정리하는 것이 현실적인 시작점이다. 단, 민감한 자료에는 접근 제어를 적용하고, AI 결과는 반드시 담당자의 검토와 승인을 거치도록 설계해야 한다.

github

초보자를 위한 GitHub Copilot CLI: 자주 사용하는 슬래시 명령어 개요 (새 탭에서 열림)

GitHub Copilot CLI의 슬래시 명령은 모델 선택, 컨텍스트 관리, 세션 재개, 변경 사항 확인 등을 터미널에서 직접 수행하게 해주는 핵심 제어 기능이다. `/`를 입력하면 사용 가능한 명령 목록을 확인할 수 있으며, 각 명령을 익히면 작업 흐름과 권한을 더 효율적으로 관리할 수 있다. 특히 모델과 토큰 사용량을 상황에 맞게 조절하면 속도와 결과 품질을 균형 있게 유지할 수 있다. ## 슬래시 명령의 역할 - 슬래시 명령은 Copilot CLI에 내장된 제어 기능이다. - Copilot의 동작을 지시하고, 변경 사항과 컨텍스트를 확인하며, 세션과 프로젝트를 관리한다. - 터미널에서 `/`를 입력하면 현재 지원되는 명령을 스크롤 목록으로 확인할 수 있다. ## 작업에 맞는 모델 선택: `/model` - `/model`을 입력하면 사용 가능한 모델 목록이 표시된다. - 모델마다 적합한 작업이 다르다. - 간단한 리팩터링이나 빠른 작업에는 가벼운 모델이 적합하다. - 기능 설계나 복잡한 추론에는 더 강력한 모델이 유리하다. - 모델 목록은 사용 중인 요금제나 조직 설정에 따라 달라질 수 있다. - 각 모델 옆의 비용 배수는 사용량과 비용 수준을 비교하는 기준이 된다. - 작업의 복잡도와 속도, 비용을 고려해 모델을 선택해야 한다. ## 컨텍스트와 토큰 관리 ### 현재 사용량 확인: `/context` - `/context`는 현재 세션의 컨텍스트 사용량을 보여준다. - 남은 토큰 수, 시스템이 사용하는 공간, 추가로 활용 가능한 버퍼를 확인할 수 있다. - 컨텍스트 창이 가득 차면 Copilot이 이전 대화와 정보를 충분히 참고하기 어려워진다. ### 대화 압축: `/compact` - `/compact`는 현재 대화를 요약해 컨텍스트 공간을 확보한다. - 기존 세션을 유지하면서 새로운 작업으로 넘어갈 때 유용하다. - 컨텍스트 한도에 가까워지면 Copilot CLI가 자동으로 압축할 수 있지만, 사용자가 직접 실행할 수도 있다. ### 세션 초기화: `/clear` - `/clear`는 현재 세션을 완전히 지운다. - 이전 대화의 영향을 받지 않고 새로운 작업을 시작할 때 사용한다. ## 이전 세션 재개: `/resume` - `/resume`은 과거에 진행한 세션 목록을 표시한다. - 로컬 세션과 원격 세션을 모두 확인할 수 있다. - 세션을 선택하면 이전 작업 기록을 검토한 뒤 중단한 지점부터 작업을 이어갈 수 있다. ## 변경 사항 확인: `/diff` - `/diff`는 현재 세션에서 발생한 최근 변경 사항을 보여준다. - Copilot이 수정한 파일을 검토하고, 의도하지 않은 변경이 없는지 확인하는 데 사용한다. - 변경 내용을 검증한 뒤 커밋이나 다음 작업으로 넘어가는 것이 좋다. ## 작업 디렉터리 변경: `/cwd` - `/cwd`를 사용하면 Copilot을 종료하지 않고 다른 저장소나 디렉터리로 이동할 수 있다. - 여러 프로젝트를 오가며 작업할 때 편리하다. - Copilot의 작업 범위를 현재 선택한 프로젝트에 맞게 조정할 수 있다. ## 도구 권한 초기화: `/reset-allowed-tools` - `/reset-allowed-tools`는 이전에 허용한 파일 수정 등의 도구 권한을 초기화한다. - 신뢰 수준이 다른 저장소로 이동했을 때 기존 권한을 재설정하는 데 유용하다. - 민감한 프로젝트를 다룰 때 권한을 다시 확인하는 안전 장치로 활용할 수 있다. ## 실용적인 활용 방법 - 작업을 시작하기 전에 `/`를 입력해 사용 가능한 명령을 확인한다. - 복잡한 기능 설계에는 `/model`로 추론 능력이 높은 모델을 선택한다. - 컨텍스트가 부족해지면 `/context`로 상태를 확인하고 `/compact`를 실행한다. - Copilot이 코드를 수정한 뒤 `/diff`로 변경 내용을 검토한다. - 다른 프로젝트로 이동할 때는 `/cwd`, 권한을 정리해야 할 때는 `/reset-allowed-tools`를 사용한다. - 슬래시 명령을 익히면 Copilot CLI를 단순한 코드 생성 도구가 아니라 세션·컨텍스트·권한을 통제하는 작업 환경으로 활용할 수 있다.

github

GitHub Copilot CLI가 작업 위임을 더 선별적으로 하도록 만든 방법 (새 탭에서 열림)

GitHub는 Copilot CLI가 단순한 작업까지 불필요하게 서브에이전트에 위임해 발생하던 검색 반복, 도구 실패, 대기 시간을 줄이기 위해 위임 정책을 개선했다. 핵심은 좁고 명확한 작업은 메인 에이전트가 직접 처리하고, 독립적인 탐색·복잡한 조사·병렬 실행이 필요한 경우에만 서브에이전트를 활용하는 것이다. 그 결과 도구 실패가 23% 감소하고 P95 사용자 대기 시간이 5% 줄었으며, 품질 저하 없이 Copilot CLI 전체 트래픽에 적용됐다. ### 서브에이전트 위임은 항상 효율적이지 않다 - 서브에이전트는 복잡한 작업을 분해하고 여러 조사를 병렬로 수행하는 데 유용하다. - 하지만 단순한 파일 수정까지 위임하면 오히려 다음과 같은 비용이 발생한다. - 불필요한 에이전트 간 인계와 조정 - 동일하거나 겹치는 저장소 검색 - 메인 에이전트가 결과를 기다리는 시간 - 오래된 파일 경로, 잘못된 상대 경로, 워크스페이스 불일치에 따른 도구 실패 - 특히 메인 에이전트가 이미 충분한 맥락을 알고 있는데도 탐색 서브에이전트를 실행하면, 서브에이전트가 저장소를 다시 검색하면서 작업이 지연된다. ### 데이터 분석으로 불필요한 위임 패턴 식별 - GitHub는 에이전트의 전체 실행 궤적을 LLM으로 분석해 위임이 실제로 도움이 되는지 확인했다. - 분석 결과, 다음과 같은 작업에 서브에이전트가 과도하게 사용되고 있었다. - 범위가 좁고 명확한 작업 - 필요한 정보가 이미 핸드오프에 포함된 작업 - 파일을 찾고 읽은 뒤 한 곳을 수정하는 작업 - 이를 바탕으로 “간단한 탐색과 수정은 메인 에이전트가 직접 처리한다”는 방향을 개선 목표로 삼았다. ### 좁은 작업은 직접 처리하고 복잡할 때만 위임 - Copilot CLI의 새로운 정책은 가장 간단한 실행 경로에서 시작한다. - 파일 찾기 - 파일 읽기 - 특정 부분 수정 - 변경 사항 검증 - 다음과 같은 경우에는 서브에이전트 위임이 효과적이다. - 익숙하지 않은 대규모 저장소 탐색 - 서로 독립적인 코드 영역 조사 - 장시간 실행되는 명령 수행 - 여러 작업을 동시에 진행할 수 있는 경우 - 작업이 복잡하거나 불확실할 때 위임하고, 다시 작업 범위가 좁아지면 메인 에이전트가 직접 처리하도록 한다. - 서브에이전트는 메인 에이전트를 멈추게 하는 “일시정지 버튼”이 아니라, 독립 작업을 병렬화하는 도구로 사용해야 한다. ### 구체적인 핸드오프와 병렬 실행 - 서브에이전트를 실행할 때는 핸드오프에 다음 내용을 명확히 포함해야 한다. - 사용자가 요청한 전체 목표 - 메인 에이전트가 이미 파악한 정보 - 서브에이전트가 담당할 범위 - 반환해야 하는 결과의 형태 - 메인 에이전트는 서브에이전트의 결과를 기다리기만 하지 않고, 그동안 독립적으로 수행할 수 있는 작업을 계속 진행해야 한다. - 이 방식은 중복 검색과 순차적 대기를 줄이고, 실제로 병렬 처리가 가능한 작업에서 위임의 이점을 높인다. ### 오프라인 평가와 운영 환경 A/B 테스트 - GitHub는 자동 생성 회귀 테스트와 기존 벤치마크를 이용해 정책 변경을 먼저 오프라인에서 검증했다. - 이후 내부 사용자와 공개 사용자를 대상으로 A/B 테스트를 진행했다. - 평가 항목은 다음과 같았다. - 도구 안정성 - 사용자 응답성과 대기 시간 - 서브에이전트 사용량 - 최종 결과 품질 - 성능 향상은 개별 LLM 호출 자체를 빠르게 만든 결과가 아니라, 불필요한 서브에이전트 실행을 줄여 오케스트레이션 비용을 낮춘 결과였다. ### 측정된 개선 효과 - 세션당 도구 실패가 **23% 감소** - 검색 도구 실패: **27% 감소** - 편집 도구 실패: **18% 감소** - 사용자 대기 시간 개선 - P95: **5% 감소** - P75: **3% 감소** - 품질 저하는 관찰되지 않았다. - 개선된 위임 기능은 Copilot CLI 운영 트래픽의 100%에 배포됐다. - 사용자는 `/update` 명령으로 Copilot CLI **1.0.42 이상**으로 업데이트하면 적용된 기능을 사용할 수 있다. 간단한 작업에는 직접 실행을 우선하고, 서브에이전트는 독립성·복잡성·병렬성 때문에 실제 이득이 있을 때만 사용하는 것이 효율적이다. 이를 위해 위임 여부뿐 아니라 핸드오프의 구체성, 메인 에이전트의 병렬 진행 여부까지 함께 설계해야 한다.

github

언어 서버로 GitHub Copilot CLI에 진정한 코드 인텔리전스를 더하세요 (새 탭에서 열림)

GitHub Copilot CLI는 LSP(Language Server Protocol)를 연동하면 단순한 텍스트 검색이나 바이트코드 추출을 넘어, 코드의 타입·정의·참조를 의미론적으로 이해할 수 있다. 글에서는 이를 자동화하는 **LSP Setup 스킬**의 동작 방식과 설정 형식, 지원 언어 및 설치 절차를 소개하며, 결과적으로 더 정확하고 빠른 코드 분석이 가능해진다고 설명한다. ## 텍스트 검색 기반 코드 이해의 한계 - LSP가 없으면 Copilot CLI는 의존성 정보를 찾기 위해 다음과 같은 우회 작업을 수행한다. - Java JAR 파일 검색 및 임시 디렉터리 추출 - `.class` 파일에 대한 `grep` - Python의 `site-packages`나 TypeScript의 `node_modules` 파일 직접 탐색 - 이런 방식은 단순한 패턴 검색에 의존하므로 다음 정보를 정확히 처리하기 어렵다. - 제네릭 타입 - 메서드 오버로드 - 전이 의존성의 타입 - 컴파일된 바이트코드 내부의 의미 구조 - 반면 LSP의 `textDocument/definition` 요청은 심볼의 정확한 소스 위치, 해석된 타입, 메서드 시그니처를 반환한다. ## LSP Setup 스킬의 7단계 동작 ### 1. 언어 선택 - `ask_user`를 사용해 사용자가 LSP를 설정할 프로그래밍 언어를 선택한다. - 선택한 언어가 이후 설치 명령과 설정 생성을 결정한다. ### 2. 운영체제 확인 - macOS와 Linux에서는 `uname -s`를 사용한다. - Windows에서는 `$env:OS` 또는 `%OS%`를 확인한다. - 운영체제에 따라 LSP 서버 설치 방법을 다르게 적용한다. - macOS Java: `brew install jdtls` - Linux Java: Eclipse 등에서 다운로드 ### 3. LSP 서버 조회 - `references/lsp-servers.md`에 14개 언어의 정보가 미리 정리되어 있다. - 각 언어별로 다음 내용을 제공한다. - 운영체제별 설치 명령 - 실행 파일 이름 - 바로 사용할 수 있는 설정 예시 ### 4. 설정 범위 선택 - 사용자 전역 설정: - `~/.copilot/lsp-config.json` - 모든 저장소에 적용 - 저장소별 설정: - 저장소 루트의 `lsp.json` - 또는 `.github/lsp.json` - 특정 프로젝트에만 적용 - 두 설정이 모두 존재하면 저장소별 설정이 우선한다. ### 5. LSP 서버 설치 - 언어에 맞는 설치 명령을 자동으로 실행한다. - 예시는 다음과 같다. ```bash npm install -g typescript typescript-language-server brew install jdtls rustup component add rust-analyzer ``` ### 6. 설정 파일 생성 및 병합 - 설정은 `lspServers` 객체 아래에 서버별 항목을 둔다. ```json { "lspServers": { "java": { "command": "jdtls", "args": [], "fileExtensions": { ".java": "java" } } } } ``` - 주요 규칙은 다음과 같다. - `command`는 `$PATH`에 있거나 절대 경로여야 한다. - 일반적으로 표준 입출력 통신을 위해 `--stdio`를 `args`에 지정한다. - `fileExtensions`는 점으로 시작하는 확장자와 VS Code 언어 식별자를 연결한다. - 기존 설정은 삭제하지 않고 새로운 항목을 병합한다. - `jdtls`처럼 표준 입출력을 내부적으로 처리하는 서버는 별도 인자가 필요하지 않을 수 있다. ### 7. 설치 및 설정 검증 - `which <binary>` 또는 Windows의 `where.exe`로 실행 파일이 접근 가능한지 확인한다. - 설정 파일이 올바른 JSON인지 검증한다. ## 지원 언어와 확장 방식 - 스킬은 현재 14개 언어에 대한 사전 정의 서버 정보를 제공한다. - 미리 매핑되지 않은 언어를 만나면 적절한 LSP 서버를 검색하고 수동 설정 과정을 안내한다. - 따라서 지원 목록에 없는 언어도 서버만 확보하면 직접 추가할 수 있다. ## 설정 후 가능한 코드 인텔리전스 LSP 연동 후 Copilot CLI는 다음 작업을 수행할 수 있다. - 의존성 전체에서 타입을 정확히 해석 - 저장소에 소스 코드가 없는 외부 라이브러리의 정의로 이동 - 프로젝트 전반에서 심볼의 모든 참조 검색 - 함수·클래스·타입의 hover 문서 확인 - 메서드 시그니처와 타입 관계를 기반으로 코드 수정 및 분석 그 결과 불필요한 JAR 압축 해제나 `node_modules` 검색이 줄고, 잘못 해석한 API에 기반한 코드 생성도 감소한다. ## 설치 및 사용 절차 1. Awesome Copilot의 LSP Setup 스킬 페이지에서 ZIP 파일을 다운로드한다. 2. 다음 명령으로 `~/.copilot/skills/`에 압축을 푼다. ```bash unzip lsp-setup.zip -d ~/.copilot/skills/ ``` 3. 실행 중인 Copilot CLI를 `/exit`로 종료한 뒤 다시 실행한다. 4. “set up LSP for Java” 또는 “enable code intelligence for Python”처럼 요청한다. 5. 설정이 끝나면 Copilot CLI를 다시 시작한다. 6. `/lsp`로 서버 상태를 확인하고, 의존성 심볼의 정의 이동을 테스트한다. 프로젝트 규모가 크거나 외부 라이브러리 사용이 많은 경우에는 LSP Setup 스킬을 적용하는 것이 좋다. 특히 Java, TypeScript, Python처럼 타입과 의존성 관계가 복잡한 언어에서는 텍스트 검색보다 정확한 코드 분석과 안정적인 결과를 기대할 수 있다.

github

일회성 프롬프트에서 워크플로로: GitHub Copilot CLI에서 커스텀 에이전트를 사용하는 방법 (새 탭에서 열림)

GitHub Copilot CLI의 커스텀 에이전트는 반복적인 터미널 작업과 팀의 개발 규칙을 Markdown 기반 워크플로로 표준화하는 기능이다. 저장소에 에이전트 프로필을 두면 팀의 도구, 코딩·보안·접근성 기준, 출력 형식을 버전 관리하며 CLI·IDE·GitHub 전반에서 일관되게 사용할 수 있다. 따라서 일회성 프롬프트를 반복하는 대신 검토 가능하고 재사용 가능한 전문 에이전트를 구축할 수 있다. ## 커스텀 에이전트의 개념 - 커스텀 에이전트는 특정 작업에 특화된 Copilot 에이전트다. - Markdown 파일인 에이전트 프로필에 다음 내용을 정의한다. - 에이전트의 역할과 전문 영역 - 사용할 수 있는 도구 - 따라야 할 개발·보안·접근성 기준 - 실행 범위와 안전장치 - 결과물의 형식 - 일반적인 코드 정리 에이전트와 달리, 팀의 포맷 규칙·접근성 표준·리뷰 절차·보안 요구사항을 매번 동일하게 적용할 수 있다. - 프로필이 저장소에 포함되므로 코드처럼 리뷰·수정·공유·버전 관리가 가능하다. ## 에이전트 프로필 구성 프로필은 YAML frontmatter와 지침 본문으로 구성된다. - `name`: 에이전트 이름 - `description`: 에이전트의 목적과 역할 - `model`: 사용할 Copilot 모델 - `tools`: 코드베이스 검색, 파일 수정, 테스트 실행, 터미널, 웹 요청 등 허용할 도구 - 본문 지침: - 에이전트의 전문성 - 작업 절차 - 출력 형식 - 금지 사항과 안전 규칙 예를 들어 접근성 전문가 에이전트는 WCAG 2.1/2.2의 A·AA·AAA 등급을 기준으로 웹 UI를 검토하고, 디자인·개발·QA에 적용 가능한 실무 지침을 제공하도록 설정할 수 있다. ## GitHub Copilot CLI에서 사용하는 방법 - 터미널에서 GitHub Copilot CLI를 실행한다. - `/agent` 슬래시 명령을 사용해 원하는 커스텀 에이전트를 선택한다. - 대상 저장소의 `.github/agents` 디렉터리에 프로필을 만든다. - 파일 확장자는 `.agent.md`를 사용한다. 예: - `.github/agents/accessibility.agent.md` - `.github/agents/security-audit.agent.md` - CLI는 정의된 도구와 지침에 따라 스크립트 실행, API 호출, 저장소 분석 등을 반복 가능한 방식으로 수행한다. ## 자동화할 수 있는 보안 감사 글에서는 보안 점검을 대표적인 커스텀 에이전트 활용 사례로 제시한다. - 여러 저장소에서 팀의 표준 보안 도구를 실행한다. - `gitleaks`: 비밀·자격 증명 탐지 - `trivy`: 파일 시스템 및 컨테이너 취약점 검사 - `semgrep`: 정적 분석 - `gh`: GitHub 설정 및 의존성 검토 - `jq`, `git`: 결과 처리와 저장소 작업 - 결과를 `Critical`, `High`, `Medium`, `Low` 심각도로 분류한다. - 담당자와 다음 조치를 포함한 PR용 체크리스트로 출력한다. - 저장소에 이미 존재하는 설정 파일을 우선 사용한다. - `.semgrep.yml` - `.trivyignore` - `.gitleaks.toml` - 도구가 설치되지 않은 경우 결과를 추측하지 않고 “검사 범위의 공백”으로 기록한다. - 토큰이나 자격 증명 등 민감한 정보는 출력에서 마스킹한다. - `CODEOWNERS`가 없으면 경로별 기본 담당 팀을 매핑해 후속 조치를 명확히 한다. ## 커스텀 에이전트의 장점 - 반복 작업을 자동화해 명령어 재실행과 컨텍스트 재설명을 줄인다. - 팀 표준을 프롬프트가 아닌 저장소 파일로 관리할 수 있다. - 결과 형식과 품질 기준이 일관된다. - CLI에서 시작한 작업을 IDE와 GitHub의 리뷰·PR 흐름으로 자연스럽게 연결할 수 있다. - 에이전트 설정 자체를 코드 리뷰 대상으로 삼아 변경 이력과 책임 소재를 남길 수 있다. 반복적으로 수행하는 보안 검사, 접근성 검토, 테스트 실행, 로그 분석 같은 작업부터 `.github/agents`에 에이전트로 정의하는 것이 좋다. 특히 허용 도구, 민감 정보 처리, 실패 시 동작, 결과 형식을 명확히 작성하면 Copilot CLI를 단순한 명령어 생성기가 아니라 팀 표준을 실행하는 재사용 가능한 워크플로 엔진으로 활용할 수 있다.

github

GitHub, Gartner® 매직 쿼드런트™ 엔터프라이즈 AI 코딩 에이전트 부문에서 3년 연속 리더로 선정 (새 탭에서 열림)

코드 생성이 쉬워지면서 소프트웨어 개발의 병목은 코드 작성에서 리뷰·보안·거버넌스·배포로 이동했으며, GitHub는 이를 해결하려면 소프트웨어 개발 생명주기(SDLC) 전반에 AI 에이전트가 필요하다고 주장합니다. GitHub Copilot은 이슈 처리부터 코드 리뷰와 배포까지 지원하는 에이전트형 기능을 확장하고 있으며, Gartner의 2026년 보고서에서 3년 연속 ‘Leader’로 선정됐습니다. GitHub는 특히 실행 역량, 네이티브 통합, 보안·거버넌스 기능에서 강점을 보였다고 설명합니다. ## 코드 생성에서 소프트웨어 결과물 조율로 - 개발자는 더 이상 Copilot에 단순히 함수 작성을 요청하는 데 그치지 않고, 이슈를 에이전트에 할당한 뒤 작업을 맡길 수 있습니다. - 에이전트는 코드 작성뿐 아니라 관련 작업을 수행하고, 개발자는 결과를 검토·수정·승인하는 역할에 집중합니다. - Gartner는 2028년 비동기 AI 코딩 에이전트가 소프트웨어 엔지니어링 팀 생산성을 30~50% 향상할 것으로 전망했습니다. - 이는 2025년 AI 코드 보조 도구가 제공할 것으로 예상된 0~20%의 생산성 향상보다 큰 폭입니다. - 생산성 향상을 실현하려면 코드 생성뿐 아니라 계획, 테스트, 리뷰, 보안, 거버넌스까지 AI가 관여해야 한다는 것이 GitHub의 주장입니다. ## 엔터프라이즈 규모로 확산되는 GitHub Copilot - GitHub Copilot은 현재 14만 개 조직에서 사용되며, 전년 대비 사용자·조직 기반이 거의 3배로 증가했습니다. - 전체 성장률은 전년 대비 100%를 넘었고, 많은 사용자가 여러 AI 모델을 함께 활용하고 있습니다. - GitHub Copilot CLI 사용량도 전월 대비 거의 두 배씩 증가하고 있다고 설명합니다. - GitHub는 이러한 지표가 기업들이 Copilot을 단순 코드 자동완성 도구가 아니라 복합적인 개발 플랫폼으로 활용하고 있음을 보여준다고 평가합니다. ## Gartner ‘Leader’ 선정과 평가 - Gartner는 2026년 Enterprise AI Coding Agents Magic Quadrant에서 12개 공급업체를 평가했습니다. - 평가는 크게 다음 두 기준을 바탕으로 이뤄졌습니다. - 실행 역량(Ability to Execute) - 비전의 완성도(Completeness of Vision) - GitHub는 실행 역량 부문에서 가장 높은 위치에 배치됐으며, 3년 연속 Leader로 선정됐습니다. - Gartner가 말하는 Leader는 다음 특징을 갖춘 업체입니다. - 강력한 제품 실행력과 시장 방향을 형성할 수 있는 명확한 비전 - 편집기 내부를 넘어 계획·테스트·코드 리뷰·워크플로 자동화까지 지원하는 에이전트 기능 - 개발자와 기업 모두에게서 확보한 시장 반응 - 확장되는 생태계와 지속 가능한 비즈니스 모델 - 엔터프라이즈급 보안, 거버넌스, 운영 성숙도 ## GitHub Copilot의 차별화 요소 - **모델과 사용 환경의 선택권** - 여러 공급업체의 AI 모델을 지원합니다. - 코드 에디터, IDE, CLI뿐 아니라 GitHub 웹·데스크톱·모바일 앱에서도 Copilot을 사용할 수 있습니다. - **SDLC 전반의 통합** - 개발 시작 단계의 코드 작성에만 머물지 않습니다. - 이슈, 풀 리퀘스트, 코드 리뷰, GitHub Actions 등 개발 및 배포 과정 곳곳에 Copilot을 통합합니다. - **기업용 통제 기능** - 조직이 AI 사용 현황을 관찰하고 감사할 수 있도록 지원합니다. - AI가 생성하거나 수정한 코드의 사용을 보안 정책과 거버넌스 체계 안에서 관리할 수 있도록 합니다. - GitHub는 이러한 기능이 GitHub 플랫폼 내부의 네이티브 통합과 결합되어 기업 환경에서 AI 개발을 관리하기에 유리하다고 주장합니다. ## 앞으로의 계획 - 개발자가 사용하는 모든 GitHub 표면에서 에이전트형 워크플로를 더욱 확장할 예정입니다. - 여러 모델을 더 폭넓게 제공하고, 작업에 적합한 모델을 자동으로 선택하는 지능형 라우팅을 강화할 계획입니다. - 단순히 코드가 어떻게 생성되는지만이 아니라 GitHub에서 소프트웨어가 실제로 어떻게 개발·검토·배포되는지에 기반해 Copilot 성능을 개선하려 합니다. - 핵심 방향은 개발 생명주기 전체를 연결하는 AI-native 소프트웨어 개발 환경을 구축하는 것입니다. Gartner의 Leader 선정은 GitHub Copilot의 엔터프라이즈 경쟁력을 보여주는 지표지만, Gartner도 특정 업체나 최고 등급 업체만을 선택하라고 권고하지 않는다고 명시합니다. 따라서 도입을 검토할 때는 모델 선택권, 기존 저장소·CI/CD와의 통합성, 보안 및 감사 기능, 실제 팀의 리뷰·배포 프로세스 개선 효과를 함께 평가하는 것이 바람직합니다.

github

던전 & 데스크톱: GitHub Copilot CLI로 절차적으로 생성되는 로그라이크 만들기 (새 탭에서 열림)

GitHub Dungeons는 GitHub 저장소를 터미널에서 플레이할 수 있는 로그라이크 던전으로 변환한 Go 기반 GitHub CLI 확장이다. 저장소의 최신 커밋 SHA를 시드로 삼아 BSP(Binary Space Partitioning) 방식으로 방과 통로를 생성하므로, 같은 커밋에서는 같은 맵이 만들어지고 코드가 변경되면 던전도 달라진다. 저자는 GitHub Copilot CLI의 `/delegate`와 에이전트를 활용해 구현과 문서화를 위임하고, 게임 설계와 플레이 경험에 집중했다. ## 코드 저장소가 로그라이크 던전이 되는 방식 - 저장소의 코드 구조를 바탕으로 방, 통로, 적, 출구가 있는 던전을 생성한다. - 플레이어는 터미널에서 화살표 키로 이동하며 버그와 싸우고 출구를 찾아야 한다. - HP가 0이 되면 처음부터 다시 시작하는 영구 사망(permadeath) 구조를 따른다. - 저장소마다 맵의 구조가 달라지고, 커밋이 바뀔 때마다 새로운 레이아웃이 만들어진다. - 최신 커밋 SHA를 난수 생성의 시드로 사용한다. - 같은 커밋은 항상 같은 던전을 생성한다. - 서로 다른 저장소는 구조적으로 서로 다른 맵을 만든다. - 코드 변경은 던전의 변화로 이어진다. ## 로그라이크와 절차적 생성 - 로그라이크는 1980년대 게임 *Rogue*에서 시작된 장르다. - 주요 특징은 다음과 같다. - 실행할 때마다 달라지는 절차적 생성 맵 - 죽으면 다시 시작하는 영구 사망 - 텍스트 기반 인터페이스 - 절차적 생성은 콘텐츠를 사람이 하나씩 설계하는 대신, 규칙과 무작위성을 이용해 알고리즘으로 생성하는 방식이다. - 하나의 던전을 직접 만드는 것이 아니라, 여러 던전을 생성할 수 있는 시스템을 만든다는 점이 핵심이다. - 이러한 구조 덕분에 매 플레이마다 레이아웃과 상황이 달라져 반복 플레이가 가능해진다. ## BSP 기반 던전 생성 - BSP(Binary Space Partitioning)는 큰 공간을 반복해서 더 작은 영역으로 나누는 알고리즘이다. - 기본 흐름은 다음과 같다. - 전체 던전을 하나의 큰 직사각형 공간으로 설정한다. - 공간을 두 영역으로 분할한다. - 각 영역을 재귀적으로 다시 나눈다. - 충분히 작은 영역 안에 방을 배치한다. - 방들을 통로로 연결한다. - BSP가 로그라이크에 적합한 이유는 다음과 같다. - 직사각형 방을 만들기 쉽다. - 방 사이의 연결 구조를 보장하기 쉽다. - 완전히 무작위인 맵보다 구조적으로 이해하기 쉽다. - 일정한 규칙 안에서 무작위성이 생겨 매번 다른 맵을 만들 수 있다. - 결과적으로 맵은 무질서하지 않으면서도 반복 플레이에 적합하고, 막다른 길이나 이동 불가능한 구조를 줄일 수 있다. ## GitHub Copilot CLI를 활용한 개발 - 저자는 Go 문법을 모두 직접 작성하기보다, Copilot CLI에 원하는 동작을 자연어로 설명하는 방식으로 개발했다. - `/delegate` 명령은 작업을 클라우드에서 실행되는 Copilot 코딩 에이전트에 위임한다. - 개발자는 요구사항을 평문으로 작성한다. - 에이전트가 비동기적으로 코드를 구현한다. - 작업이 끝나면 결과가 Pull Request로 생성된다. - 개발자는 PR을 검토하고 수정해 완성도를 높인다. - 예를 들어 다음과 같은 요구를 위임했다. - 레벨이 올라갈수록 적을 늘리고, 대신 체력 회복 아이템도 추가하기 - 플레이어를 무적으로 만드는 치트 코드 추가하기 - Copilot이 초기 구현과 보일러플레이트를 맡는 동안 저자는 난이도 조정, 게임 메커니즘, 이스터 에그 등 플레이 경험에 집중했다. ## 에이전트를 통한 문서화 - 저자는 Copilot으로 “dungeon scribe”라는 별도 에이전트도 생성했다. - 이 에이전트는 다음 작업을 수행했다. - 던전 생성 방식에 대한 문서 작성 - ASCII 아트 다이어그램 생성 - BSP 기반 레이아웃 생성 과정 설명 - 이를 통해 구현 코드뿐 아니라 알고리즘의 동작 원리와 프로젝트 구조도 함께 문서화할 수 있었다. ## 실용적인 결론 절차적 생성과 커밋 기반 시드를 결합하면 코드 저장소 자체를 재현 가능하면서도 변화하는 게임 세계로 만들 수 있다. 또한 Copilot CLI의 `/delegate`처럼 구현 작업을 에이전트에 위임하고 결과를 PR 단위로 검토하는 방식은, 개발자가 반복적인 코딩보다 기능 설계와 사용자 경험에 집중하는 데 유용하다.

github

초보자를 위한 GitHub Copilot CLI: 대화형 vs 비대화형 모드 (새 탭에서 열림)

GitHub Copilot CLI는 대화형과 비대화형이라는 두 가지 실행 모드를 제공한다. 대화형 모드는 세션 안에서 질문과 후속 작업을 반복하며 프로젝트를 함께 다루는 데 적합하고, 비대화형 모드는 한 번의 프롬프트로 빠른 답변을 얻거나 자동화된 워크플로에 연결할 때 유용하다. 이전 세션을 다시 불러오는 기능도 제공하므로 작업 방식과 목적에 따라 모드를 선택할 수 있다. ## 대화형 모드: 반복적인 협업과 심층 작업 대화형 모드는 Copilot CLI의 기본 모드로, 채팅처럼 Copilot과 여러 차례 상호작용하는 방식이다. - 터미널에서 `copilot`을 입력해 시작한다. - 처음 실행하면 Copilot이 프로젝트 파일을 읽고 수정할 수 있도록 현재 폴더를 신뢰할지 물을 수 있다. - 질문을 입력하면 프로젝트를 분석한 답변이나 실행 방법을 제시한다. - 필요하면 “직접 실행해줘”와 같은 후속 프롬프트를 입력해 서버 실행이나 파일 수정 등을 맡길 수 있다. - 같은 세션에서 결과를 검토하고 추가 질문이나 변경 요청을 이어갈 수 있다. - 프로젝트 탐색, 디버깅, 기능 구현처럼 맥락을 유지해야 하는 작업에 적합하다. ## 비대화형 모드: 빠른 일회성 작업 비대화형 모드는 별도의 대화 세션에 들어가지 않고 한 번의 프롬프트를 즉시 실행하는 방식이다. - 일반 터미널에서 `copilot -p "프롬프트"` 형식으로 실행한다. - 예시: ```bash copilot -p "이 저장소의 역할과 주요 폴더를 간단히 요약해줘" ``` - 저장소 요약, 코드 조각 생성, 간단한 질문처럼 후속 대화가 필요 없는 작업에 적합하다. - 답변을 받은 뒤 곧바로 기존 셸 작업으로 돌아갈 수 있다. - 스크립트나 자동화된 개발 워크플로에 Copilot을 연결할 때도 활용할 수 있다. ## 이전 세션 이어가기 Copilot CLI는 이전 대화의 맥락을 유지한 채 작업을 재개할 수 있다. - 대화형 모드에서 `/resume`을 입력하면 이전 세션 목록이 표시된다. - 비대화형 상태에서 바로 세션 선택기를 열려면 다음 명령을 사용한다. ```bash copilot --resume ``` - 이전에 진행하던 프로젝트 분석, 코드 수정, 논의 내용을 이어서 작업할 수 있다. ## 모드 선택 기준 - 프로젝트를 탐색하거나 Copilot과 계속 협업해야 한다면 대화형 모드를 사용한다. - 명확한 질문에 대한 단일 답변, 저장소 요약, 코드 생성이 필요하면 비대화형 모드가 효율적이다. - 반복 작업이나 자동화 파이프라인에는 `copilot -p`를 활용한다. - 중단했던 복잡한 작업을 재개할 때는 `/resume` 또는 `copilot --resume`을 사용한다. 상호작용이 많은 개발 작업에는 대화형 모드를, 빠르고 집중적인 요청에는 비대화형 모드를 선택하면 터미널 안에서 Copilot을 효율적으로 활용할 수 있다.

github

GitHub Copilot CLI로 이모지 리스트 생성기 만들기 (새 탭에서 열림)

소셜 미디어용 목록에 어울리는 이모지를 자동으로 붙여 주는 터미널 애플리케이션을 GitHub Copilot CLI로 개발한 사례를 소개합니다. 사용자가 마크다운 bullet list를 입력한 뒤 `Ctrl + S`를 누르면 Copilot SDK가 각 항목에 적절한 이모지를 추가하고 결과를 클립보드에 복사합니다. 이 프로젝트는 짧은 기획과 여러 AI 개발 도구를 활용해 실용적인 CLI를 빠르게 만들 수 있음을 보여 줍니다. ## 이모지 목록 생성기의 기능 - 터미널에서 실행되는 대화형 애플리케이션입니다. - 사용자가 bullet point 목록을 붙여 넣거나 직접 작성합니다. - `Ctrl + S`를 누르면 각 항목의 의미에 맞는 이모지를 자동으로 추가합니다. - 완성된 목록은 클립보드에 복사되어 소셜 미디어 게시물 등에 바로 사용할 수 있습니다. - `Ctrl + C`로 애플리케이션을 종료합니다. ## 사용한 기술 스택 - `@opentui/core` - 터미널 기반 사용자 인터페이스를 구현합니다. - `@github/copilot-sdk` - 입력된 문장을 분석하고 적절한 이모지를 선택하는 AI 기능을 담당합니다. - `clipboardy` - 생성된 결과를 시스템 클립보드에 복사합니다. - GitHub Copilot CLI - 프로젝트 기획, 구현, 코드 작성 과정 전반에 활용되었습니다. ## Copilot CLI를 활용한 개발 과정 - 먼저 Copilot CLI의 **plan mode**에서 애플리케이션의 요구사항을 자연어로 설명했습니다. - Copilot은 사용할 기술 스택, UI 방식, 라이브러리 등에 대해 추가 질문을 했습니다. - 논의 결과를 바탕으로 검토 가능한 `plan.md` 파일을 생성했습니다. - 계획을 확인한 뒤 Claude Opus 4.7을 사용해 실제 구현을 진행했습니다. - 몇 분 만에 동작하는 터미널 UI와 AI 기반 변환 기능을 완성했습니다. ## 함께 사용한 Copilot CLI 기능 - **Plan mode** - 구현 전에 요구사항과 기술적 접근 방식을 정리합니다. - **Autopilot mode** - 여러 구현 작업을 자동으로 진행하도록 합니다. - **Multi-model workflow** - 계획 수립과 구현 등 작업 목적에 따라 서로 다른 AI 모델을 활용합니다. - **`allow-all` 도구 플래그** - CLI가 필요한 도구를 보다 자유롭게 사용할 수 있도록 합니다. - **GitHub MCP 서버** - GitHub 관련 정보와 기능을 Copilot이 활용할 수 있게 합니다. ## 공개된 결과물 - 완성된 프로젝트는 무료 오픈 소스로 공개되었습니다. - GitHub 저장소: `cassidoo/emoji-list-generator` - Copilot CLI와 Copilot SDK의 공식 문서를 참고해 유사한 프로젝트를 직접 만들 수 있습니다. 작은 자동화 도구라도 요구사항을 먼저 계획으로 구체화하고, AI 모델·SDK·터미널 UI·클립보드 라이브러리를 조합하면 빠르게 완성할 수 있습니다. 특히 반복적인 콘텐츠 작성 작업을 CLI로 자동화하려는 개발자에게 적합한 접근입니다.

github

GitHub Copilot CLI로 개인용 정리 커맨드 센터 구축하기 (새 탭에서 열림)

여러 앱에 흩어진 업무 정보를 하나로 모으기 위해, GitHub 엔지니어 Brittany Ellich가 개인용 조직 관리 커맨드 센터를 만들었다. 이 프로젝트는 일상적인 디지털 파편화 문제를 해결하는 데 초점을 맞췄으며, GitHub Copilot을 기획과 구현 전반에 활용해 하루 만에 v1을 완성했다. 글은 작은 개인적 불편에서 출발해 AI 도구로 실제 생산성 도구를 만드는 과정을 소개한다. ## 디지털 파편화를 해결하는 개인용 커맨드 센터 - 여러 앱을 오가며 발생하는 컨텍스트 전환과 정보 분산을 해결하기 위해 중앙 집중형 작업 공간을 구축했다. - 사용자가 정보를 시각적으로 파악하고 사고하는 방식에 맞춘 “차분하고 시각적인 홈 화면”을 목표로 했다. - 캘린더, 업무 정보, 음성 비서 등 다양한 기능을 한곳에서 사용할 수 있도록 설계했다. ## 기획 후 구현하는 AI 협업 방식 - Brittany는 먼저 요구사항을 정리한 뒤 구현하는 `plan-then-implement` 방식을 사용한다. - 기획 단계에서 Copilot이 질문을 연속적으로 던지도록 해 다음 사항을 구체화했다. - 애플리케이션이 어떻게 동작해야 하는지 - 사용자가 어떤 흐름으로 기능을 이용하는지 - 구현에 필요한 요구사항과 우선순위 - 충분히 구체화된 계획을 Copilot에 전달하고, 이를 기반으로 실제 구현을 진행했다. - 이 방식 덕분에 다른 업무를 병행하면서도 아이디어에서 작동하는 v1까지 하루 만에 도달할 수 있었다. ## 동기·비동기 에이전트 활용 - 동기식 개발에는 VS Code의 Agent Mode를 사용한다. - 서로 충돌하지 않는 작업은 최대 2개의 에이전트 워크플로로 동시에 진행한다. - 감독이 필요한 작업은 VS Code에서 직접 처리하고, 다음과 같은 범위가 명확한 작업은 Copilot Cloud Agent에 맡긴다. - 버그 수정 - 기술 부채 정리 - 비동기적으로 처리 가능한 소규모 변경 - 이를 통해 집중적인 개발과 백그라운드 작업을 병렬화한다. ## 기술 스택과 프로젝트 공개 - 애플리케이션은 다음 기술로 구성됐다. - **Electron**: 크로스 플랫폼 데스크톱 애플리케이션 프레임워크 - **React**: UI 컴포넌트와 상태 관리 - **Vite**: 빠른 개발 서버와 Hot Module Replacement를 제공하는 빌드 도구 - **Tailwind CSS**: 유틸리티 기반 CSS 프레임워크 - **WorkIQ MCP**: Microsoft 365 데이터에 접근하기 위한 MCP 서버와 CLI - 초기 구현 대부분을 Agent Mode로 진행했기 때문에 Electron 자체를 깊이 학습하지는 않았다고 설명한다. - 다만 공개 저장소로 정리하는 과정에서는 직접 코드를 읽고 불필요한 코드를 제거했다. - 에이전트는 코드를 추가하는 데는 능숙하지만, 불필요한 코드를 삭제하고 저장소를 단순화하는 작업에는 상대적으로 소극적이라는 경험도 공유한다. - 프로젝트는 `brittanyellich/command-center-lite` 저장소에서 확인할 수 있다. ## 실행에 필요한 환경 - 직접 프로젝트를 실행하려면 다음 조건이 필요하다. - Node.js 18 이상 - WorkIQ 설정을 위한 GitHub Copilot CLI - 캘린더 동기화를 위한 Microsoft 365 계정 - 음성 비서 기능을 위한 ElevenLabs 계정 - 구체적인 설치 및 실행 절차는 프로젝트의 README에 정리되어 있다. ## 작은 불편에서 시작하는 개발 - 가장 유용한 프로젝트는 거대한 아이디어보다 일상적인 불편을 해결하려는 시도에서 시작될 수 있다. - 기술 스택을 완벽히 이해한 뒤 시작하기보다, AI 도구의 도움을 받아 새로운 프레임워크와 서비스를 빠르게 조합할 수 있다. - Brittany의 조언은 간단하다. 직접 무언가를 만들어 보면서 새로운 AI 도구를 사용하는 방법을 익히라는 것이다. 개인 업무에서 반복적으로 앱을 전환하거나 정보를 수동으로 모으고 있다면, 먼저 해결할 불편을 하나 정한 뒤 Copilot으로 요구사항을 인터뷰하고 작은 v1을 만들어보는 접근이 실용적이다.

github

입문자를 위한 GitHub Copilot CLI: GitHub Copilot CLI 시작하기 (새 탭에서 열림)

GitHub Copilot CLI는 에이전트형 AI를 터미널에 통합해 코드 작성, 테스트 실행, 오류 수정 등을 지원하는 도구다. 이 글은 npm을 통한 설치부터 GitHub 인증, 폴더 권한 설정, 첫 프롬프트 실행까지의 시작 과정을 소개한다. 또한 프로젝트 분석, 엔드포인트 생성, Copilot Cloud Agent로 작업 위임 같은 활용 사례를 설명한다. ## GitHub Copilot CLI란? - Copilot의 에이전트 기능을 명령줄 환경에서 사용할 수 있게 해주는 도구다. - 저장소 전체 맥락을 바탕으로 파일을 탐색하고 코드를 작성할 수 있다. - 코드 빌드와 테스트 실행을 자율적으로 수행하며, 오류를 발견하면 스스로 수정할 수 있다. - 사용자는 작업을 요청한 뒤 결과를 검토하고 추가 변경을 지시할 수 있어, 다른 도구로 전환하지 않고 개발 흐름을 유지할 수 있다. - CLI에서 Copilot Cloud Agent에 작업을 위임하는 것도 가능하다. ## 설치 방법 Node.js가 설치되어 있다면 npm으로 전역 설치할 수 있다. ```bash npm install -g @github/copilot ``` - Windows에서는 WinGet, macOS에서는 Homebrew 등 패키지 관리자를 사용할 수도 있다. - 패키지 관리자별 정확한 설치 명령은 해당 도구의 문서를 확인해야 한다. ## 최초 실행과 인증 설치가 끝나면 터미널에서 `Copilot` 명령으로 실행한다. ```plaintext Copilot ``` 처음 사용하는 경우 `/login` 명령으로 GitHub 계정에 로그인한다. ```plaintext /login ``` 로그인 과정에서 다음 작업이 수행된다. - Copilot 클라이언트와 GitHub Copilot 계정을 연결한다. - GitHub 리소스에 접근할 수 있도록 읽기 전용 GitHub MCP 서버를 연결한다. ## 폴더 권한 설정 Copilot이 프로젝트를 분석하거나 파일을 수정하려면 해당 폴더에 대한 접근 권한을 부여해야 한다. - 현재 세션에서만 권한을 허용할 수 있다. - 같은 프로젝트에서 반복적으로 사용할 경우 권한 설정을 저장할 수 있다. - 파일을 생성하거나 수정하는 작업에서는 Copilot이 별도로 사용자 승인을 요청할 수 있다. - 권한을 부여한 뒤 자연어로 프로젝트 분석, 코드 작성, 테스트 등의 작업을 요청할 수 있다. ## 프로젝트 분석과 코드 생성 Copilot CLI는 저장소의 파일과 문서를 직접 탐색해 프로젝트 구조와 개발 관례를 파악한다. 예를 들어 다음과 같이 요청할 수 있다. ```plaintext Give me an overview of this project ``` - 주요 파일과 프로젝트 구성을 확인한 뒤 개요를 제공한다. - 새 기능을 요청하면 기존 문서와 코드 예제를 참고해 프로젝트 스타일에 맞추려 한다. - 예를 들어 카테고리 전체를 반환하는 새 엔드포인트를 추가하도록 요청할 수 있다. ```plaintext Let’s add a new endpoint to return all categories ``` - 파일 생성이나 변경 전에는 필요한 권한을 요청한다. ## Copilot Cloud Agent로 작업 위임 명확하게 정의된 작업은 CLI에서 Copilot Cloud Agent에 넘길 수 있다. ```plaintext /delegate Let’s deal with issue #14 to add the rest of the CRUD endpoints to games ``` 위임하면 Copilot이 다음 작업을 수행한다. - 현재 CLI 세션의 컨텍스트를 유지한다. - 새 브랜치를 생성한다. - 초안 상태의 Pull Request를 연다. - 백그라운드에서 요청된 변경 작업을 진행한다. - 작업 완료 후 사용자가 결과를 검토하도록 한다. ## 이후 학습할 기능 이 글은 입문 시리즈의 첫 번째 내용으로, 다음 주제들이 후속 글에서 다뤄질 예정이라고 안내한다. - 대화형 모드와 비대화형 모드 비교 - `-p` 플래그를 이용한 빠른 요약 - Copilot CLI의 슬래시 명령 - MCP 서버 연동 - CLI 사용법과 모범 사례 Copilot CLI는 터미널을 떠나지 않고 프로젝트를 이해하고 코드를 수정할 수 있게 해주는 도구다. 처음에는 작은 프로젝트 개요나 단순한 기능 추가부터 사용하고, 파일 변경과 권한 요청 결과를 직접 검토하면서 점차 작업 위임 범위를 넓히는 것이 좋다.

github

GitHub Copilot CLI, 세컨드 오피니언을 위해 여러 모델 제품군 결합 (새 탭에서 열림)

GitHub Copilot CLI가 주 모델과 다른 AI 계열의 모델을 활용해 작업을 검토하는 실험 기능 **Rubber Duck**을 공개했습니다. Rubber Duck은 계획 수립, 복잡한 구현, 테스트 작성 후처럼 오류를 조기에 발견하기 좋은 시점에 독립적인 피드백을 제공합니다. 평가 결과 Claude Sonnet과 GPT-5.4 기반 Rubber Duck 조합은 Sonnet과 Opus 단독 실행 성능 차이의 74.7%를 줄였습니다. ## 자신감 있는 실수가 누적되는 문제 - 코딩 에이전트는 일반적으로 다음 순서로 작업합니다. - 요구사항 분석 - 계획 수립 - 구현 - 테스트 - 문제 발생 시 반복 수정 - 초기 계획의 잘못된 가정이나 비효율은 이후 구현의 기반이 되어 오류를 연쇄적으로 키울 수 있습니다. - 에이전트가 자신의 결과를 스스로 검토하는 방식도 도움이 되지만, 동일한 모델은 같은 학습 데이터와 편향, 맹점을 공유합니다. - 따라서 자기 검토만으로는 발견하기 어려운 문제를 찾기 위해 다른 모델 계열의 관점이 필요합니다. ## 다른 모델 계열을 활용하는 Rubber Duck - Rubber Duck은 주 에이전트의 계획과 작업을 검토하는 전문 리뷰 에이전트입니다. - 현재 Claude 모델을 주 오케스트레이터로 선택하면 Rubber Duck은 GPT-5.4를 사용합니다. - 검토 결과는 다음과 같은 고가치 우려 사항을 짧고 집중적으로 제시합니다. - 주 에이전트가 놓친 세부 사항 - 다시 검토해야 할 가정 - 잠재적인 엣지 케이스 - 현재 Claude Opus, Sonnet, Haiku를 주 모델로 사용할 때 활성화할 수 있으며, 향후 다른 모델 조합도 실험할 예정입니다. ## 복잡한 작업에서의 효과 - SWE-Bench Pro의 실제 오픈소스 프로젝트 기반 대형 코딩 문제로 평가했습니다. - Claude Sonnet 4.6과 GPT-5.4 Rubber Duck 조합은 Claude Opus 4.6 단독 실행과 유사한 해결률을 기록했습니다. - Sonnet과 Opus의 성능 차이 중 74.7%를 줄였습니다. - 특히 다음 조건의 작업에서 효과가 컸습니다. - 3개 이상의 파일을 수정하는 작업 - 70단계 이상이 필요한 장기 작업 - 복잡한 리팩터링과 아키텍처 변경 - 성능 개선 폭은 일반적으로 Sonnet 기준 3.8%, 가장 어려운 문제에서는 4.8%였습니다. ## Rubber Duck이 발견한 오류 사례 - **스케줄러의 구조적 오류** - 스케줄러가 시작 직후 종료되어 작업을 하나도 실행하지 못하는 문제를 발견했습니다. - 수정하더라도 내부 작업 중 하나가 무한 루프라는 추가 문제도 확인했습니다. - **반복문으로 인한 데이터 손실** - 반복문이 매번 같은 `dict` 키를 덮어쓰는 버그를 찾았습니다. - 그 결과 Solr 검색 요청에서 네 개의 facet 범주 중 세 개가 조용히 사라졌습니다. - **파일 간 데이터 흐름 단절** - 여러 파일이 Redis 키를 읽지만 새 코드가 해당 키를 더 이상 기록하지 않는 문제를 발견했습니다. - 배포 후 이메일 확인 UI와 정리 작업이 조용히 고장 날 수 있는 상황이었습니다. ## 검토가 실행되는 시점 Rubber Duck은 필요성이 높은 체크포인트에서 자동으로 호출되거나 사용자가 직접 요청할 수 있습니다. - **계획 작성 후** - 잘못된 설계 결정을 구현 전에 발견해 후속 오류의 누적을 막습니다. - **복잡한 구현 후** - 여러 파일에 걸친 코드의 엣지 케이스와 구조적 문제를 점검합니다. - **테스트 작성 후, 실행 전** - 테스트 커버리지의 공백이나 잘못된 단정을 찾아냅니다. - **에이전트가 작업 루프에 빠졌을 때** - 진전이 없는 상황에서 새로운 관점을 제공해 막힌 지점을 해결합니다. - **사용자 요청 시** - 사용자가 언제든 작업을 비판적으로 검토하도록 요청할 수 있습니다. - Copilot은 피드백을 반영한 뒤 무엇이 어떻게 바뀌었는지 보여줍니다. ## 사용 방법과 적합한 활용 사례 - GitHub Copilot CLI를 설치한 뒤 `/experimental` 명령으로 실험 기능을 활성화합니다. - 모델 선택기에서 Claude 모델을 선택하고 GPT-5.4 사용 권한이 있어야 합니다. - Rubber Duck은 자동으로 호출되거나 “작업을 검토해 달라”고 요청해 수동 실행할 수 있습니다. - 특히 다음 작업에 적합합니다. - 복잡한 리팩터링 - 아키텍처 변경 - 실패 비용이 큰 고위험 작업 - 테스트 커버리지 검증 - 구현 전 계획에 대한 독립적인 의견 확인 Rubber Duck은 코딩 에이전트를 단순히 더 오래 실행하는 대신, 서로 다른 모델 계열의 관점으로 중요한 의사결정을 교차 검증하려는 접근입니다. 복잡하거나 영향 범위가 큰 작업에서는 계획 단계와 테스트 실행 전에 검토를 요청하는 것이 실용적인 활용법입니다.

github

Copilot CLI에서 /fleet으로 여러 에이전트 동시에 실행하기 (새 탭에서 열림)

Copilot CLI의 `/fleet`는 하나의 작업을 여러 독립적인 하위 작업으로 나누고, 여러 에이전트를 병렬 실행하는 기능이다. 오케스트레이터가 작업의 의존성을 분석해 실행 순서를 정하고, 결과를 검증·통합하므로 여러 파일이나 모듈을 동시에 처리할 수 있다. 다만 에이전트들이 동일한 파일을 수정하면 잠금이나 자동 병합 없이 마지막 변경이 덮어쓰므로, 작업 범위와 파일 경계를 명확히 지정해야 한다. ## `/fleet`의 작동 방식 - 사용자가 `/fleet <작업 목표>` 형식으로 목표를 전달한다. - 오케스트레이터가 목표를 독립적인 작업 단위로 분해한다. - 작업 간 의존성을 분석해 병렬 실행 가능한 항목과 순차 실행해야 하는 항목을 구분한다. - 독립적인 작업은 백그라운드 하위 에이전트에 동시에 배정한다. - 작업 완료를 확인한 뒤 다음 의존 작업을 실행한다. - 각 결과를 검증하고 최종 산출물로 통합한다. - 하위 에이전트는 각자의 컨텍스트 창을 사용하지만 동일한 파일 시스템을 공유하며, 서로 직접 대화하지 않고 오케스트레이터를 통해 조정된다. ## 시작 방법 - 대화형 CLI에서는 다음과 같이 실행한다. ```text /fleet Refactor the auth module, update tests, and fix the related docs in the folder docs/auth/ ``` - 터미널에서 비대화형으로 실행할 수도 있다. ```bash copilot -p "/fleet <YOUR TASK>" --no-ask-user ``` - `--no-ask-user`는 사용자가 추가 질문에 응답할 수 없는 비대화형 환경에서 필요하다. ## 병렬화에 적합한 프롬프트 작성 - 작업마다 구체적인 산출물을 지정해야 한다. - 파일 - 테스트 스위트 - 문서 페이지 - 특정 모듈 - “문서를 작성하라”처럼 모호한 요청은 독립 작업을 식별하기 어려워 순차 실행될 가능성이 높다. - 예를 들어 인증, 엔드포인트, 오류 문서를 각각 별도 파일로 지정하면 세 작업은 병렬 처리할 수 있다. - 여러 문서를 연결하는 `docs/index.md`처럼 다른 결과물에 의존하는 작업은 후속 단계로 명시해야 한다. ## 파일 범위와 제약 조건 지정 프롬프트에는 각 에이전트가 담당할 범위를 명확히 적어야 한다. - 담당 디렉터리나 파일을 지정한다. - 수정해서는 안 되는 영역을 명시한다. - 테스트 변경 금지 - 의존성 업그레이드 금지 - 지정 디렉터리 외 수정 금지 - 완료 조건을 제시한다. - 린트 통과 - 타입 검사 통과 - 특정 테스트 통과 - API, UI, 설정처럼 서로 다른 영역을 별도 트랙으로 나누면 병렬 실행 효과가 커진다. ## 작업 의존성 선언 - 한 작업이 다른 작업의 결과를 필요로 하면 프롬프트에 `depends on` 관계를 명시한다. - 예를 들어 다음과 같이 데이터베이스 마이그레이션, ORM 모델, API 핸들러, 통합 테스트의 순서를 지정할 수 있다. - ORM 모델이 완성된 뒤 API 핸들러와 통합 테스트를 동시에 실행하도록 구성할 수 있다. - 의존성을 명시하지 않으면 에이전트가 충돌하거나 불완전한 결과를 바탕으로 작업할 수 있다. ## 사용자 지정 에이전트 활용 - `.github/agents/`에 전문 에이전트 설정 파일을 만들 수 있다. - 에이전트마다 다음을 지정할 수 있다. - 모델 - 사용 가능한 도구 - 역할과 작업 지침 - 문서 작성에는 `technical-writer` 같은 전문 에이전트를 사용하고, 코드 변경에는 기본 에이전트를 사용하는 식으로 역할을 나눌 수 있다. - 모델을 별도로 지정하지 않으면 현재 기본 모델이 사용된다. ## 병렬 실행 여부 확인 - 오케스트레이터가 작업을 여러 트랙으로 분해했는지 계획을 먼저 확인한다. - `/tasks` 명령으로 백그라운드 작업 목록과 진행 상태를 볼 수 있다. - 여러 트랙에서 동시에 진행 상황이 보고되는지 확인한다. - 병렬화되지 않는다면 다음처럼 먼저 분해하도록 요청할 수 있다. ```text Decompose this into independent tracks first, then execute tracks in parallel. Report each track separately with status and blockers. ``` ## 주요 주의점 - 하위 에이전트는 파일 잠금 기능 없이 동일한 파일 시스템을 공유한다. - 두 에이전트가 같은 파일을 수정하면 오류나 자동 병합 없이 마지막 완료 결과가 앞선 변경을 덮어쓸 수 있다. - 따라서 각 에이전트에 서로 다른 파일을 배정해야 한다. - 하나의 파일에 여러 에이전트가 기여해야 한다면: - 각자 임시 파일에 작성한 뒤 오케스트레이터가 병합하게 하거나 - 에이전트 실행 순서를 명시해야 한다. - 하위 에이전트는 오케스트레이터와의 이전 대화 기록을 볼 수 없으므로, 전달되는 프롬프트만으로 작업할 수 있도록 지침과 제약 조건을 self-contained하게 작성해야 한다. 실제로 `/fleet`를 사용할 때는 먼저 작업을 파일·모듈 단위로 분리하고, 의존성과 검증 조건을 프롬프트에 명시하는 것이 좋다. 특히 공유 파일을 여러 에이전트가 수정하지 않도록 범위를 엄격히 나누면 병렬 처리의 속도 이점과 결과 안정성을 함께 얻을 수 있다.

github

가까운 곳에서 열 (새 탭에서 열림)

소프트웨어 개발 전반이 AI 중심으로 빠르게 바뀌는 가운데, GitHub Copilot Dev Days는 개발자들이 GitHub Copilot을 실제 업무에 적용하는 방법을 함께 배우는 글로벌 오프라인 행사다. 초보자부터 숙련자까지 참여할 수 있으며, 라이브 데모와 실습을 통해 AI 보조 개발의 최신 도구와 모범 사례를 익히는 것이 목적이다. 행사는 2026년 3월부터 전 세계 여러 도시에서 열리며, 개발자 커뮤니티나 사용자 그룹이 직접 개최할 수도 있다. ## AI 보조 개발 역량을 함께 높이는 행사 - AI는 더 이상 미래의 도구가 아니라 코드 기획, 작성, 리뷰, 배포 방식에 이미 영향을 주고 있다. - 개발자는 빠르게 변화하는 개발 환경에 맞춰 AI 도구를 효과적으로 활용해야 한다. - Dev Days는 이러한 변화에 대응해 개발자들이 함께 학습하고 경험을 공유하도록 설계됐다. - 글로벌 시리즈이지만 각 행사는 지역 커뮤니티가 주도하는 대면 이벤트로 진행된다. ## 초보자부터 전문가까지 참여 가능 - 전문 개발자, 학생 등 다양한 배경의 참가자를 대상으로 한다. - AI 보조 개발을 처음 접하는 사람에게는 기본 도구와 성공적인 활용 방법을 소개한다. - 이미 Copilot을 사용 중인 개발자에게는 최신 기능, 팁, 활용 기법을 제공한다. - 행사별로 수준과 프로그래밍 언어, 주제가 다를 수 있으므로 등록 전에 세부 내용을 확인해야 한다. ## 실습 중심의 프로그램 - 라이브 데모, 실용적인 강의, 상호작용형 워크숍으로 구성된다. - GitHub Copilot CLI, Cloud Agent, VS Code, Visual Studio 및 기타 편집기 관련 교육 자료를 다룬다. - 일반적인 예시 일정은 다음과 같다. - GitHub Copilot 소개: 30~45분 - 지역 개발자 또는 커뮤니티 리더의 세션: 30~45분 - 코딩 실습과 실전 연습: 약 1시간 - GitHub Stars, Microsoft MVPs, GitHub Campus Experts, Microsoft Student Ambassadors, GitHub·Microsoft 직원 등이 진행자로 참여한다. - 행사마다 지역 개발자들의 관심사에 맞춰 일정과 주제가 조정될 수 있다. ## 지역 커뮤니티와의 교류 - 참가자는 Copilot 활용법뿐 아니라 지역 개발자들과 네트워킹할 수 있다. - 행사에는 음식, 간식, 기념품 등 커뮤니티 이벤트 요소도 포함된다. - 각 지역의 사용자 그룹은 공식 양식을 통해 Dev Days 개최를 신청할 수 있다. - 행사는 2026년 3월부터 전 세계 도시에서 시작되며, 좌석이 제한되어 있다. 가까운 지역에서 열리는 행사의 등록 페이지를 확인하고, 관심 있는 주제와 실습 환경이 포함되어 있다면 직접 참여하는 것이 좋다. 사용자 그룹을 운영한다면 자체 행사를 개최해 지역 개발자들에게 AI 보조 개발을 경험할 기회를 제공할 수 있다.

github

아이디어에서 풀 리퀘스트까지 (새 탭에서 열림)

GitHub Copilot CLI는 터미널에서 자연어로 아이디어를 구체화하고, 코드 작성·테스트·수정·Pull Request 생성까지 이어 주는 코딩 에이전트다. 다만 설계와 검토를 대신하는 도구가 아니라, 개발자의 판단 아래 반복 작업과 초기 구현을 빠르게 처리하는 도구로 활용해야 한다. CLI에서 빠르게 시작한 뒤 IDE에서 정교하게 다듬고 GitHub에서 협업·배포하는 흐름이 핵심이다. ## Copilot CLI의 역할과 한계 - 터미널에서 원하는 결과를 자연어로 설명할 수 있다. - `/plan` 또는 `Shift + Tab` planning mode로 작업 계획을 먼저 작성할 수 있다. - 명령어, 파일 변경, diff를 실행 전에 검토할 수 있다. - 사용자의 명시적인 승인 없이는 명령 실행이나 파일 변경을 수행하지 않는다. - 설계 결정과 코드 리뷰를 대체하지 않으며, 생성된 결과는 동료가 작성한 코드처럼 검토해야 한다. ## 의도에서 시작하는 프로젝트 설계 - 처음부터 프레임워크나 템플릿을 고르기보다 만들고 싶은 기능을 먼저 설명한다. - 예시: ```text Create a small web service with a single JSON endpoint and basic tests ``` - `copilot -p "..."`를 사용하면 단일 프롬프트로 제안 내용을 생성할 수 있다. - Copilot CLI는 기술 스택, 파일 구조, 초기화 명령 등을 제안하지만 자동으로 실행하지는 않는다. - 제안 내용을 검토한 뒤 실제 프로젝트 방향으로 채택할 항목을 선택한다. ## 필요한 만큼만 스캐폴딩하기 - 방향이 정해지면 최소한의 프로젝트 구조와 설정 파일을 생성하도록 요청한다. - 예시: ```text Scaffold this as a minimal Node.js project with a test runner and README ``` - 디렉터리, 설정, 테스트 러너, README 등 반복적인 보일러플레이트를 빠르게 만들 수 있다. - 생성된 구조는 일반적인 관례에 기반한 출발점일 뿐이며, 최종 설계로 받아들일 필요는 없다. - 불필요한 파일이나 설정은 직접 수정하거나 삭제해야 한다. ## 실패 지점에서 바로 반복하기 - 테스트를 CLI 내부에서 실행하고 실제 출력 결과를 바탕으로 다음 작업을 요청한다. - 예시: ```text Run all my tests and make sure they pass ``` ```text Why are these tests failing? ``` ```text Fix this test failure and show the diff ``` - `실행 → 결과 확인 → 원인 질문 → diff 검토`의 짧은 반복 주기가 중요하다. - 추상적인 설명보다 실제 테스트 실패나 명령 출력에 근거해 수정하도록 만들 수 있다. - 이해가 필요할 때는 `explain`, 구체적인 수정안을 원할 때는 `suggest`를 활용할 수 있다. ## 저장소 전체의 기계적 변경 - 이름 변경, 반복 패턴 수정, 테스트 갱신처럼 범위가 명확한 작업에 적합하다. - 예시: ```text Rename all instances of X to Y across the repository and update tests ``` - 작업 의도가 명확하고 변경 범위가 제한적이므로 diff 검토와 롤백이 쉽다. - 긴 생성 결과를 읽는 대신 저장소 전체에 적용된 구체적인 변경 내역을 확인할 수 있다. ## CLI에서 IDE로 정교하게 다듬기 - 초기 구현과 반복 작업이 끝나면 IDE로 이동해 코드의 정확성과 설계를 개선한다. - IDE에서는 다음과 같은 작업에 집중한다. - 예외 상황과 엣지 케이스 검토 - API 구조 개선 - 복잡한 비즈니스 로직 결정 - 리뷰에서 설명하고 책임질 설계 선택 - CLI는 낮은 형식 비용으로 빠르게 실제 결과물을 만드는 데 적합하다. - IDE는 코드를 원하는 수준으로 정제하고 장기적으로 유지 가능한 형태로 만드는 데 적합하다. ## 커밋과 Pull Request로 마무리하기 - 변경 사항을 커밋하고 push하는 작업도 자연어로 요청할 수 있다. - 예시: ```text Add and commit all files with applicable descriptive messages, push the changes. ``` - Pull Request를 생성하고 Copilot을 리뷰어로 추가할 수도 있다. - GitHub로 작업을 넘기면 결과물이 다음 단계로 연결된다. - 팀원이 검토할 수 있음 - CI에서 테스트할 수 있음 - 비동기 방식으로 수정·협업할 수 있음 - Copilot의 가치는 단순한 코드 제안보다 커밋, Pull Request, 리뷰까지 이어지는 전체 개발 흐름에서 커진다. ## CLI·IDE·GitHub의 역할 분담 - **CLI:** 아이디어를 빠르게 검증하고, 계획·스캐폴딩·테스트·기계적 변경을 수행한다. - **IDE:** 로직을 정밀하게 다듬고 설계와 엣지 케이스를 결정한다. - **GitHub:** 코드 리뷰, CI, 협업, Pull Request 병합과 배포를 진행한다. Copilot CLI는 개발자의 판단을 대체하기보다, 의도에서 검토 가능한 변경 사항까지 도달하는 시간을 줄이는 도구로 사용하는 것이 가장 효과적이다. generated code와 diff를 항상 직접 확인하고, 정밀한 설계가 필요한 순간에는 IDE와 팀 리뷰로 넘기는 방식을 권장한다.