디자이너에게 개발이 더 이상 스펙이 아닌 이유
개발하는 디자이너 챌린지 - 01
챌린지 소개
'개발하는 디자인 챌린지'는 스레드(threads)에서 모집한 디자이너 참가자들과 개발 스터디. 실습을 진행하기 위해 매주 1 회식 발행하는 교육자료입니다.
0. 프롤로그
자랑 한 번만 하겠습니다. 디자인 에이전시(Data Driven Design)를 운영하고 있는 저는 프로젝트 종료 후에도 고객사 실무자들과 좋은 관계를 이어갈 때가 많습니다. 그들의 현실적인 페인포인트를 해결하기 때문입니다. 이는 크게 '설명하기 어려운 디자이너'와 '일 두 번 하기 싫은 개발자'로 나뉩니다.
이런 페인 포인트들은 지식의 장벽보다는 성격이 다른 업무 간의 의존성에 더 큰 영향을 받습니다. '개발하는 디자이너 챌린지'는 이러 관점에서 기획한 기술 에세이 시리즈입니다. IT 업계의 디자이너분들이 react.js를 통해서 모던 프레임워크에 한층 익숙해지고, 협업과 디자인 역량 에도 도움이 되길 바랍니다.
첫 번째 에피소드 '디자이너에게 개발이 더 이상 스펙이 아닌 이유'에서는 react를 본격적으로 배우기 전에 디자이너가 갖추면 좋을법한 마인드셋과 구체적인 목적의식을 얘기해 보겠습니다.
1. 공장을 한 번도 가보지 않은 자동차 디자이너
여러분 혹시 감각은 기똥차게 좋은데 공장 견학을 한 번도 안 가본 자동차 디자이너가 상상이 가시나요? 디자인은 결국 실존하는 것을 만드는 과정에 속한다는 걸 잊지 마세요. 건축가가 설계공정을, 자동차 디자이너가 기계 공학을 공부하는 건 너무나도 당연합니다.
이 디자인이 설계적인 측면에서 오류는 없는지, 리소스를 얼마나 요구하는지 등 디자인 싱킹에서는 말하는 feasibility에 해당되며 빅테크 기업들이 디자이너 채용에서 강조하는 product sensitivity도 같은 맥락입니다.
2. 개발을 배운다는 것의 의미
위 관점으로 봤을 때 디자이너가 개발을 배운다는 건 다음 세 가지 의미가 있습니다.
2-1 창작의 자유도가 높아진다.
일단 내 디자인을 직접 구현한다는 창작의 기쁨이 학습비용을 높여줍니다. 만들고 싶은 대상이 구체적일수록 이러한 경향이 강해지며 '내 관념'이 철저하게 '논리적인 인 코드'로 옮겨지는 첫 경험을 하게 됩니다. 즉 말이 아다르고 어다르다는걸 직접 뚝딱거리면서 체감하는 단계입니다.
2-2 개발자와 협업 수준이 높아진다.
이제 디자인 가이드를 어떻게 보여줘야 하는지 대충 감이 오기 시작합니다. 시각적인 복잡도와 구현의 난이도가 일치하지 않는다는 걸 알기에 사용자 시나리오에 영향을 미칠 개발 의존성을 좀 더 촘촘하게 논의할 수 있습니다. 결과적으로 빠른 합의 + 리소스가 절약을 억습니다.
2-3 역설적으로 디자인을 더 잘하게 된다.
이전 단계에서 힘 빼고 작업하는 노하우를 점점 터득했다면, 절약한 에너지로 디자인의 범위를 넓혀갑니다. 화면, 제품을 벗어난 개발 프로세스 전체를 디자인하게 됩니다. 제품을 구성하는 단위를 잘게 쪼개고 이를 디자인과 개발 사이드에서 싱크 되도록 관리합니다.
3. 개발을 어렵게 느끼게 하는 3가지 미신
하지만 위 과정을 경험한 디자이너들은 굉장히 소수입니다. 애초에 배울 엄두를 못 내고, 디자인 하나만 잘하기 바쁘다고 생각하는 사람들이 대부분이죠. 그렇다면 왜 개발을 배우기 도전에 심리적인 괴리감을 느끼는 걸까요?
3-1 디자이너와 개발자는 다른 종족이다?
일단 두 분야가 요구하는 성향이 크게 다르다는 오해가 있습니다. 물론 서로 감수성과 논리력을 쓰는 비율이 다른 건 맞습니다. 하지만 큰 문제를 정의하고 이를 작은 문제로 쪼개서 해결하는 능력은 두 분야에서 그 어떤 것보다 중요합니다. 이렇게 하는 이유는 목적이 뭉뚱그려진 상태에서는 불필요한 행동들을 매우 반복할 여지가 크기 때문이죠.
UX 디자인은 가치 > 사용자 시나리오 > UX 패턴 > UI 순으로 큰 것을 먼저 정의하고 작은 것들로 쪼개는 과정입니다. 개발 역시 '사용자 시나리오'가 성립하기 위해 필요한 더 작은 요소들을 계속 쪼개는 접근이 필요합니다. '어떻게' 보다 '무엇이' 필요한지를 먼저 정하는 이 '선언적(declartive)'접근은 뒤에서 더 설명하겠지만 UI 디자인. 개발 영역에서 공통으로 중요한 개념입니다.
3-2 모든 문법을 알아야 개발이 가능하다?
여러분이 모든 디자인을 잘할 수 없듯이, 개발자들도 모든 걸 알지 못합니다. 중요한 건 위에서 말한 문제정의를 잘하고 당장 필요한 걸 찾는 메타인지입니다. 모르는 걸 찾는 건 꽤나 쉬운 세상입니다. 하지만 무엇을 모르는지 모르는 것은 기술이 해결해주지 않습니다. 내가 무엇을 하려는지 명확하다면 배워야 할 영역 또한 충분히 좁힐 수 있습니다.
모든 문법을 처음부터 다 배워야겠다는 방식보다는 당장 필요한 것을 인지하고 공식 문서나 검색 + LLM을 통해 빠르게 학습하는 능력이 더 중요합니다.'바퀴를 재발명하지 말라'라는 명언은 개발에서도 마찬가지입니다. 여러분이 모든 문법을 배워야 다음 진도로 나갈 수 있다기보다, 필요한걸 빨리 찾는 인덱싱 능력이 더 중요합니다. Chat gpt, perplexity 등의 LLM 서비스로 개발 습득력이 높아진 지금 시대에서는 특히 더 그렇습니다.
3-3 둘을 병행하는 것은 노력이 배로 든다?
처음에는 당연히 배의 노력이 들 수밖에 없습니다. 하지만 위에서 말한 개발울 배운다는 3가지 의미를 다시 짚어본다면 개인이 프로젝트를 구성하는 시간, 개발자와의 협업시간 그리고 전체 프로세스를 개선해서 절약한 리소스등을 감안하다면 장기적으로 노력을 줄이는 과정입니다. 지수함수와 같은 J커브를 상상해 보세요.
4. 모던 프레임워크의 역할
이제 모던프레임워크에 대해 잠시 설명해 보겠습니다. 결과적으로 웹상에 존재하는 거의 모든 웹사이트들이 동적으로 작동하려면 여러분이 한 번쯤 들어본 javascript를 사용해야 합니다. 하지만 순수하게 html과 javascript만 활용해서 웹서비스를 만들기에는 많은 제한 사항이 있습니다.
그래서 react.js처럼 반복되는 컴포넌트의 구성과 화면의 데이트 흐름을 처리하기 위해 미리 설계된 조립 키트 정도를 모던프레임워크라고 이해하시면 됩니다. 이름에서 알 수 있듯이 대부분 모던프레임워크 또한 javascript로 만들어졌습니다. 그렇다면 모던 프레임워크가 앞선 맥락들과 어떻게 연결되는지를 본격적으로 설명해 보겠습니다. 일단 react.js로 만든 스레드 웹사이트의 두 크롬 인스펙터 화면을 비교해 보도록 하죠.
왼쪽은 크롬의 기본 인스펙터로 스레드 웹사이트를 살펴본 것이고 오른쪽은 react 전용 inspector를 켠 것입니다. 일단 어떤 프레임워크를 사용했건 사용자들이 보는 화면은 결국에는 왼쪽의 인스펙터처럼 html의 기본 태그들로 이루어진 페이지입니다.
과거에는 개발자들이 왼쪽 결과물과 동일하게 웹사이트를 만들어야 했습니다. 하지만 기본 태그들만 조합하는 방식은 큰 한계가 있습니다. 반복해서 사용되야 할 컴포넌트들의 변경 사항이 생길 때마다 매번 바꾸는 수고스러움. 그리고 사용자에게 필요한 데이터를 페이지간에 공유하는 문제들을 제어하는 것이 여간 수고스러운 게 아니었습니다.
오른쪽 화면은 react.js에서 작성된 코드를 기준으로 보여준 inspeector입니다. 물론 당장 보면 이 화면도 복잡해 보이지만 차이점은 공통적으로 사용되는 컴포넌트와 데이터의 흐름이 이미 정리되어 있는 상태입니다. 각 컴포넌트를 클릭하면 이 컴포넌트들이 어떤 데이터와 기능들을 내포하고 있는지 미리 정의되어 있습니다.
5. 그래서 왜 리액트인가?
이 글은 react.js가 가장 좋다는 취지에서 쓴 것은 아닙니다. 다만 저에게 가장 익숙하기도 하고, react의 등장이 역으로 디자인 툴에 미친 영향의 상징성이 있기 때문에 디자이너가 배우기 좋은 프레임워크라고 생각합니다. 예전에 디자인툴과 개발툴은 점점 비슷해질 것이다라는 글을 쓴 적이 있습니다. 다소 과장된 내용이지만 결국 둘 다 디자인 컴포넌트를 구성하는 2가지 타입의 데이터를 효율적으로 관리하는 방향으로 진화하기 때문입니다.
첫 번째 데이터는 컴포넌트의 '역할'을 정의하는 데이터이고 두 번째는 '형태'를 정의하는 데이터입니다. figma애서 1번은 property, 2번을 variable이라고 합니다. 그리고 react.js 입장에서는 1번은 props, 2번은 디자인 토큰에 해당되며 다양한 방식으로 다뤄집니다.
V0라는 온라인 코드 생성툴을 이용해서 직접적인 예시를 들어보겠습니다. 아래 화면은 프롬프트에게 에어비앤비 랜딩페이지를 카피해 보도록 시킨 건데 하나는 순수 html + javascript조합 그리고 하나는는 react.js를 이용하라고 시켰습니다. 그리고 그 결과는 아래 링크에서 직접 확인할 수 있습니다.
v0에게 '에어비앤비 랜딩페이지를 카피해 줘'라는 프롬프트를 입력해 보았다.일단 react버전의 코드 사진을 순서대로 보시면
- 랭킹 페이지의 구성 (헤더, 히어로, 목적지, 경험, 푸터)
- 목적지 섹션
- 목적지 카드
식으로 나뉘어 작성된 걸 볼 수 있습니다. 처음 보는 코드에 다소 혼란이 있을 수 있지만 쫄필요 없습니다. 일단 에디터 구성을 잠시 설명하자면 왼쪽은 웹사이트를 구성하고 있는 파일들의 구성을 보여주는 탭이고 오른쪽 섹션을 해당하는 파일(컴포넌트)의 코드를 보여줍니다.
가장 밑에 AirbnbLandingPage.js가 위에 렌던링된 화면에 해당되고 그 위의 컴포넌트들은 이 페이지를 구성하고 있는 컴포넌트라고 보시면 됩니다. 이 코드를 읽는 방법은 다음 에피소드에서 다시 설명드릴 텐데 일단 react.js 프로젝트가 어떻게 구성되었는지를 보여드리기 위해 작성한 예시 코드입니다.
코드 내부를 살펴보면 상단의 import는 이미 만들어져 있는 '무언가'를 갖고 오겠다는 뜻입니다. 아래 이름이 붙여진 태그들은 import에서 불러온 컴포넌트나 html의 기본 컴포넌트들(태그)들로 구성된 페이지 혹은 컴포넌트의 구조라고 보시면 됩니다. 위에서 반복해서 말했듯이 '무엇이'필요한지 먼저 정의하고 설계하는 것이 중요합니다.
그리고 AirbnbLandingPage.js의 import 구문 아래에 선언된 데이터들 은 (실제로 웹서비스에서는 api를 통해 받아야 하는 데이터입니다) 위에서 언급한 property(figma 입장)과 props(react.js 입장)에 넘겨주는 대상입니다. 페이지의 각 섹션들은 필요한 데이터를 props로 받고 다시 DestinationSection과 DestinationCard의 코드를 보시면 넘겨받은 props가 어떻게 처리되는지 보실 수 있습니다.
이제 반대로 순수 html 버전을 보겠습니다.
아마 위 링크를 들어가서 확인해 보시면 아시겠지만 한 화면에 담기도 벅차고 스타일 코드들과 수많은 태그들이 병렬적으로 나열되어 있습니다. html5 버전에는 component 기능을 제공하지만 모듈화 및 데이터 관리 측면에서 매우 효율성이 떨어져서 불가피한 이유가 아니면 거의 사용하고 있지 않습니다.
같은 결과물을 만든 이 두 개의 코드만 비교해 봐도 모던 프레임워크와 리액트가 어떤 역할을 하는지 대략 이해하셨을 것이라 생각합니다.
6. 과제
첫 번째 에피소드 과제는 디테일한 문법에 대한 공부 없이 일단 react.js에 친숙해지는 것이 목표였습니다. 그래서 첫 번째 과제는 아래 라이브러리들의 공식 문서 링크들을 통해 리액트의 컴포넌트들이 props를 어떻게 활용하는지 살펴보는 것입니다.
1. MUI
mui는 대표적인 react의 UI library이며 이름에서 알다시피 google의 material design을 기반으로 만들어졌습니다. mui의 공식문서에는 각 컴포넌트들이 props에 의해서 어떻게 작동하고 스타일링을 하는지를 자세하게 보여주고 있습니다. 아래는 버튼에 해당되는 링크인데 다른 컴포넌트들도 살펴보실 것을 권장합니다.
https://mui.com/material-ui/react-button/
2. Carbon Design System
Carbon design system은 IBM의 수많은 클라우드 서비스를 위해 만들어진 디자인 시스템입니다. 아래는 CDS의 공식 스토리북 링크입니다. 스토리북은 나중에 다시 설명드리겠지만 디자인 시스템 구성요소를 제품의 개발과정과 독립적으로 관리하기 위한 UI 관리 라이브로입니다. 아래 링크에 들어가시면 모든 컴포넌트들의 스펙과 props를 직접 조절하면서 어떻게 바뀌는지를 확인하실 수 있습니다.
https://react.carbondesignsystem.com/
3. Mantine UI
Mantine UI는 제가 가장 많이 사용하는 UI 라이브러리입니다. 유용성, 확장성 측면에서 좋지만 처음 배울 때 러닝커브가 높다는 단점이 있습니다. mantine UI 공식문서에서는 Layout 쪽 섹션을 한번 유심히 보시는 것을 추천합니다.
https://mantine.dev/core/grid/
7. 마치며
부탁 하나만 드리겠습니다. 제말을 믿으셔도 됩니다. react.js의 문법이나 개발에 대한 막연한 두려움은 곧 시간이 해결해 줄 것입니다. 다만 제일 중요한 건 애초에 디자인을 하는 방식에서 위 두 가지 데이터(variant, variable)를 관리하는 습관과 이를 개발자가 알기 쉽게 가이드를 작성하는 능력이 오히려 모던 프레임웍을 배우는데 더 결정적으로 작용할 겁니다.
그래서 이 챌린지를 진행하는 동안 막연하게 개발에 대한 지식을 배운다는 생각보다는 여태까지 UI 디자인과 피그마 파일을 관리했던 습관들을 같이 업그레이드한다는 생각이 더 도움이 될 것이라 생각합니다.
첫 번째 에피소드를 제가 생각하는 디자인 - 개발과의 관계, 그리고 모던프레임워크의 역할과 react의 간단한 특징을 직접 보여드렸습니다. 다음 에피소드에서는 더 자세한 리액트의 개념과 코드를 읽는 방법을 알려드리겠습니다.
반복해서 얘기하지만 무엇이 필요한지 인지하고 이를 구성하는 능력은 디자인과 개발에서 모두 중요하거든요. 이러한 과정은 next designer가 되기 위해 필연적이라고 생각합니다. 첫 번째 에피소드 제목 '더 이상 개발이 스펙이 아닌 이유'가 의미하는 바입니다.
다음 에피소드에서는 본격적으로 react.js의 오리엔테이션을 갖겠습니다.
Data Driven Design 공식 홈페이지: http://dddesign.io
dddd의 스레드: https://www.threads.net/@dddesign.io
