Microsoft Build 2026과 agent-native 개발로 가는 조용한 전환

spinny:~/writing $ less microsoft-build-2026-agent-native-development.md

1 
2Microsoft Build 2026의 메시지는 꽤 분명했다. software agent의 다음 단계는 더 예쁜 chat box가 아니다. agent에게 책상, checklist, sandbox, 그리고 책임자를 주는 일이다.
3 
4공식 신호는 [Microsoft Build 2026 live blog](https://news.microsoft.com/build-2026-live-blog/microsoft-build-2026-live/), Microsoft의 [AI alone won't change your business. The system running it will](https://blogs.microsoft.com/blog/2026/06/02/ai-alone-wont-change-your-business-the-system-running-it-will/), GitHub의 [GitHub Copilot app](https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/) 발표에서 나왔다. 함께 읽으면 방향이 같다. agents는 editor 옆의 부가 기능이 아니라 development system 안으로 들어가고 있다.
5 
6## 유용한 부분은 좋은 의미로 지루하다
7 
8patch를 쓰는 agent는 흥미롭다. 하지만 isolated worktree에서 작업하고, checks를 실행하고, 읽을 수 있는 trace를 남기고, pull request를 열고, 올바른 approval gate에서 멈추는 agent가 훨씬 더 유용하다.
9 
10Build 2026에서 보인 변화는 이것이다. 마법은 줄고 운영 모델은 늘어난다. GitHub Copilot app은 agent work의 control room처럼 보인다. sessions, repositories, issues, pull requests, parallel tasks가 한곳에 있다. 특히 worktree가 좋다. 각 시도가 자기 공간에 있으니 비교하거나 버리거나 승격하기 쉽다.
11 
12## Sandbox는 부가 기능이 아니다
13 
14agent가 code를 실행할 수 있다면 안전하게 틀릴 곳이 필요하다. local 또는 cloud sandbox가 그 역할을 한다. laptop이나 production을 실험장으로 만들지 않고도 테스트할 수 있다.
15 
16화려하지는 않지만 demo와 workflow의 차이가 여기 있다. 좋은 agent는 tests를 돌리고, failures를 읽고, 다시 시도하고, 무엇이 바뀌었는지 보여야 한다. 동시에 실수가 작게 머물도록 제한되어야 한다.
17 
18## Review가 병목이 된다
19 
20agentic development의 함정은 agent가 많아지면 shipped work도 자동으로 늘어난다고 믿는 것이다. 실제로는 지친 reviewers 앞에 pull requests가 더 쌓일 수 있다.
21 
22나는 세 가지를 보겠다. reviewer 시간이 줄었는가 늘었는가. generated changes가 babysitting 없이 checks를 통과하는가. trace가 diff를 믿을 만큼 reasoning을 설명하는가.
23 
24reviewer가 매번 처음부터 추론을 복원해야 한다면 workflow는 아직 끝난 것이 아니다. 부담만 옮겨간 것이다.
25 
26## 어디서 시작할까
27 
28나는 지루하고 경계가 뚜렷한 일부터 시작하겠다. dependency updates, test fixes, 작은 refactors, review-comment follow-ups, release notes, 강한 tests가 있는 migrations.
29 
30각 task에는 isolation, checks, trace, human merge decision이 필요하다. agent는 발품을 판다. 결과의 책임은 team에 남는다.
31 
32## 내 생각
33 
34Build 2026은 agent-native development를 slogan보다 operations 문제에 가깝게 만들었다. 이길 team은 agents에게 모든 것을 맡기는 team이 아니다. agents가 전진하되 trace를 숨기지 못하게 system을 설계하는 team이다.
35 
36## 출처
37 
38- [Microsoft Build 2026 live blog](https://news.microsoft.com/build-2026-live-blog/microsoft-build-2026-live/)
39- [Microsoft: AI alone won't change your business](https://blogs.microsoft.com/blog/2026/06/02/ai-alone-wont-change-your-business-the-system-running-it-will/)
40- [GitHub: Copilot app, the agent-native desktop experience](https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/)
41

:Microsoft Build 2026과 agent-native 개발로 가는 조용한 전환lines 1-41 (END) — press q to close

2Microsoft Build 2026의 메시지는 꽤 분명했다. software agent의 다음 단계는 더 예쁜 chat box가 아니다. agent에게 책상, checklist, sandbox, 그리고 책임자를 주는 일이다.

4공식 신호는 [Microsoft Build 2026 live blog](https://news.microsoft.com/build-2026-live-blog/microsoft-build-2026-live/), Microsoft의 [AI alone won't change your business. The system running it will](https://blogs.microsoft.com/blog/2026/06/02/ai-alone-wont-change-your-business-the-system-running-it-will/), GitHub의 [GitHub Copilot app](https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/) 발표에서 나왔다. 함께 읽으면 방향이 같다. agents는 editor 옆의 부가 기능이 아니라 development system 안으로 들어가고 있다.

6## 유용한 부분은 좋은 의미로 지루하다

8patch를 쓰는 agent는 흥미롭다. 하지만 isolated worktree에서 작업하고, checks를 실행하고, 읽을 수 있는 trace를 남기고, pull request를 열고, 올바른 approval gate에서 멈추는 agent가 훨씬 더 유용하다.

10Build 2026에서 보인 변화는 이것이다. 마법은 줄고 운영 모델은 늘어난다. GitHub Copilot app은 agent work의 control room처럼 보인다. sessions, repositories, issues, pull requests, parallel tasks가 한곳에 있다. 특히 worktree가 좋다. 각 시도가 자기 공간에 있으니 비교하거나 버리거나 승격하기 쉽다.

12## Sandbox는 부가 기능이 아니다

14agent가 code를 실행할 수 있다면 안전하게 틀릴 곳이 필요하다. local 또는 cloud sandbox가 그 역할을 한다. laptop이나 production을 실험장으로 만들지 않고도 테스트할 수 있다.

16화려하지는 않지만 demo와 workflow의 차이가 여기 있다. 좋은 agent는 tests를 돌리고, failures를 읽고, 다시 시도하고, 무엇이 바뀌었는지 보여야 한다. 동시에 실수가 작게 머물도록 제한되어야 한다.

18## Review가 병목이 된다

20agentic development의 함정은 agent가 많아지면 shipped work도 자동으로 늘어난다고 믿는 것이다. 실제로는 지친 reviewers 앞에 pull requests가 더 쌓일 수 있다.

22나는 세 가지를 보겠다. reviewer 시간이 줄었는가 늘었는가. generated changes가 babysitting 없이 checks를 통과하는가. trace가 diff를 믿을 만큼 reasoning을 설명하는가.

24reviewer가 매번 처음부터 추론을 복원해야 한다면 workflow는 아직 끝난 것이 아니다. 부담만 옮겨간 것이다.

26## 어디서 시작할까

28나는 지루하고 경계가 뚜렷한 일부터 시작하겠다. dependency updates, test fixes, 작은 refactors, review-comment follow-ups, release notes, 강한 tests가 있는 migrations.

30각 task에는 isolation, checks, trace, human merge decision이 필요하다. agent는 발품을 판다. 결과의 책임은 team에 남는다.

32## 내 생각

34Build 2026은 agent-native development를 slogan보다 operations 문제에 가깝게 만들었다. 이길 team은 agents에게 모든 것을 맡기는 team이 아니다. agents가 전진하되 trace를 숨기지 못하게 system을 설계하는 team이다.

36## 출처

38- [Microsoft Build 2026 live blog](https://news.microsoft.com/build-2026-live-blog/microsoft-build-2026-live/)

39- [Microsoft: AI alone won't change your business](https://blogs.microsoft.com/blog/2026/06/02/ai-alone-wont-change-your-business-the-system-running-it-will/)

40- [GitHub: Copilot app, the agent-native desktop experience](https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/)