Ember.js 7.0 출시 — 잊혀진 줄 알았던 그 프레임워크가 돌아왔어요

"Ember.js? 그거 아직 살아있어요?"

이 질문이 사실 가장 정확한 시작점일 것 같아요. React, Vue, Svelte, Solid… 요즘 프론트엔드 얘기를 하면 이 정도가 기본 메뉴인데, Ember.js(엠버) 는 한국에선 거의 들어볼 일이 없잖아요. 그런데 최근 Ember 팀이 7.0 메이저 버전을 발표했어요. 죽은 줄 알았던 프레임워크가 메이저 버전을 올렸다는 게 놀라운데, 더 놀라운 건 "이게 사실 꽤 잘 만들어진 채로 꾸준히 굴러가고 있었다"는 거예요. 한 번 쯤은 알아둘 가치가 있어요.

잠깐 배경을 짚고 갈게요. Ember는 2011년에 등장한 자바스크립트 프레임워크예요. React보다 2년이나 먼저 나왔어요. 당시엔 "규모 있는 SPA(Single Page Application, 한 페이지 안에서 화면이 바뀌는 웹앱)를 어떻게 체계적으로 만들지"가 큰 고민이었는데, Ember는 "우리가 정답을 줄게"라는 태도로 라우팅, 데이터 관리, 컴포넌트 구조까지 다 정해주는 방식을 택했어요. 이걸 "convention over configuration"(설정보다 관례) 이라고 부르는데, Ruby on Rails에서 빌려온 철학이에요. 개발자가 일일이 정하지 않아도 정해진 길을 따라가면 되는 거죠.

7.0에서 뭐가 달라졌나

이번 릴리스의 핵심은 "오래된 짐을 드디어 정리했다"는 거예요. Ember는 하위 호환성에 굉장히 집착하는 프레임워크로 유명해요. 옛날에 짠 코드가 새 버전에서도 그대로 돌아가야 한다는 원칙을 거의 종교처럼 지켜왔거든요. 그래서 좋은 점도 있었지만, 새 기능을 도입할 때 옛 API와 충돌하는 부분이 쌓여 코드베이스가 무거워졌어요.

7.0은 그 동안 deprecated(곧 제거됨) 표시가 붙어 있던 오래된 API들을 본격적으로 걷어냈어요. 예를 들면 옛날 방식의 컴포넌트 정의 문법, 클래식한 옵저버 패턴, 일부 라우터 훅 같은 것들이 사라졌어요. 대신 6.x에서 계속 권장해 온 "새로운 방식" — 즉 Glimmer 컴포넌트, tracked properties(추적 속성), <template> 태그 컴포넌트 같은 모던 패턴이 정식 표준 자리에 앉았어요.

Glimmer가 뭐냐면, Ember가 내부적으로 쓰는 렌더링 엔진의 이름이에요. React의 가상 DOM과는 좀 다른 방식으로 동작하는데, "어떤 데이터가 바뀌었는지"를 컴파일 단계에서 미리 분석해서 꼭 필요한 DOM만 업데이트해요. 이걸 fine-grained reactivity(세밀한 반응성)라고 부르는데, 요즘 Solid.js나 Svelte 5가 자랑하는 그 컨셉이랑 비슷해요. 사실 Ember는 이 길을 훨씬 일찍부터 걸어왔어요.

tracked properties는 이게 무슨 뜻이냐면, 클래스 안의 어떤 속성을 "이게 바뀌면 화면 다시 그려야 해"라고 표시해두는 데코레이터예요. @tracked count = 0 이렇게 쓰면 count가 변할 때마다 관련 화면이 자동으로 업데이트돼요. Vue의 ref나 React의 useState와 비슷한 개념인데, 클래스 기반이라 객체지향이 익숙한 사람에겐 더 자연스러워요.

다른 프레임워크들과 비교하면

솔직히 시장 점유율로만 보면 Ember는 React, Vue에 한참 밀려요. 그런데 자세히 들여다보면 흥미로운 위치를 차지하고 있어요. LinkedIn, Apple Music 웹, Discourse 같은 굵직한 서비스가 여전히 Ember로 돌아가고 있어요. 한 번 만들면 10년 가는 안정성을 원하는 팀들에게는 여전히 매력적인 선택지인 거죠.

비교하자면 React는 "라이브러리이고 나머지는 알아서 골라 써라" 쪽이고, Vue는 그 중간 어디쯤, Ember는 "라우팅, 데이터, 빌드 도구까지 다 묶음으로 줄게" 쪽이에요. 이런 풀스택 프레임워크 진영에서 최근 SvelteKit, Nuxt, Next.js 같은 후발 주자들이 비슷한 자리를 노리고 있는데, Ember는 "우리는 13년째 이걸 하고 있어"라는 짬에서 나오는 안정감이 있어요.

흥미로운 점 하나는, 최근 프론트엔드 업계가 다시 "opinionated framework(주장이 강한 프레임워크)" 쪽으로 돌아가고 있다는 흐름이에요. React 생태계에서 매번 라우터 고르고, 상태관리 고르고, 폼 라이브러리 고르는 데 지친 사람들이 "그냥 정답 알려줘"를 원하는 분위기거든요. Ember의 철학이 다시 평가받을 수 있는 시기일지도 몰라요.

한국 개발자에게는?

현실적으로 한국 채용 시장에서 Ember를 요구하는 곳은 거의 없어요. 그래서 "당장 배워서 써먹어라"고 하긴 어려워요. 하지만 두 가지 이유로 한 번쯤 들여다볼 가치는 있다고 봐요.

첫째, 프레임워크 설계 철학을 배우는 데 좋은 교재예요. 라우터를 어떻게 1급 시민으로 다뤄야 하는지, 데이터 로딩과 화면 전환을 어떻게 묶어야 하는지에 대한 Ember의 답은 정교해요. 이걸 알면 Next.js나 SvelteKit을 쓸 때도 "이게 왜 이렇게 설계됐는지"가 더 잘 보여요.

둘째, fine-grained reactivity의 원조 격 구현을 볼 수 있어요. 요즘 Signals가 React에도 들어온다 어쩐다 하는데, 이 개념의 실전 사례를 보고 싶다면 Ember의 tracked가 가장 오래된 프로덕션 사례 중 하나예요.