"리액트 엔진은 데이터가 삭제되면 DOM 노드를 즉시 파괴(Unmount)하려 하지만, 애니메이션 라이브러리는 key를 앵커로 삼아 '언마운트를 지연(Defer Unmounting)'시키고 애니메이션이 끝난 뒤에 비로소 DOM을 정리합니다."

리스트에서 아이템을 삭제하거나 팝업 모달을 닫을 때 스르륵 사라지는 퇴장 효과(Exit Animation)를 구현하기 위해 Framer Motion의 <AnimatePresence>를 많이 사용합니다.

그런데 <motion.div>에 exit={{ opacity: 0 }} 속성을 아무리 완벽하게 정의해 두어도, 고유한 key를 부여하지 않으면 퇴장 애니메이션이 완전히 씹히고 화면에서 툭 꺼지듯이 사라지는 현상을 겪게 됩니다.

도대체 리액트의 렌더링 파이프라인과 Framer Motion 내부에서 어떤 일이 일어나기에 key가 없으면 Exit 애니메이션이 불가능한 것인지, 그 상호작용 원리를 심층 분석합니다.

1. 근본적인 딜레마: 리액트의 "즉각 삭제" vs 애니메이션의 "시간차(Latency)"

Exit 애니메이션을 구현할 때 가장 큰 기술적 장벽은 리액트 가상 DOM과 브라우저 DOM의 라이프사이클 차이입니다.

[일반적인 리액트 조건부 렌더링]

1. 상태 변경: isVisible = false (또는 리스트에서 item 삭제)

2. 재조정(Reconciliation): "이 노드는 트리에서 제외되었음" 판정

3. 커밋(Commit) 단계: 브라우저 DOM에서 해당 노드를 '즉시 물리적으로 제거(Unmount)' ➔ ⚠️ 결과: 0.3초 동안 서서히 투명해질 시간적 여유가 전혀 없음!

사용자가 보고 즐길 수 있는 페이드아웃(Fade-out) 효과가 발생하려면, 상태는 이미 false가 되었더라도 실제 DOM 노드는 화면에 0.3초~0.5초 동안 살아남아 있어야 합니다.

<AnimatePresence>는 리액트의 '즉각 언마운트' 동작을 중간에서 가로채(Intercept) 퇴장 애니메이션이 완료될 때까지 컴포넌트의 수명을 인위적으로 연장합니다.

2. AnimatePresence의 핵심 메커니즘: 언마운트 지연(Deferred Unmount)

Framer Motion의 <AnimatePresence>는 내부적으로 직전 렌더링의 자식 요소(prevChildren)와 현재 렌더링의 자식 요소(currentChildren)를 key를 기준으로 비교·추적합니다.

[AnimatePresence의 내부 처리 흐름]

1. 이전 렌더링: Children 목록 ➔ [ Key: 'item-1', Key: 'item-2' ]

2. 삭제 발생: Children 목록 ➔ [ Key: 'item-2' ]

3. AnimatePresence의 비교:

   • "어? 'item-1'이라는 Key를 가진 자식이 이번 렌더 트리에서 사라졌네?"

   • "리액트가 바로 DOM을 지우지 못하도록 'item-1' 노드를 메모리(PresenceContext)에 복제·유지하자!"

4. Exit 애니메이션 실행:

   • 'item-1' 컴포넌트에 isPresent: false 플래그 전달 ➔ exit={{ opacity: 0 }} 실행 (0.3초 소요)

5. 최종 언마운트:

   • 애니메이션 완료 이벤트(onAnimationComplete) 수신 ➔ 비로소 실제 DOM에서 노드 완전 제거

❖ key가 반드시 필요한 이유:

• 사라진 엔터티 식별: 부모의 렌더 함수가 실행되었을 때, "어떤 구체적인 컴포넌트가 사라지는 중인가?"를 식별할 수 있는 유일한 기준이 바로 key입니다.
• 인스턴스 캐싱: AnimatePresence는 사라진 key의 DOM 노드와 스타일 상태를 캐싱하여 화면에 일시적으로 렌더링을 지속시킵니다.

key가 없으면 AnimatePresence는 어떤 요소가 삭제 대기 상태(Exiting)인지 추적할 수 없으므로 지연 메커니즘 자체가 발동하지 않습니다.

3. 코드 검증: key 유무에 따른 동작 차이

① 모달 / 토글 컴포넌트의 조건부 렌더링

import { motion, AnimatePresence } from 'framer-motion';

// ✅ 올바른 패턴: AnimatePresence 직계 자식에 고유 key 할당
function AlertModal({ isOpen, message }) {
  return (
    <AnimatePresence>
      {isOpen && (
        <motion.div
          key="alert-modal" // 💡 고유 Key 필수!
          initial={{ opacity: 0, y: -20 }}
          animate={{ opacity: 1, y: 0 }}
          exit={{ opacity: 0, y: -20 }}
          transition={{ duration: 0.3 }}
        >
          <p>{message}</p>
        </motion.div>
      )}
    </AnimatePresence>
  );
}

• key="alert-modal"이 있는 경우: isOpen이 false가 되어도 AnimatePresence가 해당 키를 감지하고 0.3초간 위로 올라가며 투명해진 뒤 사라집니다.

• key를 생략한 경우: isOpen이 false가 되는 즉시 리액트가 DOM을 날려버려 퇴장 애니메이션이 0초 만에 끊기고 즉시 사라집니다.

② 동적 리스트 아이템 삭제 (Todo List)

// ❌ 안티 패턴: key={index}를 사용한 리스트 애니메이션
<AnimatePresence>
  {todos.map((todo, index) => (
    <motion.li
      key={index} // ⚠️ 인덱스를 키로 사용
      initial={{ opacity: 0, x: -50 }}
      animate={{ opacity: 1, x: 0 }}
      exit={{ opacity: 0, x: 50 }}
    >
      {todo.text}
    </motion.li>
  ))}
</AnimatePresence>

key={index} 사용 시 발생하는 치명적 시각 결함

1. 사용자가 3개 항목(A: 0, B: 1, C: 2) 중 첫 번째 'A'를 삭제함.

2. 배열이 재정렬되면서 B가 인덱스 0번, C가 인덱스 1번이 됨.

3. AnimatePresence는 key=0, key=1은 여전히 존재하고, "마지막 key=2가 삭제되었다"고 오판함.

4. [참사 발생]: 사용자는 A를 지웠는데, 화면에서는 맨 밑의 C가 페이드아웃되고 A는 순식간에 사라진 뒤 B가 A 자리로 튕겨 올라가는 끔찍한 UI 깨짐이 발생합니다.

  // ✅ 올바른 패턴: 불변 고유 ID(todo.id)를 Key로 바인딩
<AnimatePresence>
  {todos.map((todo) => (
    <motion.li
      key={todo.id} // 💡 불변하는 고유 ID 바인딩
      initial={{ opacity: 0, x: -50 }}
      animate={{ opacity: 1, x: 0 }}
      exit={{ opacity: 0, x: 50 }}
    >
      {todo.text}
    </motion.li>
  ))}
</AnimatePresence>

불변 고유 ID를 부여해야만 정확히 삭제된 'A' 노드에만 exit 트랜지션이 적용되고, 나머지 아이템들은 자연스럽게 layout 애니메이션으로 빈자리를 채웁니다.

  // ✅ React Router 페이지 전환 애니메이션 패턴
function AnimatedRoutes() {
  const location = useLocation();

  return (
    <AnimatePresence mode="wait">
      {/* 💡 pathname을 key로 주어 라우트가 바뀔 때마다 이전 페이지 언마운트를 지연시킴 */}
      <Routes key="{location.pathname}" location="{location}">
        <Route element="{<Home" path="/"/>} />
        <Route element="{<About" path="/about"/>} />
      </Routes>
    </AnimatePresence>
  );
}

• 동작 원리: URL 경로(location.pathname)가 바뀌면 Routes의 key가 변경됩니다.

• AnimatePresence는 이전 pathname 컴포넌트의 exit 애니메이션이 끝날 때까지 화면에 유지하고, mode="wait" 옵션에 따라 이전 페이지가 완전히 퇴장한 뒤 새 페이지를 마운트합니다.

애니메이션 라이브러리 관점의 Key 비교 요약

📚 References

• Framer Motion Official Docs - AnimatePresence & Exit Animations
• React Official Documentation - Preserving and Resetting State
• Framer Motion Guide - Component Keys and Presence Context

"AI 시대를 완벽하게 활용하기 위해 반드시 알아야 할 12가지 핵심 개념을 한눈에 정리합니다. 복잡한 기술 용어도 비유와 예시를 통해 한 번에 이해할 수 있습니다."

유튜브 채널 '혼잡스'의 모르면 따라가기 힘든 Ai 용어정리 12개 딱 한장으로 끝! (바이브코딩 지도 2부) 영상을 바탕으로, 바이브 코딩과 AI 서비스 구축 시 필수로 알아야 하는 12가지 AI 핵심 용어를 체계적으로 정리한 블로그 포스팅입니다.

1. AI의 기본 두뇌와 감각

• 1. LLM (Large Language Model, 대형 언어 모델)
  • 무수한 문장과 데이터를 읽고 학습한 기본 두뇌 역할을 합니다. (예: ChatGPT, Claude, Gemini)
• 2. 멀티모달 (Multimodal)
  • 글로만 소통하던 LLM에 눈과 귀(시각·청각 감각)를 달아준 것입니다.
  • 이미지, 소리, 영상 등 다양한 형태의 입력을 이해할 수 있게 도와줍니다.

2. AI 예절 교육과 맞춤형 학습

• 3. RLHF (Reinforcement Learning from Human Feedback, 인간 피드백 기반 강화학습)
  • 사람이 직접 점수를 매기고 평가하여 AI가 친절하고 안전하게 답하도록 세팅하는 AI 예절 교육 과정입니다.
• 4. 파인튜닝 (Fine-Tuning)
  • 범용적으로 일 잘하는 AI 신입 사원에게 우리 회사의 내부 자료를 잔뜩 안겨주어 우리 팀 맞춤형 전문가로 재학습시키는 과정입니다.

