GitHub Copilot CLI는 같은 터미널 도구 안에서도 두 가지 속도로 쓸 수 있습니다. 오래 이어지는 탐색·수정 작업은 기본 대화형 세션으로, 결과가 한 번이면 copilot -p 한 줄 실행으로 처리하는 편이 안전합니다. 핵심은 편의보다 권한, 파일 접근 범위, 재현 가능한 기록을 먼저 정하는 것입니다.

핵심 요약

  • GitHub 블로그는 Copilot CLI의 기본 사용 흐름을 대화형 모드와 비대화형 모드로 나눠 설명했습니다.
  • 대화형 모드는 터미널에서 copilot을 실행해 시작하는 기본 방식입니다. 질문, 응답 확인, 후속 요청, 파일 분석과 실행을 같은 세션에서 이어갈 수 있습니다.
  • 비대화형 모드는 일반 셸에서 copilot -p "프롬프트"처럼 한 번의 요청을 넘기고 바로 결과를 받는 방식입니다. 저장소 요약, 짧은 코드 조각, 자동화 스크립트 안의 단발성 질문에 맞습니다.
  • 이전 대화 맥락으로 돌아가야 하면 대화형 세션 안에서는 /resume, 일반 명령줄에서는 copilot --resume을 사용할 수 있습니다.
  • 실무 적용 전에는 폴더 신뢰, 파일 읽기·수정 권한, 자동 실행 허용 범위, 결과 검증 방법을 명시해야 합니다.

무엇이 바뀌었나

이번 글은 새 가격표나 별도 제품 출시가 아니라, GitHub Copilot CLI를 실제 터미널 작업에서 어떻게 나눠 쓸지 정리한 사용 가이드에 가깝습니다. GitHub는 초보자 시리즈에서 Copilot CLI를 처음 실행하는 흐름부터 다루고 있으며, 이번 편에서는 “계속 대화하며 맡길 일”과 “한 번 묻고 끝낼 일”을 구분하는 기준을 제시했습니다.

대화형 모드는 Copilot CLI를 실행하면 기본으로 들어가는 방식입니다. 원문 예시는 “이 프로젝트를 로컬에서 어떻게 실행하나?”라고 묻고, 이어서 “직접 실행해 줄 수 있나?”라고 요청하는 흐름을 보여줍니다. 이 경우 Copilot은 프로젝트를 분석하고 서버 실행을 시도할 수 있습니다. 따라서 단순 질의응답이 아니라 실제 파일과 명령 실행으로 이어질 수 있는 작업 환경으로 이해해야 합니다.

비대화형 모드는 -p 또는 --prompt 옵션으로 한 번의 프롬프트를 전달하고 종료되는 방식입니다. GitHub 문서는 프로그램matic 사용에서도 같은 방향을 설명합니다. 예를 들어 특정 파일 설명, 저장소 구조 요약, 테스트 작성 요청, 커밋 메시지 작성처럼 입력과 기대 출력이 비교적 좁은 작업을 셸 스크립트나 CI 단계에 넣을 수 있습니다.

대화형 모드가 맞는 상황

대화형 모드는 작업의 범위가 처음부터 닫혀 있지 않을 때 유리합니다. 낯선 저장소를 열어 구조를 파악하고, 실행 방법을 확인하고, 실패한 명령을 다시 고치고, 수정 결과를 함께 보며 다음 지시를 이어가는 식의 흐름입니다. 같은 세션 안에서 맥락이 유지되므로 매번 배경 설명을 반복하지 않아도 됩니다.

반대로 이 장점은 권한 리스크와 붙어 있습니다. GitHub 블로그는 Copilot이 폴더를 신뢰할지 물을 수 있다고 설명합니다. 그 이유는 해당 폴더의 파일을 읽고 수정할 권한이 필요할 수 있기 때문입니다. 업무 저장소나 고객 코드가 있는 환경에서는 “편하니까 신뢰”가 아니라, 테스트 브랜치·샘플 디렉터리·읽기 전용 검토처럼 피해 범위를 줄인 뒤 시작해야 합니다.

  • 여러 번의 후속 질문이 필요한 디버깅
  • 프로젝트 실행 방법을 찾고 실제 명령까지 시도해야 하는 온보딩
  • 수정 전후의 diff, 테스트 결과, 로그를 보면서 판단해야 하는 변경 작업
  • 이전 세션 맥락을 다시 불러와 이어서 처리해야 하는 작업

copilot -p가 맞는 상황

