copilot-cli

GitHub Copilot 앱의 슬래시 명령어 가이드 (새 탭에서 열림)

GitHub Copilot 앱의 슬래시 명령어는 채팅 입력창에서 `/`로 시작해 세션 관리, 프로젝트 탐색, 작업 모드 전환을 빠르게 수행하도록 돕는다. CLI가 터미널과 디렉터리·작업 경로 관리에 초점을 둔다면, 앱의 명령어는 시각적 인터페이스와 멀티 세션 워크플로에 맞춰 계획 수립, 비판적 검토, 자동 구현 등을 지원한다. 특히 `/plan`으로 작업을 설계하고 `/spar`로 위험을 검토한 뒤 `/autopilot`으로 구현하는 흐름이 핵심이다. ## 슬래시 명령어의 개념과 앱·CLI의 차이 - 채팅 입력창에 `/`를 입력하면 현재 상황에서 사용할 수 있는 명령어 자동완성 메뉴가 표시된다. - CLI 명령어는 터미널 중심으로 설계되어 디렉터리 추가(`/add-dir`), 작업 디렉터리 변경(`/cwd`) 등을 담당한다. - Copilot 앱은 프로젝트 컨텍스트와 파일 접근을 시각적으로 관리하므로 `/add-dir`, `/cwd` 같은 명령어가 필요하지 않다. - 앱에서는 세션 이동, 프로젝트 관리, 에이전트 작업 방식 제어 등 워크플로 중심의 명령어를 제공한다. - `/clear`, `/model`처럼 CLI와 앱에서 공통으로 사용할 수 있는 명령어도 있다. ## `/plan`으로 코딩 전에 작업 설계 `/plan`은 구현에 앞서 작업을 분석하고 단계별 계획을 세우는 명령어다. 실행하면 세션이 **Plan 모드**로 전환되며, 채팅 입력창의 **Mode** 메뉴에서도 같은 모드를 선택할 수 있다. - 새 기능 개발: - 변경이 필요한 파일, 컴포넌트, 의존성을 파악한다. - 예: `/plan`으로 2단계 인증 도입에 필요한 작업과 구현 순서를 정리한다. - 대규모 리팩터링: - 복잡한 코드 변경의 범위와 위험 요소를 확인한다. - 한 번에 전환하지 않고 점진적으로 마이그레이션할 방법을 수립한다. - 버그 조사: - 원인이 불명확한 장애의 가능한 원인을 탐색한다. - 진단 절차와 수정 작업을 단계별로 계획한다. ## `/spar`로 가정과 설계 검증 `/spar`는 Copilot이 반대 의견을 제시하도록 해 설계의 허점, 위험, 트레이드오프를 검토하는 명령어다. - 아키텍처 선택 검증: - Redis 캐시의 무효화 전략, 확장성, 일관성 문제 등을 점검한다. - 구현 방식 비교: - REST와 GraphQL, 동기 처리와 비동기 처리처럼 여러 접근법의 장단점을 비교한다. - 애플리케이션 요구사항에 맞는 선택을 추천하도록 요청할 수 있다. - 마이그레이션 계획 검토: - 데이터베이스나 인프라 이전 과정의 엣지 케이스와 배포 위험을 찾는다. - 무중단 또는 최소 다운타임 조건에서 발생할 문제를 미리 점검한다. - 성능 최적화 비판: - 지연 로딩 등 최적화가 사용자 경험을 해치거나 불필요한 복잡성을 만들 가능성을 확인한다. - 숨은 병목과 부작용, 더 단순한 대안을 함께 검토한다. ## `/autopilot`으로 구현 자동화 `/autopilot`은 계획한 목표를 바탕으로 여러 구현 단계를 Copilot이 직접 수행하도록 하는 명령어다. 실행하면 세션이 **Autopilot 모드**로 전환되며, Mode 메뉴에서도 선택할 수 있다. - 새 기능 구현: - 필요한 파일을 식별하고 코드를 수정한다. - 관련 테스트를 추가하거나 업데이트하도록 요청할 수 있다. - 예: 사용자 보고서를 CSV로 내보내는 기능을 설계부터 구현까지 진행한다. - 대규모 유지보수: - 의존성 업데이트, 리팩터링, 문서 개선처럼 여러 단계가 필요한 작업에 적합하다. - React 버전 업그레이드 시 호환성 문제를 수정하고 테스트 통과 여부까지 확인하도록 할 수 있다. - 사용자는 세부 단계마다 지시하기보다 최종 목표와 제약 조건을 전달하는 방식으로 작업할 수 있다. ## `/rubber-duck`로 문제를 대화형 검토 `/rubber-duck`는 문제를 설명하고 다른 관점에서 검토받는 디버깅 지원 명령어다. - Copilot이 별도의 모델을 사용해 독립적으로 검토하는 방식으로 소개된다. - 혼자 문제를 설명하며 사고를 정리하는 ‘러버 덕 디버깅’ 과정을 Copilot과 수행할 수 있다. - 제공된 글 내용은 이 명령어 설명 중간에서 끝나므로, 구체적인 사용 예와 전체 동작 방식은 확인할 수 없다. 실무에서는 먼저 `/plan`으로 범위와 순서를 정리하고, `/spar`로 설계의 위험을 검증한 다음, 충분히 구체화된 작업을 `/autopilot`에 넘기는 방식이 효과적이다. 자동 구현을 사용하더라도 테스트와 변경 내용을 직접 검토해 결과를 확인하는 것이 좋다.

