저는 가끔씩 "Angular를 여전히 선택할 가치가 있는가?"라는 질문의 변형된 형태를 접하곤 합니다. 수년 동안 저의 답변에는 많은 전제 조건이 따랐습니다. 팀에 따라 다릅니다. 앱이 얼마나 오래 유지되어야 하는지에 따라 다릅니다. RxJS를 얼마나 좋아하는지에 따라 다릅니다.

이제 그 질문은 다르게 느껴집니다. 상당한 양의 코드가 에이전트 (Agents)에 의해 작성되고 있으며, 프레임워크를 손으로 직접 타이핑할 때 즐겁게 만드는 요소들이 생성(generate)할 때 안전하게 만드는 요소와는 다릅니다. 저는 Angular의 트레이드오프 (tradeoffs) 중 어떤 것이 이 세계에서 더 좋아졌고, 어떤 것이 더 나빠졌는지에 대해 생각해 왔습니다. 요약하자면, Angular는 에이전트 엔지니어링 (agentic engineering)과 바이브 코딩 (vibe coding)을 위한 가장 안전한 메인스트림 옵션이 되었으며, 이는 유행을 쫓기보다는 항상 해왔던 방식을 유지함으로써 달성되었습니다.

Angular가 실제로 위치했던 곳

시작점을 솔직하게 인정합시다. 그래야만 이 AI에 관한 논의가 의미를 갖기 때문입니다.

Angular는 사람들이 주말에 가볍게 선택하는 프레임워크가 아니었습니다. React는 수년 전에 마음 점유율 (mindshare)을 차지했고 이를 다시 내어준 적이 없습니다. Stack Overflow의 2025년 설문조사에 따르면 전문 개발자들 사이에서 React는 44.7%, Angular는 18.2%, Vue는 17.6%를 기록했습니다. State of JS 2025는 변화에 대한 많은 논의에도 불구하고 사용량 순위는 거의 움직이지 않았다고 언급했습니다. Angular는 오랫동안 지배적인 선택지는 아니었지만, 상당하고 지속적인 선택지로 남아 있었습니다.

그 이유는 신비로운 것이 아닙니다. AngularJS에서 Angular 2로의 재작성(rewrite)은 많은 신뢰를 깎아먹었으며, 사람들이 그 이야기를 그만 꺼내기까지 10년이 걸렸습니다. NgModules는 신입 개발자에게 설명할 수 있는 이점도 없이, 컴포넌트를 추가할 때마다 두 번째 파일을 편집해야 함을 의미했습니다. RxJS는 단순한 값(plain value)만으로도 충분할 곳을 포함하여 도처에 깔려 있었고, 학습 곡선(learning curve)이 매우 가팔라서 "Angular를 배워야 할 뿐만 아니라 반응형 프로그래밍(reactive programming)도 배워야 한다"는 점이 실제적인 장벽이 되었습니다. 템플릿(Templates)은 그들만의 독자적인 방언을 가지고 있었습니다. CLI는 너무 많은 파일을 생성했습니다. 앱이 커질수록 빌드(Build) 속도가 느려졌는데, 저는 최근 대규모 실제 앱에서 이를 측정해 보았고, 그 원인이 번들러(bundler)가 아닌 대부분 타입 체커(type-checker)의 잘못임을 발견했습니다.

이 모든 것의 밑바탕에는 일관된 베팅이 있었습니다. 첫 주 경험(first-week experience)을 희생하더라도, 대규모 팀과 긴 타임라인에 최적화하겠다는 베팅 말입니다. Angular는 의도적으로 지루하고, 일관되며, 장황한(verbose) 방식을 선택했습니다. 만약 당신이 프로토타입을 출시하는 1인 개발자였다면, 비용은 지불하면서 이점은 거의 얻지 못했을 것이고, 이를 체감했을 것입니다.

