터미널 AI 에이전트를 제어하는 슬래시 명령

GitHub Copilot CLI의 슬래시 명령은 AI에게 코드를 요청하는 프롬프트와 성격이 다릅니다. 모델 선택, 컨텍스트 확인, 세션 전환, 변경 내역 검토, 작업 디렉터리 이동, 도구 권한 초기화처럼 Copilot CLI의 실행 상태를 직접 관리하는 제어 기능입니다. 터미널에서 /를 입력하면 현재 지원되는 슬래시 명령 목록을 스크롤하며 확인할 수 있습니다.

초보자에게 중요한 점은 모든 명령을 외우는 것이 아닙니다. 지금 어떤 모델과 디렉터리에서 작업 중인지, 대화 컨텍스트가 얼마나 남았는지, AI가 무엇을 변경했는지, 이전에 허용한 권한이 계속 유효한지를 확인하는 습관이 더 중요합니다. 특히 여러 저장소를 오가거나 긴 세션에서 작업한다면 슬래시 명령은 편의 기능을 넘어 실수의 범위를 줄이는 안전장치가 될 수 있습니다.

먼저 익힐 명령과 사용 기준

/model: 작업에 맞는 모델 선택

/model을 입력하면 사용할 수 있는 모델과 주요 정보를 확인하고 다른 모델로 전환할 수 있습니다. 모델마다 빠른 리팩터링 같은 가벼운 작업에 적합한 경우가 있고, 기능 설계나 복잡한 추론처럼 더 깊은 검토가 필요한 작업에 적합한 경우도 있습니다. 표시되는 모델 목록은 사용자의 플랜이나 조직 설정에 따라 달라질 수 있습니다.

각 모델 옆에 표시되는 숫자는 절대 가격표라기보다 플랜 사용량과 관련된 비용 배수를 판단하는 정보입니다. 따라서 숫자가 큰 모델이 항상 더 나은 선택이라고 단정해서는 안 됩니다. 파일 이름 변경, 단순한 테스트 생성, 반복 코드 정리에는 가벼운 모델을 먼저 적용하고, 여러 모듈에 걸친 설계나 원인 추적처럼 복잡한 작업에서만 더 높은 추론 능력이 필요한지 비교하는 편이 합리적입니다.

  • 개인 사용자는 자주 반복하는 작업에서 응답 속도와 수정 횟수를 비교합니다.
  • 학생은 과제 결과를 대신 생성하는 용도보다 코드 설명과 오류 원인 검토에 적합한 모델인지 확인합니다.
  • 연구자는 입력 자료의 민감도와 조직 정책을 먼저 확인하고 모델 목록의 차이를 검토합니다.
  • 팀은 구성원마다 사용 가능한 모델이 다른지, 조직 관리자가 제한한 설정이 있는지 확인합니다.

/context, /compact, /clear: 대화 기억 범위 관리

Copilot CLI는 한 세션에서 처리할 수 있는 컨텍스트 범위 안에서 대화와 작업 정보를 유지합니다. /context는 남은 토큰, 시스템이 사용하는 부분, 사용할 수 있는 여유 공간을 확인할 때 사용합니다. 긴 오류 로그와 여러 파일을 연속해서 다루면 초기 요구사항이나 중요한 제약이 컨텍스트에서 약해질 수 있으므로, 답변 품질이 흔들린 뒤가 아니라 작업 전환 시점에 확인하는 것이 좋습니다.

/compact는 현재 대화를 요약해 공간을 확보하면서 세션을 이어가는 명령입니다. 한 기능의 조사와 구현이 끝나고 테스트 단계로 넘어갈 때처럼 맥락은 유지하되 세부 대화를 정리하고 싶을 때 유용합니다. Copilot CLI는 한계에 가까워지면 압축을 자동으로 수행할 수 있지만, 사용자가 작업 경계를 기준으로 직접 실행할 수도 있습니다.

/clear는 현재 세션을 완전히 비우고 새로 시작할 때 사용합니다. 이전 작업의 가정이나 오류 로그가 다음 작업에 섞이면 안 되는 경우에 적합합니다. 다만 중요한 결정이나 재현 절차가 대화에만 남아 있다면 초기화 전에 별도 문서나 이슈에 기록해야 합니다. 대화 컨텍스트는 프로젝트의 공식 기록이나 버전 관리 이력을 대신하지 않습니다.

/resume: 이전 세션 이어서 작업

/resume을 실행하면 과거의 로컬 및 원격 세션 목록을 확인하고 선택한 세션의 이력을 불러올 수 있습니다. 전날 중단한 디버깅을 계속하거나 다른 환경에서 시작한 작업의 흐름을 살펴볼 때 유용합니다. 세션을 재개한 뒤에는 현재 체크아웃된 브랜치, 작업 디렉터리, 파일 상태가 당시와 같은지 별도로 확인해야 합니다. 대화가 이어진다는 사실만으로 저장소 상태까지 동일하다고 가정하면 잘못된 파일이나 브랜치에 변경을 적용할 수 있습니다.

