시작하기 전에..
지난 1월, 대학생 연합 IT 창업 동아리 'SOPT'에서 장기 해커톤(이하 앱잼)을 진행하게 되었습니다. 앱잼은 2주 동안 기획자와 디자이너, 그리고 개발자가 모여 하나의 서비스를 만들어내는 활동으로 저에게 처음으로 협업의 경험을 안겨 주었습니다. 이와 같은 경험을 통해 다른 직무와 소통하는 법을 배우고 다른 직무와 협업할 때 발생하는 문제점 등을 겪을 수 있었습니다. 오늘은 디자이너분들과 협업하는 과정에서 발생한 문제 사항들에 대해 짚어보며 그것들을 조금이나마 개선할 수 있는 방법에 대해서 얘기해 볼까 합니다.
개발을 시작하며..
안타깝게도 저희 팀은 다른 팀 대비 개발자가 2명 정도 부족한 상황이었습니다. 기획자분들이 제안한 뷰의 개수는 총 21개였고 완성을 확신하지 못한 저희는 뷰의 개수를 줄이는 것을 제안하며 기획자분들과 첫 소통이 시작되었습니다. 줄어든 뷰도 부담이 없는 작업량은 아니었습니다. 주어진 시간과 인력으로 최대한의 효율을 뽑아내야 했기에 저희는 아토믹 패턴을 도입하기로 결정했습니다. 뷰 단위의 개발을 하게 된다면 디자인이 나오는 동안 병목이 생길 것이라 생각했기에, 컴포넌트 단위로 디자인을 부탁하며 그것들을 바로바로 분자 단위 컴포넌트로 구성하는 작업을 시작하였습니다. 그렇게 디자이너분들과 첫 소통을 시작하게 되었습니다.
문제 발생
문제는 기획의 변경에서 시작되었습니다. 특정 페이지에 대한 기획이 변경되면 그에 따라 레이아웃도 변경되고 컴포넌트들도 변경되었기 때문입니다. 아토믹 패턴의 특징인 재사용성을 높이기 위해 디자이너들에게 최대한 컴포넌트와 레이아웃을 통일시켜달라는 요청을 한 상황이었기에, 디자인 수정은 해당 컴포넌트를 사용하는 많은 부분에서 변화를 요구했습니다. 매번 특정 뷰에서만 독립적으로 작동하는 로직을 추가하던지, 새로운 컴포넌트를 만들던지 고민하는 일에 부딪혔고 전자는 prop drilling이 깊어지고 후자는 점점 더 시맨틱해지지 않는 이름을 갖게 되는 등 다양한 문제점이 발생하게 되었습니다. 또한 개발자들끼리 인지하는 분자나 유기체 단위도 조금씩 차이가 있어 이것을 통합하는 과정도 일종의 trade off로 여겨졌습니다. 우여곡절 끝에 서비스는 완성하였지만 퍼블리싱에 너무 많은 시간을 쓰게 된 나머지 기능의 퀄리티에 몰두하지 못한 듯한 찝찝함이 남았습니다.
문제 해결
아토믹 패턴의 미숙함을 차치하고서라도 왜 이렇게 마크업에 시간이 많이 들었을까? 고민해본 결과
- 디자인 레이아웃이 변경되면 HTML 구조를 다시 짜야한다.
- 목적이 애매한 CSS의 이름을 고민한다.(ex. buttons-wrapper, banner-inner-wrapper)
- styled-components(css-in-js)를 사용하다보니 매 컴포넌트마다 중복되는 CSS를 적용해줘야 한다.
와 같은 이유들이 떠올랐습니다. 협업 중 저와 같은 고민에 닿은 사람이 있을까 찾아보던 중 카카오 엔터프라이즈의 유용태 개발자님이 만드신 adorable-css를 접하게 되었고 해당 프레임워크로 제 고민의 많은 부분을 해결할 수 있었기에 이렇게 글을 작성하게 되었습니다.
소개
adroable-css는 기본적으로 function-css입니다. 대표적인 tailwind와 비슷한 모양새를 하고 있습니다.
<div>
<h2>:hover</h2>
<div class="w(100) h(100) b(#000) font(12) pack pointer hover:bg(orange) hover:c(#fff) hover:font(18) transition(.5s)">Hover Me</div>
</div>adorable-css의 공식 문서에 따르면 필요한 CSS를 미리 다 만들어두고 빌드 타임에 필요한 만큼만 생성한다고 합니다. tailwind의 예전 버전도 대용량의 CSS 파일을 빌드 타임 때 purge 하는 작업을 진행하였는데 해당 방식과 유사한 것 같습니다. 현재 tailwind는 최소한의 CSS만 만들어두고 내부적으로 JIT 컴파일러로 동작하여 사용자 정의 CSS를 즉석에서 만들어주고 CSS파일 크기를 최소화 해주기 때문에 adorable-css가 빌드 시간은 좀 더 오래 걸릴 것으로 예상됩니다.
설치 및 셋팅
npm i -D adorable-css// vite.config.js
...
import {adorableCSS} from "adorable-css/vite-plugin-adorable-css" // <-
export default defineConfig({
plugins: [adorableCSS(), ...] // <-
})// main.tsx
import React from "react"
import ReactDOM from "react-dom"
import "@adorable.css" // <-
import "./index.css"
import {App} from "./App"
ReactDOM.render(
<React.StrictMode>
<App/>
</React.StrictMode>,
document.getElementById("root")
)vite 기반의 모든 프레임워크 및 라이브러리를 지원한다고 합니다. (CDN 방식도 지원하나 beta버전이라고 합니다.)
사용
사용법은 무척 간단합니다. 보시는 바와 같이 직관적으로 이해할 수 있습니다. 원하는 기능을 수행하는 클래스를 넣어주면 끝입니다.
이 외에도 pseudo class나 media query등 다양한 기능을 지원합니다.
<div class="vbox">
<div class="nth-child(3n+1):bg(orange)">pseudo class!</div>
</div>
<div class="@w(360~):c(red)">@media only screen and (min-width:360px)</div>큰 사용법이랄 것이 없고 필요한 클래스명을 기억해두었다가 삽입하면 되기 때문에 공식 문서를 참고하는 것이 좋을 것 같습니다. (공식문서)
Handshake
adorable-css가 지원하는 강력한 기능 중 하나는 바로 함께 제공되는 피그마 플러그인입니다. 기존에는 디자인이 완성되면 피그마의 inspect를 보고 마크업을 진행하였는데, 위치 정보가 항상 절대 좌표로 제공되어 아쉬움을 느겼습니다. 레이아웃 정보가 제공되지 않으면 마크업 구조를 결국 직접 구상해야 하기 때문입니다. 다만 handshake 플러그인을 사용하면 adorable-css로 작성된 마크업을 제공해주기 때문에 시간을 크게 단축할 수 있습니다. 다만, 해당 기능을 사용하기 위해선 디자이너분들이 몇 가지 가이드를 지켜 그려주어야 한다고 합니다. (참고)
- 모든 요소들은 Frame과 Text을 이용해서 구조적으로 작성을 합니다. Rectangle과 Circle을 이용해서 겹쳐서 그리지 않습니다.
- Circle의 경우 Frame의 border-radius를 이용해서 그립니다.
- 레이아웃은 가급적 Autolayout을 이용하여 작업합니다.
- 겹치는 Overlay를 표현해야하는 경우 Frame을 겹쳐둔뒤 선택해서 Frame Selection(option + cmd + G) 을 사용해줍니다. (Group Selection를 사용하지 않습니다. Group Selection를 사용할 경우 Constraints 기능을 쓸 수 가 없습니다.)
플러그인을 설치하고 위 가이드라인을 따라 완성한 이후 피그마의 상단 플러그인을 눌러주면
아래와 같이 adorable-css로 작성된 코드를 확인할 수 있습니다.
또한 함께 렌더링 되는 컴포넌트는 실제 웹에서 보여지는 뷰와 같기 때문에 디자이너분들은 실시간으로 본인이 만든 결과물이 어떻게 렌더링 되는지 확인할 수 있습니다.
Recap
해당 프레임워크를 접하고 아직까지 프로젝트에 적용해보진 못했지만 제가 이전 협업에서 느꼈던 불편함들은 상당수 해소가 가능할 것으로 예상됩니다. 다만 예상되는 trade-off가 있다면
- HTML 코드가 지저분해지고 가독성이 떨어진다.
- 모든 기능들이 클래스명으로 작동하기 때문에 상당량의 클래스명에 익숙해져야한다.
- tailwind와 같은 프레임워크와 비교했을 때 사용성 측면의 클래스명들은 조금 부족하다.(ex. darkmode, ring 등)
등이 있을 것 같습니다. 다만 1, 2번의 문제점들은 해당 방식과 비슷한 스타일의 프레임워크라면 모두 겪는 사항이며 익숙해진다면 큰 문제 없이 개발이 가능합니다. 3번 또한 차후 업데이트를 통해 확장해 갈 여지가 있기 때문에 저와 같은 고민을 겪은 분들, 협업을 통한 사이드 프로젝트를 진행하시는 분들은 한 번쯤 고려해도 좋을 것 같은 프레임워크인 것 같습니다.
