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에 넘기는 방식이 효과적이다. 자동 구현을 사용하더라도 테스트와 변경 내용을 직접 검토해 결과를 확인하는 것이 좋다.