핵심 요약
AI 코딩 도구가 좋아졌다는 말은 절반만 맞습니다. 이제 더 중요한 질문은 “코드를 얼마나 빨리 쓰나”가 아니라 “변경 전 계획을 세우고, 여러 파일 변경을 검토하고, 모델이 잃어버리는 문맥을 어떻게 관리하나”입니다.
Microsoft가 2026년 5월 26일 공개한 Visual Studio May Update는 이 전환을 잘 보여줍니다. 이번 업데이트의 이름은 “Plan, Review, Refine”입니다. 말 그대로 GitHub Copilot을 자동완성 도구에서 계획, 변경 검토, 컨텍스트 관리, 팀 규칙 적용을 돕는 IDE 안 작업 흐름으로 밀어 넣는 업데이트입니다.
독자는 Visual Studio로 C#, .NET, C++ 프로젝트를 다루는 개발자와 팀 리드입니다. VS Code 중심의 에이전트 창, BYOK, 원격 에이전트 흐름은 이미 VS Code가 AI 에이전트 작업실로 바뀌고 있다에서 다뤘습니다. 이 글은 Visual Studio 본편, 특히 .NET/C++ 개발자가 실제로 켜볼 만한 변화에 초점을 맞춥니다.
이미지 출처: Microsoft Visual Studio Blog, “Visual Studio May Update – Plan, Review, Refine”. 첫 번째 본문 이미지이며 카드 썸네일로도 Plan agent 중심의 업데이트임을 바로 보여준다.
무슨 일이 있었나
이번 업데이트의 직접 근거는 Microsoft Visual Studio Blog의 2026년 5월 26일 글입니다. Microsoft는 Visual Studio 2026 Stable Channel에서 아래 기능들을 써볼 수 있다고 안내했습니다.
| 기능 | 한 줄 의미 | 팀에서 봐야 할 지점 |
|---|---|---|
| Plan agent | 코드 수정 전 read-only 탐색과 구현 계획 작성 | 큰 변경 전 승인 가능한 계획 문서가 남는가 |
| Agent Skills panel | 저장소와 사용자 프로필의 스킬을 한곳에서 확인 | 팀 규칙, 빌드 절차, 릴리스 절차가 재사용되는가 |
| Context window usage | Copilot 대화의 문맥 사용량을 시각적으로 표시 | 긴 세션에서 모델이 앞 내용을 잃기 전 정리하는가 |
| Multi-file summary diff | 여러 파일 변경을 한 화면에서 검토 | AI가 만든 변경을 PR 전 단계에서 빠르게 훑는가 |
| Commit message instructions 이동 | 커밋 메시지 규칙을 repository instructions로 통합 | 팀 규칙을 개인 설정이 아니라 repo 안에 두는가 |
| MSVC Build Tools v14.51 | C++23, coroutine, ARM SVE, regex 등 툴체인 개선 | C++ 팀의 빌드 환경과 servicing 기간을 맞추는가 |
이 중 가장 큰 변화는 Plan agent입니다. Microsoft 설명에 따르면 Plan agent는 바로 파일을 고치지 않습니다. 먼저 읽기 전용 도구로 코드베이스를 탐색하고, 필요하면 질문을 던지고, 구현 계획을 작성합니다. 계획은 .copilot/plans/plan-{title}.md 형태의 Markdown 파일로 저장됩니다. 사용자는 이 파일을 직접 고치거나 채팅으로 다듬은 뒤, 준비가 되면 Agent mode에 넘겨 구현을 맡길 수 있습니다.
즉 Copilot의 작업 단위가 “질문에 답하기”에서 “계획 파일을 만들고, 그 계획을 검토하고, 구현으로 넘기기”로 바뀝니다. 이 차이는 개인보다 팀에서 큽니다. 대형 .NET 솔루션이나 오래된 C++ 코드베이스에서는 “수정해줘”보다 “먼저 어떤 파일을 건드릴지, 어떤 테스트를 돌릴지, 어떤 리스크가 있는지 계획부터 보여줘”가 더 안전합니다.
사람들이 실제로 겪는 문제
Visual Studio 사용자가 AI 코딩 도구에서 자주 겪는 문제는 모델이 코드를 못 쓰는 것만이 아닙니다. 오히려 많이 바꿔놓고 나서 검토가 어려운 경우가 더 피곤합니다.
예를 들어 WPF 앱에서 ViewModel, XAML, service, test project가 한꺼번에 바뀌었다고 해보겠습니다. 채팅창에는 “수정 완료”라고 뜨지만, 개발자는 실제로 무엇이 바뀌었는지 파일을 하나씩 열어야 합니다. Git Changes 창만 봐도 파일 목록은 나오지만, 변경 흐름을 한 화면에서 이해하기는 어렵습니다.
이번 multi-file summary diff는 이 지점을 겨냥합니다. Copilot이 여러 파일을 수정한 뒤 working set에서 change summary view를 열면, 여러 파일의 diff를 하나의 탭에서 볼 수 있습니다. 변경 전체를 한 번에 keep/undo하거나, 파일 단위, diff chunk 단위로 나눠 결정할 수 있습니다. 같은 통합 diff 경험은 Copilot 변경뿐 아니라 Git Changes, branch history, pull requests list 쪽에도 확장됩니다.
이미지 출처: Microsoft Visual Studio Blog, “Visual Studio May Update – Plan, Review, Refine”. Copilot이 여러 파일을 고친 뒤 사람이 검토해야 하는 실제 화면을 보여준다.
두 번째 문제는 컨텍스트입니다. 개발자는 긴 대화를 이어가며 “아까 말한 조건 기억하지?”라고 기대하지만, 모델에는 context window 한계가 있습니다. Microsoft는 Visual Studio Copilot Chat 프롬프트 박스 오른쪽 위에 링 아이콘을 넣어, 현재 대화와 선택 모델 기준으로 문맥 사용량을 보여준다고 설명했습니다. 사용량이 차오르면 /compact 또는 summarize conversation으로 요약해 문맥을 줄일 수 있습니다.
이 기능은 화려하지 않지만 실무적으로 중요합니다. AI 코딩 세션이 실패하는 순간은 대개 모델이 멍청해서가 아니라, 앞서 정한 제약 조건, 파일 구조, 테스트 실패 원인, 사용자가 금지한 접근을 잊었을 때 옵니다. 문맥 사용량을 UI로 보여주는 것은 “모델이 아직 내 작업을 따라오고 있는가”를 개발자가 판단할 수 있게 해줍니다.
이미지 출처: Microsoft Visual Studio Blog, “Visual Studio May Update – Plan, Review, Refine”. 긴 Copilot 세션에서 문맥 사용량을 직접 확인하는 UI다.
왜 중요한가
이번 업데이트는 Visual Studio가 VS Code를 따라 AI 기능을 붙였다는 정도의 이야기가 아닙니다. Visual Studio의 강점은 원래 대형 솔루션, 디버거, profiler, 테스트, C++ toolchain, enterprise .NET 워크플로우에 있었습니다. Microsoft의 Build 2026 발표도 같은 방향을 말합니다. GitHub Copilot in Visual Studio는 채팅과 완성에서 벗어나 디버깅, 프로파일링, 테스트에 더 적극적으로 참여하는 agents 방향으로 간다고 설명했습니다.
개발자에게 의미 있는 변화는 역할 분담입니다. AI에게 무작정 “고쳐줘”라고 시키는 단계에서는 사람의 역할이 사후 수습으로 밀립니다. Plan agent를 먼저 쓰면 사람은 초기에 범위와 접근을 검토할 수 있습니다. Multi-file summary diff를 쓰면 구현 후 검토가 파일 탐색이 아니라 변경 단위 판단이 됩니다. Context window usage를 보면 긴 세션을 계속 끌고 갈지, 요약하고 새 단계로 넘어갈지 결정할 수 있습니다.
Agent Skills도 같은 맥락입니다. Visual Studio 2026의 18.5.0 release notes에 따르면 Copilot agents는 저장소나 사용자 프로필에 정의된 skills를 자동 발견할 수 있습니다. 위치는 .github/skills/, .claude/skills/, .agents/skills/, 그리고 사용자 프로필의 ~/.copilot/skills/, ~/.claude/skills/, ~/.agents/skills/ 등입니다. 이번 May update에서는 새 skills panel로 발견된 스킬을 검색하고, 편집하고, 파일 탐색기에서 열 수 있게 했습니다.
팀 입장에서는 이것이 꽤 큽니다. “우리 팀은 테스트를 이렇게 돌린다”, “릴리스 노트는 이렇게 만든다”, “C# 서비스 레이어는 이 규칙을 따른다” 같은 절차를 매번 프롬프트에 쓰지 않고 저장소 안의 스킬로 둘 수 있기 때문입니다. AI 코딩 도구의 품질은 모델만으로 결정되지 않습니다. 좋은 하네스, 좋은 지침 파일, 좋은 검증 루프가 같이 있어야 팀에서 반복 사용이 가능합니다.
어떻게 써야 하나
개인 개발자는 이번 업데이트를 한꺼번에 다 켜기보다 작업 종류별로 나누는 편이 좋습니다.
작은 수정은 여전히 기존 Copilot Chat이나 inline suggestion으로 충분합니다. 변수명 변경, 짧은 LINQ 수정, 예외 메시지 다듬기, 주석 생성 같은 작업은 Plan agent까지 갈 필요가 없습니다. 반대로 여러 프로젝트가 걸린 변경, public API 변경, database migration, performance issue, C++ toolchain upgrade, 오래된 Web Forms나 WinForms 코드 정리처럼 리스크가 있는 작업은 Plan agent로 시작하는 편이 낫습니다.
Visual Studio에서 바로 써볼 체크리스트는 이렇습니다.
- Agent picker에서 Plan을 선택한다.
- “먼저 수정하지 말고 계획만 세워줘”라고 범위를 못 박는다.
- Copilot이 만든
.copilot/plans/plan-{title}.md파일을 읽고, 금지할 파일·반드시 돌릴 테스트·성능 기준을 추가한다. - 계획이 충분할 때만 Implement plan으로 Agent mode에 넘긴다.
- 구현 후 multi-file summary diff에서 전체 변경 흐름을 먼저 본다.
- Keep all을 누르기 전에 파일 단위와 diff chunk 단위로 위험한 변경을 분리한다.
- 긴 세션에서는 context window usage를 보고 요약 또는 새 세션 전환을 결정한다.
- 팀 규칙은 개인 채팅 히스토리가 아니라 repository instructions와 Agent Skills로 옮긴다.
프롬프트는 길게 꾸미기보다 검토 기준을 분명히 쓰는 편이 좋습니다.
이 작업은 바로 구현하지 말고 Plan agent로 계획부터 세워줘.
목표:
- OrderService의 할인 계산 로직을 새 정책에 맞게 분리한다.
- public API 응답 형식은 바꾸지 않는다.
제약:
- 데이터베이스 스키마 변경 금지
- 기존 단위 테스트는 모두 유지
- 새 정책은 별도 테스트 파일에 추가
계획에 반드시 포함할 것:
- 수정 후보 파일
- 테스트 범위
- 위험한 변경 지점
- 구현 후 사람이 확인해야 할 diff 체크포인트
이렇게 시키면 Copilot이 잘하느냐 못하느냐를 떠나, 사람이 승인할 수 있는 구조가 생깁니다. 실무에서 중요한 것은 “한 번에 정답을 내는 AI”가 아니라 “틀렸을 때 어디서 멈춰 세울 수 있는 AI”입니다.
리스크와 한계
첫 번째 한계는 Plan agent가 계획을 만든다고 해서 계획이 옳아지는 것은 아니라는 점입니다. read-only 탐색을 하더라도 테스트가 부족하거나, 숨은 런타임 제약이 있거나, 사내 배포 절차가 코드 밖에 있으면 Copilot은 놓칠 수 있습니다. Plan 파일은 승인 문서의 시작점이지 설계 리뷰를 대체하지 않습니다.
두 번째 리스크는 스킬과 지침의 과다입니다. Agent Skills가 편해지면 팀은 모든 규칙을 파일에 밀어 넣고 싶어집니다. 하지만 너무 긴 지침은 중요한 기준을 흐립니다. 좋은 스킬은 “이 작업에서 반드시 해야 할 절차”를 짧고 실행 가능하게 담아야 합니다. 예를 들어 “모든 코드는 깔끔하게 작성” 같은 문장보다 “변경 후 dotnet test src/Orders.Tests/Orders.Tests.csproj를 실행하고 실패 테스트 이름을 보고하라”가 훨씬 낫습니다.
세 번째는 비용과 사용량입니다. GitHub Docs의 Copilot billing 문서는 Copilot 사용량이 GitHub AI Credits로 측정되며, Copilot Chat, Copilot CLI, Copilot cloud agent, Copilot Spaces, Spark, third-party coding agents 같은 기능이 AI Credits를 소비한다고 설명합니다. 긴 계획 수립, 큰 context window, 여러 차례 구현·재시도는 결국 사용량과 연결됩니다. 팀은 “Plan agent는 큰 작업에만 쓴다”, “실패한 세션은 요약 후 새 세션으로 전환한다”, “자동 재시도보다 테스트 로그를 먼저 사람이 본다” 같은 운영 기준을 가져야 합니다.
네 번째는 보안입니다. Visual Studio 2026 release notes에는 2026년 2월에 GitHub Copilot and Visual Studio 관련 원격 코드 실행 취약점과 보안 기능 우회 취약점이 보안 업데이트로 처리된 기록도 있습니다. 최신 패치를 유지해야 하는 이유입니다. IDE 안 AI가 파일, 빌드, 터미널, 외부 도구와 가까워질수록 확장과 개발 환경 보안이 중요해진다는 점은 GitHub 내부 repo 유출과 VS Code 확장 보안 경고에서도 이어서 볼 수 있습니다.
MSVC 14.51도 가볍게 볼 업데이트가 아니다
이번 May update에는 Copilot만 있는 것이 아닙니다. Microsoft는 MSVC Build Tools v14.51이 C++ desktop과 gaming workloads에 기본 설치된다고 밝혔습니다. 확인하려면 Visual Studio Installer에서 MSVC Build Tools v14.51 for x64/x86 또는 ARM64/ARM64EC 구성 요소가 선택돼 있는지 보면 됩니다.
Microsoft가 언급한 변화는 C++23 conformance work, consteval, coroutine 개선, sample-based profile guided optimization, Intel APX preview support, ARM SVE 구현, <flat_map>, <flat_set>, <regex> overhaul 등입니다. v14.51은 9개월 servicing fixes도 받습니다.
이미지 출처: Microsoft Visual Studio Blog, “Visual Studio May Update – Plan, Review, Refine”. Copilot 업데이트와 함께 들어온 C++ 툴체인 변경을 확인할 수 있는 공식 화면이다.
AI 기능만 보고 업데이트하면 놓치기 쉽지만, C++ 팀에서는 오히려 이 부분이 더 실질적일 수 있습니다. Copilot이 계획을 세워도 컴파일러, 표준 라이브러리, optimizer, sanitizer, profiler가 받쳐주지 않으면 생산성은 제한됩니다. Visual Studio의 AI 전략은 결국 “모델이 코드를 써준다”가 아니라 “IDE, 툴체인, 리뷰 화면, 팀 규칙, 모델이 같은 작업 루프에 들어온다”에 가깝습니다.
관전 포인트
앞으로 볼 지점은 세 가지입니다.
첫째, Visual Studio의 Plan agent가 실제 팀 리뷰 문화에 들어갈 수 있는지입니다. 계획 파일이 PR 설명, issue checklist, architecture decision record와 연결되면 가치가 커집니다. 반대로 개인 채팅 로그에 머물면 “보기 좋은 계획”에서 끝날 수 있습니다.
둘째, Agent Skills가 VS Code, Visual Studio, Copilot coding agent 사이에서 얼마나 일관되게 동작할지입니다. Microsoft Build 2026 발표는 Visual Studio가 GitHub Copilot SDK를 AI 통합 기반으로 삼는다고 밝혔습니다. 이 기반이 안정되면 같은 repository instructions와 skills가 여러 표면에서 재사용될 가능성이 커집니다.
셋째, BYOK와 모델 선택이 Visual Studio 본편에 어떻게 들어올지입니다. Build 발표는 Visual Studio도 bring your own key 또는 model 방향으로 간다고 설명했습니다. VS Code 쪽은 이미 모델 선택과 BYOK 흐름이 빠르게 확장되고 있습니다. Visual Studio까지 같은 흐름을 따라가면 기업은 비용, 보안, 규정 준수, 로컬 모델 사용 기준을 IDE 정책으로 다뤄야 합니다.
결론은 분명합니다. Visual Studio GitHub Copilot 5월 업데이트의 핵심은 자동완성이 조금 더 좋아졌다는 소식이 아닙니다. Copilot 작업을 계획하고, 문맥을 관리하고, 여러 파일 변경을 검토하고, 팀 규칙을 스킬로 재사용하는 방향입니다. 개발자의 일은 줄어드는 것이 아니라 바뀝니다. 더 적게 타이핑하고, 더 빨리 승인하지 말고, 더 명확하게 계획하고 검증해야 합니다.
출처와 더 읽을 거리
- Microsoft Visual Studio Blog — Visual Studio May Update – Plan, Review, Refine: Plan agent, Agent Skills panel, context window usage, multi-file summary diff, MSVC 14.51 등 이번 글의 직접 근거가 되는 공식 발표다.
- Microsoft Visual Studio Blog — What’s Coming Next in Visual Studio: Our Microsoft Build 2026 Announcements: Visual Studio의 GitHub Copilot SDK 전환, debugging·profiling·testing agents, BYOK 방향성을 확인할 수 있는 공식 로드맵 글이다.
- Microsoft Learn — Visual Studio 2026 Release Notes: Visual Studio 2026의 월별 release notes, Agent Skills, cloud agent integration, 보안 업데이트, MSVC 관련 변경을 버전별로 확인할 수 있는 공식 문서다.
- Microsoft Learn — Manage GitHub Copilot installation and state in Visual Studio: Visual Studio 안에서 Copilot 설치 상태, 로그인, 구독, badge 관리를 확인할 수 있는 공식 사용 문서다.
- GitHub Docs — Usage-based billing for individuals: Copilot 사용량이 GitHub AI Credits로 측정되는 방식, AI Credits를 소비하는 기능, IDE별 권장 업데이트 버전을 확인할 수 있는 GitHub 공식 billing 문서다.
- GitHub Docs — Adding repository custom instructions for GitHub Copilot: 커밋 메시지와 팀 규칙을 저장소 지침으로 관리할 때 참고할 수 있는 GitHub 공식 문서다.