슬래시 명령은 무엇이 달라졌나

GitHub Copilot 앱의 슬래시 명령은 채팅 입력창에서 /로 시작하는 텍스트 단축 명령이다. 입력창에 /를 넣으면 현재 작업 맥락에서 사용할 수 있는 명령이 자동 완성 메뉴에 나타난다. 설정 화면이나 여러 메뉴를 오가지 않고 계획 수립, 검토, 구현 같은 작업 흐름을 바로 호출하는 것이 핵심이다.

비슷한 기능을 GitHub Copilot CLI에서 사용해 본 개발자라면 차이를 먼저 이해할 필요가 있다. CLI 명령은 터미널을 중심으로 디렉터리 추가, 작업 디렉터리 설정, 터미널 접근 관리 등을 처리한다. 반면 Copilot 앱은 파일과 프로젝트 맥락을 시각적 인터페이스에서 관리하므로 /add-dir이나 /cwd 같은 파일 접근 명령의 필요성이 작다. 앱의 명령은 여러 세션을 오가거나 프로젝트를 관리하고, 에이전트가 작업하는 방식을 바꾸는 데 더 초점을 맞춘다.

/clear와 /model처럼 CLI와 앱 양쪽에서 볼 수 있는 명령도 있지만, 모든 명령이 같은 환경에서 동일하게 제공된다고 가정해서는 안 된다. 계정, 앱 버전, 선택한 프로젝트, 현재 세션의 모드에 따라 표시되는 명령이 달라질 수 있으므로 실제 입력창에서 /를 입력해 나타나는 목록을 기준으로 확인하는 편이 정확하다.

명령별로 어디에 써야 하나

/plan: 코드를 바꾸기 전에 작업을 구조화한다

/plan은 구현에 바로 들어가기 전에 해야 할 일을 나누고, 관련 파일과 구성 요소, 의존성, 예상 위험을 살펴보는 명령이다. 이 명령을 실행하면 세션이 Plan 모드로 전환된다. 같은 모드는 채팅 입력창의 모드 선택 메뉴에서도 고를 수 있으므로, 명령은 기능 자체를 새로 만드는 것보다 전환 시간을 줄이는 단축 경로에 가깝다.

새 기능을 추가할 때는 요구사항을 파일 단위 작업으로 분해하는 데 활용할 수 있다. 예를 들어 이중 인증을 도입하려면 인증 흐름, 사용자 설정, 데이터 저장, 복구 절차, 테스트에 어떤 변경이 필요한지 먼저 나열하도록 요청할 수 있다. 대규모 리팩터링에서는 현재 구조와 변경 목표를 설명하고, 한 번에 전환하지 않는 단계별 이전 방안을 만들어 달라고 요청하는 방식이 적합하다.

원인이 분명하지 않은 장애에도 사용할 수 있다. 결제 처리 후 일부 요청이 간헐적으로 실패한다면 곧바로 수정 코드를 만들게 하기보다, 가능한 원인과 관측해야 할 로그, 재현 조건, 점검 순서를 먼저 제안하게 하는 편이 안전하다. 다만 Copilot이 만든 계획은 저장소의 실제 실행 상태나 운영 환경을 자동으로 증명하는 문서가 아니다. 계획에 언급된 파일이 존재하는지, 의존 관계가 맞는지, 테스트와 롤백 단계가 포함됐는지는 사람이 다시 확인해야 한다.

/spar: 결정하기 전에 반대 논리를 요청한다

/spar는 사용자의 접근법을 지지하는 답만 만드는 대신, 가정과 위험을 비판적으로 검토하도록 요청하는 명령이다. 설계 결정을 이미 내린 뒤 형식적으로 확인받기보다, 아직 수정 비용이 낮을 때 반례와 절충안을 찾는 용도로 적합하다.

Redis를 캐시 계층으로 도입하려는 경우에는 캐시 무효화, 일관성, 장애 시 동작, 예상 부하가 설계에 반영됐는지 질문하게 할 수 있다. REST와 GraphQL을 비교할 때도 유행이나 일반적인 장단점만 묻기보다 모바일 클라이언트 수, 응답 형태, 캐시 전략, 운영 복잡도 같은 현재 서비스 조건을 함께 제공해야 유용한 검토가 나온다.

데이터베이스 이전이나 인프라 변경에서는 중단 시간을 줄이는 절차, 데이터 동기화, 전환 시점, 실패 시 복귀 경로를 공격적으로 점검하게 할 수 있다. 성능 최적화에서는 초기 로딩 개선만 보지 말고 사용자 경험 악화, 지연된 오류, 번들 분할 비용, 유지보수 복잡도 같은 부작용을 찾도록 요청할 수 있다. 이 명령의 가치는 정답을 대신 결정하는 데 있지 않고, 놓친 질문을 작업 전에 표면으로 끌어내는 데 있다.