지난 몇 년 동안 표면적인 불만 사항 중 많은 부분이 정리되었습니다. 독립형 컴포넌트(Standalone components)가 NgModules를 없앴습니다. 시그널(Signals)은 switchMap이 무엇인지 알 필요 없이 반응성(reactivity)을 제공합니다. 내장 제어 흐름(Built-in control flow)이 구조적 지시어(structural directives)를 대체했습니다. 존리스(Zoneless)가 안정화되었습니다. angular.dev는 진정으로 훌륭한 문서입니다. Angular v22는 Webpack 빌더를 폐기하고 안정적인 esbuild 및 Vite 빌더를 채택했습니다. 사람들이 불평하는 프레임워크는 종종 그들이 2019년에 마지막으로 사용했던 프레임워크인 경우가 많습니다.

하지만 표면을 정리한다고 해서 근본적인 베팅이 변한 것은 아니며, 바로 그 베팅이 흥미로워지는 지점입니다.

Angular가 항상 잘해왔던 것

Angular의 실제 차별점은 템플릿이나 DI(의존성 주입, Dependency Injection) 구문이 아니었습니다. 그것은 Angular가 빌드하기 전에 애플리케이션의 얼마나 많은 부분을 검증하려고 시도하느냐에 있었습니다.

엄격한 템플릿 타입 체크 (Strict template type-checking)가 핵심입니다. Angular는 모든 템플릿에 대해 타입 체크 블록을 생성하므로, {{ user.nmae }}는 빌드 에러가 되고, 잘못된 타입의 input()에 바인딩된 값도 빌드 에러가 되며, 임포트(import)를 잊어버린 디렉티브 (directive) 또한 빌드 에러가 됩니다. 스테이징 환경에서 페이지에 빈 공간이 생기는 것이 아니라, 빌드 자체가 실패하는 것입니다.

이것은 공짜가 아닙니다. 수백 개의 컴포넌트(component)가 있는 실제 Angular 앱을 네 가지 방식으로 벤치마킹했을 때, 전체 프로그램 타입 체크 (whole-program type-check)만으로 약 15초가 소요되었는데, 이는 타입 체크가 없는 전체 빌드 시간과 거의 비슷했습니다. 이 비용은 보증을 위한 대가이며, Angular 역사의 대부분 동안 사람들은 자신들이 사고 있는 대상에 대해 진정으로 인정하지 않은 채 이 비용을 원망해 왔습니다.

의존성 주입 (Dependency injection)은 연결(wiring)에 대해 유사한 역할을 수행합니다. 이는 선언되고, 타입이 지정되며, 정적으로 해결(resolvable) 가능합니다. 즉, 프로바이더 (provider)가 누락되면 세 단계 깊은 컴포넌트에서 나타나는 undefined 값이 아니라, 알려진 메시지와 함께 알려진 실패로 나타납니다. HttpClient는 타입이 지정되어 있습니다. Router도 타입이 지정되어 있습니다. CLI는 컴파일러가 기대하는 형태에 이미 부합하는 코드를 생성합니다.

프로덕션 준비가 된 Signal Forms API는 그러한 철학을 가장 명확하게 보여주는 최근의 표현입니다. 유효성 검사 (Validation)는 타입이 지정된 모델에 대해 한 곳에서 데이터로서 선언됩니다:

import { Component, signal } from '@angular/core';
import { form, FormField, required, email, minLength } from '@angular/forms/signals';

...

schemaPath.email은 런타임(runtime)에 조회되는 문자열 키가 아닙니다. LoginData의 필드 이름을 변경하면 컴파일 오류가 발생합니다. 또한 Zod 또는 Valibot 스키마를 직접 전달받는 validateStandardSchema도 있습니다. 따라서 서버에서 동일한 페이로드(payload)를 이미 검증하고 있다면, 규칙을 두 번 작성하는 대신 스키마를 공유할 수 있습니다.

이것이 프레임워크 전체에 걸쳐 적용되는 패턴입니다. 무엇이 참인지 명시하고, 컴파일러가 이를 확인하게 하며, 빌드 타임(build time)에 실패하도록 만드는 것입니다.

에이전트(Agents) 환경에서 이것이 더 중요한 이유

코드를 작성하는 에이전트에게는 사람이 직접 코드를 작성할 때는 고려하지 않는 두 가지가 필요합니다. 바로 정답의 범위가 좁아야 한다는 것과, 틀렸을 때 빠르게 알아낼 수 있는 방법입니다.

