디자인 구현을 위한 원칙

디자인 구현을 위한 9가지 원칙

 

 웹 사이트를 구축하는 프로젝트는 보통 '기획-디자인-개발-테스트' 순서로 진행됩니다. 기획자가 사이트를 기획하면 기획서를 바탕으로 디자이너가 디자인을 합니다. 그 후 디자이너가 만든 화면 이미지를 보고 퍼블리셔나 개발자가 HTML을 퍼블리싱하고 프로그램 요소를 추가하게 됩니다. 저는 프로젝트에서 종종 퍼블리싱과 프로그래밍을 동시에 하는 롤을 맡아왔습니다. 디자인된 결과 이미지를 보고 브라우저에서 디자이너가 디자인한 결과물과 동일하게 나오도록 HTML 마크업과 CSS 스타일을 작성합니다. 이러한 작업을 할 때 저는 디자인된 화면과 픽셀 단위까지 동일하게 나오는 것이 중요하다고 생각하고 공을 들이는 편입니다.

 최근에는 모 사이트를 기존의 것과 화면은 동일하게 하되, 서버단 일부만 바꾸는 일에서 템플릿을 만드는 일을 맡게 되었습니다. 이 과정에서 기존 사이트의 마크업을 살펴보았는데, 만약 내가 이 부분을 퍼블리싱한다면 다른 식으로 해야겠다고 생각되는 부분들이 있었습니다. 그런데 문득, '내가 생각하는 방법이 더 나은 방법일까? 더 낫다는 판단은 무엇을 기준으로 할 수 있을까?' 하는 의문이 들었습니다.

 사실 디자인을 보고 HTML 퍼블리싱을 하는 과정에서 가장 쉽게 달성할 수 있는 목표는 디자인과 동일하게 만드는 것일지도 모르겠습니다. 모든 요소에 넓이와 높이 값을 주고 position을 absolute로 잡아서 위치를 맞춰주기만 하면 ─실제로 화면 크기가 다른 많은 기기들에 맞추기 위해 사용하지 않더라도─ 말 그대로 디자인과 "똑같이" 만들 수 있으니까 말이죠. 그렇다면 디자인을 HTML로 구현할 때 중요한 요소는 무엇일까요? 이런 궁금증에 대해 본인의 경험을 살려 9가지 원칙을 제시한 외국 블로거의 글이 있어서 그 글을 소개해볼까 합니다.

제목은 '디자인 구현의 9가지 원칙'입니다. 글쓴이는 이 원칙들은 체크리스트가 아니라, 근본적인 가치를 지키기 위한 전반적인 가이드라인이라고 설명하고 있습니다. 따라서 디자인 구현 작업을 하는 사람에게 가이드라인이 될 수도 있고 기존의 프로젝트를 평가하는 툴로써도 활용될 수 있습니다. 9가지 원칙은 다음과 같습니다.

 

1. 구조화시키기(Structured): 스타일이 있든 없든 HTML 문서를 의미론적으로, 논리적으로 쓴다.

HTML문서의 내용은 표현되는 스타일(CSS)이 없어도 의미를 갖습니다. 이는 올바르게 정렬된 제목 수준(h1, h2, h3...)과 순서를 갖지 않는 리스트(unordered list)를 적절하게 사용했는지, 또한 <header>나 <article> 처럼 의미있는 컨테이너를 사용했는지를 의미합니다. aria label이나 alt 속성과 접근성을 위해 필요한 다른 요소를 생략해서는 안됩니다.

