Linkedin을 살펴보던 중 토스에서 프론트엔드 파이트 클럽이란 온라인 토론회를 진행한다길래 내용을 읽어보게 되었고 평소 관심 있었던 주제들이었기 때문에 흥미롭게 생각해 참관 신청을 하게 되었다.
프론트엔드 파이트 클럽은 프론트엔드에 관한 주제에 대해 홍팀과 청팀으로 입장을 나누어서 토론을 하는 모임이였다.
인턴을 하게 되면서 생각의 폭이 이전과는 많이 달라졌다.
이전에는 그냥 배우기에 급급했다면, 요즘은 어떻게 하면 내가 만들고 있는 프로덕트의 성능을 더 향상 시킬수 있을까? 회사의 생산성을 높이기 위해 디자이너와 같이 할 수 있는 게 뭐가 있을까? 등등 내 직업과 관련해서 많은 생각들을 하게 되는 것 같다.
프론트엔드 파이트 클럽(이하 "프파클") 강연을 듣고 많은 생각들이 들었다.
첫 라운드는 조금 가벼운 주제여서 그런지 가볍게 들었지만, 2,3 라운드는 개발자 분들이 많은 수치적인 자료들을 기반으로 말씀을 해주셔서 듣기만 해도 큰 도움이 되었다.
또 댓글들을 보면서 나와 다른 의견을 지닌 분들의 생각을 볼 수 있어서 유익했고 이런 부분을 프론트 개발자들이 신경 쓰고 있구나라는 느낌을 받을 수 있어서 좋았다.
역시 경험을 주고받고 모자란 부분을 깨닫고 채우는 이런 환경에 있을 때 빠르게 성장한다는 느낌을 받는 것 같다.
Round 1: 뛰어난 문제 해결사 동료 vs 커뮤니케이션 친절한 동료
해당 주제는 조금 입장이 극과 극인 한쪽이 뛰어난 대신 한쪽이 결여된 인간.. 같은 느낌이었다.
인성이 파탄 났고 커뮤니케이션이 잘 안 되는데 문제는 잘 해결하는 동료와 간단한 버그도 크게 키워오지만 커뮤니케이션은 기깔난 동료 중 누가 더 낫냐는 것이었다..ㅋㅋ
(후자는 개발자라는 직업이 안 맞는 게 아닌지.. 그냥 다른 직업을 가지면 천재 아닌가?)
회사의 입장에서 생각을 한다면, 아무래도 시간 대비 효율이 좋은 뛰어난 문제 해결사 동료가 더 좋다고 생각한다.
다만, 두 팀원 모두 회사에 필요한 사람들이라고 생각한다.
커뮤니케이션을 친절하게 하는 것도 어떻게 보면 사회생활의 소프트 스킬이기 때문에 이런 소프트 스킬이 더 빛을 발하는 순간이 있다.
클라이언트와의 관계를 잘 맺은 동료가 있다면 내가 실수를 했을 때 클라이언트로부터 방파제가 되어 줄수도 있고, 관계를 잘 형성해 둔 다른 동료분에게 대신 도움을 요청해 줄 수도 있다.
또, 개발적으로도 내가 프론트엔드일때 커뮤니케이션이 친절한 백엔드 분이 있다면 효율이 달라질 수도 있다.
더 쉽게 질문을 하고 의논을 나누는 것만으로도 개발 속도가 엄청나게 빨라질 수 있다는 것을 몸소 체감했기 때문이다..ㅋㅋㅎ
다만 나는 개인적으로 뛰어난 문제 해결사 동료가 되고 싶은 사람이고 지금에 나에겐 후자보다는 전자인 동료가 더 필요하다고 생각한다.
회사에서 일을 하다 보면 기능에 대한 개발은 당연히 할 줄 알아야 하는 부분이고 그 외적인 부분에 대해서 신경을 써야 할 일이 많다.
내가 만든 기능이 버그를 유발할 가능성이 있는가? 크로스 브라우징 테스트는 되었는가? 유지보수 하기 좋게 개발되었는가? 구조적으로 문제는 없는가? 등등 이런 경험에서 나오는 스킬들과 기술들이 현재 나에게 필요하다고 느끼는 순간들이 많았다.
경험을 해보지 않았으니 우선 불완전한 프로토 타입을 만들어보고 개선하는 경험을 해야 했고 모르는 지식이 많아 첫 발을 내딛기까지 많은 자료들을 찾아봐야 했다.
이 과정에서 가끔은 클라이언트에게 불완전한 개발을 해서 전달하기도 하였고 로직을 갈아엎기도 하면서.. 누가 차라리 알려줬으면 하는 순간순간들이 많았다... 그래서 뛰어난 문제 해결사 동료가 있으면 좋겠다고 생각했기도 하다.
하지만 이러한 과정에서 왜 이런 기술들이 나오게 되었고 왜 사장되게 되었는지 스스로 코드를 짜보면서 느낄 수 있었고 다음에는 지금보다는 더 나은 코드를 짜면서 조금씩 성장하고 있음을 느끼는 중이다.
Round 2: CSS vs CSS in JS
2라운드부터는 본격적으로 프론트 기술에 관한 얘기였다.
그래서 그런지 패널분들도 수치적이고 전문적인 자료들을 가져오셨고 정말 듣기만 해도 배울 점이 많구나..라는 생각이 들었다.
패널들의 입장을 간단히 요약하자면 다음과 같았다. (아래 더보기)
홍팀 (CSS)
1. CSS in JS는 실제로 런타임에서 성능 문제를 일으킬 수 있다.
- Chakra UI의 경우 @emotion/styled 의존성을 통해 런타임 CSS in JS를 사용하고 있는데, 개발팀은 이러한 CSS in JS의 성능 문제를 인지하고 있음을 공식적으로 언급했다.
2. CSS-in-JS는 실제로 런타임에서 성능 문제를 일으킬 수 있다.
- useInsertionEffect 이란 hook은 애초에 CSS in JS를 위해 만들어졌다.
- React 개발팀은 CSS in JS의 런타임 주입 방식을 사용해야 하는 경우 useInsertionEffect를 통해 최적화할 것을 권장한다. 하지만, 해당 방식이 최적의 해결책은 아니라고 생각한다.
3. Next.js에서의 CSS-in-JS는 제약이 있다.
- Next.js 13+ 에서는 React 18의 새로운 streaming rendering 방식을 사용하는데, 이 방식에서는 <head>가 <body>보다 먼저 렌더링 된다. 하지만 CSS in JS는 일반적으로 <body>를 렌더링 한 후에 스타일을 생성하기 때문에 문제가 발생할 수 있다.
4. emotion vs pure CSS 성능 테스트
- benchmark 테스트를 했을 때, 순수 CSS는 emotion 보다 최대 6배가량 빠르다.
청팀 (CSS in JS)
1. TailwindCSS 와의 비교
- Tailwind CSS는 zero runtime을 표방하지만 실제로는 추가 라이브러리 사용으로 런타임 오버헤드가 발생할 수 있다. 또한, 클래스 이름 결합이나 동적 스타일링을 위해 추가 라이브러리가 필요할 수 있다.
- CSS in JS는 런타임에 스타일을 생성하지만 점차 성능 개선을 통해 부담이 줄어들고 있으며, JavaScript의 모든 기능을 활용할 수 있어 유연한 스타일링이 가능하다.
2. 런타임에서 CSS in JS가 더 뛰어난 순간이 있다.
- 런타임에 className이 추가되어야 할 경우 emotion은 css를 잘못 사용한 것보다 훨씬 빠르다.
- 각 서비스에서 프로파일러를 돌려보면서 emotion이 더 적절한 경우가 있는지 파악하며 개발하는 것이 중요하다.
토론을 들으면서 벤치마크 테스트나 런타임 오버헤드 등 그냥 CSS 라이브러리를 사용할 때는 몰랐던 내용들이 많이 있었다.
그만큼 내가 경험이 부족한 것도 있고 신경을 안 썼던 것 같기도 해서 조금 반성하는 계기가 되었다.
토론이 끝나고 난 뒤에 관련해서 이것저것 알아보면서 사람들이 퍼포먼스 테스트도 하고 프로덕트에 맞는 CSS 라이브러리를 찾기 위해 많은 노력을 하고 있구나라는 생각이 들었다.
내 생각을 조금 얘기해보자면,결국 개발 역사의 흐름대로 본다면 두 방식 모두 나온 이유가 있을 것이고 어느 하나가 잘못되었다고 말하기 힘들지만, 그때마다 상황에 맞는 기술을 쓰는 것이 중요하다는 생각이다.
또, 훌륭한 DX만으로도 CSS in JS는 사용될 많은 이유를 가지고 있다고 생각하고 팀원이 모두가 똑똑하다면 사실 CSS-in-JS나 심지어는 React도 쓸 필요가 없으니 배척하는 것은 좋지 못한 것 같다.
모든 기술은 성능도 중요하지만 개발자의 실수를 잘 막아주느냐, 생산성을 높여주느냐도 정말 중요하다고 생각한다.
나는 요즘 사이드 프로젝트에서 Next 14 + styled-component 조합을 쓰고 있긴 한데.. 왜 Next에서 TailwindCSS를 권장하는지 알 것 같고 SSR에서 CSS in JS 방식이 잘 맞지 않다는 것을 느끼는 중이다.
CSS in JS의 가장 큰 장점이 조건부 렌더링이라고 생각하는데, SSR과 함께 쓰려고 하면 SSR이 가져다주는 장점이 조금 상쇄되는 느낌이다.
특히, app-router에서 styled-component를 사용하려면 styled.ts 파일마다 'use-client'를 붙여야 하는데, 불필요한 js 번들 파일이 늘어나는 느낌이 들어서 기분이 묘하다. 굳이 클라이언트로 안 넘어 가도될 컴포넌트를 넘기는 느낌이다.
그래서 다음 프로젝트에서 Next를 쓴다면 아마 CSS 방식의 라이브러리를 써볼 것 같다.
회사에서 Vue나 Nuxt를 쓸 때에는 굳이 CSS나 SCSS 외의 CSS 라이브러리를 쓰지 않았다.
왜냐면 Vue는 SFC(Single File Component) 형태의 템플릿이 존재하다 보니 조건부 렌더링을 굳이 CSS에서 처리할 필요가 없기 때문이다. v-bind를 통해서 css에 script에서 계산된 수치값을 넣을 수 있기도 하고 v-if를 통해서도 제어할 수 있기 때문이다.
아마 내가 Vue의 SSR 프레임워크인 Nuxt를 쓰면서 CSS 적인 문제를 못 느꼈던 부분도 이런 점 때문이었을 것 같다.
또 확실히 SSR 프레임워크들이 떠오르면서 CSS in JS 라이브러리들이 점점 인기가 식고 있는 느낌도 든다.
나는 개인적으로 CSS를 외우고 다니다 보니까 TailwindCSS 같이 따로 정의된 방식을 별로 좋아하진 않는다. 이전에 PHP+부트스트랩으로 개발을 할 때도 외우는데 오래 걸리진 않았지만 확실히 문서를 보고 개발을 해야 한다는 불편함이 초반엔 크게 느껴졌다.
그래서 CSR로 작업하지 않는 이상은 앞으로 CSS 방식을 쓸 것 같다.
Round 3: pnpm vs yarn
마지막 라운드의 주제는 패키지 매니저였다.
사실 나는 패키지 매니저를 npm과 yarn classic 밖에 안 써봐서 해당 주제를 이해하기에 이해도가 많이 부족했다.
유령 호이스팅 문제나 최신 패키지 매니저보다 성능이 떨어진다는 것은 알고 있었는데, 사용하기에 yarn이 크게 불편하지 않았고 문제를 일으킨 적이 딱히 없어서 고정적으로 사용하고 있었던 것 같다.
패널들의 입장을 간단히 요약하자면 다음과 같았다. (아래 더보기)
홍팀 (pnpm)
1. yarn은 호환성 문제를 일으킬 수도 있다.
- yarn berry는 npm을 대체하기 위해 새로운 패러다임을 도입했다. 다만 일부 제약들이 따른다.
- 2020년 Vercel에서는 'Turbopack'이라는 번들러를 만들었는데, yarn berry에서 지원하게 수정할 생각이 없다고 못 박아 버렸다. 만약 yarn을 사용해서 개발을 하다가 이런 상황을 만나면 난감할 것이다.
2. yarn PnP의 Zip 파일 형식은 확인이 힘들다.
- yarn PnP는 패키지를 각각의 zip 파일로 저장하여 무결성을 보장하고 수정 여부를 쉽게 알 수 있게 한다.
하지만, zip 파일은 압축된 형태이기 때문에 내용을 직접 보거나 수정하기 어렵다.
- pnpm은 'Content-addressable store'를 사용하여 패키지를 관리해서 파일 시스템에서 직접 패키지 내용을 볼 수 있어 직관적이다.
청팀 (yarn)
1. pnpm도 결국 npm이다.
- pnpm으로 설치된 패키지도 실제로는 npm이 관리하는 node_modules 규격을 따른다.
2. yarn은 기존의 문제점들을 잘 수정하여 설계했다.
- 전통적 의미로 본다면 근본이 아닌 건 맞지만, 근본이 잘못되었다면 바로 잡을 필요가 있다.
- yarn은 npm이 가지고 있었던 문제점들 잘 수정해서 좋은 변화를 만들었다.
3. 커뮤니티에서 자주 사용되는 라이브러리의 경우 yarn을 통해서도 관리가 가능하다.
토론을 들으면서 내가 너무 패키지 매니저에 대해서 무지했나 라는 생각이 많이 들었다.
실제로 홍팀에서 제시한 turbo pack 이슈 때문에 pnpm을 사용하시고 계시기도 한 걸 보면서 꽤나 심각한 일이었구나 라는 생각도 들었고 또 yarn classic은 지원도 멈췄고 성능이나 호환성 문제가 있다는 것을 찾아보면서 알게 되었다.
내가 계속 사용하고 있는 기술에 익숙해져서 그것만 사용하지 말고 새로운 소식들을 접하고 알아보고 시도해 보는 것이 정말 필요하구나 라는 생각이 들었다.
후기
더 나은 개발자가 되고 싶고 더 좋은 프로덕트를 만들고 싶지만, 이렇게 정보를 알아보고 기여하고 반영하고 시행착오를 겪는 과정이 정말 힘들다는 것을 인턴을 하면서 느끼는 것 같다. 사람이 바쁘다 보면 현실에 점점 안주하게 되는 것 같다.
그런 점에서 프파클의 토론회를 보면서 저분들도 정말 바쁘실 텐데 많은 것들을 알아보고 지식을 나누고 하시는 게 정말 대단해 보이고 일에 대한 애정이 느껴지는 것 같았다.
앞으로 이런 행사에 자주 참여해서 스스로의 식견을 넓혀야겠다는 생각이 많이 들었다.
개발을 하다 보니 가끔 무지에서 오는 두려움이 있다. 크게 어려운 일이 아님에도 내가 잘 모르기 때문에 방어적인 입장을 취하게 되는 순간들이 있었다.
프파클을 듣기만 했음에도 정말 알아가는 것들이 많았고 앞으로 프로젝트를 진행할 때 고려해야 할 것 같은 점이나 생각해 볼 점 등등 새로운 식견이 생긴 것 같아 좋았다.
다음번에도 열린다면 꼭 참석하고 싶은 행사였다.
'취미 > 강연' 카테고리의 다른 글
| [강연] 예비 창업자들에게 들려주고 싶은 광고 이야기 (0) | 2023.10.16 |
|---|---|
| 가장 최근에 한 프로젝트를 글로 써주세요. (0) | 2023.08.22 |
| [릴레이 토크콘서트] 한명수 CCO의 미래를 여는 창의성과 기업정신과 ME (1) | 2022.11.28 |
| [릴레이 토크콘서트] 타일러 라쉬가 들려주는 꿈과 진로에 대한 이야기 (0) | 2022.09.26 |