GitHub Copilot content exclusions GA: 앱과 CLI에서도 민감 코드가 컨텍스트에서 빠진다

검색 의도: GitHub Copilot content exclusions GA, Copilot CLI content exclusion, GitHub Copilot 민감 코드 보호, AI 코드 보안 정책

GitHub가 2026년 9월 2일 Copilot app과 Copilot CLI에서 content exclusions를 일반 제공한다고 밝혔다. enterprise, organization, repository 관리자가 설정한 제외 정책을 Copilot app과 CLI가 존중한다. 제외된 파일은 Copilot이 컨텍스트로 사용하지 않는다. GitHub는 이 기능을 Copilot Business와 Copilot Enterprise 고객에게 제공한다고 설명했다.

이 업데이트가 중요한 이유는 Copilot 사용 위치가 IDE 안에 머물지 않기 때문이다. 개발자는 이제 앱, CLI, 코드 리뷰, 에이전트형 워크플로우에서 Copilot을 쓴다. 정책이 VS Code 확장에만 적용되고 CLI에는 적용되지 않는다면 보안 모델에 구멍이 생긴다. 이번 GA는 “어떤 인터페이스로 쓰든 같은 제외 규칙이 적용돼야 한다”는 방향으로 간다.

content exclusion은 프롬프트 필터가 아니다

민감 파일 보호를 프롬프트 문구로 해결하려는 팀이 많다. “비밀 값을 읽지 마라”, “.env는 사용하지 마라” 같은 지시는 없는 것보다 낫지만 충분하지 않다. 모델에게 보낸 뒤 지시로 막는 방식은 이미 늦다. content exclusion은 애초에 특정 파일이나 경로를 컨텍스트 후보에서 빼는 쪽에 가깝다.

예를 들어 .env, 인증서, 고객 데이터 샘플, 내부 보안 정책, 취약점 재현 코드, 라이선스 키가 들어간 fixture는 AI 보조 도구가 읽을 필요가 없는 경우가 많다. 코드 생성에 필요한 것은 API shape와 테스트 케이스지 실제 운영 secret이 아니다. 제외 정책은 이런 파일을 “주의해서 다뤄라”가 아니라 “컨텍스트로 쓰지 말라”로 바꾼다.

CLI 지원이 중요한 이유

CLI는 자동화와 붙기 쉽다. 로컬에서 copilot 명령을 쓰거나, 스크립트가 PR 설명을 만들거나, 터미널에서 에러 로그를 설명하게 하는 식이다. IDE보다 빠르고 편하지만, 그만큼 파일 접근 범위가 넓어질 수 있다. 개발자는 터미널에서 현재 디렉터리의 파일을 자연스럽게 다루고, 에이전트형 CLI는 여러 파일을 읽어 문제를 해결하려 한다.

따라서 Copilot CLI가 content exclusions를 따른다는 것은 운영상 의미가 크다. 같은 repo에서 IDE는 막히는데 CLI는 읽는 상황을 줄일 수 있다. 특히 보안팀이 repository 단위로 정책을 관리하는 조직에서는 도구별 예외를 추적하는 비용이 줄어든다.

제외해야 할 파일을 어떻게 고를까

처음부터 모든 것을 막으면 Copilot의 usefulness가 떨어진다. 반대로 너무 느슨하면 민감 정보가 섞인다. 실무 기준은 세 그룹으로 나누는 것이 좋다.

첫째, 절대 제외 그룹이다. .env, private key, certificate, production credential, 고객 원문 데이터, 내부 감사 자료처럼 모델 컨텍스트가 될 이유가 거의 없는 파일이다. 둘째, 조건부 제외 그룹이다. 대용량 로그, 보안 테스트 payload, 마이그레이션 덤프처럼 상황에 따라 필요한 자료다. 이 그룹은 기본 제외 후 승인된 샘플만 제공하는 편이 안전하다. 셋째, 허용 그룹이다. 공개 문서, 타입 정의, 테스트 더블, mock schema, README, ADR처럼 코드 이해에 필요한 파일이다.

이 분류를 repo마다 새로 만들면 유지 비용이 커진다. 조직 공통 baseline을 두고, repo별로 추가 제외만 허용하는 구조가 낫다.

에이전트형 코딩에서 정책 누락은 리뷰 비용으로 돌아온다

Copilot이 단순 autocomplete일 때는 컨텍스트 노출 문제가 상대적으로 작아 보였다. 하지만 코드 리뷰, CLI, 앱, 에이전트 세션으로 확장되면 이야기가 다르다. 에이전트가 여러 파일을 읽고 수정안을 만들수록 “무엇을 읽었는지”와 “읽으면 안 되는 파일이 섞였는지”가 리뷰 포인트가 된다.

정책이 잘 잡혀 있으면 리뷰어는 기능 변화와 테스트 결과에 집중할 수 있다. 정책이 없으면 PR마다 “이 제안이 secret을 봤나?”, “고객 데이터 예시를 학습성 컨텍스트로 썼나?”를 의심해야 한다. AI 보안은 모델 안전성만의 문제가 아니라 리뷰 생산성 문제이기도 하다.

기존 secret scanning과 역할이 다르다

content exclusion은 secret scanning을 대체하지 않는다. secret scanning은 이미 커밋된 비밀 값을 찾는다. push protection은 유출을 막는 마지막 관문이다. content exclusion은 AI 도구가 어떤 파일을 참고할 수 있는지를 제한한다. 세 기능은 서로 다른 단계에서 작동한다.

권장 순서는 이렇다. 먼저 secret scanning과 push protection으로 repo 자체를 정리한다. 그다음 content exclusions로 AI 컨텍스트 경계를 만든다. 마지막으로 Copilot 사용 로그, 정책 변경 기록, 예외 승인 절차를 운영한다. 한 가지 도구에 모든 책임을 몰아주면 빈틈이 생긴다.

운영 체크리스트

• 조직 공통 제외 baseline을 만든다: .env, key, certificate, production dump, 고객 원문 데이터.
• repo별로 추가 제외가 필요한 경로를 정리한다: 보안 테스트 payload, 내부 정책, 대용량 로그.
• Copilot app, CLI, IDE에서 같은 정책이 적용되는지 샘플 파일로 검증한다.
• 제외된 파일을 대체할 안전한 mock schema와 test fixture를 제공한다.
• PR 템플릿에 “AI 도구가 참고해도 되는 자료” 링크를 둔다.
• 정책 변경은 보안팀 또는 repo owner 승인 로그를 남긴다.
• secret scanning, push protection, content exclusion을 각각 다른 방어선으로 문서화한다.
• 분기마다 제외 규칙이 과도하거나 부족하지 않은지 false positive와 false negative를 확인한다.

GitHub Copilot content exclusions GA는 “AI가 코드를 잘 쓰게 하자”에서 “AI가 읽을 수 있는 코드를 관리하자”로 운영 초점을 옮긴다. Copilot을 앱과 CLI까지 쓰는 팀이라면 이제 content exclusion을 선택 기능이 아니라 기본 보안 설정으로 봐야 한다.