/autopilot: 계획을 여러 단계의 구현으로 연결한다

/autopilot은 목표를 받은 뒤 필요한 구현 단계를 이어서 수행하도록 하는 명령이며, 세션을 Autopilot 모드로 전환한다. 새 기능 구현, 여러 파일에 걸친 유지보수, 의존성 업데이트, 리팩터링, 문서와 테스트 수정처럼 단계가 연속되는 작업에 맞는다.

예를 들어 사용자 보고서를 CSV로 내보내는 기능을 요청할 때 관련 파일 식별, 기능 구현, 테스트 갱신을 하나의 목표로 전달할 수 있다. 프레임워크 버전 업데이트라면 변경 사항 조사, 코드 수정, 테스트 실행까지 묶어 요청할 수 있다. 그러나 자동으로 여러 단계를 수행한다는 점은 검토가 필요 없다는 뜻이 아니다. 변경 범위가 넓을수록 별도 브랜치, 깨끗한 작업 트리, 재현 가능한 테스트, 명확한 중단 조건이 중요해진다.

특히 운영 설정, 데이터 마이그레이션, 인증과 권한, 배포 파이프라인처럼 실패 비용이 큰 영역에서는 처음부터 전체 작업을 맡기지 않는 편이 낫다. 작은 샘플 저장소나 제한된 모듈에서 결과를 확인한 뒤 범위를 넓혀야 한다. 생성된 변경 사항은 diff로 검토하고, 테스트 통과 여부뿐 아니라 요구사항 누락, 보안 영향, 성능 저하, 되돌리기 가능성까지 확인해야 한다.

실제 작업 흐름에서는 어떻게 조합할까

세 명령은 서로 대체하는 기능보다 작업의 서로 다른 단계에 가깝다. 먼저 /plan으로 변경 범위와 순서를 만들고, /spar로 계획의 취약점과 반례를 찾은 뒤, 검토가 끝난 항목을 /autopilot으로 구현하는 흐름을 구성할 수 있다. 규모가 큰 작업이라면 전체 계획을 한 번에 실행하지 말고, 검증 가능한 단위로 잘라 같은 흐름을 반복하는 것이 좋다.

  1. 목표와 제외 범위를 적는다. 무엇을 바꿀지뿐 아니라 이번 작업에서 건드리지 않을 영역도 명확히 한다.
  2. /plan으로 변경 지도를 만든다. 관련 파일, 의존성, 테스트, 예상 위험과 롤백 지점을 포함하도록 요청한다.
  3. /spar로 가정을 검증한다. 실패 상황, 데이터 일관성, 보안, 운영 복잡도, 더 단순한 대안을 질문하게 한다.
  4. 사람이 계획을 승인 가능한 단위로 줄인다. 각 단계가 독립적으로 테스트되고 되돌려질 수 있는지 확인한다.
  5. /autopilot으로 제한된 범위를 구현한다. 수정 파일과 허용 작업을 지정하고 결과를 diff와 테스트로 검증한다.

개인 프로젝트에서는 이 흐름이 과도해 보일 수 있지만, 의존성 업데이트나 인증 변경처럼 문제가 뒤늦게 드러나는 작업에는 유용하다. 학생은 과제의 정답을 대신 생성하게 하기보다 설계 선택의 이유와 반례를 설명하게 하는 방식으로 활용할 수 있다. 연구자는 분석 코드와 재현 절차를 분리하고, 원자료나 민감한 연구 데이터가 입력되는지 먼저 점검해야 한다. 팀 개발자는 명령 결과를 승인 기록으로 간주하지 말고 기존 코드 리뷰와 CI 정책 안에서 검증해야 한다.

도입 가치가 있는지 판단하는 기준

슬래시 명령의 장점은 새로운 능력 하나보다 자주 쓰는 작업 흐름에 빠르게 접근할 수 있다는 데 있다. 따라서 명령 수가 많다는 이유만으로 도입 가치를 평가하기보다, 반복되는 계획 작성과 검토, 구현 전환에서 실제로 시간을 줄이는지 측정해야 한다. 같은 일을 일반 채팅 요청이나 기존 IDE 기능으로 충분히 처리하고 있다면 즉시 작업 방식을 바꿀 필요는 없다.