3. 명령 기술과 문서 창고 시스템

• 5. 프롬프트 엔지니어링 (Prompt Engineering)
  • AI에게 원하는 최상의 결과물이 나오도록 지시문(Prompt)을 효과적으로 설계하고 작성하는 기술입니다.
• 6. 지식 베이스 (Knowledge Base)
  • AI가 거짓말(할루시네이션)을 하지 않도록 회사 규정, 매뉴얼, 회의록을 모아둔 문서 데이터 창고입니다.
• 7. RAG (Retrieval-Augmented Generation, 검색 증강 생성)
  • 질문을 받았을 때 무작정 답을 지어내는 것이 아니라, 지식 베이스 창고에서 정확한 문서를 찾아서 검증된 근거로 답변하게 만들어 주는 장치입니다.

파인튜닝이 AI의 '뇌' 자체를 바꾸는 과정이라면, RAG는 AI의 뇌는 그대로 둔 채 '문서 창고'에서 직접 찾아서 답하게 만드는 방식입니다.

4. 도구 연결과 자율적 업무 수행

• 8. MCP (Model Context Protocol)
  • AI가 구글 캘린더, 이메일, 데이터베이스 등 다양한 외부 도구와 쉽게 연결될 수 있도록 이어주는 멀티플러그 어댑터(연결 표준 규격)입니다.
• 9. 에이전트 (Agent)
  • 단순 질문에 답하는 수준을 넘어, 목표를 설정해 주면 스스로 추론하고 계획을 세워 외부 도구를 활용해 업무를 완수하는 자율형 AI입니다.
• 10. 워크플로우 자동화 (Workflow Automation)
  • AI 에이전트를 공장의 컨베이어 벨트에 배치하듯, 매일 반복되는 복잡한 업무 프로세스를 자동으로 연쇄 실행되도록 만든 시스템입니다.

5. 통제 장치와 미래의 AI

• 11. 하네스 (Harness)
  • 아무리 똑똑해도 야생마처럼 통제 불능이 될 수 있는 AI를 원하는 방향으로 부르고 제어하기 위한 마구/통제 시스템입니다.
• 12. AGI / ASI (범용 인공지능 / 초인공지능)
  • AGI: 영업, 회계, 개발 등 모든 영역에서 사람처럼 일할 수 있는 만능 범용 인공지능 (현재 지향하는 목표 stage)
  • ASI: 모든 면에서 인간의 지능을 뛰어넘는 상상 속의 초인공지능

아무리 뛰어난 AI 모델이라도 하네스(Harness)와 MCP 시스템을 얼마나 정교하게 짜느냐에 따라 실제 비즈니스 결과물의 성패가 갈립니다.

💡 AI 핵심 용어 12가지 한눈에 보기

📚 References

• 유튜브 영상 - 모르면 따라가기 힘든 Ai 용어정리 12개 딱 한장으로 끝! (바이브코딩 지도 2부)

"개발자를 고용하거나 외주를 주지 않고도, 클로드 코드(Claude Code)와 Supabase, Vercel 조합만 알면 혼자서 완벽한 웹서비스를 배포할 수 있습니다."

AI 시대가 도래하면서 손으로 일일이 코드를 짜지 않고 AI와 대화하며 개발하는 바이브 코딩(Vibe Coding)이 큰 주목을 받고 있습니다. 하지만 터미널, VS Code, Git 등 복잡한 초기 환경 세팅 때문에 입문 과정에서 포기하는 경우가 많습니다.

본 글에서는 복잡한 기존 방식을 벗어나, 단 한 장의 지도로 바이브 코딩의 도구 세팅부터 프론트엔드·백엔드 연결, 최종 배포까지의 전 과정을 정리합니다.

1. 바이브 코딩 필수 개념 & 도구 세팅

과거에는 터미널(Terminal) 창을 열어 복잡한 명령어 형태로 프로그램을 설치하고, VS Code 편집기와 Git을 일일이 연동해야 했습니다. 하지만 최근에는 단독 실행이 가능한 현대적인 신식 도구들이 등장하면서 세팅 과정이 대폭 단순화되었습니다.

• LLM (대형 언어 모델): Claude, ChatGPT, Gemini 등 무수한 데이터를 학습한 두뇌 역할
• 코딩 에이전트 (Coding Agent): LLM과 연결되어 실제로 코드를 작성하고 실행하는 손과 발 역할 (예: Claude Code PC 버전, Cursor AI)

🛠️ 3분만에 끝내는 기본 환경 세팅

1. Claude Code PC 버전 설치
   • 구글에 Claude Code를 검색하여 공식 다운로드 페이지 접속 후 설치 파일을 실행합니다.
   • 실행 후 로그인 및 좌측 상단의 [Code] 탭을 선택합니다. (대화 창 안에서 코드 작성, 실행 과정, 결과물 미리보기까지 한 번에 처리됨)
2. Git (버전 관리 저장소) 설치
   • 코드가 변경될 때마다 이전으로 되돌리거나 저장하는 세이브 파일 역할을 합니다.
   • git-scm.com에 접속하여 설치 프로그램을 받되, 모든 옵션은 기본값(Default)으로 두고 완료합니다.
3. GitHub (클라우드 저장소) 연동
   • 내 컴퓨터에 저장된 Git 기록을 인터넷 참고/창고에 올리는 서비스입니다.
   • GitHub 가입 후 Claude Code 대화창 옆 + 버튼 ➔ Connect ➔ GitHub를 선택해 계정을 인증합니다.

Claude Code와 GitHub를 연결해 두면, "GitHub에 올려줘"라는 한 마디로 작업 시점의 코드가 웹 저장소에 자동으로 보관됩니다.

2. 프론트엔드(Front-end) 구축: 눈에 보이는 화면 만들기

웹사이트는 크게 눈에 보이는 화면인 프론트엔드(시계의 판과 바늘)와 뒤에서 데이터를 처리하는 백엔드(시계 내부 태엽)로 나뉩니다.

프론트엔드 개발 시 HTML, CSS, JavaScript나 React, Flutter 같은 밀키트형 프레임워크를 다 외울 필요가 없습니다. 만들고자 하는 프로젝트의 규모를 Claude Code에게 전달하는 것이 핵심입니다.

• 규모에 맞는 기술 스택 제안 요청:
  • 소규모 서비스/단일 페이지인데 과도하게 큰 스택을 쓰거나, 반대로 트래픽이 몰릴 서비스에 너무 가벼운 스택을 쓰면 추후 사이트가 다운될 수 있습니다.
  • 프롬프트 예시: *"단일 페이지 소개 사이트를 만들어줘. 서비스 규모에 적합한 언어와 기술 스택을 먼저 제안해줘."*

3. 백엔드(Back-end) 구축: Supabase로 매니저 고용하기

회원가입, 게시판, 데이터 저장 등 화면 뒤에서 일어나는 비즈니스 로직을 처리하려면 서버와 데이터베이스(DB)가 필수적입니다. 과거에는 AWS 등에서 서버를 빌리고 DB 프로그램을 직접 설치하는 등 진입장벽이 매우 높았으나, 이를 한 번에 해결해 주는 매니저 서비스가 있습니다.

• Supabase (서버 & 데이터 담당 매니저): 서버 구축, 데이터베이스 테이블 생성, 회원가입 인증을 알아서 처리해 주는 BaaS 서비스

🗄️ Supabase 데이터베이스 연결 흐름

1. supabase.com에 접속하여 GitHub 계정으로 가입 후 New Project를 생성합니다.
2. 프로젝트 생성 시 발급되는 Project URL과 공개용 API Key(열쇠) 두 가지를 복사합니다.
3. Claude Code에게 두 정보를 제공하며 요청합니다.
   • 프롬프트 예시: *"지금 만든 사이트에 이 Supabase 프로젝트(URL, API Key)를 연결해주고, 필요한 데이터 테이블을 생성하는 SQL 문을 짜줘."*
4. Claude Code가 제공한 SQL 문을 Supabase의 SQL Editor에 붙여넣고 Run을 누르면 데이터베이스 구축이 완료됩니다.

Supabase를 연결하면 웹사이트에서 입력한 데이터가 실제 웹 서버 데이터베이스 표에 즉시 기록되는 백엔드 시스템이 완성됩니다.

4. 최종 웹 배포: Vercel로 전 세계에 사이트 공개하기

내 컴퓨터에서만 작동하던 웹사이트를 전 세계 누구나 접속할 수 있도록 인터넷에 올리는 과정을 배포(Deployment)라고 합니다.

• Vercel (배포 담당 매니저): GitHub 저장소와 연동하여 자동으로 웹에 올리고 도메인을 생성해 주는 무료 배포 플랫폼

🚀 Vercel 자동 배포 3단계

1. vercel.com에 접속하여 Continue with GitHub로 가입 및 로그인합니다.
2. Add New ➔ Project를 누른 뒤, 아까 Claude Code로 작업해 올린 GitHub 저장소(Repository)를 선택(Import)하고 Deploy 버튼을 클릭합니다.
3. 배포가 완료되면 전 세계 누구나 접속할 수 있는 인터넷 주소(URL)가 생성됩니다.

이후 Claude Code로 코드를 수정해 GitHub에 올릴 때마다, Vercel 배포 매니저가 이를 감지하여 최신 버전으로 자동 업데이트해 줍니다.

💡 핵심 요약 비교표

🏁 결론

바이브 코딩의 전체 구조는 다음 3단계로 요약할 수 있습니다.

1. 도구 세팅: Claude Code + Git/GitHub 연동
2. 프론트엔드: 서비스 규모에 맞게 AI에게 스택 제안을 받아 개발
3. 백엔드 & 배포: 데이터 관리는 Supabase, 최종 배포 및 관리는 Vercel에 위임

이 세 가지 매니저 도구 조합만 이해하면 코딩을 몰라도 혼자서 구동 가능한 완전한 웹 서비스를 빠르게 완성할 수 있습니다.

"key는 배열 렌더링 전용 속성이 아닙니다. 리액트에서 '컴포넌트 인스턴스의 생명주기를 강제로 재시작하고 State를 초기화하는 선언적 트리거'입니다."

