diff --git "a/\354\235\264\352\260\200\354\227\260/\355\206\240\353\271\204 6\354\236\245/6.1-6.2.md" "b/\354\235\264\352\260\200\354\227\260/\355\206\240\353\271\204 6\354\236\245/6.1-6.2.md"
new file mode 100644
index 0000000..2547cff
--- /dev/null
+++ "b/\354\235\264\352\260\200\354\227\260/\355\206\240\353\271\204 6\354\236\245/6.1-6.2.md"	
@@ -0,0 +1,44 @@
+# 6.1 트랜잭션 코드의 분리 
+
+비즈니스 로직 안에 트랜잭션 코드가 들어가니 구분이 잘 안 간다. 트랜잭션과 비즈니스 로직과의 분리가 필요해보인다. 
+
+1. 메소드로 분리하기
+2. DI로 분리하기
+
+이 비즈니스 트랜잭션을 담기 위해 UserService를 상속하는 UserServiceTx를 도입하였다. 
+
+> 보통 Service와 ServiceImpl을 분리하는 이유 <br>
+> 일반적으로 구현 클래스를 바꿔가면서 사용하기 위해서이다. <br>
+> 테스트 때는 필요에 따라 테스트 구현 클래스를, 정식 운영 중에는 정규 구현 클래스를 DI 해주는것.
+
+꼭 하나의 인터페이스에 하나만 상속하라는 법은 없으니까 그럼 트랜잭션 경계 설정을 분리한 UserServiceTx를 도입해보는 것이다. 
+
+즉 요청의 흐름이 
+
+Client -> UserServiceTx -> UserServiceImpl 이 된다. 
+
+이러한 수고로 얻는 효과가 뭘까? 
+
+첫째, 비즈니스 로직을 작성할 때는 비즈니스 로직에만 집중할 수 있게 된다. 
+둘째, 비즈니스 로직에 대한 테스트를 손쉽게 만들어낼 수 있다. 
+
+두 번째에 대한 얘기를 좀 더 해보자면 독립된 단위 테스트와 관련 있다. 
+
+# 6.2 고립된 단위 테스트 
+
+테스트의 단위가 작을 수록 유리한 이유는 테스트가 실행되는 동안 실행된 메소드가 많다면 오류 원인을 찾기 힘들어지기 때문이다. 
+
+단 작은 단위로 테스트 하고 싶어도 그럴 수 없는 경우가 많은데 테스트 대상이 다른 오브젝트와 환경에 의존하고 있을 때 특히 그렇다. 
+
+복잡한 의존관계 속의 테스트는 어떻게 이루어질까? 
+
+만약 A 가 B, C, D 세 가지 객체와 의존관계를 지니고 있다면 이 의존관계를 지닌 객체들도 테스트 실행 도중 같이 실행될 것이다. 
+
+그리고 이 B, C, D 가 의존하는 다른 객체들도 실행될 것이고.. 속도가 느리고 효율이 떨어지는 테스트가 된다. 
+
+따라서 **테스트 대상 오브젝트**를 고립시키는 일이 중요하다. 이는 Mock 객체를 사용하면 된다. 
+테스트 대상이 의존하는 객체를 Mock으로 만들면 테스트 대상은 고립된 테스트 대상이 된다. 
+
+그럼 의존 객체에서 산출되는 값은 테스트에서 어떻게 검증해야 할까. 
+
+이는 A가 B에 어떤 요청을 했는지, 그 메소드 실행 여부로 판단하면 된다.