# Angular v22 발표 > Clean Markdown view of GeekNews topic #30162. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30162](https://news.hada.io/topic?id=30162) - GeekNews Markdown: [https://news.hada.io/topic/30162.md](https://news.hada.io/topic/30162.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-06-04T10:10:43+09:00 - Updated: 2026-06-04T10:10:43+09:00 - Original source: [blog.angular.dev](https://blog.angular.dev/announcing-angular-v22-c52bb83a4664) - Points: 2 - Comments: 1 ## Topic Body - **Angular v22**는 **AI 에이전트** 흐름을 Angular MCP의 개발 서버 제어 도구, Angular Agent Skills, 실험적 WebMCP, Google AI Studio·Gemini Canvas의 Angular 생성 워크플로로 확장함 - 안정성과 개발 편의성 개선을 목표로 Signal Forms, Angular Aria, `resource`·`httpResource`를 실험/프리뷰 단계에서 프로덕션 준비 상태로 올림 - **Signal Forms**는 Reactive Forms·강한 타입 폼·템플릿 기반 폼·signals 반응성을 결합한 선언형 폼 API이며, 문서 보강·커뮤니티 피드백 반영·Angular Material 및 Angular Aria 지원을 마침 - **API와 템플릿** 개선은 Router의 Navigation API 통합, 경로 리소스 정리 제어, `@Service`와 `injectAsync`, HTML 요소 주석·spread/rest·`@switch` 검사·템플릿 화살표 함수 지원으로 이어짐 - Angular v22는 새 앱의 OnPush 기본값, `ChangeDetectionStrategy.Eager` 명칭 변경, 2026년 3분기 `@boundary` 개발자 프리뷰, Webpack 계열 지원 중단 예정과 TSGo 집중으로 **미래 기반**을 강화함 --- ### 프로덕션 준비 상태로 올라간 기능 - **Signal Forms**는 Reactive Forms의 장점, 강한 타입 폼, 템플릿 기반 폼의 선호 요소, signals의 반응성을 결합한 반응형·조합형·선언형 폼 API임 - v21 출시 이후 [angular.dev 폼 가이드](https://angular.dev/guide/forms)를 갱신하고, 커뮤니티 피드백과 이슈를 반영했으며, Angular Material 및 Angular Aria 연동을 지원함 - **Angular Aria**는 개발자가 스타일과 비즈니스 로직을 맡고 UI 지시자와 패턴이 접근성을 처리하도록 설계된 접근성 프리미티브이며, v22에서 프로덕션 사용 가능 상태가 됨 - [Angular Aria의 12개 UI 패턴](https://angular.dev/guide/aria/overview)은 공통 접근성 패턴을 다루며, API 안정화, Signal Forms 완전 지원, [테스트 하네스](https://angular.dev/guide/aria/accordion#testing)를 갖춤 - **비동기 반응형 API**는 `resource`로 비동기 리소스를 signal 방식의 사용성으로 다루고, `httpResource`로 HTTP 데이터 가져오기를 더 선언적인 모델로 처리함 - `resource`와 `httpResource`는 v22에서 프로덕션 앱에 사용할 수 있으며, 사용법은 [공식 가이드](https://angular.dev/guide/signals/resource)에서 확인 가능함 ### AI 개발과 에이전트 워크플로 - Angular v22는 AI-native 애플리케이션을 위한 흐름을 코드 작성용 에이전트 도구, 브라우저 에이전트 도구, AI 개발 플랫폼의 세 영역으로 확장함 - [Angular MCP](https://angular.dev/ai/mcp)의 `devserver.wait_for_build`는 에이전트가 애플리케이션을 빌드하고 출력 결과를 검토해 다음 단계를 결정하도록 지원하며, 빌드 로그의 코드 오류를 바탕으로 자가 치유 루프를 만들 수 있음 - `devserver.start`와 `devserver.stop`은 개발 서버 시작·중지를 담당하며, 이 도구들은 테스트 및 end-to-end 도구와 함께 v22에서 stable로 승격됨 - Angular MCP는 `ai_tutor`, `modernize`, `onpush_zoneless_migration` 등 현대적 Angular 앱 개발을 돕는 도구 목록을 늘려가고 있음 - [Angular Agent Skills](http://github.com/angular/skills)의 `angular-developer`는 Angular Aria와 Signal Forms 같은 최신 기능을 포함한 모던 Angular 개발 지침을 모델에 제공하며, 파일은 140줄 미만이고 필요한 시점에 코드 샘플과 참조 파일을 불러오는 점진적 공개 방식을 사용함 - `angular-new-app`은 에이전트 환경에서 Angular를 처음 탐색하는 사용자가 로컬 Angular 코딩 환경을 구성하도록 안내하며, 이 skills는 [Antigravity](https://antigravity.google/) 같은 AI 개발 도구나 에이전트 워크플로 환경에서 사용 가능함 - [Contributor Skills](https://github.com/angular/angular/tree/main/.agent/skills)는 Angular codebase 내부에서 기능을 개발하는 데 필요한 mental model 이해를 돕고, 첫 pull request를 준비하는 사람과 경험 많은 팀원 모두에게 가치가 있음 - 실험적 [WebMCP](https://developer.chrome.com/docs/ai/webmcp)는 브라우저 안에서 에이전트가 사용할 구조화 도구를 만들고 노출하게 해 DOM 상호작용 필요성을 줄이며, 앱 전체·routes·services 도구 정의와 dynamic Signal Forms 기반 자동 도구 생성을 지원함 - WebMCP 통합 문서는 [angular.dev/ai/webmcp](https://angular.dev/ai/webmcp)에서 확인 가능함 - [Google AI Studio](https://aistudio.google.com/)와 [Gemini Canvas](https://gemini.google.com/)는 전통적 코딩 배경이 없는 builders가 Angular 기반 프로젝트를 시작하도록 지원하며, Gemini 웹앱의 내장 코딩 샌드박스에서는 브라우저 안에서 전체 애플리케이션을 만들 수 있음 - Gemini 워크플로에서는 prompt에 “Angular”를 지정하면 Angular 앱이 생성되고, 생성 뒤에는 브라우저에서 수동 편집하거나 AI와 계속 대화해 다듬거나 [Firebase](https://firebase.google.com/) 통합을 요청할 수 있음 - Google AI Studio에서는 configuration panel에서 Angular를 선택하고 prompt를 시작하는 유사한 워크플로를 사용할 수 있으며, 생성 후 채팅으로 기능을 추가하고 배포까지 이어갈 수 있음 ### Router와 의존성 주입 API - **Navigation API 통합**은 Router를 브라우저 native [Navigation API](https://developer.mozilla.org/en-US/docs/Web/API/Navigation_API)와 맞춰 더 적은 boilerplate로 앱 이동 제어를 제공함 - Router는 `RouterLink`와 표준 anchor tag를 포함한 모든 navigation request를 자동으로 가로챌 수 있음 - native scroll behavior를 활용해 back/forward 이동 시 사용자가 기대한 위치에 도달하도록 하며, custom scroll-management logic 없이 bundle size 영향도 없음 - 브라우저 native navigation lifecycle에 직접 연결해 page transition 중 global loading indicator와 정확한 접근성 announcement를 더 쉽게 처리함 - **경로 정리 제어**는 `withExperimentalAutoCleanupInjectors`와 `destroyDetachedRouteHandle` 두 기능으로 메모리 관리를 더 명시적으로 다룸 - `withExperimentalAutoCleanupInjectors`는 더 이상 active하지 않은 route와 연결된 dependency injector를 자동으로 destroy해 idle route-level provider와 resource를 정리함 - `destroyDetachedRouteHandle`은 custom `RouteReuseStrategy` 사용 시 detached route handle 안의 component를 clean하게 destroy하는 공식 public API임 - **`@Service` decorator**는 대부분의 use case에서 `@Injectable({ providedIn: 'root' })` 패턴을 대체하며, deeper configuration이나 constructor injection이 필요한 경우 `@Injectable`을 계속 사용할 수 있음 - **`injectAsync`** 는 service의 asynchronous dependency injection을 지원해 code splitting과 on-demand loading을 가능하게 하며, service는 auto-provided 상태여야 하고 `@Service`가 이를 처리함 - `injectAsync` 예시에서 `ReportExporter` service는 처음 사용될 때까지 load되지 않으며, `prefetch: onIdle` 같은 prefetch 설정도 가능함 - 사용법은 [injectAsync 공식 문서](https://angular.dev/guide/di/lazy-loading-services)에서 확인 가능함 - 기타 개선으로 TypeScript 6 전체 호환성과 template pipeline 및 runtime efficiency 성능 개선이 들어감 ### 템플릿 작성 경험과 변경 감지 - HTML element 안의 property와 binding 수준에서 comment를 사용할 수 있어 template 가독성과 명확성이 높아지며, VS Code comment toggling도 지원함 - Angular는 같은 element에서 여러 번 match되는 host directive를 자동으로 de-duplicate함 - directive가 template과 host directive 양쪽에서 match되면 template match가 우선하며, host directive의 input/output map은 merge됨 - input 또는 output이 여러 이름으로 expose되면 Angular가 error를 발생시켜 naming conflict를 방지함 - template에서 spread/rest syntax를 사용할 수 있으며, object literal, array literal, function call에 적용 가능함 - `@switch`는 여러 `@case`가 같은 output을 공유할 수 있어 code duplication을 줄임 - union type을 쓰는 `@switch` block에서 `@default never;`를 사용하면 처리되지 않은 값이 있을 때 compile-time error를 받을 수 있음 - template 안 inline function은 arrow function 형태로 사용할 수 있으며, 짧고 단순한 함수에 적합하고 복잡하거나 오래 실행되는 함수는 template에 두지 않는 조건이 붙음 - 새 애플리케이션에서는 `OnPush`가 기본 change detection 전략이며, zoneless 기본값과 performance by default 목표에 맞춰짐 - 기존 기본값이던 `ChangeDetectionStrategy.Default`는 `ChangeDetectionStrategy.Eager`로 이름이 바뀌어 change detection cycle에서의 동작을 더 명확하게 드러냄 ### 오류 경계, 폐기 예정, 향후 방향 - **`@boundary`** 는 Angular template 안에서 error boundary를 구현하는 새 API이며, 감싼 code block에서 올라오는 error를 catch하고 fallback content를 지정할 수 있음 - 전자상거래 checkout 같은 high-stakes flow에서 단일 component failure가 전체 page를 무너뜨리는 문제를 줄이는 데 목적이 있음 - `@boundary`는 2026년 3분기에 developer preview로 제공될 예정임 - Webpack support, `@angular-devkit/build-angular` builders, `@ngtools/webpack` 등은 v22에서 deprecated 상태가 됨 - Angular는 application builder의 TSGo support에 집중하며, 더 자세한 deprecation 정보는 [Angular CHANGELOG](https://github.com/angular/angular/blob/main/CHANGELOG.md)에서 확인 가능함 ## Comments ### Comment 58899 - Author: neo - Created: 2026-06-04T10:10:44+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48386463) - **Angular v21**로 꽤 복잡한 앱을 만들고 있는데, 컴포넌트·상태·데이터 흐름을 만들고 다루는 인지 부담이 낮아서 경험이 아주 좋았음 **시그널**과 시그널 저장소 덕분에 매우 쉬워졌고, AI 코딩 도구 없이 전부 손으로 작성함 - 요즘 **Angular**는 쓰기 즐거운 수준이라는 걸 인정하게 됨 생태계가 조금 거친 건 아쉽지만, 다행히 기본 제공 기능이 워낙 많음 - 나도 같은 경험을 함 Angular가 `tsc`에 강하게 결합된 특이한 컴파일러를 버리고, 어떤 TypeScript 컴파일러와도 쓸 수 있는 더 플러그 가능한 접근으로 갔으면 좋겠음 앱과 단위 테스트의 콜드 빌드 시간은 여전히 별로지만, 코딩 에이전트를 쓰면 그 부담은 조금 덜 신경 쓰게 됨 - 생태계에서 뭐가 거친지 궁금함 패키지를 찾는 데 문제를 겪은 적은 없고, 대부분의 패키지도 **시그널 흐름**을 잘 따라가고 있음 - 프로젝트들이 아직도 **RxJS** 같은 걸 선택해서 코드가 층층이 쌓이고 디버깅이 괴로운 상태인지 궁금함 아니면 이제 Angular 생태계에도 제정신이 돌아왔는지 궁금함 - 최근 꽤 복잡한 Angular 프로젝트를 **v14에서 v21**로 올렸음 몇 년간 Angular 개발이 느려진 느낌이 있었지만, 그 버전들 사이의 변화를 한꺼번에 보면 거의 완전히 새로운 프레임워크처럼 느껴짐 - **Angular Aria**가 정말 좋아 보임 자동완성처럼 복잡한 시나리오까지 문서가 잘 갖춰져 있어서, 예전에 직접 만들어야 했던 스크린 리더용 자동완성을 대체할 수 있을지 빨리 써보고 싶음 - 내가 뭘 잘못 본 건지 모르겠지만, [https://angular.dev/guide/aria/overview#showcase]()에서 키보드 조작을 해보니 훨씬 흔한 `tab`/`shift+tab` 대신 **화살표 키**로 탐색하게 해놨음 심지어 그 예제 바로 위의 자체 문서 탭은 포커스 이동에 `tab`/`shift+tab`을 쓰고 있음 - 이 기능이 정말 기대됨 실험 기능일 때부터 **signal-forms**와 resources를 쓰고 싶었고, 시그널에 올라탄 뒤로는 돌아갈 수 없었음 폼 때문에 RxJS를 써야 하는 게 큰 고통이었음 - 시그널에 대해 좀 더 설명해줄 수 있는지 궁금함 Godot 같은 게임 엔진의 시그널 패러다임처럼, 깊이에 상관없이 컴포넌트가 시그널을 내보내고 다른 컴포넌트가 구독하는 방식과 비슷한 건지, 아니면 완전히 다른 건지 궁금함 - React 이전에는 Angular를 즐겁게 썼고 꽤 괜찮은 시절이었지만, 솔직히 지금은 Angular가 존재했다는 사실도 거의 잊고 지냄 React를 칭찬하려는 것도 아니고, 요즘은 오히려 **htmx 방식**이 마음에 듦 다만 이제 경쟁은 어떤 프레임워크나 언어를 에이전트가 더 잘 다루는지, 그리고 정적 분석이나 컴파일러 수준 도구가 실수를 얼마나 잡아줄 수 있는지로 옮겨간 느낌임 - Angular는 약간 **Django** 같은 느낌이라 좋음 필요한 게 다 포함돼 있어서 쓰기 쉬움 - 그냥 Django를 쓰면 되는 것 아닌가 싶음 아니면 템플릿과 서버 사이드 렌더링을 갖춘 더 빠른 백엔드를 쓰고, 거기에 htmx를 붙이면 실제로 망가진 JS 생태계의 광기 없이도 단일 페이지 앱 같은 경험을 얻을 수 있음 - Angular 덕분에 프로그래밍 커리어가 즐거웠고, 전혀 일처럼 느껴지지 않았음 좋아하는 언어로 일하고, 더 배우고, 돈까지 받을 수 있는 것보다 좋은 건 없음 - 한동안 Angular를 쓰지 않았음 Vue, React, Svelte 같은 다른 JavaScript 프레임워크를 쓰는 입장에서 내가 놓치고 있는 게 뭔지 궁금함 다른 큰 프레임워크보다 Angular를 고르는 사람들의 이유가 궁금함 - 대체로 Angular는 **구식 애플리케이션을 웹사이트로 만들고 싶을 때** 가장 잘 맞는다고 봄 특히 JavaScript와 웹 개발을 별로 좋아하지 않고, 백엔드가 주된 부분이라고 생각하는 경우에 잘 맞음 - `import {signal} from "@angular/core"`와 `import {form} from "@angular/forms/signals"`처럼, `signal`은 core에서 나오고 `form`은 forms/signals에서 나오는 구조임 내가 이해하지 못한 용어상의 이유가 있는 듯함 그 외에는 10년 만에 Angular를 다시 써보는 게 기대되고, 꽤 좋아 보임 - 시그널은 Angular의 **기본 데이터 구조**라서 core에 있음 시그널 기반 폼은 Forms 모듈의 일부라서, 폼을 쓰지 않으면 그 오버헤드를 가져오지 않음 - Angular에는 폼을 다루는 방식이 많음 아마 새로 나온 **시그널 기반 폼**을 가져오는 import일 것 같음