웹 애플리케이션을 개발하다 보면 사용자 ID가 바뀌거나 선택된 모달 데이터가 변경될 때, 컴포넌트 내부의 입력 폼(State)이나 로컬 상태를 깨끗하게 비워야 하는 상황을 자주 마주합니다.

이때 대부분의 주니어 개발자들은 습관적으로 useEffect를 선언하고 setFormData(initialState)를 호출해 수동으로 상태를 리셋하곤 합니다. 하지만 이는 불필요한 렌더링 플리커(Flicker)와 동기화 버그를 유발하는 명령형 안티 패턴입니다.

React 공식 문서에서도 적극 권장하는 key 프로퍼티를 활용한 선언적 State 초기화 패턴의 원리와 실무 적용법을 심층적으로 살펴봅니다.

1. 흔히 저지르는 안티 패턴: useEffect로 상태 수동 동기화

사용자가 프로필 목록에서 다른 유저를 클릭해 상세 폼(ProfileForm)을 열람하는 상황을 가정해 보겠습니다.

// ❌ 비효율적이고 위험한 패턴: useEffect를 통한 상태 리셋
function ProfileForm({ user }) {
  const [comment, setComment] = useState('');

  // ⚠️ Props(user.id) 변경을 감지하고 상태를 수동으로 비움
  useEffect(() => {
    setComment('');
  }, [user.id]);

  return (
    <div>
      <h3>{user.name}의 한 줄 코멘트</h3>
      <textarea value={comment} onChange={(e) => setComment(e.target.value)} />
    </div>
  );
}

1 이 방식이 유발하는 3가지 문제점

1. 찰나의 화면 깜빡임 (Stale UI Flash):

   • 리액트는 먼저 이전 유저의 comment 상태를 유지한 채 새 유저 이름으로 화면을 1회 렌더링합니다.
   • 브라우저에 Paint가 끝난 뒤 useEffect가 실행되고 나서야 setComment('')로 인해 2번째 리렌더링이 발생합니다. 사용자 눈에는 이전 데이터가 순간적으로 스쳐 지나가는 깜빡임(Flash)이 노출됩니다.

2. 불필요한 렌더 트리 낭비:

   • 단 한 번의 데이터 변경에 컴포넌트가 2번씩 렌더링되므로 불필요한 연산 및 성능 낭비가 발생합니다.

3. 상태 누락 위험 (휴먼 에러):

   • 폼 내부에 관리할 State(input, checkbox, file, validation 등)가 늘어날 때마다 useEffect 내부에 리셋 로직을 일일이 수동으로 추가해야 하므로 상태 초기화가 누락되는 버그가 발생하기 쉽습니다.

2. 해결책: 단일 컴포넌트에 key를 부여하는 역발상

리액트의 재조정(Reconciliation) 엔진은 형제 노드뿐만 아니라 단일 컴포넌트에서도 key를 기준으로 인스턴스의 유지 여부를 판단합니다.

// ✅ 선언적이고 완벽한 베스트 프랙티스: 부모에서 key에 식별자를 전달
function ProfilePage({ user }) {
  return (
    <div>
      <h2>프로필 관리 대시보드</h2>
      {/* 💡 user.id가 변경되는 순간, 기존 인스턴스를 파괴하고 새 인스턴스를 마운트 */}
      <ProfileForm key="{user.id}" user="{user}"/>
    </div>
  );
}

function ProfileForm({ user }) {
  // useEffect가 전혀 필요 없음! 마운트 시 항상 깔끔한 초기값으로 시작
  const [comment, setComment] = useState('');

  return (
    <div>
      <h3>{user.name}의 한 줄 코멘트</h3>
      <textarea value={comment} onChange={(e) => setComment(e.target.value)} />
    </div>
  );
}

key 값을 변경하는 것만으로 리액트는 이전 컴포넌트의 Fiber 노드를 통째로 Unmount하고 새 State를 가진 인스턴스를 즉시 Mount합니다.

3. 리액트 내부 엔진 동작 비교 (Reconciliation & Fiber)

key가 변경될 때 리액트 내부에서 일어나는 과정을 도식화하면 다음과 같습니다.

[Case 1: useEffect 수동 초기화]

1. user.id 변경
2. 이전 State('이전 댓글')를 유지한 채 1차 Render & DOM Commit ➔ ⚠️ 이전 상태 잔류
3. 브라우저 Paint 완료 후 useEffect 실행 ➔ setComment('') 트리거
4. 2차 Render & DOM Commit ➔ 총 2회 렌더링 비용 발생

[Case 2: key={user.id} 변경 테크닉]

1. user.id 변경 ➔ key 값이 변경됨
2. 리액트 판단: "Key가 달라졌으니 완전히 다른 컴포넌트다!"
3. 기존 Fiber Node 및 DOM 완전 정리(Unmount) + 새 Fiber Node 생성(Mount)
4. State 초기화가 포함된 상태로 단 1회의 Clean Render & DOM Commit 완료 ($O(1)$)

❖ key 리셋 패턴의 3대 핵심 이점:

• 완벽한 선언적 코드 (Declarative): 상태를 어떻게 지울지(setX('')) 명령하지 않고, "유저가 바뀌면 새 폼이다"라고 선언합니다.
• 플리커 프리 (Zero Flicker): 단 1회의 렌더 패스 안에서 초기 상태가 결합되어 화면 깜빡임이 완전히 사라집니다.
• 하위 비제어 상태(Uncontrolled State) 및 스크롤까지 일괄 리셋: 컴포넌트가 새로 마운트되므로 DOM의 내부 포커스, 스크롤 위치, 에러 스타일까지 완벽히 초기화됩니다.

4. 실무에서 쓰이는 3가지 대표 시나리오

• ① 상세 보기 모달 / 사이드 드로어 (Detail Drawer):

  • 목록에서 여러 항목을 클릭해 상세 모달을 띄울 때, 이전 항목의 로딩 상태나 수정 중이던 텍스트가 남아있는 문제를 <DetailModal key={selectedItem.id} item={selectedItem} /> 한 줄로 완벽히 해결합니다.

• ② 다단계 설문조사 / 위저드 폼 (Wizard Form Step):

  • 다음 단계로 넘어갈 때 이전 스텝 컴포넌트를 재사용하면서 State가 꼬이는 현상을 <StepForm key={currentStep} step={currentStep} /> 형태로 깔끔하게 격리합니다.

• ③ 캔버스 / 차트 라이브러리 초기화:

  • Chart.js나 D3.js처럼 인스턴스 파괴(destroy()) 후 재구성이 까다로운 서드파티 라이브러리를 감싼 컴포넌트는 <ChartCanvas key={chartDataId} />를 통해 완벽한 라이프사이클 재시작을 유도할 수 있습니다.

💡 3가지 Key 안티패턴 및 올바른 해결책 비교

📚 References

• React Official Documentation - Why does React need keys?
• React Official Documentation - Rules of Keys
• Dan Abramov - Preserving and Resetting State in React

[Next.js] App Router 핵심 정리: Server Actions, formData, useFormState

Next.js의 App Router 환경에서 데이터를 주고받는 방식은 기존 리액트 방식과는 완전히 다릅니다. 핵심이 되는 세 가지 개념을 실제 코드 예시와 함께 정리합니다.

1. Server Actions (서버 액션)

"백엔드 로직을 프론트엔드 함수처럼 직접 호출하는 기술"

기존에는 데이터를 전송하기 위해 API 엔드포인트를 따로 만들었지만, 서버 액션은 함수 하나로 서버측 로직을 실행합니다.

• 구현: 함수 내부에 'use server' 지시어를 선언합니다.
• 장점: * API URL을 일일이 관리할 필요가 없습니다.
  • 민감한 DB 로직이 클라이언트에 노출되지 않아 보안에 강력합니다.
  • 자바스크립트가 로드되지 않은 환경에서도 HTML Form 표준에 따라 동작합니다.

2. formData (폼 데이터)

"폼에 담긴 모든 데이터를 한데 묶은 보따리"

서버 액션이 호출될 때 전달되는 인자로, 폼 내부의 모든 입력값을 가지고 있습니다.

• 자동 수집: 각 input 태그에 name 속성만 적어주면 제출 시점에 데이터를 자동으로 싹 긁어모읍니다.
• 데이터 추출: formData.get('name값') 메서드로 원하는 데이터를 꺼낼 수 있습니다.
• 💡 useRef와 차이점:
  • useRef (리모컨): 특정 입력창에 포커스를 주거나 직접 클릭을 발생시키는 등 '조작'이 목적입니다.
  • formData (보따리): 입력된 데이터들을 서버로 '전송'하기 위해 묶어주는 것이 목적입니다.

3. useFormState (폼 상태 관리)

"서버의 응답을 UI에 실시간으로 연결하는 통로"

서버 액션이 실행된 후, 서버에서 보내온 결과(성공/실패 메시지 등)를 클라이언트 화면에 보여주기 위해 사용하는 Hook입니다.

실제 구현 예시

// 1. 서버 액션 정의 (actions.js)
'use server';

export async function shareMeal(prevState, formData) {
  const title = formData.get('title');

  if (!title) {
    return { message: '제목을 입력해주세요!' }; // 에러 메시지 리턴
  }

  // DB 저장 로직 수행...
  return { message: '성공적으로 저장되었습니다.' };
}

// 2. 클라이언트 컴포넌트 (MealForm.js)
'use client';
import { useFormState } from 'react-dom';
import { shareMeal } from './actions';

export default function MealForm() {
  const [state, formAction] = useFormState(shareMeal, { message: null });

  return (
    <form action={formAction}>
      <input type="text" name="title" />
      {/* 서버에서 보낸 메시지가 state에 담겨 출력됨 */}
      {state.message && <p>{state.message}</p>}
      <button type="submit">제출</button>
    </form>
  );
}

4. revalidatePath: 데이터 최신화 (캐싱)

Next.js는 성능을 위해 페이지를 캐싱합니다. 데이터가 추가되었는데 화면이 바뀌지 않는다면 캐시 때문입니다.

