2026년 7월 초 GitHub Copilot changelog를 보면 코딩 에이전트 경쟁의 초점이 한 단계 이동하고 있습니다. 더 많은 모델, 더 넓은 IDE 통합, 브라우저 조작, 이미지와 PDF 입력도 중요하지만, 운영팀 관점에서 더 큰 변화는 에이전트 세션을 보고, 저장하고, 비용 한도 안에서 멈추게 하는 기능입니다.

GitHub는 2026년 7월 2일 Copilot agent session streaming public preview를 공개했습니다. Enterprise Cloud의 enterprise managed user 환경에서 cloud agents, Copilot CLI, VS Code, Visual Studio, JetBrains/Eclipse 같은 partner IDE의 agent session data를 streaming endpoint나 REST API로 볼 수 있다는 내용입니다. 같은 주에 AI credit session limit, cost center AI credit pool, enterprise managed-settings.json, browser tools GA, Copilot vision GA도 같이 나왔습니다.

저는 이 흐름을 Agent Session Ledger라고 부르는 편이 좋다고 봅니다. 에이전트가 무엇을 프롬프트로 받았고, 어떤 응답을 만들었고, 어떤 tool을 호출했고, 어느 모델과 credit을 썼고, 어디서 멈췄는지를 작업 단위 장부로 남기는 흐름입니다. 이 글은 AI Agent Observability Evidence Contract, AI Coding Spend Preflight, Agentic Capacity SLO, IDE-native Agent Picker와 이어집니다.

이 글에서 얻는 것

  • Copilot usage records streaming이 왜 단순 사용량 리포트보다 중요한지 이해할 수 있습니다.
  • AI credit session limit, cost center pool, managed settings를 에이전트 운영 제어로 묶어 볼 수 있습니다.
  • 브라우저 도구, 이미지/PDF 입력, issue field MCP 연동처럼 넓어지는 agent surface에 필요한 감사 기준을 잡을 수 있습니다.
  • 팀에서 바로 적용할 수 있는 session ledger 필드, 예산 기준, 보존 정책 체크리스트를 가져갈 수 있습니다.

핵심 개념/이슈

1) 에이전트 로그는 이제 디버그 로그가 아니라 감사 데이터다

GitHub의 Copilot agent session streaming 공지는 enterprise가 prompts, responses, tool calls 같은 session activity를 streaming endpoint 또는 REST API로 볼 수 있다고 설명합니다. streaming은 audit log 설정에서 event collector나 SIEM으로 보낼 수 있고, REST API는 최근 48시간 session data를 가져오는 형태입니다.

이 변화의 핵심은 “사용량을 볼 수 있다"가 아닙니다. 코딩 에이전트가 파일 수정, 테스트 실행, issue 업데이트, 브라우저 조작, PR 작성까지 하게 되면 세션 로그는 장애 분석과 보안 감사의 1차 증거가 됩니다. 예전에는 개발자가 어떤 명령을 실행했는지 shell history와 CI 로그를 봤습니다. 이제는 agent가 어떤 prompt를 받았고 어떤 tool call을 했는지도 봐야 합니다.

최소 ledger 필드는 아래 정도가 필요합니다.

agent_session_ledger:
  session_id: "copilot_cli_20260703_1042"
  task_id: "AUTH-421"
  actor: "user_or_service_account"
  repository: "payment-api"
  surface: "cli"
  model_policy: "auto"
  credit_limit: 250
  credit_used: 184
  tool_calls:
    - "repo_search"
    - "file_edit"
    - "test_run"
  external_actions: []
  evidence_refs:
    - "pr_1821"
    - "ci_run_99310"
  stop_reason: "completed_within_limit"

원문 prompt와 response를 전부 장기 보관하자는 뜻은 아닙니다. 오히려 민감정보가 섞일 수 있으므로 보존 기간, 마스킹, 접근 권한을 좁혀야 합니다. 하지만 “무엇을 했는가"에 대한 구조화된 증거는 남겨야 합니다.

2) AI credit session limit은 자동화의 stop condition이다

GitHub는 7월 1일 Copilot CLI와 SDK에서 AI credit session limit을 설정할 수 있다고 발표했습니다. 비대화형 실행에서는 --max-ai-credits로 단일 run을 제한하고, limit에 도달하면 작업을 끝내고 알리는 방식입니다. 공지에 따르면 usage는 응답이 끝난 뒤 알려지므로 soft cap이고, 한 응답이 진행 중이면 약간 초과될 수 있습니다.

이건 FinOps 기능처럼 보이지만 실제로는 운영 안전장치입니다. 에이전트 자동화의 위험은 “비싸다"만이 아닙니다. 더 큰 문제는 잘못 잡은 작업이 계속 탐색하고, 파일을 더 읽고, 하위 agent를 부르고, compaction을 반복하면서 사람 없이 실행되는 것입니다. credit cap은 완벽한 정답은 아니지만 명확한 stop condition입니다.

실무 기본값은 아래처럼 둘 수 있습니다.

