toss 프론트엔드 파이트 클럽 참여

이번주 토스 프론트엔드 파이트클럽(프파클) Round4에 초대를 받아 참여하게 됐습니다.
해당 행사는 지난 프파클 행사의 스핀오프 행사로 토스 오피스에서 오프라인으로 진행이 됐습니다.

프파클은 프론트엔드 개발자라면 누구나 한번쯤 고민해봤을 법한 주제를 밸런스게임처럼 비교하며 패널과 참여자들이 토론하는 이벤트입니다. 앞선 Round1,2,3은 온라인으로 참관했었는데, 참관하면서도 청vs홍 코너의 주장과 근거들을 들으며 나라면 어떤 것을 선택할까 몰입하며 들었던 기억이 납니다.

인상적이었던 것은 Round2에서 pure css와 css-in-js 어떤 것을 선택할 것인가 부분이었는데, 최근 회사에서도 런타임css -> 빌드타임css로 마이그레이션하는 중이기도 했고, 제가 개발을 하기 전부터도 오랜시간 많은 개발자들이 css와 스타일링 기술에 여러가지 패러다임을 만들어 가고 있는 것에 흥미가 있었기 때문입니다.

더 자세한 내용은 별도의 포스트로 다뤄보기로 하고 기억에 남는 짧은 후기로는 스타일링 기술을 선택할 때 주로 고려하는 사항이

• 런타임 오버헤드 (렌더링 성능)
• DX - developer experience (파일 관리, 중복 classname, 컨벤션 등)
  이라는 것입니다.

보통 css-in-js가 런타임 오버헤드가 발생할 수 있다고 하는데, 패널분이 가져오신 벤치마크 비교를 보면 pure css로 classname을 런타임에 추가해야하는 경우 css를 잘못 사용한 것보다 대표적인 css-in-js 라이브러리인 emotion가 훨씬 빠를 수 있다는 것을 볼 수 있었습니다. 결국에는 실제로 오버헤드가 생기는 스타일링 구간을 프로파일러로 분석해보면서 최적화해나가는게 중요하다는 이야기입니다.

게다가 css-in-js를 선택할만한 이유로 좋은 DX를 꼽을 수도 있습니다. 성능도 분명 중요하지만, 코드를 작성하는 개발자의 생산성, 관리와 유지보수 측면도 성능만큼이나 중요한 부분입니다. 모든 기술 선택에는 트레이드오프가 있으니까요.

Round3의 주제인 패키지 매니저 비교도 인상적이었습니다. 저는 그동안 사실 패키지 매니저들의 차이에 대해서 자세히 관심을 가지지 못했었는데, npm과 yarn이 node_modules과 zip을 기반으로 파일들을 다루는데에 차이가 있다는 것을 새로 알게 되었습니다. pnpm이 npm의 어떤 문제를 해결하기 위해 생겨났는지도 알게 됐습니다. 프로젝트별로 매번 node_modules를 설치하게 되는 npm과 달리 글로벌하게 한번만 설치해서 패키지 중복 설치를 방지하고 저장공간을 효율적으로 쓸수 있는 장점을 가져서 performative npm이라는 이름을 가지게 되었다고 하네요. rush도 pnpm을 사용하는 모노레포 관리 도구인데, 이후에 다른 포스트로 또 다뤄볼 기회가 있을 것 같습니다.

Round4에서는 토스 임용빈님, 박건영님과 저를 포함한 프론트엔드 개발자 4명이 모여서 당일 공개되는 주제를 바탕으로 청vs홍 코너를 선택해 토론했습니다. 주제는 워딩은 정확하지 않지만 대략 아래와 같았습니다.

1. 주니어 개발자에게 사수가 있는게 좋다 vs 사수가 없는게 좋다
2. 힙하고 새로운 스택 도입 vs 인기많고 검증된 스택 도입
3. 회사는 3년 이상은 다니는게 좋다 vs 3년 이하로 다니고 이직하는게 좋다
4. 요즘 관심 있는 기술 자유 토론
   1. 프론트엔드과 백엔드가 점차 통합되지 않을지
   2. 프론트엔드 개발자로서 좋은 코드를 작성하는 방법
   3. 가독성이 매우 좋지만 버그가 있는 코드 vs 아무도 읽을 수 없지만 버그가 하나도 없는 코드
   4. AI시대에 프론트엔드 개발자란?
   5. 새로운 기술을 도입할 때의 기준이 있다면?
   6. 팀에서 기술적으로 보완하고자 할때 팀원들을 설득하거나 비개발 직군 팀원들에게 설명하는 방법