/diff: AI가 만든 변경 검토

/diff는 현재 세션에서 발생한 최근 변경을 확인하는 명령입니다. 파일 수정 결과를 바로 받아들이지 않고 어떤 부분이 바뀌었는지 검증하는 데 사용합니다. 특히 설정 파일, 의존성 목록, 데이터베이스 마이그레이션, 배포 스크립트가 함께 변경됐다면 의도하지 않은 범위까지 수정됐는지 살펴봐야 합니다.

이 명령의 결과만으로 검토를 끝내기보다는 저장소의 버전 관리 상태와 테스트 결과도 함께 확인하는 편이 안전합니다. 변경된 코드가 요구사항을 충족하는지, 기존 테스트를 제거하거나 완화하지 않았는지, 비밀값이나 개인 경로가 포함되지 않았는지 검토해야 합니다. 규모가 큰 수정은 파일 단위로 나누어 확인하고, 이해할 수 없는 변경은 커밋하기 전에 원인을 물어보거나 되돌릴 수 있어야 합니다.

/cwd: 저장소와 디렉터리 이동

/cwd는 Copilot CLI를 종료하지 않고 다른 저장소나 디렉터리로 작업 위치를 옮길 때 사용합니다. 여러 코드베이스를 다루는 개발자에게 편리하지만, 작업 범위가 바뀐다는 점에서 주의가 필요합니다. 이동 직후 현재 경로와 저장소 루트를 확인하고, 새 위치에 적용되는 프로젝트 지침이나 권한 범위가 이전 위치와 다른지 살펴봐야 합니다.

모노레포에서는 상위 디렉터리 전체를 대상으로 삼기보다 필요한 패키지나 서비스 디렉터리로 범위를 좁히는 것이 좋습니다. 홈 디렉터리나 여러 프로젝트가 함께 있는 넓은 경로에서 작업하면 AI가 불필요한 파일을 탐색하거나 의도하지 않은 대상을 수정할 가능성이 커집니다.

/reset-allowed-tools: 허용한 도구 권한 초기화

/reset-allowed-tools는 이전에 Copilot CLI에 허용한 도구 권한을 초기화할 때 사용합니다. 예를 들어 파일 편집을 허용한 상태에서 더 민감한 저장소로 이동했다면 기존 허용 상태를 그대로 유지하기보다 권한을 다시 정리하는 편이 안전합니다.

이 명령은 권한을 깔끔하게 재검토하기 위한 출발점입니다. 실행 후에는 필요한 작업에 필요한 최소 권한만 다시 허용하고, 쓰기 작업이나 외부 명령 실행이 요구될 때 대상과 영향을 확인해야 합니다. 업무 코드, 연구 자료, 자격 증명과 연결된 설정을 다룬다면 조직의 보안 정책과 데이터 처리 조건을 먼저 확인해야 합니다.

실제 작업 흐름에 적용하는 방법

  1. 작업 위치를 확인합니다. 여러 저장소를 오갔다면 /cwd로 올바른 디렉터리를 지정하고 현재 브랜치와 변경 상태를 점검합니다.
  2. 작업 난이도에 맞는 모델을 고릅니다. /model에서 사용 가능한 모델과 비용 배수를 확인하되, 간단한 작업부터 불필요하게 무거운 모델을 선택할 필요는 없습니다.
  3. 작은 범위로 요청합니다. 전체 프로젝트를 한 번에 수정하기보다 파일 하나, 테스트 하나, 오류 하나처럼 결과를 검증할 수 있는 단위로 시작합니다.
  4. 긴 작업에서는 컨텍스트를 점검합니다. /context로 남은 공간을 확인하고 작업 단계가 바뀔 때 /compact를 사용합니다. 이전 맥락이 불필요하면 /clear로 새 세션을 시작합니다.
  5. 변경을 검토합니다. /diff로 수정 범위를 살펴보고 테스트, 정적 분석, 버전 관리 도구를 통해 결과를 추가로 확인합니다.
  6. 저장소를 바꿀 때 권한도 재검토합니다. 민감도가 다른 프로젝트로 이동한다면 /reset-allowed-tools로 과거의 허용 상태를 정리합니다.
  7. 중단한 작업은 상태를 대조한 뒤 재개합니다. /resume으로 대화를 불러온 다음 현재 파일과 브랜치가 당시 상태와 일치하는지 확인합니다.

도입 전에 확인할 기준