더 나은 도구가 Copilot 코드 리뷰를 악화시켰습니다. 실제로 개선한 방법은 다음과 같습니다. (새 탭에서 열림)

더 나은 코드 탐색 도구를 도입했지만, GitHub Copilot 코드 리뷰의 비용은 오히려 증가하고 발견하는 문제는 줄어들었다. 원인은 `grep`, `glob`, `view` 자체가 아니라, 코딩 에이전트용으로 작성된 도구 지침을 리뷰 작업에 그대로 적용한 데 있었다. 리뷰어처럼 PR diff에서 출발해 필요한 최소한의 코드만 확인하도록 지침을 바꾸자, 리뷰 품질을 유지하면서 평균 비용을 약 20% 낮출 수 있었다. ## 도구 교체가 예상과 다른 결과를 낳은 이유 - 기존 Copilot 코드 리뷰는 자체 코드 탐색 도구를 사용했다. - `list_dir`: 디렉터리 탐색 - `search_file`, `search_dir`: 파일 및 디렉터리 검색 - `read_code`: 코드 읽기 - 이 도구들은 검색 결과나 지정한 코드 범위뿐 아니라 주변 코드도 함께 반환했다. - 토큰 비용은 증가하지만, 도구 호출 횟수가 적고 자동으로 맥락을 확보하기 어려운 초기 모델에는 유용했다. - Copilot CLI는 여러 제품이 공유하는 Unix 스타일 도구를 제공했다. - `glob`: 후보 파일과 디렉터리 탐색 - `grep`: 텍스트, 심벌, 호출 지점 검색 - `view`: 특정 파일이나 코드 범위 읽기 - 인프라를 통합하면 도구 구현 중복을 줄이고, CLI와 클라우드 에이전트의 개선 사항을 코드 리뷰에도 공유할 수 있다는 장점이 있었다. - 그러나 단순히 기존 도구를 새 도구로 치환하는 방식으로는 충분하지 않았다. ## 벤치마크에서 드러난 성능 저하 - 공유 도구를 적용한 오프라인 벤치마크에서 다음 문제가 나타났다. - 평균 리뷰 비용 증가 - 유용한 리뷰 댓글 감소 - 전체적으로 효율성과 효과성 모두 저하 - 내부 추적 데이터는 최종 점수뿐 아니라 에이전트의 탐색 과정도 보여줬다. - 어떤 도구를 호출했는지 - 각 호출이 얼마나 많은 결과를 반환했는지 - 오류가 발생했는지 - 탐색이 문제의 증거로 좁혀졌는지, 아니면 범위를 넓혔는지 - 이를 통해 도구가 오작동한 것이 아니라, 에이전트가 도구를 사용하는 방식이 문제였음이 드러났다. ## 코드 리뷰가 저장소 탐색으로 변한 문제 - 에이전트는 PR의 변경 사항을 분석하기보다 저장소 전체를 이해하려는 것처럼 행동했다. - 전형적인 흐름은 다음과 같았다. - 넓게 검색 - 경로를 추측 - 많은 파일을 읽음 - 새로 발견한 내용을 바탕으로 다시 검색 - 불필요한 맥락을 계속 누적 - 이런 방식은 “저장소를 이해하거나 기능을 구현하라”는 작업에는 적합할 수 있다. - 하지만 코드 리뷰의 목적은 저장소 전체를 파악하는 것이 아니라, 변경 사항이 실제 문제를 만들었는지 판단하는 것이다. - 도구 결과는 일회성 출력이 아니다. - 반환된 파일 내용은 에이전트의 컨텍스트에 남는다. - 불필요한 코드는 이후 추론 비용을 높인다. - 관련 없는 정보가 많아지면 리뷰의 초점도 흐려질 수 있다. ## 코딩 에이전트와 코드 리뷰어의 탐색 방식 차이 - 일반적인 코딩 에이전트는 변경 전에 넓은 영역을 파악할 수 있다. - 다른 코드에 미칠 영향을 확인하기 위해 저장소 구조를 폭넓게 탐색한다. - 계획 수립, 파일 수정, 여러 차례의 대화형 작업을 전제로 한다. - 코드 리뷰어는 보통 훨씬 좁은 질문에서 시작한다. - 이 함수는 어디에서 호출되는가? - 이 설정 키가 다른 곳에서도 사용되는가? - 같은 패턴의 테스트나 헬퍼가 존재하는가? - 이 동작을 설명하는 데 필요한 가장 작은 코드 범위는 무엇인가? - 따라서 리뷰 에이전트는 다음 순서를 따라야 한다. - PR diff에서 출발 - 변경된 코드가 일으킬 수 있는 구체적인 의문을 제기 - 해당 의문을 검증할 최소한의 주변 코드만 탐색 - 문제의 증거가 부족하면 탐색을 확장하지 않고 결론 ## 도구보다 중요한 지침과 워크플로 - Copilot CLI와 클라우드 에이전트의 도구 지침은 대화형 코딩 작업에 맞춰져 있었다. - 동일한 `grep`, `glob`, `view`라도 지침이 다르면 에이전트의 행동이 달라진다. - 기존 지침은 넓은 저장소 탐색을 유도했지만, 코드 리뷰에는 다음 원칙이 필요했다. - 변경된 diff를 탐색의 중심으로 삼기 - 파일 경로를 추측하기보다 diff에서 확인된 심벌과 호출 관계를 활용하기 - 전체 파일보다 필요한 코드 범위만 읽기 - 새 정보를 얻을 때마다 탐색을 무작정 넓히지 않기 - 실제 문제를 판단하는 데 필요한 증거만 컨텍스트에 추가하기 - 지침을 리뷰 작업의 특성에 맞게 다시 작성한 결과, 도구는 그대로 유지하면서도 리뷰 비용을 약 20% 절감했다. - 글에서는 이 개선이 리뷰 품질을 유지한 상태에서 이루어졌다고 설명한다. ## 실용적인 결론 에이전트 도구를 교체할 때는 도구의 기능만 비교해서는 안 된다. 도구 사용 지침과 에이전트가 따라야 할 탐색 워크플로까지 작업 목적에 맞게 설계해야 하며, 특히 코드 리뷰에서는 “더 많이 읽기”보다 “변경 사항을 검증하는 데 필요한 최소한만 읽기”가 비용과 품질 모두에 유리하다.