1 .
저는 주니어 개발자에게 사수가 있는게 좋다를 선택했습니다.
주니어일 때는 뭘 모르는지조차 모르기 때문에 빠르게 학습하고 기반을 다지려면 팀원이든 사수이든 함께 해줄 사람이 필요하다고 생각합니다. 혼자서 방법을 찾지 못하는 시간이 많아지면 자신감도 떨어지고 안좋은 길로 빠질때 구해줄 사람이 없기 때문이죠. 개발자라면 혼자서 문제 해결을 척척 해내야하는 것 아니냐고 할 수 있지만 그것도 문제가 뭔지 실마리라도 찾을 수 있는 정도에 진입하고 나서의 일이라고 생각하는 편입니다. 사수가 없다면 커뮤니티나 ai를 활용할 수도 있지만요. 경험상 함께 모니터를 보며 팀원분들과 문제를 해결해낼 때 훨씬 더 기억에 남았던 것 같습니다. 사수에게 어떤 문제에 봉착했고, 어떻게 해결하고 싶으며, 어떤 방식이 있을지 도움을 요청하는 것만으로도 자신의 상황을 객관적으로 바라볼 수 있게 되고요.

2 .
저는 회사의 프로덕션 레벨이라면 인기 많고 검증된 스택을 선택하겠습니다.
모든 기술은 기술만으로 존재할 수 없고, 실제 프로덕트를 위해서 사용되는 도구라고 생각합니다. 아무리 좋은 기술이라도 목적이 없다면 도입하는 이유가 없겠죠. 그러나 토론을 하다보니 마음이 좀 바뀌기도 했네요. 새로운 스택 도입을 선택하겠다고 하신 참여자분은 충분히 설득력있고 필요한 기술이라면 검증되지 않았더라도 감수하고 도입할 수 있다. 그리고 내가 책임질 수 있는 선택이라면 못할 것이 없다고 하셨는데요, 그렇게 말씀하신 분의 자신감에 좀 놀라기도 했고, 프로덕트에 필요하고 해결해야할 문제를 해결해줄 수 있는 기술이라면 계속 발전하는 기술 생태계에서 빠르게 새로운 기술을 선택하는 결단력도 필요하다는 생각으로 기울어지기도 했습니다.

3 .
회사는 3년 이상 다녀야 좋다를 선택했습니다.
실제로 현 회사를 만 3년째 다니고 있네요.. 되돌아보니 첫 1년은 모르는게 너무 많아서 혼자서 처음부터 끝까지 프로젝트를 주도적으로 핸들링하지는 못했던 것 같습니다. 대부분 사수나 팀원들의 도움을 받으며 진행했고, 새로운 방향으로 프로젝트를 이끌어 나가기에도 좀 부족했습니다. 좀 시간이 지나서 도메인이나 내부 운영, 정책들을 숲의 관점으로 볼 수 있게 되고, 컨텍스트가 필요 없는 작은 단위의 피쳐만 만드는 것에서 나아가 좀 더 앞을 내다보고 그에 필요한 기술적인 결정과 설계도 시도해볼 수 있게 됐습니다. 그리고 새로운 코드를 작성하고 끝이아니라 내가 쓴 코드, 팀원들이 쓴 코드, 레거시 코드를 유지 보수하고 확장해나가는 경험은 3년 이하의 시간으로는 턱없이 부족한 시간이라는 생각이 듭니다. 현 회사에서 운좋게 초기 리뉴얼 프로젝트 멤버로 합류하고 난 뒤 현재까지 빌드업해가는 과정에 기여할 수 있어서 많은 인사이트를 얻을 수 있었다고 생각합니다. 다른 분들은 현실적으로 이직을 해야 연봉 및 처우가 개선되고, 회사에서 발전기회가 적다면 정체되지 않고 빠르게 원하는 회사에 가서 목표를 달성하는게 좋다. 3년 이상 오래 다니는 것은 매니저나 리드급 레벨에서 선택하는 것이 좋다고 해주시기도 했습니다. 저는 여전히 제 기회는 어디에 있든 제가 만들어 나가는 거라고 생각하고 있습니다.

4 파트는 toss 프론트엔드 파이트 클럽 참여2 로 업데이트 예정