Angular는 이 두 가지를 모두 제공하며, 이는 우연이 아닙니다. 대규모 팀이 자신이 작성하지 않은 코드를 안전하게 변경할 수 있고, 잘못되었을 때 즉시 알림을 받을 수 있도록 설계된 프레임워크는 이미 에이전트가 작업할 수 있는 프레임워크의 요건을 대부분 갖추고 있습니다. 대상(audience)이 변했을 뿐, 요구사항은 변하지 않았습니다.

정답의 범위가 좁은 이유는 공식적으로 지원되는 선택지의 집합이 훨씬 작기 때문입니다. 하나의 라우터(router), 하나의 의존성 주입(DI) 시스템, 하나의 HTTP 클라이언트, 그리고 ng generate가 생성하는 하나의 프로젝트 레이아웃이 존재합니다. 모델이 Angular 컴포넌트를 작성할 때, 학습 데이터에 모두 존재하고 모두 정답인 네 가지 라우터나 세 가지 데이터 페칭(data-fetching) 라이브러리 사이에서 고민할 필요가 없습니다. 생태계의 파편화(fragmentation)는 주관이 뚜렷한 개발자에게는 좋지만, 특정 저장소(repo)가 어떤 스택을 선택했는지 추측해야 하는 생성기(generator)에게는 가혹합니다. 과거에 Angular의 경직성(rigidity)은 불만 사항이었지만, 에이전트가 주도하는 시대에는 그것이 강력한 레버리지(leverage)가 됩니다.

빠른 피드백은 타입 체커 (type-checker)로부터 옵니다. 입력 이름을 환각(hallucinate)하거나, 잘못된 타입을 바인딩하거나, imports에 컴포넌트를 추가하는 것을 잊어버린 에이전트는 파일명과 줄 번호가 명시된 ng build 메시지를 통해 이를 알게 됩니다. 그것은 에이전트 스스로가 닫을 수 있는 루프(loop)입니다. 제가 생성된 코드에서 실제로 걱정하는 실패 모드 (failure mode)는, 실행은 되지만 미묘하게 잘못된, 그럴듯해 보이는 것입니다. 템플릿 타입 체킹 (template type-checking)은 바로 그런 범주의 오류들을 통째로 잡아냅니다. 그 15초의 비용은 절대 지치지 않는 자동화된 리뷰어를 사는 것과 같습니다.

안전하게 구축하는 바이브 코더 (Vibe Coders)

위의 모든 내용은 당신이 코드를 읽고 있다는 것을 전제로 합니다. 지금 당장 코드를 (적어도 면밀히) 읽지 않는 사람들도 많으며, 저는 그것이 반드시 나쁜 작업 방식이라고 생각하지는 않습니다. 다만, 그것은 당신이 프레임워크에 무엇을 기대해야 하는지를 변화시킵니다.

만약 코드를 면밀히 읽지 않는다면, 질문은 '코드를 작성하기가 얼마나 좋은가'에서 '프레임워크가 무엇을 통과시키지 않고 거부하는가'로 바뀝니다. 훑어보는 것만으로는 잡을 수 없는 버그는 당신이 클릭하지 않은 페이지에서만 나타나는 버그인데, Angular는 그런 많은 오류를 빌드 실패 (failed build)로 바꿔버립니다. 빌드 실패는 무시하기 어렵습니다.

따라서 조언은 지루할 정도로 단순합니다: 빌드를 실행하고, 자주 실행하세요. 그것이 당신이 가질 수 있는 가장 저렴한 리뷰입니다. Angular는 에이전트가 최신 문서를 참조하고 자신의 빌드 에러를 읽을 수 있도록 안내하는 AI 에디터를 위한 설정 (setup for AI editors)을 제공하며, 이는 몇 분의 시간을 투자할 가치가 있습니다.

