스타일 가이드 작성하기

들어가며

지난 글, “스타일 가이드로 웹서비스 개발하기”를 통해 스타일 가이드가 무엇인지, 그리고 웹서비스 개발에 스타일 가이드가 얼마나 중요한지 알아보았습니다. 스타일가이드는 단순히 디자인과 프론트엔드 개발의 참고안이 아닌, 서비스와 함께 성장하는 역할을 합니다. 서비스의 운영과 함께 지속적으로 업데이트되며 성장합니다. 

사용자에게 일관된 사용자 경험을 전달하기 위해 UI의 통일성과 확장성은 필수적입니다. 스타일 가이드는 이를 체계적이고 쉽게 할 수 있도록 도와줍니다. 또한, 점점 비대해지는 서비스의 뿌리 역할을 합니다. 

이번에는 스타일 가이드를 실제로 어떻게 작성하고 유지해가야 하는지 알아보겠습니다. 

어떻게 시작할까

하얀 캔버스 위, 비어있는 텍스트 에디터를 보면 난감합니다. 무엇을 만들지 먼저 고민해야 합니다. 먼저 스타일 가이드에 무엇이 들어가야 할지 구상해 봅니다. 서비스의 와이어프레임이나 화면설계가 미리 준비되어 있다면 매우 좋습니다. 그러면 이를 분해하는 작업부터 시작할 수 있습니다. 

화면설계에서 시작하기

서비스가 완성품이라면 스타일 가이드는 ‘조립’을 위한 ‘부품’의 모음입니다. 따라서 완성품을 분해하여 부품을 유추하는 과정으로 시작합니다.

화면설계를 분석하여 UI단위를 분리합니다. 버튼을 하나하나 따로 분리할 수도 있고, 버튼의 모음으로 분리할 수도 있습니다. 화면에서의 역할이나 목적으로 분리할 수도 있고, 개발 관점에서 <table>이나 <form>과 같은 HTML 태그 단위로도 분리할 수 있습니다. 어쨌든 부품을 만들기 위해 분해를 해야 합니다. 이 분해된 단위를 컴포넌트라고 합니다. 

컴포넌트를 나누는 기준은 매우 중요합니다. 너무 작은 단위로 나누면 “가이드”라는 말이 무색할 정도로 어렵고 복잡해질 것이고, 너무 큰 단위로 나누면 상황별로 재사용하기 어려울 수 있습니다. 저는 가장 중요한 기준은 ‘독립성’과 ‘재사용성’이라고 생각합니다. 분해된 ‘부품’은 너무 작지 않아야 합니다. 스스로 독립적인 “상태”를 가지고, “동작 또는 표현”할 수 있어야 합니다.

버튼을 예로 들어 보겠습니다. 버튼은 활성화, 비활성화, 마우스 오버에 대한 반응, 클릭 이후의 변화 등의 상태를 갖습니다. 그리고 가로, 세로, 여백(padding)과 품고 있는 텍스트의 크기와 같은 표현 값을 가집니다. 버튼의 역할을 부연설명하는 아이콘이 들어갈 수도 있습니다. 이 버튼은 독립적으로 존재하므로 하나의 컴포넌트라고 부를 수 있습니다. 버튼에 상태와 표현을 조금씩 변경하면 다른 상태, 모양의 버튼을 몇 번이고 재사용할 수 있습니다. 

화면설계서의 분해

화면설계가 없다면?

화면설계를 분해하면서 컴포넌트들을 정의하는 방법이 좋긴 하지만, 화면이 설계되기 전에 미리 스타일 가이드를 구성할 수도 있습니다. 웹서비스에 쓰일 부품부터 미리 정의해보는 겁니다. 웹서비스에서 자주 쓰이는 버튼, 드롭다운, 목록, 테이블, 양식(form)등을 미리 구상하여 통일성 있게 구성합니다. 

완성품을 예측하여 부품을 만들기란 매우 어려운 과정입니다. 설계 전에 정확히 어떤 요소가 필요할지 미리 알 수 있을까요? 설계하면서 변경되는 경우도 많을 것입니다. 잘 설계된 부품을 조합했을 때 원하지 않은 모습이 나올 수도 있습니다.

그럴 때는 공개된 스타일 가이드를 참고하는 것이 좋습니다. 유명한 Bootstrap이나 Foundation과 같은 프레임워크의 구성을 살펴보겠습니다. bootstrap이나 foundation은 그 구성이 매우 방대하고, 많은 테스트를 거쳐 견고한 상태입니다. 처음부터 이런 완성도를 기대할 수는 없고, 작은 부분부터 참고합니다. 