Copilot Applied Science의 에이전트 주도 개발 (새 탭에서 열림)

GitHub Copilot Applied Science 팀의 Tyler McGoffin은 코딩 에이전트를 활용해 벤치마크 결과 분석에 필요한 지적 반복 작업을 자동화한 프로젝트 `eval-agents`를 만들었다. 핵심은 에이전트를 단순한 코드 생성기가 아니라 계획·구현·검증에 참여하는 협업자로 활용하고, 에이전트가 기여하기 쉬운 저장소 구조를 만드는 것이다. 그 결과 3일도 안 되어 5명이 11개 에이전트와 4개 스킬을 추가하고, 345개 파일에 걸쳐 약 2만 8천 줄의 변경을 만들어냈다. ## 반복적인 벤치마크 분석에서 `eval-agents` 탄생 - 연구자는 TerminalBench2, SWEBench-Pro 같은 코딩 에이전트 평가 벤치마크를 분석한다. - 각 평가 작업은 에이전트의 사고 과정과 행동을 담은 trajectory로 기록되며, 대개 수백 줄의 `.json` 파일로 저장된다. - 수십 개 작업과 여러 번의 벤치마크 실행을 합치면 분석 대상이 수십만 줄에 달한다. - 기존에는 Copilot으로 trajectory에서 패턴을 먼저 찾은 뒤 사람이 직접 조사해 읽어야 할 분량을 수백 줄로 줄였다. - 이 반복 과정을 에이전트가 자동 수행하도록 만든 도구가 `eval-agents`다. ## 프로젝트 설계 목표 - 에이전트를 쉽게 공유하고 사용할 수 있도록 구성한다. - 새로운 에이전트를 쉽게 작성할 수 있도록 한다. - 사람보다 코딩 에이전트가 프로젝트 기여의 주요 수단이 되도록 설계한다. - 특히 세 번째 목표를 적용하자 프로젝트 자체의 사용성과 협업성도 함께 좋아졌다. - 과학자와 엔지니어가 각자의 필요에 맞는 에이전트와 기능을 직접 추가할 수 있는 기반이 마련됐다. ## 코딩 에이전트를 중심으로 한 개발 환경 - 코딩 에이전트: Copilot CLI - 사용 모델: Claude Opus 4.6 - IDE: VS Code - Copilot SDK를 사용해 Copilot CLI의 도구, MCP 서버, 사용자 정의 도구와 스킬 등록 기능을 재활용했다. - 에이전트 실행 기반을 직접 처음부터 만들지 않아도 되어 에이전트 생성 속도를 높일 수 있었다. ## 효과적인 프롬프트 전략 - 에이전트는 범위가 명확한 작업에는 강하지만, 복잡하고 고차원적인 문제에는 충분한 안내가 필요하다. - 짧은 요구사항보다 문제를 고민하는 과정, 전제, 우려 사항을 자세히 설명하는 대화형 프롬프트가 효과적이다. - 바로 구현을 지시하기보다 계획 모드에서 조사와 설계를 먼저 진행하게 하는 것이 좋다. - 예를 들어 테스트가 에이전트의 변경에 맞춰 부적절하게 수정되는 문제를 해결하기 위해, 계획 모드에서 에이전트가 건드릴 수 없는 보호된 테스트 영역을 설계하도록 했다. - 그 대화의 결과로 사람이 승인해야만 수정할 수 있는 계약 테스트와 유사한 회귀 방지 장치가 만들어졌다. - 결론적으로 효과적인 인간 엔지니어에게 필요한 설명, 사고 유도, 검토 과정이 에이전트에도 동일하게 중요하다. ## 에이전트 우선 저장소를 위한 아키텍처 전략 - 에이전트 중심 프로젝트에서는 새 기능보다 코드 구조 개선, 리팩터링, 문서화, 테스트 작성이 더 중요한 기반 작업이 된다. - 명확한 이름과 파일 구조는 에이전트가 코드를 탐색하고 변경하기 쉽게 만든다. - 기능과 패턴을 문서화하면 에이전트가 프로젝트의 규칙과 설계 의도를 더 잘 따를 수 있다. - 발견된 문제를 테스트 케이스로 남기면 이후 에이전트의 변경으로 인한 회귀를 방지할 수 있다. - 에이전트가 기능을 빠르게 추가할수록 사람이 죽은 코드와 불필요한 복잡성을 정리하는 작업도 병행해야 한다. - 잘 관리된 저장소에서는 Copilot을 통한 기능 전달이 쉬워지므로, 과거에 미뤄두었던 유지보수 작업이 개발 생산성의 핵심 요소가 된다. ## 짧은 기간에 이루어진 협업 성과 - 처음 참여한 팀원 5명이 3일 이내에 프로젝트에 기여했다. - 새로 추가된 항목: - 에이전트 11개 - 스킬 4개 - 과학자의 추론 흐름을 표현하는 `eval-agent workflows` - 전체 변경 규모는 345개 파일에서 `+28,858/-2,884`줄이었다. - 이는 에이전트에게 적절한 개발 환경과 구조를 제공하면 새로운 기능과 협업을 매우 빠르게 확장할 수 있음을 보여준다. 에이전트를 효과적으로 활용하려면 좋은 프롬프트만으로는 부족하다. 계획 모드와 상세한 대화를 적극 활용하고, 문서·테스트·리팩터링을 지속해 에이전트가 이해하기 쉬운 저장소를 유지하는 것이 실용적인 출발점이다.