별것 아닌 것처럼 보일 수 있지만, 앵커 태그를 사용할 지 버튼 태그를 사용할 지 중요합니다. 그들이 시각적으로는 동일하게 보일지라도 각기 서로 다른 의미를 가지며 다른 인터랙션(interaction)을 제공하기 때문입니다. 시맨틱 마크업(semantic markup)은 그 의미를 검색 엔진과 보조 공학(ex.스크린리더)에 전달하며 다른 기기에서 용도에 맞게 변경되는 것을 쉽게 해줍니다. 이로써 프로젝트가 좀 더 향후에 대비할 수 있도록 해줍니다. 잘 구성된(well-structured) 문서를 만든다는 것은 시맨틱 HTML을 쓰는 방법을 배우고, W3C 표준과 다른 전문가들의 모범 사례에 친숙해지며, 본인의 코드를 좀 더 이해하기 쉽도록 만드는 데에 시간을 활용한다는 것을 의미합니다. 가장 간단한 테스트는 아무런 스타일없이 작성한 HTML을 브라우저에서 보는 것입니다. 그리고 스스로에게 다음과 같은 질문을 해보세요.

• CSS가 없어도 사용할 수 있는가?

• 스타일이 없어도 여전히 시각적으로 위계 구조를 가지고 있는가?

• HTML 그 자체가 의미를 전달하는가?

잘 짜여진 문서를 보장하는 가장 좋은 방법 중 하나는 HTML부터 시작하는 것입니다. 시각적인 스타일을 생각하기 전에, 문서가 어떻게 구성되어야 하고 각 부분이 어떤 의미를 갖는지를 생각하며 HTML을 작성해 보세요. div 태그를 피하고 어떤 적절한 태그로 감쌀지 생각합니다. 이 기본 단계는 적절한 구조를 만드는 데 도움이되는 방향으로 나아갈 것입니다.

**위와 아래 코드를 비교해보면 1번 원칙의 내용을 이해하기 쉬울 것입니다.

 

 2. 효율성(Efficient): 디자인을 달성하기 위해서 최소한의 마크업과 assets를 사용한다. 

코드가 정확하며 불필요한 마크업이나 스타일을 포함하고 있지는 않은지 생각해야 합니다. HTML의 남용은 CSS나 근본적인 구조를 이해하지 못한 결과입니다. 마크업이나 CSS외에 아이콘, 웹 폰트, 이미지 등의 외부 asset들을 필요로 하는 경우가 있습니다. 이 asset들을 구현하기 위해, 커스텀 아이콘 폰트부터 외부 SVG를 끼워 넣은 base64까지 훌륭한 방법이 많습니다. 모든 프로젝트가 다르지만, 만약 버튼에 들어가는 하나의 아이콘을 위해 500 픽셀짜리 PNG를 사용하고 있다면, 효율을 고려하지 않았을 가능성이 있습니다. 프로젝트의 효율성을 평가할 때, 중요하게 물어볼 두 가지 질문이 있습니다.

• 더 적은 코드로 똑같은 것을 수행할 수 있는가?

• 최소의 오버헤드를 달성하기 위해 asset을 최적화하는 가장 좋은 방법은 무엇인가?

구현의 효율성은 표준화와 모듈화에 관한 원칙들과 중복되는 부분이 있습니다. 효율적으로 하는 한 가지 방법은 표준을 만들어 사용하고 그것들을 재사용할 수 있게 하여 디자인을 구현하는 것이기 때문입니다.

** 'assets'란 텍스트 컨텐트, 그래픽 요소, 이미지, 동영상, 오디오파일 등 사용하는 모든 자원을 의미함.

 

3. 표준화(Standardized): 공통값에 대한 규칙을 저장하고 자유롭게 사용한다.

 웹 사이트나 앱을 위해 표준을 만드는 것은 보통 각 제목 수준의 크기, 공통의 여백 너비, 각 버튼 타입을 위한 스타일을 통제하기 위한 규칙을 세우는 일입니다. CSS를 작성할 때, 외부의 스타일 가이드의 규칙들을 유지해야 하고, 이 스타일들을 올바르게 적용하기 위해 기억해야 합니다. 그러나 LESS나 Sass와 같은 전처리장치를 사용하는 것이 가장 좋은데, 이렇게 함으로써 변수나 믹스인(mixins)에 그 내용을 저장할 수 있습니다. 여기서 주요시사점은 픽셀이 완벽한 디자인을 넘어서 표준화를 중요하게 생각하는 것입니다.

 LESS 변수나 믹스인에서 표준화된 값을 가지고 와서 사용하기 때문에, CSS는 자체적으로 숫자로된 어떤 값도 가지지 않습니다. 모두 중앙화된 값으로 부터 상속되는 것입니다. 표준화를 체크하기 위해서, CSS를 리뷰하고 픽셀, hex 컬러, em, 숫자로된 값 등 하드 코딩된 부분을 살펴봅니다. 가능하면, 표준 값을 사용하고 예외 상황에만 새로운 값을 만듭니다.

