Copilot 에이전트 로그 공개, 프롬프트와 도구 호출까지 감사 대상

AI 요약

• 무슨 일: GitHub가 2026년 7월 2일 Copilot agent session streaming 공개 프리뷰를 열었습니다.
  • 대상은 기업 관리 사용자 기반 GitHub Enterprise Cloud와 데이터 레지던시 배포입니다.
• 새 데이터: 프롬프트, 응답, 도구 호출 같은 세션 기록이 스트리밍 엔드포인트와 GET /enterprises/{enterprise}/copilot/usage-records로 나옵니다.
  • GitHub 문서는 기록 타입을 request와 response로 나누고, body가 1MB 제한 때문에 잘릴 수 있다고 적습니다.
• 운영 영향: Copilot 에이전트가 만든 PR만 보는 단계에서 세션 내용 자체를 감사·보안·비용 시스템으로 보내는 단계로 넘어갑니다.
• 주의점: 공개 프리뷰이며 EMU 기업 소유자 조건, 최근 48시간 REST 조회, soft credit limit 같은 제약을 함께 봐야 합니다.

GitHub가 2026년 7월 2일 Copilot 에이전트 세션 스트리밍 공개 프리뷰를 발표했습니다. 발표 대상은 GitHub Enterprise Cloud에서 기업 관리 사용자(Enterprise Managed Users, EMU)를 쓰는 고객입니다. GitHub는 Copilot 클라우드 에이전트, Copilot CLI, Visual Studio Code, Visual Studio, JetBrains·Eclipse 같은 파트너 IDE에서 나오는 에이전트 세션 데이터를 기업이 직접 받을 수 있다고 설명했습니다.

이 발표가 단순한 관리 화면 추가보다 큰 이유는 기록의 범위입니다. GitHub는 세션 활동 예시로 프롬프트, 응답, 도구 호출을 들었습니다. PR이 만들어졌는지, 이슈가 닫혔는지 같은 최종 이벤트만 보는 것이 아닙니다. Copilot 에이전트가 어떤 입력을 받았고, 어떤 응답을 냈으며, 어떤 도구 호출을 거쳤는지까지 기업 감사 체계에 들어옵니다. 에이전트 흔적 1,781개 분석 글에서 다룬 trace 관측성이 이제 GitHub Enterprise 관리 기능 안으로 들어온 셈입니다.

세션 기록이 감사 로그의 이웃이 됩니다

GitHub Changelog는 사용자가 AI Controls의 Copilot 하위 페이지에서 Copilot Usage Records Streaming과 Copilot Usage Records API를 Enable everywhere로 켜야 한다고 설명합니다. 스트리밍 쪽은 감사 로그 설정에서 이벤트 수집기나 SIEM으로 연결합니다. GitHub Docs의 감사 로그 스트리밍 문서는 Amazon S3, Azure Blob Storage, Azure Event Hubs, Datadog, Google Cloud Storage, Splunk를 나열합니다. Copilot 에이전트 세션 이벤트용 Microsoft Purview 공개 프리뷰도 별도로 적습니다.

출처: GitHub Changelog 공식 설정 스크린샷입니다.

감사 로그 문서는 기존 기업 감사 이벤트와 같은 목적을 반복합니다. 설정 변경, 접근 권한, 사용자 멤버십, 앱 권한 같은 이벤트를 외부 데이터 시스템에 보관해 지식재산과 규정 준수를 보호하는 방식입니다. 여기에 Copilot 에이전트 세션 활동이 붙으면 질문이 바뀝니다. AI 에이전트가 어떤 코드를 바꿨는가만이 아니라, 그 작업을 시작한 사람, 세션 식별자, 요청과 응답 본문, 도구 호출 경로가 보안 팀과 플랫폼 팀의 데이터 파이프라인에 들어갑니다.

GitHub는 스트리밍이 at-least-once 전달 방식이라고 문서화합니다. 네트워크나 시스템 이슈 때문에 일부 이벤트가 중복될 수 있다는 뜻입니다. 스트림을 잠시 멈추면 7일 동안 버퍼가 유지되지만, 3주 이상 멈추면 현재 시점부터 새로 시작합니다. 이 문장은 세션 로그를 보안 증거로 쓰려는 팀에게 작습니다. 중복 제거, 수집 실패 알림, 보관 기간, 증거 보존 정책을 GitHub 설정 하나에 맡길 수 없기 때문입니다.

REST API는 최근 세션을 좁혀 보는 창입니다

GitHub는 스트리밍과 별도로 REST API도 제공합니다. Changelog에 적힌 엔드포인트는 GET /enterprises/{enterprise}/copilot/usage-records입니다. 발표문은 이 API가 엔터프라이즈 소유자가 최근 48시간의 세션 데이터를 온디맨드로 가져오게 한다고 설명합니다. GitHub Docs의 Copilot usage metrics REST 문서는 이 엔드포인트가 공개 프리뷰라고 적습니다. 접근 대상은 EMU를 쓰는 GitHub Enterprise Cloud와 데이터 레지던시 기업 소유자입니다.

