diff --git "a/\354\261\225\355\204\260_10/\353\260\225\354\212\271\355\233\210.md" "b/\354\261\225\355\204\260_10/\353\260\225\354\212\271\355\233\210.md"
new file mode 100644
index 0000000..4c9b075
--- /dev/null
+++ "b/\354\261\225\355\204\260_10/\353\260\225\354\212\271\355\233\210.md"
@@ -0,0 +1,167 @@
+## 들어가며
+
+- 모듈형 : "서로 의존성이 낮은 기능들이 모듈로써 저장된 형태"
+- 느슨한 결합은 의존성을 제거하여 앱의 유지보수에 용이
+
+## 스크립트 로더
+
+- 모듈형 JS를 구현하기 위한 핵심도구
+- 호환 가능한 스크립트 로더를 사용해야만 모듈형 JS 구현 가능
+
+
+## AMD
+
+- Asynchronous Module Definition
+- 모듈과 의존성 모두를 비동기적으로 로드할 수 있도록 설계된 모듈 정의 방식
+- 주요 목표 : 개발자들이 활용할 수 있는 모듈형 JS 솔루션 제공
+- JS 모듈화를 위한 주춧돌
+
+
+### AMD의 구조
+
+- define() : 모듈을 정의하는 함수
+- require() : 모듈을 로드하는 함수
+
+
+```javascript
+define('module', ['dependency'], function(dependency) {
+    return {
+        method: function() {
+            dependency.method();
+        }
+    };
+});
+
+require(['module'], function(module) {
+    module.method();
+});
+```
+
+
+### AMD 결론
+
+- 탄탄한 애플리케이션 작성에 여러 장점을 제공
+- 전역 객체의 사용을 최소화
+- 변수에 모듈을 할당 가능
+- 의존성 관리 측면에서 효율적
+
+
+### 나의 생각
+
+AMD는 사용할 일이 없어서 조금 어려운 감이 있네요. 예제에는 더 다양한 예시와 설명들이 있는데 가볍게 훑고 지나간 것 같습니다.
+
+
+## CommonJS
+
+- 서버 사이드에서 모듈을 선언하는 간단한 API를 지정하는 모듈 제안
+- AMD와는 달리 I/O, 파일시스템, 프로미스 등 더욱 광범위한 기능 제공
+
+
+### CommonJS의 구조
+
+- 모듈을 함수로 감싸는 작업이 불필요(AMD의 define과 달리)
+- exports 객체를 통해 다른 모듈에 내보내고자 하는 객체를 담음
+- require() 함수를 통해 다른 모듈을 불러옴
+
+
+```javascript
+var lib = require('package/lib');
+
+function foo() {
+    lib.log('hello world');
+}
+
+exports.foo = foo;
+```
+
+만약 위의 코드를 AMD로 구현했다면?
+
+```javascript
+// 정적 의존성
+define(['package/lib'], function(lib) {
+    function foo() {
+        lib.log('hello world');
+    }
+
+    return {
+        foo: foo
+    };
+});
+
+// 동적 의존성
+define(function(require) {
+    var lib = require('package/lib');
+
+    function foo() {
+        lib.log('hello world');
+    }
+
+    return {
+        foo: foo
+    };
+});
+```
+
+
+### Node.js 환경에서의 CommonJS
+
+- Node.js 환경에서는 CommonJS가 기본 형식으로 사용됨
+- Node.js 버전 13.2.0 이후의 안정적인 버전에서는 ES 모듈도 지원
+  - 최근에는 ES 모듈 형식이 재사용 가능한 JS 코드를 모듈화하는 표준으로 자리잡음
+
+
+#### Node.js가 CommonJS를 모듈로 인식하는 경우
+
+- .cjs 확장자
+- package.json 파일에 "type": "commonjs" 속성이 있거나 type 항목이 없을 때 .js 확장자
+- .mjs, .cjs, .json, .node, .js 이외의 확장자를 가진 파일
+
+
+#### 메서드에 따라 다른 모듈 로더
+
+- require : 항상 CommonJS 모듈 로더 사용
+- import : ECMAScript 모듈 로더 사용
+
+
+#### CJS / ESM 호환성
+
+- 많은 Node.js 라이브러리와 모듈은 CommonJS 형식으로 작성되어 있음
+- 브라우저 호환을 위해 모든 주요 브라우저에서는 ESM 문법 지원
+- Babel 등의 트랜스파일러를 사용해 구버전 Node.js에서도 작동하는 require() 함수로 변환 가능
+- **정리 : ES6 모듈 문법으로 작성된 라이브러리를 Node.js에서 실행하는 경우 내부적으로 CommonJS로 트랜스파일링됨**
+
+
+### AMD vs CommonJS
+
+> AMD, CommonJS는 서로 다른 목표를 가진 유효한 모듈 형식
+
+#### AMD
+
+- 브라우저 우선 접근 방식 채택
+- 비동기 동작과 간소화된 하위 호환성을 선택
+- 파일 I/O에 대한 개념 없음
+- 객체, 함수, 생성자, 문자열, JSON 등 다양한 형태의 모듈 지원
+- 브라우저에서 자체적으로 실행된다는 점에서 유연한 포맷
+
+#### CommonJS
+
+- 서버 우선 접근 방식
+- 동기적 작동, 전역 변수와의 독립성, 미래의 서버 환경 고려
+- CommonJS가 언래핑된 모듈을 지원하기 때문에 ES2015+ 표준에 조금 더 가깝게 느껴짐
+
+
+### 나의 생각
+
+AMD 파트에서는 진짜 막막했는데, CommonJS부터는 눈이 조금씩 트이는 기분이었어요. 나중에 ESM, 혹은 더 진보된 무언가가 나온 미래에는 CommonJS도 "뭐야 저게?"하는 날이 올까 싶네요ㅋㅋㅋ Node.js 기반 라이브러리나 옛날 코드를 볼 때 require 방식의 cjs를 많이 보게 되는데, CommonJS에 대해 조금 알고 넘어간다는 것에 의미를 두고 싶어요.
+
+
+## 마치며
+
+> 이런 모듈 형식들은 단순히 모듈 패턴만 사용하는 것보다 장점이 있다.
+
+- 전역 변수 관리의 필요성 감소
+- 정적/동적 의존성 관리에 대한 향상된 지원
+- 스크립트 로더와의 높은 호환성
+- 서버 환경에서의 모듈 호환성 강화
+
+
diff --git "a/\354\261\225\355\204\260_2/\b\354\232\260\354\260\275\354\231\204.md" "b/\354\261\225\355\204\260_2/\354\232\260\354\260\275\354\231\204.md"
similarity index 100%
rename from "\354\261\225\355\204\260_2/\b\354\232\260\354\260\275\354\231\204.md"
rename to "\354\261\225\355\204\260_2/\354\232\260\354\260\275\354\231\204.md"