diff --git "a/6\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/6\354\236\245/\354\265\234\354\204\234\355\235\254.md"
new file mode 100644
index 0000000..23bc30e
--- /dev/null
+++ "b/6\354\236\245/\354\265\234\354\204\234\355\235\254.md"
@@ -0,0 +1,20 @@
+## Ch 6. 아이디어는 일찍 그리고 자주 검증하라
+
+### 인상 깊었던 내용
+
+> **피드백을 개방적으로 수용하라.**
+> 업무에 대해 방어적인 마인드셋을 고수하면 사람들 이 피드백을 꺼리게 되므로 피드백을 듣기 어려워진다. 그런 마인드셋을 버리고 학습을 위해 최적화하라. 피드백과 비판을 개인적인 공격이 아닌 발전의 기회로 보라.
+>
+> **코드를 일찍, 자주 커밋하라.**
+> 대규모 코드 변경은 리뷰하기 어렵고 피드백받는 데 시간이 오래 걸리며 설계 결함이 발견됐을 때 시간과 수고가 크게 낭비된다. 반복적인 진전에 집중하고 반복적인 커밋을 피드백받기 위한 유도 장치로 활용하라. 어마어마하게 많은 코드 리뷰를 보내는 사람이 되지 마라.
+>
+> **코드 리뷰를 철저한 비평가에게 부탁하라.**
+> 품질을 최적화하거나 자신의 접근법이 제대로 작동하는지 확인하고 싶다 면 철저한 비평가에게 코드 리뷰를 부탁하는 것이 훨 씬 더 레버리지가 높다. 무언가 제대로 작동하지 않 는다는 혹독한 비평은 사용자보다 동료에게 미리 받 는 것이 낫다.
+
+---
+
+### 느낀 점
+
+예전에는 개발 일정에 쫓기다 보니 PR을 세부적으로 나누기보다는 한꺼번에 올리는 일이 많았다. 커밋만 잘게 나누고 기록을 잘 해두면 괜찮다고 생각했는데, 책을 읽고 보니 그 방식이 오히려 피드백을 어렵게 만들 수 있다는 걸 깨달았다. 앞으로는 커밋뿐 아니라 PR도 더 작고 명확하게 나눠서, 빠르게 피드백을 받고 문제를 초기에 잡을 수 있도록 해야겠다고 느꼈다.
+
+또한 요즘 들어 코드 리뷰의 가치에 대해 많이 생각하고 있어, “코드 리뷰는 철저한 비평가에게 부탁하라”는 문장이 특히 마음에 남았다. 
diff --git "a/7\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/7\354\236\245/\354\265\234\354\204\234\355\235\254.md"
new file mode 100644
index 0000000..4a2d10f
--- /dev/null
+++ "b/7\354\236\245/\354\265\234\354\204\234\355\235\254.md"
@@ -0,0 +1,15 @@
+## Ch 7. 아이디어는 일찍 그리고 자주 검증하라
+
+### 인상 깊었던 내용
+
+> 프로젝트 계획에 추정을 포함시켜라. 
+추정을 바탕으로 특정 날짜에 계획한 기능을 모두 출시하는 것이 가능한지 결정해야 한다. 불가능하다면 출시할 기능 변경 또는 출시일 변경에 관해 논의해야 한다. 원하는 목표에 맞춰서 추정치를 변경하지 마라.
+>
+> 미지의 변수를 고려해서 일정을 여유 있게 잡아라. 
+의무적으로 해야 하는 다른 업무, 휴일, 병치레 등을 고려하라. 프로젝트가 길수록 이런 일이 발생할 확률이 높아진다.
+---
+
+### 느낀 점
+
+프로젝트뿐 아니라 어떤 일을 하더라도 예상보다 지연되는 일이 많았다. 돌아보면, 계획 단계에서 일의 복잡도나 소요 시간을 과소평가한 경우가 대부분이었다. 사소해 보이는 작업에도 여러 변수와 리스크가 있었지만, 이를 충분히 감안하지 못했다.
+앞으로는 감에 의존하기보다 실제 소요 시간을 기록하며 더 객관적으로 추정해야겠다고 생각했다. 또한 처음부터 여유를 두는 계획 습관이 예기치 못한 변수에 대처하는 데 중요하다는 걸 깨달았다.