• 역할: revalidatePath('/meals')를 호출하면 해당 경로의 기존 캐시를 버리고 새로운 데이터를 다시 가져오도록 명령합니다.

• 시점: 보통 서버 액션 안에서 DB 업데이트가 성공적으로 끝난 직후에 사용합니다.

5. 전체 데이터 흐름 요약

1. 사용자: 폼 작성 후 제출 클릭.

2. 클라이언트: 모든 데이터가 formData 보따리에 담김.

3. 서버: Server Action 실행, DB 작업 수행.

4. 서버: 작업 결과(메시지 등)를 반환하고 revalidatePath로 캐시 갱신.

5. 클라이언트: useFormState가 리턴받은 결과를 화면에 표시.

useEffect와 fetch 없이 서버에서 직접 데이터를 꺼내오는 현대적인 풀스택 로딩 전략을 분석함

키워드: Direct DB Access, RSC async/await, lib 폴더 구조, SQLite

1. 데이터 로딩 방식의 혁신

기존 리액트(CSR)는 브라우저가 API 서버를 호출하고 기다리는 복잡한 과정을 거쳤지만, Next.js 서버 컴포넌트는 서버 내부에서 DB에 직접 접근합니다.

2. DB 로직 분리 (lib/meals.js)

데이터베이스 연결과 쿼리 로직은 별도의 lib 폴더에서 관리하여 코드의 가독성과 재사용성을 높입니다.

import sql from 'better-sqlite3';

const db = sql('meals.db');

export async function getMeals() {
  // 로딩 상태 확인을 위해 의도적인 지연(Delay) 추가
  await new Promise((resolve) => setTimeout(resolve, 2000));

  // .all()은 모든 행을 배열로 가져옴
  return db.prepare('SELECT * FROM meals').all();
}

3. 컴포넌트에 async/await를 직접 쓰는 이유

가장 많은 입문자가 헷갈리는 부분입니다. 왜 일반 리액트 컴포넌트는 async가 안 되고, 서버 컴포넌트는 될까요?

① 일반 리액트(CSR)의 한계

일반적인 클라이언트 컴포넌트는 "즉시 UI(JSX)를 반환해야 하는 함수"입니다

• 문제점: async를 붙이면 함수가 JSX가 아닌 Promise를 반환합니다.

• 결과: 리액트 엔진은 화면에 그릴 HTML이 필요한데 '나중에 줄게'라는 약속(Promise)을 받으면 에러를 냅니다. 그래서 예전엔 useEffect 안에서 데이터를 따로 관리했습니다.

② 서버 컴포넌트(RSC)의 마법

서버 컴포넌트는 브라우저가 아닌 서버(백엔드 환경)에서 실행됩니다.

• 기다림의 미학: 서버는 "데이터 가져오는 데 2초 걸려? 오케이, 다 가져올 때까지 내가 기다렸다가(await) 완성된 HTML을 통째로 구워서 보내줄게"라고 할 수 있는 능력이 있습니다.

데이터 로딩 프로세스 변화

1. 서버 진입: 요청이 오면 서버 컴포넌트 함수가 실행됨.
2. 비동기 대기: await getMeals() 라인에서 DB 응답이 올 때까지 함수 실행을 잠시 멈춤.
3. HTML 생성: 데이터가 도착하면 그 데이터를 버무려 최종 HTML을 완성함.
4. 전송: 브라우저는 자바스크립트가 실행되기 전부터 이미 데이터가 채워진 HTML을 받게 됨.

page.js가 각 페이지의 구체적인 내용이라면, layout.js는 이를 감싸는 공통의 뼈대와 환경 설정을 담당함

키워드: Root Layout, Children Props, Nested Layout, Metadata SEO

1. layout.js의 정의와 역할

layout.js는 하나 이상의 페이지를 감싸는 공통의 껍데기(Shell)입니다. 헤더, 푸터, 내비게이션 바처럼 모든 페이지에서 반복되는 요소들을 한 곳에서 관리합니다.

2. 루트 레이아웃(Root Layout)의 필수성

app 폴더 최상위의 layout.js는 애플리케이션의 근본입니다. 리액트 컴포넌트임에도 불구하고 <html>과 <body> 태그를 직접 렌더링해야 하는 필수 파일입니다.

3. children 속성과 페이지 삽입

레이아웃은 리액트의 표준 속성인 children을 통해 내용을 전달받습니다.

• 동작: 사용자가 접속한 경로의 page.js가 레이아웃의 {children} 자리로 자동 조립됩니다.

4. 중첩 레이아웃 (Nested Layout)

특정 하위 폴더에도 레이아웃을 추가할 수 있으며, 이는 해당 섹션(예: 관리자 페이지, 마이페이지)에만 특화된 디자인을 적용할 때 유용합니다.

5. 메타데이터(Metadata)와 SEO

Next.js에서는 <head> 태그를 직접 쓰지 않고 약속된 metadata 객체를 사용합니다.

• 자동 처리: export const metadata = { title: '...', description: '...' }라고 정의하면 Next.js가 이면에서 메타 태그를 생성합니다.
• 상속: 상위 레이아웃의 메타데이터는 하위 페이지로 자연스럽게 이어집니다.

19. [Next.js] 서버 컴포넌트(RSC) vs 클라이언트 컴포넌트(RCC)

코드가 서버(Node.js)에서 실행되는지, 브라우저(클라이언트)에서 실행되는지에 따라 성능과 기능이 결정됨

1. 리액트 서버 컴포넌트 (React Server Components, RSC)

Next.js의 모든 컴포넌트는 별도 설정이 없다면 기본적으로 서버 컴포넌트입니다.

• 실행 위치: 브라우저가 아닌 백엔드 서버에서 실행됩니다.
• 장점:
  • 자바스크립트 번들 크기가 줄어들어 성능 향상.
  • 완성된 HTML을 보내주므로 SEO(검색 엔진 최적화)에 매우 유리.
• 특징: console.log가 브라우저가 아닌 터미널에 찍힙니다.

2. 클라이언트 컴포넌트 (Client Components, RCC)

브라우저 전용 기능이나 사용자와의 실시간 상호작용이 필요한 경우 사용합니다.

• 사용법: 파일 최상단에 'use client'; 지시어를 추가합니다.
• 언제 사용하나?
  1. 상태 및 생명주기: useState, useEffect 사용 시.
  2. 이벤트: onClick, onChange 핸들러 사용 시.
  3. 브라우저 API: window, localStorage 접근 시.

3. 왜 기본이 서버 컴포넌트일까? (비교)

4. 실전 예시: ImageSlideshow 컴포넌트

슬라이드쇼처럼 setInterval이나 useState를 써서 실시간으로 화면을 바꿔야 하는 경우, 서버는 브라우저의 미래 상황을 예측할 수 없으므로 반드시 클라이언트 컴포넌트로 작성해야 합니다.