이를 반드시 설정하세요. 왜냐하면 모델이 알고 있는 Angular의 개념은 몇 년 전의 것이기 때문입니다. 모델은 예전 방식으로 코드를 작성할 것이고, 그 코드는 여전히 작동하며, 아무런 경고도 주지 않을 것입니다. 그러다 나중에 현대적인 요소를 추가했을 때 두 스타일이 서로 맞지 않는다는 것을 뒤늦게 깨닫게 됩니다. 모델에게 당신이 사용하는 버전을 알려주고, 시그널 (signals)과 스탠드얼론 컴포넌트 (standalone components)를 명시적으로 요청하세요.

빌드가 통과되었다는 것은 코드가 결합되어 있다는 뜻이지, 당신이 원하는 대로 동작한다는 뜻은 아닙니다. 컴파일러는 오타는 잡아내지만, 잘못된 기능은 결코 잡아내지 못합니다. 올바른 것을 만드는 것은 여전히 당신의 몫입니다.

그것은 제가 기꺼이 받아들일 만한 거래입니다. 모든 프레임워크는 당신이 자유롭게 작업하도록(vibe) 내버려 둡니다. 하지만 Angular는 당신이 작업하는 동안 당신의 결과물을 검증해 주는 유일한 프레임워크입니다.

로드맵이 말하는 것

Angular 로드맵은 이 점에 대해 이례적일 정도로 직설적입니다. 이 로드맵은 프레임워크의 세 가지 목표를 나열하고 있는데, 그 첫 번째가 개발자를 위한 AI 경험(AI experience) 개선입니다. 그다음은 개발자 경험(developer experience), 그리고 성능(performance) 순입니다.

그중 대부분은 이미 존재합니다. 위에서 언급한 에디터 설정은 CLI에 포함된 MCP 서버와 일련의 공식 에이전트 스킬 (agent skills)을 기반으로 구축되었으며, 이들과 함께 실험해 볼 수 있는 AI 튜터와 WebMCP도 있습니다. 또한 로드맵은 코드 생성(code generation) 품질을 평가하고, 이를 개선할 수 있다면 프레임워크 자체를 변경하겠다고 약속합니다. "모델이 더 나은 코드를 생성할 수 있도록 API를 변경하겠습니다"라는 태도는 "더 나은 문서를 작성하겠습니다"라는 태도와는 차원이 다릅니다.

성능 개선 작업 역시 동일한 순환 구조 측면에서 중요합니다. 팀은 Microsoft의 Go 언어 기반 TypeScript 포트와의 호환성을 프로토타이핑하고 있으며, 로드맵에서는 이를 일반적인 TypeScript 컴파일 속도가 5배에서 10배 빨라지는 것으로 설명합니다. Angular의 컴파일러는 TypeScript 프로그램을 직접 감싸기 때문에, 템플릿 타입 체크(template type-checking)를 위한 이 솔루션이 도입되면 비용이 많이 들었던 보장(guarantee) 과정을 훨씬 저렴하게 처리할 수 있습니다. 그 수치의 아주 일부만 개선되더라도, 전체 체크(full check)를 실행하려는 의지 자체가 달라질 것입니다.

그렇다면 Angular를 선택해야 할까요?

만약 팀의 인력 교체(turnover) 속에서도 살아남아야 하는 무언가를 구축하고 있다면, 검증 규칙(validation rules)이 여러 컴포넌트에 흩어져 있는 대신 하나의 타입이 지정된(typed) 장소에 있기를 원한다면, 템플릿에서의 실수가 고객 지원 티켓(support ticket)이 되기보다 빌드 실패로 나타나기를 원한다면, Angular의 트레이드오프(tradeoffs)는 5년 전보다 오늘날 더 타당하게 느껴질 것입니다. 여러분이 무언가에 대한 생각을 바꿀 필요는 없었습니다. 시그널(signals)과 스탠드얼론 컴포넌트(standalone components)가 도입되면서 형식적인 절차(ceremony)의 비용은 낮아졌고, 머신(machine)이 초안을 작성하기 시작하면서 강제된 정확성(enforced correctness)의 가치는 높아졌습니다.

만약 여러분이 이미 다른 생태계에서 빠르고, 배포하는 모든 코드를 직접 검토한다면, 이 중 그 어떤 것도 전환을 권장하는 근거가 되지 않습니다. 단 한 번도 그런 적은 없었습니다.