Performance | The .NET Blog

.NET 11이 드디어 프로세스 API를 수정합니다

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

프로세스를 시작하고 출력을 캡처해야 했던 모든 .NET 개발자는 동일한 위험한 보일러플레이트 코드의 변형을 작성해 왔습니다: stdout의 비동기 읽기, stderr의 비동기 읽기, WaitForExitAsync, 두 스트림을 모두 비우는 것을 잊으면 데드락이 발생합니다. 이것은 수년간 존재해 온 잘 알려진 함정입니다.

.NET 11이 마침내 이것을 제대로 수정합니다.

RunAndCaptureTextAsync

핵심 추가 사항: 프로세스를 시작하고, stdout과 stderr를 캡처하고, 데드락 없이 종료를 기다리는 단일 정적 메서드.

var result = await Process.RunAndCaptureTextAsync("dotnet", "--version");
Console.WriteLine(result.StandardOutput);

한 번의 호출. 수동 스트림 드레인 없음. 신중하게 배치된 WaitForExit 없음. 단순히 무언가를 실행하고 출력을 얻어야 한다면, 이것이 원하는 API입니다.

출력을 캡처하지 않고 종료를 기다리는 경우를 위한 Process.RunAsync도 있습니다.

KillOnParentExit

시작된 프로세스의 일반적인 문제: 부모 프로세스가 충돌하거나 종료되면, 자식 프로세스는 고아로 계속 실행됩니다. KillOnParentExit를 사용하면 프로세스 시작 시 부모 프로세스가 종료될 때 자식 프로세스도 종료되어야 한다고 선언할 수 있습니다.

이것은 플랫폼별 방식(Windows의 job objects, Linux의 prctl)으로 존재했던 기능이지만 .NET에서 사용하려면 p/invoke나 서드파티 라이브러리가 필요했습니다. 이제 ProcessStartInfo의 일급 프로퍼티가 되었습니다.

SafeProcessHandle 기반 API

새로운 경량 API 표면은 전체 Process 클래스가 아닌 SafeProcessHandle을 중심으로 구축되었습니다. 전체 Process 클래스는 많은 상태를 가지고 있어 트리밍하기 어렵습니다 — SafeProcessHandle 경로는 출력 크기를 최소화해야 하는 애플리케이션(WASM, 네이티브 AOT)에 더 트리머 친화적입니다.

핸들 상속에 대한 완전한 제어

업데이트는 또한 자식 프로세스가 상속하는 핸들과 표준 핸들이 리다이렉트되는 방식에 대한 세밀한 제어를 추가합니다. 이전에는 stdin/stdout/stderr를 리다이렉트할 수 있었지만 OS 수준에서 정확히 어떤 핸들을 상속할지 지정할 수 없었습니다. 새로운 API는 그 제어를 노출합니다.

왜 중요한가

Process 클래스는 툴링, 빌드 시스템, 테스트 러너, 그리고 다른 실행 파일을 호출하는 모든 애플리케이션에서 사용됩니다. 이전 API 표면은 .NET Framework 시절의 것으로 노후화되어 있었습니다. 이것은 호환성을 깨는 변경이 아닙니다 — 이전 API는 계속 작동합니다 — 하지만 새 코드는 새 표면을 선호해야 합니다.

트리밍된 애플리케이션이나 AOT 컴파일 시나리오에서는 SafeProcessHandle 경로가 특히 환영받습니다. 이전 Process 클래스는 트리밍을 복잡하게 만드는 리플렉션 heavy 코드를 많이 가져왔습니다.

원본 게시물: Process API Improvements in .NET 11

Copilot Studio가 .NET 10 WebAssembly로 마이그레이션하여 20% 빨라진 방법

Emiliano Montesdeoca — Sat, 23 May 2026 00:00:00 +0000