```javascript 'use client'; // 이 컴포넌트는 이제 브라우저에서 생동감 있게 움직입니다.

import { useEffect, useState } from 'react'; // ... 5초마다 이미지를 바꾸는 로직 (브라우저 메모리와 타이머 사용)

리액트를 넘어선 표준 프레임워크 Next.js의 핵심인 '보호된 파일명'과 서버 중심의 렌더링 설계를 분석함

키워드: Full-stack Framework, File-based Routing, RSC(React Server Components), Prefetching

1. Next.js의 정의와 특징

Next.js는 리액트(React)를 기반으로 하는 풀스택 프레임워크입니다. 리액트가 UI 라이브러리로서 기능을 제공한다면, Next.js는 라우팅, 서버 사이드 렌더링, API 구축 등 웹 서비스에 필요한 모든 도구를 종합적으로 제공합니다.

❖ 핵심 특징:

• 파일 기반 라우팅: 특정 폴더 구조와 파일명만으로 자동으로 URL 경로를 생성함.
• 서버 컴포넌트 기본값: 모든 컴포넌트가 별도 설정 없이도 서버에서 실행되는 구조를 가짐.
• 성능 자동 최적화: 이미지, 폰트 최적화 및 코드 분할(Code Splitting)을 자동으로 처리함.

2. 보호된 파일명: page.js

Next.js 프로젝트에서는 파일명이 곧 기능이 되는 약속된 규칙이 존재합니다. 그중 가장 핵심이 되는 것이 page.js입니다.

• 역할: 해당 경로(URL)에서 실제로 브라우저에 렌더링될 리액트 컴포넌트를 정의함.
• 규칙: 반드시 해당 파일 내에서 컴포넌트를 export 해야만 Next.js 엔진이 인지하고 화면을 구성함.

3. 리액트 서버 컴포넌트 (React Server Components)

Next.js 환경의 컴포넌트는 기본적으로 서버 컴포넌트로 취급됩니다. 이는 컴포넌트가 브라우저가 아닌 백엔드 서버에서 실행됨을 의미합니다.

### 서버 컴포넌트 실행 프로세스

1. 서버 실행: 사용자가 페이지를 요청하면 서버에서 컴포넌트 함수를 실행함.
2. 로그 출력: 컴포넌트 내부의 console.log는 브라우저 콘솔이 아닌 서버 터미널에 출력됨.
3. HTML 전송: 계산이 끝난 완성된 HTML 구조만 브라우저로 전송함.
4. 클라이언트 부담 감소: 브라우저가 내려받아야 할 자바스크립트 번들 크기가 획기적으로 줄어듦.

4. Link 컴포넌트: SPA의 부드러움과 SEO의 결합

Next.js는 초기 방문 시에는 서버에서 완성된 페이지를 보여주고, 이후 이동 시에는 필요한 데이터만 교체하는 하이브리드 방식을 취합니다.

• <a> 태그의 한계: 전체 페이지를 다시 다운로드하여 새로고침(깜빡임)이 발생하고 SPA의 장점이 사라짐.
• <Link> 컴포넌트: 브라우저의 기본 이동 동작을 막고 자바스크립트로 화면 내용만 교체함.

### 성능의 핵심: 프리페칭(Prefetching)

Next.js의 <Link>는 단순히 이동만 돕지 않습니다. 링크가 사용자의 화면(뷰포트)에 들어오는 순간, Next.js는 해당 페이지의 데이터를 미리 로드해둡니다.

사용자가 링크를 클릭하기도 전에 데이터를 준비해두기 때문에, 클릭하는 순간 즉각적인 전환이 일어나는 압도적인 반응성을 제공합니다.

요약 및 결론

결론

Next.js를 사용한다는 것은 단순히 리액트를 서버에서 돌리는 것을 넘어, 최적의 사용자 경험을 위한 설계 시스템을 도입하는 것입니다. 서버 컴포넌트와 Link 컴포넌트의 조화는 현대 웹이 추구하는 속도와 SEO 두 마리 토끼를 모두 잡는 가장 우아한 방법입니다.

"사용자가 소프트웨어를 사용하는 방식과 유사하게 테스트하라"는 철학 아래, 컴포넌트의 렌더링부터 복잡한 비동기 로직까지 검증하는 실전 테스팅 기법임

키워드: RTL(React Testing Library), AAA 패턴, User Event, Mocking(jest.fn), Async Testing

1. 리액트 테스팅의 핵심 철학

리액트 테스팅 라이브러리(RTL)의 최우선 가치는 내부 구현(State, Props 명칭 등)이 아닌 사용자의 관점을 검증하는 것입니다.

❖ 핵심 원칙:

• 내부 상태값이 무엇인지보다 화면에 무엇이 보이고, 어떤 상호작용이 일어나는지가 중요함.
• 코드를 리팩토링해도 사용자 경험이 같다면 테스트는 통과해야 함.

2. 테스트의 기본 구조: AAA 패턴

모든 테스트 코드는 가독성과 유지보수를 위해 3단계 구조를 따릅니다.

1. Arrange (준비): 테스트할 컴포넌트를 render()로 가상 DOM에 띄움.
2. Act (실행): 클릭, 타이핑 등 사용자의 행동을 수행 (userEvent 활용).
3. Assert (단언): 결과가 예상과 일치하는지 expect()로 확인.

3. 단계별 실습 및 메서드 분석

① 기초: 정적 컴포넌트 테스트 (getByText)

가장 기본적인 텍스트 렌더링 확인 단계입니다. describe로 관련 테스트를 그룹화합니다.

describe('Greeting component', () => {
  test('renders "Hello World" as a text', () => {
    render(<Greeting />); // Arrange
    const helloWorldElement = screen.getByText('Hello World!'); // Act & Assert
    expect(helloWorldElement).toBeInTheDocument();
  });
});

② 중급: 이벤트와 상태 변경 (getByRole & userEvent)

버튼 클릭 시 UI가 변하는지 테스트합니다. userEvent는 실제 브라우저의 상호작용(포커스, 클릭 등)을 더 정밀하게 흉내 냅니다.

test('버튼 클릭 시 "Changed!" 문구가 나타나는지 확인', () => {
  render(<Greeting />);

  // 1. 역할(Role)로 버튼 찾기
  const buttonElement = screen.getByRole('button');

  // 2. 사용자의 실제 클릭 동작 수행
  userEvent.click(buttonElement); 

  // 3. 변경된 UI 검증
  const outputElement = screen.getByText('Changed!');
  expect(outputElement).toBeInTheDocument();
});

③ 고급: 요소의 부재 확인 (queryBy)

특정 요소가 화면에 없어야 함을 검증할 때는 getBy를 쓰면 안 됩니다. 요소를 찾지 못하는 순간 에러를 던져 테스트가 중단되기 때문입니다.

• queryByText: 요소를 찾지 못하면 에러 대신 null을 반환합니다.
• 활용: expect(...).toBeNull()과 함께 사용하여 특정 UI가 사라졌음을 안전하게 확인합니다.

④ 심화: 비동기 데이터와 모킹 (Mocking)

API 호출처럼 시간이 걸리는 작업은 실제 네트워크를 타지 않도록 jest.fn()으로 가짜 함수를 만들어 대체(Mocking)합니다.

test('성공 시 포스트 목록을 렌더링함', async () => {
  // 1. Mocking: 실제 fetch를 가짜 함수로 대체하여 외부 의존성 제거
  window.fetch = jest.fn();
  window.fetch.mockResolvedValueOnce({
    json: async () => [{ id: 'p1', title: 'First post' }],
  });

  render(<Async />);

  // 2. 비동기 대기: findAllByRole
  // find로 시작하는 메서드는 요소가 나타날 때까지 기다리며 Promise를 반환함
  const listItemElements = await screen.findAllByRole('listitem');

  // 3. 결과 검증
  expect(listItemElements).not.toHaveLength(0);
});

### 테스팅 메서드 선정 가이드

상황에 맞는 쿼리(Query)를 선택하는 것이 테스트의 견고함을 결정합니다. 단순히 요소를 찾는 것을 넘어, 테스트의 의도에 맞는 접두사를 사용하는 것이 중요합니다.

💡 쿼리 선택의 팁

1. 우선순위: 가능하면 getByRole을 최우선으로 사용하세요. 이는 시각 장애인이 스크린 리더를 사용하는 방식과 유사하여 접근성까지 함께 테스트할 수 있습니다.
2. 에러 메시지: getBy는 요소를 찾지 못할 때 전체 DOM 구조를 에러 메시지로 보여주기 때문에 디버깅에 매우 유리합니다.
3. 비동기 처리: findBy는 기본적으로 1000ms(1초) 동안 요소를 기다립니다. API 응답 속도에 따라 이 시간은 조절 가능합니다.

리액트 테스팅 기초: 코드가 코드를 검증하는 법

수동 테스트의 한계를 극복하고, 앱이 커져도 안정성을 유지할 수 있도록 테스트 코드를 작성하는 자동화 테스팅의 핵심 원리임

키워드: Unit/Integration/E2E Test, Jest, React Testing Library(RTL), AAA 패턴

1. 수동 테스트의 한계와 자동화의 필요성

우리는 보통 브라우저에서 직접 클릭하며 기능을 확인하는 수동 테스트를 진행합니다. 하지만 서비스가 커지면 다음과 같은 치명적인 문제가 발생합니다.

❖ 수동 테스트의 문제점:

• 회귀 버그(Regression Bug): 새 기능을 넣었을 때 기존 기능이 망가지는 것을 놓침.
• 심리적 부담: "이거 수정하면 다른 데 터지는 거 아냐?"라는 두려움 발생.
• 비효율성: 복잡한 앱을 매번 전수 조사하는 것은 불가능함.

자동화 테스팅은 수동 테스트를 대신하는 것이 아니라, 코드가 코드를 검사하게 함으로써 개발자의 확신을 더해주는 도구입니다.

2. 테스팅의 3가지 유형

자동화 테스트는 검사하는 범위에 따라 세 단계로 구분됩니다.

3. 테스팅 도구의 역할: Jest & RTL

리액트 앱은 보통 두 가지 도구의 조합으로 테스트를 진행합니다.

• Jest (심판): 테스트 코드를 실행하고 결과가 성공인지 실패인지 판단하는 테스트 러너입니다.
• React Testing Library (시뮬레이터): 가상의 브라우저(JSDOM)에 컴포넌트를 렌더링하고 사용자의 행동을 흉내 냅니다.

4. 실전 코드 분석 및 AAA 패턴

테스트 코드는 Arrange(준비), Act(행동), Assert(단언)라는 3단계 법칙을 따를 때 가장 명확합니다.

import { render, screen } from '@testing-library/react';
import App from './App';

test('리액트 학습 링크가 렌더링되는지 확인', () => {
  // 1. Arrange (준비): 테스트할 컴포넌트를 가상 DOM에 띄움
  render(<App />);

  // 2. Act (행동): 필요한 요소를 찾음 (/i는 대소문자 무시)
  const linkElement = screen.getByText(/learn react/i);

  // 3. Assert (단언): 결과가 맞는지 확인 (문서에 존재하는가?)
  expect(linkElement).toBeInTheDocument();
});

테스트 실행 흐름 요약

가상 렌더링: render() 함수가 실제 브라우저 없이도 메모리 상에 HTML 구조를 생성함.

요소 탐색: screen.getByText를 통해 사용자가 눈으로 보는 텍스트를 기준으로 요소를 찾음.

검증 실행: expect(...).toBeInTheDocument()가 심판 역할을 하며 테스트 통과 여부를 결정함.

loader가 데이터를 가져오는(Read) 역할이었다면, action은 데이터를 보내고 조작하는(Create, Update, Delete) 핵심 도구임

키워드: action, useLoaderData, useRouteLoaderData, throw json(), useRouteError

1. loader(): 화면이 뜨기 전에 데이터를 가져온다

기본 리액트 방식(useEffect)은 컴포넌트가 렌더링된 후에 데이터를 가져오지만, loader는 페이지 이동이 완료되기 전에 데이터를 미리 가져옵니다.

❖ 장점 및 특징:

• UX 향상: 빈 화면이나 로딩 스피너를 보는 시간을 줄이고, 완성된 페이지를 바로 보여줍니다.
• 자동 처리: loader가 response 객체를 그대로 리턴하면, 리액트 라우터가 내부적으로 .json() 처리를 수행해줍니다.

2. useLoaderData & useRouteLoaderData

가져온 데이터를 컴포넌트에서 꺼내 쓰는 방법입니다.

• useLoaderData: 현재 라우트에 설정된 loader 데이터를 직접 가져옵니다.
• useRouteLoaderData: 부모 라우트의 데이터를 공유받을 때 사용합니다. 라우트 설정에 id를 부여하고, 그 id를 열쇠 삼아 자식 페이지(상세, 수정 등)들이 데이터를 공유합니다.

3. 동적 라우트와 파라미터 (params)

URL에 :eventId와 같은 변수가 포함된 경우, loader 함수는 자동으로 params 객체를 인자로 받습니다.

❖ 차이점:

• 컴포넌트 외부에서 실행되므로 useParams 훅을 사용할 수 없습니다.
• 대신 loader({ params }) 형태를 활용하여 어떤 데이터를 가져올지 API 주소를 동적으로 생성합니다.

4. throw json()을 이용한 우아한 에러 처리

데이터 로딩 중 404나 500 에러가 발생하면 리액트 라우터의 방식으로 에러를 "던집니다(throw)".

• json() 유틸리티: JSON.stringify를 직접 쓸 필요 없이 객체와 상태 코드를 한 번에 던질 수 있게 해줍니다.
• useRouteError: 던져진 에러는 공통 ErrorPage에서 이 훅으로 낚아채서 상황에 맞는 메시지(404: 페이지 없음, 500: 서버 에러 등)를 보여줍니다.

5. 데이터 재사용을 위한 중첩 라우트 설계

동일한 데이터가 필요한 여러 페이지(상세 보기, 수정 페이지)를 하나의 부모 라우트로 묶어 관리합니다.

❖ 최적화 원리:

• 부모 라우트에 id와 loader를 설정합니다.
• 하위의 모든 자식들은 추가적인 API 호출 없이 부모의 데이터를 재사용할 수 있어 성능과 유지보수에 매우 유리합니다.

### Action 작동 프로세스 (CUD)

1. 양식 제출: 사용자가 <Form>을 제출하면 브라우저의 기본 동작을 막고 라우터의 action이 가동됨.
2. 데이터 처리: action 함수가 request 객체에서 폼 데이터를 뽑아내 서버로 POST/PATCH/DELETE 요청을 보냄.
3. 자동 갱신: 서버 작업이 끝나면 리액트 라우터가 현재 페이지의 loader를 다시 실행하여 화면을 최신 상태로 업데이트함.
4. 이동: 작업 완료 후 redirect()를 통해 목록 페이지 등으로 사용자를 안내함.

요약 및 결론

리액트 라우터의 loader와 action을 활용하면 컴포넌트 내부 로직이 획기적으로 줄어듭니다.

"읽기는 loader, 쓰기는 action". 이 두 축을 중심으로 라우트를 설계하면 데이터의 흐름이 명확해지고 앱의 반응 속도가 비약적으로 향상됩니다.

컴포넌트가 렌더링된 후 데이터를 가져오는 기존 방식(Waterfall)을 탈피하여, 페이지 이동과 동시에 데이터를 준비하는 효율적인 데이터 패칭 기법임

키워드: createBrowserRouter, loader, useLoaderData, Outlet, NavLink (end)

중첩 라우팅과 레이아웃 구성

리액트 라우터 6.4 버전부터는 객체 기반의 라우터 설정을 통해 복잡한 계층 구조를 직관적으로 관리할 수 있습니다.

❖ 구조적 특징:

• RootLayout: 전체 앱의 공통 뼈대 (네비게이션 등).
• EventsRootLayout: /events 하위 페이지들의 공통 레이아웃.
• Outlet: 부모 라우트 컴포넌트 내에서 자식 라우트 컴포넌트가 렌더링될 위치를 지정함.
• NavLink (end): 경로가 정확히 일치할 때만 활성 상태(active)를 표시하도록 제한함.

loader: "선 로딩 후 렌더링"의 마법

기존의 useEffect 방식은 컴포넌트가 화면에 나타난 뒤에야 데이터를 가져왔지만, loader는 페이지에 발을 들이기 전에 미리 장을 봐오는 것과 같습니다.

loader는 라우트 설정 단계에서 함수를 연결하여, 해당 경로로 이동하기 직전에 데이터를 미리 가져오는 '사전 준비 요원'입니다.

실전 코드 분석: loader 적용하기

{
  path: 'events',
  element: <EventsRootLayout />,
  children: [
    {
      index: true,
      element: <EventsPage />,
      // 페이지 이동 전 실행되는 사전 로딩 함수
      loader: async () => {
        const response = await fetch('http://localhost:8080/events');

        if (!response.ok) {
          // 에러 처리 로직
        } else {
          const resData = await response.json();
          return resData.events; // 리턴된 데이터는 컴포넌트에서 useLoaderData로 사용 가능
        }
      },
    },
    { path: ':eventId', element: <EventDetailPage /> },
  ],
}

데이터 패칭 프로세스의 변화

1. 사용자 클릭: 사용자가 /events 링크를 클릭함.
2. Loader 가동: 리액트 라우터가 해당 경로의 loader 함수를 감지하고 데이터를 가져오기 시작함.
3. 컴포넌트 렌더링: 데이터 로딩이 끝날 때까지 이동을 잠시 유보했다가, 데이터가 준비되면 EventsPage를 화면에 뿌림.
4. 데이터 사용: 컴포넌트 내부에서 useLoaderData() 훅을 통해 useState 없이도 데이터를 바로 사용함.

커스텀 레이아웃과 Outlet의 조화

중첩된 라우트 구조에서 레이아웃 컴포넌트는 UI의 일관성을 유지하는 핵심 역할을 합니다.

❖ 레이아웃 관리:

• EventsRootLayout 내부에 <EventsNavigation />을 배치하고 그 아래에 <Outlet />을 둡니다.
• 이렇게 하면 /events, /events/new, /events/1 등 어떤 하위 페이지로 가더라도 서브 네비게이션은 고정된 채 알맹이(Outlet)만 바뀌게 됩니다.

리듀서 내부의 금지된 규칙을 이해하고, "멍청한 백엔드"를 보완하는 프론트엔드 설계 전략을 마스터하는 단계임

키워드: Reducer Purity(리듀서의 순수성), Side Effects(부수 효과), Fat Reducer vs Lean Component, Thunk(썽크)

리듀서 안에서 fetch()를 쓰면 안 되는 이유

리덕스의 리듀서는 반드시 순수 함수(Pure Function)여야 합니다. 즉, 외부 세계를 건드리지 않고 입력값에 대해서만 결과를 내놓아야 합니다.

❖ 설계 원칙 위반:

• 예측 가능성 파괴: 비동기 요청은 언제 끝날지 알 수 없습니다. 리덕스는 현재 상태를 즉각적으로 파악해야 하는데, 비동기가 끼어들면 상태 추적이 불가능해집니다.
• 순수성 위반: 서버 데이터를 수정하는 행위는 '부수 효과'입니다. 리듀서는 오직 '상태 계산'만 해야 하며 외부 환경(서버)을 바꿔서는 안 됩니다.

리듀서는 "입력(현재 상태+액션) -> 출력(새 상태)"이 즉각적이고 명확한 '계산기' 역할만 수행해야 합니다.

전략적 선택: "멍청한 백엔드" 대응법

파이어베이스와 같이 단순히 저장만 하는 백엔드를 사용할 때는 프론트엔드가 더 똑똑해져야 합니다.

### 데이터 동기화 프로세스

1. 리덕스 선제 업데이트: 리듀서에서 복잡한 계산(수량, 합계)을 완벽하게 끝냄
2. 상태 감지 (App.js): useSelector로 바뀐 상태를 감지함
3. 서버 복사 (PUT): useEffect를 통해 최신 상태를 서버에 통째로 덮어쓰기(PUT)하여 동기화함

해결책: 썽크(Thunk)와 액션 생성자

리듀서에 넣을 수 없는 비동기 로직은 리덕스 썽크(Thunk)를 통해 우아하게 해결할 수 있습니다.

❖ 로직의 거처 선정:

• 리듀서(Reducer): "데이터 계산의 중심". 절대 비동기 금지.
• 썽크(Thunk): "비즈니스 로직의 해결사". HTTP 요청, 에러 처리 등 '지저분한' 일을 전담.
• 컴포넌트(Component): "화면의 전달자". 복잡한 건 몰라도 됨. 오직 dispatch만 수행 (Lean Component).

// App.js에서의 자동 동기화 예시
useEffect(() => {
  if (isInitial) { // 초기 렌더링 시 전송 방지
    isInitial = false;
    return;
  }

  // 리덕스 상태(cart)가 바뀔 때마다 서버에 PUT 요청
  sendCartData(cart); 
}, [cart]);

리덕스 데브툴(DevTools) 활용

단순한 디버깅을 넘어, 애플리케이션의 흐름을 지배하는 도구입니다.

❖ 핵심 기능:

• 상태 추적: 액션 전후의 상태 변화를 한눈에 비교.

• 시간 여행(Time Travel): 과거의 특정 액션 시점으로 상태를 되돌려 버그 재현.

• 복잡한 상태 변화를 시각화하여 유지보수 시간을 획기적으로 단축함.

배열(Array)만 쓰다가 특정 상황에서 막힐 때가 있는데, 그때 꺼내 쓰는 게 Map이랑 Set임. 중복 제거랑 탐색 속도 면에서 효율이 압도적이라 정리

1. Set (세트)

Set은 중복을 허용하지 않는 데이터 집합임. 값만 저장하는데, 똑같은 걸 두 번 넣어도 하나만 남음.

특징

• 중복된 값은 알아서 걸러짐.
• 특정 값이 있는지 확인할 때 has()를 쓰는데, 배열의 includes()보다 훨씬 빠름 ($O(1)$).

const mySet = new Set();

mySet.add(1);
mySet.add(2);
mySet.add(2); // 중복이라 안 들어감

console.log(mySet.has(1)); // true
console.log(mySet.has(3)); // false
console.log(mySet.size);   // 2 (개수 확인)

// ✅ 꿀팁: 배열 중복 제거 한 줄 컷
const arr = [1, 2, 2, 3, 3];
const uniqueArr = [...new Set(arr)]; // [1, 2, 3]

2. Map (맵)Map은 Key(키) - Value(값) 쌍으로 저장하는 구조임. 객체({})랑 비슷하지만 코테에선 Map이 훨씬 편함.특징키값으로 숫자, 객체 등 아무거나 다 쓸 수 있음.size로 데이터가 몇 개인지 바로 확인 가능.데이터가 들어온 순서가 유지됨.JavaScriptconst myMap = new Map();

myMap.set('바키', '격투가');
myMap.set('죠죠', '스탠드사');
myMap.set(123, '숫자 키 가능');

console.log(myMap.get('바키')); // '격투가'
console.log(myMap.has('죠죠')); // true (키 있는지 확인)
console.log(myMap.size);        // 3

구분,Array (배열),Set / Map 속도,includes() 쓰면 O(N) (느림),has() 쓰면 O(1) (개빠름) 중복,상관없음 (다 들어감),중복 불가 (특히 Set) 용도,순서대로 저장하거나 인덱스 접근할 때,빠른 탐색이나 빈도수 셀 때

실전 예시: 숫자 개수 세기 배열에 숫자가 각각 몇 개씩 있는지 셀 때 Map 쓰면 깔끔함.

const arr = [1, 1, 2, 3, 1, 2];
const counts = new Map();

arr.forEach(num => {
  // 있으면 가져와서 +1, 없으면 0에서 +1
  counts.set(num, (counts.get(num) || 0) + 1);
});

console.log(counts.get(1)); // 3

✅ 정리: 단순히 들어있는지 체크만 할 거면 Set, 이름표 붙여서 관리하거나 개수 세야 하면 Map 쓰면 됨. 성능 차이 때문에 큰 데이터 다룰 땐 필수임.

복잡한 비동기 통신이나 상태 관리 로직을 하나의 함수(Hook)로 묶어 여러 컴포넌트에서 재사용할 수 있게 만드는 고급 기법임

리액트의 내장 훅(useState, useEffect 등)을 조합하여 나만의 도구를 만드는 과정이다.

커스텀 훅의 핵심 규칙

커스텀 훅을 만들 때는 리액트가 이를 일반 함수와 구분할 수 있도록 약속된 형식을 지켜야 한다.

❖ 작성 가이드:

• use 접두사: 반드시 함수 이름은 use로 시작해야 함 (예: useFetch, useInput)
• 상태의 독립성: 같은 훅을 여러 컴포넌트에서 사용해도 각각의 컴포넌트는 자신만의 독립된 상태를 가짐
• 로직 공유: UI가 아닌 동작(Logic)을 공유하는 것이 목적임

커스텀 훅은 컴포넌트를 가볍게 만들고, 코드의 중복을 획기적으로 줄여주는 "로직 주머니"와 같다.

실전 예시: useFetch 커스텀 훅

데이터를 가져오는 공통 로직을 useFetch.js 파일로 분리한 모습이다.

import { useEffect, useState } from 'react';

export function useFetch(fetchFn, initialValue) {
  const [isFetching, setIsFetching] = useState(false);
  const [error, setError] = useState();
  const [fetchedData, setFetchedData] = useState(initialValue);

  useEffect(() => {
    async function fetchData() {
      setIsFetching(true);
      try {
        const data = await fetchFn();
        setFetchedData(data);
      } catch (error) {
        setError({ message: error.message || '데이터를 불러오지 못했습니다.' });
      }
      setIsFetching(false);
    }
    fetchData();
  }, [fetchFn]);

  // 컴포넌트에서 필요한 값들을 객체 형태로 반환
  return { isFetching, fetchedData, setFetchedData, error };
}

커스텀 훅 작동 프로세스

1. 매개변수 전달: 컴포넌트에서 실행할 비동기 함수(fetchFn)와 초기값(initialValue)을 훅에 넘겨줌
2. 내부 상태 관리: 훅 내부에서 로딩, 에러, 데이터 상태를 독립적으로 관리함
3. 자동 실행: useEffect를 통해 컴포넌트가 마운트될 때 데이터를 자동으로 가져옴
4. UI 연결: 컴포넌트는 훅이 리턴한 값들을 구조 분해 할당으로 받아 화면을 그리는 데만 집중함

커스텀 훅의 이점: 관심사의 분리

컴포넌트 파일 안에 수십 줄의 useEffect와 useState가 섞여 있으면 가독성이 떨어진다.

❖ 최적화 효과:

• 가독성 향상: 컴포넌트는 "어떤 UI를 보여줄지"에만 집중하고, 훅은 "어떻게 데이터를 가져올지"만 고민함
• 유지보수 용이: 데이터 패칭 로직에 수정이 필요할 때, 여러 파일을 고칠 필요 없이 커스텀 훅 파일 하나만 수정하면 됨
• 함수 이름(useFetch)만 봐도 이 로직이 무엇을 하는지 한눈에 파악할 수 있음

사용자가 삭제 버튼을 눌렀을 때, 서버의 응답을 기다리지 않고 화면에서 먼저 지워버려 앱이 즉각적으로 반응하게 만드는 기법임

비동기 통신의 지연 시간(Latency)을 사용자 경험(UX)으로 극복하는 고급 기술이다.

삭제 로직의 3단계 흐름

데이터 삭제는 단순히 명령을 보내는 것이 아니라, UI와 서버 데이터를 동기화하는 섬세한 과정이 필요하다.

❖ 구현 프로세스:

1. 화면 선제 업데이트: setUserPlaces를 호출하여 클릭한 항목을 리스트에서 즉시 제거한다.
2. 서버 통신 수행: fetch 요청을 통해 서버에 삭제 명령을 보낸다.
3. 에러 핸들링 (복구): 만약 서버 삭제가 실패하면, 화면에서 지웠던 데이터를 다시 복구시킨다.

사용자는 "내 명령이 즉시 실행되었다"고 느끼며, 앱이 매우 빠르다는 인상을 받게 된다.

실전 코드 분석

const handleRemovePlace = useCallback(async function handleRemovePlace() {
  // 1. 낙관적 업데이트: UI에서 먼저 제거
  setUserPlaces((prevPickedPlaces) =>
    prevPickedPlaces.filter((place) => place.id !== selectedPlace.current.id)
  );

  try {
    // 2. 서버에 실제 삭제 요청
    await updateUserPlaces(
      userPlaces.filter((place) => place.id !== selectedPlace.current.id)
    );
  } catch (error) {
    // 3. 실패 시 복구 로직: 이전 상태로 되돌림
    setUserPlaces(userPlaces);
    setErrorUpdatingPlaces({
      message: error.message || '삭제에 실패했습니다.',
    });
  }
}, [userPlaces]);

### 삭제 및 복구 프로세스

1. 배열 필터링: filter 메서드를 사용하여 선택된 ID를 제외한 새로운 배열을 생성하고 상태를 업데이트함
2. 비동기 요청: await를 사용하여 서버의 응답을 기다리지만, 사용자는 이미 지워진 화면을 보고 있음
3. 롤백(Rollback): 네트워크 단절 등으로 서버 작업이 실패하면 catch 문에서 기존 userPlaces를 다시 세팅하여 항목을 화면에 다시 나타나게 함

### 왜 useCallback으로 감싸나

이 삭제 함수는 보통 자식 컴포넌트(모달이나 버튼)로 전달되는 경우가 많다.

❖ 최적화 이유:

• 함수 주소 고정: useCallback을 쓰지 않으면 부모가 리렌더링될 때마다 삭제 함수가 새로 만들어진다.
• 불필요한 자식 렌더링 방지: 함수 주소가 바뀌면 이 함수를 전달받은 자식 컴포넌트(memo 처리된 경우)까지 다시 그려지게 되므로, 이를 방지하기 위해 주소를 박제한다.
• 의존성 배열에 userPlaces를 넣어 최신 데이터 상태를 유지하도록 설계한다.

리액트가 왜 빠른지, 그리고 우리가 개발자 도구에서 목격하는 "깜빡임"의 정체가 무엇인지 파헤쳐 봅니다.

1. 초기 렌더링 (The Initial Render)

처음 웹사이트에 접속하면 리액트는 전체 컴포넌트 트리를 훑으며 가상 DOM 스냅샷을 찍습니다. 그리고 이 설계도대로 실제 빈 HTML의 <div> 안에 내용을 꽉 채워 넣습니다.

❖ 초기 단계:

• 실제 DOM: 텅 비어 있음 (<div id="root"></div>)
• 가상 DOM: 컴포넌트 트리 전체 구조를 메모리에 생성
• 결과: 가상 DOM 전체가 실제 DOM으로 뿅! 하고 나타남

2. 컴포넌트 재실행과 가상 DOM의 비교

사용자가 버튼을 클릭해서 counter 값이 바뀌면 리액트가 다시 움직이기 시작합니다. 단순히 화면을 바꾸는 게 아니라 내부적으로 정교한 비교 과정을 거칩니다.

❖ 비교 프로세스:

• 새 스냅샷 생성: 상태가 변한 컴포넌트를 다시 실행해서 새로운 가상 DOM 스냅샷을 생성
• Diffing (비교): 리액트가 "이전 스냅샷"과 "새 스냅샷"을 1:1로 비교 (마치 '틀린 그림 찾기'와 같음)
• 최소 변경 사항 도출: "다른 건 그대로인데 <span> 안의 숫자만 5에서 6으로 바뀌었네?"라고 딱 그 부분만 찾아냄

3. 실제 DOM 업데이트 (Reconciliation)

리액트가 영리한 이유는 바로 이 지점입니다. 전체 페이지를 다시 그리는 대신, 찾아낸 그 '차이점'만 실제 DOM에 적용합니다.

• 비효율적 방식: 전체 HTML을 싹 지우고 새로 쓰기 (브라우저 부하 가중)
• 리액트 방식: 딱 <span> 요소의 텍스트 노드만 교체 (사용자가 느끼지 못할 정도로 빠름)

개발자 도구에서 "해당 요소만 깜빡이는 현상"이 바로 리액트가 최소한의 일만 하고 있다는 증거입니다!

4. 왜 실제 DOM을 직접 안 쓰나요?

실제 DOM은 브라우저 화면을 그리는 복잡한 정보(스타일, 레이아웃 등)를 다 가지고 있어서, 하나만 건드려도 브라우저가 계산을 다시 해야 합니다.

❖ 가상 DOM의 장점:

• 속도: 자바스크립트 객체일 뿐이라 메모리 안에서 수만 번 비교해도 엄청나게 빠름
• 전략: "메모리에서 신나게 비교하고, 결론만 실제 DOM에 딱 한 번 알려주는" 효율적인 방식

💡 요약 정리

결론

리액트는 단순히 UI를 그리는 라이브러리가 아니라, 최소한의 변경으로 최적의 경험을 제공하는 전략가입니다. 가상 DOM이라는 완충 지대를 두어 브라우저의 부담을 덜어주는 것이 그 핵심입니다.

JSON 기본 이해: JSON.stringify와 JSON.parse 활용 및 JSON 형식과 문자열의 차이

1. JSON이란 무엇인가

JSON은 "JavaScript Object Notation"의 약자입니다. 이는 데이터를 구조화하여 표현하기 위한 개방형 표준 형식이며, 사람이 읽고 쓰기 용이하며 기계가 파싱하고 생성하기 쉬운 형태로 설계되었습니다. 웹 서비스에서 서버와 클라이언트 간의 데이터 교환에 주로 사용됩니다.

JSON의 주요 특징

가독성: key-value 쌍으로 구성되어 데이터의 의미를 쉽게 파악할 수 있습니다. 경량성: 다른 데이터 교환 형식(예: XML)에 비해 파일 크기가 작아 네트워크 전송 효율이 높습니다. 범용성: 대부분의 프로그래밍 언어에서 JSON을 처리하는 라이브러리 및 기능이 내장되어 있습니다.

JSON 데이터의 일반적인 구조

{
  "department": "IT 개발",
  "employeeId": "mjh",
  "isActive": true,
  "skills": ["JavaScript", "React", "Spring"],
  "contact": {
    "email": "contact@example.com",
    "phone": "010-xxxx-xxxx"
  }
}

2. JSON.stringify()와 JSON.parse()의 기능 및 형태

JSON 데이터는 주로 문자열 형태로 통신되거나 저장됩니다. 자바스크립트에서는 이러한 변환을 위해 JSON.stringify()와 JSON.parse() 두 가지 내장 함수를 제공합니다.

JSON.stringify(): 자바스크립트 객체를 JSON 문자열로 변환

• 자바스크립트 객체 또는 값을 JSON 형식의 문자열로 직렬화(serialize)합니다. 이 함수는 주로 객체를 웹 서버로 전송하거나 localStorage와 같은 웹 스토리지에 저장하기 전에 사용됩니다.

  // 변환 전: 자바스크립트 객체
  const userDataObject = {
  name: "김철수",
  age: 30,
  isAdmin: false,
  roles: ["user", "guest"]
  };
  

console.log("변환 전 타입:", typeof userDataObject); console.log("변환 전 값:", userDataObject); /* 출력: 변환 전 타입: object 변환 전 값: { name: '김철수', age: 30, isAdmin: false, roles: [ 'user', 'guest' ] } */

// JSON.stringify() 적용: 객체를 JSON 문자열로 변환 const jsonStringifiedData = JSON.stringify(userDataObject);

console.log("변환 후 타입:", typeof jsonStringifiedData); console.log("변환 후 값:", jsonStringifiedData); /* 출력: 변환 후 타입: string 변환 후 값: {"name":"김철수","age":30,"isAdmin":false,"roles":["user","guest"]} */

변환 후 jsonStringifiedData 변수는 JavaScript의 object 타입이 아닌 string 타입의 값을 가지게 되며, 모든 키와 문자열 값은 이중 따옴표(")로 감싸집니다.



 JSON.parse(): JSON 문자열을 자바스크립트 객체로 변환

- J JSON 형식의 문자열을 파싱(parse)하여 자바스크립트 객체로 역직렬화(deserialize)합니다. 이 함수는 주로 웹 서버로부터 JSON 응답을 수신하거나 localStorage에서 JSON 데이터를 읽어올 때 사용됩니다.
```js
// 변환 전: JSON 형식의 문자열 (예: 서버로부터 수신된 데이터)
const receivedJsonString = '{"name":"박영희","age":25,"isAdmin":true,"roles":["admin","editor"]}';

