나는 실무에서 Angular를 오랫동안 사용해 온 프론트엔드 개발자다. 그만큼 Angular에 익숙하고, Angular의 발전 과정을 몸소 겪어 왔다. 그럼에도 개인적으로 React 혹은 React Native를 공부해 보기도 하고 꾸준히 트렌드를 쫓아 공부하려고 노력했다. 요즘 프론트엔드 대세는 누가 뭐래도 React인 것은 분명하다. 여러 설문 조사 결과나 넘쳐나는 프론트엔드 개발자 채용 공고가 이를 뒷바침한다. 하지만 그동안 개인적으로는 능숙하기도 하고 편한 Angular를 React보다 더 자주 선택해 왔던 것 같다.
그렇다면 내가 React보다 Angular를 선호해 왔던 이유를 알아보고자 한다.
Angular가 좋은 점
깔끔한 개발 환경
기본적인 개발 도구들은 이미 갖춰져 있다. React와 달리 의존성 주입, 데이터 바인딩, 비동기 처리 등 기본 제공되는 모든 것을 갖추고 있기 때문에 단일 페이지 어플리케이션(SPA)을 빠르게 개발 할 수 있다. 다만 이를 위해서는 개발자가 Angular 프레임워크에 맞게 개발을 할 수 있어야 해서 학습 곡선이 매우 높다. 그러나 일단 마스터하면 Angular는 완전한 도구가 된다. 상대적으로 나는 Java Spring 프레임워크에 익숙했던 개발자라 Angular가 훨씬 수월하게 느껴졌다.
두터운 커뮤니티와 꾸준한 개발
Angular는 구글 개발자의 작은 개인 프로젝트로부터 시작해서 거대하게 발전해 온 프레임워크다. 구글의 전폭적인 지원 덕분에 당시 가장 인기 있는 웹 프레임워크 중 하나가 되었다. 그리고 지금도 여전히 Angular는 두터운 커뮤니티에 의해 지속적인 발전을 이루고 있고 매년 꾸준히 성능 개선을 해온 프레임워크 중 하나였다. 또한 마니아층이 워낙 두텁기 때문에 공부를 하거나 문제가 생겼을 때 관련된 자료도 굉장히 많아서 정말 좋았다.
엔터프라이즈 환경에 적합
비교적 복잡한 웹 애플리케이션을 개발해야 할 때, Angular의 아키텍쳐가 빛을 발한다. 프론트엔드에서도 백엔드처럼 엔터프라이즈 애플리케이션에 대한 필요성이 대두되던 시기에 개발 관점에서 Angular는 모듈 의존성 덕분에 신뢰도를 높일 수 있다는 느낌을 받았다. Java 진영에서 Spring 프레임워크가 오랫동안 쓰임 받고 있는 것처럼 말이다. Angular는 개발자 마음대로 코딩하기 보단 프레임워크에 맞춰 개발을 하도록 강제하기 때문에 비교적 휴먼 에러를 줄일 수 있고 안전하다고 평가받는 것 같았다.
React가 불편하다고 느꼈던 이유
Boilerplate의 부재
내가 React를 공부하고 개인 프로젝트에 사용해 보려고 하던 때에는 Create React App(CRA)라는 도구도 없었고, 일일히 디펜던시를 선택하고 개발 환경을 구축하는 일이 Angular에 이미 익숙한 내게 상대적으로 큰 걸림돌로 느껴졌다. Boilerplate를 찾아보려 해도 사실 당시에 워낙 많은 라이브러리들이 떠오르던 상황이라 Boilerplate들의 디펜던시도 다 제각각이었고 React를 잘 모르는 상태에서 어떤 Boilerplate가 잘 되어 있는 건지 선택하기도 쉽지 않았다.
수많은 라이브러리 중에 뭘 선택해야 할지 모르겠음
당시에 Redux 관련 라이브러리만 해도 많은 라이브러리가 존재하고 단순한 통신 관련 라이브러리도 프로젝트에 맞는 고민이 필요했다. 그런 걸 비교하고 선택하는 데 시간을 쓰는 것 보다 Angular로 개발하는 게 더 이점이 크다고 느꼈다. React 자체는 학습곡선이 높지 않은데 여러가지 개발 도구들을 조합해야 할 때 Redux부터 시작해서 굉장히 난이도가 올라간다는 생각이 들어 오히려 기본만 공부해도 되는 Angular가 상대적으로 쉽게 다가왔다. 물론 이미 Angular에 익숙한 상태라 더 그렇게 느꼈겠지만.
Javascript 환경에서 실수할 가능성이 높았다
React는 Javascript 기반에서 돌아가기 때문에 Javascript의 유연성과 태생적 한계로 인한 에러들을 마주할 일이 상대적으로 높았다. Angular는 이미 버전 2부터 Typescript가 거의 기본이 되었기 때문에 정적 타입을 기반으로 컴파일 단계에서 오류를 검출할 수 있는 장점이 있었다. 그러나 Angular의 학습곡선을 이야기하면서 항상 빠지지 않았던 것이 Typescript 문제였다. 당시에는 Typescript를 학습해야 하는 것에 대한 부정적인 의견이 많았다. 나는 당연히 Typescript에 대한 오해라고 생각했고, 나름대로 웹팩 등을 이용해 React를 쓸 때 Typescript를 사용해 보고자 했지만 당시에는 Typescript 환경을 구축하려면 상당한 시간을 들여 개발 환경을 세팅해야만 했다. 그래서 쉽게 Typescript를 사용하여 개발할 수 있는 Angular를 더 선호했다. 물론 지금은 React 진영에서도 Typescript 환경이 대중화된 것 같다.
Angular를 오래 사용하면서 든 생각
프론트엔드에서 이정도로 설계할 이유가 있을까?
프론트엔드에서 과연 완전한 프레임워크가 얼마나 유의미한가에 대한 의문이 생겼다. 안정성이 최우선인 프로젝트라면 필수가 될 수 있겠다 싶은데, 한 편으로 그 부분은 개발 외 업무 프로세스나 테스트, 코드 리뷰 등으로도 충분히 방지할 수 있는 부분이라는 생각이 들었다. 완전한 프레임워크는 상대적으로 백엔드에 더 적합하지 않을까 생각한다.
하고자 하는 일은 단순한데 Angular 프레임워크에 맞추기 위해 복잡해지는 로직
결국 UI에서 하고자 하는 일은 단순한데 Angular 구조에 맞추기 위해 설계 고민이 필요한 시점이 생기고, 그로 인해서 컴포넌트 간 통신을 신경쓰는 등 불필요하게 복잡해진다는 느낌이 있다. 추후 유지보수를 위해 코드를 열어보면 Angular 자체의 복잡도로 인해 흐름을 파악하기가 꽤 까다로운 일들이 생기기도 한다.
테스트가 상대적으로 까다로움 - 의존성 주입을 신경써야 함
상대적으로 의존성 주입을 신경쓰지 않으면 테스트하기 굉장히 까다롭다. React에 비해 모듈 의존성 주입을 신경써야 하기 때문에 테스트 코드 자체가 양이 많아지고 어렵다. 만약 모듈 디펜던시 설계를 잘못했다면 테스트 자체가 굉장히 까다로운 부분도 생긴다. React와 비교하자면 Angular 테스트 코드 작성이 더 어렵고 실행이 빠른 비즈니스 환경에서 때로는 테스트를 신경써야 하는 일이 현실성이 없을 수도 있다고 느껴졌다. 여담이지만 그래서 실무에서는 일부 중요한 비즈니스 로직을 외부 함수로 분리할 수 있을 때 주로 테스트를 작성했다.
컴포넌트 내부에 있는 비즈니스 로직을 재사용하기 까다로움
비즈니스 로직 재사용이 React에 비해 까다롭다는 생각이 들었다. React는 Hook 등을 통해서 공유하면 되는데, Angular로 개발하다 보면 부득이하게 컴포넌트에 종속적인 로직이 생긴다. 그럴 경우 재사용이 안되고, 복붙할 수 밖에 없게 되어버린다. 그렇다고 재사용 가능한 컴포넌트를 개발하자니 상대적으로 시간이 너무 오래 걸리거나 요구사항에 비해 불필요하게 오버 엔지니어링처럼 되어버려서 포기하게 되는 경우가 꽤 있었다.
마무리
프론트엔드는 빠른 배포 빠른 실행이 중요한 현대 비즈니스 환경에서 UI/UX 개발에 더 집중하는 게 가장 적합한 시대가 되었다고 생각한다. 더 작게 개발하고 더 빠르게 적용하며, 유연성과 재사용이 중요한 영역이 프론트엔드라고 본다.
위에서 언급했던 생각들을 종합해 봤을 때 그런 점에서 UI 개발에 초점을 맞춘 React가 요즘 개발 트렌드에 딱 맞는 대안이라고 느껴진다. Controller, Directive, Template, Model처럼 분리를 하지 않고 Component 단 하나로 관리하고, 간편한 UI 수정과 재사용에 용이하기 때문이다. 이제는 React도 위에서 언급했던 Javascript 환경이 아니라 Typescript 환경으로 대체 가능하고, 라이브러리도 대중적인 라이브러리가 대략 간추려져서 쉽게 선택하고 사용해 볼 수 있다. CRA나 Next.js 등을 사용해도 된다. CLI 지원도 꽤 많다. Angular에 비해 상대적으로 UI 개발에만 집중할 수 있는 환경이 갖추어진 것 같다.
그래서 이제는 React로 기술 스택을 전환하고자 준비하고 있다.
하지만 전환의 가장 큰 이유는 결국 채용 시장이다. 적어도 좁은 한국 시장에서는 거스를 수 없는 트렌드인 점. 전 직장에서 실제로 Angular 개발자를 뽑으려 해도 정말 사람이 없더라. 현실적으로 나도 이직을 하기 위해서 Angular 보다는 React를 더 공부해야겠다는 다짐을 했다.
늦었지만 나도 대세를 따라 React 개발자가 되기로 결심하고 정진해 나갈 것이다.