Copilot Studio 팀은 모든 Blazor WASM 개발자들이 궁금해했던 것을 실행했습니다: 프로덕션 애플리케이션을 .NET 8에서 .NET 10으로 실제로 업그레이드하고 결과를 측정했습니다. 게시물은 구체적인 수치를 공유하는데, 이는 드물고 진정으로 유용합니다.

업그레이드는 지루했습니다 (이것은 좋은 일입니다)

타겟 프레임워크 업데이트, 패키지 참조 새로 고침, 주요 변경 사항 수정. 그게 전부입니다. .NET 10 빌드가 이제 프로덕션에서 실행되고 있습니다. 마이그레이션 자체는 흥미로운 부분이 아니었습니다—.NET 10의 변경 사항이 그렇습니다.

자동 에셋 지문 인식

이전에는 WASM 앱을 배포하려면 캐시 무효화를 위해 SHA256 해시로 게시된 에셋의 이름을 바꾸는 사용자 정의 스크립트를 작성해야 했습니다. Copilot Studio에는 정확히 이를 수행하는 PowerShell 스크립트가 있었습니다—파일 이름 바꾸기, JavaScript 로더에 integrity 속성 주입, 모든 것을 수동으로 관리.

.NET 10에서는 이 모든 것이 내장되어 있습니다. 게시된 에셋은 자동으로 지문 인식되고, dotnet.js에서 직접 가져오며, 수동 개입 없이 무결성 검증됩니다. 팀은 이름 바꾸기 스크립트를 삭제했습니다.

범위의 작은 변경, 복잡성의 상당한 감소.

WasmStripILAfterAOT가 이제 기본적으로 활성화

.NET 8에서는 AOT 컴파일된 어셈블리에서 IL을 제거하는 것이 옵트인이었습니다. .NET 10에서는 기본값입니다. AOT 컴파일 후 원본 IL 바이트코드가 출력에서 제거됩니다—런타임에 필요하지 않으며, 이를 유지하면 이유 없이 패키지 크기가 커졌습니다.

Copilot Studio는 특정 최적화를 사용합니다: JIT 엔진(빠른 시작)과 AOT 엔진(최대 안정 상태 성능) 둘 다 배포하고, 둘 다 병렬로 로드하여 준비되면 JIT에서 AOT로 핸드오프합니다. 두 엔진 간에 동일한 파일도 중복 제거합니다.

새로운 IL 제거 동작은 AOT 어셈블리가 더 이상 JIT 대응물과 비트 단위로 일치하지 않음을 의미하므로 더 적은 파일이 중복 제거됩니다:

.NET 8: 59개의 공유 파일
.NET 10: 22개의 공유 파일

결과: AOT 엔진의 패키지 크기가 약 15% 더 커집니다. AOT 다운로드는 빠른 LAN에서 ~6% 느리고, 4G에서 ~17% 느립니다. 하지만 이 모든 것은 앱이 이미 인터랙티브해진 후 백그라운드에서 발생합니다.

성능 수치

이것이 중요한 부분입니다:

첫 번째 호출 시 ~20% 더 빠름 (콜드 패스)
후속 호출 시 ~5% 더 빠름 (웜 패스)

개선 사항은 “큰 봇"에서 가장 눈에 띕니다—AOT 컴파일된 코드가 지배하는 크고 복잡한 에이전트. 더 단순한 워크플로우에서는 이득이 더 작습니다.

아직 .NET 8을 사용 중이라면

마이그레이션 이야기는 진정으로 간단합니다: <TargetFramework>를 업데이트하고, 패키지 참조를 업데이트하고, 사용자 정의 지문 인식 스크립트를 제거하면, 자동으로 WasmStripILAfterAOT의 혜택을 받게 됩니다. AOT를 컴파일하는 경우 유사한 성능 향상을 기대하세요.

게시물의 참고 사항: WebWorker 내에서 .NET WASM 런타임을 로드하는 경우 초기화 시 dotnetSidecar = true를 설정하세요.

원본 게시물: Copilot Studio gets faster with .NET 10 on WebAssembly