콘텐츠로 이동

React

웹 에디터를 만들 때 화면 전체를 통째로 다시 그리면, 사용자가 텍스트를 칠 때마다 페이지가 깜빡이며 기다림이 생겨요. 노션처럼 블록을 잇고, 캔버스처럼 노드를 옮기는 화면은 상태가 끊임없이 바뀌는 데다 그 상태가 곧 사용자가 눈앞에서 만지는 물건이라, 렌더링이 느리면 그대로 불편함으로 드러나죠. React는 컴포넌트 단위로 화면을 쪼개고, 상태가 바뀐 부분만 다시 그리는 라이브러리예요. 상태가 수시로 변하는 에디터 UI에서 이런 재렌더링 컨트롤이 몹시 중요해서, 데이터스케쳐스 프론트엔드의 기준도 React로 잡혀 있어요.

기술 하이라이트 / 핵심 개념

  • 컴포넌트 모델 — 화면을 작은 조각(컴포넌트)으로 나눠 조립합니다. 블록 하나, 캔버스 노드 하나, 협업 커서 하나가 각각 컴포넌트로 살아 있죠. 같은 조각을 여러 곳에서 재사용할 수 있고, 각 조각이 자기 화면만 책임집니다.
  • 선언적 UI — "어떻게 그릴지" 단계를 일일이 짜지 않고 "지금 상태가 이렇다"만 선언하면, React가 그 상태에 맞는 화면을 그려줘요. 화면을 바꾸는 방법이 아니라 화면이 어때야 하는지를 코드로 적는 셈이죠. 아래 코드를 보면 텍스트가 바뀌는 걸 직접 그리는 게 아니라 상태에 따라 화면이 "그렇게 보여야 한다"고만 선언하는 게 느껴져요.
function Node({ title }: { title: string }) {
  // title이 바뀌면 이 컴포넌트만 다시 그려진다.
  return <div className="node">{title}</div>;
}
  • 재렌더링 — 상태(props·state)가 바뀌면 관련 컴포넌트만 다시 그립니다. 에디터처럼 상태가 자주 바뀌는 화면에서 이 부분을 컨트롤하는 게 성능의 핵심이에요. 값이 변하지 않은 컴포넌트는 다시 그리지 않도록 최적화하기도 하죠.
  • 가상 DOM — 실제 DOM 대신 가상 표현을 먼저 비교하고, 달라진 곳만 실제 DOM에 반영해요. 화면 전체를 무턱대고 고치는 대신 바뀐 부분만 정확히 업데이트하는 구조예요.
  • 상태 관리와의 결합 — React 자체도 상태를 다루지만, 에디터처럼 여러 컴포넌트가 같은 문서 상태를 공유할 때는 Zustand 같은 전역 상태 라이브러리와 묶어 씁니다. 화면 하나하나의 로컬 상태는 React가, 문서 전체의 공유 상태는 store가 맡는 식이죠.

사용 사례 / 실제 적용

  • D-SKET Canvas — React + Vite 에디터. 캔버스 노드를 그리고, dnd-kit으로 옮기고, 실시간 협업 커서를 그리는 데 React가 중심이에요. 상태는 Zustand가, 스타일은 Tailwind가 나눠 맡습니다.
  • D-SKET Webbuilder — Next.js + React + Tailwind + TypeScript + Three.js 조합. 노션 콘텐츠와 템플릿을 뿌리는 렌더링을 React가 담당해요.

웹빌더의 Next.js는 React 기반의 풀스택 프레임워크고, 캔버스는 Vite로 빌드하는 순수 React 클라이언트예요. 같은 React 생태계라도 역할에 따라 프레임워크를 달리 쓰는 셈이죠. 화면이 서버에서 미리 그려져야 할 필요(SEO·SSR)가 있으면 Next.js 계열로, 클라이언트 중심의 무거운 에디터 인터랙션이면 Vite 계열로 갈라집니다.

에디터 같은 인터랙티브 화면에서 React를 쓰는 요즘 흐름을 보면, 외국 사례에서도 비슷한 선택이 이어져요. 텍스트 에디터로 유명한 Notion은 React 기반으로 블록 단위 문서 에디터를 만들었고, Figma는 브라우저에서 캔버스 협업과 실시간 다중 커서를 구현해 데스크톱 앱을 압도했죠. 우리가 React 계열을 기준으로 두는 것도, 이런 에디터 경쟁에서 화면 갱신 속도와 개발 속도를 동시에 잡기 위해서예요.

각 제품이 실제로 어떻게 돌아가는지는 Webbuilder와 Canvas 페이지에서 이어집니다.

더 알아보기