console.log("변환 전 타입:", typeof receivedJsonString);
console.log("변환 전 값:", receivedJsonString);
/* 출력:
변환 전 타입: string
변환 전 값: {"name":"박영희","age":25,"isAdmin":true,"roles":["admin","editor"]}
*/

// JSON.parse() 적용: JSON 문자열을 자바스크립트 객체로 변환
const parsedDataObject = JSON.parse(receivedJsonString);

console.log("변환 후 타입:", typeof parsedDataObject);
console.log("변환 후 값:", parsedDataObject);
/* 출력:
변환 후 타입: object
변환 후 값: { name: '박영희', age: 25, isAdmin: true, roles: [ 'admin', 'editor' ] }
*/

변환 후 parsedDataObject 변수는 JavaScript의 object 타입이 되며, 해당 객체의 속성에 직접 접근하여 데이터를 활용할 수 있습니다.

function키워드를 사용해서 만든 함수는 동적인 this때문에 이리저리 바인딩하느라 혼동을 줄 수 있음 화살표 함수를 사용하면 어떤방법으로 호출하던 this의 값이 변하지않음 화살표함수의 this값은 그 함수를 감싸는 스코프의 this를 그대로 가져와서 사용 전통적인 함수의 this는 함수를 호출하는 방법에 따라 동적으로 바뀜