GitHub Copilot 코딩 에 (새 탭에서 열림)

GitHub Copilot coding agent는 이슈를 할당받아 백그라운드에서 코드를 수정하고 테스트를 추가한 뒤, 검토 가능한 풀 리퀘스트를 생성하는 기능이다. 최근에는 작업별 모델 선택, 자체 코드 리뷰, 보안 검사, 사용자 정의 에이전트, 로컬 CLI와의 컨텍스트 공유가 추가되어 자동화 수준과 결과 품질이 향상됐다. GitHub는 향후 비공개 모드, 코딩 전 계획 수립, 이슈 요약과 보고서 생성까지 기능을 확장할 예정이다. ## 작업에 맞는 AI 모델 선택 Agents 패널에서 작업별로 사용할 모델을 지정할 수 있게 됐다. - 단순한 단위 테스트 추가에는 빠른 모델을 선택할 수 있다. - 복잡한 리팩터링이나 엣지 케이스가 많은 통합 테스트에는 더 강력한 모델을 사용할 수 있다. - `Auto`를 선택하면 GitHub가 작업에 적합한 모델을 자동으로 결정한다. - 사용 방법: - GitHub 우측 상단의 Agents 패널에서 저장소를 선택한다. - 모델을 고르고 작업 프롬프트를 입력한다. - 현재 Copilot Pro와 Pro+에서 사용할 수 있으며, Business와 Enterprise 지원은 추후 제공될 예정이다. ## 자체 코드 리뷰로 개선된 풀 리퀘스트 에이전트가 풀 리퀘스트를 열기 전에 Copilot code review를 실행해 자신의 변경 사항을 점검한다. - 코드가 동작하더라도 지나치게 복잡하거나 팀의 일반적인 작성 방식과 다른 부분을 찾아낸다. - 리뷰 피드백을 반영해 코드를 수정한 뒤 풀 리퀘스트를 생성한다. - 개발자는 에이전트의 작업 로그에서 코드 리뷰 실행과 수정 과정을 확인할 수 있다. - 사용자는 에이전트가 반복 작업을 마친 후 최종 풀 리퀘스트를 검토하면 된다. ## 작업 중 실행되는 보안 검사 Copilot coding agent는 작업 과정에서 생성된 코드를 대상으로 여러 보안 검사를 수행한다. - Code scanning으로 취약한 코드 패턴을 탐지한다. - Secret scanning으로 API 키나 비밀 값이 커밋되는지 확인한다. - 의존성 취약점 검사를 통해 알려진 CVE가 포함된 패키지를 탐지한다. - 검사 결과는 세션 로그에 표시되며, 풀 리퀘스트가 열리기 전에 문제를 확인할 수 있다. - 일반적으로 GitHub Advanced Security에 포함되는 code scanning을 Copilot coding agent에서는 별도 비용 없이 제공한다. ## 팀 규칙을 반영하는 사용자 정의 에이전트 사용자 정의 에이전트를 사용하면 팀의 개발 절차와 전문 작업 방식을 파일로 명시할 수 있다. - 저장소의 `.github/agents/` 아래에 에이전트 설정 파일을 만든다. - 특정 에이전트에 작업 범위와 수행 절차를 부여할 수 있다. - 예를 들어 성능 최적화 에이전트가 다음 순서로 동작하도록 만들 수 있다. - 먼저 벤치마크를 실행한다. - 특정 코드를 수정한다. - 변경 후 성능을 다시 측정한다. - 결과와 함께 풀 리퀘스트를 생성한다. - 조직이나 엔터프라이즈 전체에서 사용자 정의 에이전트를 공유할 수 있어 팀별 작업 방식의 일관성을 높인다. - 실제 데모에서는 조회 함수의 성능을 측정한 뒤 수정해 해당 함수에서 99% 개선을 달성했다. ## 클라우드와 로컬 CLI 간 작업 연속성 클라우드에서 시작한 작업을 로컬 터미널로 이어가거나, 로컬 작업을 클라우드 에이전트에 위임할 수 있다. - “Continue in Copilot CLI”를 선택하면 브랜치, 로그, 대화 컨텍스트가 유지된 채 로컬에서 작업을 이어간다. - CLI에서 `&`를 누르면 현재 작업을 클라우드로 다시 위임할 수 있다. - 클라우드와 로컬 사이를 이동할 때 대화를 처음부터 다시 설명할 필요가 없다. - 터미널 중심 개발과 GitHub 기반 자동화를 유연하게 결합할 수 있다. ## 앞으로의 확장 방향 GitHub는 Copilot coding agent를 단순한 풀 리퀘스트 생성 도구 이상으로 확장하려 하고 있다. - 비공개 모드 지원 - 코딩 전에 작업 계획을 세우는 기능 - 풀 리퀘스트가 필요 없는 이슈 요약 - 자동 보고서 생성 팀의 반복적인 개발 작업에는 사용자 정의 에이전트와 적절한 모델 선택을 적용하고, 보안 검사와 자체 리뷰 결과를 확인하는 방식으로 활용하는 것이 좋다. 복잡한 작업은 클라우드에서 위임하고 세부 수정은 CLI에서 이어가는 방식도 효과적이다.