diff --git "a/11\354\236\245/\352\263\265\354\230\210\354\230\201.md" "b/11\354\236\245/\352\263\265\354\230\210\354\230\201.md"
new file mode 100644
index 0000000..61001c3
--- /dev/null
+++ "b/11\354\236\245/\352\263\265\354\230\210\354\230\201.md"
@@ -0,0 +1,38 @@
+**📕 Ch11. 시스템**
+
+> 큰 그림을 이해하지 못할지라도, 개인이 관리하는 구성요소는 효율적으로 돌아간다.
+
+큰 그림을 이해하지 못하더라도, 개인이 관리하는 구성요소는 효율적으로 만들 수 있고 그것이 모여 큰 그림을 이룬다는 것이 인상깊다. 프론트엔드 개발자로서 시스템 전체를 다 알지 못하더라도, 내가 만든 컴포넌트/로직이 잘 분리되어 있고 효율적으로 작동한다면 그것드이 모여 큰 시스템을 이룬다.
+결국 모듈성과 확장성의 핵심인 것 같다.
+<br>
+<br>
+> 설정 논리와 일반 실행 논리와 분리해야 모듈성이 높아진다.
+> 
+> 실행 시점에서 객체를 생성해야 할 때는 추상 팩토리 패턴을 사용한다. 생성 시점은 애플리케이션이 결정하지만 생성하는 로직은 애플리케이션이 모르게 한다.
+
+프론트엔드에서도 API 클라이언트를 설정하거나 상태관리 라이브러리를 초기화할때 설정 파일을 별도로 분리하여 설정 논리를 별도로 분리해둔다.
+<br><br>
+> 의존성 주입 : 사용과 제작을 분리하는 강력한 메커니즘.? 제어 역전에서는 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘긴다. 새로운 객체는 넘겨받은 책임만 맡으므로 SRP를 지키게 된다.
+클래스는 의존성을 해결하는 게 아니라 의존성을 주입한다.
+
+자바 기준으로 설명되어 있어 예시를 이해하기에 어려웠지만, 의존성 주입은 프론트엔드에서 hook과 비슷한 것 같다.
+컴포넌트 내부에서 직접 fetch 로직을 수행하는 것이 아니라 useUser()와 같은 커스텀훅으로 분리하면, 컴포넌트는 데이터를 사용하고, 훅은 데이터를 가져오는 책임을 지게 된다.
+<br><br>
+> 확장 : 소프트웨어 시스템은 수명이 짧다는 본질로 인해 아키텍처의 점진적인 발전이 가능하다. 
+
+이 말에 공감이 됐던 게, 최근에 개인 사이드 프로젝트를 시작하면서
+빠르게 프로토타입을 만들기 위해 Next.js + Supabase로 시작했다.
+나중에 API 서버를 따로 만들고 붙이기로 계획되어 있어 구조를 대거 변경해야하지만,
+비즈니스 로직을 분리해두면 나중에 서버 로직을 붙이기 어렵지 않을 거라는 판단이 있었다.
+
+물론… 이 판단이 아직 “겪기 전 패기”일 수도 있지만,,,
+클린코드에서 말하는 유연한 시스템 구성의 마인드를 참고하면서,
+일단은 작게, 단순하게, 확장 가능하게 만드는 걸 목표로 하고 있다.
+
+<br><br>
+> AOP(관점 지향 프로그래밍) ? 비즈니스 로직과 상관없는 공통 기능(관심사)을 분리해서 코드 중복을 줄이고, 가독성을 높이자는 철학
+
+ErrorBoundary, Suspense, Axios 인터셉터와 같이 공통 관심사를 한 곳에서 관리하는 것을 지향한다. 
+<br><br>
+> POJO ? 프레임워크나 특정 기술에 의존하지 않는, 순수한 자바 객체
+
diff --git "a/12\354\236\245/\352\263\265\354\230\210\354\230\201.md" "b/12\354\236\245/\352\263\265\354\230\210\354\230\201.md"
new file mode 100644
index 0000000..af6ec7f
--- /dev/null
+++ "b/12\354\236\245/\352\263\265\354\230\210\354\230\201.md"
@@ -0,0 +1,14 @@
+**📕 Ch12. 창발성**
+
+창발적 설계 (중요도순)
+- 모든 테스트를 실행한다.
+- 중복을 없앤다.
+- 프로그래머 의도를 표현한다.
+- 클래스와 메서드 수를 최소로 줄인다.
+
+리팩토링 전에 테스트 코드를 작성해야 한다. 그래야 두려움 없이 코드를 변경하고, 새로운 코드를 검증할 수 있다.
+응집도를 높이고, 결합도를 낮추고, 관심사를 분리하고, 시스템 관심사를 모듈로 나누고 함수와 클래스 크기를 줄이고, 더 나은 이름을 선택하기.
+
+> 나중에 코드를 읽을 사람을 바로 자신일 가능성이 높다는 사실을 명심하자.
+
+자랑스러운 코드를 남기자 ! 내가 짠 코드임에도 나중에 봤을때 이해가 어려운 경우가 많다. 다른 사람이 볼 때는 당연히 수월할 리 없다. 언제 보더라도 의도가 명확하게 보이는 코드를 작성하겠다!
diff --git "a/13\354\236\245/\352\263\265\354\230\210\354\230\201.md" "b/13\354\236\245/\352\263\265\354\230\210\354\230\201.md"
new file mode 100644
index 0000000..cac4971
--- /dev/null
+++ "b/13\354\236\245/\352\263\265\354\230\210\354\230\201.md"
@@ -0,0 +1,36 @@
+**📕 Ch13. 동시성**
+
+동시성과 깔끔한 코드는 양립하기 어렵다.
+[장점]
+1. 동시성은 결합을 없애는 전략이다. 동시성을 활용하면 프로그램은 거대한 루프 하나가 아니라 작은 협력 프로그램 여럿으로 보인다. 따라서 시스템을 이해하기 쉽고 문제를 분리하기 쉽다.
+2. 응답 시간과 작업 처리량을 개선할 수 있다.
+
+[고려해야할 점]
+1. 동시성이 항상 성능을 높여주는 것은 아니다. 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다. 오히려 다소 부하를 유발한다. 
+2. 동시성은 복잡하다.
+3. 동시성 버그는 재현하기 어렵다.
+4. 근본적인 설계 전략을 재고해야 한다.
+
+
+필자는 자바 관점에서 동시성을 설명해서 이해가 어려웠지만, 이를 자바스크립트에서도 적용해서 생각해보았다.
+<br>자바스크립트는 싱글 스레드이지만 브라우저의 Web API와 이벤트 루프 덕분에 비동기 처리가 가능하다.
+<br>이를 이용하여 동시성을 활용할 수 있지만, 주의할 점이 있다.
+<br>
+예를 들어 Promise.all을 사용하면 여러 비동기 작업을 병렬로 실행할 수 있다.<br>
+하지만 요청 간에 종속성이 있을 경우, 병렬 처리는 오히려 요청 낭비나 UX 저하를 초래할 수 있다.<br>
+<br>
+또한 비동기 요청은 응답 순서를 보장하지 않기 때문에 race condition이 발생하기 쉽다. <br>
+실제로 검색 자동완성 기능을 구현할 때, 사용자가 검색어를 빠르게 바꿨을 경우
+이전 요청이 나중에 응답되면 UI에 오래된 결과가 렌더링되는 문제가 발생할 수 있다.
+<br>AbortController를 써서 이전 요청을 취소하고 해결할 수 있다고 한다. 왜 나느 지금까지 이런 흔한 동시성 문제를 겪지 않았는지 생각해보았는데, 항상 tanstack-query를 사용하기 때문이었다.<br>
+tanstackquery는 내부적으로 AbortController를 이용해 이전 요청을 자동으로 취소하고, 동일한 쿼리 키로 중복 요청을 막아준다.
+또한 isFetching, staleTime, retry 등 다양한 상태와 타이밍 제어도 내장되어 있어,
+동시성을 직접 제어하지 않아도 안정적이고 예측 가능한 흐름을 유지할 수 있다.<br>
+그동안은 이 기능들을 그저 프레임워크가 해주는 기본 동작처럼 당연하게 사용했기에
+그 중요성을 제대로 인식하지 못하고 있었다.
+
+프론트엔드에서 동시성을 다룬다는 건 성능을 높이는 기술적 트릭보다도,
+사용자 경험을 해치지 않으면서 예측 가능한 흐름을 만들어가는 것이 중요하다는 것을 느꼈다.<br>
+클린코드에서 말한 동시성의 복잡성과 위험성은 프론트엔드에도 적용된다.<br>
+그래서 복잡함을 잘 추상화해주는 도구나 패턴을 적극 활용하고,
+설계 자체를 동시성에 맞게 정돈하는 것이 진정한 클린 코드에 가까운 길이라는 걸 느꼈다.