** mixins: Mixins는 Vue 컴포넌트에 재사용 가능한 기능을 배포하는 유연한 방법입니다. mixin 객체는 모든 구성 요소 옵션을 포함 할 수 있습니다. 구성 요소가 mixin을 사용하면 해당 mixin의 모든 옵션이 컴포넌트의 고유 옵션에 “혼합”됩니다.

 

4. 추상화(Abstracted): 기본 요소(base elements)가 특정한 컨텍스트와 분리되어 있고, 핵심 뼈대를 구성한다.

이 원칙은 향후 프로젝트나 전체 프로젝트 내에서 사용될 필요가 있는 더 큰 공통 요소를 정의하는 것에 관한 것입니다. 이것은 타이포그래피와 폼 필드 input 그리고 네비게이션 디자인에 이르기까지 광범위하게 시작됩니다. 이렇게 생각해보세요. 만약 작성한 CSS가 부트스크랩이나 파운데이션과 같은 프레임워크로 오픈 소스화된다고 했을 때, 디자인 요소를 어떻게 분리할 것인가? 어떻게 요소마다 스타일을 다르게 줄 것인가? 이미 부트스트랩을 사용하고 있다고 할지라도, 프로젝트는 부트스트랩이 제공하지 않는 기본 요소를 가지고 있을 가능성이 있습니다.

여기서 중요한 점은 각각의 요소를 프로젝트에 특정한 컨텍스트에서가 아니라, 좀 더 포괄적인 조건에서 생각하는 것입니다. 특정한 요소를 살펴보고, 부분으로 나누고 각 요소에 대해 현재 작업중인 특정 구현과 관계없이 해당 요소가 가질 수 있는 전반적인 스타일을 지정합니다. 가장 흔한 요소는 타이포그래피(제목 스타일, 줄 간격, 사이트, 폰트), 폼 요소 그리고 버튼입니다. 프로젝트가 추상화되었는지를 체크할 때, 다음 질문을 해보세요.

• 상이한 요구사항에 의해 다른 맥락에서 재사용 되어야한다는 것을 알았을 때, 이 요소를 어떻게 구성할 것인가?

• 전체 애플리케이션 내에서 중요하게 사용될 부분을 어떻게 쪼갤것인가?

각 요소의 좀 더 일반적인 구현을 생각하는 것이 중요합니다. 유연한 무언가를 만들기 위해서 항상 파생된 맥락에서 작업을 추상화하여야 합니다.

 

5. 모듈화(Modular): 공통 요소들이 논리적으로 재사용할 수 있는 부분으로 나눠진다.

 4번의 추상화 원칙과 중복되지만, 디자인을 모듈화하는 것은 작업과 유지보수가 쉬운 설계 시스템을 확립하는 중요한 부분입니다. 이 둘 사이에는 미세한 선이 있지만, 그 차이는 원칙적으로 중요합니다. 미묘한 차이는 글로벌 기본 요소는 컨텍스트에서 추출해야하지만 상황에 맞는 개별 항목은 재사용이 가능해야하며 독립적인 스타일을 유지해야 하는 것입니다. (즉, '추상화'는 요소에서 일반적인 부분을 추출하는 데에 포인트가 있다면, '모듈화'는 추출한 부분이 특정 스타일을 유지하며 재사용이 가능하게 만드는 것에 포인트가 있습니다.) 모듈은 애플리케이션에 고유할 수 있으며 전체 프레임워크에서 사용 가능하지 않을 수도 있습니다. 그러나 그 모듈이 필요할 때마다 코드를 중복하지 않기 위해서 모듈을 재사용이 가능하도록 만들 필요가 있습니다.

 