요청 파라미터도 운영 관점에 가깝습니다. phrase는 type, user_id, created 같은 한정자를 지원합니다. per_page는 최대 25개로 제한됩니다. after와 before 커서는 페이지 이동에 쓰고, order는 최신순과 오래된순을 고릅니다. 즉 이 API는 대량 장기 보관용 데이터 레이크가 아닙니다. 사고 조사나 사용자 단위 확인을 위해 최근 세션 기록을 좁혀 보는 창에 가깝습니다.

응답 스키마는 더 직접적입니다. 문서는 각 기록이 type, user_id, enterprise_id, github_request_id, endpoint, body, @timestamp, event_id를 포함한다고 설명합니다. 별도 에이전트 감사 이벤트 문서는 스트리밍된 Copilot API 사용 기록의 type이 request 또는 response라고 적습니다. body는 JSON으로 인코딩된 문자열입니다. body가 1MB 문서 크기 제한에 맞춰 잘리면 truncated가 true가 됩니다.

Copilot의 기업 기능은 비용과 보안으로 묶이고 있습니다

이번 공개 프리뷰는 혼자 떨어진 발표가 아닙니다. GitHub는 2026년 7월 1일 Copilot CLI와 SDK의 AI 크레딧 세션 한도를 공개 프리뷰로 냈습니다. 공식 문서는 AI 크레딧을 모델 상호작용 비용 단위로 설명하며, 각 크레딧이 0.01달러라고 적습니다. 사용자는 대화형 CLI에서 /limits set max-ai-credits NUMBER를 쓰고, 비대화형 실행에서는 --max-ai-credits=NUMBER를 넘깁니다.

이 한도는 hard stop이 아닙니다. GitHub Docs는 진행 중인 응답이 있으면 그 응답이 끝난 뒤 멈추므로 실제 사용량이 설정값을 조금 넘을 수 있다고 설명합니다. 자동화에서 이 차이는 큽니다. 에이전트가 테스트 실패를 보고 다시 빌드를 돌리는 중이라면, 마지막 응답이 끝나기 전까지 비용이 계속 잡힐 수 있습니다. 그래서 세션 한도는 예산 통제의 시작점이지, 전체 조직 예산이나 비용 센터 정책을 대체하지 않습니다.

2026년 7월 2일 발표된 Copilot CLI의 GITHUB_TOKEN 지원도 같은 방향입니다. GitHub Actions에서 Copilot CLI를 실행할 때 장기 개인 액세스 토큰(PAT)을 만들고 저장하지 않아도 됩니다. 조직 소유 저장소에서 Actions 토큰으로 CLI를 쓰면 AI 크레딧은 조직에 직접 청구됩니다. GitHub는 워크플로에 copilot-requests: write 권한이 필요하고, 별도 비밀값은 필요 없다고 설명합니다.

여기에 비용 센터별 AI 크레딧 풀이 붙습니다. 같은 날 GitHub는 비용 센터가 월간 포함 AI 크레딧 풀을 제한할 수 있다고 발표했습니다. 이 기능은 현재 REST API로 제공되고, UI 관리는 나중에 온다고 적었습니다. 비용 센터의 포함 사용량 풀과 초과 과금 예산을 분리한다는 설명은 GitHub가 Copilot을 개인 개발자 도구보다 조직 비용 항목과 감사 항목으로 다루고 있음을 보여줍니다.

프롬프트 로그는 보안 자산이면서 민감 데이터입니다

프롬프트와 응답을 보게 되면 보안 팀은 더 많은 질문에 답할 수 있습니다. 어떤 사용자가 Copilot 에이전트에게 고객 데이터가 든 파일을 요약하게 했는지, 어떤 도구 호출이 외부 API로 나갔는지, PR 생성 전에 어떤 명령을 실행했는지 확인할 수 있습니다. GitHub 감사 이벤트 문서는 actor:Copilot 필터로 최근 180일의 에이전트 활동을 볼 수 있다고 적습니다. 최종 PR 이벤트와 세션 기록을 함께 묶으면 사용자 지시, 에이전트 행동, 결과 변경을 한 조사 타임라인에 올릴 수 있습니다.

하지만 같은 기록은 민감 데이터입니다. 세션 본문에는 소스 코드, 내부 이슈 설명, 보안 취약점, 고객 식별자, API 응답 조각이 들어갈 수 있습니다. body 필드가 JSON 문자열로 전달된다는 말은 저장소 코드와 대화 문장이 SIEM, 데이터 레이크, Purview 같은 외부 시스템에도 남을 수 있다는 뜻입니다. 로그 접근 권한을 Copilot 관리자와 보안 운영자에게 어떻게 나눌지 정하지 않으면, 관측성을 얻는 대신 민감 데이터를 더 넓게 복제하게 됩니다.

1MB 잘림 조건도 조사 품질에 영향을 줍니다. truncated가 true인 기록은 본문 전체가 아닙니다. 사고 보고서에서 잘린 기록을 완전한 증거처럼 다루면 안 됩니다. 반대로 잘림을 이유로 모든 긴 세션을 버리면 장시간 에이전트 작업의 핵심이 사라질 수 있습니다. 실무적으로는 event_id, github_request_id, 세션 ID, PR 번호, Actions 실행 ID를 함께 묶어 원본 시스템에서 재현 가능한 참조를 남겨야 합니다.

