diff --git "a/6\354\236\245/\352\263\265\354\230\210\354\230\201.md" "b/6\354\236\245/\352\263\265\354\230\210\354\230\201.md"
new file mode 100644
index 0000000..dd9232f
--- /dev/null
+++ "b/6\354\236\245/\352\263\265\354\230\210\354\230\201.md"
@@ -0,0 +1,8 @@
+**📕 Ch6. 아이디어는 일찍 그리고 자주 검증하라**
+> 제품 변경 시 흔히 제기되는 문제는 지표에 변화가 관찰되더라도 제품 출시가 지표의 상승(또는 하락)에 얼마나 영향을 준 것인지 확신할 수 없다는 것이다.
+최근 상용화된 서비스에 합류하여 새 기능을 배포하였다. 실제 기능을 출시하면 뿌듯하고 짜릿할 줄 알았는데 크게 느껴지는 바가 없었다. 이유를 생각해보면 내가 출시한 이 기능이 소비자에게 어떤 변화를 가져오는지 파악할 만한 분석 도구가 없고, 정량화할 지표가 없어서 그런 것 같다.
+개발하고 끝! 이게 아니라 내 기능을 소비자가 내가 의도한 대로 잘 사용하고 있는지, 어떤 효과가 있는지 모니터링하고 분석하는 데에도 투자해야겠다고 생각했다.
+
+> A/B 테스트는 제대로 수행하면 제품 아이디어를 검증하고, 있는 그대로는 이해할 수 없는 사용자 행동 데이터라는 블랙박스를 이해하고 실행할 수 있는 지식으로 변환하는 데 도움이 된다.
+실제로 도입해보고싶은 테스트방식이다. 특히나 사용자 경험에 관련해서는 팀원들과 정말 의견이 분분한데다 대부분 확고하다. 그렇게 하면서 느낀점은 아무리 팀원들과 이렇네저렇네 토론해봐도 결국 정답은 아무도 모른다는 것이다. 빠르게 도입하고 실험해보고 디벨롭하는 게 훨씬 효율적이라는 생각이 든다.
+
diff --git "a/7\354\236\245/\352\263\265\354\230\210\354\230\201.md" "b/7\354\236\245/\352\263\265\354\230\210\354\230\201.md"
new file mode 100644
index 0000000..93116c1
--- /dev/null
+++ "b/7\354\236\245/\352\263\265\354\230\210\354\230\201.md"
@@ -0,0 +1,13 @@
+# **📕 Ch7. 프로젝트 추정 기술을 향상시켜라**
+> 우리가 추정을 종종 ‘실현 가능성이 0이 아닌, 가장 낙관적인 예측’으로 생각한다.
+> 우리가 의존하는 정보는 불완전하므로 추정을 최상의 시나리오부터 최악의 시나리오까지 아우르는, 결과 범위에 대한 확률 분포라고 생각해야 한다.
+공감이 가는 내용이다. 개발자들은 대부분 업무를 과소평가한다. 대부분은 자신이 생각한 시일에 맞추려면 밤을 새야한다. 이를 인지하고 보다 정확한 추정을 할 수 있도록 노력해야한다.
+
+> 시간 제약이 없는 활동에 정해진 양의 시간, 즉 타임 박스를 배정하라. 조사에 3일 정도 걸린다고 추정하지 말고, 3일 이내에 찾은 데이터를 기반으로 최선의 결정을 내리려고 노력하라.
+시간 제약이 없는 활동에 지나친 리소스를 들지 않으면서 효율적으로 처리할수 있는 방법인 것 같다.
+
+> 첫째, 잘 정의해둔 목표는 작업 목록에서 꼭 해야 할 일과 하면 좋은 일을 구분하는 중요한 필터가 된다.
+> 목표가 구체적일수록 기능을 구별하는 데 도움이 된다
+> 필요한 작업, 미뤄야 할 작업, 나중에 점진적으로 추가할 작업에 관해 공통의 이해를 형성할 수 있다.
+목표 설정하기는 당연한 듯한 절차이면서도 잘 지켜지지 어려운 사항인 것 같다. 목표를 구체적으로 잘 세우는 것이 중요하다고 느꼈다. 구체적인 목표는 이번 스프린트의 크기를 불필요하게 키우지 않으면서 모든 팀이 한 방향으로 나아가게끔 하는 것을 경험했다. 새로운 아이디어가 생겨서 이걸 추가하면 어떨까? 싶을때 그건 다음 스프린트, 백로그에 추가하는 것으로 빠르게 의사결정을 내릴 수 있게 된다. 
+