diff --git "a/\354\261\225\355\204\260_10/\354\230\244\355\230\234\354\204\261.md" "b/\354\261\225\355\204\260_10/\354\230\244\355\230\234\354\204\261.md"
new file mode 100644
index 0000000..4432f64
--- /dev/null
+++ "b/\354\261\225\355\204\260_10/\354\230\244\355\230\234\354\204\261.md"
@@ -0,0 +1,69 @@
+# 모듈형 자바스크립트 디자인 패턴
+
+## AMD
+
+- CommonJS의 모듈 형식에 대한 사양 초안으로 시작됐지만, 합의점을 이루지 못해 amdjs 그룹으로 넘어감
+  
+- 모듈과 의존성 모두를 비동기적으로 로드할 수 있도록 설계된 모듈 정의 방식
+
+## CJS
+
+- 2009년 ServerJS 프로젝트에서 만들어진 형식, 이후 CommonJS 그룹에 의해 공식화됨
+
+## VS
+
+- AMD
+  - 브라우저 우선 접근 방식을 채택하여 비동기 동작과 간소화된 하위 호환성을 선택
+  - 반면 파일 IO에 대한 개념이 없음
+  - 객체, 함수, 생성자, 문자열, JSON 등 다양한 형태의 모듈을 지원
+
+- CJS
+  - 서버 우선 접근 방식을 취함
+  - 동기적으로 작동
+  - 전역 변수와의 독립성
+  - 언래핑된 모듈을 지원하기 때문에 ES 표준에 조금 더 가깝게 느껴짐
+
+> 여기서 말하는 언래핑된 모듈?
+
+```js
+// wrapped-module.js
+define(['dependency1', 'dependency2'], function(dep1, dep2) {
+    var privateVar = "비공개 변수";
+    
+    return {
+        publicMethod: function() {
+            return "공개 메서드";
+        }
+    };
+});
+
+// unwrapped-module.js
+var dep1 = require('dependency1');
+var dep2 = require('dependency2');
+
+var privateVar = "비공개 변수";
+
+exports.publicMethod = function() {
+    return "공개 메서드";
+};
+
+// 문법적 차이
+// 래핑된 모듈: define() 함수로 전체 모듈을 감싸야 함
+// 언래핑된 모듈: 일반 JavaScript처럼 직접 코드를 작성
+
+// 의존성 관리
+// 래핑된 모듈: 의존성을 배열로 한번에 선언
+// 언래핑된 모듈: 필요한 곳에서 직접 require()로 호출
+```
+
+## UMD
+
+- 브라우저와 서버 환경에서 모두 작동할 수 있는 모듈을 위해 개발
+
+- UMD는 AMD나 CommonJS를 대체하기 위한 것이 아니라, 오늘날 다양한 환경에서 동작할 수 있도록 돕는 보조 도구
+
+## 내 생각
+
+Node.js 환경도 13.2.0 이후부터 ES 모듈을 정상적으로 사용할 수 있으니 앵간해서는 ES 모듈을 사용하는게 좋지 않을까 생각됨
+
+- CJS 트리쉐이킹 안되는 것은 다른 분이 설명해주실 것으로 예상
\ No newline at end of file
diff --git "a/\354\261\225\355\204\260_11/\354\230\244\355\230\234\354\204\261.md" "b/\354\261\225\355\204\260_11/\354\230\244\355\230\234\354\204\261.md"
new file mode 100644
index 0000000..9952e45
--- /dev/null
+++ "b/\354\261\225\355\204\260_11/\354\230\244\355\230\234\354\204\261.md"
@@ -0,0 +1,109 @@
+# 네임스페이스 패턴
+
+- 네임스페이스는 코드 단위를 고유한 식별자로 그룹화한 것을 뜻함
+
+## 단일 전역 변수 패턴
+
+```js
+const myUniqueNamespace = {};
+```
+
+## 접두사 네임스페이스 패턴
+
+```js
+const foo_property = {};
+```
+
+## 객체 리터럴 표기법 패턴
+
+```js
+const myUnique = {
+  getInfo: () => {}
+  models: {};
+}
+```
+
+## 중첩 네임스페이스 패턴
+
+```js
+foo.util.DOM.getElementById('bar');
+```
+
+## 즉시 실행 함수 표현식 패턴
+
+```js
+const namespace = {};
+
+((n) => {
+  n.foo = 'foo';
+})(namespace)
+```
+
+## 네임스페이스 주입 패턴
+
+```js
+const namespace = {};
+
+(() => {
+  this.foo = 'foo';
+}).apply(namespace);
+```
+
+- 객체/클로저 내에서 명시적으로 선언할 때 직접 접근이 불가능한 상황에서만 사용하는 것을 추천
+
+## 고-급 네임스페이스 패턴
+
+
+### 중첩 네임스페이스 자동화 패턴
+
+```js
+const namespace = {};
+const mod = extend(namespace, "module1.module2.module3");
+
+console.log(mod === namespace.module1.module2.module3); // true
+```
+
+### 의존성 선언 패턴
+
+```js
+const namespace = {
+  // 대충 여기에 중첩된 거 많음
+};
+
+const util = namespace.DOM.util;
+util.getById('bar');
+```
+
+- 로컬 변수를 사용하는 것이 전역 변수에 매번 접근해 사용하는 것보다 빠름
+> 이전 챕터에서 공유한 것처럼 체이닝을 덜하는 이점도 있을 것이라 생각
+
+
+## 내 생각
+
+- ES 모듈을 이용하는 현대적인 환경에서 전역 네임스페이스를 고려하는 환경이 있을까 싶음
+  - 너무 내가 어플리케이션 레이어 개발자인가 ;;
+
+- 코드 스니펫 정도에서 배워가는 건 있었다고 생각 (살짝)
+
+- 의존성 선언 패턴(이게 이름이 적절한지는 모르겠는데)이 좋은 건 알겠으나, 가독성 측면에서 좋지 않다고 느낀 경험
+
+```tsx
+const UserCard = () => {
+  const { data: {
+    foo: {
+      name
+    }
+  } } = useSuspenseQuery(대충getUserQuery);
+
+  return <div>{name}</div>
+}
+
+// 간단한 형태라면 이렇게 사용해도 좋겠으나
+
+const ComplexUserCard = () => {
+  const { data: user } = useSuspenseQuery(대충getUserQuery);
+
+  // 복잡한 형태라면 해당 줄만 읽어도 출처를 알 수 있는 형태가 좋았던 경험이 있음
+  return <div>{user.foo.name}</div>
+}
+```
\ No newline at end of file