3명으로 시작한 작은 불씨 — Angular 다큐멘터리를 보고
백엔드를 주로 하던 나를 프론트엔드로 데려간 것이 Angular였다. 그 프레임워크의 다큐멘터리에 한글 자막을 붙이고 내용을 정리했다.
현재 웹 프레임워크 판은 사실상 “React 독주, Vue 및 Angular 2위, 그 외 나머지” 구조로 볼 수 있다.
그중 Angular 는 주로 백엔드를 하던 나에게 프론트엔드를 쉽게 접할 수 있게 해 준, 지금도 꾸준히 쓰고 있는 고마운 프레임워크다. 최근 Angular 에 대한 다큐멘터리가 나와 한글 자막을 붙이고 관련 내용을 정리했다.
1. 탄생과 초기 성장 (AngularJS)
Angular 는 웹 애플리케이션 개발에서 반복되는 데이터 전달(marshaling) 문제를 단순화하려는 아이디어에서 시작됐다. 초기 목표는 HTML 에 추가적인 어휘를 도입해 디자이너처럼 코딩 지식이 부족한 사람도 쉽게 웹 애플리케이션을 만들게 하는 것이었다. Misko Hevery 는 Adam Abrans 와 협력해 프런트엔드 프레임워크와 데이터베이스 기능을 결합한 ‘Get Angular’ 를 개발했다.
이후 Misko 는 구글 내부 피드백 도구 개발 프로젝트에서 자신이 만들던 AngularJS 를 써서, 몇 달간 어려움을 겪던 개발 기간을 단 3주로 단축시키는 성과를 냈다. 이를 계기로 AngularJS 는 구글 내부 프로젝트로 발전했고, 초기 소규모 팀에서 Igor Minar 등 외부 인력을 영입하며 커졌다.
AngularJS 는 적은 코드로 풍부하고 상호작용적인 UI 를 만들 수 있다는 점, 특히 클라이언트 측 렌더링으로 동적 UI 구현이 쉽다는 점에서 큰 호응을 얻었다. 초기 개발은 정해진 계획보다 팀원들의 열정과 아이디어를 바탕으로 유기적으로 진행됐다. 구글 내 다른 팀들로부터 충분한 인정을 받지 못하고 자원 확보에 어려움을 겪었지만, 오픈소스 커뮤니티의 활발한 기여로 빠르게 성장했다.
Angular 1.0 출시 후 폭발적인 관심을 받았고, 커뮤니티 주도로 열린 첫 ng-conf 는 티켓 판매 10초 만에 매진될 정도로 인기가 높았다. 양방향 데이터 바인딩, 의존성 주입, 디렉티브 같은 기능은 당시 개발자들에게 혁신적인 해법으로 다가갔다.
2. 전환기의 도전 (Angular 2와 TypeScript)
Angular 1.3 이후 구글 광고 조직으로 개편되면서, GWT(Google Web Toolkit)에 익숙했던 기술 리더들의 영향으로 타입 안전성에 대한 요구가 커졌다. 이는 Dart 언어 기반으로 차세대 Angular 를 개발해야 한다는 결정으로 이어졌고 팀 내부에 큰 반향을 일으켰다.
이 결정이 결과적으로 TypeScript 도입의 중요한 계기가 됐다. 초기에는 타입 시스템에 회의적이었으나, Dart 작업을 하면서 대규모 애플리케이션 개발에서 타입의 중요성을 인식하게 됐다. ‘AdScript’ 라는 자체 타입 시스템을 구상하기도 했으나, 마이크로소프트 TypeScript 팀과 협력해 TypeScript 를 표준으로 채택했다.
하지만 Angular 2 발표는 큰 논란을 낳았다. Angular 1의 핵심 개념을 폐기한다는 발표 방식은 기존 AngularJS 생태계에 투자했던 커뮤니티의 강한 반발을 샀다. 전환을 어렵게 만들었고, ‘Angular’ 라는 이름 사용의 혼란(AngularJS vs Angular 2+)은 학습과 정보 검색을 더 어렵게 했다. 이 시기의 소통 방식은 오랫동안 Angular 에 대한 부정적 인식을 남기는 원인이 됐다.
3. 내부 혁신과 재정비 (Ivy 엔진)
Angular 2 개발 초기에는 Dart 와 TypeScript 를 동시에 지원하려고 코드를 변환하는 방식을 썼지만 언어 간 차이로 제약이 많았다. 결국 Dart 팀이 Angular Dart 를 별도로 관리(포크)하기로 하면서, Angular 팀은 TypeScript 생태계에 완전히 집중할 수 있게 됐다.
Angular 2 출시 이후 내부 구조 개선과 성능 향상, 특히 쓰이지 않는 코드를 제거하는 트리 쉐이킹 효율을 높이려는 노력이 시작됐다. 이 과정에서 프랑스 Amadeus 개발자들이 제안한 새 렌더링 엔진 프로토타입 ‘Ivy’ 가 채택됐다. Ivy 는 트리 쉐이킹을 핵심 목표로 설계됐다.
그러나 Ivy 프로젝트는 예상보다 훨씬 방대해져 사실상 프레임워크 전체를 재작성하는 작업이 됐고 약 3.5년(7개 릴리스) 이 걸렸다. 가장 큰 어려움은 기존 애플리케이션 코드를 바꾸지 않고 전환할 수 있도록 완벽한 하위 호환성을 지키는 것이었다. 문서화되지 않은 내부 동작 방식까지 똑같이 구현해야 했기에 개발은 매우 복잡했다.
Ivy 는 Angular 8에서 옵션으로 제공된 뒤 9에서 기본 엔진이 됐지만, 구글 내부 시스템과의 호환성 문제 해결과 약 2,500개 내부 앱 마이그레이션 때문에 실제 안정화까지는 더 많은 시간이 필요했다. 이 기간에 외부 커뮤니티에서는 개발이 더디다는 비판과 프로젝트의 미래에 대한 우려가 나왔다.
4. 재도약과 미래 (Signals와 Wiz 통합)
힘든 과정을 지나 Ivy 가 안정화되면서 Angular 는 새로운 혁신의 발판을 마련했다. Ivy 덕분에 전보다 더 빠르고 유연하게 프레임워크를 개선하고 새 기능을 넣을 수 있게 됐다.
이후 팀은 반응성(Reactivity) 시스템 개선에 집중했다. 기존 Zone JS 기반 모델의 성능 한계를 인식하고 OnPush 변경 감지 전략과 RxJS 조합의 장점을 분석했다. 그러나 근본적인 개선을 위해 새로운 반응성 기본 요소를 도입하기로 하고, 여러 프레임워크에서 주목받던 Signals 를 채택했다. Signals 는 RxJS 보다 단순하면서도 상태 관리에 효과적인 모델을 제공한다. 이 과정에서 SolidJS 개발자 등 외부 커뮤니티와의 협력도 이루어졌다.
최근 Angular 는 구글 검색, 포토 등 핵심 서비스에서 쓰는 내부 프레임워크 ‘Wiz’ 와의 통합을 발표했다. 두 팀 모두 Signals 도입을 검토하면서 협력의 계기를 찾았고, 현재 YouTube 모바일 웹 앱 전체가 공동 개발한 Angular Signals 를 쓰고 있다. 이 통합은 Angular 가 구글의 핵심 기술로 자리 잡고 앞으로도 계속 발전할 것이라는 강한 신호로 해석된다. 통합 작업은 Ivy 때와 달리 점진적으로 진행되며, 커뮤니티 피드백과 주요 고객 요구를 계속 반영할 계획이다.
현재 Angular 는 ‘Angular 르네상스’ 시대를 맞고 있다. 새 기능 도입, 문서 개선, 학습 경험 향상으로 개발자 친화적인 프레임워크로 거듭나고 있다.
영상 댓글들
다큐멘터리에 달린 댓글들을 옮긴다. 이 프레임워크가 사람들에게 무엇이었는지가 여기에 있다.
“현재까지 Angular 팀은 제가 함께 일했던 가장 뛰어난 엔지니어들 중 일부였고, 그 팀에서의 시간을 소중히 여깁니다. 몇 년 전 Angular의 경영진 교체는 프레임워크에 일어날 수 있었던 최고의 일이라고 생각합니다. 엔지니어링 작업을 활성화했고 마침내 Angular가 가야 할 방향으로 이끌었습니다.” — _benlesh
“그 당시 AngularJS를 배우면서 프론트엔드 개발자로 전업하고 싶어졌습니다. 비록 Angular 2로 가는 길이 많은 사람들(저를 포함하여)을 React나 Vue로 돌아서게 만들었지만요. 팀 뒤에 있는 분들께 큰 존경을 표합니다. 이것은 웹 진화의 근본적인 기술이었습니다.” — @luizbaldi
“6개월 전에 Angular를 다시 시작했습니다. 마지막으로 사용했던 건 2020년이었죠. 돌아온 것은 제가 내린 최고의 선택이었고, 바로 Angular 18로 뛰어들었습니다. 제 미래 앱과 커리어는 여기에 달려 있습니다.” — @hbfl3x50
“초창기인 12/13년경 AngularJS를 접했던 것을 시작으로 이 모든 여정을 함께했습니다. 오늘날까지도 저는 Angular 애플리케이션을 출시합니다. 지금보다 더 좋았던 적은 없었습니다.” — @nomiscph
“AngularJS(정말 사랑했던)부터 과거 제가 맹목적으로 ’네, Angular 2로 업그레이드합시다’라고 말했던 때, TypeScript라는 벽돌 벽에 부딪혔던 때, 하지만… 프레임워크가 현재 v17+에 이르기까지, 기본 Standalone Components에서 Signals까지, 이 다큐멘터리는 매우 즐겁고, 치유적이며, 향수를 불러일으켰습니다.” — @marklreyes
“이 다큐멘터리 덕분에 ‘새로운’ Angular 프레임워크로 나아가는 길에 대한 흥미로운 점들을 배웠습니다. 제가 상세히 언급되었으면 했던 몇 가지 사항이 있습니다. 모듈식 프로젝트에서 Standalone Components로의 전환도 (Ivy와 Signals만큼 중요했습니다). 타입 지정 반응형 폼도 큰 이정표였습니다.” — @PhaseControlDNB
“드디어! 누군가 Angular 생태계에서 null에 대한 집착을 설명해 주었네요 :) 솔직히, 저는 핵심 팀만큼 흥분되지는 않습니다. 우리 개발자들에게는 또다시 많은 코드를 재작성해야 하는 일입니다. 동시에, 만약 당신이 젊고 최근에 합류했다면, 새로운 Angular로 새롭게 시작하는 것이 좋은 선택일 수 있습니다.” — @fetis26
“모든 Google 서비스가 Angular로 구축되도록 Wiz와 완전히 통합되기를 바랍니다. 그 시점에는 되돌릴 수 없을 것이고 Angular가 가장 중요해질 것입니다. 저는 ’Angular는 프레임워크계의 키아누 리브스’라는 문구에 동의합니다.” — @masterterricola