개발자와 소통이 쉬워지는 ‘기획자용 리액트(React) 핵심 용어 가이드’
개발자와 소통이 쉬워지는 ‘기획자용 리액트(React) 핵심 용어 가이드’
어느덧 리액트는 웹 개발의 표준이 되었습니다.
저 역시 얼마 전 리액트 프로젝트를 마쳤는데요. 기획자에게 중요한 건 기능의 본질이라 믿으면서도, 개발 회의만 들어가면 쏟아지는 낯선 용어들에 작아지곤 했습니다.
“스테이트”, “컴포넌트”... 외계어 같은 말들 사이에서 눈동자가 로딩 아이콘처럼 빙글빙글 돌았던 적 없으신가요? 용어를 몰라 소통의 주도권을 뺏기면, 공들인 기획도 결국 “가능한 만큼만”으로 타협하게 됩니다.
우리가 만든 서비스가 어떤 원리로 돌아가는지 아는 것만으로도 협업의 질이 달라집니다. 코드를 몰라도 기획의 자부심을 지킬 수 있도록, 소통 효율을 200% 높여줄 ‘기획자용 리액트 핵심 용어’를 쉽고 빠르게 정리해 드립니다.
핵심 요약 (30초 컷)
- 컴포넌트: UI를 조립하는 부품 단위(재사용의 핵심)
- State/Props: 화면을 바꾸는 데이터(변하는 값 vs 전달되는 값)
- 가상 DOM: 바뀐 부분만 빠르게 업데이트하는 방식
- 렌더링: 데이터 변화가 화면에 반영되는 과정(리렌더링 조건이 중요)
- SPA: 새로고침 없이 화면 일부만 바꿔 끼우는 구조(SEO/초기 로딩 고려)
1. 리액트(React)란 무엇인가?
리액트(React)는 페이스북(Meta)에서 만든 사용자 인터페이스(UI)를 만들기 위한 자바스크립트 라이브러리입니다. 핵심은 화면을 “레고 블록”처럼 조각(컴포넌트)으로 나누어 조립하는 방식이라는 점입니다.
기획자 관점에서는 이렇게 이해하면 충분합니다: “화면의 재사용성과 변경 효율을 극대화하기 위한 구조(방식)”. 즉, 버튼 하나도 ‘한 번 만들고 여러 곳에서 재사용’할 수 있게 설계합니다.
기획자가 React를 알면 바로 좋아지는 것
- “이 기능, 공통 컴포넌트로 빼면 되겠네요” 같은 대화가 가능해짐
- 상태(State) 변경 조건을 기획 단계에서 정리해 성능/버그 리스크 감소
- SPA 전환, 초기 로딩, SEO 같은 제품 지표 이슈를 미리 논의 가능
2. 기획자가 꼭 알아야 할 핵심 용어 5가지
① 컴포넌트(Component)
정의: UI를 이루는 독립적인 최소 단위(부품)입니다.
기획자 시점: 버튼, 입력창, 네비게이션 바, 카드 리스트 등을 각각의 ‘부품’으로 보는 것입니다.
기획서에 이렇게 쓰면 개발이 빨라집니다
- “이 버튼은 A/B/C 화면에서 동일한 형태로 재사용됩니다(라벨만 변경).”
- “이 카드 컴포넌트는 썸네일/제목/뱃지 조합만 바뀝니다.”
한 줄 실무 멘트: “이 요소는 공통 컴포넌트로 분리해서 재사용 가능한 구조로 가면 좋겠어요.”
② 스테이트(State) & 프롭스(Props)
State: 컴포넌트 내부에서 변하는 데이터 (예: 입력창 타이핑 중인 글자, 체크박스 선택 여부, 모달 열림/닫힘).
Props: 부모 컴포넌트가 자식에게 전달하는 외부 데이터 (예: 버튼 라벨, 리스트 아이템 데이터, 권한/플래그 값).
기획자에게 진짜 중요한 포인트: “무엇이 변하나?”
- 사용자 액션(클릭/스크롤/입력)으로 무엇이 바뀌는가?
- 서버 응답(조회/저장/에러)으로 무엇이 바뀌는가?
- 상태 변경 시 화면이 어떻게 달라져야 하는가?
한 줄 실무 멘트: “이 버튼을 누르면 이 값(State)이 바뀌고, 그 결과로 이 영역이 리렌더링돼야 해요.”
③ 가상 DOM(Virtual DOM)
정의: 실제 화면(DOM)을 직접 다 바꾸지 않고, 변경점을 “가상의 화면”에서 먼저 계산한 뒤 필요한 부분만 업데이트하는 방식입니다.
기획자 시점: 리액트가 ‘왜 빠르게 느껴지는지’의 배경입니다. 화면 전체가 아니라 바뀐 부분만 갱신하니 UX가 매끄럽습니다.
성능 이슈가 생기는 전형적인 구간
- 리스트가 너무 길 때(무한 스크롤, 수백~수천 개 항목)
- State 변경이 너무 잦을 때(입력 시 실시간 계산/필터링)
④ 렌더링(Rendering)
정의: 코드와 데이터가 실제 눈에 보이는 화면으로 그려지는 과정입니다.
기획자 시점: “언제 화면이 다시 그려져야 하는가(리렌더링 조건)”를 기획 단계에서 정리하면 성능 이슈와 예외 케이스가 줄어듭니다.
기획서 체크리스트(렌더링 관점)
- 로딩: 최초 진입, 탭 전환, 필터 변경 시 로딩 UI가 필요한가?
- 에러: 실패 시 토스트/다이얼로그/리트라이 버튼은?
- 빈 화면: 데이터 0건일 때 문구/가이드/CTA는?
한 줄 실무 멘트: “이 상태 값이 바뀔 때만 리렌더링되도록, 조건을 명확히 잡아주세요.”
⑤ SPA(Single Page Application)
정의: 페이지 이동 시 전체를 새로고침하지 않고 필요한 부분만 갈아 끼우는 방식입니다.
기획자 시점: 앱처럼 부드러운 전환(UX)을 줄 수 있지만, 초기 로딩과 SEO(검색 노출) 전략을 함께 봐야 합니다.
SPA 기획에서 자주 놓치는 포인트
- 뒤로 가기/앞으로 가기 동작(브라우저 히스토리) 기대치
- 딥링크(특정 화면 URL 공유) 시 초기 상태 복원
- 검색 노출이 KPI라면 SSR/SSG 여부를 초기부터 합의
3. 개발 협업을 위한 실무 팁
1) 일관된 UI 규칙을 “컴포넌트 기준”으로 합의하기
리액트는 재사용성을 중시합니다. 기획 단계에서 디자인 시스템(Design System)을 잡아두면 개발 속도가 비약적으로 빨라집니다.
- 버튼 종류: Primary/Secondary/Disabled/Loading 상태 정의
- 입력폼: 에러 메시지 규칙(언제, 어디에, 어떤 문구로)
- 리스트/카드: 썸네일 유무, 뱃지 규칙, 말줄임 기준
2) “화면”보다 “데이터 흐름(State 흐름)”을 먼저 그리기
“이 화면은 이렇게 보이면 돼요”만으로는 부족합니다. “어떤 데이터가 언제 바뀌고, 그 결과로 무엇이 렌더링되는지”까지 잡히면 협업이 매끈해집니다.
- 조회: 진입 시 자동 호출? 사용자 액션 호출?
- 저장: optimistic UI 필요? 저장 완료 후 어디 업데이트?
- 권한/조건: 특정 사용자에게만 노출되는 UI는?
3) 회의에서 바로 써먹는 ‘기획자 문장 템플릿’
- “이 영역은 공통 컴포넌트로 재사용될 가능성이 커요(다른 화면에서도 동일 패턴).”
- “이 액션 이후 바뀌는 State는 A, B 두 가지고, 화면 영향 범위는 여기까지예요.”
- “빈 화면/에러/로딩 3종 세트 상태를 먼저 정의해 두면 QA가 빨라집니다.”
- “SEO가 중요한 화면이라 SSR/SSG 같은 렌더링 방식도 함께 고려해 주세요.”
4. 자주 묻는 질문 (FAQ)
Q 기획자도 리액트 코드를 읽을 줄 알아야 하나요?
A 코드를 직접 작성할 필요는 없습니다. 하지만 컴포넌트 구조와 데이터(State/Props) 흐름을 이해하면 기획서의 논리적 결함(상태 변경 조건 누락, 재사용 요소 중복, 예외 케이스 누락)을 크게 줄일 수 있습니다.
Q 리액트로 만들면 SEO(검색 노출)에 불리하다는데 사실인가요?
A 과거엔 CSR 중심 SPA에서 SEO 이슈가 자주 있었지만, 지금은 Next.js 같은 기술(SSR/SSG)로 충분히 극복 가능합니다. 기획 단계에서 “검색 노출이 KPI인가?”를 먼저 정하고, 해당 화면은 렌더링 방식을 개발자와 초기 합의하는 것이 핵심입니다.
Q 컴포넌트를 너무 작게 쪼개면 안 좋나요?
A 너무 과하면 관리가 힘들 수 있습니다. 기준은 간단합니다: 재사용 가능성과 변경 단위. 여러 화면에서 반복되거나, 바뀌는 이유가 명확히 다르면 분리하는 편이 유지보수에 유리합니다.
글을 마치며
리액트 용어를 이해하는 건 “개발자의 언어로 대화하려는 노력”의 시작입니다. 기획자가 컴포넌트, 스테이트, 렌더링 같은 개념을 알면 회의가 이렇게 바뀝니다: 추측(감) → 조건(정의) → 합의(결정).
오늘 정리한 기획자용 React 핵심 용어가 여러분의 협업 속도를 올리고, 불필요한 핑퐁을 줄이는 데 도움이 되길 바랍니다. 🚀