Angular v22 주요 변경 사항과 실무 적용 포인트
Angular v22가 공식 릴리즈되면서 프론트엔드 생태계에 의미 있는 변화가 생겼다. Java 백엔드 개발자 입장에서도 BFF(Backend for Frontend) 구조나 풀스택 프로젝트에서 Angular를 다루는 경우가 적지 않은 만큼, 이번 변경 사항은 충분히 파악해 둘 필요가 있다.
Signal Forms API 안정화와 폼 처리 방식의 변화
기존 Angular의 ReactiveForms는 FormControl, FormGroup 등을 통해 상태를 관리했지만, 변경 감지와 결합된 복잡성이 항상 문제였다. v22에서 Signal Forms API가 안정 버전으로 승격되면서 이제 폼 상태를 Signal 기반으로 선언적으로 다룰 수 있게 됐다.
Signal은 Angular가 점진적으로 도입해 온 반응형 원시 타입(reactive primitive)으로, 값이 변경될 때만 관련 뷰를 정밀하게 업데이트한다. 폼 입력값 하나가 바뀌었을 때 전체 컴포넌트 트리를 재렌더링하지 않아도 된다는 점은 대규모 데이터 입력 화면에서 체감 성능 차이로 이어진다.
OnPush 기본 적용과 변경 감지 전략 개선
v22의 핵심 성능 개선 중 하나는 변경 감지(Change Detection) 전략으로 OnPush가 기본값으로 적용된다는 점이다. 기존에는 별도로 설정하지 않으면 Default 전략이 적용되어, 어떤 이벤트가 발생해도 전체 컴포넌트 트리를 순회했다. 이는 규모가 커질수록 불필요한 렌더링 비용을 유발했다.
// v22 이전: 수동 설정 필요
@Component({
changeDetection: ChangeDetectionStrategy.OnPush,
...
})
// v22 이후: OnPush가 기본값으로 적용
@Component({
// 별도 설정 없이도 OnPush 동작
...
})
이 변경은 새로 작성하는 컴포넌트에 즉시 긍정적인 효과를 주지만, 기존 코드베이스에서는 Default 전략의 암묵적인 동작에 의존하던 로직이 있을 수 있어 마이그레이션 시 회귀 테스트가 필수다.
새로운 @Service() 데코레이터와 DI 간소화
의존성 주입(DI) 설정에도 변화가 생겼다. 기존에는 서비스를 등록할 때 @Injectable({ providedIn: 'root' }) 형태로 작성해야 했는데, v22에서는 새로운 @Service() 데코레이터가 도입되어 선언이 더욱 간결해졌다.
// 기존 방식
@Injectable({ providedIn: 'root' })
export class UserService { ... }
// v22 신규 방식
@Service()
export class UserService { ... }
Java Spring의 @Service 어노테이션과 유사한 개념으로 이해하면 빠르다. DI 컨테이너에 의해 싱글톤으로 관리되며, 명시적인 providedIn 설정 없이도 루트 수준에서 주입이 가능하다. 코드 가독성이 높아지고, 팀 내 신규 개발자의 온보딩 비용도 줄어드는 효과가 있다.
또한 이번 릴리즈는 TypeScript 6를 공식 지원하며, 기존에 deprecated 처리됐던 API들이 이번 버전에서 완전히 제거됐다. 기존 프로젝트를 v22로 업그레이드할 때는 Angular 공식 마이그레이션 가이드를 통해 제거된 API 사용 여부를 반드시 사전에 점검해야 한다.
정리
- Signal Forms API 안정화로 반응형 폼 상태 관리가 간결해지고, 정밀한 렌더링 최적화가 가능해졌다.
OnPush가 기본 변경 감지 전략으로 채택되어 성능이 향상되나, 기존 코드베이스 마이그레이션 시 회귀 테스트가 필요하다.@Service()데코레이터 도입으로 DI 선언이 간소화되었으며, TypeScript 6 지원과 deprecated API 제거로 하위 호환성 검토가 필요하다.