diff --git "a/\354\261\225\355\204\260_7/\354\240\225\353\246\254.md" "b/\354\261\225\355\204\260_7/\354\240\225\353\246\254.md"
index a04bbbe..877b49a 100644
--- "a/\354\261\225\355\204\260_7/\354\240\225\353\246\254.md"
+++ "b/\354\261\225\355\204\260_7/\354\240\225\353\246\254.md"
@@ -102,12 +102,56 @@ Weakmap 으로 캡슐화를 하는 것은 유용한 지 모르겠다.
 
 
 
+# 7장 자바스크립트 디자인 패턴 (2/3)
 
 
+### 서준환
+
+퍼사드 패턴: 복잡한 시스템을 단순한 인터페이스로 감싸서 사용하기 쉽게 만든다. 외부와 내부의 결합도가 낮다.  
+믹스인: 댄형님이 작성한 리액트에서 믹스인이 좋지 않은 이유 아티클 참고.  
+데코레이터: 믹스인과 달리 객체 자체를 변경시키지 않는다. 타입스크립트를 쓰겠다 그냥.  
+
+
+### 백지연
 
+퍼사드 패턴: 제이쿼리 예시가 이해하기 편했다.  
+믹스인: createClass 이제 사용할 수 없어서 리액트에서 사용하기 어렵다.  
+데코레이터: 반지의 제왕 예시 이해하기 좋았다.  
+
+### 신승준
+
+믹스인: 믹스인 사용하면 타입스크립트가 메서드의 타입을 추론하지 못하더라.  
+데코레이터: 자바스크립트에서 Interface를 구현한 예시. 타입스크립트를 쓰자.  
+
+### 오혜성
 
+퍼사드: 추상화라고 이해하고 있었다.  
+데코레이터: 인터페이스를 이용한 형태로 이해했다. 타입스크립트로 재작성해봄.  
 
+### 박상범
+
+퍼사드: 선언적 프로그래밍의 기조와 비슷하다고 느낌. 너무 많은 책임을 가지면 단점이 생길수도.  
+플라이웨이트 패턴: 경량급처럼 메모리 공간의 경량화가 목표  
+
+### 변수미
+
+믹스인: 믹스인의 단점을 극복하기 위해서 문서화를 주장하지만 안쓰는게 나을 것 같다.  
+의사 클래스 데코레이터: 이렇게까지 해야하나 싶지만 타입스크립트가 없었다면 이렇게라도 해야할 것 같다.  
+데코레이터: 자바스크립트에서 잘 쓰이는지는 모르겠다. 자바에서는 자주 쓰이는 것 같다.  
+
+### 박승훈
+
+퍼사드: 엄청 실용적이라고 느꼈다. 필요한 상황이 오면 적용해 볼만 하다.
+믹스인: 메서드를 오버라이딩하는 패턴. 프로토타입을 오염시키지는 않는 것 아닌지?
+데코레이터: 매력적으로 느껴지지는 않았다. 빌더 패턴을 사용하는 것이 더욱 매력적으로 느껴짐. 파이썬의 데코레이터와 달라서 의아했다.
+추상 데코레이터: 위에서 나온 데코레이터 패턴보다 낫다고 느낌
+
+### 우창완
 
+서브 클래싱 패턴: 부모 클래스 생성자를 호출하는 것.
+믹스인: 제네릭을 사용해서 SuperClass의 타입을 보존하면 메서드의 타입도 전부 추론 가능하다. HOC도 믹스인의 일종이라고 생각했다. 많아지면 복잡도 높아질 것 같다.
+데코레이터: 상속은 컴파일 타임에 확정되지만 데코레이터 패턴은 동적으로 추가할 수 있다. 개발자의 인지부하를 높일 것 같다. 인자로 넣어주는게 무엇인지 주의해야함
+의사 클래스 데코레이터: ensureImplements까지 사용하는 것은 투머치