6. 설정가능하게하기(Configurable): 기본 요소에 부가적인 파라미터를 통해서 커스터마이징이 가능하다.

디자인 시스템을 구축하면서 프로젝트가 현재 혹은 향후에 필요할 수도 있는 옵션들을 생각해야 합니다. 규정된대로만 디자인을 구현하는 것은 충분하지 않습니다. 어떤 부분을 옵션으로 설정가능하게 할 지, 다른 설정을 통해서 켜거나(on) 끄게 할지(off)를 생각해야 합니다. 예를 들어, 오로지 배경색만 다른 동일한 요소가 있다면, 각각의 독립된 클래스를 만들기 보다 디폴트 클래스를 만들고 선택적인 파라미터로써 부가적으로 클래스 이름을 추가하도록 만들 것입니다. 특정한 디자인 요소를 생각할 때, 가치가 있을 수 있는 옵션에 대해 생각해보세요. 이를 이해하는 가장 중요한 부분은 이 요소가 재사용될 수 도 있는 다른 컨텍스트에 대하여 비판적으로 생각하는 것입니다.

• 외부 변수를 통해 구성, 선택 또는 활성화 할 수 있는 부분은 무엇인가?

• 요소의 색이나 위치가 변경될 수 있다는 점이 중요한가?

• 소, 중, 대(sm,md,lg) 크기를 제공하는 것이 도움이 될 수 있는가?

css를 체계화하고 명명 규약(naming conventions)을 수립하기 위해 BEM(Block Element Modifier), OOCSS(Object-Oriented CSS), SMACSS와 같은 방법론을 사용하는 것은 이러한 결정을 내리는 데 도움이 될 수 있습니다. 이러한 활용 사례(use case)를 통해 작업하는 것은 설정이 가능한(configurable) 디자인 시스템을 구축하는 데 큰 부분을 차지합니다.

** BEM은 프론트엔드 개발에서 재사용 가능한 컴포넌트를 만들고 코드 공유하는 것을 도와주는 방법론이다.

** OOCSS는 간단 명료하고 유지보수가 쉬운 CSS를 작성하도록 도와주는 방법론이다.

** SMACSS는 디자인 프로세스를 검토하는 방법이며 견고한 프레임워크를 유연한 사고 프로세스에 맞추는 방법이다.

 

7. 확장 가능(Scalable): 코드가 쉽게 확장될 수 있고 향후 향상될 것으로 예상된다.

 설정 가능하게 만드는 원칙과 동일한 사상에서, 구현한 내용이 향후에 변경될 것을 예상해야만 합니다. 선택적 매개변수를 도입하는 것이 유용하지만, 프로젝트에 필요하게 될 모든것을 예상할 수는 없습니다. 그러므로, 작성한 코드가 어떻게 향후의 변화에 영향을 미칠지 생각하여 의도적으로 체계화하여 향상되기 용이하도록 하는 것이 중요합니다.

확장 가능한 디자인 시스템을 만들기 위해서는 프로젝트에서 흔히 일어나는 변화를 예상하는 것을 익히고, 이러한 이해를 적용하여 작성한 코드가 그러한 변화에 대비할 수 있도록 합니다. 일반적인 해결책으로는 변수와 mixins을 사용하는 것 뿐만 아니라, 값을 배열에 저장하여 값을 반복시키는 것이 있습니다. 스스로에게 다음과 같은 질문을 해보세요.

• 요소의 어떤 부분이 변경되기 쉬운가?

• 향후 그러한 변화들을 쉽게 적용하기 위해서 어떻게 코드를 작성해야 하는가?

 

