본문으로 건너뛰기
피드

Ember.js 7.0 공개, 새 기능보다 ‘예고된 정리’에 집중한 메이저 릴리스

frontend 약 7분
vote
0
댓글
북마크

Ember.js 7.0은 새 공개 API를 추가하지 않고, 6.x 주기에서 이미 폐기 예정이던 기능을 제거하는 데 집중한 메이저 릴리스다. Ember 6.12는 장기 지원 버전이 됐고, 7.0으로 가려면 6.12에서 경고를 모두 없앤 뒤 올리는 흐름이 권장된다. 6.x 동안 기본 빌드 시스템이 Embroider와 Vite 기반으로 바뀌고, 템플릿 태그 기반 작성 방식이 기본값이 된 점도 중요하다.

  • 1

    Ember.js 7.0은 새 공개 API 없이 기존 폐기 예정 기능 제거와 버그 수정 중심으로 출시됨

  • 2

    Ember 6.12가 장기 지원 버전이 됐고, 7.0 업그레이드는 6.12에서 경고를 제거한 뒤 진행하는 방식이 권장됨

  • 3

    6.8부터 새 앱 기본값이 Embroider와 Vite 기반 빌드 시스템으로 바뀜

  • 4

    import Ember from 'ember', ember-source의 AMD 번들 배포, @ember/service의 inject 가져오기가 제거됨

  • Ember.js 7.0이 나왔지만, 이번 릴리스의 메시지는 “새 기능 잔뜩”이 아니라 “예고했던 정리 끝냄”에 가까움

    • Ember의 메이저 버전 정책상 7.0은 7.0 전까지 폐기 예정으로 표시됐던 기능 제거와 버그 수정이 중심임
    • 새 공개 API는 추가되지 않았고, 새 폐기 예정 항목도 없음
    • 동시에 이전 버전인 Ember 6.12는 장기 지원 버전이 됨
  • Ember 팀은 큰 메이저 릴리스에 신기능을 몰아넣는 방식을 피하고 있음

    • 새 기능은 보통 마이너 릴리스에서 하위 호환성을 유지한 채 먼저 제공함
    • 기존 앱이 새 기능을 실험하면서도 업그레이드 충격을 줄일 수 있게 하려는 전략임
    • 그래서 Ember 7.0은 화려하진 않지만, 운영 중인 앱 입장에선 예측 가능성이 훨씬 중요함

중요

> Ember 7.0으로 바로 뛰기보다 6.12 최신 패치에서 폐기 경고를 0개로 만드는 게 핵심 루트임. 6.12에서 경고 없이 빌드와 테스트가 통과하면 7.0 업그레이드 때 추가 변경이 거의 없어야 한다는 게 공식 안내임.

  • 6.x 라인에서 이미 꽤 큰 변화가 들어갔음

    • Ember 6.1에서는 ember-source를 v2 애드온으로 배포하기 시작해서 Embroider가 ember-source를 직접 소비할 수 있게 됨
    • Ember 6.3에서는 템플릿 태그 컴포넌트를 라우트 템플릿으로 쓰는 지원이 들어감
    • Ember 6.8에서는 Embroider와 Vite 기반 빌드 시스템이 새 앱의 기본값이 됨
    • 같은 6.8에서 strict-mode, 즉 템플릿 태그 컴포넌트 작성 방식도 기본값으로 바뀜
  • 특히 Ember 6.8은 최근 Ember 프로젝트 생성 방식에서 가장 큰 전환점으로 언급됨

    • Ember 코어 팀은 Embroider와 Vite 빌드 시스템, strict-mode 템플릿을 수년간 작업해 왔음
    • 이전에는 얼리어답터가 선택해서 쓰는 기능에 가까웠지만, 6.8 이후 새 앱을 만들면 이 현대적인 구성이 기본 경험이 됨
    • 개별 컴포넌트를 전체 프로젝트 없이 렌더링할 수 있는 renderComponent API도 6.8에서 추가됨
  • 6.x 동안 내부 구조 정리도 꽤 많이 진행됨

    • glimmer-vm 모노레포가 ember.js에 병합돼 렌더링 엔진과 Ember 통합을 더 빠르게 반복할 수 있게 됨
    • router.js 저장소도 ember.js 저장소로 병합돼 새 라우터 아키텍처 실험과 Route Manager RFC 구현을 준비함
    • 패키지 배포는 OIDC 기반으로 업데이트됐고, broccoli 등 의존성 보안 경고를 줄이는 작업도 이어짐
    • 새 앱 생성 시 폐기 경고를 줄이는 작업도 계속 진행 중임
  • 업그레이드 경로는 꽤 명확함

    • 우선 앱에서 쓰는 애드온을 가능한 최신 버전으로 올려, 의존성 내부의 폐기 API 사용을 줄이는 게 권장됨
    • 그다음 Ember 6.12 최신 패치로 올리고, 앱이 정상 빌드되는지 확인함
    • 6.8 경계를 넘을 때는 빌드 시스템 변화 때문에 ember-cli 설정 조정이 필요할 수 있음
    • 모든 폐기 경고를 해결하고 테스트가 통과하면 npx ember-cli-update --to 7.0 같은 방식으로 7.0에 진입함
  • 7.0에서 제거된 대표 항목은 오래된 사용 패턴들임

    • import Ember from 'ember'가 제거됨
    • ember-source의 AMD 번들 배포가 제거됨
    • @ember/service에서 inject를 가져오는 방식도 제거되고, import { service } from '@ember/service' 형태를 써야 함
  • 버그 수정도 꽤 실무적인 것들이 포함됨

    • 런타임 템플릿 컴파일러의 strict mode 기본 전역 지원이 들어감
    • 인라인 SVG 안의 LinkTo가 애플리케이션을 다시 로드하던 문제가 수정됨
    • 빈 문자열에 바인딩된 라디오·체크박스 입력에서 value 속성이 빠지던 문제가 수정됨
    • trackedMap과 trackedWeakMap에서 기존 키의 반응성이 깨지던 문제도 고쳐짐
    • destroy 이후 오래된 메타데이터 참조를 지워 가비지 컬렉션이 가능하도록 한 수정도 포함됨

