프론트엔드 개발 2년 느낀점
시장의 양극화, 기대하는 역할의 괴리
(깊지는 않지만) JSP나 JQuery에서부터 지금의 모던한 프론트 엔드 스택까지 경험한 내가 지켜본 우리나라 프론트엔드 세상은 양극화가 심한 것 같다.
프론트엔드 라는 용어가 흔해진 지금의 형태가 정립된 지 그리 오래되지 않기도 했고 짧은 시간 동안 너무나 많은 변화가 있어서 그렇지 않을까 생각한다. (앞으로 어떻게 변화할지는 모르겠지만….)
유저가 보고 동작하는 페이지를 개발하는 역할은 같으나. 지금 이 순간도 누구는 es5 이전 문법과 JQuery로 개발하고, 누구는 모던하고 멋진 최신의 핫한 기술들을 쓰고 있는 게 참 재미있다. 모던한 스택과 최신 기술들이 무조건 좋은 것은 아니지만, 문제는 그 중간에 보이지 않는 벽이 있어서 점프업 하기가 쉽지 않다.
구인, 구직 시장도 마찬가지다. 역량, 실력을 줄 세울 수는 없겠지만 굳이 따지자면 제대로 하거나, 못하거나 두 그룹 밖에 없는 것 같고 그마저도 제대로 하는 개발자는 속된 말로 천상계라고 하는 회사에서 다 데려가다 보니 모든 회사가 (쓸만한) 개발자가 없다고 하는 상황이다. 다른 파트도 그렇겠지만 현재로선 프론트엔드가 가장 심하지 않나 싶다.
더 큰 문제는 프론트엔드 생태계를 잘 이해하고 이끌어 줄 수 있는 시니어급 혹은 리드 급이나 C레벨도 없다는 거다. 그런 분들은 아랫마을로 내려오지도 않을뿐더러 아랫마을에서는 그런 분이 필요하다는 사실조차 인지하지 못한다. 한 명은 계속 뒤로 걷고 한 명은 계속 앞으로 걸어서 중간이 없다랄까? 이런 분위기라면 잘하는 개발자가 모여있는 집단과 아닌 집단의 기술 격차와 서비스 퀄리티의 격차는 점점 벌어질 것 같다.
이건 현재의 멋진 주니어 개발자들이 힘을 합쳐 으쌰으쌰해서 어느 레벨 이상의 층이 형성되어야지 해결될 문제가 아닐까 조심스레 혼자 생각해보았다.
대충하기엔 쉽고 제대로 하기엔 절대 쉽지 않다.
CS 지식도 별로 필요 없고 대충 화면만 그리는 게 무슨 개발자냐 프로트엔드 개발자는 개발자가 아니라는 사람도 보았고, 디자인에는 소질이 없고 그런 쉬운 것 보다는 진짜 개발자가 하고 싶어서 백엔드 개발자를 하고 싶다 라는 개발자 지망생도 보았다.
내가 전에 일했던 회사도 겉으로 그런 말 하는 사람은 없었지만 프론트엔드 개발자는 엔지니어기보다는 오히려 디자이너나 마크업을 하는 사람이라는 인식과 분위기가 어느 정도 있었다. (UI개발자 혹은 퍼블리셔 라고 불리기도 했음) 물론 도메인의 영향도 있었겠지만 프론트엔드의 중요도가 낮다고 생각하는 사람들을 종종 보았다.
오히려 이런 분위기는 업력이 어느 정도 있는 회사와 웹 개발을 어느 정도 오래 하신 시니어가 많은 곳에 존재한다. 회사가 기대하는 역할이 마크업과 약간의 데이터 바인딩 정도라면 사실 할 말은 없을 것도 같다. 나도 아주 약간이나마 백엔드, 프론트엔드로 불리지 않고 웹 개발자로 불리며 서버도 만들고 템플릿 엔진과 스크립트로 페이지를 만들던 시절을 경험했기 때문에 어느 정도 이해한다.
공감은 하지만 동감은 하기 힘들다.
적어도 이제는 그런 인식과 생각은 큰 오산이 아닐까 생각한다. 프론트엔드 엔지니어라면 마크업은 수많은 롤 중 일부이다.
브라우저와 엔진, 네트워크, DB, 아키텍쳐, 디자인 패턴, 언어, 성능을 위한 알고리즘, 특정 기술을 사용하기 위한 지식에서부터 브라우저가 어떻게 요소들의 지오메트리를 계산하고 그려내는지에 대한 시스템, 플로우, 모델들과 CSS 스펙들, 접근성, UI/UX 지식(with 심리학), 디자인 지식 등등
하나도 제대로 하기 힘든 것들이 수십 개가 기다리고 있다. 과연 이 모든 것들을 전부 깊게 이해하고 알고 있는 사람이 존재는 할까라는 생각이 들정도로 공부하고 알아야 할 것들이 수도 없이 많다. 결코 만만치 않다.변화가 정말 빠르다
프론트엔드의 특징 중 하나는 변화가 너무 빠르다는 거다. 몇 년 전만 해도 "SPA? 우와 좋다~" 했던 것이 무색하게 "흠.. SPA는 아무래도 좀 아닌 거 같아 SSR? SSG? 하이브리드? 찍어내!!", "데이터 fetching을 우아하게~ Stale-while-revalidation 전략!!", "비동기시 랜더링도 우아하게! Suspense!!!", "에러는?? Error Boundary!!!"
리액트 진형에서의 상태관리를 예를 들자면 2년 전만 해도
Redux, Thunk, Saga 같은 것들이 공식처럼 사용되었고 영원할 것 같았다. (개인적으로 처음에는 그런 verbose한 보일러플레이트가 뭔가 탄탄하고 멋져 보이기도 했었다) 현재는 환경에 따라 다르고 장단이 있겠지만 Mobx, Recoil, jotai, Redux Toolkit, (성격은 조금 다르지만)Apollo Client 등 선택지가 많아졌고 지금 새로운 프로젝트를 한다면 개인적으로는 꼭 필요한 것이 아니라면 Redux를 쓰진 않을 것 같다.스타일과 디자인 쪽은 또 어떤가?
Sass, Less, Stylus 같은 전처리기와 Css-in-css 그리고 Styled Component, Emotion 과 같은 Css-in-js 가 엎치락뒤치락 하고 UI프레임워크와 라이브러리도 최근에는 Utility First인 Tailwind와 스타일과 컴포넌트의 비즈니스 로직의 관심사를 분리한 Headless UI도 주목받는다.오늘 정답처럼 보이던 것이 내일은 잘못된 선택이었나? 하는 기분이 들 때도 있다.
이렇듯 빠르게 변화하는 프론트엔드에서는 빠르게 학습하고 올바르게 적용하는 것이 중요한 덕목 인 것 같다. 또 많은 경험을 해보아야지 지금 내 환경에 가장 적합한 환경을 구성하는 데 도움이 될 것 같다. 그러기 위해서는
기초와 기본을 튼튼히 하는 것이 가장 중요한 것 같다.주니어의 고민
신입때는 단순히 원하는 데이터로 원하는 화면을 렌더링 하는게 목표 였다면 이제는 조금 더 욕심과 고민이 생긴다.
- 어떻게 성능을 최적화 할까?
- 무엇을 최적화 할것인가? 리소스의 용량을 최적화 할것인가, 메모리를 최적화 할것인가, 알고리즘을 최적화 하고 불필요한 연산과 렌더링을 막아 성능을 최적화 할것인가 등등
- 어느정도 리소스를 최적화에 투자해야 할까? 투자한 리소스 대비 가치 즉 최적화에 대한 ROI에 대해 고민
- 일단은 기본적인 최소한의 최적화에서부터 필요에 의해 단계적으로 최적화해 나아가는것이 올바른 방법일까?
- 어떻게 멋지고 편리한 유저 경험과 접근성을 제공할까?
- 입력 사용성, 접근성
- 일관된 사용자 경험
- 디자인시스템, 반응형
- 시각적 요소, 인터렉션
- 유저가 체감되는 성능 향상
- 어떻게 하면 탄탄한 환경과 믿을 수 있는 코드를 만들까?
- 언제나 시작은 그럴싸. TDD. Jest, Storybook, Cypress 등
- 답정너 일정에 치이면서 패턴이 깨지고 겉잡을수 없게됨
- 무엇을, 어떻게, 얼마나 테스트할것인가? 테스팅 전략
- 유틸이나 비즈니스 로직의 경우 테스트하기 용이하지만 단순한 스태틱 컴포넌트는?
- Static Test, Unit Test, Integration Test, E2E Test, 시각적 회귀 테스트
- 트레이드 오프, ROI
- 어떻게 하면 더 유지보수가 편하고 유연한 코드를 작성할까?
- 어떻게 하면 더 빠르고 편리하게 코드를 생산할 수 있게 설계할까?
- micro frontend, module federation
- 등등