항목 확인할 질문 판단 기준
이용 조건 내 플랜과 조직 설정에서 필요한 모델과 기능을 사용할 수 있는가? /model에 실제 표시되는 목록과 조직 관리자의 제한을 기준으로 판단합니다.
사용량 선택한 모델의 비용 배수가 현재 플랜 사용량에 어떤 영향을 주는가? 절대 가격을 추정하지 말고 계정에 적용되는 공식 플랜 조건과 사용량 화면을 확인합니다.
권한 파일 편집이나 도구 실행 권한이 어느 범위까지 유지되는가? 저장소를 이동할 때 권한을 재검토하고 필요한 최소 범위만 허용합니다.
데이터 업무 코드, 연구 자료, 로그를 입력해도 되는가? 조직 정책과 GitHub의 최신 데이터 처리 조건을 확인하기 전에는 민감한 자료 입력을 보류합니다.
검증 AI가 만든 변경을 독립적으로 확인할 방법이 있는가? /diff뿐 아니라 테스트, 린터, 빌드, 코드 리뷰와 버전 관리 이력을 함께 사용합니다.
대안 기존 셸 명령과 편집기 기능으로도 같은 결과를 얻을 수 있는가? 전환 비용보다 반복 작업의 시간 절감과 검토 편의가 클 때 도입을 검토합니다.

사용자 유형별 주의점

개인 개발자는 사이드 프로젝트 전체에 곧바로 적용하기보다 테스트가 갖춰진 작은 저장소에서 시작하는 것이 좋습니다. 작업별 응답 속도, 수동 수정 횟수, 실패했을 때 되돌리는 시간을 기록하면 실제로 생산성이 개선됐는지 판단하기 쉽습니다.

학생은 생성된 코드의 실행 여부만 확인해서는 안 됩니다. 각 변경의 이유를 설명할 수 있는지, 사용한 라이브러리와 알고리즘을 이해했는지 검토해야 합니다. 수업이나 평가에서 AI 도구 사용 규칙이 별도로 정해져 있다면 그 조건을 먼저 따라야 합니다.

연구자는 미공개 데이터, 참여자 정보, 논문 심사 자료, 접근 제한 저장소가 컨텍스트에 포함되지 않도록 주의해야 합니다. 세션을 재개하거나 디렉터리를 이동할 때 이전 맥락과 새 자료가 섞이지 않는지도 확인해야 합니다.

팀 개발자는 개인의 편의보다 재현 가능한 검토 절차를 마련하는 것이 중요합니다. 어떤 모델을 사용했는지보다 최종 변경이 테스트와 리뷰를 통과했는지를 기준으로 삼고, 권한과 사용 가능한 모델이 조직 설정에 따라 달라질 수 있다는 점을 문서화해야 합니다.

자주 묻는 질문

슬래시 명령만 익히면 안전하게 사용할 수 있나?

아닙니다. 슬래시 명령은 상태와 권한을 제어하는 수단이지만 코드의 정확성이나 보안을 자동으로 보장하지는 않습니다. 변경 내역 검토, 테스트 실행, 비밀정보 검사, 사람의 코드 리뷰가 여전히 필요합니다.

/compact와 /clear 중 무엇을 선택해야 하나?

이전 대화의 핵심을 유지하면서 공간만 확보하려면 /compact가 적합합니다. 완전히 다른 작업으로 넘어가거나 이전 가정이 새 작업에 영향을 주면 안 된다면 /clear가 더 알맞습니다. 중요한 결정은 어느 명령을 실행하든 저장소 문서나 이슈에 별도로 남기는 것이 좋습니다.

모델 비용 배수만 보고 선택해도 되나?

비용 배수는 중요한 판단 자료지만 유일한 기준은 아닙니다. 동일한 샘플 작업으로 응답 시간, 결과 정확도, 추가 수정 횟수를 비교해야 합니다. 플랜과 조직 설정에 따라 선택 가능한 모델이 달라질 수 있으므로 실제 계정에 표시되는 정보와 공식 이용 조건을 함께 확인해야 합니다.

이 기능을 바로 팀 표준으로 채택해도 되나?

먼저 비민감 저장소의 제한된 작업에서 시험하는 편이 좋습니다. 모델 사용량, 권한 요청, 컨텍스트 관리, 변경 검토, 실패 시 롤백 절차를 확인한 뒤 반복 작업에서 얻는 이점이 운영 부담보다 큰지 판단해야 합니다.

출처와 검증

주요 명령의 기능과 동작은 GitHub Blog의 GitHub Copilot CLI for Beginners: Overview of common slash commands를 기준으로 정리했습니다. 실제 지원 명령, 사용 가능한 모델, 플랜별 이용 조건과 조직 정책은 변경될 수 있으므로 적용 시점에 터미널의 / 목록과 GitHub 공식 문서를 함께 확인해야 합니다.