HTML5 기반의 웹 어플리케이션 사용 사례가 늘어나면서, 자연스럽게 SPA 기술에 대한 관심도 늘어나고 있습니다. SPA의 시초는 Angular 였지만, 지금은 React와 Vue가 시장을 양분하고 있습니다. React를 대체하고자 하는 경쟁 라이브러리들이 하나 둘씩 등장하고 있긴 하지만, 아직 React는 왕좌의 자리에서 내려올 생각이 없어 보입니다.
저는 React를 주로 개발하는 사람입니다. 그런데 어느날, React가 무엇인지 제대로 이해하고 있는 사람은 생각보다 많지 않다는 것을 깨닫게 되었습니다. 제 주변에도 React 를 한다는 사람이 여럿 있었지만 리액트가 정확히 어떤 기술인지에 대해서 물어보면, 대부분 "UI Framework" "jquery 다음 세대" 이런 추상적인 얘기만 하면서 얼버무리기만 할 뿐이었습니다.
그래서 저는 잠깐 시간을 내어서, React 가 무엇인지 소개를 하고자 합니다. 글은 길지 않습니다. 하지만 이 글을 읽고나면 당신은 React가 무엇인지 명확하게 알게 될 것입니다.
자 그럼 시작해보겠습니다.
딱 세줄로 요약하자면, 리액트는
입니다.
이 세 항목은, React 공식 홈페이지를 들어갔을때 제일 처음 나오는 소개 내용들과 동일하며, 3가지 항목이 무엇을 의미하는지만 정확히 알고 있으면 React에 대해서 최소 절반은 이해하고 있다고 봐도 무방합니다.
우리가 웹상에서 보는 화면은, HTML로 이루어져 있습니다. HTML 상에서 동적 기능을 제공하기 위해, Javascript를 사용하고 있고, CSS로 스타일링을 입힙니다. 브라우저는, 서버로부터 받은 HTML, Javascript, CSS를 읽은 다음, HTML 문서를 화면에 표시하고, CSS로 스타일링을 입히고, Javascript를 실행시켜주는 프로그램이라고 생각할 수 있습니다.
초창기의 웹은, 정적이었습니다. 즉 서버로부터 어떤 페이지를 내려 받으면, 그 페이지의 데이터가 바뀌는 일은 거의 없었습니다. 새로운 내용을 보려면 페이지를 이동하여야 했고, 이를 위해선 페이지 내의 Anchor 태그를 클릭하여서 새로운 URL로 페이지 전환을 하는 과정이 필요했습니다.
그러다가 구글이 Ajax 기술을 사용하여서 Gmail을 세상에 선보였습니다. Gmail을 접한 사람들은 화면 전환 없이도 페이지 내의 요소들이 업데이트 되는 신비함을 경험하게 되었습니다. 한번 화면을 연 다음, 특정 부분의 화면을 바꾸고 싶으면, Ajax 요청을 하여서 데이터를 받은 뒤, 이 데이터를 기반으로 해당 부분의 화면만 갱신하면 됐으니까요. 즉 "새로운 화면의 제공 = 페이지의 전환" 라는 공식이 깨지게 되었습니다.
웹 개발자의 관심사는, 자연스럽게, "DOM을 효율적으로 조작하는 방법" 으로 넘어갔습니다. 그리고 이 무렵 JQuery란게 등장하여 시장을 평정하였습니다. 마법같은 $ 와, $가 제공하는 풍부한 method들은, DOM 조작에 고통받던 개발자들을 해방시켜주었고, 이제 웹에서 화면 전환 없이 할수 있는 일들은 점점 많아졌습니다.
이렇게 Ajax와 JQuery를 사용하여서 Web page에 동적 기능이 추가되던 시기와 맞물려서, 서버사이드에서도 기술적 진보가 일어나게 됩니다. 기존에는 클라이언트가 요청할때 내려주어야 할 html 파일들을 서버에서 다 보관하고 있어야 했습니다. 그런데 이런 정적 html 파일을 내려주던 방식에서 벗어나서, html template 엔진을 사용하여, "데이터에 의해 동적으로 생성된 웹페이지"를 내려주는 기술이 유행하게 하게 됩니다. 가장 대중적으로 많이 쓰인 언어는 PHP, JSP, ASP 일 겁니다. 서버는 html이 아닌, template 파일을 보관하고 있다가, 클라이언트로부터 요청이 들어오면, 해당 요청에 맞는 데이터를 불러와서, template 내의 지정한 부분에 데이터를 입혀서 html파일로 만든다음, 클라이언트로 내려줍니다.
html template 엔진을 사용하여서 서버 사이드에서 동적 페이지를 생성하고, ajax, jquery를 사용하여 페이지 내에서 클라이언트 사이드에서 동적 기능을 추가하는 것은 한동안 보편적인 기술이 되었습니다.
그러다가 Angular 및 Ember, Backbone.js 와 같은 MVC 기반의 Javascript 프레임워크들이 등장하며, Single Page Application의 시대가 열리게 됩니다.
html template 와의 가장 큰 차이점은, Single Page Application은 한번 페이지를 받은 뒤 더 이상 페이지 이동을 하지 않는다는 것입니다. Frontend Routing library들을 통해, 마치 페이지가 바뀐 것 같은 효과를 주기 위해 브라우저 주소 창의 url을 바꿔주긴 하지만, 어디까지나 이 모든 것은 단일 페이지에서 일어나는 일이지, 새로운 페이지를 받는 것은 아닙니다.
그리고 이 뒤를 이어, 오로지 UI Rendering만 제공하는 라이브러리로써, React가 등장하게 되었습니다. 이전 세대 기술들과 차별되는 React만의 특징으로는, Virtual DOM, JSX 같은 것들이 있습니다. 이런 내용들은 React를 공부하다보면 자연스럽게 제일 처음 학습하게 되는 것이기 때문에 굳이 여기에선 언급하지 않을겁니다.
다만 한가지 확실히 해 두어야 할 것은, React는 html template 엔진이 아닌, javascript를 사용한 렌더링 기술이라는 것입니다. 따라서 이런 역사적인 맥락에서, “Javascript”를 기반으로 했다는 것이 React의 첫번째 특징으로 언급된 것입니다.
이 파트는, “Data를 선언하다"와 “컴포넌트” 이 두가지 중요한 단어를 담고 있습니다. 따라서 이 둘을 구분하여서 더 자세히 얘기를 해보도록 하겠습니다.
웹 프론트엔드는, 사용자에게 보여지는 UI를 그리는 것을 최종적인 목표로 하고 있습니다. 그리고 웹 페이지 내에 동적인 기능을 넣고자 한다면, javascript를 사용하여서 이벤트 핸들링과 DOM 조작을 하게 될 수밖에 없는데, 이를 구현하는 방법으로써 React는 Declarative 한 방법을 사용하고 있다는 것입니다.
선언형 (Declarative)의 반댓말은, 명령형 (Imperative) 입니다. 저는 이에 대해서 매우 잘 설명하고 있는 한 블로그의 글을 그대로 따라가면서, “선언형"이 무엇인지 설명을 하고자 합니다.
우리는 다음과 같은 동작을 하는 Web Application 예시를 만들려고 합니다
- 처음 화면을 열었을때는, “Show the Unicorn”라는 "파란색" 버튼이 보입니다
- 이 파란색 버튼을 클릭할 경우, “Are you sure”라는 "분홍색" 버튼으로 바뀝니다
- 이 분홍색 버튼을 클릭할 경우, 이제 버튼은 사라지고 유니콘이 보여지게 됩니다.
이러한 동작을 하는 Web Application을, Imperative 방식 으로 만들려면, 아래와 같이 코드를 작성해야 합니다
먼저, click 이벤트 핸들러를 추가하기 위해 button DOM 객체를 가져와야 합니다. 이를 위해서 querySelector api를 사용하였습니다. 그리고 버튼의 click 이벤트에, 각각의 동작에 대한 이벤트 리스너를 등록해야 합니다. 먼저 1번 동작 click listener를 등록합시다.
이때 1번 동작의 click listener에는,
- 버튼의 색깔을 "분홍색"으로 바꾸는 코드와,
- 버튼의 텍스트를 "Are you sure"로 바꾸는 코드와",
- 2번 동작의 click listener를 등록하는 코드와,
- 동시에 1번 동작의 click listener의 구독을 취소
하는 코드 를 넣어야 합니다
그리고 2번 동작의 click listener 에는,
- 버튼의 내용을 유니콘으로 바꾸는 코드
만 넣으면 됩니다.
이것이 바로 명령형으로 UI 를 작성하는 방식입니다. 각 이벤트 별로 어떤 작업을 할 지 이벤트 리스너 내에 UI 조작을 step by step으로 명령 하는 것이죠.
이번에는 같은 ui를 Declarative (선언형) 방식으로 만들어보겠습니다
useState는 React에서 상태를 선언하는 방법입니다. 이에 대한 자세한 설명은 지금 하지 않을 것이며, 지금은 그저 scene라는 상태 변수가 "button"이라는 초기값을 갖고 있고, setScene 이라는 함수를 통해 scene 상태의 값을 변경한다고만 알고 있으면 됩니다.
return 부분을 통해서 알 수 있듯이, 이 두번째 예시는 사실, JSX element를 리턴하는 하나의 큰 function 입니다. 블로그 저자는 설명의 간단함을 위해 이 두번째 예시 코드 전체를 function으로 감싸진 않은 것 같습니다. 하지만 우리는 두번째 예시가 하나의 큰 function 이라고 상상하고 있으면 됩니다.
이 function 내에서 정의된 scene이라는 상태 변수는, 3가지 값 (button, question, unicorn)을 가질 수 있습니다. 그리고 각각 상태에 따라서, 우리가 요구했던 동작에 해당하는 JSX Element를 return 하고 있습니다.
(사실 엄밀하게 말하자면, scene 상태는 아무 string 값을 가질 수 있지만, 현재는 코드 내에서 onClick 이벤트 핸들러 내에, button, question, unicorn 이 세가지 상태 값만 갖도록 코드가 작성되었기 때문에 3가지 값만 가진다고 얘기를 한 것입니다. 만약 scene 상태 변수가 가질 수 있는 값을 엄격하게 제한하고자 한다면, typescript의 도움을 빌리거나 혹은 setScene 를 호출하기 전에 validation 로직을 넣어야 할 것입니다)
Declarative UI 코드를 그림으로 표현할 경우, 아래와 같이 scene 이라는 상태 데이터가 UI 로 맵핑되는 것으로 도식화 할 수 있습니다
여기서 ? 는 무엇일까요?
바로 Rendering 을 의미합니다! 그리고 이것이 바로 React가 하는 일입니다
어디서 많이 본 그림 같지 않나요? 바로 학창시절 수학시간에 배운 function 과 아주 흡사한 그림입니다
즉 결론을 내자면, UI를 Declarative 하게 작성한다는 것은,
- 먼저 데이터를 정의하고
- 각 데이터의 상태에 따른 UI 맵핑 규칙 (렌더링 로직) 을 작성하는 것
임을 알 수 있습니다.
Imperative 방식과 차이가 느껴지시나요? Declarative 한 방식에 더 매력이 느껴지시나요? 그렇다면 당신은 React 를 좋아할 준비가 된 것입니다.
이제 여러분은 Declarative 한 방식으로 UI 렌더링 로직을 작성한다는 의미를 이해 하셨을 겁니다. 그런데 위의 예시는 설명을 위해 한개의 상태만 있다고 가정한 것이며, 사실 웹페이지는 엄청나게 많은 상태들이 UI로 표현된 것 이라고 볼 수 있습니다.
지금 이 gist 페이지만 해도
- 페이지 최상단 Header 영역
- 그 아래, 글 meta 정보 영역
- 글 본문 영역
- 글 댓글 영역
- Footer 영역
이렇게 나뉘고 있는데, 각 영역에 있는 각각의 요소는, 최소 한개 이상의 상태를 갖고 있는 UI 입니다. 예를들어, 지금 제가 작성중인 이 글의 상단 meta 정보 영역에는, 아래와 같은 버튼 모음들이 보이고 있는데요,
각각의 버튼별로, icon, children (text), 색상 과 같은 공통 상태를 갖고 있으며 특히 제일 우측 Star 버튼은, Star Count 와, 내가 Star를 했는지 안했는지 여부까지도 상태로 갖고 있습니다
이런 무수히 많은 UI 렌더링 로직을, 단일 파일에 작성하는 것은 매우 어리석은 일입니다. 우리는 본능적으로, UI 렌더링 로직을 재사용 할수 있게끔, Capsule 화를 하고싶어지는데, 이것이 바로 컴포넌트라고 말할 수 있습니다. 즉 컴포넌트는, UI 렌더링의 단위를 의미합니다.
컴포넌트는 UI 렌더링의 단위
앞에서 저는, Declarative UI란, Data를 UI로 Mapping 시키는 Rendering 규칙을 작성하는 것이라고 얘기를 하였습니다. 그리고 이제부터는 Rendering 규칙 및 이에 필요한 Data 및 결과물인 UI들을 묶어서, "컴포넌트" 라는 단위로 부르려고 합니다. 즉 그림으로 그리자면 아래와 같습니다.
자, 그럼 이번엔, Top down 방식을 사용하여서, 전체 페이지를 어떻게 컴포넌트로 구성할 수 있는지 이해해보도록 하겠습니다.
예를들어, 어떤 하나의 전체 페이지를 Rendering 하는 것을, Declarative 하게 표현하자면, 아래 그림처럼 생각해 볼 수 있습니다. 즉 페이지는, 페이지 내의 모든 데이터를, 전체 페이지 UI로 Mapping 을 시키는 하나의 큰 컴포넌트 (빨간색) 인 것입니다.
이때, 전체UI 의 일부인 UI[1] 은, 전체Data 의 일부인 Data[1] 만을 필요로 한다고 가정 해보겠습니다. 또한 UI[2] 는, Data[2] 만을 필요로 가정하겠습니다. 그러면 각각 Data[1] -> UI[1], Data[2] -> UI[2] 로 Mapping 관계 가 생기는데, 이 렌더링을 하나의 단위로 만들어서, Sub Component 화 할 수 있습니다. (초록색)
UI[1]은 하위 UI인 UI[1,1], UI[1,2]로 분해할 수 있으며, 각각에 대해서 Origin이 되는 Data[1,1], Data[1,2]가 있어야 합니다. 그리고 이러한 Mapping 관계를 컴포넌트를 만들면, Sub-Sub-Component 화 할 수 있습니다 (주황색)
이런식으로 어떤 Component에서 Data와 UI가 Mapping 되던 Rendering 로직을, Sub-Data와 Sub-UI에 대한 Sub-Rendering으로 분할한 다음, 해당 부분을 Sub-Component 화 하는 것을 반복하면, 아래 그림처럼 컴포넌트의 깊이가 깊어지면서, 결국에는, 쪼개질 수 없는 단위에서 최소 단위 컴포넌트가 만들어질 것입니다.
여기서 복잡한 Data, UI 및 Mapping Arrow 들을 다 제거하고 오로지 컴포넌트만 남긴다면 아래 그림처럼 표현이 되겠죠
즉, 선언형 (Declarative) UI로 전체 페이지의 UI를 작성하는 것은, 전체 페이지를 컴포넌트의 Hierarchy로 표현한다는 것과 같은 말이 되는 것입니다. 그렇기 때문에, 컴포넌트는 React의 중요한 특징이 됩니다. React에서 제공하는 모든 기술들은 결국 컴포넌트 작성에 쓰인다고 봐도 무방합니다.
자 이제 마지막 특징입니다. 그런데 마지막 특징이라고 하기엔, 우리가 이미 앞서 렌더링이 무엇인지에 대해서 여러번 언급을 한 상황입니다. 따라서 이 문장의 의미를 이해하기 위해선, SPA (Single Page Application)을 제작함에 있어서, React가 "무엇을 제공하지 않는지" 를 생각해봐야 합니다.
Web Application을 제작하기 위해선, Rendering 기술 외에도
-
Frontend Routing 기술이 필요합니다. 유저가 실제로 보는 것은 단일 페이지이지만, 브라우저 주소 창의 URL과, 화면의 메인 영역 UI의 전환을 sync 시켜서, 마치 multi page를 보는 것처럼 유저가 착각하게 만드는 것입니다.
-
상태관리 기술이 필요합니다. Application을 제작하다 보면, 컴포넌트 내에서만 쓰이는 지역 데이터 외에도, 앱 전역적으로 쓰이는 글로벌 데이터에 대한 필요성도 생기게 됩니다. 또한 적당한 단위로 컴포넌트를 묶어서, 이 컴포넌트 안에서만 직접 접근하여 사용되는 데이터가 필요할 수도 있습니다. 이런 상태 데이터들을 선언, 접근하고 조작할 수 있게 해주는 기술이 상태관리 기술입니다. React는 context api, useState 같은 기본적인 기능들은 제공하고 있으나, 실 사용 application을 만들땐 Flux 아키텍쳐를 기반으로 한 좀더 강력한 라이브러리들을 종종 사용하게 됩니다 (Redux, Mobx, Recoil, Zustand, Jotai 등등..)
-
Design System 이 필요합니다. 프론트엔드 어플리케이션은, "예쁘게 동작하는 것"이 중요한 요소기 때문에, 어떻게 예쁜 앱을 디자인 할 것인지에 대한 체계가 반드시 필요합니다. 이를 위해서 처음부터 직접 css 를 작성하여서전체 application을 디자인 할 수도 있겠지만, 사람들이 많이 쓰는 UI design library를 import 한 뒤, 이 위에 custom style을 넣으면서 디자인 작업을 하는 방식도 많이 사용됩니다.
-
Ajax 기술이 필요합니다. 표준 Web Api 중의 하나인 Fetch를 사용할 수도 있지만, Axios 와 같은 라이브러리를 사용하여서, 좀더 풍부한 Ajax 기능을 사용하는 것이 더 일반적입니다.
-
각 어플리케이션의 용도별로 특화된 기술이 필요하기도 합니다. Canvas가 될 수도 있고, Grid가 될 수도 있고, WebSocket이 될 수도 있고, Animation이 될 수도 있고, 동영상 기술이 될 수도 있습니다.
등등, 하나의 Application으로써 동작하기 위해선 많은 부분들의 구현이 필요한데, React는 이런 것들에 대해서 관심이 없으며, 오로지 UI Rendering 에만 집중하겠다는 것이 바로 이 3번 특징입니다.
이것은 달리 말하자면, React는, React에서 정한 Rendering 규칙만 지킨다면, 어떤 방식으로 Application을 제작하든 상관이 없다는 것을 의미하며, 이는 React 개발자들에게 매우 높은 자유도를 선물해 주었습니다. 또한 React를 학습한다는 것은, Rendering 기술만 학습하면 되는 것이기 때문에, React의 Learning Curve 를 매우 낮게 만드는 요인이 되었으며, 이는 React 커뮤니티가 폭발적으로 성장하는 것에 매우 큰 기여를 하였습니다.
이런 React의 세번째 특징과 반대되는 것은 바로 Angular 입니다. Angular를 처음 접하는 사람들은, 공식 홈페이지에 있는 어마어마하게 많은 section 들을 보면서 그 높은 Learning Curve에 좌절하는 경우가 매우 많습니다. 물론 Web Application을 만들다 보면, 결국에는 저 많은 섹션에 해당하는 요소들을 Application 내에서 제공해야 하기 때문에, 오히려 Angular 처럼 사전에 약속한 방식을 쓰도록 제약을 하는 것이 더 편안하게 느껴질 때도 있습니다. 하지만 어쨌든 초심자 입장에서는, Hello world 혹은 간단한 Application 을 하나 만들기 위해서 고작 몇분이면 되는 React가, "어떻게 돌아가는지 이해"하기 위해서 며칠동안 문서만 들여다봐야 하는 Angular 보다, 더 반갑게 느껴질 수 밖에 없을겁니다.
다시 요약하자면, React는
입니다.
이 글이 React 가 무엇인지 궁금해하는 입문자들에게, 좋은 가이드 글이 되길 바랍니다.
감사합니다.
Good