올해로 여덟 번째를 맞이한 FEConf의 세션은 그 퀄리티가 높기로 유명합니다. 프론트엔드 개발자로 근무하는 실무자들이 현장에서 마주친 문제와 그 해결 과정을 생생하게 전달하기 때문이죠. 그런 만큼 올해 FE의 새로운 트렌드를 가장 빠르게 만날 수도 있고요. 어떤 이야기가 오갈지 궁금한 분들을 위해 요즘IT에서 이번 FEConf 2024 발표자들을 만났습니다. 메인 세션의 발표부터 이번 행사에 새로 도입되는 라이트닝 토크 발표까지. 2024년, 프론트엔드 개발자들은 어떤 문제를 만났고 무슨 고민을 하고 있을까요?
이번 글에서는 앞서 발행된 ‘크로스 플랫폼 디자인 시스템, 1.5년의 기록(1)’에서 살펴본 정의를 실제 컴포넌트 구현에 어떻게 적용할 수 있는지 알아보겠습니다. 우선 차크라와 스펙트럼의 API를 다시 한번 살펴보겠습니다. 제품 언어를 만드는 입장에서 일관성을 최우선으로 추구하여 오른쪽의 API처럼 간결하게 제공하고 싶은 것은 당연한 생각입니다. 그러나 일관성을 추구하는 형태로 제공함으로써 발생할 수 있는 모든 케이스의 90%를 커버할 수 있다고 하더라도, 사용자 입장에서는 커버하지 못하는 10%의 케이스로 인해 개발이 지연될 수 있습니다.
‘React Native, Metro를 넘어서’ 1회에서는 번들러가 무엇인지와 번들러의 역할로 Resolution, Load, Optimization에 관해 소개했습니다. 1부 마지막에서 파일 크기를 줄이기 위한 Optimizaton을 간단히 이야기하고, 파일 크기를 줄이는 테크닉에는 크게 Minification과 Tree Shaking이 있다고 말씀드렸죠. 이 글인 2부에서는 Metro와 ESBuild의 차이를 조금 더 명확하게 알기 위해서, 이 각각의 테크닉이 구체적으로 어떤 역할을 하는지 살펴보겠습니다. 그리고 토스에서 Metro를 ESBuild로 바꾼 여정도 소개합니다.