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

spinny:~/writing $ vim 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~

NORMAL · microsoft-build-2026-agent-native-development.md [readonly]41 lines · :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가 좋다. 각 시도가 자기 공간에 있으니 비교하거나 버리거나 승격하기 쉽다.

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~