diff --git "a/\354\261\225\355\204\260_12/\354\230\244\355\230\234\354\204\261.md" "b/\354\261\225\355\204\260_12/\354\230\244\355\230\234\354\204\261.md"
new file mode 100644
index 0000000..494fc14
--- /dev/null
+++ "b/\354\261\225\355\204\260_12/\354\230\244\355\230\234\354\204\261.md"
@@ -0,0 +1,179 @@
+# 리액트 디자인 패턴
+
+## 리액트 소개
+
+제곧내
+
+## 고차 컴포넌트
+
+- 장점
+ - 재사용하고자 하는 로직을 한 곳에 모아 관리
+ - 관심사
+- 단점
+ - props에 대한 핸들링 (블랙박스)
+ - 파악하기 어려워짐
+
+> hook이나 후술하는 렌더링 프롭 등 대체 가능한 패턴이 많다고 생각됨
+> 고차 컴포넌트가 핏한 해결 방법인 경험이 없음
+
+## 렌더링 Props 패턴
+
+```js
+function Compo() {
+ return (
+
+ {value => {value}
}
+
+ );
+}
+```
+
+- 장점
+ - 여러 컴포넌트 사이에서 로직과 데이터를 쉽게 공유 (재사용성)
+- 단점
+ - hook으로 대체 가능
+ > 코드의 추상화 수준이 좀 높아질 수 있다? 단점은 아니겠지만 ..
+
+## Hooks
+
+알잘딱
+
+## 동적 가져오기
+
+### 로더블 컴포넌트
+
+서버 사이드의 Suspense의 대안
+https://www.npmjs.com/package/@loadable/component
+
+> 생각보다 다운로드 수가 높네용
+
+> 18 이후부터 서버 사이드에서도 Suspense 동작
+> > 그럼에도 클라이언트에서만 하고 싶다면 https://suspensive.org/ko/docs/react/Suspense#%EC%84%9C%EB%B2%84%EC%82%AC%EC%9D%B4%EB%93%9C-%EB%A0%8C%EB%8D%94%EB%A7%81%EC%9D%84-%ED%94%BC%ED%95%98%EA%B8%B0-clientonly
+
+## PRPL 패턴
+
+- Push Render Pre-cache Lazy-load
+
+- Push
+ - 중요한 리소스를 효율적으로 푸시, 서버 왕복 횟수를 최소화해 로딩 시간을 단축
+- Render
+ - 초기 경로를 최대한 빠르게 렌더링
+- Pre-cache
+ - 자주 방문하는 경로의 에셋을 백그라운드에서 미리 캐싱
+- Lazy-load
+ - 자주 요청되지 않는 것은 지연 로딩
+
+### HTTP
+
+- HTTP/1.1은 keep-alive 헤더를 통해 새로운 요청 전송 전까지 클라이언트와 서버 간의 TCP 연결을 유지하는 등 1.0에 비해 많은 개선점을 도입
+
+- HTTP/1.1은 클라이언트와 서버 간 최대 6개의 TCP 연결만 가능했음
+ - 그래서 마지막 요청이 오래 걸리면, 다른 요청을 전송할 수 없어 HOL Blocking이 발생해 로딩 시간을 증가시킬 수 있음
+ - Head-of-line Blocking
+
+- HTTP/2는 양방향 스트림을 사용
+ - 단일 TCP 연결을 통해 여러 개의 양방향 스트림을 만들어 클라이언트와 서버 간에 여러 개의 요청 및 응답 프레임을 동시에 전달할 수 있음
+
+- HTTP/2는 서버 푸시라는 데이터 가져오기 방식을 도입
+ - 매번 명시적으로 리소스를 요청하지 않고, 이런 리소스를 푸시하여 자동으로 추가 리소스를 전송할 수 있게 됨
+ > 이게 먼소리여
+
+```md
+HTTP/1.1 (기존 방식)
+
+1. 피자를 주문합니다
+2. 피자가 도착합니다
+3. 피자를 보니 콜라가 필요해서 다시 주문합니다
+4. 콜라가 도착합니다
+5. 그러다 치킨 윙이 먹고 싶어서 또 주문합니다
+6. 치킨 윙이 도착합니다
+
+이렇게 매번 필요한 것이 생길 때마다 새로운 주문을 해야 했습니다.
+
+HTTP/2 서버 푸시 (새로운 방식)
+
+1. 피자를 주문합니다
+2. 가게에서는 "아! 손님들이 보통 피자랑 콜라랑 치킨 윙을 같이 시키시더라"라고 생각하고
+3. 피자와 함께 콜라와 치킨 윙도 미리 보내줍니다
+
+즉, 서버 푸시는 웹사이트가 "이 사용자가 곧 필요할 것 같은 파일들"을 미리 보내주는 똑똑한 시스템입니다. 예를 들어:
+
+- 웹페이지를 요청하면
+- HTML 파일과 함께
+- 곧 필요할 CSS, 이미지, JavaScript 파일들도 자동으로 보내줍니다
+
+이렇게 하면 사용자가 일일이 요청하지 않아도 되니까 웹사이트 로딩이 더 빨라지죠! 🚀
+
+> 이해 완
+```
+
+- 서버 푸시는 HTTP 캐시를 인지하지 못함
+ - 그래서 웹사이트 재방문 시에는 사용할 수 없음
+ - 이를 위해 초기 로드 이후에 서비스 워커를 사용하여 해당 리소스를 캐시함으로써 클라이언트가 불필요한 요청을 하지 않도록 함
+
+```md
+
+1. HTTP 캐시와 서버 푸시의 관계
+
+중학생 철수가 문방구에서 장난감을 사는 상황으로 비유해볼게요:
+첫 방문 시:
+철수: "로봇 장난감 하나 주세요!"
+문방구 아저씨: "여기 로봇이요! 아, 그리고 보통 애들이 건전지랑 스티커도 같이 사니까 이것도 드릴게요!" (서버 푸시)
+
+재방문 시:
+철수: "어제 산 로봇이랑 똑같은 거 주세요!"
+문방구 아저씨: "어! 철수야, 너 이미 건전지랑 스티커 있을 텐데... 근데 난 그걸 모르니까 또 줘버렸네..."
+
+2. 왜 서비스 워커가 필요할까?
+
+서비스 워커는 마치 철수의 '장난감 노트'같은 거예요:
+📝 철수의 장난감 노트 (서비스 워커)
+- 로봇 장난감 ✅
+- 건전지 ✅
+- 스티커 ✅
+
+이제 철수가 다시 문방구에 갈 때:
+
+노트를 먼저 확인해서 "아, 이미 있는 거네!"
+필요한 것만 달라고 할 수 있어요
+
+정리하면:
+HTTP 서버 푸시는 사용자의 브라우저에 뭐가 있는지 모르고 무조건 다 보내요 (비효율적)
+서비스 워커는 브라우저에 뭐가 있는지 기록해두고, 필요한 것만 요청할 수 있게 해줘요 (효율적)
+이렇게 서비스 워커가 똑똑한 메모장 역할을 해서, 불필요한 데이터를 또 받지 않아도 되는 거예요! 🎯
+
+> 개쩐다
+```
+
+> 저자가 브라우저 개발자라 그런지 이런건 빠삭한 느낌..?
+
+## 로딩 우선순위
+
+- 에셋은 `rel='preload'`
+- 자바스크립트 자체의 로딩을 최적화 -> `` 안에 `