[후기] 프론트엔드 파이트 클럽 온라인 참관 후기

0. 들어가며

토스에서 진행하는 오프라인 커뮤니티인 '프론트엔드 다이빙 클럽'에서 온라인 세션 '프론트엔드 파이트 클럽'을 개최하였다.

꽤 재밌는 쟁점을 가지고 개발자들이 토론을 가졌는데, 내용이 흥미로워 공유해본다.

1. 뛰어난 문제 해결사 동료 vs 커뮤니케이션 친절한 동료

생각보다 너무 극단적인 상황을 가정하여 밸런스 게임의 느낌으로 흘러가버려 조금 아쉬웠다.

아예 일을 못하는데 입만 산 사람 vs 사회성 결여된 문제 해결 머신 구도로...

같은 이야기를 리더급의 시니어 개발자분들이 풀어주셨으면 어땠을까 한다.

개인적 의견

반대의 능력치(문제해결능력/커뮤니케이션)가 평균이라는 가정하에 '매우 뛰어난 커뮤니케이션 능력자'를 선호한다.

결국은 회사라는 사회에서 가장 중요한건 '커뮤니케이션 능력'이라고 생각한다.

지나온 프로젝트들을 되돌아봤을 때, 결국 일정이 밀리고 잡음을 만들던건 커뮤니케이션의 부재였다.

그리고.. 뛰어난 문제 해결사는 내가 되면 되니까..!!

2. CSS vs CSS-in-JS

홍팀 의견

CSS-in-JS는 생태계에서 환영받지 못한다.

• Chakra UI는 CSS-in-JS 방식을 사용하지만, 성능 저하에 대해 인지하고 있다.
• React 팀은 useInsertionEffect를 통해 CSS-in-JS 스타일을 런타임에 주입할 수 있도록 했지만, 이를 사용할 때 몇 가지 문제가 발생할 수 있다고 언급한 바 있다.
• SSR 환경에서는 CSS-in-JS를 사용하는데 제약 사항이 존재한다.
• emotion docs에서는 순수 CSS 방식보다 실제로 6배 정도의 시간이 더 소요되는 것을 보여준다.

청팀 의견

CSS-in-JS는 생각보다 느리지 않다.

• React의 useInsertionEffect가 생겨난 것 같이 CSS-in-JS 시장은 점점 커지고 있다.
• 리액트가 해결하고자 하는 문제는 성능보다도 개발자의 편의성이다. CSS-in-JS 또한 마찬가지로, 단순히 성능만을 기준으로 비교하기보다는 각각이 해결하고자 하는 문제가 다르다는 점을 인식해야 한다.
• 실제로 emotion과 같은 CSS-in-JS 방식의 라이브러리들이 생각만큼 느리지 않다.

개인적 의견

사실 두 방식 모두 각각의 필요에 따라 적절하게 사용하는 것이 중요하다고 생각한다. 하지만 굳이 하나를 꼽자면 CSS-in-JS를 고르겠다.

청팀 패널이 말한 "React가 해결하려는 문제는 성능이 아니라 편의성이다"라는 점에 공감한다. CSS-in-JS가 해결하고자 하는 문제 또한 성능이 아닌 편의성이기 때문에, 스타일링 시 다양한 기능과 유연성을 제공한다는 점에서 큰 장점이 있다.

이러한 이유로 나도 주로 styled-components를 사용해 편리하게 동적 스타일링을 구현하고 있기 때문에, 아무래도 청팀의 의견에 손을 들 수 밖에 없었다.

이와 별개로 SCSS/SASS도 좀 공부해봐야겠다.

3. pnpm vs yarn

홍팀 의견

• yarn에는 제약사항이 존재한다. (ex: Vercel사의 Turbopack)
• yarn pnp는 패키지를 zip 파일로 관리하기 때문에 내용을 확인하기 어렵다.
• yarn이 빠른 것은 인정. 모든 패키지를 지원해주고 안정성이 갖춰지면 넘어갈 의향이 있다.

청팀 의견

• pnpm은 결국 npm일 뿐이다. (npm의 잘못된 설계를 고친 것은 아님)
• 근본이 잘못되었으면 파괴적 혁신이 필요하다.
• 패키지가 지원을 안해주면 직접 고쳐나가면 된다.

개인적 의견

며칠 전 팀원들과 npm과 yarn의 차이에 대해 이야기를 나눴다. yarn이 npm에 비해 모든 면에서 월등히 낫다면 왜 모든 프로젝트가 yarn으로 대체되지 않았을까? 우리는 '레거시'라는 이름으로 npm을 쉽게 걷어내지 못하고 그 위에서 계속 작업을 이어가고 있는 것이 아닐까라는 결론을 내렸다.

이처럼 레거시로 인해 잘못된 설계를 계속 쌓아가다 보면, 결국 이는 기술 부채로 남아 비합리성을 유발하게 된다. 이럴 때일수록 우리가 가져야 할 자세는 바로 '파괴적 혁신'을 통해 기존의 틀을 깨고 더 나은 방향으로 나아가는 것이라고 생각한다.

4. 마치며

완벽한 도구는 없다. 상황에 따라서, 그리고 해결하고자 하는 문제에 따라 더 나은 도구만이 있을 뿐이다.

하나의 기술에 매몰되어 좁은 시야를 가진 개발자가 아닌, 넓은 시야로 도구를 활용할 수 있는 '문제 해결사'가 될 수 있도록 노력해야겠다.