Angular v22 발표
요약
Angular v22는 비동기 리소스를 위한 resource API와 AI-native 애플리케이션 개발을 위한 에이전트 워크플로를 도입했습니다. MCP를 통한 자가 치유 루프와 브라우저 기반 에이전트 도구, 그리고 브라우저 네이티브 Navigation API 통합을 통해 개발 생산성을 극대화합니다.
핵심 포인트
- resource 및 httpResource API로 비동기 데이터의 선언적 처리 지원
- Angular MCP를 활용한 에이전트 기반 자가 치유 빌드 루프 구현
- Google AI Studio 및 Gemini와의 연동을 통한 AI 기반 앱 생성
- 브라우저 네이티브 Navigation API 통합으로 라우팅 최적화
비동기 반응형 API는 resource로 비동기 리소스를 signal 방식의 사용성으로 다루고, httpResource로 HTTP 데이터 가져오기를 더 선언적인 모델로 처리함
resource와 httpResource는 v22에서 프로덕션 앱에 사용할 수 있으며, 사용법은 공식 가이드에서 확인 가능함
AI 개발과 에이전트 워크플로
Angular v22는 AI-native 애플리케이션을 위한 흐름을 코드 작성용 에이전트 도구, 브라우저 에이전트 도구, AI 개발 플랫폼의 세 영역으로 확장함
Angular 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의 angular-developer는 Angular Aria와 Signal Forms 같은 최신 기능을 포함한 모던 Angular 개발 지침을 모델에 제공하며, 파일은 140줄 미만이고 필요한 시점에 코드 샘플과 참조 파일을 불러오는 점진적 공개 방식을 사용함
angular-new-app은 에이전트 환경에서 Angular를 처음 탐색하는 사용자가 로컬 Angular 코딩 환경을 구성하도록 안내하며, 이 skills는 Antigravity 같은 AI 개발 도구나 에이전트 워크플로 환경에서 사용 가능함
Contributor Skills는 Angular codebase 내부에서 기능을 개발하는 데 필요한 mental model 이해를 돕고, 첫 pull request를 준비하는 사람과 경험 많은 팀원 모두에게 가치가 있음
실험적 WebMCP는 브라우저 안에서 에이전트가 사용할 구조화 도구를 만들고 노출하게 해 DOM 상호작용 필요성을 줄이며, 앱 전체·routes·services 도구 정의와 dynamic Signal Forms 기반 자동 도구 생성을 지원함
Google AI Studio와 Gemini Canvas는 전통적 코딩 배경이 없는 builders가 Angular 기반 프로젝트를 시작하도록 지원하며, Gemini 웹앱의 내장 코딩 샌드박스에서는 브라우저 안에서 전체 애플리케이션을 만들 수 있음
Gemini 워크플로에서는 prompt에 “Angular”를 지정하면 Angular 앱이 생성되고, 생성 뒤에는 브라우저에서 수동 편집하거나 AI와 계속 대화해 다듬거나 Firebase 통합을 요청할 수 있음
Google AI Studio에서는 configuration panel에서 Angular를 선택하고 prompt를 시작하는 유사한 워크플로를 사용할 수 있으며, 생성 후 채팅으로 기능을 추가하고 배포까지 이어갈 수 있음
Router와 의존성 주입 API
Navigation API 통합은 Router를 브라우저 native 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 설정도 가능함
Angular v21로 꽤 복잡한 앱을 만들고 있는데, 컴포넌트·상태·데이터 흐름을 만들고 다루는 인지 부담이 낮아서 경험이 아주 좋았음 시그널과 시그널 저장소 덕분에 매우 쉬워졌고, AI 코딩 도구 없이 전부 손으로 작성함
요즘 Angular는 쓰기 즐거운 수준이라는 걸 인정하게 됨
생태계가 조금 거친 건 아쉽지만, 다행히 기본 제공 기능이 워낙 많음
나도 같은 경험을 함
Angular가 tsc에 강하게 결합된 특이한 컴파일러를 버리고, 어떤 TypeScript 컴파일러와도 쓸 수 있는 더 플러그 가능한 접근으로 갔으면 좋겠음
앱과 단위 테스트의 콜드 빌드 시간은 여전히 별로지만, 코딩 에이전트를 쓰면 그 부담은 조금 덜 신경 쓰게 됨
생태계에서 뭐가 거친지 궁금함
패키지를 찾는 데 문제를 겪은 적은 없고, 대부분의 패키지도 시그널 흐름을 잘 따라가고 있음
프로젝트들이 아직도 RxJS 같은 걸 선택해서 코드가 층층이 쌓이고 디버깅이 괴로운 상태인지 궁금함
아니면 이제 Angular 생태계에도 제정신이 돌아왔는지 궁금함
최근 꽤 복잡한 Angular 프로젝트를 v14에서 v21로 올렸음
몇 년간 Angular 개발이 느려진 느낌이 있었지만, 그 버전들 사이의 변화를 한꺼번에 보면 거의 완전히 새로운 프레임워크처럼 느껴짐
Angular Aria가 정말 좋아 보임
자동완성처럼 복잡한 시나리오까지 문서가 잘 갖춰져 있어서, 예전에 직접 만들어야 했던 스크린 리더용 자동완성을 대체할 수 있을지 빨리 써보고 싶음
이 기능이 정말 기대됨
실험 기능일 때부터 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일 것 같음
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기