작업 유형권장 credit cap추가 제한
문서 수정50~100파일 쓰기 5개 이하
작은 버그 수정150~300테스트 명령 3회 이하
리팩터링300~700plan approval 후 실행
장애 분석200~500read-only 기본
배포/권한/결제 경로자동 실행 금지사람 승인 필수

숫자는 도구와 과금 체계에 따라 바뀝니다. 중요한 것은 “작업 시작 전에 한도를 말한다"는 점입니다. 이 기준은 AI Coding Spend Preflight에서 말한 비용 gate가 실제 런타임 stop condition으로 내려온 형태입니다.

3) cost center AI credit pool은 팀별 공정성 문제다

GitHub는 7월 2일 cost center가 AI credit pool을 지원한다고 공지했습니다. enterprise의 월 포함 AI credits가 전체 pool로 합쳐지고, 한 cost center가 다른 cost center의 라이선스가 만든 포함 credit을 먼저 써버릴 수 있는 문제를 줄이기 위한 기능입니다. AI credit pool은 포함 사용량에 대한 cap이고, cost center budget은 pool 소진 이후 metered phase의 비용 cap이라는 구분도 중요합니다.

엔지니어링 조직으로 보면 이것은 “AI 사용량 chargeback” 문제입니다. 에이전트 작업은 CI minute, cloud runner, DB query처럼 공유 자원을 씁니다. 어떤 팀이 대량 코드 생성과 agent review를 돌리는 동안 다른 팀의 포함 credit까지 빠르게 쓰면 내부 마찰이 생깁니다.

권장 기준:

  • product/team 단위 cost center를 만든다.
  • agent automation은 반드시 task type과 cost center를 가진다.
  • 포함 credit pool cap과 추가 과금 budget을 분리해 본다.
  • 상위 10% 사용 팀의 completed task당 credit을 주간 리뷰한다.
  • 한 작업이 팀 주간 credit의 5%를 넘으면 사전 승인 대상으로 둔다.

이 관점은 Agentic Capacity SLO와 바로 연결됩니다. 에이전트 용량은 모델 호출만이 아니라 credit, runner, reviewer, queue wait을 함께 소비합니다.

4) 입력과 행동 표면이 늘수록 ledger가 더 중요해진다

같은 시기 GitHub는 Copilot vision GA도 공개했습니다. 이미지와 PDF를 chat prompt에 붙일 수 있고, Business/Enterprise에서는 attachment가 약 24시간 보존된다고 설명합니다. VS Code browser tools도 GA가 되어 agent가 실제 브라우저를 열고 navigate, click, type, screenshot, console error 확인을 할 수 있습니다. 이 기능은 private tab, isolated agent tabs, camera/microphone/location/notification/clipboard read 같은 민감 권한의 명시 승인, network domain allow/deny controls를 함께 설명합니다.

이 기능들은 개발자 경험을 크게 넓힙니다. 에이전트가 스크린샷을 보고 UI 버그를 찾고, PDF 스펙을 읽고, live web app을 브라우저로 테스트할 수 있습니다. 동시에 감사 표면도 넓어집니다.

질문이 바뀝니다.

  • 첨부된 PDF나 이미지에 고객 정보가 있었는가?
  • agent browser가 어떤 도메인에 접근했는가?
  • clipboard, location, camera 같은 민감 권한 요청은 누가 승인했는가?
  • screenshot과 console log는 어디에 저장되고 언제 지워지는가?
  • issue field를 MCP로 수정했다면 어떤 task와 연결되는가?

따라서 session ledger는 code diff만 담으면 부족합니다. attachment, browser domain, issue metadata mutation, tool permission, retention까지 포함해야 합니다.

실무 적용

1) session ledger schema를 먼저 정한다

처음부터 SIEM 연동을 크게 만들 필요는 없습니다. 하지만 필드는 먼저 고정해야 합니다.

필수 필드:

  • session id, task id, actor, repository, branch
  • 실행 surface: IDE, CLI, cloud agent, CI, SDK
  • model policy: fixed model, auto, admin default
  • credit limit, credit used, stop reason
  • tool call 요약: read, write, execute, browser, issue mutation, external send
  • evidence refs: PR, CI run, test output, issue, execution receipt
  • risk flags: secret path touched, auth/payment/infra path touched, external domain access
  • retention class: raw prompt 보존 여부, redacted summary 보존 기간

처음 30일은 raw log보다 redacted summary 중심으로 시작하는 편이 안전합니다. 보안팀이 보고 싶은 것은 모든 대화 원문이 아니라, 위험 행동과 비용, 승인, 증거의 연결입니다.

2) credit cap을 작업 등급별 기본값으로 둔다

개발자에게 매번 숫자를 정하라고 하면 정책이 작동하지 않습니다. 작업 등급별 기본값을 둡니다.

agent_credit_policy:
  docs:
    max_ai_credits: 80
    max_files_changed: 5
  bugfix:
    max_ai_credits: 250
    max_test_runs: 3
  refactor:
    max_ai_credits: 600
    requires_plan: true
  incident_readonly:
    max_ai_credits: 300
    write_tools: false
  high_risk:
    auto_run: false
    requires_human_approval: true

