CSSCONF 참관후기 #1에서 이어집니다.
# 최신 CSS 스펙에 관한 주제
7. CSS4 Grid: 마침내 등장한 진정한 레이아웃(True Layout Finally Arrives)
FlexBox: 이제는 그리드 시스템을 파야할 때(It’s Time to Ditch The Grid System)
과학의 힘으로 수억 마일 밖의 혜성에도 탐사선이 정확하게 착륙하는 시대이지만, 여전히 모던 웹 디자인 분야에서 CSS로 요소를 알맞게 정렬하는 일은 힘들기만 합니다. 웹 디자인에서 두 번째로 시간 낭비를 많이 하게 되는 부분이 바로 처음에는 flexbox로 레이아웃 짜기를 시도했다가 현실의 한계에 부딪혀 그만두고 float으로 돌아가는 것이라고 합니다.
하버드 대학교에서 디지털 미디어에 대한 강의를 하고 있는 젠 크레이머(Jen Kramer)는 새로 등장한 CSS 스펙인 grid에 관해 설명했습니다. 여담이지만 ‘CSS4’라는 것은 실제로는 존재하지 않는다고 합니다. W3C 문서를 살펴보면 CSS 언어의 새로운 버전이 나오는것이 아닌 모듈(예를 들어 그리드에 관한 스펙은 그리드 모듈 안에 정의됨)의 버전이 올라가는 것이라고 합니다.
반응형 디자인의 등장으로 레이아웃을 짜기 위한 노력과 고민이 예전보다 많이 소요됩니다. 가장 고전적인 방식인 float 속성은 가장 안정적인 브라우저 지원을 보여주지만 항상 열의 높이가 같아진다는 단점이 있습니다. 이러한 문제는 자바스크립트로 해결이 가능하긴 하지만 물론 좋은 해결책이 아닙니다. 최근에 등장한 flexbox 속성도 여전히 전체 페이지의 레이아웃용으로는 부족한 점이 있어, float처럼 핵을 사용하게 되어 코드가 복잡해지기도 합니다. 또한 브라우저 지원이 완전하지 못하므로 프리픽스(prefix)와 지원 범위를 신경을 써야합니다. 다만 flexbox는 수직 중앙 정렬 및 박스간의 순서를 바꾸기가 편리하다는 장점이 있습니다.
그러나 이와 연관된 레이아웃 개발에 관한 주제를 발표한 에밀리 헤이만(Emily Hayman)은 flexbox 속성의 브라우저 지원이 충분히 좋아졌기 때문에 실무에 사용하는 것을 주저하지 말자고 설득하였습니다. Bootstrap 4에서도 flexbox를 지원하기 시작했다고 합니다.
CSS
하버드 대학교에서 디지털 미디어에 대한 강의를 하고 있는 젠 크레이머(Jen Kramer)는 새로 등장한 CSS 스펙인 grid에 관해 설명했습니다. 여담이지만 ‘CSS4’라는 것은 실제로는 존재하지 않는다고 합니다. W3C 문서를 살펴보면 CSS 언어의 새로운 버전이 나오는것이 아닌 모듈(예를 들어 그리드에 관한 스펙은 그리드 모듈 안에 정의됨)의 버전이 올라가는 것이라고 합니다.
반응형 디자인의 등장으로 레이아웃을 짜기 위한 노력과 고민이 예전보다 많이 소요됩니다. 가장 고전적인 방식인 float 속성은 가장 안정적인 브라우저 지원을 보여주지만 항상 열의 높이가 같아진다는 단점이 있습니다. 이러한 문제는 자바스크립트로 해결이 가능하긴 하지만 물론 좋은 해결책이 아닙니다. 최근에 등장한 flexbox 속성도 여전히 전체 페이지의 레이아웃용으로는 부족한 점이 있어, float처럼 핵을 사용하게 되어 코드가 복잡해지기도 합니다. 또한 브라우저 지원이 완전하지 못하므로 프리픽스(prefix)와 지원 범위를 신경을 써야합니다. 다만 flexbox는 수직 중앙 정렬 및 박스간의 순서를 바꾸기가 편리하다는 장점이 있습니다.
그러나 이와 연관된 레이아웃 개발에 관한 주제를 발표한 에밀리 헤이만(Emily Hayman)은 flexbox 속성의 브라우저 지원이 충분히 좋아졌기 때문에 실무에 사용하는 것을 주저하지 말자고 설득하였습니다. Bootstrap 4에서도 flexbox를 지원하기 시작했다고 합니다.
CSS
grid는 테스트 중인 스펙으로 현재 브라우저 지원이 전무합니다. 아직은 플래그 chrome://flags 기능으로만 크롬에서 테스트해 볼 수 있다고 합니다. 그럼에도 불구하고 그리드에 관심을 가져야 하는 이유가 있습니다. 우선 CSS 스펙에 공식적으로 게시된 사안이고 온전히 레이아웃 설계를 목적으로 만들어진 기능이기에 기존의 float과 flexbox의 불편했던 점을 개선하고자 만든 더 나은 방법의 속성이기 때문입니다. 앞으로 grid의 테스트가 완료되어 사용이 가능하다면 flexbox는 UI 요소 용으로, grid는 페이지의 메인 레이아웃에 주로 사용하게 될 것으로 보입니다.
8. SVG: 위대한 SVG 레트콘(The Great SVG RetCon)
W3C SVG2 스펙 작성에 참여한 아멜리아 벨라미-로이드(Amelia Bellamy-Royds)는SVG의 새로운 버전인 SVG2에서는 어떤 점이 바뀌었는지 레트콘(Retcon)이라는 연속성 유지 개념을 들어서 설명했습니다.
레트콘(Retcon)이란 retroactive-continuity의 합성어로 주로 만화책나 시리즈물에서 기존의 설정을 바꾸는 것을 말합니다. 지난 내용이 현재 스토리 전개에 방해가 될 경우 의도적으로 과거의 설정을 수정하거나 추가하여 현재와 끼워 맞추는 방식입니다. 만화나 영화에서는 이와 같은 설정 변경이 가능해서 아예 ‘리부트’라는 단어를 붙여 세계관이나 캐릭터 설정을 변경하는 것도 가능하지만 웹에서는 그렇게 할 수 없습니다. XML의 사용으로 웹의 속성을 리부트하려는 시도가 과거에 있었으나, 이미 존재하는 HTML도 동시에 지원을 해야 하므로 실패했습니다. 이러한 사연으로 웹표준 개발자들은 연속성(continuity)에 집중해야 한다는 것을 교훈으로 삼았다고 합니다. 9월 15일에 후보 권고안으로 지정된 SVG2 역시 이러한 연속성 유지를 기본으로 합니다. SVG2에는 새롭고 흥미로운 기능이 추가되었고, 연속성을 저하시키면서 브라우저 지원이 좋지 않은 일부 기존 기능은 삭제되었습니다. 몇가지 웹의 핵심 기능을 중심으로 SVG2에서는 SVG1과 비교하여 달라진 점을 살펴보겠습니다.
첫째로 마크업적인 관점에서 SVG1에서 정의한 ‘SVG는 XML이다’라는 개념은 실패했습니다. SVG1이 나올 당시에는 XML이 HTML을 대체할 것으로 예상했었으나, 여전히 HTML이 널리 사용됩니다. 따라서 SVG2에서는 ‘SVG는 XML 혹은 HTML 마크업으로 표현 가능한 도큐먼트 모델’이라고 재정의하였습니다.
둘째로 링크의 경우, 과거 SVG1에서는 xlink:href 속성을 링크 생성시에 사용했지만, SVG2에서는
또한 스타일에 관련해서도 변화가 있었습니다. 2001년에 SVG1이 만들어질 당시 CSS는 비교적 최신 기술이였습니다. 그것이 일시적인 유행인지 아닌지 알 수 없었기 때문에 SVG 스펙 작업자들은 SVG 소프트웨어에 CSS 파서를 필수 구현 사항으로 지정하는 대신, CSS 속성이나 그에 상응하는 XML 속성을 사용하여 SVG 스타일링을 하게 했습니다. 그러나 15년이 지난 지금, CSS 비중은 여전히 커져만 가고 있고 가상 클래스와 같이 SVG 엘리먼트 속성(attribute)에만 적어내기 어려운 프로퍼티(property)와 규칙들이 생겨남에 따라 SVG2에서는 CSS 속성으로 스타일링을 하도록 변경되었습니다.
CSS와 마크업을 따로 작성하여 표현과 구조를 서로 분리하는 원칙은 SVG에서도 적용이 됩니다. 스펙 작성자들은 기하학적인 구조(geometry)는 컨텐츠이므로 SVG 마크업으로, 그리고 색상을 비롯한 다른 모든 표현적인 것들은 스타일 혹은 속성값으로 정의하도록 하였습니다. 이제 SVG2에서 사용하는 CSS는 HTML 파일 안에서 사용하던 CSS와 동일합니다. 같은 CSS 문법을 사용하며 CSS의 폴백(fallback) 처리 등이 가능해 질 것입니다.
반대로 의도적으로 SVG1에서 이어지는 연속성을 깨고자 하는 예로는
레트콘(Retcon)이란 retroactive-continuity의 합성어로 주로 만화책나 시리즈물에서 기존의 설정을 바꾸는 것을 말합니다. 지난 내용이 현재 스토리 전개에 방해가 될 경우 의도적으로 과거의 설정을 수정하거나 추가하여 현재와 끼워 맞추는 방식입니다. 만화나 영화에서는 이와 같은 설정 변경이 가능해서 아예 ‘리부트’라는 단어를 붙여 세계관이나 캐릭터 설정을 변경하는 것도 가능하지만 웹에서는 그렇게 할 수 없습니다. XML의 사용으로 웹의 속성을 리부트하려는 시도가 과거에 있었으나, 이미 존재하는 HTML도 동시에 지원을 해야 하므로 실패했습니다. 이러한 사연으로 웹표준 개발자들은 연속성(continuity)에 집중해야 한다는 것을 교훈으로 삼았다고 합니다. 9월 15일에 후보 권고안으로 지정된 SVG2 역시 이러한 연속성 유지를 기본으로 합니다. SVG2에는 새롭고 흥미로운 기능이 추가되었고, 연속성을 저하시키면서 브라우저 지원이 좋지 않은 일부 기존 기능은 삭제되었습니다. 몇가지 웹의 핵심 기능을 중심으로 SVG2에서는 SVG1과 비교하여 달라진 점을 살펴보겠습니다.
첫째로 마크업적인 관점에서 SVG1에서 정의한 ‘SVG는 XML이다’라는 개념은 실패했습니다. SVG1이 나올 당시에는 XML이 HTML을 대체할 것으로 예상했었으나, 여전히 HTML이 널리 사용됩니다. 따라서 SVG2에서는 ‘SVG는 XML 혹은 HTML 마크업으로 표현 가능한 도큐먼트 모델’이라고 재정의하였습니다.
둘째로 링크의 경우, 과거 SVG1에서는 xlink:href 속성을 링크 생성시에 사용했지만, SVG2에서는
href 속성을 사용하라고 변경되었습니다. 하지만 xlink:href 사용을 중단한다면 사파리 브라우저에서 동작이 안되는 문제점이 있습니다. 따라서 일렉트론(Electron) 앱이나 최신 버전의 크롬에서 개발하지 않는 이상 기존 브라우저와의 연속성 유지를 위해 xlink:href 를 계속 사용하도록 권장하였습니다.또한 스타일에 관련해서도 변화가 있었습니다. 2001년에 SVG1이 만들어질 당시 CSS는 비교적 최신 기술이였습니다. 그것이 일시적인 유행인지 아닌지 알 수 없었기 때문에 SVG 스펙 작업자들은 SVG 소프트웨어에 CSS 파서를 필수 구현 사항으로 지정하는 대신, CSS 속성이나 그에 상응하는 XML 속성을 사용하여 SVG 스타일링을 하게 했습니다. 그러나 15년이 지난 지금, CSS 비중은 여전히 커져만 가고 있고 가상 클래스와 같이 SVG 엘리먼트 속성(attribute)에만 적어내기 어려운 프로퍼티(property)와 규칙들이 생겨남에 따라 SVG2에서는 CSS 속성으로 스타일링을 하도록 변경되었습니다.
CSS와 마크업을 따로 작성하여 표현과 구조를 서로 분리하는 원칙은 SVG에서도 적용이 됩니다. 스펙 작성자들은 기하학적인 구조(geometry)는 컨텐츠이므로 SVG 마크업으로, 그리고 색상을 비롯한 다른 모든 표현적인 것들은 스타일 혹은 속성값으로 정의하도록 하였습니다. 이제 SVG2에서 사용하는 CSS는 HTML 파일 안에서 사용하던 CSS와 동일합니다. 같은 CSS 문법을 사용하며 CSS의 폴백(fallback) 처리 등이 가능해 질 것입니다.
반대로 의도적으로 SVG1에서 이어지는 연속성을 깨고자 하는 예로는
transform이 있습니다. SVG의 transform 스펙은 나온지 15년이 지났고 완벽하게 브라우저 지원이 가능합니다. 그러나 CSS의 transform 스펙은 CSS 규칙의 일관성을 유지하며 CSS 스펙 전문가에 의해 작성된 것이기 때문에, 현재 SVG의 transform 스펙과는 연관성이 떨어집니다. 예를 들면 SVG는 고유 좌표 시스템을 가지고 있어서 동일한 rotate()을 적용하더라도 SVG 태그 내에서 회전하는 것과 CSS를 사용하여 회전하는 것이 동일한 결과를 보이지 않습니다. 좌표를 기반으로 그려지는 SVG와는 달리 CSS는 작성된 코드에 따라 좌표 시스템이 없을 때도 있으므로 회전 중심점인 transform-origin에 대해 다른 개념을 가지고 있기 때문입니다. 이러한 문제를 해결하기 위해 CSS 워킹 그룹은 최근 CSS transform이 SVG에서 버그없이 사용 될 수 있도록 스펙을 작성하는 협약을 맺었다고 합니다. 시일내에 브라우저에서 개선되길 기다리며 우선은 SVG2 요소에 관한 transform 속성의 사용은 예전처럼 속성값(attribute)으로 적용하기를 권하며, 만일 CSS transform을 적용하는 경우에도 퍼센트(%)는 사용하지 말 것을 당부하였습니다.
9. CSS 변수
MIT 연구원이자 CSS 워킹 그룹의 초대 전문가인 리아 베루(Lea Verou)는 새롭게 등장한 CSS 네이티브 변수를 소개했습니다. 이미 예전부터 존재하는 CSS 변수의 예를 들자면,
사용자 정의 프로퍼티는 이름 앞에 — 기호를 붙여 정의합니다. Sass 변수로 이미 사용이 익숙한 $ 기호를 선택하지 않은 이유는 다른 프레임워크와 사용방법이 중복되어 발생하는 문제를 피하기 위함도 있지만 CSS 변수와는 다른 Sass 변수의 장점과 용도가 있으므로 둘 다 필요에 따라 활용하기 위해서라고 합니다.
CSS 변수명은 대소문자를 구분하며 사용 방법은 간단합니다. 예를 들어, –color: blue;와 같이 기호를 사용하여 변수를 정의하고 변수를 사용할 때에는
일반적인 CSS 프로퍼티처럼 동작하는 CSS 변수는 상속이 가능하여 필요 시 사용자가 상속을 해제하는 방법이 있습니다. 예를 들어, –corners라는 변수가 자손 요소에 상속되지 않게 하려면 * {–corners: initial;}을 선언하여 상속을 전체 해제합니다. 또한 CSS 변수가 유효하지 않거나 브라우저가 지원되지 않는 경우를 대비하여 폴백(fallback)을 작성할 수도 있습니다. 이 경우에는
브라우저 지원은 아래 그림과 같습니다. 안타깝게도 IE는 지원이 Edge 포함 전무한 상태로 실무에서는 사용하기가 어렵습니다. 모바일의 경우도 마찬가지로 iOS 9.2 이하 버전과 안드로이드의 하위(4.x) 버전은 지원이 되지 않습니다. Edge는 가능한 다음 버전에는 해당 기능을 포함하기 위해 노력 중이라고 합니다.
이외에도 리아는 CSS 변수를 사용할 때 몇 가지 주의할 사항도 공유해주었습니다. 먼저 CSS 변수는 특정 단위를 포함한 CSS 값 자체를 직접 할당하기보다 순수 데이터 값(예: 숫자)을 담는 용도로 사용하는 것이 변수를 더 유연하게 활용할 수 있다 말하였습니다. 그리고 숫자인 CSS 변수를 가지고 단위를 붙이는 방법으로는 calc() 함수를 조합하는 방법을 알려주었습니다. 예를 들어, –font-size: 6; 에서 em 단위를 적용하고 싶다면 calc( var(–font-size) * 1em ); 와 같이 변수에 단위를 곱하는 방법으로 단위를 추가할 수 있습니다.
또한 이미지 경로를 CSS 변수에 담아 url() 함수를 사용하거나 애니메이션 @keyframes에 CSS 변수를 사용하는 경우, 브라우저의 버그로 인해 값이 제대로 들어가지 않는 문제가 일부 발생하므로 사용을 주의할 것을 권하였습니다.
CSS 변수는 SVG에서도 사용이 가능하다는 장점이 있습니다. 뿐만 아니라 자바스크립트와도 혼용 할 수 있습니다. getPropertyValue() 함수나 setProperty() 함수를 이용하면 CSS 변수를 가져오거나 인라인 스타일에 넣을 수 있습니다. 또한 기본값을 코드 작성자가 var() 함수의 두 번째 인자로 미리 남겨주면 되므로, 설령 값 입력이 잘못되더라도 걱정할 필요가 없습니다. 즉 CSS 변수를 활용하면 자바스트립트 파일을 전혀 건드리지 않고 CSS 변수로 지정된 스타일링 부분을 얼마든지 CSS만으로 수정할 수 있게 됩니다. 이것으로 리아는 스타일을 담당하는 CSS와 동적인 부분을 제어하는 스크립트의 역할이 더욱 분명하게 분리될 것으로 전망하였습니다.
currentColor라는 키워드 값이 있습니다. 캐스케이딩 원칙에 따라 미리 적용되어 있는 색상값을 가져다 쓸 때 사용합니다. 이보다 조금 더 나아가 이제 CSS에서도 사용자가 임의로 프로퍼티 값(custom properties)을 생성할 수 있는 변수 기능이 도입되었습니다.사용자 정의 프로퍼티는 이름 앞에 — 기호를 붙여 정의합니다. Sass 변수로 이미 사용이 익숙한 $ 기호를 선택하지 않은 이유는 다른 프레임워크와 사용방법이 중복되어 발생하는 문제를 피하기 위함도 있지만 CSS 변수와는 다른 Sass 변수의 장점과 용도가 있으므로 둘 다 필요에 따라 활용하기 위해서라고 합니다.
CSS 변수명은 대소문자를 구분하며 사용 방법은 간단합니다. 예를 들어, –color: blue;와 같이 기호를 사용하여 변수를 정의하고 변수를 사용할 때에는
var() 함수를 사용합니다. –color 변수에 할당한 값을 호출 시에는 var(–color);으로 표기합니다. CSS 변수는 인라인 스타일로도 활용할 수 있는데 style=”–color: yellow;”와 같이 변수의 값만을 조절하여 스타일을 재설정하는 것이 가능합니다.일반적인 CSS 프로퍼티처럼 동작하는 CSS 변수는 상속이 가능하여 필요 시 사용자가 상속을 해제하는 방법이 있습니다. 예를 들어, –corners라는 변수가 자손 요소에 상속되지 않게 하려면 * {–corners: initial;}을 선언하여 상속을 전체 해제합니다. 또한 CSS 변수가 유효하지 않거나 브라우저가 지원되지 않는 경우를 대비하여 폴백(fallback)을 작성할 수도 있습니다. 이 경우에는
var() 함수의 두번째 인자에 다음과 같이 var(–color, orange); 값을 추가합니다.브라우저 지원은 아래 그림과 같습니다. 안타깝게도 IE는 지원이 Edge 포함 전무한 상태로 실무에서는 사용하기가 어렵습니다. 모바일의 경우도 마찬가지로 iOS 9.2 이하 버전과 안드로이드의 하위(4.x) 버전은 지원이 되지 않습니다. Edge는 가능한 다음 버전에는 해당 기능을 포함하기 위해 노력 중이라고 합니다.
이외에도 리아는 CSS 변수를 사용할 때 몇 가지 주의할 사항도 공유해주었습니다. 먼저 CSS 변수는 특정 단위를 포함한 CSS 값 자체를 직접 할당하기보다 순수 데이터 값(예: 숫자)을 담는 용도로 사용하는 것이 변수를 더 유연하게 활용할 수 있다 말하였습니다. 그리고 숫자인 CSS 변수를 가지고 단위를 붙이는 방법으로는 calc() 함수를 조합하는 방법을 알려주었습니다. 예를 들어, –font-size: 6; 에서 em 단위를 적용하고 싶다면 calc( var(–font-size) * 1em ); 와 같이 변수에 단위를 곱하는 방법으로 단위를 추가할 수 있습니다.
또한 이미지 경로를 CSS 변수에 담아 url() 함수를 사용하거나 애니메이션 @keyframes에 CSS 변수를 사용하는 경우, 브라우저의 버그로 인해 값이 제대로 들어가지 않는 문제가 일부 발생하므로 사용을 주의할 것을 권하였습니다.
CSS 변수는 SVG에서도 사용이 가능하다는 장점이 있습니다. 뿐만 아니라 자바스크립트와도 혼용 할 수 있습니다. getPropertyValue() 함수나 setProperty() 함수를 이용하면 CSS 변수를 가져오거나 인라인 스타일에 넣을 수 있습니다. 또한 기본값을 코드 작성자가 var() 함수의 두 번째 인자로 미리 남겨주면 되므로, 설령 값 입력이 잘못되더라도 걱정할 필요가 없습니다. 즉 CSS 변수를 활용하면 자바스트립트 파일을 전혀 건드리지 않고 CSS 변수로 지정된 스타일링 부분을 얼마든지 CSS만으로 수정할 수 있게 됩니다. 이것으로 리아는 스타일을 담당하는 CSS와 동적인 부분을 제어하는 스크립트의 역할이 더욱 분명하게 분리될 것으로 전망하였습니다.
# 특정 플랫폼이나 프레임워크에 대한 소개
10. Electron: 새로운 표준화 방식은 바로 네이티브화 하는 것(Nativize Is The New Normalize)
깃허브에서 온 제시카 로드(Jessica Lord)는 오픈 소스 라이브러리인 일렉트론(Electron)을 소개하였습니다. 일렉트론은 일반적인 웹 페이지를 만들 때 사용하는 웹 기술(HTML, CSS, 그리고 JS 파일)을 가지고 데스크탑 앱을 만들 수 있는 기능을 제공합니다. 대표적인 일렉트론으로 만들어진 프로그램의 예로는 Atom, Slack, Visual Studio Code, Pixate, 그리고 Brave가 있습니다.
일렉트론은 크롬 브라우저의 오픈 소스 버전인 크로미움(Chromium)과 Node.js, 그리고 Native API로 이루어져 있습니다. 크로미움을 통해 앱화면을 그려내고 또한 크롬 브라우저의 최신 기능을 모두 사용할 수 있습니다. Node.js로 사용자의 파일 시스템 및 네트워크에 접근이 가능합니다. 또한 일렉트론의 Native API를 이용해 운영체제와 상호작용이 가능합니다. 일렉트론으로 앱을 만드는 것은 웹 사이트를 만드는 것과 비슷하지만 크롬 환경에서만 개발하며, 다양한 브라우저 대신에 윈도우와 맥 그리고 리눅스와 같은 운영체제 환경을 고려하게 됩니다. 일렉트론 핵심 API 기능은 일렉트론 API 데모를 통해 직접 확인해 볼 수 있습니다.
제시카는 일렉트론 앱 개발에서 가장 중요한 점 중 하나는 ‘Removing the Webiness’, 즉 ‘웹사이트 같지 않게 만드는 것’이라고 하였습니다. 동일한 웹 기술을 사용하지만 웹 사이트를 제작할 때와는 달리 네이티브 앱과 최대한 비슷하게 CSS 스타일링 하는 것이 핵심입니다. 외부 링크나 버튼 그리고 코드 샘플이 아닌 이상 일반적인 웹의 디폴트 스타일은 리셋합니다. 텍스트의 드래그(선택)를 방지하는 처리, 링크나 버튼을 일반 포인터 모양으로 유지하는 처리 그리고 이미지를 드래그로 끌어 움직이지 않게 하는 처리가 이에 포함됩니다.
일렉트론은 사용자의 네이티브 환경에 맞는 메뉴와 다이얼로그를 띄울 수도 있으며 별도로 개발자가 의도하는 앱 디자인이 있을 경우 UI를 커스텀할 수 있는 기능도 제공합니다. 다만 유의할 점은 아이콘의 경우 OS마다 필요한 아이콘 파일이 달라 그에 맞추어 준비해야 합니다. 앱 구동 시에 아이콘 세팅 시점 또한 각 OS마다 다르므로 주의해야 합니다.
사용자와의 상호 작용 방식도 네이티브 방식으로 처리합니다. 앱 구동시 배경 화면을 보여 줄 것인지, 아니면 로딩이 끝난 후에 보여줄 것인지, 메뉴바 앱인 경우에는 언제 표시할 것인지, OS마다 다른 메뉴 컨벤션을 어떻게 적용할 것인지, 앱 프로토콜은 어떻게 설정할 것인지 등을 고려해야 합니다. 일렉트론의 유용한 툴로는 접근성 툴(Accessibility Tools)이 있습니다. 데브트론(Devtron)으로 자체 내장된 개발자 도구를 사용하고, 스펙트론(Spectron)으로 앱 테스트를 진행할 수 있습니다.
일렉트론은 크롬 브라우저의 오픈 소스 버전인 크로미움(Chromium)과 Node.js, 그리고 Native API로 이루어져 있습니다. 크로미움을 통해 앱화면을 그려내고 또한 크롬 브라우저의 최신 기능을 모두 사용할 수 있습니다. Node.js로 사용자의 파일 시스템 및 네트워크에 접근이 가능합니다. 또한 일렉트론의 Native API를 이용해 운영체제와 상호작용이 가능합니다. 일렉트론으로 앱을 만드는 것은 웹 사이트를 만드는 것과 비슷하지만 크롬 환경에서만 개발하며, 다양한 브라우저 대신에 윈도우와 맥 그리고 리눅스와 같은 운영체제 환경을 고려하게 됩니다. 일렉트론 핵심 API 기능은 일렉트론 API 데모를 통해 직접 확인해 볼 수 있습니다.
제시카는 일렉트론 앱 개발에서 가장 중요한 점 중 하나는 ‘Removing the Webiness’, 즉 ‘웹사이트 같지 않게 만드는 것’이라고 하였습니다. 동일한 웹 기술을 사용하지만 웹 사이트를 제작할 때와는 달리 네이티브 앱과 최대한 비슷하게 CSS 스타일링 하는 것이 핵심입니다. 외부 링크나 버튼 그리고 코드 샘플이 아닌 이상 일반적인 웹의 디폴트 스타일은 리셋합니다. 텍스트의 드래그(선택)를 방지하는 처리, 링크나 버튼을 일반 포인터 모양으로 유지하는 처리 그리고 이미지를 드래그로 끌어 움직이지 않게 하는 처리가 이에 포함됩니다.
일렉트론은 사용자의 네이티브 환경에 맞는 메뉴와 다이얼로그를 띄울 수도 있으며 별도로 개발자가 의도하는 앱 디자인이 있을 경우 UI를 커스텀할 수 있는 기능도 제공합니다. 다만 유의할 점은 아이콘의 경우 OS마다 필요한 아이콘 파일이 달라 그에 맞추어 준비해야 합니다. 앱 구동 시에 아이콘 세팅 시점 또한 각 OS마다 다르므로 주의해야 합니다.
사용자와의 상호 작용 방식도 네이티브 방식으로 처리합니다. 앱 구동시 배경 화면을 보여 줄 것인지, 아니면 로딩이 끝난 후에 보여줄 것인지, 메뉴바 앱인 경우에는 언제 표시할 것인지, OS마다 다른 메뉴 컨벤션을 어떻게 적용할 것인지, 앱 프로토콜은 어떻게 설정할 것인지 등을 고려해야 합니다. 일렉트론의 유용한 툴로는 접근성 툴(Accessibility Tools)이 있습니다. 데브트론(Devtron)으로 자체 내장된 개발자 도구를 사용하고, 스펙트론(Spectron)으로 앱 테스트를 진행할 수 있습니다.
11. React: 컴포넌트를 바탕으로 스타일 재사용하기(Component-Based Style Reuse)
피트 헌트(Pete Hunt)는 리액트 프레임워크를 사용함으로써 CSS에 관한 접근 방법을 어떤 식으로 했는지 설명했습니다. 페이스북과 인스타그램을 개발하면서 피트가 느낀 점은 2016년의 사이트들은 더 이상 문서(document)로 취급하면 안된다는 것이였습니다. 그런 점에서 CSS가 가지고 있는 성질인 구체성과 상속, 케스케이딩은 컴포넌트 단위로 프로그래밍을 하려는 이들에게는 아주 마음에 안드는 것이였습니다.
이들이 프로그래밍하는 가장 기본 단위인 컨포넌트란, 다양한 맥락에서 재사용될 수 있는 UI 조각을 뜻합니다. OOCSS에서 주장하는 바도 이와 같습니다. 하나의 CSS로 여기저기서 반복해서 사용할 수 있는 것이죠. 리액트 프레임워크의 가장 핵심이 되는 생각은 정적인 HTML은 이제 없다는 것입니다. 모든 DOM 노드는 js로 생성되고, 모든 컴포넌트들은 렌더링 메소드를 가짐으로써 마크업 리턴값을 가집니다. 또한 기본이 되는 컴포넌트들을 조립해서 다른 컴포넌트를 만들어 냅니다.
다른 사람들과 리액트로 앱을 개발을 하다보면, CSS 클래스명 충돌이 빈번하게 일어나서 원치 않은 스타일링이 여기저기서 발견됩니다. 컴포넌트와 다른 컴포넌트들을 조합하게 되면 더욱 더 예측이 어렵습니다. 리팩토링 또한 불편합니다. 따라서 BEM이나 접두사 혹은 아이디 값을 클래스명에 사용함으로써 고유의 이름을 생성하여 클래스명의 중복을 최대한 피하고자 했습니다. 구체성 문제를 피하기 위해 자손선택자 사용은 하지 않고, 클래스 선택자 하나만 사용합니다. 또한 클래스 이름은 js 코드에서 정확히 한 번만 참조되도록 했습니다. CSS 클래스를 재사용하는 것이 아니라, 컴포넌트를 재사용하는 것입니다.
인라인 스타일의 사용도 시도해보았는데, 리액트에서 꽤 효율이 좋기 때문에 피트의 팀에서는 2년째 채택하고 있는 개발방식이라고 합니다. 컴포넌트 코드가 조금 복잡해 보이지만, js와 CSS 코드를 번갈아 가면서 볼 필요 없이 한 눈에 어떤 요소에 어떤 스타일이 들어가 있는지 알 수 있기 때문에 렌더링 예측 및 리팩토링이 수월했습니다. 다만 미디어쿼리의 경우에는 인라인 스타일로 개발이 힘드므로 이 경우에는 CSS를 사용했습니다. 또한 이렇게 개발된 앱은 미리 모든 요소에 인라인 스타일이 들어가 있는 것이 아니라, 코드가 실행 되면서 DOM에 스타일시트가 주입되기 때문에 성능과 UX에 큰 문제가 없다고 합니다.
CSS 상속에 관한 얘기도 했는데, 처음에는 아예 모든 컴포넌트에 CSS 리셋을 적용해서 상속을 초기화하려고 했으나 특정 스타일은 빈번하게 사용될 수도 있으므로 완전히 초기화하기 보다는 부분 채택하는 방식을 사용했다고 합니다. 2016년의 앱개발에 있어서 문서 형식의 HTML에 맞춰진 CSS의 특성은 불편한 점이 있으므로, 기존 개발 방식과 좀 다르게 시도해보는 실험은 해 볼만 하다고 주장하며 발표를 마무리했습니다.
이들이 프로그래밍하는 가장 기본 단위인 컨포넌트란, 다양한 맥락에서 재사용될 수 있는 UI 조각을 뜻합니다. OOCSS에서 주장하는 바도 이와 같습니다. 하나의 CSS로 여기저기서 반복해서 사용할 수 있는 것이죠. 리액트 프레임워크의 가장 핵심이 되는 생각은 정적인 HTML은 이제 없다는 것입니다. 모든 DOM 노드는 js로 생성되고, 모든 컴포넌트들은 렌더링 메소드를 가짐으로써 마크업 리턴값을 가집니다. 또한 기본이 되는 컴포넌트들을 조립해서 다른 컴포넌트를 만들어 냅니다.
다른 사람들과 리액트로 앱을 개발을 하다보면, CSS 클래스명 충돌이 빈번하게 일어나서 원치 않은 스타일링이 여기저기서 발견됩니다. 컴포넌트와 다른 컴포넌트들을 조합하게 되면 더욱 더 예측이 어렵습니다. 리팩토링 또한 불편합니다. 따라서 BEM이나 접두사 혹은 아이디 값을 클래스명에 사용함으로써 고유의 이름을 생성하여 클래스명의 중복을 최대한 피하고자 했습니다. 구체성 문제를 피하기 위해 자손선택자 사용은 하지 않고, 클래스 선택자 하나만 사용합니다. 또한 클래스 이름은 js 코드에서 정확히 한 번만 참조되도록 했습니다. CSS 클래스를 재사용하는 것이 아니라, 컴포넌트를 재사용하는 것입니다.
인라인 스타일의 사용도 시도해보았는데, 리액트에서 꽤 효율이 좋기 때문에 피트의 팀에서는 2년째 채택하고 있는 개발방식이라고 합니다. 컴포넌트 코드가 조금 복잡해 보이지만, js와 CSS 코드를 번갈아 가면서 볼 필요 없이 한 눈에 어떤 요소에 어떤 스타일이 들어가 있는지 알 수 있기 때문에 렌더링 예측 및 리팩토링이 수월했습니다. 다만 미디어쿼리의 경우에는 인라인 스타일로 개발이 힘드므로 이 경우에는 CSS를 사용했습니다. 또한 이렇게 개발된 앱은 미리 모든 요소에 인라인 스타일이 들어가 있는 것이 아니라, 코드가 실행 되면서 DOM에 스타일시트가 주입되기 때문에 성능과 UX에 큰 문제가 없다고 합니다.
CSS 상속에 관한 얘기도 했는데, 처음에는 아예 모든 컴포넌트에 CSS 리셋을 적용해서 상속을 초기화하려고 했으나 특정 스타일은 빈번하게 사용될 수도 있으므로 완전히 초기화하기 보다는 부분 채택하는 방식을 사용했다고 합니다. 2016년의 앱개발에 있어서 문서 형식의 HTML에 맞춰진 CSS의 특성은 불편한 점이 있으므로, 기존 개발 방식과 좀 다르게 시도해보는 실험은 해 볼만 하다고 주장하며 발표를 마무리했습니다.
12. Webpack: 웹팩과 CSS
자크 그린(Zach Green)은 자기가 속한 팀의 웹팩 사용기를 발표하면서 웹팩 안에서 CSS가 어떤 식으로 처리되는지에 관해 설명했습니다. 웹팩은 모듈을 묶어주는 번들러(bundler)이자 빌드 툴로써, 커뮤니티와 지원 환경이 풍부하다는 장점이 있습니다.
웹팩 공식 문서를 읽어 보면, 하는 일이 ‘의존성으로 엮여 있는 모듈 묶음을 가지고 이들을 대표할 수 있는 정적인 에셋(asset)을 만들어 낸다’고 합니다. 너무 모호한 설명이기 때문에 많은 사람들이 이해할 수 없다고 불평이 많습니다. 그래서 이 문서를 읽고 있기 보다는 그냥 일단 사용해 보는 것이 더 도움이 됩니다.
웹팩의 핵심 요소로는 플러그인과 로더(loader)가 있습니다. 로더는 파일 전처리를 담당하는 역할로,
플러그인을 사용하면 커스텀 빌드 과정을 패키징 과정에 주입합니다. CSS와 Sass 플러그인도 사용할 수 있습니다. 자크의 팀은 CSS를 DOM의 <style> 태그에 주입시켜 주는 style-loader 플러그인만을 사용함으로써 화면 렌더링이 중간에 지연되지 않고, 리로딩이 빠른 개발 과정을 고수한다고 합니다. css-loader는 압축화(minification), sourcemap, CSS 모듈화 기능을 제공합니다. 해쉬값으로 클래스명을 만들어서 유일함을 보장해주는 기능을 쓸 수 있기 때문에 케스케이딩 문제 때문에 골치 아프지 않아도 됩니다.
웹팩 공식 문서를 읽어 보면, 하는 일이 ‘의존성으로 엮여 있는 모듈 묶음을 가지고 이들을 대표할 수 있는 정적인 에셋(asset)을 만들어 낸다’고 합니다. 너무 모호한 설명이기 때문에 많은 사람들이 이해할 수 없다고 불평이 많습니다. 그래서 이 문서를 읽고 있기 보다는 그냥 일단 사용해 보는 것이 더 도움이 됩니다.
웹팩의 핵심 요소로는 플러그인과 로더(loader)가 있습니다. 로더는 파일 전처리를 담당하는 역할로,
require()나 import와 같은 선언문과 함께 사용합니다. grunt나 gulp 같은 빌드 툴의 ‘task’와 비슷하다고 보면 될 것 같습니다. 파일을 받아들인 후에 온갖 변형(transformation)을 가합니다. webpack.config.js파일에 로더들을 보기 좋게 정리하여 가독성 좋은 코드를 쓸 수 있습니다.플러그인을 사용하면 커스텀 빌드 과정을 패키징 과정에 주입합니다. CSS와 Sass 플러그인도 사용할 수 있습니다. 자크의 팀은 CSS를 DOM의 <style> 태그에 주입시켜 주는 style-loader 플러그인만을 사용함으로써 화면 렌더링이 중간에 지연되지 않고, 리로딩이 빠른 개발 과정을 고수한다고 합니다. css-loader는 압축화(minification), sourcemap, CSS 모듈화 기능을 제공합니다. 해쉬값으로 클래스명을 만들어서 유일함을 보장해주는 기능을 쓸 수 있기 때문에 케스케이딩 문제 때문에 골치 아프지 않아도 됩니다.
# 코딩에 관한 새로운 시각을 부여해주는 주제
13. 재미있고 이득이 되는 프로그래밍 속의 창의력(Creativity in Programming for Fun and Profit)
웹 기술 컨설턴트인 새라 드래즈너(Sarah Drasner)는 프로그래밍에서 창의성이 필요한 이유와 평소에 창의적인 코딩을 위해서 실천 할 수 있는 단계에 대해 토론하였습니다.
보통 개발자의 일하는 평균 70%의 시간은 유지보수에 사용되고 직접 코드를 새로 작성하는 것은 단 30%의 비율이라고 합니다. 하지만 코드를 새로 작성하는 것만이 아닌, 유지보수를 위해 프로그램을 읽고 다른 사람과 코드로 소통하는 일 자체도 실제로는 창의력을 요하는 행위입니다. 창의성은 효율적인 결과물을 만들어 내는데 중요하기도 하지만 나 자신을 위해서도 꾸준히 연마하는 것이 좋습니다. 창의성을 발휘할 때 사람은 집중을 하게 되는데 이러한 상황에서 개발자는 코드 작성에 쉽게 몰입(flow)하게 됩니다. 번아웃을 피하는데도 도움이 됩니다.
그렇다면 이러한 프로그래밍 속의 창의력을 발견하는 요소를 다섯가지로 정리하여 살펴보겠습니다. 첫번째는 기본 전제된 것들에 의문을 던지는 과정(Questioning the base premises)이 있습니다. React 라이브러리는 ‘인라인 자바스크립트를 써보면 어떨까?’나 ‘DOM을 쓰지 않는다면 어떨까?’라는 고민에서 출발하였습니다. Sass도 마찬가지로 CSS에 변수가 있기를 바라거나 순환문을 적용하고 싶다는 생각에서 나온 것입니다. 이러한 고민들과 필요성에 의해 발생한 요구사항이 창의성을 통해서 스펙으로 형성될 수도 있습니다.
두번째는 인위적인 발판을 마련(Impose artificial bounds)해보는 것입니다. 무언가 하려 할 때, 어디서부터 시작해야 할지 막막한 경우가 많습니다. 이럴 때는 구현 주제와 관련하여 주위에서 널리 사용되는 것들이 무엇이 있는지 살펴보는 게 좋습니다. 새라는 예로 도시 풍경을 그린 애니메이션 데모를 보여주었습니다. 평범하게 헥사코드로 색상값을 대입해도 되지만, HSLA 색상 표기 방법을 이용하여 일정한 프로그래밍 규칙을 마련하고 애니메이션의 전체 컬러 팔레트가 역동적으로 변경되게 할 수도 있습니다. 이러한 컬러 믹싱 외에도 책에서 참고한 어려운 물리와 수학 공식을 이용해서 파티클을 구현해보거나 프랙탈 모형을 만들어 보는 것도 좋은 시작 방법입니다.
세번째 요소는 알고있는 웹 테크닉의 용도를 응용하여 다른 목적으로 사용해 보는 것(Repurposing)이며, 네번째는 이미 있는 것들의 장점을 조합하여 더 나은 버전을 만드는 것(Combining)입니다. 새라는 수학을 작곡에 활용한 음악가가 있다는 것을 알고 자신도 특정 키를 누르면 애니메이션과 사운드가 재생되는 데모를 만들어 보았다고 설명하였습니다. 조합하기의 예시로는 자신이 만든 여행 정보 앱의 데모로 평소 사용하던 론리 플래닛이라는 사이트와 구글 맵스에서 UX적으로 불편했던 점을 개선했던 경험을 공유하였습니다. 콘텐츠는 좋지만 화면이 실제 여행지 코스를 설계하는데 사용성이 떨어지는 론니 플래닛과 원하던 기능은 있지만 유용한 팁이나 리뷰가 부족했던 구글 맵스를 합쳐 보았다고 합니다.
마지막 다섯번째는 오픈 소스를 활용하는 것(Use open source as a tool)입니다. 예술 창작 활동과 동일하게 코딩 작업 또한 얼마든지 리소스를 통해 영감을 받고 재해석 및 응용하는 과정이 가능하다고 말하였습니다.
위의 그림은 이미 구현되어 있는 접착(adhesive) 효과를 응용해서 메뉴를 만들고 같은 원리를 이용해 일렁이는 촛불 효과까지 구현한 과정을 캡쳐한 것입니다. 아무것도 없는 맨손 상태에서 시작할 필요가 없음을 강조하며 소셜 코딩 사이트인 codepen.io, JSfiddle, 그리고 Dabblet의 적극적인 사용도 권장하였습니다.
보통 개발자의 일하는 평균 70%의 시간은 유지보수에 사용되고 직접 코드를 새로 작성하는 것은 단 30%의 비율이라고 합니다. 하지만 코드를 새로 작성하는 것만이 아닌, 유지보수를 위해 프로그램을 읽고 다른 사람과 코드로 소통하는 일 자체도 실제로는 창의력을 요하는 행위입니다. 창의성은 효율적인 결과물을 만들어 내는데 중요하기도 하지만 나 자신을 위해서도 꾸준히 연마하는 것이 좋습니다. 창의성을 발휘할 때 사람은 집중을 하게 되는데 이러한 상황에서 개발자는 코드 작성에 쉽게 몰입(flow)하게 됩니다. 번아웃을 피하는데도 도움이 됩니다.
그렇다면 이러한 프로그래밍 속의 창의력을 발견하는 요소를 다섯가지로 정리하여 살펴보겠습니다. 첫번째는 기본 전제된 것들에 의문을 던지는 과정(Questioning the base premises)이 있습니다. React 라이브러리는 ‘인라인 자바스크립트를 써보면 어떨까?’나 ‘DOM을 쓰지 않는다면 어떨까?’라는 고민에서 출발하였습니다. Sass도 마찬가지로 CSS에 변수가 있기를 바라거나 순환문을 적용하고 싶다는 생각에서 나온 것입니다. 이러한 고민들과 필요성에 의해 발생한 요구사항이 창의성을 통해서 스펙으로 형성될 수도 있습니다.
두번째는 인위적인 발판을 마련(Impose artificial bounds)해보는 것입니다. 무언가 하려 할 때, 어디서부터 시작해야 할지 막막한 경우가 많습니다. 이럴 때는 구현 주제와 관련하여 주위에서 널리 사용되는 것들이 무엇이 있는지 살펴보는 게 좋습니다. 새라는 예로 도시 풍경을 그린 애니메이션 데모를 보여주었습니다. 평범하게 헥사코드로 색상값을 대입해도 되지만, HSLA 색상 표기 방법을 이용하여 일정한 프로그래밍 규칙을 마련하고 애니메이션의 전체 컬러 팔레트가 역동적으로 변경되게 할 수도 있습니다. 이러한 컬러 믹싱 외에도 책에서 참고한 어려운 물리와 수학 공식을 이용해서 파티클을 구현해보거나 프랙탈 모형을 만들어 보는 것도 좋은 시작 방법입니다.
세번째 요소는 알고있는 웹 테크닉의 용도를 응용하여 다른 목적으로 사용해 보는 것(Repurposing)이며, 네번째는 이미 있는 것들의 장점을 조합하여 더 나은 버전을 만드는 것(Combining)입니다. 새라는 수학을 작곡에 활용한 음악가가 있다는 것을 알고 자신도 특정 키를 누르면 애니메이션과 사운드가 재생되는 데모를 만들어 보았다고 설명하였습니다. 조합하기의 예시로는 자신이 만든 여행 정보 앱의 데모로 평소 사용하던 론리 플래닛이라는 사이트와 구글 맵스에서 UX적으로 불편했던 점을 개선했던 경험을 공유하였습니다. 콘텐츠는 좋지만 화면이 실제 여행지 코스를 설계하는데 사용성이 떨어지는 론니 플래닛과 원하던 기능은 있지만 유용한 팁이나 리뷰가 부족했던 구글 맵스를 합쳐 보았다고 합니다.
마지막 다섯번째는 오픈 소스를 활용하는 것(Use open source as a tool)입니다. 예술 창작 활동과 동일하게 코딩 작업 또한 얼마든지 리소스를 통해 영감을 받고 재해석 및 응용하는 과정이 가능하다고 말하였습니다.
위의 그림은 이미 구현되어 있는 접착(adhesive) 효과를 응용해서 메뉴를 만들고 같은 원리를 이용해 일렁이는 촛불 효과까지 구현한 과정을 캡쳐한 것입니다. 아무것도 없는 맨손 상태에서 시작할 필요가 없음을 강조하며 소셜 코딩 사이트인 codepen.io, JSfiddle, 그리고 Dabblet의 적극적인 사용도 권장하였습니다.
14. 브라우저에서 재현하는 바우하우스(Bauhaus in the Browser)
디자이너인 저스틴 맥도웰(Justin McDowell)은 1919년에 설립된 유명한 독일의 예술학교 바우하우스(Bauhaus)에서 만들어진 모던 그래픽 디자인의 시초가 되는 몇가지 프린트를 브라우저 화면으로 옮겨 재현한 것을 공유하였습니다. 그가 바우하우스 디자인의 특징과 연결지어 설명한 주요 CSS의 기능은 뷰포트 단위(viewport units), 변형(transforms), 그리드(grid), 형태(shapes), 그리고 블렌딩 모드(blending mode)입니다.
타이포 그래픽 실험이 많이 이루어지던 이 시기의 작품 중 하나인 Merz 잡지 8/9호는 쿠르트 슈비터스(Kurt Schwitters)가 엘 리시츠키(El Lissitzky)와 콜라보하여 만든 표지 디자인입니다. 해당 디자인을 보면 글자가 페이지의 일정한 비율로 분할된 영역을 차지하고 있습니다. 이러한 개념은 브라우저 화면에서는 뷰포트 단위로 표현이 가능합니다.
다른 예시로는 얀 치홀트(Jan Tschichold)가 디자인한 이름 없는 여자 영화 포스터의 원근감을 주는 디자인 요소와 perspective 속성을 연관지어서 소개하였습니다. 웹 엘리먼트에 시점을 부여하는 방법은 두 가지가 있습니다. 하나는 transform: perspective(10em); 와 같이 transform 속성으로 자식 요소에 각각 투시도를 적용하는 방법이 있고, 다른 하나는 perspective: 10em;처럼 부모 요소에 투시도법을 포함하여 자식 요소가 모두 같은 구도의 영향을 받게 하는 방법이 있습니다. 해당 포스터의 디자인의 경우 모든 요소들이 1개의 소실점을 공유하므로 후자의 방법으로 구현되었습니다.
그 외에도 shape 모듈은 포토샵의 레이어 마스크 기능과 유사하게 이미지(혹은 특정 엘리먼트)가 차지하는 영역을 원하는 모양으로 클립(clip)하는 기능을 제공합니다. 텍스트 옆에 위치한 이미지에 shape-outside: content-box ellipse();라고 선언해주면 편집 디자인에서 종종 쓰이는 기법처럼 텍스트가 타원 모양으로 주변을 따라 글자가 흘러가는 것을 볼 수 있습니다.
사진작가 유딧 카라즈(Judit Kárász)의 바우하우스 건물을 찍은 사진 Otti Berger and the Bauhaus와 같이 당시 사진 인화 기법의 발달과 함께 유행하였던 다중노출 효과 또한 CSS로 표현이 가능합니다. 하나의 엘리먼트를 페이지에 블렌딩하는 mix-blend-mode 속성을 사용하거나, 여러 개의 배경 이미지를 블렌딩하는 background-blend-mode 속성을 사용할 수 있습니다. 적용할 수 있는 블랜딩 모드의 종류는 대표적으로 screen , multiply 그리고 overlay가 있습니다.
타이포 그래픽 실험이 많이 이루어지던 이 시기의 작품 중 하나인 Merz 잡지 8/9호는 쿠르트 슈비터스(Kurt Schwitters)가 엘 리시츠키(El Lissitzky)와 콜라보하여 만든 표지 디자인입니다. 해당 디자인을 보면 글자가 페이지의 일정한 비율로 분할된 영역을 차지하고 있습니다. 이러한 개념은 브라우저 화면에서는 뷰포트 단위로 표현이 가능합니다.
vw는 너비값의 100분의 1의 단위로 10vw는 화면의 10%를 말합니다. 반대로 vh는 화면의 높이값에 적용되는 단위입니다. 뷰포트 단위를 사용하면 디자인의 창크기 대비 비율을 유지하며 또한 회전된 텍스트는 transform속성으로 적용할 수 있었습니다.다른 예시로는 얀 치홀트(Jan Tschichold)가 디자인한 이름 없는 여자 영화 포스터의 원근감을 주는 디자인 요소와 perspective 속성을 연관지어서 소개하였습니다. 웹 엘리먼트에 시점을 부여하는 방법은 두 가지가 있습니다. 하나는 transform: perspective(10em); 와 같이 transform 속성으로 자식 요소에 각각 투시도를 적용하는 방법이 있고, 다른 하나는 perspective: 10em;처럼 부모 요소에 투시도법을 포함하여 자식 요소가 모두 같은 구도의 영향을 받게 하는 방법이 있습니다. 해당 포스터의 디자인의 경우 모든 요소들이 1개의 소실점을 공유하므로 후자의 방법으로 구현되었습니다.
grid 속성은 기하학적 질서를 강조한 피에트 몬드리안(Piet Mondrian)의 빨강, 파랑, 노랑의 구성이 가진 모듈형 레이아웃을 모방하기에 적합합니다. 사각형의 갯수인 7개의 div 엘리먼트를 생성하고 부모 요소에 display: grid;를 선언합니다. 그리고 뷰포트 단위로 열과 행의 간격을 설계한 뒤 grid-row과 grid-column으로 레이아웃을 지정해 주었습니다.그 외에도 shape 모듈은 포토샵의 레이어 마스크 기능과 유사하게 이미지(혹은 특정 엘리먼트)가 차지하는 영역을 원하는 모양으로 클립(clip)하는 기능을 제공합니다. 텍스트 옆에 위치한 이미지에 shape-outside: content-box ellipse();라고 선언해주면 편집 디자인에서 종종 쓰이는 기법처럼 텍스트가 타원 모양으로 주변을 따라 글자가 흘러가는 것을 볼 수 있습니다.
사진작가 유딧 카라즈(Judit Kárász)의 바우하우스 건물을 찍은 사진 Otti Berger and the Bauhaus와 같이 당시 사진 인화 기법의 발달과 함께 유행하였던 다중노출 효과 또한 CSS로 표현이 가능합니다. 하나의 엘리먼트를 페이지에 블렌딩하는 mix-blend-mode 속성을 사용하거나, 여러 개의 배경 이미지를 블렌딩하는 background-blend-mode 속성을 사용할 수 있습니다. 적용할 수 있는 블랜딩 모드의 종류는 대표적으로 screen , multiply 그리고 overlay가 있습니다.
15. 코딩은 특권이다(Coding is a Privilege)
디자인 디렉터로 vox.com에서 일하고 있는 앨리샤 라모스(Alisha Ramos)는 다양성(diversity)을 주제로 오늘날 테크(tech) 업계에서 우리가 생각해볼 문제를 언급하며 이틀간의 컨퍼런스를 마무리지었습니다.
기술자가 되는 문은 누구에게나 열려 있을 것 같지만 현재 실정은 그렇지 않습니다. 앨리샤는 수영을 예를 들며 이야기를 시작하였습니다. 인종 차별과 백인들의 특권이 당연시 되었던 미국의 60년대 초기에는 공용 수영장에서 흑인은 백인과 같이 수영을 할 수 없었습니다. 부모가 수영을 할 줄 모르면 아이들도 수영을 못하는 현상이 이어졌고, 최근 CDC 통계에 따르면 미국계 흑인 아이들의 물에 빠져 죽을 확률이 백인 아이들에 비해 6배나 높다고 합니다. 그리고 여전히 70%의 미국계 흑인 아이들은 수영을 할 줄 모른다고 합니다. 이러한 차별에 관한 이슈는 여러 인종이 사회를 구성하고 있는 미국과 같은 나라에서 상당히 중요하게 다뤄지는 사회적 사안입니다.
컴퓨터 공학 교육 또한 모두가 누릴 수 있는 것이 아니라고 합니다. AP 컴퓨터 공학 시험(AP Computer Science Exam)을 선택하는 미국 흑인과 라틴계 미국인(히스패닉)은 불과 전체의 13% 밖에 차지하지 않는다고 합니다. 그렇기 때문에 자연스레 테크 분야의 고용률도 미국 흑인 종사자는 전체의 7%, 라틴계 미국인은 5%로 매우 낮다고 합니다. 이러한 격차를 줄이기 위해서는 다양성의 문제에 대해 우리가 올바르게 인식하고 있어야 한다고 말하였습니다. 그래야만 회사의 정책이나 사회적인 시스템에 문제가 있지는 않은지 고민도 시작될 수 있기 때문입니다. 컴퓨터 공학 교육의 기회를 넓히는 것은 모든 사람의 평등한 권리를 보장하기 위한 한가지 방법입니다.
한국인 어머니와 도미니카 공화국에서 온 아버지를 둔 엘리샤는 부유하지도 가난하지도 않았고 한가지 운이 좋았던 점은 컴퓨터가 집에 있었다는 것입니다. 어린 시절 취미 삼아 곧잘 웹을 꾸미고 간단한 사이트를 제작하곤 했지만, 이러한 취미는 직업으로 연결되지 못했다고 합니다. 그녀는 하버드에서 사회학과 중세 역사를 전공한 뒤, 한 컨설팅 회사를 다니게 되었으나 결국에는 좋아하는 웹 디자인과 코딩으로 커리어를 변경하기로 결심합니다. 이렇게 마음을 먹은 후에 일을 배울 방법을 찾아보았지만 코딩 학교(boot camp)는 가격이 너무 비싸서 도저히 들을 수가 없었습니다. 차선책으로 웹의 도움을 받으며 독학을 했고 취직에도 성공하여 컨설턴트로 일할 당시 연봉보다 60% 높은 연봉을 받을 수 있게 되었다고 말했습니다.
그녀가 이 모든 과정을 겪고 나서 든 생각은 ‘왜 진작 이 생각을 못했지?’였습니다. 항상 컴퓨터를 옆에 끼고 살았으면서도 몰랐던 자신을 보면서, 그렇다면 이런 환경에 아예 노출되지 못한 사람들의 입장은 어떨까 생각해 보게 되었다고 합니다. 그래서 내린 결론은, 사람들이 컴퓨터 공학을 접할 기회를 늘림으로써 불평등을 다음 세대로 되물림하는 사슬을 끊을 수 있다는 것입니다. 컴퓨터 앞에 앉기만 하면 코딩을 시작할 수 있지 않냐고 반문하는 사람도 있습니다. 자신의 환경이 전부가 아닙니다. 인종적, 사회 경제학적, 남성적, 종교적, 지리학적 특권 등 생각하지 못한 요인으로 기술을 배우지 못하는 경우도 있습니다.
테크 업계의 다양성 증진을 위해서는 모두를 위한 컴퓨터 공학(CS for all) 운동이나 자원봉사에 참여하는 방법이 있습니다. 만약 소수를 대표하는 그룹에 속한다고 생각하면 자신의 얘기를 롤모델로 만들어 공유하는 것도 좋은 방법입니다. 코딩하는 여성들(women who code)과 같은 단체도 있습니다.
모두에게 공평(equality)성을 부여하는 것과 형평(equity)성을 고려하는 것은 언뜻 비슷한 개념으로 들리지만 두가지는 전혀 다른 내용의 이야기입니다. 앨리샤는 다양성을 포한한 회사만이 다양성을 기반으로 하는 의견(voices)을 낼수 있으며, 그것이 더 나은 비즈니스 결과물(better bussiness result)로 이어질 수 있다고 하였습니다. 최근 스냅챗은 자신의 얼굴을 촬영해 동양인 얼굴처럼 만들어주는 얼굴 스티커로 곤욕을 치렀습니다. 이러한 예를 들며, 만약 회사의 인종적 비율이 편향되지 않고 다양성에 대한 존중과 이해가 팀 내부에 있었더라면 이러한 실수는 없었을 거라고 말하였습니다. 글로벌 사업이 흔히 이루어지는 요즘 시대에는 한 번쯤은 생각해봐야 하는 좋은 내용의 발표였습니다.
기술자가 되는 문은 누구에게나 열려 있을 것 같지만 현재 실정은 그렇지 않습니다. 앨리샤는 수영을 예를 들며 이야기를 시작하였습니다. 인종 차별과 백인들의 특권이 당연시 되었던 미국의 60년대 초기에는 공용 수영장에서 흑인은 백인과 같이 수영을 할 수 없었습니다. 부모가 수영을 할 줄 모르면 아이들도 수영을 못하는 현상이 이어졌고, 최근 CDC 통계에 따르면 미국계 흑인 아이들의 물에 빠져 죽을 확률이 백인 아이들에 비해 6배나 높다고 합니다. 그리고 여전히 70%의 미국계 흑인 아이들은 수영을 할 줄 모른다고 합니다. 이러한 차별에 관한 이슈는 여러 인종이 사회를 구성하고 있는 미국과 같은 나라에서 상당히 중요하게 다뤄지는 사회적 사안입니다.
컴퓨터 공학 교육 또한 모두가 누릴 수 있는 것이 아니라고 합니다. AP 컴퓨터 공학 시험(AP Computer Science Exam)을 선택하는 미국 흑인과 라틴계 미국인(히스패닉)은 불과 전체의 13% 밖에 차지하지 않는다고 합니다. 그렇기 때문에 자연스레 테크 분야의 고용률도 미국 흑인 종사자는 전체의 7%, 라틴계 미국인은 5%로 매우 낮다고 합니다. 이러한 격차를 줄이기 위해서는 다양성의 문제에 대해 우리가 올바르게 인식하고 있어야 한다고 말하였습니다. 그래야만 회사의 정책이나 사회적인 시스템에 문제가 있지는 않은지 고민도 시작될 수 있기 때문입니다. 컴퓨터 공학 교육의 기회를 넓히는 것은 모든 사람의 평등한 권리를 보장하기 위한 한가지 방법입니다.
한국인 어머니와 도미니카 공화국에서 온 아버지를 둔 엘리샤는 부유하지도 가난하지도 않았고 한가지 운이 좋았던 점은 컴퓨터가 집에 있었다는 것입니다. 어린 시절 취미 삼아 곧잘 웹을 꾸미고 간단한 사이트를 제작하곤 했지만, 이러한 취미는 직업으로 연결되지 못했다고 합니다. 그녀는 하버드에서 사회학과 중세 역사를 전공한 뒤, 한 컨설팅 회사를 다니게 되었으나 결국에는 좋아하는 웹 디자인과 코딩으로 커리어를 변경하기로 결심합니다. 이렇게 마음을 먹은 후에 일을 배울 방법을 찾아보았지만 코딩 학교(boot camp)는 가격이 너무 비싸서 도저히 들을 수가 없었습니다. 차선책으로 웹의 도움을 받으며 독학을 했고 취직에도 성공하여 컨설턴트로 일할 당시 연봉보다 60% 높은 연봉을 받을 수 있게 되었다고 말했습니다.
그녀가 이 모든 과정을 겪고 나서 든 생각은 ‘왜 진작 이 생각을 못했지?’였습니다. 항상 컴퓨터를 옆에 끼고 살았으면서도 몰랐던 자신을 보면서, 그렇다면 이런 환경에 아예 노출되지 못한 사람들의 입장은 어떨까 생각해 보게 되었다고 합니다. 그래서 내린 결론은, 사람들이 컴퓨터 공학을 접할 기회를 늘림으로써 불평등을 다음 세대로 되물림하는 사슬을 끊을 수 있다는 것입니다. 컴퓨터 앞에 앉기만 하면 코딩을 시작할 수 있지 않냐고 반문하는 사람도 있습니다. 자신의 환경이 전부가 아닙니다. 인종적, 사회 경제학적, 남성적, 종교적, 지리학적 특권 등 생각하지 못한 요인으로 기술을 배우지 못하는 경우도 있습니다.
테크 업계의 다양성 증진을 위해서는 모두를 위한 컴퓨터 공학(CS for all) 운동이나 자원봉사에 참여하는 방법이 있습니다. 만약 소수를 대표하는 그룹에 속한다고 생각하면 자신의 얘기를 롤모델로 만들어 공유하는 것도 좋은 방법입니다. 코딩하는 여성들(women who code)과 같은 단체도 있습니다.
모두에게 공평(equality)성을 부여하는 것과 형평(equity)성을 고려하는 것은 언뜻 비슷한 개념으로 들리지만 두가지는 전혀 다른 내용의 이야기입니다. 앨리샤는 다양성을 포한한 회사만이 다양성을 기반으로 하는 의견(voices)을 낼수 있으며, 그것이 더 나은 비즈니스 결과물(better bussiness result)로 이어질 수 있다고 하였습니다. 최근 스냅챗은 자신의 얼굴을 촬영해 동양인 얼굴처럼 만들어주는 얼굴 스티커로 곤욕을 치렀습니다. 이러한 예를 들며, 만약 회사의 인종적 비율이 편향되지 않고 다양성에 대한 존중과 이해가 팀 내부에 있었더라면 이러한 실수는 없었을 거라고 말하였습니다. 글로벌 사업이 흔히 이루어지는 요즘 시대에는 한 번쯤은 생각해봐야 하는 좋은 내용의 발표였습니다.
마치며
실제 업무를 하다 보면 브라우저 지원 문제로 적용하지 못하는 최신 속성이나 사용빈도가 낮은 스펙들(Grid, Custom Properties, Compositing and Blending 등) 은 자세히 알기가 어려운데, 이번 기회로 최신 웹 기술에 관한 다양한 정보를 접할 수 있어서 좋았습니다.
개인적으로 흥미롭게 느꼈던 점은, 컨퍼런스 발표자의 성향 중에 크게 대립하는 두 가지 성향이 있었다는 것입니다. 하나는 자바스크립트 안에서 CSS를 사용함으로써 개발상의 제약을 극복하고자 하는 쪽, 그 반대로는 자바스크립트가 CSS를 삼키는 것을 그다지 달가워하지 않으면서, CSS만의 독자성을 유지하고, 현재 개발되는 스펙 모듈에 관심을 지속해서 가져주기를 바라는 쪽이 있었습니다. CSS를 바라보는 대립하는 시각에 대해 비교해보고, 어느 쪽으로 더 관심이 가는지 생각도 해 볼 좋은 기회였습니다.
그러나 두 가지 시각이 공통적으로 시사해 주는 바는, CSS는 이제 웹에서 빼놓을 수 없는 중요한 역할을 맡고 있으며 관련한 라이브러리나 프레임워크도 크게 성장하고 있다는 점입니다. 프로젝트의 성격에 따라 실제 활용 방법은 다양하게 변화될 것이로 생각되는데요, 관련된 경험과 지식이 계속해서 공유되길 기대합니다.
2개의 댓글
Yongwon Kim · 2017년 2월 7일 5:15 오후
멋집니다
ipadoursa · 2017년 5월 8일 8:21 오후
잘읽었습니다. 감사합니다.