8. 문서화(Documented): 모든 요소가 다른 사람들이 사용하고 확장할 수 있도록 설명되어 있다.

 디자인을 문서화하는 것은 저평가되어 있으며 종종 프로젝트에서 생략되는 일순위 항목입니다. 그러나 작업을 기록으로 만드는 것은 옆 사람이 그 작업의 의도를 알아내도록 도와주는 것 이상의 역할을 합니다. 실제로 관련된 모든 사람들에게 전체적인 디자인 시스템을 이해시킬 수 있는 좋은 방법이며, 매번 쓸데없는 시간을 낭비하지 않게 됩니다. 문서는 팀에 있는 개발자부터 경영진까지 모든 이들에게 참고가 될 수 있습니다.

 작업물에 대해 문서화를 하는 가장 좋은 방법은 코드 상의 주석으로부터 직접 생성되는 라이브 스타일 가이드(live style guide)를 만드는 것입니다. 만약 프로젝트가 라이브 스타일 가이드가 없다고 해도, HTML이나 PDF를 사용하여 수작업으로 만드는 것도 괜찮습니다. 이 원칙에서 기억해야 할 것은 작업한 모든 것은 반드시 문서화되어야 한다는 것입니다.

 디자인 시스템을 문서화하기 위해서, 다른 사람으로 하여금 디자인이 어떻게 구현되었는지 그들이 스스로 재창조를 하기 위해서 무엇이 필요한지 이해하도록 도와주기 위한 지침을 작성하세요. 이 정보는 요소 뒤에 있는 특정한 설계 생각이나 샘플 코드, 실제로 작동하는 요소의 데모가 포함될 수 있습니다.

** CSS작성법에 대한 설명을 담은 CSS 가이드라인 예제 사이트: https://cssguidelin.es/

** 데모를 포함한 스타일 가이드 예제 사이트: http://codeforamerica.clearleft.com/

 

9. 정확한(Accurate): 최종 결과물이 의도된 디자인을 적절하게 표현한다.

 마지막으로, 만든 결과물이 의도된 원래 디자인 컨셉만큼 훌륭하게 보이도록 해야한다는 것을 잊어서는 안됩니다. 시각적 매력에 대한 기대를 만족시키지 못하면 아무도 디자인 시스템을 인정하지 않을 것입니다. 결과는 오직 디자인의 적절한 표현이 될 수 있으며 픽셀 단위까지 완벽하지 않을 것이라고 강조하는 것이 중요합니다. "픽셀이 완벽한(pixel perfect)"이라는 문구를 별로 좋아하지 않는데, 왜냐하면 구현이 픽셀 하나하나까지 목업(mockup)과 완전히 똑같아야 한다고 시사하는 것은 여타 모든 제약을 잊고 표준화를 평가 절하하는 것이기 때문입니다. (브라우저마다 CSS를 다르게 렌더링한다는 것을 잊어서는 안됩니다.)

 정확성을 더 복잡하게 하는 것은 반응형 애플리케이션을 위한 디자인이 모든 가능한 디바이스의 크기를 거의 고려하지 않는다는 사실입니다. 요점은 어느 정도의 융통성이 필요하다는 것입니다. 프로젝트에서 얼만큼 적절한 표현이 필요한지를 결정해야 하지만, 반드시 함께 일하는 사람들의 기대를 만족시켜야 합니다.

 

 글을 요약해보자면 디자인 구현에 있어 '픽셀 단위까지 완벽하게 맞추는 것보다 의미있는 최소한의 코드와 자원들로 현재 개발과 향후 유지보수가 용이하도록 만드는 것이 중요하다.'라고 할 수 있겠습니다. 물론 디자인의 의도를 살리는 것이 기본이지만, 융통성을 발휘하여 공통 요소를 만들고 향후 변경될 여지가 있음을 항상 생각하는 것이 중요할 것 같습니다. 그리고 협업이나 유지보수 측면에서 구현에 대한 문서화 역시 생략해서는 안되는 중요한 과정이라는 생각이 듭니다. 디자인을 HTML로 구현하는 분들에게 이 글이 도움이 되기를 바랍니다. (글의 원문 보기)