비대화형 모드는 질문이 작고 결과 형식이 분명할 때 좋습니다. 예를 들어 “이 저장소의 핵심 폴더를 5줄로 요약해 줘”, “이 파일의 역할을 100단어 이하로 설명해 줘”, “스테이징된 변경 사항에 맞는 커밋 메시지를 plain text로 써 줘”처럼 답의 범위가 닫힌 요청입니다. 답을 받은 뒤 바로 일반 셸 흐름으로 돌아갈 수 있다는 점이 장점입니다.

자동화에 넣을 때는 더 엄격해야 합니다. GitHub 문서는 프로그래밍 방식 사용에서 정확한 프롬프트, 셸 특수문자 해석을 피하기 위한 따옴표 처리, 최소 권한 부여를 권합니다. 특히 --allow-tool과 --allow-url처럼 필요한 도구와 URL만 허용하고, 샌드박스가 아닌 환경에서 --allow-all처럼 넓은 승인을 쓰는 것은 피하는 편이 안전합니다.

구분 대화형 모드 비대화형 모드
실행 copilot copilot -p "프롬프트"
흐름 대화와 후속 요청을 이어감 한 번의 입력과 한 번의 결과에 집중
맥락 세션 안에서 유지 프롬프트에 필요한 맥락을 직접 포함
적합한 작업 탐색, 실행, 수정, 디버깅 요약, 설명, 짧은 생성, 스크립트 단계
주의점 폴더 신뢰와 파일 수정 범위 권한 옵션, 출력 형식, 실패 시 처리

실사용 전에 확인할 기준

  • 권한: Copilot이 읽을 수 있는 폴더와 실행할 수 있는 도구를 정합니다. 자동화에서는 필요한 셸 명령만 허용하고, URL 접근도 업무상 필요한 범위로 제한합니다.
  • 데이터 처리: 저장소에 비밀키, 고객 데이터, 사내 문서가 섞여 있는지 먼저 확인합니다. 빠른 요약 요청이라도 Copilot이 프로젝트 파일을 살펴볼 수 있으므로 조직의 Copilot 정책과 저장소 등급을 맞춰야 합니다.
  • 재현성: 비대화형 실행은 프롬프트, 옵션, 모델, 실행 위치를 남겨야 나중에 같은 결과를 검토할 수 있습니다. 문서에서 권하는 것처럼 --model을 명시하면 환경 차이를 줄이는 데 도움이 됩니다.
  • 롤백: 수정 작업은 새 브랜치에서 시작하고, 실행 전 git status와 실행 후 diff를 확인합니다. Copilot이 서버를 시작하거나 파일을 바꿀 수 있는 작업은 되돌릴 지점을 먼저 만들어야 합니다.
  • 오답과 과잉 수정: 저장소 요약, 테스트 작성, 코드 리뷰 결과는 참고 자료일 뿐입니다. 실제 병합 전에는 사람이 diff를 보고 테스트를 돌려야 하며, 보안 지적은 false positive와 누락 가능성을 함께 봐야 합니다.
  • 비용과 사용량: 원문은 가격 변경을 다루지 않습니다. 다만 CI나 반복 스크립트에 넣으면 사용량이 늘 수 있으므로 팀 플랜, 조직 정책, 실행 빈도를 별도로 확인해야 합니다.

작은 범위에서 시험하는 절차

  1. 민감 정보가 없는 샘플 저장소나 테스트 브랜치를 준비합니다.
  2. 먼저 copilot -p로 저장소 요약처럼 읽기 중심의 작업을 요청하고, 답이 실제 구조와 맞는지 확인합니다.
  3. 다음으로 대화형 모드에서 “로컬 실행 방법을 알려 달라”처럼 후속 질문이 필요한 작업을 진행합니다. 폴더 신뢰 요청이 나오면 해당 저장소에서 파일 읽기와 수정이 허용되는지 확인한 뒤 진행합니다.
  4. 수정 요청을 했다면 Copilot의 설명보다 git diff, 테스트 결과, 실행 로그를 기준으로 판단합니다.
  5. 자동화에 넣을 후보는 -s로 출력 형식을 단순화하고, --no-ask-user를 붙여 사람이 없는 환경에서 멈추지 않게 합니다. 대신 실패 시에는 상태 코드를 확인하고 결과를 저장하는 방식을 함께 둡니다.

결론

Copilot CLI의 두 모드는 우열보다 작업 크기의 차이로 보면 쉽습니다. 대화형 모드는 프로젝트를 이해하고 함께 조정하는 긴 흐름에 맞고, copilot -p는 이미 질문이 정리된 짧은 작업에 맞습니다. 팀에서 쓴다면 “어떤 작업은 세션으로, 어떤 작업은 한 줄 프롬프트로”라는 운영 기준을 먼저 만들고, 권한·기록·검증을 포함한 최소 실험부터 시작하는 편이 안전합니다.

출처와 검증