React Sketch.app 오픈소스 라이브러리 공개
원문: Painting with Code: Introducing our new open source library React Sketch.app.
오늘 우리는 디자인 시스템을 만드는 디자이너와 개발자간 협업을 도와주는 React-sketch.app을 공개하게 되어 기쁘다. 이 툴은 오픈소스 라이브러리이고, 리액트 컴포넌트를 스케치에 렌더링할 수 있다*.
*스케치 파일로 디자인을 한 뒤에 코드로 옮기는 것이 아니라, 정 반대로 코드를 사용하여 스케치에 디자인할 수 있다는 의미이다.
이 라이브러리는 리액트에 친숙한 디자이너나 엔지니어라면 누구나 사용할 수 있도록 제작되었다. 그리고 지금 당장 사용할 수 있다.
아래는 현재 버전에서 가능한 기능들이다.
디자인에 실제 데이터를 접목할 수 있다. 전통적인 API와 GraphQL 엔드포인트같은 것들 말이다.
React Sketch.app은 플렉스박스를 사용하기 때문에 실제 구현된 컴포넌트처럼 다양한 레이아웃이 가능하다. 더이상 마우스로 오브젝트를 드래그할 필요 없이 모든 것이 레이아웃 엔진에 의해 제작된다!
우리는 전세계에 사용자가 있는 회사이다. 그러므로 모두가 잘 사용할 수 있는 디자인은 우리에게 필수이다. 우리의 디자인 툴은 모국어를 넘어서 생각할 수 있도록 도와주어야 한다.
디자인 시스템*은 디자이너가 스타일, 컴포넌트, 패턴을 재사용할 수 있게 해준다. 결과적으로 디자이너들은 더 고차원적인 생각에 더 많은 시간을 쏟을 수 있다. 또한 개발자가 디자이너와 앉아 픽셀 미세 조절을 하지 않아도 되며, 새로운 기능들을 확신을 가지고 구현할 수 있도록 도와준다. 그럼에도 불구하고, 디자인 시스템이 큰 조직에서 해가 될 경우가 있는데, 우리의 경우 그것은 바로 스케치 템플릿이었다.
*역자주 - 디자인 시스템은 구글 매터리얼 디자인 가이드라인과 같은 스타일 가이드라인뿐만 아니라 실제 작업에 바로 사용 준비가 된 스케치 심벌과 같은 디자인 컴포넌트 및 모든 버전과 사이즈의 스크린을 검색할 수 있는 총체적인 시스템을 말한다. 복잡한 제품일수록 디자인 시스템이 필요하지만, 이를 잘 관리하는 것은 상당히 어려우며 실제 제품과 많은 불일치의 잠재 가능성을 가지고 있다.
나는 Airbnb의 디자인 시스템인 DLS (번역본)를 좋아한다. DLS는 타이포그래피, 색상, 간격과 같은 기본 요소로 시작하여 다양한 플랫폼, 화면 크기, 언어에서 작동하는 라이브러리로 확장된다.
물론 디자인 시스템은 결코 완성되지 않는다. 우리는 끊임없이 DLS를 변경하고 새로운 요소를 추가한다. 그리고 전세계의 모든 사람들이 사용할 수 있게 하기 위하여 지속적으로 최적화한다.
디자인 시스템을 변경하려면 일련의 작업 단계를 거쳐야 한다. 문서를 업데이트해야하고, 각 앱의 코드를 변경해야하며 (Swift, Java, JavaScript) 스케치 템플릿을 다시 그려야한다. 이러한 작업들은 일관되게 진행되어야 하며, 각 소스는 항상 다른 소스와 동기화되어야 한다.
코드는 비교적 쉽게 결합 할 수 있다. 우리는 이미 앱의 버전 관리와 지속적인 통합을 가능하게하는 인프라를 갖추고 있다. 문제는 디자인인데, 항상 수작업으로 스케치 템플릿을 유지 관리해야만 했다.
디자인 시스템이 어떻게 구성되어 있는지에 따라 시스템에 미치는 영향을 확인하기 위해 변경 사항을 추적해야한다. 색상을 변경하면 수십 개의 컴포넌트가 영향을 받을 수 있다. 각 컴포넌트는 라인 높이와 간격을 조절하여 다시 그려져야 한다. 다양한 디스플레이 포맷으로 색상을 변환하고, 스펙 주석을 달고, 접근성을 위해 색상 대비를 계산하는 등의 세부 작업은 모두 오류 및 불일치의 가능성을 높인다. 그래픽 소프트웨어는 버전 컨트롤에는 병맛이다. 모든 픽셀의 움직임이 시스템을 일관되지 못하게 하는 잠재적 요소이다 "모바일에서 타이틀 폰트 사이즈는?", "이 컴포넌트가 계속 이렇게 보여야 하는가?", 혹은 "이 컴포넌트가 다른 화면 사이즈에서는 어떻게 적용되는가?" 같은 질문들은 회사에서 자주 들을 수 있다.
이러한 문제들은 조직의 규모와 관계가 있다. 프리랜서 한 명이 디자인하고 코딩할 때는 쉽게 변경할 수 있는 것도 세 명의 디자인 팀에서는 쉽지 않다. 마찬가지로, 우리 팀 같이 중간 사이즈의 팀이 작업할 때는 더 큰 비효율이 발생한다. 따라서 더 효율적인 DLS를 위해 직접적인 사람의 개입을 줄이는 것은 필수이다.
사실 디자이너의 스케치 작업 흐름은 리액트 컴포넌트를 사용하는 것과 매우 유사하다. 스케치에는 심벌과 오버라이드를 사용하듯이, 리액트에서는 컴포넌트와 프로퍼티를 사용한다. 둘의 개념이 너무 유사해서 통합하지 않는게 오히려 이상하다고 생각했다.
우리는 자원을 한 곳에서 관리하기 원했다. 스케치에서 디자인이 완성되고 코드로 구현이 된 다음에는 별도의 스케치 컴포넌트 라이브러리를 관리해야할 이유가 없다.
자원이 통합되어 관리될 수록 더 효율적인 디자인 시스템을 만들 수 있다.
많은 어려운 문제들은 반대로 생각할 때 풀리곤 한다.
— Charlie Munger, Berkshire Hathaway 부회장
디자인 소프트웨어에서 코드를 생성해주는 기능은 오래 전부터 있었다. UI 업계가 스케치를 중심으로 돌아가면서 사람들은 스케치에서 CSS와 같은 코드를 생성해주기 바랬다. 이것은 우리가 다 아는 사실이다. 그러나 우리가 당면한 문제를 풀기 위해서는 이와 정 반대로 생각해야 했다. DLS를 최신으로 유지하기 위해서 코드로부터 스케치 파일을 생성하는 것이다.
우리는 2016년부터 스케치에서 돌아가는 내부 프로그램을 몇 개 제작했다. 그리고 우리는 코드로 파일을 관리할 수 있는 가능성에 대해 배웠다. 하지만 스케치의 언어인 CocoaScript는 대부분의 개발자에게는 생소한 언어였다. 우리는 더 친숙하고 가능성이 많은 자바스크립트를 활용하기 원했다.
리액트는 남은 세기동안 내내 가지고 놀아도 손색이 없는 가능성 많은 라이브러리이다.
— Guillermo Rauch, ZEIT 창업자
우리는 React.js를 좋아한다. 컴포넌트 기반의 디자인 시스템을 구상하고 만들기 좋은 개념이기 때문이다. 그리고 이미 웹과 모바일 앱에서 상당 부분 사용하고 있다. 리액트는 단순히 하나의 플랫폼이 아니다. React Native를 포함하여 다양한 개념으로 사용이 가능하다. (virtual reality, blinking LEDs, music synthesizers, and terminal applications.)
리액트는 기저의 복잡한 플랫폼 API를 감싸기 적합하며 개발자가 다루기 쉽게 도와준다.
'주변 가능성 (adjacent possible)'의 이상하면서도 아름다운 사실은, 탐험할 수록 영역이 더 커진다는 것이다. 각각의 조합은 새로운 가능성을 열 수 있다.
— Steven Johnson
어느 비오는 날 저녁, 우리 팀은 질문을 하나 던졌다. "리엑트를 사용하여 스케치 파일을 만들면 어떨까?" 얼마 지나지 않아 우리는 꽤 괜찮은 수준의 리액트 프로토타입을 만들었다. 그것은 컬러 스와치에 색상 이름과 HEX값을 적은 스케치 파일을 만드는 것이었다. 하지만 우리는 아직 어떻게 더 디자인 시스템에 도움이 될만한 방식을 만들 수 있을지는 알지 못했다.
<rect>, <circle> 및 <line>과 같은 코드 기반의 컴포넌트를 사용한다는 것은, 스케치에서 사용할 수 있는 DLS 컴포넌트를 다시 생성해야 한다는 것을 의미했다. 규모가 큰 시스템일수록 수작업으로 스케치 파일을 만드는 것보다는 빠르겠지만, 아직도 (프로그래밍적으로는) '사용할 수 없는' 보기 좋은 그림을 그릴 수 있을 뿐이었다. 게다가 우리는 실수로 한 가지 소스를 바꾸고 말았다!
그런데 Airbnb의 개발자인 Leland Richardson이 리액트 네이티브 타입의 컴포넌트 사용을 제안하면서 획기적인 돌파가 일어났다. <View>, <Text> 등은 디자인 시스템을 이루는 기본 요소들인데, 개념적으로 스케치 컴포넌트와 연결되었다. 더 흥미로웠던 것은, 그의 React Primitives 프로젝트를 통해 우리는 실제 리액트 컴포넌트를 스케치에 그릴 수 있게 되었다. 그리고 동시에 브라우저와 폰에서도 볼 수 있다.
우리는 사실 이 프로젝트를 정적인 컴포넌트를 생성하는데 드는 시간을 줄이기 위해 시작했다. 그러나 새로운 가능성을 탐구하고 다른 조합을 시도하면서, 디자인 시스템과 스케치를 연결할 수 있는 혁신적인 방법을 발견했다. 많은 것들이 이전에 실현 불가능했거나, 엄청난 수작업을 요했거나, 완벽하지 않은 플러그인에 의존해야만 했던 것들이다. 그러나 이제는 개발자들이 매일 사용하는 언어로 작성이 가능해졌다.
이미 스케치에서 가능한 것에 머물지 않았더니, 흥미롭고 실험적이면서도 우리의 작업 방식에 맞는 툴을 만들 수 있었다. 우리는 우리 팀이 매일 사용하는 소프트웨어와의 호완성을 유지하면서도 더 좋은 내일의 디자인 툴을 만들 수 있었다.
우리는 코드를 디자인 툴로써 사용한다. 단지 레이아웃과 디자인에 머무는 것이 아니라 로직과 데이터를 고려한 에셋을 만들기 위해 노력한다. 이를 통해 디자이너와 개발자간의 간극을 줄이고, 더 나아가 디자인 스펙 문서의 의존성을 줄이고, 비전을 더 현실로 다가서게 만든다.
— Alex Schleifer, Airbnb 디자인 VP
이 프로젝트는 많은 개발자의 공헌을 통해 이루어졌다. Andrew Pouliot, Mathieu Dutour, 그리고 도움을 준 수많은 사람들에게 감사를 표한다. 우리는 이 프로젝트를 오픈소스로 공개하게 되어 기쁘며, 앞으로 더 많은 협업이 이루어지기 기대한다.
당신도 우리와 같이 React Sketch.app을 즐겁게 사용하기 바란다. 완벽하진 않지만 대규모 디자인 시스템을 만드는데 있어 이미 상당이 유용한 툴이다. 실제 데이터를 사용할 수 있으며, 디자이너와 개발자를 더 가깝게 만든다.
우리는 당신이 React Sketch.app으로 무엇을 만들지 벌써 기대된다. 피드백이나 제안이 있으면 언제든 편하게 이메일로 연락하기 바란다. 그리고 이 프로젝트가 흥미로워 보인다면, 현재 우리 샌프란시스코의 디자인 툴 팀은 Design Technologist를 채용 중이다.
글쓴이 Jon Gold는 Airbnb에서 툴, 시스템, 그리고 새로운 기술을 만드는 Design Technologist이다.
앞으로 디자인계의 큰 화두 중 하나가 ‘디자인 시스템’이 아닐까 싶습니다. Airbnb 뿐만 아니라 다른 미국 기업에서도 디자인 시스템을 이미 도입했거나 도입을 검토 중이라는 소식을 종종 듣습니다. 한국에도 디자인과 개발을 진지하게 생각하고, 더 나아가 내부의 효율성을 높이기 위한 노력을 하는 기업들이 많아지면 좋겠습니다.
디자인 시스템은 디자이너가 코드를 알아야 하거나 개발자가 디자인을 알아야 한다는 개인적인 차원의 패러다임은 아닙니다. 제품 디자인/개발 프로세스의 효율성을 높이고자 한다면 누구나 관심을 가져야 하고, 디자이너와 개발자가 머리를 맞대고 고민할 멋진 도전 과제라고 생각합니다.
디자인 시스템은 꼭 Airbnb와 같은 방식일 필요는 없습니다. 그 기업의 특성에 맞는 시스템을 개발해야 한다고 생각합니다. 코드에서 스케치가 아닌 전통적으로 스케치에서 코드로 가는 과정에서도 엄청나게 많은 장애물들이 있습니다. 제플인이나 인비전 같은 툴이 나와서 도와주고는 있지만, 이들은 기능적인 성격이 강하고 회사의 디자인 규칙이 일관되게 전달되지는 못합니다.
저는 기회가 된다면 규모가 작기는 하지만 제가 몸 담고 있는 Daylight이나 디자인 커뮤니티 Design Spectrum에서 실험적인 프로젝트를 시작해보려고 합니다.
읽어주셔서 감사합니다.
Proof reading을 도와주신 김지홍, 김한웅님께 감사드립니다.