this 복습

일반함수 this

const object = {
  name:'jungo',
  main: function () {
    console.log(this);
  },
};
object.main();
// {name:'jungo',main:f}

함수를 어떤 객체가 호출했냐에 따라 this가 달라짐 -> object 객체

• 일반함수가 가지는 this값은 함수가 선언된 위치랑은 관련 x
• 함수가 호출된 방법에 따라 달라짐

화살표함수 this

화살표함수는 자신만의 this를 가지고 있지 않는다. 화살표함수 내부에서 this에 접근하면 외부에서 가져와서 사용

const object = {
  name:'jungo',
  main: function () {
    console.log(this);
  },
  mainArrow:()=>{
    console.log(this)
  }
};

object.mainArrow();

결과 window가 this값으로 나온다. 화살표함수는 자신만의 this를 가지지 않기 때문에 자신을 감싸고있는 스코프로 올라가서 this를 찾는다.

• 선언된 위치에서 this가 결정된다. === 함수가 호출된 방법과는 무관하다.

따라서

const object = {
  name:'jungo',
  main: function () {
    console.log(this);
  },
  mainArrow:()=>{
    console.log(this.name)    //아무것도 출력 x
  }
};

object.mainArrow();

화살표함수는 this가 더이상 object가 되지않기 때문에 object속성에 접근할 수 없음

