GitHub Copilot VS Code 8월 업데이트: 에이전트 세션 관리가 IDE의 핵심 기능이 됐다

GitHub가 2026년 8월 VS Code용 Copilot 업데이트를 공개했다. 공식 changelog는 VS Code v1.132부터 v1.135까지의 변화를 묶어 설명한다. 핵심은 코드 자동완성보다 에이전트 세션 운영이다. 여러 채팅을 나란히 배치하고, 진행 중인 작업을 따라가고, 긴 대화에서 특정 프롬프트와 관련 파일 변경을 찾아가고, Agent Plugins 1.0 기반의 휴대용 플러그인을 설치하는 기능이 들어갔다. 자세한 내용은 GitHub Changelog에서 확인할 수 있다.

이 업데이트는 AI 코딩 도구의 무게중심이 바뀌고 있음을 보여 준다. 예전에는 “한 줄을 얼마나 잘 완성하나”가 중요했다. 지금은 “여러 작업을 동시에 맡긴 뒤 사람이 어디에서 검토하고 개입할 수 있나”가 중요하다. IDE는 더 이상 코드 편집기만이 아니라 에이전트 작업대가 되고 있다.

문제: 에이전트는 일을 하지만, 사람은 맥락을 잃는다

AI 코딩 에이전트를 실제 개발에 쓰면 가장 먼저 겪는 문제는 품질보다 추적성이다. 에이전트가 파일을 고치고 테스트를 돌리고 설명까지 붙여도, 사람이 중간 과정을 놓치면 리뷰가 어려워진다. 어떤 프롬프트에서 어떤 파일이 바뀌었는지, 이전 답변이 지금 변경에 어떤 영향을 줬는지, 실패한 시도는 무엇이었는지 한눈에 보이지 않으면 결국 “전체 diff를 다시 읽는 일”로 돌아간다.

특히 장시간 세션에서는 대화가 길어진다. 요구사항 설명, 에러 로그, 수정 지시, 재시도, 테스트 결과가 섞이면 나중에 특정 판단의 근거를 찾기 어렵다. 팀에서는 더 복잡하다. 한 명이 에이전트에게 작업을 맡긴 뒤 다른 사람이 리뷰에 들어오면, 코드만 보고 맥락을 재구성해야 한다. 이때 생산성 향상분이 상당히 사라진다.

GitHub가 이번 업데이트에서 채팅 배치, 프롬프트 타임라인, 세션 상세 패널, 대화 검색, sticky scroll 같은 기능을 강조한 이유가 여기 있다. AI 코딩은 이제 생성 문제가 아니라 운영 문제다. 에이전트가 만든 결과를 사람이 안전하게 검토하고 이어받을 수 있어야 한다.

원인: AI 코딩 워크플로우는 파일 중심에서 세션 중심으로 이동했다

기존 IDE는 파일과 브랜치가 중심이었다. 개발자는 파일을 열고 코드를 수정하고 커밋했다. 하지만 에이전트 기반 개발에서는 작업 단위가 세션이 된다. 세션 안에는 목표, 제약, 대화, 도구 실행, 실패 로그, diff, 테스트 결과가 모두 들어 있다. 파일은 결과물이고, 세션은 의사결정 기록이다.

이 차이를 무시하면 팀 운영이 꼬인다. 예를 들어 에이전트가 리팩터링 중 “테스트가 깨지지만 기존 테스트가 잘못된 것 같다”고 판단했다고 하자. 코드 diff만 보면 왜 테스트를 바꿨는지 알기 어렵다. 세션 기록을 보면 어떤 에러를 보고 어떤 대안을 검토했는지 알 수 있다. 세션이 리뷰 가능한 단위가 되어야 하는 이유다.

이번 VS Code 업데이트의 Agent Host도 같은 흐름이다. 여러 VS Code 창을 같은 에이전트 세션에 연결하거나, 외부 애플리케이션에서 만든 Copilot·Claude 세션을 VS Code에서 이어보는 기능은 세션을 IDE 밖까지 확장한다. 개발 환경이 “내 로컬 편집기”에서 “작업이 이어지는 에이전트 런타임”으로 바뀌고 있다.

새 기능이 실무에 주는 변화

첫째, side-by-side 채팅은 단순 편의 기능이 아니다. 하나의 문제를 두 방향으로 실험할 때 유용하다. 예를 들어 성능 개선 세션과 안정성 개선 세션을 나란히 두고 diff를 비교하거나, 프론트엔드 UI 수정과 백엔드 API 수정 세션을 동시에 추적할 수 있다. 사람이 컨텍스트 스위칭을 줄이면 리뷰 피로도도 줄어든다.

둘째, /btw side-conversation은 장기 작업에서 특히 중요하다. 메인 세션이 빌드 수정이나 대형 리팩터링을 계속하는 동안, 별도 질문을 같은 캐시와 맥락으로 던질 수 있다. “이 접근이 보안상 괜찮은가”, “다른 라이브러리로 바꾸면 영향이 무엇인가” 같은 보조 검토를 병렬로 할 수 있다. 다만 같은 맥락을 공유한다는 것은 잘못된 가정도 공유할 수 있다는 뜻이므로, 보조 세션에는 반대 관점 질문을 던지는 편이 좋다.

