CSS 프레임워크를 직접 개발해보았습니다.

Donghyun Peter Kim·2020년 9월 25일
2
post-thumbnail

들어가기 전에

웹 프론트엔드 개발을 하다보면 CSS 프레임워크는 거의 필수적으로 사용하게 됩니다.

저는 웹 개발할 때 Vue.js를 주로 사용하는데, 그 동안 이것저것 많이 사용해보았지만, 기능적으로나 디자인적으로 Element UI가 괜찮아서 그 동안 10개가 넘는 기업 웹사이트를 이 두 개의 프레임워크를 조합해서 개발했습니다.

하지만 웹은 디자인 트렌드가 너무 빠르게 변하는 산업이라, 이제는 Element의 UI가 모던해보이지 않을 때도 있어서 항상 사용하면서 아쉽다는 생각을 많이하고 있습니다.

그렇다고 조금씩 트렌드에 맞게끔 기존 프레임워크를 커스텀을 하자니 PR을 날리는 건 기존 디자인 시스템을 바꾸기 때문에 어렵고, 매번 프레임워크 위에 커스텀한 css를 프로젝트마다 복붙하기엔 개발자로써 받아들일 수 없었고, 또 원하는 대로 커스텀이 100% 되지 않기도 했습니다.

그럼 나머지 옵션은 "직접 프레임워크를 개발하자" 인데, 그 엄청난 작업을 하기엔 너무나 힘든 일이라는 걸 알고 있기 때문에 시도조차 하지 못했습니다.

Tailwind CSS

개인적으로 프론트엔드를 좋아하기 때문에 디자이너는 아니지만 평소 웹 디자인 공부를 꾸준히 하는 편인데, 재작년 Product Hunt에 이슈가 되었었던 Refactoring UI를 보고 굉장한 인상을 받았고, 모든 무료 강의를 듣고 거의 20만원 가량하는 e-book까지 구매해서 몇 번이나 정독했습니다. (정말 비쌉니다..ㅠ)

e-book에는 좋은 팁들이 많았지만, 가장 좋았던 점은 아무래도 오래된 웹사이트를 실리콘벨리 스타트업 느낌이 나도록 바꾸는 Web Design Refactoring을 하는 동영상 강의였던 것 같습니다. (Youtube에도 무료 강의 몇 편이 공개되어 있으니 관심있는 분들은 꼭 보시길 바랍니다.)

아무튼 SNS을 통해 알게된 사실은, 이 Refactoring UI가 반응이 좋아서, 이 팀이 모던 웹 프레임워크 (React, Vue 등)에서 사용할 수 있는 CSS 유틸리티인 Tailwind CSS를 직접 개발 및 배포 중이었다는 내용이었습니다.

저는 Tailwind를 이제 거의 2-3달 정도 사용했는데 HTML 마크업 하는 속도가 거의 2-3배 이상 빨라졌다고 느낍니다.

기존에는 HTML 태그에 클래스 선언 후 CSS로 가서 스타일링 하는 순서였다면, 클래스에 mx-2 처럼 사전 정의된 클래스를 넣어주기만 하면 바로 적용이 되는 방식입니다. 그리고 잘 설계된 컬러 팔레트도 정말 마음에 들었습니다.

물론 이미 Bootstrap이 오래 전부터 그런 기능을 제공하고 있었지만, 이제는 전혀 트렌디하지 않아보였기 때문에 이 쪽 분야에선 Tailwind가 선두에 있다고 생각합니다.

문제점

제가 사용하면서 느낀 현재 Tailwind의 문제점은 각 모던 웹 프레임워크에 네이티브하게 사용 가능한 UI 컴포넌트가 없다는 점입니다. 아무래도 아직은 작은 팀이다보니 유틸리티에 집중할 수밖에 없는 것 같습니다.

그러다보니 매번 프로젝트를 진행할 때 마다 컴포넌트를 직접 만들어야하는 문제가 있었습니다. 이 부분에선 오히려 Element를 사용할 때 보다 훨씬 속도가 느릴 수 밖에 없었고, 프로젝트 간 재사용성 측면에서도 좋지 않았습니다.

하지만 반대로 제가 직접 무에서 유를 창조할 수 있게 되는 장점이 있었습니다. 결국 전 마지막 옵션인 직접 프레임워크 개발을 선택하게 됩니다.

Force UI

사실 이번 계기로 프레임워크를 직접 만들어야겠다는 생각과 함께, 항상 프론트엔드 마크업을 하면서 매번 반응형 디자인과 UI의 위치를 신경써야 한다는 점이 굉장히 반복적이고 고된 작업이라고 생각했습니다.

아직까지 ElementAnt design은 어떤 컴포넌트를 붙일 때 반응형 디자인까진 고려해주진 않습니다.

그렇다면 이 프레임워크가 잘 설계된 UI/UX에 기반해서 만들어지고, 불필요한 의사 결정을 줄여준다면 애초에 복잡한 커스터마이즈가 필요없지 않을까? 라는 생각을 했습니다.

예를 들어 그림과 같은 Modal 창을 만든다고 할 때, Confirm 버튼을 왼쪽에 둘지 오른쪽에 둘지 고민하지 않는다는 이야기입니다.

하지만 디자이너들과 협업을 하다보면 위와 같은 고민을 자주 하게 됩니다. 큰 관점에서 보면 버튼의 위치는 그리 중요하지 않을 수 있는 부분이지만, 실제로 커뮤니케이션을 할 때 이런 부분들이 쌓여서 굉장히 많은 시간을 잡아먹게됩니다.

만약 이 프레임워크를 많이 사용하게 된다면 모두가 같은 웹사이트 레이아웃을 띄게 되겠지만, 그 부분은 더 힘들겠지만 개발자가 직접 px을 조절하는 게 아닌 레이아웃을 여러가지로 제공하면 된다고 생각합니다.

Force UI는 아직 정식 버전 배포도 아니고, Vue 위에서만 작동하는 작은 프레임워크이고, 또 100% 커스터마이즈 없이 사용할 수는 부분 등 여러 애로사항이 있겠지만 최소한의 커스텀을 하면서도 UI/UX과 시간 측면에서 최대한 많은 이점을 가져갈 수 있도록 개발할 생각입니다.

Github: https://github.com/peterkimzz/force-ui
Live demo: https://force-ui.vercel.app/

profile
웹 개발자입니다.

2개의 댓글

comment-user-thumbnail
2020년 11월 17일

예전에 Vue.js 커뮤니티에서 보고난 후 틈틈히 자주 다시 읽으러 들어옵니다.

제가 만들고자 하는 CSS 프레임워크의 지향점과 작성자분의 지향점이 다른 방향인 듯 하나, 구체화된 경험이 녹아있는 제작 후기이기에 자주 읽게 되는 것 같아요.

틈틈히 다시 읽으면서 올해 안에 저도 완성하고 말리라... 하고 다짐하게 됩니다 :)

좋은 글 감사합니다.

1개의 답글