[P-Reinforce] 2026-04-20: 15-Level React Mastery Curriculum Integrated
This commit is contained in:
@@ -0,0 +1,15 @@
|
||||
# 🍼 [LEVEL 1] 리액트의 심장: UI는 상태(State)의 함수다
|
||||
|
||||
## 1. 생각의 전환: "어떻게(How)"가 아니라 "무엇을(What)"
|
||||
- **HTML/JS 방식**: "버튼을 찾아서, 클릭 이벤트를 걸고, 텍스트를 바꾼다." (명령형)
|
||||
- **리액트 방식**: "상태가 `ON`이면 '켜짐'을 보여주고, `OFF`이면 '꺼짐'을 보여준다." (선언형)
|
||||
- **교훈**: 중급 주니어는 DOM을 직접 건드리지 않는다. 오직 **상태**만 건드린다.
|
||||
|
||||
## 2. 불변성(Immutability): 왜 `push`는 안되나요?
|
||||
- 리액트는 "값이 바뀌었네?"를 메모리 주소값으로 판단한다.
|
||||
- `arr.push(1)`은 주소는 그대로고 내용만 바뀐다. 리액트는 바뀐 줄 모른다!
|
||||
- **정답**: `setArr([...arr, 1])` 처럼 항상 **새로운 복사본**을 던져라.
|
||||
|
||||
## 3. 단방향 데이터 흐름: 물은 위에서 아래로 흐른다.
|
||||
- 부모가 자식에게 주는 건 `Props`. 자식이 부모를 바꾸려면 부모가 준 `함수`를 호출하라.
|
||||
- **하지 말 것**: 자식이 부모의 상태를 몰래 바꾸는 '매직'은 시스템을 망친다.
|
||||
@@ -0,0 +1,16 @@
|
||||
# 🧠 [LEVEL 2] Hook의 심연: 단순 사용을 넘어 오용 방지로
|
||||
|
||||
## 1. `useEffect`는 '타이머'가 아니다. '동기화' 장치다.
|
||||
- 초보는 `useEffect`를 함수 실행기로 쓴다.
|
||||
- 중급은 **"이펙트가 어떤 상태와 외부 시스템(API, 라이브러리)을 동기화하는가?"**를 고민한다.
|
||||
- **Check**: 의존성 배열(`[]`)에 넣은 변수가 정말 이 이펙트의 원인인가?
|
||||
|
||||
## 2. Custom Hooks: 논리의 분리
|
||||
- 컴포넌트 안에 `fetch`, `loading`, `error` 가 가닥가닥 널려 있다면 실패!
|
||||
- `useFetchData()` 라는 나만의 훅을 만들어 논리만 쏙 뽑아내라.
|
||||
- **성공 가이드**: UI 담당 컴포넌트는 `const { data } = useMyLogic();` 한 줄로 끝나야 한다.
|
||||
|
||||
## 3. `useRef`: 사라지지 않는 기억
|
||||
- `useState`는 바뀔 때마다 화면을 다시 그린다(Refrender).
|
||||
- `useRef`는 값이 바뀌어도 화면을 그리지 않는다.
|
||||
- **용도**: 이전 화면의 값 저장, DOM 직접 접근(포커스 등), 타이머 ID 보관.
|
||||
@@ -0,0 +1,17 @@
|
||||
# 🏗️ [LEVEL 3] 컴포넌트 아키텍처: 벽돌 쌓기에서 성 짓기로
|
||||
|
||||
## 1. Props Drilling을 멈춰라!
|
||||
- 할아버지가 손자에게 데이터 주려고 아빠, 삼촌을 거쳐가는 코드는 죄악이다.
|
||||
- **해결책**: `Context API`를 쓰거나, **Component Composition(컴포넌트 합성)**을 사용하라.
|
||||
- 아예 `<Layout content={<GrandChild />} />` 처럼 자식을 통째로 넘겨라.
|
||||
|
||||
## 2. 관심사의 분리: Container-Presenter 패턴
|
||||
- **Container**: 데이터 가져오기, 로직 처리. (머리)
|
||||
- **Presenter**: CSS, 스타일, 데이터 보여주기. (몸통)
|
||||
- **효과**: 스타일만 바꾸고 싶을 때 로직 코드를 안 봐도 된다.
|
||||
|
||||
## 3. Atomic Design 맛보기
|
||||
- `Atom`: 버튼, 입력창 (가장 작은 단위)
|
||||
- `Molecule`: 검색바 (Atom의 결합)
|
||||
- `Organism`: 헤더, 푸터 (복잡한 구조)
|
||||
- **기준**: 아톰은 프로젝트 어디서든 쓰일 수 있게 **순수(Pure)**해야 한다.
|
||||
@@ -0,0 +1,15 @@
|
||||
# ⚡ [LEVEL 4] 렌더링 최적화: "내 앱은 왜 렉이 걸릴까?"
|
||||
|
||||
## 1. 렌더링은 공짜가 아니다
|
||||
- 부모가 그려지면 자식도 그려진다. 이게 계속되면 성능 폭발이다.
|
||||
- `React.memo`: "너 아까랑 준 거 똑같은데? 다시 그리지 마!"
|
||||
- `useMemo`: 복잡한 계산 결과물 재사용.
|
||||
- `useCallback`: 함수 재생성 방지.
|
||||
|
||||
## 2. '성급한 최적화'는 독이다
|
||||
- 모든 컴포넌트에 `memo`를 바르는 건 멍청한 짓이다.
|
||||
- 진짜 느린 부분(리스트 1000개 로딩 등)을 찾아서 **프로파일러(DevTools)**로 찍어보고 최적화하라.
|
||||
|
||||
## 3. Key값의 중요성: `index`는 최후의 수단이다
|
||||
- `map` 돌릴 때 `index`를 key로 쓰면, 리스트 순서가 바뀔 때 리액트가 멘붕에 빠진다.
|
||||
- 반드시 데이터의 **Unique ID**를 써라. 그래야 리액트가 "아, 순서만 바뀌었네?" 하고 영리하게 대처한다.
|
||||
@@ -0,0 +1,15 @@
|
||||
# 🌐 [LEVEL 5] 상태 관리의 거버넌스: 어디에 저장할 것인가?
|
||||
|
||||
## 1. 상태에도 거주지가 있다
|
||||
- **Local State**: 그 컴포넌트만 알면 되는 것 (Input 입력값 등).
|
||||
- **Global State**: 온 동네가 알아야 하는 것 (로그인 정보, 테마).
|
||||
- **Server State**: 서버에서 빌려온 것 (게시글 목록).
|
||||
|
||||
## 2. 서버 상태는 `React Query`에게 맡겨라
|
||||
- `useEffect`로 API 호출해서 `loading` 관리하던 시대는 끝났다.
|
||||
- 캐싱, 재시도, 로딩 상태를 자동으로 해주는 라이브러리를 써서 **'신선한 데이터'**만 관리하라.
|
||||
|
||||
## 3. 상태의 최소화 (Single Source of Truth)
|
||||
- `firstName`과 `lastName`이 있는데 `fullName` 이라는 상태를 또 만들지 마라.
|
||||
- `fullName`은 렌더링할 때 그냥 합쳐서 보여주면 된다.
|
||||
- 상태가 많아질수록 동기화 오류(버그)의 확률은 급상승한다.
|
||||
@@ -0,0 +1,13 @@
|
||||
# 🧹 [LEVEL 6] 리액트 클린 코드: 누구나 이해하는 코드
|
||||
|
||||
## 1. 조건부 렌더링의 품격
|
||||
- `condition && <Component />` 는 편하지만, `condition`이 0일 때 화면에 0이 찍히는 대참사가 난다.
|
||||
- 가급적 `condition ? <Component /> : null` 을 써서 명확하게 표현하라.
|
||||
|
||||
## 2. 구조 분해 할당(Destructuring) 생활화
|
||||
- `props.user.name`, `props.user.age` ... 보는 사람 숨넘어간다.
|
||||
- `const { name, age } = user;` 로 깔끔하게 정리하고 시작하라.
|
||||
|
||||
## 3. Early Return: 코드를 날씬하게
|
||||
- `if (loading) return <Loading />` 처럼 실패나 예외 케이스를 먼저 쳐내라.
|
||||
- 뒤로 갈수록 **'진짜 중요한 핵심 로직'**만 남아서 가독성이 폭발한다.
|
||||
@@ -0,0 +1,15 @@
|
||||
# 🛡️ [LEVEL 7] 테스트라는 안전망: 버그 없는 코드를 향하여
|
||||
|
||||
## 1. "내 코드는 완벽해"라는 착각을 버려라
|
||||
- 실무자는 자기 코드를 믿지 않는다, **테스트 코드**를 믿는다.
|
||||
- `Unit Test`: 함수 하나가 1+1=2를 내뱉는지 확인.
|
||||
- `Integration Test`: 컴포넌트와 컴포넌트가 만나서 잘 돌아가는지 확인.
|
||||
|
||||
## 2. Vitest & React Testing Library (RTL)
|
||||
- RTL의 철학: "사용자가 보듯 테스트하라."
|
||||
- `getByRole('button')` 처럼 사용자가 버튼을 찾듯 코드를 짜야 한다.
|
||||
- **Tip**: 내부 구현(State 값 등)이 아니라 **화면에 무엇이 나오는가**를 테스트하라.
|
||||
|
||||
## 3. TDD(Test Driven Development) 맛보기
|
||||
- 테스트를 먼저 쓰고 코드를 짜라.
|
||||
- 복잡한 비즈니스 로직일수록 TDD는 당신의 퇴근 시간을 앞당겨준다.
|
||||
@@ -0,0 +1,14 @@
|
||||
# 📡 [LEVEL 8] API 통신의 품격: 서버와 대화하는 법
|
||||
|
||||
## 1. Axios Interceptor: 공항 입입국 심사
|
||||
- 매번 API 쏠 때마다 토큰 넣고 에러 처리할 건가?
|
||||
- `interceptor`를 써서 모든 요청에 **자동으로 인증 토큰**을 붙이고, 에러 응답은 한 곳에서 처리하라.
|
||||
|
||||
## 2. HTTP 에러 핸들링 (401, 404, 500)
|
||||
- 401(미인증)이 뜨면 자동으로 로그인 페이지로 보내거나 토큰을 갱신하라.
|
||||
- 사용자는 하얀 화면이 아니라 "잠시 후 다시 시도해 주세요"라는 친절한 메시지를 원한다.
|
||||
|
||||
## 3. API 추상화 (Service Layer)
|
||||
- 컴포넌트 안에 `axios.get('/api/users')` 를 직접 쓰지 마라.
|
||||
- `userService.js` 파일을 따로 만들어 함수화하라.
|
||||
- **이점**: API 주소가 바뀌어도 파일 하나만 고치면 된다.
|
||||
@@ -0,0 +1,15 @@
|
||||
# 🎨 [LEVEL 9] 스타일 거버넌스: 디자인 시스템 구축하기
|
||||
|
||||
## 1. CSS-in-JS vs Utility-First
|
||||
- `Styled-components`: 컴포넌트 중심의 스타일링. 가독성이 좋다.
|
||||
- `Tailwind CSS`: 클래스 기반의 빠른 개발. 생산성이 미쳤다.
|
||||
- **중급의 선택**: 팀의 규모와 프로젝트 성격에 맞는 도구를 제안할 줄 알아야 한다.
|
||||
|
||||
## 2. Design Tokens: 마법의 변수
|
||||
- `#FF5733` 이라고 직접 쓰지 마라.
|
||||
- `theme.primary` 라고 변수(Token)를 써라.
|
||||
- 회장님이 "빨간색 다 파란색으로 바꿔!" 라고 할 때 1초 만에 끝낼 수 있다.
|
||||
|
||||
## 3. 반응형 디자인 (Responsive)
|
||||
- 모바일 우선(Mobile First)으로 생각하라.
|
||||
- 작은 화면에서 먼저 짜고 큰 화면으로 넓혀가는 것이 논리적으로 훨씬 간결하다.
|
||||
@@ -0,0 +1,15 @@
|
||||
# 🏗️ [LEVEL 10] 모던 스택의 선택: Vite와 Next.js
|
||||
|
||||
## 1. 전광석화 같은 개발: Vite
|
||||
- `Create React App(CRA)`은 이제 느리고 무겁다.
|
||||
- `Vite`는 브라우저의 기본 기능을 써서 서버 구동이 빛보다 빠르다.
|
||||
- **교훈**: 도구가 바뀌면 개발 경험이 바뀌고, 개발 경험은 생산성이다.
|
||||
|
||||
## 2. Server Side Rendering (SSR) & Next.js
|
||||
- 구글 검색 로봇이 내 사이트를 잘 찾게 하려면(SEO) Next.js가 필수다.
|
||||
- "깜빡임 없는 페이지 전환" + "빠른 첫 로딩"의 조화.
|
||||
- **핵심**: 언제 CSR(클라이언트)을 쓰고 언제 SSR(서버)을 쓸지 구분하라.
|
||||
|
||||
## 3. 폴더 구조의 미학
|
||||
- `components`, `hooks`, `services`, `utils`, `pages`.
|
||||
- 누가 프로젝트를 열었을 때 **"아, 여긴 뭐가 있겠구나"**라고 짐작하게 만들어라.
|
||||
@@ -0,0 +1,12 @@
|
||||
# 🚑 [LEVEL 11] 최후의 방어선: 에러 바운더리와 로깅
|
||||
|
||||
## 1. Error Boundary: 앱의 수호신
|
||||
- 컴포넌트 하나에서 에러가 났다고 전체 앱이 하얗게 죽어서는 안 된다.
|
||||
- 에러가 난 부분만 "문제가 발생했습니다"라고 보여주고 나머지는 살려둬라.
|
||||
|
||||
## 2. Sentry: 눈에 보이지 않는 버그 잡기
|
||||
- 사용자의 컴퓨터에서 나는 에러는 개발자가 알 수 없다.
|
||||
- `Sentry` 같은 도구를 연동해서, 에러가 나는 즉시 개발자에게 이메일로 제보하게 하라.
|
||||
|
||||
## 3. 사용자 경험(UX) 배려: Skeleton UI
|
||||
- 데이터 로딩 중일 때 뱅글뱅글 도는 `Spinner` 보다는, 데이터가 들어올 자리를 미리 보여주는 `Skeleton`이 심리적으로 훨씬 빠르다.
|
||||
@@ -0,0 +1,14 @@
|
||||
# 🚀 [LEVEL 12] 배포 프로토콜: 세상으로 나가는 마지막 관문
|
||||
|
||||
## 1. GitHub Actions: 비서 채용하기
|
||||
- 내가 `Push` 하면 자동으로 테스트 돌리고, 에러 없으면 배포까지 해주는 비서를 고용하라.
|
||||
- **CI(지속적 통합)**: 코드 합칠 때마다 검사하기.
|
||||
- **CD(지속적 배포)**: 코드 합치면 바로 서버에 올리기.
|
||||
|
||||
## 2. Vercel & Netlify
|
||||
- 예전에는 서버 세팅에 며칠이 걸렸다.
|
||||
- 지금은 클릭 몇 번으로 전 세계에 내 앱을 서비스할 수 있다.
|
||||
|
||||
## 3. 환경 변수(ENV) 관리: 보안의 핵심
|
||||
- API Key나 비밀번호를 절대 깃허브에 올리지 마라.
|
||||
- `.env` 파일을 쓰고, 배포 환경 설정에서 따로 관리하라. **이거 하나로 회사 기밀이 털릴 수 있다.**
|
||||
@@ -0,0 +1,14 @@
|
||||
# 💎 [LEVEL 13] 타입스크립트: 흔들리지 않는 코드의 뼈대
|
||||
|
||||
## 1. 인터페이스(Interface)와 타입(Type)
|
||||
- "이 데이터는 어떻게 생겼어?"를 미리 정의하라.
|
||||
- 오타 때문에 발생하는 멍청한 버그의 90%를 막아준다.
|
||||
- **원칙**: `any`를 쓰는 것은 코딩을 포기하는 것이다. 죽어도 `any`는 쓰지 마라.
|
||||
|
||||
## 2. 제네릭(Generic): 유연하면서도 안전하게
|
||||
- 어떤 타입이 들어올지 모르지만, 들어온 타입 그대로 내뱉고 싶을 때 사용하라.
|
||||
- 재사용 가능한 컴포넌트(`Button<T>`, `Select<T>`)를 만들 때 중급자의 실력이 여기서 드러난다.
|
||||
|
||||
## 3. 타입 추론과 좁히기(Narrowing)
|
||||
- 리액트가 타입을 똑똑하게 유추하게 도와줘라.
|
||||
- `if (user)` 처럼 타입을 좁혀서 `undefined` 에러를 원천 차단하라.
|
||||
@@ -0,0 +1,14 @@
|
||||
# ♿ [LEVEL 14] 웹 접근성: 모두를 위한 배려
|
||||
|
||||
## 1. Semantic HTML의 진정한 의미
|
||||
- `<div>` 로만 도배하지 마라. 스크린 리더는 `<div>`를 이해하지 못한다.
|
||||
- `<button>`, `<nav>`, `<main>`, `<header>`를 적재적소에 써라.
|
||||
- **이점**: 이건 단순히 착한 일이 아니라, **검색 엔진 최적화(SEO)**와 직결된다.
|
||||
|
||||
## 2. ARIA(Accessible Rich Internet Applications)
|
||||
- 표준 태그로 설명이 안 될 때 `aria-label` 등을 써서 힌트를 줘라.
|
||||
- "이 버튼은 메뉴를 닫는 버튼입니다"라고 기계에게 알려주는 배려다.
|
||||
|
||||
## 3. 키보드 네비게이션
|
||||
- 마우스 없이도 탭(`Tab`) 키만으로 내 앱의 모든 기능을 쓸 수 있게 하라.
|
||||
- 누군가에게는 이것이 세상과 소통하는 유일한 길이다.
|
||||
@@ -0,0 +1,15 @@
|
||||
# 🤝 [LEVEL 15] 협업과 거버넌스: 혼자 하는 게 아니다
|
||||
|
||||
## 1. 전설의 PR(Pull Request) 쓰기
|
||||
- "수정함" 한마디는 무책임하다.
|
||||
- **무엇을(What), 왜(Why), 어떻게(How)** 했는지, 그리고 스크린샷을 첨부하라.
|
||||
- 동료의 시간을 아껴주는 것이 최고의 실력이다.
|
||||
|
||||
## 2. 코드 리뷰 매너 (The Kodari Way)
|
||||
- 코드를 비판하되 사람은 비판하지 마라.
|
||||
- "왜 이렇게 했나요?" 보다는 "이런 방식은 어떨까요?"라고 제안하라.
|
||||
- **Pn 규칙**: P1(꼭 수정), P2(권장), P3(질문/제안) 식으로 중요도를 표시하라.
|
||||
|
||||
## 3. 문서화(Documentation): 미래의 나에게 보내는 편지
|
||||
- 복잡한 로직은 **주석**이나 **README**에 남겨라.
|
||||
- 3개월 뒤의 당신은 오늘의 당신을 절대 기억하지 못한다.
|
||||
+15
@@ -178,6 +178,21 @@
|
||||
},
|
||||
"active": "5e19c94f304a33d1",
|
||||
"lastOpenFiles": [
|
||||
"Collaboration_Governance.md",
|
||||
"Accessibility_Inclusivity.md",
|
||||
"TypeScript_Type_Safety.md",
|
||||
"Deployment_Final_Gate.md",
|
||||
"Reliability_Safety_First.md",
|
||||
"Modern_Environment_Ecosystem.md",
|
||||
"Styling_Governance.md",
|
||||
"API_Communication_Patterns.md",
|
||||
"React_Testing_Strategy.md",
|
||||
"React_Clean_Code_Best_Practices.md",
|
||||
"React_State_Management_Strategy.md",
|
||||
"React_Performance_Optimization.md",
|
||||
"Component_Design_Patterns.md",
|
||||
"React_Hooks_Deep_Dive.md",
|
||||
"React_Mental_Model.md",
|
||||
"Tetris_Project_Retrospective.md",
|
||||
"System_Debugging_Protocol.md",
|
||||
"System_Protocol_Standard.md",
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: 효율적인 API 통신 패턴 (Axios & Interceptors)
|
||||
category: Software Architecture
|
||||
tags: [API, Axios, Interceptor, Error Handling, Network]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 효율적인 API 통신 패턴
|
||||
|
||||
## 📡 인프라 설계
|
||||
- **Service Layer**: API 호출 로직을 컴포넌트와 분리하여 별도 모듈화.
|
||||
- **Interceptors**: 전역 요청 헤더 주입 및 전역 에러 핸들링.
|
||||
|
||||
## 🚨 에러 대응
|
||||
401(토큰 만료), 500(서버 장애) 등 공통 에러에 대한 중앙 집중형 대응 시나리오 수립.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[System_Protocol_Standard]]
|
||||
- [[React_State_Management_Strategy]]
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: 웹 접근성 및 포용적 설계 (a11y)
|
||||
category: Software Architecture
|
||||
tags: [Accessibility, a11y, Semantic HTML, Inclusivity]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 웹 접근성 및 포용적 설계
|
||||
|
||||
## ♿ 설계 원칙
|
||||
- **Semantic HTML**: 기계가 이해할 수 있는 의미론적 태그 사용.
|
||||
- **ARIA**: 표준 태그 외의 인터랙션에 대한 의미 보강.
|
||||
- **Keyboard Navigation**: 마우스 없이도 모든 기능 접근 가능하게 설계.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Styling_Governance]]
|
||||
- [[React_Clean_Code_Best_Practices]]
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: 협업 가이드라인 및 코드 거버넌스
|
||||
category: Software Architecture
|
||||
tags: [Collaboration, PR, Code Review, Documentation, Governance]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 협업 가이드라인 및 코드 거버넌스
|
||||
|
||||
## 🤝 협업 문화
|
||||
- **PR Protocol**: 변경 목적과 기술적 고민을 상세히 기록.
|
||||
- **Code Review**: 비판이 아닌 개선을 위한 커뮤니케이션.
|
||||
- **Documentation**: 미래의 자신과 동료를 위한 지속적인 문서 관리.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[React_Clean_Code_Best_Practices]]
|
||||
- [[Deployment_Final_Gate]]
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: 컴포넌트 설계 패턴 (Atomic & Composition)
|
||||
category: Software Architecture
|
||||
tags: [Design Pattern, Atomic Design, Composition, Architecture]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 컴포넌트 설계 패턴
|
||||
|
||||
## 🧩 구조 설계
|
||||
1. **Atomic Design**: Atom(최소 단위) -> Molecule -> Organism -> Template -> Page 순으로 조립.
|
||||
2. **Container-Presenter**: 로직 담당과 UI 담당의 분리.
|
||||
3. **Component Composition**: Props Drilling을 방지하기 위해 자식을 통째로 넘기는 전략.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Project_Architecture_Guidelines]]
|
||||
- [[Styling_Governance]]
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: 배포 프로토콜 및 CI/CD 자동화
|
||||
category: Software Architecture
|
||||
tags: [Deployment, CI/CD, GitHub Actions, Vercel, DevOps]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 배포 프로토콜 및 CI/CD 자동화
|
||||
|
||||
## 🚀 파이프라인
|
||||
- **CI (Continuous Integration)**: 빌드 및 테스트 자동화.
|
||||
- **CD (Continuous Deployment)**: 배포 자동화 (Vercel, AWS).
|
||||
|
||||
## 🔒 보안 정책
|
||||
환경 변수(`.env`) 관리를 통한 민감 정보 보호 및 보안 사고 방지.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Modern_Environment_Ecosystem]]
|
||||
- [[Collaboration_Governance]]
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: 모던 개발 환경 및 프레임워크 생태계
|
||||
category: Software Architecture
|
||||
tags: [Vite, Next.js, Ecosystem, Modern Stack]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 모던 개발 환경 및 프레임워크 생태계
|
||||
|
||||
## 🏗️ 도구의 선택
|
||||
- **Vite**: 초고속 번들링 및 개발 생산성.
|
||||
- **Next.js**: SSR/SSG 지원을 통한 SEO 최적화 및 풀스택 기능.
|
||||
|
||||
## 📁 디렉토리 구조
|
||||
프로젝트 전반의 일관성을 위한 폴더 레이아웃 표준 확립.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Deployment_Final_Gate]]
|
||||
- [[Project_Architecture_Guidelines]]
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: 리액트 클린 코드 및 개발 에티켓
|
||||
category: Software Architecture
|
||||
tags: [Clean Code, Etiquette, Best Practice, Readable Code]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 리액트 클린 코드 및 개발 에티켓
|
||||
|
||||
## 🧹 핵심 수칙
|
||||
- **Early Return**: 복잡한 조건문을 피하고 예외를 먼저 처리.
|
||||
- **Destructuring**: Props 및 데이터 구조 분해 할당으로 가독성 확보.
|
||||
- **Explicit Naming**: 변수와 함수명은 의도를 명확히 함 (e.g., `handleBtnClick` 대신 `handleSubmit`).
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Collaboration_Governance]]
|
||||
- [[System_Debugging_Protocol]]
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: 리액트 훅(Hooks) 심층 분석 및 활용
|
||||
category: Software Architecture
|
||||
tags: [React, Hooks, useEffect, Custom Hooks]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 리액트 훅(Hooks) 심층 분석
|
||||
|
||||
## 📡 useEffect의 본질
|
||||
- 단순한 라이프사이클 함수가 아니라, **외부 시스템과의 동기화** 장치임.
|
||||
- 의존성 배열(`deps`) 관리가 핵심.
|
||||
|
||||
## 🛠️ Custom Hooks
|
||||
- 컴포넌트에서 비즈니스 로직을 분리하여 재사용 가능하게 만드는 기술.
|
||||
- UI 컴포넌트는 오직 데이터 전달과 렌더링에만 집중하게 함.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[React_Mental_Model]]
|
||||
- [[React_Performance_Optimization]]
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: 리액트 핵심 멘탈 모델 (UI as a Function of State)
|
||||
category: Software Architecture
|
||||
tags: [React, State, Mental Model, Immutability]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 리액트 핵심 멘탈 모델
|
||||
|
||||
## 🎯 핵심 개념
|
||||
리액트 앱은 단순히 DOM을 조작하는 것이 아니라, **상태(State)**가 바뀌면 UI가 자동으로 업데이트되는 구조를 가집니다.
|
||||
|
||||
## 🧱 3대 원칙
|
||||
1. **Immutability (불변성)**: 상태는 직접 수정하지 않고 항상 새로운 복사본을 만들어 교체해야 함.
|
||||
2. **Declarative UI (선언형 UI)**: "어떻게"가 아니라 "무엇을" 보여줄지에 집중.
|
||||
3. **Unidirectional Data Flow (단방향 데이터 흐름)**: Props는 부모에서 자식으로만 흐름.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[React_Hooks_Deep_Dive]]
|
||||
- [[Component_Design_Patterns]]
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: 리액트 렌더링 최적화 전략
|
||||
category: Software Architecture
|
||||
tags: [Performance, Memoization, React.memo, Optimization]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 리액트 렌더링 최적화 전략
|
||||
|
||||
## ⚡ 주요 도구
|
||||
- **React.memo**: Props 변경이 없을 때 재렌더링 방지.
|
||||
- **useMemo / useCallback**: 연산 결과 및 함수 객체의 메모이제이션.
|
||||
- **Virtualization**: 대량의 리스트 렌더링 시 화면에 보이는 것만 처리.
|
||||
|
||||
## 🚨 주의사항
|
||||
성급한 최적화(Premature Optimization)는 지양하며, 반드시 성능 측정을 선행해야 함.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[WebWorker_Performance]]
|
||||
- [[System_Debugging_Protocol]]
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: 전략적 상태 관리 가이드 (Global & Server State)
|
||||
category: Software Architecture
|
||||
tags: [State Management, React Query, SSOT, Architecture]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 전략적 상태 관리 가이드
|
||||
|
||||
## 🌐 상태의 분류
|
||||
1. **UI State**: 로컬 상태 (useState).
|
||||
2. **Global State**: 전역 상태 (Context API, Zustand/Redux).
|
||||
3. **Server State**: 서버 데이터 (React Query, SWR).
|
||||
|
||||
## 🎯 원칙
|
||||
상태는 가능한 낮게(Lift State Down), 필요할 때만 높게(Lift State Up) 유지하여 복잡도를 관리함.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[React_Hooks_Deep_Dive]]
|
||||
- [[System_Protocol_Standard]]
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: 리액트 애플리케이션 테스트 전략
|
||||
category: Software Architecture
|
||||
tags: [Testing, Vitest, RTL, Unit Test, QA]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 리액트 애플리케이션 테스트 전략
|
||||
|
||||
## 🧪 테스트 피라미드
|
||||
- **Unit Test**: 개별 유틸리티/함수 검증.
|
||||
- **Integration Test**: 컴포넌트 간 상호작용 및 UI 흐름 검증.
|
||||
|
||||
## 🛠️ 도구
|
||||
- **Vitest**: 고성능 테스트 러너.
|
||||
- **React Testing Library**: 사용자 중심의 DOM 테스트 지향.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[System_Debugging_Protocol]]
|
||||
- [[Reliability_Safety_First]]
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: 애플리케이션 안정성 및 로깅 (Error Boundary)
|
||||
category: Software Architecture
|
||||
tags: [Reliability, Error Boundary, Sentry, Logging, Stability]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 애플리케이션 안정성 및 로깅
|
||||
|
||||
## 🚑 장애 대응
|
||||
- **Error Boundary**: 국소적 에러가 전체 앱을 무너뜨리지 않도록 보호.
|
||||
- **Logging (Sentry)**: 클라이언트 사이드 에러의 실시간 모니터링 및 추적.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[System_Debugging_Protocol]]
|
||||
- [[React_Testing_Strategy]]
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: 스타일 거버넌스 및 디자인 시스템
|
||||
category: Software Architecture
|
||||
tags: [Styling, Tailwind, CSS-in-JS, Design System, Responsive]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 스타일 거버넌스 및 디자인 시스템
|
||||
|
||||
## 🎨 스타일 전략
|
||||
- **Design Tokens**: 색상, 여백, 폰트를 변수화하여 유지보수성 확보.
|
||||
- **Tailwind CSS**: 유틸리티 우선 방식으로 개발 속도 극대화.
|
||||
|
||||
## 📱 반응형 설계
|
||||
Mobile First 원칙을 준수하여 상향식 미디어 쿼리 적용.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Component_Design_Patterns]]
|
||||
- [[Accessibility_Inclusivity]]
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: 타입스크립트 기반의 안정적 개발 (Type Safety)
|
||||
category: Software Architecture
|
||||
tags: [TypeScript, Interface, Type Safety, Generic]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 타입스크립트 기반의 안정적 개발
|
||||
|
||||
## 💎 핵심 장점
|
||||
- 컴파일 단계의 에러 포착으로 사후 버그 90% 이상 예방.
|
||||
- 코드 자체가 문서가 되는 자동 명세 효과.
|
||||
|
||||
## 🛠️ 고급 문법
|
||||
- **Generic**: 재사용성 높은 타입 설계.
|
||||
- **Narrowing**: 런타임 타입 검사 및 좁히기를 통한 안전한 데이터 처리.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[React_Clean_Code_Best_Practices]]
|
||||
- [[React_Hooks_Deep_Dive]]
|
||||
Reference in New Issue
Block a user