셋째, 프롬프트 타임라인과 관련 파일 변경 이동은 코드 리뷰를 바꾼다. 리뷰어는 diff만 보는 대신 “이 변경을 유도한 프롬프트”로 바로 이동할 수 있다. 요구사항과 구현의 연결이 보이면 불필요한 추측이 줄어든다. 특히 AI가 테스트나 문서까지 함께 바꾸는 경우, 각 변경의 의도를 확인하기 쉬워진다.

넷째, Agent Plugins 1.0 지원은 조직 표준화에 영향을 준다. 팀이 사용하는 스킬, MCP 서버, 도구 설정을 IDE마다 따로 복사하는 대신 휴대 가능한 패키지로 묶을 수 있다. GitHub, Google, Amazon, Microsoft, OpenAI, Vercel 등이 관여하는 표준이라는 점도 의미가 있다. 에이전트 커스터마이징이 개인 설정에서 팀 자산으로 넘어가는 신호다.

도입할 때 조심해야 할 점

에이전트 세션 관리 기능이 좋아졌다고 해서 모든 작업을 에이전트에게 맡기면 안 된다. 오히려 추적 기능이 생긴 만큼 작업 경계를 더 명확히 해야 한다. 세션 이름, 목표, 금지 사항, 테스트 기준, 승인 조건을 앞에 적어야 한다. 에이전트가 무엇을 바꾸면 안 되는지 모호하면 좋은 UI도 사고를 막지 못한다.

두 번째는 보안이다. 외부 에이전트 세션을 IDE에서 이어보거나, 플러그인을 설치하는 기능은 편리하지만 공급망 위험을 키울 수 있다. 플러그인은 스킬과 MCP 서버를 함께 담을 수 있다. MCP 서버는 로컬 파일, 데이터베이스, SaaS API에 접근할 수 있다. 따라서 팀은 플러그인 설치 권한, 허용된 MCP 서버 목록, 비밀키 접근 범위, 실행 로그 보존 정책을 가져야 한다.

세 번째는 리뷰 습관이다. AI가 만든 코드는 빠르게 많아진다. 세션이 늘어나면 리뷰어는 “전체를 꼼꼼히 읽기”보다 “위험도가 높은 부분을 먼저 읽기”로 바꿔야 한다. 인증, 결제, 데이터 삭제, 마이그레이션, 권한 체크, 외부 API 호출은 우선 리뷰 대상으로 표시해야 한다. IDE 기능만으로는 우선순위를 자동으로 정해주지 않는다.

팀 워크플로우 추천안

작은 팀이라면 먼저 세션 템플릿부터 만들면 된다. 프롬프트 첫 부분에 목표, 범위, 금지 파일, 테스트 명령, 완료 조건을 고정한다. 예를 들어 “src/payment와 migrations는 수정 전 확인”, “테스트는 npm test와 typecheck 통과”, “UI 변경은 스크린샷 포함”처럼 적는다. 그 다음 VS Code의 세션 상세와 diff를 리뷰 루틴에 넣는다.

중간 규모 팀은 플러그인과 MCP 서버를 표준화해야 한다. 공통 스킬에는 코드 스타일, 아키텍처 규칙, 배포 절차, 보안 체크리스트를 담는다. MCP 서버는 읽기 전용부터 시작하고, 쓰기 권한은 승인 흐름을 붙인다. Agent Plugins가 설치 가능한 구조를 제공하더라도 권한 모델은 각 조직이 별도로 세워야 한다.

대규모 조직은 세션 로그와 감사 정책이 필요하다. 누가 어떤 세션에서 어떤 모델을 사용했고, 어떤 파일이 바뀌었고, 어떤 테스트가 통과했는지 기록해야 한다. GitHub 업데이트에 포함된 모델별 토큰 사용량 표시도 비용 관리의 출발점이 될 수 있다. AI 코딩 비용은 개인 구독료가 아니라 세션 단위 운영비로 봐야 한다.

실행 체크리스트

• 에이전트 작업을 시작할 때 세션 목표와 금지 범위를 먼저 적는다.
• 대형 작업은 하나의 거대 세션보다 기능별 세션으로 나눈다.
• 프롬프트 타임라인과 파일 변경 연결을 코드 리뷰 때 확인한다.
• side-conversation에는 같은 결론을 강화하는 질문보다 반대 검토 질문을 던진다.
• Agent Plugins 설치는 개인 판단에 맡기지 말고 허용 목록을 둔다.
• MCP 서버는 읽기 권한부터 시작하고 쓰기 권한에는 승인 절차를 붙인다.
• 세션별 모델, 토큰, 테스트 결과를 기록해 비용과 품질을 함께 본다.
• 인증, 결제, 데이터 삭제, 권한 로직은 AI 생성 여부와 관계없이 우선 리뷰한다.
• 외부에서 만든 세션을 이어받을 때는 마지막 결정과 변경 파일부터 확인한다.
• 팀 공통 프롬프트 템플릿을 만들어 IDE 설정이 아니라 저장소 문서로 관리한다.