항목 확인할 질문 선택 기준
사용 가능 범위 내 계정과 앱 버전, 현재 프로젝트에서 필요한 명령이 표시되는가? 입력창의 자동 완성 목록에서 실제 제공 여부를 확인한다.
요금과 사용량 현재 Copilot 이용 조건에서 추가 제한이나 사용량 영향이 있는가? 공식 가격표와 계정 관리 화면을 확인한 뒤 기존 비용과 비교한다.
권한 명령 실행 중 어떤 파일과 도구, 저장소에 접근할 수 있는가? 최소 권한으로 시작하고 업무 저장소의 정책과 충돌하면 보류한다.
데이터 소스 코드, 로그, 개인정보, 연구 자료가 어떤 방식으로 처리되는가? 조직의 데이터 보존 및 외부 서비스 이용 기준을 먼저 적용한다.
검증 생성된 계획과 변경을 테스트하고 되돌릴 수 있는가? diff, 자동 테스트, 수동 검토, 롤백 절차가 준비된 작업부터 적용한다.
기존 대안 일반 채팅, IDE 기능, 이슈 템플릿, 스크립트로 같은 결과를 얻을 수 있는가? 전환 비용보다 반복 작업 절감 효과가 클 때 범위를 넓힌다.

적용 전에 꼭 확인할 점

  • 자동 완성 목록을 기준으로 판단한다. 블로그에 소개된 명령이 모든 세션과 계정에서 똑같이 보인다고 가정하지 않는다.
  • 작업 트리를 먼저 확인한다. 아직 커밋하지 않은 개인 변경과 자동 수정이 섞이지 않도록 작업 범위를 분리한다.
  • 쓰기 권한을 제한한다. 처음에는 작은 저장소나 테스트용 브랜치에서 실행하고 운영 환경 접근을 피한다.
  • 계획과 사실을 구분한다. Copilot이 언급한 파일, API, 의존성, 장애 원인은 저장소와 공식 문서에서 재확인한다.
  • 완료 조건을 명시한다. 테스트 통과, 변경 파일 범위, 성능 기준, 보안 검사처럼 멈출 기준을 요청에 포함한다.
  • 비용과 정책을 별도로 확인한다. 제공된 소개만으로 요금, 사용량 제한, 데이터 보존 조건을 확정할 수 없으므로 적용 시점의 공식 문서를 살핀다.

자주 묻는 질문

슬래시 명령을 쓰면 일반 채팅보다 답변 품질이 좋아지나?

항상 그렇다고 단정할 수는 없다. 슬래시 명령은 특정 작업 모드와 흐름에 빠르게 접근하도록 돕는다. 결과 품질은 제공한 맥락, 요구사항의 구체성, 저장소 상태, 검증 절차에 크게 좌우된다. 같은 요청을 일반 채팅으로 수행할 수 있다면 소규모 비교를 통해 수정 횟수와 완료 시간을 확인하는 것이 좋다.

/autopilot에 전체 리팩터링을 바로 맡겨도 되나?

변경 범위가 크거나 되돌리기 어려운 작업이라면 권장하기 어렵다. 먼저 /plan으로 단계를 나누고 /spar로 위험을 검토한 뒤, 테스트 가능한 한 단계만 실행하는 편이 안전하다. 자동 테스트가 통과해도 API 호환성, 데이터 변화, 권한 확대, 사용자 경험은 별도 검토가 필요하다.

CLI에서 쓰던 명령을 앱에서도 그대로 사용할 수 있나?

일부 명령은 공통이지만 목적과 맥락이 다르다. CLI는 터미널과 디렉터리 관리가 중심이고, 앱은 시각적 프로젝트 맥락과 여러 세션의 작업 흐름에 초점을 둔다. 기억에 의존해 명령을 입력하기보다 앱 입력창에서 /를 눌러 현재 사용할 수 있는 목록을 확인해야 한다.

개인 사용자나 학생도 별도 운영 절차가 필요한가?

복잡한 승인 체계까지 만들 필요는 없지만, 변경 전 커밋, 별도 브랜치, 테스트 실행, diff 검토 정도는 갖추는 것이 좋다. 과제, 논문, 비공개 저장소, 개인정보가 포함된 자료를 사용할 때는 학교나 조직의 정책과 현재 서비스 조건을 먼저 확인해야 한다.

출처와 검증

기능 설명과 명령 예시는 GitHub Blog의 A guide to slash commands in the GitHub Copilot app을 바탕으로 정리했다. 실제 사용 가능 명령, 계정별 제공 범위, 요금, 사용량 제한, 권한과 데이터 처리 조건은 변경될 수 있으므로 적용 시점의 GitHub 공식 문서와 앱 내 표시를 함께 확인해야 한다.