이 정책은 model picker보다 중요합니다. 모델이 자동 선택되더라도 작업 한도와 승인 기준은 조직이 정해야 합니다. IDE-native Agent Picker에서 다룬 것처럼 선택지가 늘어날수록 기본값이 운영 품질을 좌우합니다.

3) streaming은 보안팀 요구보다 개발팀 질문에서 시작한다

SIEM으로 모든 것을 보내면 좋아 보이지만, 먼저 답할 질문을 정해야 합니다.

  • 지난 7일간 agent가 가장 많이 수정한 repository는 어디인가?
  • credit 대비 완료 PR 비율이 낮은 작업 유형은 무엇인가?
  • high-risk path를 만진 session 중 evidence가 없는 비율은 얼마인가?
  • browser tool이 접근한 외부 도메인 top 20은 무엇인가?
  • 사람 승인 없이 issue field나 PR metadata를 수정한 session이 있는가?

초기 경보 기준은 단순하게 둡니다.

신호초기 경보
credit limit 초과 종료하루 5건 이상
no-evidence completed session0건 목표
high-risk path touch + no approval즉시 조사
external domain not allowlisted차단 또는 P1 review
same task retry 3회 이상사람 개입
attachment 포함 sessionretention class 필수

트레이드오프/주의점

첫째, session streaming은 privacy 문제를 만듭니다. prompts, responses, tool calls에는 소스코드, 고객 정보, 내부 사고 내용이 들어갈 수 있습니다. 따라서 raw payload 보존은 최소화하고, 기본은 redacted summary와 risk metadata로 시작하는 편이 좋습니다.

둘째, credit cap은 soft cap입니다. GitHub 공지처럼 사용량은 응답이 끝난 뒤 확정될 수 있으므로 약간 초과될 수 있습니다. 예산 경보를 정확한 차단선으로 착각하면 안 됩니다. 고위험 작업은 credit cap이 아니라 권한 cap과 승인 gate가 먼저입니다.

셋째, cost center cap은 품질 문제를 해결하지 않습니다. 비용을 잘 나눠도 쓸모없는 agent 작업이 많으면 낭비는 그대로입니다. completed task당 사람 수정 시간, rollback, defect leak도 같이 봐야 합니다.

넷째, 로그가 많아질수록 책임이 흐려질 수 있습니다. “로그에 남았으니 안전하다"가 아니라, 누가 보고 어떤 기준으로 멈출지가 있어야 합니다. session ledger는 책임 회피용 저장소가 아니라 의사결정 도구여야 합니다.

다섯째, agent browser와 vision은 편하지만 데이터 경계가 다릅니다. 이미지, PDF, browser session, clipboard, console log는 코드 파일과 다른 보존·마스킹 규칙을 요구합니다. “Copilot 기능” 하나로 묶지 말고 입력 유형별 정책을 나눠야 합니다.

의사결정 우선순위는 민감정보 보호 > 고위험 행동 승인 > 실행 증거 > 비용 한도 > 개발자 편의성입니다. 비용보다 먼저 볼 것은 데이터와 권한입니다.

체크리스트 또는 연습

체크리스트

  • 에이전트 세션에 task id와 repository가 반드시 붙는다.
  • 비대화형 실행에는 credit cap, timeout, max tool call, stop condition이 있다.
  • tool call은 read/write/execute/browser/external send로 분류된다.
  • high-risk path touch에는 approval ref가 필요하다.
  • session 완료 시 PR, CI, issue, receipt 중 최소 하나의 evidence가 남는다.
  • prompt, response, attachment, screenshot의 보존 기간이 분리돼 있다.
  • cost center별 included credit pool과 metered budget을 따로 본다.
  • session stream을 SIEM으로 보내기 전 redaction과 접근 권한을 검토했다.

연습

  1. 최근 agent 작업 10개를 골라 credit_used, files_changed, tests_run, human_fix_time, merged_or_discarded를 표로 적어 보세요.
  2. 문서 수정, 버그 수정, 리팩터링, 장애 분석에 대해 기본 credit cap과 stop condition을 각각 정해 보세요.
  3. 에이전트가 접근해도 되는 외부 도메인 allowlist와 절대 접근하면 안 되는 denylist를 20개 이하로 만들어 보세요.
  4. prompt 원문을 저장하지 않고도 감사 가능한 redacted session summary 예시를 1개 작성해 보세요.

Agent Session Ledger의 목표는 개발자를 감시하는 것이 아닙니다. 에이전트가 점점 더 많은 일을 할수록, 그 실행을 설명 가능하고 중단 가능하며 비용 한도 안에 두는 것입니다. 2026년의 코딩 에이전트 운영은 “어떤 모델이 더 똑똑한가"에서 “어떤 세션이 어떤 근거와 예산 안에서 움직였는가"로 옮겨가고 있습니다.

출처 링크