UI 디자인 시스템 협업 _첫 단추. 네이밍

(feat. BEM 구조 네이밍)

UI 디자인 시스템 도입에 있어서 넘어야 할 산이 있었으니 그것은 바로 네이밍이었다.

사실 통일된 이름을 갖고 있지 못한다면 모두 다 각각 다른 걸 말하고 있을 테니 시스템이 잘 돌아갈 리 없다.

디자인 시스템의 협업을 위한 첫 단추는 네이밍이다.

이런 네이밍에 있어서 개발자와 디자이너는 많은 고민을 했었다. 이런 고민의 해결안으로 제안 된 것은 BEM 구조형식의 네이밍방식이었다.

BEM 이 뭔가요?

BEM이란 CSS에서 class의 네이밍 방법론중 하나이다.

Block- Element -Modifer 라는 구조를 줄여서 BEM이라고 한다.

컴퍼넌트의 클래스 이름을 입력할 때, 해당 컴퍼넌트의 이름에는 흔히 다음과 같은 정보들이 표시된다.   

이 컴퍼넌트는 어디에 쓰이는 건가요?

이 컴퍼넌트의 이름은 뭔가요?

이 컴퍼넌트의 색 혹은( 그리고) 사이즈는 어떤가요?

이 컴퍼넌트는 현재 어떤 상태인가요?

위의 그림과 같이 Block 은 컴퍼넌트들이 모여있는 하나의 섹션의 개념으로 생각하면 되고 (가령 여러 탭들이 있는 네비게이션 바) 그 안에서 실재적으로 기능을 하는 객체인 element(탭)가 있다. Modifier는 엘레먼트안에서 각 상태에 대한 값을 나타내준다. 

예를 들자면, Header__Button--Hover 라고 써있다고 하자. 이 말은 헤더에 있는 버튼인데, 지금 호버상태의 버튼을 가르키는 BEM이 된다. 

이렇게 세 덩어리로 나누기 위해서는 __, — 이렇게 언더바와 하이픈을 2번 연달아서 쓰는데 그 이유는 클래스 이름에서 스페이스바가 허용되지 않기 때문에 이미 한 번 쓰이는 하이픈과 햇갈리지 않게 하기 위해서이다.

실전편

컴퍼넌트들이 늘어나고 개발자와 소통을 할 때 커뮤니케이션에서 이름이 정확하지 않아서 잘 전달이 안되는 경우도 발생하기 시작했다. 제플린을 통해 쉽게 핸드오프가 되지만 간혹가다 (좀 많이) 아이콘이 export가 안되는 이슈들이 생겼기 떄문에 따로 아이콘을 전달해야하는 상황들도 많아졌기 떄문이었다. 안 되겠다! 한 번 에셋의 네이밍에 대해서 셋팅을 해보는 회의를 하는 시간을 가졌다.

어떻게 디자인 에셋들의 이름을 정할 것인가에 대해서 많은 팀들이 BEM 구조를 참고하여 쓰고 있었다.

우리의 경우에는 다음과 같은 부분을 염두하고 BEM 구조 네이밍을 접목시켜보기로 했다. 

  

아직 서비스 초기여서 특정 엘레먼트가 특정한 블럭에 속해져있는 것이 업데이트에 불편할 것 같다. 유연하게 업데이트를 할 것을 생각해서 독립적으로 쉽게 쓰일 수 있게 네이밍을 하자.

직관적으로 이름을 통해 바로 컴퍼넌트를 파악할 수 있게 하자.

다소 이름이 길어지더라도 이름을 보고 누구나 컴퍼넌트 이름을 보고 파악할 수 있게 하자 

첫번째와 두번째의 경우를 종합해보면 특정 엘레먼트를 감싸고 있는 Block에 대한 중요도가 우리팀에겐 낮았고 그런 맥락에서 ‘직관적’이란 Element를 Block의 위치에 바로 보여주는 것이었다. Element에서 한 뎁스 더 들어간 '직관적'으로 파악을 할 수 있게 하는 방식에는 우리는 에셋의 컬러를 잘 보여주는 방식을 택했다. 그래서 현재 팀의 니즈에 맞게 BEM을 적용시켜보았더니 대략 이런 형태였다.

ElementName+ColorName __Size—Status

정석대로 한 건 아니었지만 이렇게 작업 후 확실히 한 것이 낫다는 결론을 얻었다. 앞으로 네이밍 업데이트가 어떻게 될 지는 모르겠지만 그 때의 상황에 또 맞게 한 번 진행을 해야겠다.