코딩을 해본 적이 없다면 퍼블리싱을 어렵고 복잡한 것으로 생각할 수 있다. 나 또한 이해할 수 없는 검정화면의 채도 높은 글자들을 보며 막연히 전문가의 영역일 것으로 생각했었다.
하지만 막상 경험해보니 퍼블리싱은 직관적인 구조를 가지고 있었다.
가장 흔히 사용하는 언어인 HTML로 문서의 뼈대를 만들고, 거기에 스타일을 입히는 것이 CSS라 생각하면 된다. 예를 들어 로그인 버튼을 만든다고 하면 HTML로 버튼을 하나 만들고 'login'이라는 이름(클래스)을 붙인다. 그리고 CSS로 login 클래스의 스타일을 정의하면, 끝!
이를 응용하면 한 요소에 여러 개의 스타일을 중첩할 수도 있다. 로그인 버튼이 비활성화 되었을 때 투명도를 조절하고 싶다면 새로운 버튼을 만들 필요 없이 disabled(비활성화)라는 이름을 하나 더 붙여주면 된다.
코딩을 해본 적이 없다면 퍼블리싱을 어렵고 복잡한 것으로 생각할 수 있다. 나 또한 이해할 수 없는 검정화면의 채도 높은 글자들을 보며 막연히 전문가의 영역일 것으로 생각했었다.
하지만 막상 경험해보니 퍼블리싱은 직관적인 구조를 가지고 있었다.
가장 흔히 사용하는 언어인 HTML로 문서의 뼈대를 만들고, 거기에 스타일을 입히는 것이 CSS라 생각하면 된다. 예를 들어 로그인 버튼을 만든다고 하면 HTML로 버튼을 하나 만들고 'login'이라는 이름(클래스)을 붙인다. 그리고 CSS로 login 클래스의 스타일을 정의하면, 끝!
이를 응용하면 한 요소에 여러 개의 스타일을 중첩할 수도 있다. 로그인 버튼이 비활성화 되었을 때 투명도를 조절하고 싶다면 새로운 버튼을 만들 필요 없이 disabled(비활성화)라는 이름을 하나 더 붙여주면 된다.
바꿀 수 있는 스타일의 이름(속성)과 스타일 작성 요령(문법)만 익히면 정말 쉽게 사용할 수 있다. "그걸 모르는데?"라고 한다면, 그래도 상관없다. 모든 게 그렇듯이 우리만 모르는 게 아니며, 구글 선생님은 모든 것을 알고 계시니까! 이미 인터넷에는 잘 정리된 퍼블리싱 관련 사이트와 커뮤니티가 많아 참고할 수 있었다. 또 몇 번 하다 보면 익숙해져서 커닝 빈도가 줄어들게 된다.
먼저 커뮤니케이션 비용이 줄어든다. 앞서 언급했듯이 엔지니어와 디자이너는 커뮤니케이션 방식이 서로 다르다. 따라서 커뮤니케이션 비용이 많이 들고, 소통이 제대로 이루어지지 않을 리스크까지 있다.
하지만 코딩하는 디자이너는 코드를 읽을 수 있다. 구조를 파악하는 것은 물론, 엔지니어가 스타일을 어떻게 정의하고 부르는지 알 수 있다는 뜻이다. 변수와 수치로 디자인 스타일을 명확하게 표현할 수 있기 때문에 더욱 원활한 의사소통이 가능하다.
그리고 기술에 대한 지식이 늘어갈수록 구현 가능 여부를 고려하여 디자인할 수 있게 된다. 할 수 있는 것과 없는 것을 사전에 파악하여 리소스를 아낄 수도 있고, 퍼블리싱 지식을 바탕으로 새로운 인터페이스 또는 인터랙션을 시도해볼 수도 있다.
즉, 고려할 수 있는 선택지는 더 많아지고 선택의 기준은 더 확실해진다는 것이다.
디자인, 퍼블리싱, 밸런스!
디자이너 개인의 입장에서도 퍼블리싱은 도움이 된다. 디자이너의 역할이자 디자인의 매력은 문제를 찾고, 해결하고, 발전시키고, 또 발전시키고, 그렇게 혁신을 만들어내는 것이라고 생각한다. 즉, 디자인은 정답이 없는 문제에 뛰어들어 가치 있는 솔루션을 찾아 헤매는 일이다.
그렇지만 그것도 한두 번! 가끔은 이런 생각이 들기도 한다.
아… 난 과연 잘하고 있나? 이게 제대로 된 방향이 맞나? 뭘 어떻게 더 해야 할까… 자괴감 들고 괴로워🤦♀️
솔루션을 잘 내고 있는 것인지부터 근본적으로 문제를 제대로 파악했는지, 고민이 반복되며 지쳐버리는 것이다. 예측대로 행동하지 않는 사용자의 경험을 설계하는 이 일의 특성 탓이다. (일어나지 않은 일도 미리 걱정하는 내 성격 탓일지도 모르겠다...)
반면 퍼블리싱은 내가 이미 한 디자인을 '똑같이' 웹상에서 만들어내면 되는 일이기 때문에 달성 기준이 명확했다. 컴퓨터에 인풋을 넣은대로 아웃풋이 바로 나온다는 점이 속시원했고, 쓸데없는 고민이나 잡념을 어느 정도 버릴 수 있었다.
심지어 체크리스트를 하나씩 달성할 때면 성취감을 만끽하며 왠지 모를 자신감도 얻을 수 있었다.
이게 되네? 내가 해냄!😎
또한 구조화하고 코딩하는 머리는 디자인할 때 쓰는 머리와 다르게 느껴져 (이것이 좌뇌, 우뇌…?) 다음 디자인 작업을 하기 전에 리프레시되는 효과가 있었다. 디자인과 퍼블리싱은 서로 다른 특징을 갖고 있기 때문에, 함께 하면 시너지 효과가 나서 둘 다 더 잘할 수 있었던 것...!
멋진 엔지니어와 함께라면 두렵지 않아요!
그럼에도 불구하고 퍼블리싱을 '시작'하는 것은 어려운 일이다. 특히 코딩 자체가 처음이라면 도대체 뭐부터 시작해야 하는 것인지 고민에 빠질 것이다. 당연하다.
세상에는 참 많은 개발도구와 언어가 있고, 띄어쓰기 하나 잘못했다고 실행이 안되는 경우도 있다. 에러메시지는 왜 또 다 영어에 모르는 말 투성인지. 정말 최악의 경험이다. (실제로 퍼블리 입사 전 취미로 코딩을 해보려다 설치 단계에서 포기한 적도 있다😇)
하지만 회사에는 우리를 도와주는 빛과 소금 같은 존재, 엔지니어들이 있다. 심지어 퍼블리의 경우에는 자세한 가이드 문서가 있어서 시키는 대로만 따라 하면 개발 환경 세팅을 완료할 수 있다.
중간에 예기치 못한 문제가 생겨도 걱정없다. 혼자 고민하지 않고 엔지니어에게 공유하면 함께 해결할 수 있으니까!
작업 도중에 어려운 부분, 잘 안 되는 부분이 있을 때도 언제든 도움을 청했다. 특히 버튼을 클릭할 때, 스크롤할 때, 마우스 포인터를 올릴 때 등 특정 인터랙션이나 액션을 구현하는 부분은 엔지니어에게 요청하면 빠르게 문제를 파악하고 해결할 수 있다.
이런 부분이 퍼블리싱과 엔지니어링 사이의 그레이 영역이라고 볼 수 있을 것 같은데, 결국 퍼블리싱을 잘 하기 위해서는 코딩 실력보다 소통을 얼마나 잘 하는지가 더 중요한 것 같다. (그래서 퍼블리에서는 엔지니어와의 원활한 소통을 위한 커뮤니케이션 가이드 문서를 만들어 팀에 공유했다!)
Utility-First: 디자인 시스템을 코드로
본격적으로 퍼블리싱을 시작하게 되면 어떤 속성을 변경할 수 있는지, 어떻게 바꿀 수 있는지 모른다는 점 또한 장벽으로 느껴질 수 있을 것 같다.
잠시 디자인 시스템을 떠올려보자. 스타일에 대한 규칙을 정의하고 이를 정확하게 적용함으로써 디자인의 일관성을 유지하고, 반복되는 UI는 컴포넌트화함으로써 효율적인 디자인을 꾀하는 것이 바로 디자인 시스템이다.
디자인 시스템의 규칙이 퍼블리싱에도 그대로 적용된다면? 그럼 한결 가벼운 마음으로 시작할 수 있지 않을까? 퍼블리의 경우 디자인 시스템을 구현까지 쉽게 할 수 있도록 하는 자체 프레임워크를 만들어 활용하고 있다. 리퍼블릭(republic)이라고 이름 붙인 이 파일에 디자인 시스템을 코드화 해두었으며, '유틸리티 퍼스트' 방식을 채택한 것이 가장 큰 특징이다.
예를 들면 그레이스케일 색상에 white, gray-100, … , gray-900, gray-950, black이라는 이름을 붙인 것이다. 그럼 더 이상 퍼블리싱할 때마다 색상의 RGB 값을 찾아봐야 하는 불편을 겪지 않아도 된다. 색상 외에도 글꼴 크기, 배경 색상, 여백, 테두리 등 다양한 속성의 값이 직관적인 이름으로 정의되어 있으며, 이 이름을 유틸리티 클래스라고 한다.*