기술 맥락

  • Ember 7.0의 선택은 메이저 버전을 신기능 발표장이 아니라 정리 지점으로 쓰는 거예요. 이미 6.x에서 경고를 띄우고 마이그레이션 길을 열어둔 다음, 7.0에서 그 낡은 API를 제거하는 방식이라 운영 중인 앱이 계획을 세우기 쉬워요.

  • Embroider와 Vite를 기본값으로 가져간 건 개발 경험을 현대화하려는 결정이에요. Ember는 오래된 대형 앱이 많은 생태계라 빌드 시스템을 확 바꾸면 부담이 큰데, 6.8부터 새 앱 기본값으로 먼저 굳히고 7.0에서는 호환성 정리에 집중하는 흐름을 택했어요.

  • 템플릿 태그와 strict-mode 기본화도 같은 방향이에요. 템플릿과 자바스크립트의 경계를 더 명확하게 만들고, Glint 같은 타입 지원 도구가 제대로 힘을 쓰게 하려면 작성 방식 자체가 바뀌어야 하거든요.

  • 업그레이드에서 중요한 건 7.0 명령을 먼저 치는 게 아니라 6.12에서 경고를 없애는 일이에요. 폐기 경고는 단순 잔소리가 아니라 다음 메이저에서 실제로 깨질 코드를 미리 알려주는 신호라서, 테스트 통과만큼 중요하게 봐야 해요.

요즘 프론트엔드 생태계에서 메이저 버전은 ‘큰 신기능 쇼케이스’처럼 보이기 쉬운데, Ember 7.0은 반대로 오래 예고한 정리를 메이저에서 실행하는 쪽이다. 대규모 앱을 오래 운영하는 팀 입장에선 이런 예측 가능한 업그레이드 정책이 신기능보다 더 큰 기능일 수 있다.

댓글

댓글

댓글을 불러오는 중...

frontend

타입스크립트 7.0, Go 네이티브 포팅으로 빌드가 8~12배 빨라졌다

마이크로소프트가 타입스크립트 7.0을 출시하면서 기존 자바스크립트 기반 구현을 Go로 네이티브 포팅했다. 전체 빌드는 평균 8~12배 빨라졌고, VS코드 빌드는 125.7초에서 10.6초로 줄었으며, 슬랙은 CI 타입 검사 시간을 7.5분에서 1.25분으로 낮췄다.

frontend

타입스크립트 7 공개, 고 포팅으로 빌드가 최대 10배 이상 빨라짐

마이크로소프트가 고(Go)로 네이티브 포팅한 타입스크립트 7을 공개했다. 전체 빌드는 보통 8~12배 빨라지고, VS 코드 코드베이스에서는 125.7초가 10.6초로 줄었으며, 편집기 첫 오류 표시도 17.5초에서 1.3초 미만으로 내려갔다.

frontend

“98% 지원”이 생각보다 별로 안 넉넉한 이유

브라우저 기능 지원률 98%는 얼핏 높아 보이지만, 실제 서비스에서는 2%의 사용자를 깨진 화면 앞에 세우는 숫자일 수 있다는 글이다. 특히 일반 통계와 내 서비스 방문자 분포는 다를 수 있고, 실제 사례로 어떤 사이트는 최신 중첩 CSS 기능 지원 브라우저가 방문자의 약 70%뿐이었다.

frontend

메타, AI가 읽고 쓰는 디자인 시스템 ‘Astryx’ 오픈소스로 공개

메타가 내부 디자인 시스템 Astryx를 오픈소스로 공개했다. React와 StyleX 기반의 150개 이상 접근성 지원 컴포넌트, 디자인 토큰, 테마, 템플릿, CLI를 제공하며, 특히 AI 에이전트가 컴포넌트 구조를 이해하고 UI를 생성·수정할 수 있도록 MCP 서버까지 포함한 점이 핵심이다.

frontend

shadcn/ui, 기본 컴포넌트 라이브러리를 Radix에서 Base UI로 변경

shadcn/ui가 새 프로젝트의 기본 컴포넌트 라이브러리를 Radix가 아니라 Base UI로 바꿨어. Radix 지원은 계속되지만, Base UI가 안정화됐고 주간 다운로드 600만 이상, shadcn/create 신규 프로젝트 선택 비율 2대1이라는 이유로 기본값을 바꾼 거야. 동시에 채팅 UI용 MessageScroller와 관련 컴포넌트, headless 패키지인 @shadcn/react도 공개됐어.