객체의 메서드로는 화살표함수보다 일반함수를 사용하는 것이 적절

예제

const object = {
  name:'jungo',
  main: function () {
    const innerFunction = function (){
      console.log(this)
    };
    innerFunction()
  },
};

object.main();

결과 - window

this값이 object가 아닌 window가 출력되는 이유

• innerFunction은 어떤 객체로부터 직접적으로 호출된게 아님 따라서 innerFunction안에 this는 window

수정 예제(화살표함수)

const object = {
  name:'jungo',
  main: function () {
    const innerFunction = () => {
      console.log(this)
    };
    innerFunction()
  },
};

object.main();

결과

//object 객체
{name:'jungo', main:f}

화살표 함수의 this는 감싸는 외부 스코프(main함수)의 this를 그대로 사용

• main함수 안에있는 this값은 object객체

렉시컬 스코프

스코프란 변수나 함수의 접근가능한 유효 범위를 의미하며, 렉시컬 스코프(정적 스코프) 규칙을 따름 JavaScript 스코프는 전역/로컬 스코프로 나뉘며 렉시컬 스코프 규칙에 따라 결정된다.

❖렉시컬 스코프 규칙:변수가 선언된 위치에 따라 접근 가능 범위가 결정

자바스크립트 변수 참조 과정

함수가 실행될때마다 메모리상에 실행컨텍스트 생성

• 실행컨텍스트 안에는 렉시컬 환경 존재
• 여기에 현재 스코프에서 선언한 모든 변수와 함수들이 저장된 환경 레코드 존재
• 현재 환경에서 찾지 못한 변수 상위 스코프에서 찾기위해 상위 스코프를 가리키는 외부 렉시컬 환경 참조도 갖고있음

코드 상에서 변수나 함수를 참조하면

1. 현재 환경 레코드에서 찾기
2. 외부 렉시컬환경 참조를 통해 상위 스코프 참조
3. 없을경우 전역 스코프까지 올라가며, 없으면 Reference Error

클로저 개념을 이해해도 언제 어떻게 쓰이는지 모르겠음

function countWithoutClosure {
  let count = 0;
    return count;
}
console. log(countWithoutClosure()); // '0'
console. log(count); // ReferenceError: count is not defined

렉시컬 스코프 규칙에 따라 함수안에서 선언한 변수는 함수 안에서만 접근 가능

1. 함수가 실행되면 함수 내부 변수(count)는 메모리에 올라감
2. return -> 메모리 상 제거
3. 함수바깥에서는 변수가 제거된 상태이므로 참조 불가

기본적인 closure 형태

클로저는 함수가 생성될 때의 스코프(외부 변수)에 접근할 수 있는 성질을 의미 함수 선언문 바깥에서도 함수 스코프를 참조할 수 있음 React useState에서 클로저 개념 사용

function countWithClosure() {
let count = 0;
return {
  increase: function () {
    count++;
    return count;
    },
  decrease: function () {
    count--；
    return count;
  },
  getCount: function () {
    return count;
  },
 };
}

함수 return문에서 함수 내부의 변수를 사용하는 함수를 다시 return하면 함수 선언문 바깥에서도 스코프에 접근 가능

const counter = countWithClosure;
console. log(counter getCount()); // 0
counter. increase();
console. log(counter.getCount()); // 1
counter. decrease();
console. log(counter.getCount)); // 0

counter 변수: function increase,function decrease,function getCount 클로저에 의해 return될때 함수 실행에 필요한 상위 스코프도 메모리로 가져옴(counter) --> counter가 클로저에 의해 메모리에 캡쳐되고있음

정리

Closre 자바스크립트는 렉시컬 스코프 규칙을 따름 따라서, 일반적인 방식으로는 함수 선언문 밖에서 함수 스코프에 접근할 수 없음 이를 보완하기 위한 방법이 클로저 함수임 클로저 수는 스코프가 상위 함수의 스코프를 참조하는 항수를 return 하는 방식 React의 useState, moment 라이브러리에서 사용하는 방식