diff --git "a/8\354\236\245_\354\212\244\355\224\204\353\247\201\354\235\264\353\236\200_\353\254\264\354\227\207\354\235\270\352\260\200?/8.md" "b/8\354\236\245_\354\212\244\355\224\204\353\247\201\354\235\264\353\236\200_\353\254\264\354\227\207\354\235\270\352\260\200?/8.md"
new file mode 100644
index 0000000..f7d2258
--- /dev/null
+++ "b/8\354\236\245_\354\212\244\355\224\204\353\247\201\354\235\264\353\236\200_\353\254\264\354\227\207\354\235\270\352\260\200?/8.md"
@@ -0,0 +1,114 @@
+# 8장
+
+***
+# 8.1 스프링의 정의
+
+- 자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크.
+
+### 애플리케이션 프레임워크
+- 특정 계층이나, 기술, 업무 분야에 국한되지 않고 애플레케이션의 전 영역을 포괄하는 범용적인 프레임워크를 말한다.
+### 경량급
+- 불필요하게 무겁지 않다.
+- 단순한 개발툴과 기본적인 개발환경으로도 엔터프라이즈 개발에서 필요로 하는 주요한 기능을 갖춘 애플리케이션을 개발하기에 충분하다.
+
+***
+#8.2 스프링의 목적
+- 경량급 프레임워크인 스프링을 활용해서 엔터프라이즈 애플리케이션 개발을 편하게 하는 것.
+
+### 복잡함을 상대하는 스프링의 전략
+
+***기술적 복잡함을 상대하는 전략***
+- 기술에 대한 접근 방식이 일관성이 없고, 특정환경에 종속적이다.
+  - 서비스 추상화를 통해 로우레벨의 기술 구현 부분과 기술을 사용하는 인터페이스를 분리하고, 환경과 세부기술에 독립적인 접근 인터페이스를 제공하는 것이 가장 좋은 해결책이다.
+  - 스프링이 제공해주는 템플릿/콜백 패턴은 판에 박힌 반복적인 작업 흐름과 API 사용 코드를 제거해준다.
+
+- 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여서 등장한다.
+  - AOP는 최후까지 애플리케이션 로직을 담당하는 코드에 남아 있는 기술 고나련 코드를 깔끔하게 분리해서 별도의 모듈로 관리하게 해주는 강력한 기술이다.
+
+
+### 핵심 도구: 객체지향과 DI
+- 기술과 비즈니스 로직의 복잡함을 해결하는 데 스프링이 공통적으로 사용하는 도구는 객체지향이다.
+- 객체지향 설계와 프로그래밍을 가능하게 해주는 장점.
+- 서비스 추상화, 템플릿/콜백, AOP와 같은 스프링의 기술은 DI 없이는 존재할 수 없는 것들이다.
+- DI란, 특별한 기술이라기보다는 유연하게 확장할 수 있는 오브젝트 설계를 하다 보면 자연스럽게 적용하게 되는 객체지향 프로그래밍 기법이다.
+
+***
+
+#8.3 POJO 프로그래밍
+
+## POJO?
+- Plain Old Java Object
+- 간단한 자바 오브젝트를 사용 하는 것.
+- 
+## POJO의 조건
+- 특정규약에 종속되지 않는다.
+- 특정환경에 종속되지 않는다.
+
+## POJO의 장점
+- 특정한 기술과 환경에 종속되지 않는 오브젝트는 그만큰 깔끔한 코드 될 수 있다.
+- 자동화된 테스트에 매우 유리하다.
+  - 환경의 제약은 코드의 자동화된 테스트를 어렵게 한다.
+  - 그에 반해 어떤 환경에서도 종속되지 않은 POJO 코드는 매우 유연한 방식으로 원하는 레벨에서 코드를 빠르고 명확하게 테스트 할 수 있다.
+- 객체지향적인 설계를 자유롭게 적용할 수 있다.
+
+## POJO 프레임워크
+- 스프링은 비즈니스 로직의 복잡함과 엔터프라이즈 기술의 복잡함을 분리해서 구성할 수 있게 해준다.
+***
+
+#8.4 스프링의 기술
+
+***엔터프라이즈 개발에서 POJO 개발이 가능하기 위한 기술***
+- IOC/DI
+- AOP
+- PSA
+
+## IOC / DI
+- 왜 두개의 오브젝트를 분리해서 만들고. 인터페이스를 두고 느슨하게 연결한 뒤, 실제 사용할 대상은 DI를 통해 외부에 지정할까?
+- => 유연한 확장이 가능하게 하기 위해서.
+- => DI는 개방 폐쇄 원칙이라는 객체 지향 설계 원칙으로 잘 설명된다.
+
+### DI의 활용 방법
+
+- 핵심기능의 변경
+  - DI의 가장 대표적인 적용방법은 바로 의존대상의 구현을 바꾸는 것. ***전략 패턴***이 대표적인 예다.
+  - 실제 의존하는 대상이 가진 핵심기능을 DI 설정을 통해 변경하는 것이 대표적인 활용 방법.
+
+- 핵심기능의 동적인 변경
+  - DI도 기본적으로는 런타임 시에 동적으로 의존 오브젝트를 연결해주는 것이긴 하지만, 일단 DI 하게 되면 바뀌지 않는다.
+  - 다이내믹 라우팅 프록시나 프록시 오브젝트 기법을 활용한 것이다. -> 확장과 재사용이라는 장점 활용.
+
+- 부가기능의 추가
+  - 데코레이터 패턴을 생각하면 된다.
+  - 인터페이스를 두고 사용하게 하고, 실제 사용할 오브젝트는 외부에서 주입하는 DI를 적용해두면 데코레이터 패턴을 쉽게 적용할 수 있다.
+
+- 인터페이스의 변경
+  - 어댑터 패턴을 생각하자.
+  - 인터페이스가 다른 다양한 구현을 같은 방식으로 사용하도록, 중간에 인터페이스 어댑터 역할을 해주는 레이어 추가하는 방법.
+  - 서비스 추상화 (PSA) 는 클라이언트가 일관성 있게 사용할 수 있는 인터페이스를 정의해주고 DI를 통해 어댑터 역할을 하는 오브젝트를 이용하게 해준다.
+
+- 프록시
+  - 프록시 패턴을 생각하자.
+  - 필요한 시점에 실제 사용할 오브젝트를 초기화하고 리소스를 준비하게 해주는 지연된 로딩을 적용하려면 프록시가 필요하다.
+
+- 템플리과 콜백
+  - 탬플릿/콜백 패턴을 생각하자.
+  
+- 싱글톤과 오브젝트 스코프
+  - DI가 필요한 중요한 이유 중 하나는 DI 할 오브젝트의 생명주기를 제어 할 수 있다.
+  - 가장 기본이 되는 스코프는 역시 싱글톤이다. 상태를 갖지 않도록 만든 오브젝트가 동시에 여러 스레드의 요청을 처리하는 이런 방식을 적용하려면, 
+만들어지는 오브젝트의 개수를 제어하는 일이 매우 중요하다.
+  - 스프링의 DI느 기본적으로 싱글톤으로 오브젝트를 만들어서 사용하게 한다.
+  - 개발자 스스로가 일정한 스코프를 갖는 오브젝트를 만들고 이를 DI 에 적용하는 것도 가능하다.
+
+- 테스트
+  - 의존 오브젝트를 대신해서 스텁 또는 목 오브젝트 같은 테스트 대역을 활용해야 한다.
+  - DI를 위해 만든 수정자 메소드를 사용하면 테스트 코드 안에서 수동으로 목 오브젝트를 주입할 수 있다.
+
+### AOP
+- 점점 복잡해져 가는 애플리케이션의 요구조건과 기술적인 난해함을 모두 해결하는데 한계가 있다.
+- 이러한 객체지향의 기술의 한계와 단점을 극복하도록 도와주는 보조 프로그래밍 기술.
+
+### AOP 적용 기법
+
+- 스프링과 같이 다이내믹 프록시를 사용하는 방법.
+- 자바 언어의 한계를 넘어서는 언어의 확장을 이용하는 방법.
\ No newline at end of file