방대한 프레임워크 안에서 우리에게 필요한 것들을 추리고, 여기서 우리의 부품 만들기를 시작합니다. Bootstrap의 CSS를 보면 기본적인 헤딩의 타이포그래피부터 테이블 양식(form), 버튼 등 기본 UI들이 미리 구성되어 있습니다. 세부 내용을 보면 상황에 맞게 적용할 수 있도록 여러 크기와 상태로 구성된 것을 볼 수 있습니다. 여기서 우리에게 필요한 것들만 취해봅니다. bootstrap에서는 4가지의 크기와 5가지의 상태를 가진 버튼이 있지만 우리 서비스에 필요한 것은 3개라면? 그냥 그렇게 구성하면 됩니다. 스타일 가이드는 언제든 추가, 보완할 수 있으니까요.

프레임워크의 구성 참고

컴포넌트 + @

우리 서비스는 매우 단순하니까 몇 가지 기본 컴포넌트만 넣기로 했습니다. 계속해서 Bootstrap의 CSS를 살펴보는데 “Helper classes”라는 것이 보입니다. 구성에는 텍스트 색상, 정렬, 상자의 정렬, clearfix 등이 있습니다. 이건 어떻게 쓰는 것이고, 어떻게 우리 서비스에 도움이 될까요? 디자이너와 개발자의 취향의 문제이지만, 컴포넌트 외에 서비스 구성을 돕는 이런 “헬퍼”가 필요합니다. 이 헬퍼는 컴포넌트처럼 명확히 눈에 띄고 독립성을 가지진 않습니다. 다만 여러 컴포넌트에게 두루 적용할 수 있는 정렬이나 자주 쓰이는 색상과 상태를 미리 준비해 놓은 것입니다. 이런 헬퍼들이 있어야 통일성있는 CSS 코드를 작성할 수 있습니다. 무엇보다도, 편합니다. 

컴포넌트의 공통적인 상태를 정의하는 헬퍼

HTML, CSS 작성하기 

컴포넌트 구성이 끝났다면 실제 서비스에 적용할 코드를 작성해야 합니다. 서비스의 동적인 부분은 우선 무시하고 HTML과 CSS로 컴포넌트. 즉, 부품들을 작성합니다. HTML 마크업을 할 때는 되도록 컴포넌트 단위로 작성하고, 이후 쉽게 복사하여 사용할 수 있어야 합니다. 컴포넌트의 역할과 상태를 정확하고 알기 쉽도록 class 이름를 지어줍니다. box, area와 같이 혼동할 수 있는 이름보다는 heading-box나 contents-area와 같은 구체적인 이름이 좋습니다. 

CSS는 컴포넌트의 복잡한 정도에 따라 길어질 수 있습니다. 다양한 상태를 표현해야 한다면 코드는 복잡해지고, 다른 컴포넌트의 스타일 간섭이 있을 수 있습니다. 이를 막기 위해 SASS와 같은 전처리기를 사용합니다. CSS 전처리기는 간결한 문법으로 작성하고 이를 CSS로 변환하여 적용하는 개발 편의 도구입니다. 대표적으로 SASS와 LESS가 있습니다. 작성하기 쉽고, 무엇보다 유지보수가 편합니다. 코드의 가독성도 매우 좋습니다. 컴포넌트의 이름 단위로 nesting한다면 굉장한 업무 효율을 기대할 수 있습니다. 

SASS로 간결하게 

마치며

세상에 100가지 웹서비스가 있다면 개발방식도 100가지가 있을 것입니다. 어쩌면 100가지를 넘을 수도 있습니다. 디자이너와 개발자의 취향에 따라 많은 선택지가 있어 같은 사람이 같은 서비스를 만들어도 다른 결과물이 나올 수 있기 때문입니다. 내 머릿속에 서비스의 지도가 한 번에 그려진다면 어쩌면 스타일 가이드는 필요하지 않을 수 있습니다. 하지만 점점 커지는 서비스의 구석구석을 모두 기억하는 것은 불가능합니다. 무엇보다 우리는 혼자가 아니어서 하나의 결과물을 다수가 만들고 있습니다. 

여러 사람이 만들어도 마치 한 명이 작업한 것처럼 UI의 품질과 통일성이 보장되고, 지속적인 확장이 가능한 이유는 이런 스타일 가이드가 존재하기 때문입니다. 

스타일 가이드는 그 자체로 영감의 원천이 될 수도 있습니다. 컴포넌트를 분리하고 조합하는 과정에서 새로운 아이디어를 얻을 수 있고, 지속적으로 업데이트를 통해 서비스 품질을 향상시킬 수 있기 때문입니다. 아주 작게 시작할 수 있습니다. 스크린 단위의 화면을 디자인하기 전에 스타일 가이드를 고려해 보는 것은 어떨까요.