최근 Copilot 글과 다른 지점은 관측성입니다

최근 GitHub Copilot 발표는 꽤 많았습니다. devlery도 Copilot for Jira GA, Copilot 코드 리뷰의 AGENTS.md 지원, Copilot 모델 규칙과 AI 크레딧을 이미 다뤘습니다. 그 글들은 작업 표면, 지시문, 모델 비용 정책에 가까웠습니다. 이번 세션 스트리밍은 제품 안에서 무엇을 할 수 있느냐보다 한 작업이 끝난 뒤 무엇을 검증할 수 있느냐를 묻습니다.

AI 코딩 에이전트는 사용자가 보는 화면보다 더 많은 내부 단계를 실행합니다. 계획을 세우고, 파일을 읽고, 명령을 실행하고, 실패 로그를 요약하고, 다른 모델이나 하위 에이전트를 부를 수 있습니다. 비용도 같은 이유로 추적이 어렵습니다. 세션 한도 문서가 모델 호출, 하위 에이전트, 압축 같은 백그라운드 작업까지 한 세션의 AI 크레딧 사용량에 포함한다고 설명한 것도 이 때문입니다. 최종 diff만 보면 내부 비용과 위험을 놓칩니다.

이 지점에서 Copilot 세션 스트리밍은 Hugging Face Agent Traces, Braintrust, LangSmith 같은 관측성 도구와도 비교됩니다. 차이는 위치입니다. 독립 관측성 도구는 여러 에이전트 프레임워크와 평가 루프를 연결합니다. GitHub의 새 기능은 GitHub Enterprise 안에서 Copilot 클라이언트와 감사 로그, 비용 관리, Actions 인증을 한데 묶습니다. 이미 GitHub를 개발 통제면으로 쓰는 조직이라면, 별도 추적 도구 이전에 GitHub가 제공하는 기본 기록을 먼저 볼 수 있습니다.

도입 전에 정해야 할 세 가지

첫째, 로그 수집 목적을 먼저 정해야 합니다. 보안 사고 대응인지, 비용 분석인지, 모델 품질 평가인지에 따라 필요한 필드와 보관 기간이 다릅니다. 사고 대응은 event_id, github_request_id, 세션 ID, 사용자, 시간, 엔드포인트가 필요합니다. 비용 분석은 AI 크레딧, 비용 센터, 조직 청구, 세션 한도를 함께 봐야 합니다. 품질 평가는 프롬프트와 응답 본문을 더 길게 보려 하지만, 그만큼 개인정보와 코드 보안 검토가 필요합니다.

둘째, 본문 보관 정책을 문서화해야 합니다. Copilot 사용 기록의 body는 프롬프트와 응답을 담는 핵심 필드입니다. 이 필드를 SIEM에 그대로 보내면 검색과 조사는 쉬워집니다. 동시에 내부 코드와 고객 데이터가 보안 로그 저장소에 복제됩니다. 마스킹, 접근 권한, 보관 기간, 삭제 요청 처리, 데이터 레지던시 조건을 Copilot 정책과 별도로 정해야 합니다. 로그를 수집한다는 결정은 데이터를 어디에 또 저장할지 결정하는 일입니다.

셋째, 자동화 비용을 사용자 비용과 분리해 봐야 합니다. Copilot CLI가 Actions에서 GITHUB_TOKEN으로 동작하면 개인 PAT 위험은 줄어듭니다. 대신 조직 청구와 워크플로 권한이 더 중요해집니다. GitHub가 말한 것처럼 조직 직접 청구에서는 사용자 수준 예산이 고려되지 않습니다. 워크플로마다 --max-ai-credits 같은 세션 한도를 두고, 비용 센터별 풀과 초과 과금 정책을 함께 설정해야 합니다.

이번 GitHub 발표는 Copilot의 새 모델이나 새 IDE 버튼이 아닙니다. 기업이 AI 에이전트를 개발 프로세스에 넣을 때 피할 수 없는 장부를 연 발표입니다. 누가 시켰는가. 에이전트는 어떤 프롬프트와 응답을 남겼는가. 어떤 도구를 호출했는가. 얼마를 썼는가. 어느 로그 저장소에 남겼는가. Copilot 에이전트 세션 스트리밍은 이 질문들을 GitHub Enterprise의 감사·보안·비용 체계 안으로 끌어옵니다.

개발팀이 지금 가져갈 결론은 기능 켜기 버튼이 아닙니다. 먼저 현재 Copilot 에이전트 사용이 어느 저장소와 워크플로에서 발생하는지 목록화해야 합니다. 그 다음 세션 로그가 필요한 업무와 저장하면 안 되는 업무를 나눠야 합니다. 마지막으로 보안 로그와 비용 장부를 같은 세션 ID로 묶어야 합니다. 에이전트가 코드를 바꾸는 시대에는 결과물만 보는 리뷰가 부족합니다. 작업 과정 자체가 관리 대상이 됩니다.