(2023.11.xx 기준)
“(내가 CSS가 부족하니) 퍼블리셔를 고용 요청”
떠오르는건 개발 실력이 부족해서 생긴 일이었다. 나는 평생 직장을 다니고 싶었고, 그 당시 1년차 잡부 개발자에서 프론트엔드로 첫 이직을 하게 되었고, 프론트엔드 리드 역할까지 쥐고 있었다. 그때 React가 부족해서 계속 React를 공부하면서 회사에 틀에 끼워맞춰 보고 있었다. 3~4개월이 지나 느낀 건 프론트엔드 현업에서 CSS는 어느정도 기본으로 이해하고 있어야 했지만, JS와 React 만 조금 밖에 몰랐던 나는 CSS를 못하는 변명을 대기 시작하였다. 그리고 퍼블리셔를 뽑아달라고 회사 요구 했고, 회사는 퍼블리셔 채용 공고를 내었다.
“모던한 프론트엔드”
퍼블리셔 면접에서 면접관으로 들어가 면접을 보는데, 퍼블리셔 분은 일하게 되었을 때, “프론트엔드가 어떻게 일하는지 보게 해달라”고 요청을 하였다. 그 퍼블리셔는 CSS도 잘했지만, 프론트엔드적으로 나보다 모던한 프론트엔드에 가까웠다. 퍼블리셔는 퍼블리싱을 넘어 제품 제작에 참여까지 하여 프론트엔드로 직무가 전환되었고, 모던한 프론트엔드 스펙을 갖추기 위해 많은 기여를 해주었다. 그러면서 내가 회사에서 기여하고 노력했던 시간들은 인정해주는 사람이 없었다. 그리고 직무 전환했던 프론트엔드분은 나에게 연차도 높은데 배울 점이 없다는 것을 알고 대화 조차 하지 않았다.
내가 물경력인 것은 알겠지만 어떻게 나아가야 하는지 몰랐다. 그래서 그 프론트엔드 분이 하는 이야기에 최대한 참여하려고 했고, 무엇을 배우고 공부하는지 알아내면서 같은 발자취를 쫒고자 노력하며 방향을 잡는데 큰 도움이 되었다. 회사가 어려워지고 권고사직 시즌이 왔을 때, 그 프론트엔드 분은 자진해서 성장할 수 있는 곳으로 이동하였고, 나는 실력이 부족함을 느끼고 그 분의 발자취를 따라 멘토링까지 받게 되었다.
“문제를 마주하는 인식의 변화”
멘토링을 받기 전까진 제대로 프론트엔드에 대해 공부를 해본 적이 없다보니, 새롭게 생기는 피쳐와 요구사항 그리고 생기는 버그에 대해 두려움이 있었다. 그러나 그 멘토링을 받으면서 기술에 대한 이해가 싶어지고, 요구사항이 무엇을 해결하고 싶은 것인지 파고들어서 어떤 문제가 있는지 머리에 그려지기 시작했다. 어느덧, 문제들을 마주하고 있다.
제대로 개발을 공부한지는 1년이 되지 않았지만, 내가 지금까지 만들었던 것들의 문제들을 마주보게 되면서 더 많은 것들을 고쳐보고 모던한 프론트엔드에 가까워지고자 노력할 수 있었다. 기존 Lighthouse 성능이 2~30점이면서 개선의 욕구가 거의 없었던 프로덕트도 성능이 99점이 될 수 있는 방법에 대해서 끊임없이 갈구 했던 것처럼 지연로딩과 코드 분할을 어떻게 동작하게 할지, 이미지를 모두 지연로딩 하는 것이 옳은지 등 공부하면서 알게 되는 것들이 많아졌다.
“모노레포의 필요성”
프론트엔드가 2명 뿐임에도 불구하고 회사 프론트엔드 스펙에 모노레포의 필요성을 느꼈다. 2년간 새 프로덕트만 8개 정도 했는데 디자인이 모두 달랐다. 디자이너는 UI/UX의 전문가이니 의견을 존중했다. 존중할수록 프론트엔드는 만들어야 하는 디자인 시스템이 계속 늘어났다. 문제는 프로덕트마다 UI가 다르고, 일부는 동작 방식이 달랐다. 새 프로젝트를 할 때마다 복사해서 더 좋은 기능을 추가해서 넣어도 이전 프로덕트들은 반영되지 않았다. 기타 유틸리티 파일, config 또한 그러하였다. 한번 도입하면 바꾸기 힘들 것이라 생각하여 가장 최신의 모노레포인 Turborepo를 추가하였다.
터보레포를 집에서 만들어 볼 땐 잘 동작했지만, 회사에서 사용하려고 하니 config와 새 프로젝트를 추가하는 것에 어려움을 느꼈다. 당시, 터보레포 예제 파일을 받고 실행만 시켜도 돌아가지 않던 때였다. 멀티레포로 있던 프로덕트를 모노레포 병합하는 일에서 최근 프로덕트는 esm으로 동작하기 때문에 tsconfig의 불일치를 해결하는 것과 Setting 관련해서 통합하는데 2주 정도 시간을 투자하여서 터보레포를 통해 프로덕트를 구현하였다. 그 이후 본론으로 돌아와 디자인 시스템을 만들기 시작하였다.
“결합형 프로덕트 디자인 시스템”
headless 여도 모든 프로덕트를 만족시킬 수 없었고, 만약 모두를 만족할 경우 ui component가 비대해지면서 어떤 동작의 의도로 만들어진지를 잊어버리게 되는 경우가 생겼다. 그리하여 가장 작은 의도로 개별로 만들어진 ui 패키지에서 프로덕트에 사용할 UI들을 가져오기 때문에 light하게 구성하고, 디자이너분께서 만들어주신 디자인 시스템을 덧 입혀서 가벼운 프로덕트 디자인 시스템을 구축하였다.
이로써, headless UI의 기능이 업데이트나 리팩토링이 간편해지고, 지금까지 만들었던 모든 ui component를 가져오는 것이 아니기 때문에 light하며 tailwindcss 기반으로 만들어 SRC에도 사용가능하다. 단점이 있다면, tailwindcss에 의존적인 것은 확장에 한정적이다. 대안으로 Vanilla Extract를 통해 SRC에도 안정적이고 확장의 자유도가 높게 구성할 수 있다. 그리고 지금 바로 적용할 수 있다.
그 이유는 headless는 디자인이 포함되어 있지 않기 때문에 프로덕트의 디자인은 독립적이다. 그리하여 전체적인 디자인을 수정한다면 공수가 높겠지만, 일부 프로적트에 구현하기 좋은 구조라고 생각이 들었다. 결합형 프로덕트 디자인 시스템을 구축하는 것이 프로덕트가 자주 생기고, 바뀌는 스타트업에 가장 적합한 디자인 시스템이라는 생각이 들어 2년 간 프론트엔드로 일하면서 가졌던 문제를 어느정도 해소할 수 있어서 총체적으로 보았을 때, 가장 고민을 많이하고 현재도 진행 중인 경험이다.