React.js가 디자이너에게 의미하는바
개발하는 디자이너 챌린지 - 02
챌린지 소개
'개발하는 디자인 챌린지'는 스레드(threads)에서 모집한 10명의 디자이너 참가자들과 개발 스터디. 실습을 진행하기 위해 매주 1회 발행하는 교육자료로 쓰이는 글입니다. 이 챌린지는 자세한 문법을 처음부터 알려주는 방식이 아닌 디자인-개발 플로우의 연관성 및 기본 개념을 알려주고 과감히 바로 예제부터 시작하는 튜터링 방식을 취하고 있습니다.
0. 프롤로그
첫 번째 에피소드에서는 앞으로 디자이너가 개발을 배워야 하는 필연적인 이유와 이를 시작하기 위한 접근 방식을 다뤄봤습니다. 두 번째 에피소드에서는 리액트가 어떤 개발 언어인지 본격적으로 알아보려 합니다. 리액트가 등장하기 전후 상황을 비교해 보면서 UX.UI 디자이너들의 업무 프로세스에도 어떠한 영향을 끼치게 되었는지도 살펴보겠습니다.
마지막으로 리액트의 가장 핵심적인 개념과 문법, 그리고 이를 v0를 통해 간단하게 실습해 볼 수 있는 과제를 다뤄보도록 하겠습니다.
*참고로 원문에 react와 angular를 비교한 것은 프레임워크가 발전되는 과정을 설명하기 위함이며 두 프레임워크 모두 지속적으로 최신 버전이 업데이트되며 관리되고 있다는 점을 미리 설명드립니다.
1. 제시 제임스: 모던 프레임워크에 영감을 주었던 UX 선구자
모던 프레임워크의 탄생 뒤에는 UX 선구자의 공헌이 있었다는 사실을 알고 계셨나요?
이는 제시 제임스 가렛이라는 1세대 UX 디자이너의 이야기입니다. 그는 한때 웹 UX의 트렌드를 이끌었던 에이전시, Adaptive Path의 공동 창립자이자《The Elements of User Experience》라는 저서를 통해 현재까지 이어지는 UX 디자인 방법론의 기본을 제시한 UX 선구자 중 한 명입니다.
제시는 초기 웹이 한 페이지를 클릭할 때마다 새로고침이 이루어졌고, 사용자가 반복되는 긴 로딩 시간을 기다리는 것에 큰 문제의식을 갖고 있었습니다. 따라서 어떻게 하면 불필요한 새로고침과 데이터 로딩을 최소화할지 연구 끝에 웹 애플리케이션이 새롭게 작동하는 AJAX(Asynchronous JavaScript and XML)라는 개념을 제시합니다.
AJAX는 사용자가 페이지를 새로고침하지 않고도 필요한 데이터를 실시간으로 받아올 수 있게 해 주었으며, Gmail에서 새로운 이메일만 로드하는 방식이 대표적인 예입니다. 이렇게 모든 절차를 기다리지 않아도 독립된 기능을 작동할 수 있도록 시간을 분리하는 것을 '비동기(Asynchronous)'라고 합니다.
AJAX는 페이지가 서버에서 데이터를 받는 과정과 페이지를 렌더링 하는 과정을 비동기로 처리하는 개발 방식을 제시했다.하지만 AJAX는 완성된 개발 언어가 아니라 '개념'에 가까웠기 때문에, 개발자들은 이를 정리하고 구체화하려는 노력을 지속했습니다. 이러한 흐름은 url을 바꾸지 않고 페이지를 이동하는 방식, 이와 독립적으로 데이터를 통신하는 방식 그리고 사용자가 작동할 UI를 효율적으로 구성하는 방식을 고민하게 만들었고 결국 google의 Angular와 같은 프레임워크의 탄생으로 이어졌습니다.
2. 리액트 등장 직전의 모던 프레임워크 특징
AngularJS의 등장으로, 웹 개발은 처음으로 '앱'처럼 느껴지기 시작했습니다.
AngularJS의 주요 원칙 중 하나는 컴포넌트를 정의하고 이를 통해 뷰(html 마크업)와 컨트롤러(자바 스크립트)를 이원화 하는 방식이었습니다. 예를 들어, 컴퍼넌트의 외형은 뷰에서 관리하고, 어떻게 동작할지를 컨트롤러에서 제어하는 형식입니다.
따라서 모든 컴퍼넌트들에 View + Controller 형식의 템플렛을 적용하고 controller에서 선언한 주요 변수들을 View의 태그들과 결합하여 사용하는 식으로 동적인 웹을 구현했습니다. 그리고 사용자 인터랙션은 주로 하위 컴퍼넌트에서 이루어지므로 자식 컴퍼넌트가 부모 컴퍼넌트에게 데이터를 바로 보낼 수 있는 양방향 데이터 방식을 채택합니다.
그러나 이러한 방식은 프로젝트가 커질수록 다음과 같은 문제를 드러냈습니다
angular는 view에 해당하는 html & css와 controller에 해당되는 javascript를 한쌍의 모델로 관리한다. 데이터 처리 방식의 일관성 문제 - 부모와 자식 컴포넌트 간에 자유롭게 데이터를 주고받을 수 있는 양방향의 자유도가 오히려 데이터가 변경되었을 때 어떤 컴포넌트가 영향을 받는지 추적하기 힘든 문제가 발생했습니다. 이 말은 데이터를 처리하는 주체가 되는 컴퍼넌트가 여기저기 흩어져서 서비스의 덩치가 커졌을때 관리하기 힘들다는걸 의미합니다.
원치 않는 컴포넌트 간의 종속성 증가 - 위의 특징으로 인해 개발자가 예상치 못하게 각 컴퍼넌트들의 원치 않는 의존성을 부여하는 경우가 발생했습니다. 예를들면 특정 컴퍼넌트의 조합이 반복해서 사용될 가능성을 염두 못한채 너무 구체적인 데이터 흐름을 미리 정해버리면, 이 템플렛은 한가지 상황에서 밖에 사용하지 못한다는 뜻입니다. 이게 반복되면 적절한 재사용성과 서비스 규모의 균형을 깨트립니다.
렌더링 성능 문제: DOM(브라우저가 html을 렌더링 하는 공간) 변경이 많아질수록 속도가 느려졌습니다. 특히 데이터가대규모 애플리케이션에서 두드러졌으며, URL이 바뀌지 않는 SPA(Single Page Application)의 특징은 유지하지만 결국 페이지 전체를 렌더링 하게 되는 성능 문제로 이어집니다.
React는 2세대 프레임워크로 이러한 문제를 개선하기 위해 등장했습니다. UI를 보다 독립적인 컴포넌트들을 독립적으로 관리할 수 있게 했고, 가상 DOM을 사용해 렌더링 성능을 크게 향상했습니다. 예를 들어, Facebook 뉴스피드에서 새로운 콘텐츠가 즉시 업데이트되는 방식은 React의 효율성을 잘 보여줍니다. 마지막으로 React의 핵심은 데이터를 한 방향으로만 관리하여(큰 컴포넌트 -> 작은 컴포넌트), 데이터 로직을 한 곳에서 일관성 있게 관리하는 방식을 유도한다는 특징이 있습니다.
3. Facebook은 왜 리액트를 만들었을까?: 리택트의 특징과 철학
현 시점에서 돌이켜보면 페이스북은 소셜 미디어 뿐만 아니라 대부분의 어플리케이션의 프로토타입을 제시했다고 봐도 과언이 아닙니다. 왜냐면 왠만한 서비스들이 다량의 컨텐츠와 유저들의 인터랙션을 피드라는 형태의 UX 패턴으로 관리하고 있기 때문이죠.
페이스북은 최단기간안에 1억 MAU를 기록한 서비스이기도 합니다. 당시 실시간으로 업데이트되는 컨텐츠와 유저들의 인터랙션의 수가 기하급수적으로 늘어나는 상황에서 개발 프로세스를 개선할 필요성을 절실히 느꼈습니다. 페이스북이 react.js를 개발하기 전에는 Jquery와 같은 이미 렌더링이 완료된 html요소들을 조작하는 방식의 javascript를 활용하고 있었습니다.
이방식은 1화에서 언급했던 재활용성과 퍼포먼스 측면 둘다 안좋았고, 그렇다고 이미 나와있는 Angular를 사용하기에는 서비스의 규모가 너무 커서 더 일괄된 방식의 데이터 방식이 필요했죠. 실제로 react의 창시자 Jordan Walke는 철저하게 UI 컴퍼넌트 기반과 단방향 데이터 흐름의 조합이 우리 서비스에 필요했고 angular는 우리 철학과 맞지 않았다고 한 인터뷰에서 밝혔습니다.
이러한 배경지식을 고려했을때 Airbnb의 디자인 시스템에 큰 공헌을한 Jon Gold라는 디자이너가 Facebook출신이라는건 놀라울일도 아입니다. 어째든 facebook은 당시 혁신적인 방식으로 새로운 언어를 오픈소스로 공개합니다.
HTML과 JavaScript를 한 파일에 작성한다고?
리액트의 컴포넌트들이 작성되는 JSX는 처음 등장했을때 파격적인 방식에 의아함을 자아냈지만, 곧 많은 개발자들에게 생산성을 인정받으며 머지않아 개발 커뮤니티에서 큰 인기를 얻게 됩니다.
앵귤러에서 마크업과 스크립트를 철저하게 분리했다면 react에서는 모든 것을 데이터와 객체, 함수로 바라보는 관점으로 한 개의 파일에서 데이터와 UI를 유연하게 관리하는 걸 추구합니다.
React의 핵심 특징은 다음과 같습니다:
컴포넌트 기반 개발: 모든 UI를 작은 단위로 나누어 독립적으로 관리할 수 있습니다. 이는 AngularJS에서도 제공된 개념이지만, React는 이를 더욱 단순화하고 독립적으로 유지할 수 있도록 개선했습니다. 예를 들어, Angular에서는 컴포넌트의 로직과 템플릿이 분리되었으나, React에서는 JSX를 통해 이를 하나의 파일로 통합하여 개발자가 더 유연하게 작업할 수 있습니다.
가상 DOM: 브라우저의 실제 DOM을 조작하기 전에 가상 DOM에서 변경사항을 계산하여 브라우저에 필요한 부분만 업데이트합니다. 이는 전체 페이지를 새로고침하지 않고도 빠른 업데이트가 가능하게 합니다. AngularJS의 양방향 데이터 바인딩과 비교했을 때, React의 가상 DOM은 성능과 효율성 면에서 큰 차별화를 이루었습니다.
JSX와 선언적 프로그래밍: JSX는 JavaScript와 HTML을 혼합한 형태로, 컴포넌트를 함수처럼 다룰 수 있게 합니다. 이를 통해 개발자는 UI를 "어떻게" 만들지 보다 "무엇"을 보여줄지에 집중할 수 있습니다. 즉 복잡하게 작동하는 커다란 컴포넌트를 지양하고, 결국 간단하지만 "무엇"을 하는지 명확한 컴포넌트들을 계속 재활용하여 더 큰 문제를 다루는 방식을 지향합니다. 이는 제가 1화에서 매우 강조했던 디자이너와 개발자 공통으로 갖춰야 할 문제해결 능력과도 매우 유사합니다.
위의 핵심특징들을 반영한 react의 핵심 개념들이 있습니다.
props - 이전 에피소드에서 언급했지만 props는 컴포넌트가 상위 컴포넌트로 받을 데이터를 얘기합니다. Properties의 약자로 props를 받는 컴포넌트의 특징 및 기능을 정의하는 역할을 합니다. 위에서 선언적 프로그래밍이라고 얘기했듯이 props의 키값과 데이터명은 꼭 '무엇'을 하는지가 반영이 돼야 합니다. 그리고 props에는 단순한 변수 외에 다른 컴포넌트 및 함수 또한 전달될 수 있습니다. 예를 들어 Container라는 layout역할의 컴포넌트에 Card라는 컴포넌트를 props로 받을 수 있습니다.
states - props가 부모 컴포넌트로부터 받은 고유한 특징이라면 states(상태)는 해당 컴포넌트 내부에서 처리해야 할 데이터를 말합니다. props가 아닌 state를 쓰는 이유는 해당 컴포넌트 내부에서만 데이터를 처리할 경우가 필요하기 때문입니다. 혹은 props로 받은 데이터를 다시 가공하거나 이를 조건부로 다른 데이터를 생성할 때 필요합니다.
예를 들어 헬스장의 회원관리 앱에서 신규 회원의 이름과 나이를 입력하는 자식 컴포넌트에게 data는 props로 작동하지만 이를 관리하고 서버에 보내는 부모 컴포넌트는 이를 state로 관리해야 합니다.
context - context는 맥락이라는 뜻이죠. 말 그대로 모든 컴포넌트가 공통적으로 알고 있으면 좋을 맥락, 데이터들의 집합을 context라고 합니다. 예를 들어 웹서비스의 유저정보는 어디서든 자주 사용되므로 모든 컴포넌트에 props를 계속 내려주기가 귀찮으니 context로 접근할 수 있도록 하는 걸 권장합니다.
context는 항상 필요한 건 아니지만 알아두면 좋은 개념입니다. 만약 여러분이 내 개인 포트폴리오 사이트를 만든다라고 하면 필요하지 않을 수 있고, 웹 서비스 성격의 사이트를 만들면 활용도가 높아집니다.
리액트의 위와 같은 특징들은 규모가 커진 스타트업들이
4. 필요한 만큼 빠르게 학습하기
공식 문서에서 위에 언급한 props와 state는 꼭 정독해 보실 것을 권장합니다.
이전 에피소드에서 언급했지만 저는 모든 문법과 개념을 완벽하게 설명하고 예제를 만드는 학습 방식이 아닌, react.js를 왜 쓰는지와 최소한의 개념만 알고 바로 예제를 통해 배우는 방식을 시도하고 있습니다. 이러한 방향성안에서 react.js를 필요한 만큼 빨리 배우기 위한 몇 가지 팁을 드립니다. 일단 다음 툴을 사용해 보세요.
V0 - V0는 온라인에서 프롬프트로 웹 프로젝트를 생성해 주는 서비스입니다. 원래대로라면 각자 로컬환경에서 node.js 설치 및 프로젝트를 직접 설정해야 하는 수고스러움이 있지만 이 과정을 생략하고 일단 react.js의 문법과 작동 방식을 먼저 배우는데 집중할 수 있습니다. 코드의 퀄리티에는 차이가 있겠지만 비교적 모호한 프롬프트를 작성해도 일단 동작하는 react.js 웹사이트를 생성하고 이를 예제로 학습하기 좋습니다.
chat gpt - 이미 사용하고 계시겠지만 v0로 생성한 코드를 리뷰해 주거나 혹은 내 의도대로 작동하지 않는다면 왜 그런지 어떻게 수정해야 되는지를 물어볼 수 있습니다. 간단한 문법의 개념을 예제 코드와 함께 물어보는데도 효과적입니다.
claude - claude 역시 chat gpt와 유사한 목적으로 사용할 수 있지만 artifact라는 기능을 통해 간단한 개념을 예시 코드와 함께 실시간으로 배울 수 있습니다. 위의 회원 관리 사이트 예제 또한 claude로 작성한 것으로 이 링크를 통해 확인 가능합니다.
react.js 공식 문서 - 그럼에도 불구하고 리액트 공식문서를 읽어보실 것을 강조합니다. 이는 새로운 언어를 볼 때 사전을 참고하는 것과 같습니다. 기본적인 개념부터 간단한 예제와 함께하는 문법 상세 설명까지. 결국 자세하고 정확하게 알기 위해 가장 먼저 참고해야 할 것은 공식문서입니다.
리액트는 사용자 커뮤니티가 오래된 만큼 다른 언어에 비해 공식 문서가 쉽고 잘 정리된 편입니다. props와 state는 꼭 읽어보세요5. 리액트의 등장이 디자이너 업무에 끼친 영향
React의 등장은 팀 전체가 일하는 방식에도 큰 영향을 주었습니다.
컴포넌트 기반 아키텍처와 일관적인 데이터 처리 방식은 자연스럽게 디자인과 개발 간의 협업의 혁신을 요구하는 환경조성을 하게 되었습니다. Airbnb는 React 기반의 디자인 시스템을 도입하여 디자이너와 개발자가 동일한 컴포넌트를 공유하며 작업하는 대표적인 사례입니다. 이를 통해 팀은 일관된 UI와 빠른 개발 주기를 유지할 수 있었습니다.
Figma와 같은 도구도 이러한 변화의 중심에 있습니다. 디자이너들은 컴포넌트의 속성(Property)과 상태(State)를 정의하고 관리해야 하는 중요성을 인지하게 되었습니다. Figma에서는 컴포넌트와 properties와 variable을 통해 React의 props와 state 개념을 미리 정의할 수 있습니다. 예를 들어, 버튼의 색상 변화를 props로 정의하거나, 토글 상태를 관리하는 컴포넌트는 state와 유사한 방식으로 작동합니다.
제가 1화에서부터 의도적으로 리액트의 개념과 피그마의 기능을 반복해서 설명하는 이유는 개발자들 혼자 컴포넌트 구성을 설계하고 props를 설정할 수 없다는 걸 강조하기 위하입니다. 결국 디자인 가이드에서 선행해서 정의된 속성들이 그대로 react.js 프로젝트를 구성하는데 중요한 단서로 활용됩니다. 이러한 의사결정의 흐름을 이해한 상태에서 react.js를 접근해야 합니다.
6. Code connect: Figma와 React.js의 호환성 살펴보기
2024년 config에서 figma는 한층 업그레이드된 dev모드와 code connect 기능을 선보였습니다. 하지만 불행하게도 상당히 많은 프로덕트 팀들이 이 기능을 제대로 사용하고 있지 못합니다. 위에서 언급한 properties와 variable을 사용하지 않거나 혹은 잘못된 방식으로 적용한 figma파일은 실제로 활용하기 힘든 코드를 생성하기 때문이죠.
이미지 출처: uxdesign이런 상황에서는 code connect가 마땅히 가져야 할 패턴들이 무시된 채 덕지덕지 구성된 코드를 만들기 때문입니다. 개발자 입장에서는 차라리 디자인을 보고 본인이 임의로 해석한 걸 개발에 옮기게 됩니다. 이러한 방식이 앞으로 더 큰 문제가 될 소지가 높은 이유는 AI기반의 코드 전환 플러그인들의 해택을 받기 힘들기 때문입니다.
code connect에 연동할 수 있는 AI 코드 전환 플러그인들은 앞으로 성능이 계속 좋아지고 있습니다. 즉 피그마에서 가이드만 제대로 작성한다면 이미 프로젝트의 코드는 자동으로 생성될 환경이 곧 있으면 다가올 것이란 얘기죠. 단순히 디자이너의 러닝 커브 때문에 무조건 빠르게 만들 수 있는 디자인을 택한다면 팀 전체로 봤을 때 이게 결코 빠르지 않을 수 있습니다.
물론 아직까지는 완벽한 가이드를 짠다고 해도 100% 코드 전환을 자동화할 수 있는 상황은 아닙니다. 그리고 완벽한 가이드를 짜려는 시도 또한 팀의 적정 속도를 조절하는데 실패로 이어질 수 있습니다. 다만 디자이너가 react.js를 배우는 이유와 목적성을 실제 코드와 최대한 싱크 되는 방식으로 디자인을 하는 안목과 스킬을 갖추는 것에 맞춰야 할 것입니다.
아래는 제가 사용해 본 code connect 플러그인과 특징을 정리한 것입니다.
Figma To Code - code connect에서 가장 기본적으로 사용할 수 있는 플러그인입니다. 쉽고 빠르게 사용할 수 있지만 디자인 토큰 및 코드 모듈화 기능은 약한다. 만약 코드로 옮기고자 하는 디자인이 간단한 렌딩 페이지나, 광고 캠페인의 상세 페이지라면 빠르게 사용해 볼 만하다. (무료)
figma to code를 사용하여 react코드를 생성하면 인라인 하드코딩 스타일을 사용한다.Anima - Anima는 코드 전환 플러그인을 제공하기 훨씬 전부터 sketch, figma와 같은 UI 툴에 반응형 레이아웃 기능을 플러그인으로 제공했던 서비스입니다. 최근 5년 사이 fimga에서 dev 모드 기능을 강조하면서 점차 코드 전환 기능을 고도화하여 제공하고 있으며 컴포넌트의 반응형 코드도 어느 정도 유추해서 만들어 준다는 장점이 있습니다. (유료)
Locofy.ai - locofy는 체계적인 디자인 시스템을 코드로 옮길 때 유연한 플러그인입니다. code connect와 연결된 베타 버전은 무료로 사용할 수 있지만 다소 모듈화의 정확도는 낮은 편입니다. 하지만 유료 버전을 사용하면 fimga에 사용된 외부 라이브러리나 직접 구성한 디자인 시스템을 상당히 정확하게 이해하여 체계적인 코드로 바꿔줍니다. (부분 무료)
locafy는 스타일링 방식을 직접 선택할 수 있고 css variables 옵션을 선택하면 figma의 variable을 그대로 사용할 수 있다.7. 과제: V0로 살펴보는 빠른 예제
과제 중점사항
이번주는 과제는 V0로 직접 예제를 만들어보는 것입니다. 일단 과제의 목적은 코드가 정확하지 않더라도 위에서 언급한 개념들과 문법을 직접 확인해 보는 것입니다. 위에서 설명했듯이 V0는 프롬프트로 시작해서 코드를 생성. 수정하고 중간에 직접 코드를 수정하는 것도 가능하기 때문에 학습 목적으로 최고의 서비스라고 생각합니다.
다만 무료버전에서 하루에 사용할 수 있는 프롬프트 수가 제한되어 있기 때문에 이 부분을 염두하셔야 합니다. 다만 프롬프트를 다 사용 시에도 직접 코드를 바꿔서 테스트해 볼 수 있으니 기본 골격을 프롬프트 도움으로 잡고 이후 작업을 혼자 해보는 방식의 실습을 추천해 드립니다.
과제 예시
과제는 만들고 싶은 게 있다면 자유주제지만 혹시라도 정하기 힘든 분들을 위해 제가 만든 예시를 설명드리겠습니다. 저는 "All About Whiskey(링크)"라는 위스키 인프그래픽 웹사이트를 만들어보았습니다. 이렇게 선정한 이유는
본인이 관심 있는 주제
API 연동 없이 직접 조사한 데이터로 컴포넌트를 구성할 수 있는 예제
사실 위 과정도 chat gpt나 다른 LLM의 도움을 받을 수 있는 주제.
단일 항목에서 표현할 정보들이 많은 것. 위스키의 경우, 증류소 위치, 테이스팅 노트, 사용한 오크통 등 다양한 정보들이 담겨있습니다.
V0의 결과물은 완벽하진 않지만 기본 UX.UI의 골격을 잡고 후작업으로 이어가기에 좋다. 위 예시 경우 프롬프트에서 요구한 실제 이미지 url을 갖고 오는 데는 실패했다.프롬프트 작성 요령
제가 사용한 프롬프트는 첨부한 링크의 대화에서 확인할 수 있고 내용이 길기 때문에 글의 마지막에도 첨부하겠습니다. 프롬프트를 작성할 때 다음 조건을 명시하면 더욱 명확한 결과물을 얻을 수 있습니다. 그리고 한글로 프롬프트 작성이 가능하지만 저는 가능하면 영어로 적는 편입니다. (미세하지만 LLM이 작성된 언어로 작성하는 것이 퀄리티에 좋은 영향을 줄 수 있습니다.)
전반적인 주제와 사이트의 목적 설명
개발환경: React.js의 javascript버전으로 만들어달라고 하세요. (아닌 경우 typescript로 작성될 수 있으며 이게 어떻게 다른지는 지금 당장 알필요는 없습니다.)
PRD, 스타일, 데이터 항목을 나눠서 설명
PRD: 저 같은 경우는 유저들에게 위스키를 흥미롭게 보여줄 수 있는 인포그래픽 웹사이트를 만들 것이며 1페이지 반응형, 그리고 맵 섹션, 위스키 리스트 섹션, 테이스팅 노트 섹션의 내용을 나눠서 설명했습니다.
스타일: 사이트의 전반적인 비주얼 톤을 설명하기 위해 전통적인 위스키 메뉴의 색과 질감을 사용해 달라고 했습니다. 그러나 제가 기대했던 느낌은 나지 않네요. 이런 경우 프롬프트로 수정을 요청하거나 직접 고쳐야 합니다.
데이터: 어떻게 보면 가장 중요하 부분으로 꼭 들어가야 할 데이터 항목과 데이터의 샘플 수를 적어주었습니다. 프롬프트는 LLM 모델이 과도하게 사용되는 것을 방지하기 위해서 간혹 이 요구를 한 번에 다 들어주지 않는데 이럴 경우 재차 요구해야 합니다. 그리고 실제 존재하는 이미지 url도 요구했지만 이건 V0의 능력을 벗어나는 것 같네요.
마지막으로 데이터를 처리할 때 root component(최상위 컴포넌트 대부분 App.jsx가 해당됩니다)에서 자식 컴포넌트들에게 넘겨주는 방식으로 코드를 작성하라고 지시했습니다. 이는 데이터 처리를 한 곳에서 일괄적으로 하기 위함입니다.
각자 주제 및 과제 생각하기
제가 위에서 시도한 예제의 구조는 다양한 주제로 변형이 가능하다고 생각합니다. 와인, 커피와 같은 다른 음료, 주류도 가능하며 혹은 영화나 소설처럼 작가, 등장인물, 배경 등 다양한 데이터를 다룰 수 있는 소제로도 전환이 가능합니다. 꼭 위의 포맷을 따를 필요는 없지만 당장 시도해 볼 예제가 생각이 나지 않은 경우는 이 포맷을 참고해 보시면 좋을 듯합니다.
8. 마치며
이번 에피소드에서는 react.js가 웹 서비스 개발 프로세스 전반에 미친 영향을 간략한 역사와 함께 알아보았습니다. 이 흐름을 이해해야 하는 이유는 개발을 단순히 디자이너의 자기 계발 차원에서 배우는 것이 아니기 때문입니다. 1세대 UX 디자이너의 고민이 현재 프레임워크 발전에 영향을 끼쳤듯이 react.js는 단순히 개발 스펙만의 문제는 아니라는 점을 다시 강조합니다. 그리고 자세한 문법의 해설보다는 빠르게 실습할 수 있는 예제를 v0로 시작해 보는 과제를 공유해 봤습니다. 다음 주는 이번주 과제를 수정 및 발전시켜 보면서 자연스럽게 맞이하는 시행착오를 자세히 들여다보는 내용을 다루겠습니다.
Data Driven Design 공식 홈페이지: http://dddesign.io
dddd의 스레드: https://www.threads.net/@dddesign.io
