diff --git a/The_Missing_README/Chapter07.md b/The_Missing_README/Chapter07.md
index fc06891..982e614 100644
--- a/The_Missing_README/Chapter07.md
+++ b/The_Missing_README/Chapter07.md
@@ -16,3 +16,100 @@
 
 코드베이스 변경을 리뷰한다는 것은 곧 두 명 이상의 엔지니어가 한 줄 한 줄 모든 프로덕션 코드를 숙지한다는 의미다. **코드베이스에 대한 이해를 공유하는 것은 팀이 코드를 더 응집력 있게 개선하는 데 도움이 된다.**
 
+리뷰의 댓글 기록은 왜 이렇게 작성했는지 설명하는 문서로서의 역할도 수행한다. 코드가 왜 이와 같은 방식으로 작성됐는지 그 이유를 항상 명확히 이해할 수 있는 것은 아니다. 이럴 때 코드 리뷰는 세부 구현에 대한 결정 과정의 기록으로 활용할 수 있다.
+
+*일종의 문서화가 자동적으로 진행된다.*
+
+코드 리뷰의 모든 장점은 참여자가 신뢰도 높은 다른 말로 서로 믿는 관계에서 진행해야 효과가 나타난다. 형편없는 코드 리뷰는 오히려 장애물이 되기 때문에 개발속도가 더디게 된다
+
+**코드 리뷰는 얼마나 똑똑한지 증명하는 기회가 아닐 뿐더러 상대방이 관료주의적인 장애물이라고 낙인 찍는 기회도 결코 아니다.**
+
+### 코드 리뷰를 제대로 받는 방법
+
+코드가 변경되는 과정을 보면, 우선 필요한 코드를 변경하고 이를 제출한 후 승인 받아 머지하는 과정으로 이뤄진다. 이는 PR(Pull Request)를 통해 이뤄진다.
+
+#### 코드 리뷰를 받을 때 준비해야 할 사항
+
+잘 준비된 리뷰 요청은 결국 어떤 작업을 했는지 다른 개발자에게 쉽게 피드백을 전달할 수 있다. 이를 버전 제어 시스템을 통해 변경을 더욱 작게 유지하고 리팩터링 작업은 다른 리뷰로 분리하고, 테스트 등등의 작업까지 모두 포함해야 한다.
+
+#### 리뷰 초안이 있으면 위험을 낮출 수 있다
+
+초안은 어디서나 시작할 수 있는 강제성을 주기에 매우 효과적이다. 다른 양식이 아닌 일원화시키거나 체크리스트의 역할도 한다.
+
+#### 테스트 실행을 위한 리뷰 제출은 금물이다
+
+대규모 프로젝트는 복잡한 테스트 도구를 사용하는 경우가 많다. 이 경우 CI시스템을 사용하여 이 문제를 해결하기도 한다. 하지만 테스트를 실행할 목적으로 코드 리뷰를 제출하는 것은 낭비다.
+
+따라서 테스트를 로컬에서 실행할 수 있는 방법을 알아보자. 로컬에서 더욱 디버깅이 용이하기 때문에 빨리 알아낼 수 있다.
+
+#### 코드 변경사항이 많을 때는 좀 더 면밀하게
+
+변경한 코드가 많으면 다른 사람에게 설명하는 시간을 갖는 것이 좋다. 같은 멘탈 모델을 공유하고, 코드 변경사항을 이해하는 데 도움이 된다.
+
+#### 자신의 코드에 너무 집착하지 말자
+
+코드에 비판적인 의견이 달리는 것은 견디기 어려운 일이다. 그렇다고 그런 의견을 너무 감성적으로 받아들여서는 안된다. **리뷰는 코드에 대한 것이지, 개발자에 대한 것이 아니다.**
+
+#### 공감력을 갖되 무례함은 참지 말자
+
+의사소통 방식은 누구나 다르지만 무례함은 그냥 넘겨서는 안 된다. 누군가의 말이 '요점만 간단히'가 아니라 '퉁명스럽고 무례한' 방법이 될 수 있다. 리뷰어에게 자유는 허락하되, 리뷰어의 댓글이 요점을 벗어나거나 무례한 경우에는 사실대로 알려주자.
+
+#### 주도적으로 행동하자
+
+다른 사람에게 여러분의 코드를 리뷰해달라고 부탁하는 일을 너무 부끄러워 하지 말자. 리뷰어는 수많은 코드 리뷰 요청과 타켓 관련 알림을 받으므로 속도가 빠른 프로젝트에선 리뷰를 놓치는 경우도 있다.
+
+#### 코드 리뷰를 제대로 해주는 방법
+
+훌륭한 리뷰어는 리뷰 요청을 몇 단계로 나눈다. 요청을 선별함으로써, 요청의 긴급도와 복잡도를 결정하고 그 변경사항을 리뷰할 시간을 마련한다.
+
+#### 리뷰 요청을 선별하자
+
+리뷰에 대한 요청의 중요도를 선별하는 것부터 시작해야 하며, 중요도가 높으면 곧바로 리뷰를 진행해야 한다. 그 외에도 해당 팀의 선별 기준이나 리뷰어의 선호도에 따라 리뷰 요청을 선별할 수 있다.
+
+#### 리뷰를 위한 시간을 마련하자
+
+코드 리뷰는 운영 업무와 유사하다. 리뷰의 횟수와 빈도는 다소 예측 불가능하다. 리뷰 요청을 받을 때마다 하던 일이 중단돼서는 안 된다. 리뷰 시점을 잘 선택하지 않으며 리뷰를 하느라 오히려 생산성이 떨어진다.
+
+따라서 일정상에 코드 리뷰를 위한 시간을 마련해두자.
+
+#### 코드 변경사항을 이해하자
+
+다짜고짜 의견부터 남기는 식으로 리뷰를 시작해서는 안 된다. 먼저 읽어본 다음, 필요한 질문을 충분히 해본다. 결국 코드 리뷰란, 리뷰어가 해당 코드의 변경 목적을 이해할 때 비로소 그 가치가 나온다.
+
+#### 포괄적인 피드백을 제시하자
+
+**변경의 올바름, 구현, 유지보수성, 적합성, 보안성 등에 대한 피드백을 제공하라**. 스타일 가이드나 읽어 어렵다거나 헷갈리는 부분도 지적하고, 테스트 코드를 읽어보고 발생할 수 있는 버그에 대해서 조언하라.
+
+의견을 지나치게 간결하게 쓰지도 말자. 정중하게 표현하려는 방식과 그 이유를 설명하자.
+
+#### 좋은 점은 인정하자
+
+코드를 리뷰하다 보면 문제를 찾는 데만 급급해질 수 있지만 코드 리뷰가 항상 부정적일 필요는 없다. 좋은 점에 대해서도 의견을 남기자! 코드를 읽으면서 뭔가 새로운 것을 배웠다면 그 점을 언급하자.
+
+#### 이슈, 제안, 사소한 흠결은 잘 구분하자
+
+리뷰 의견은 중요도가 서로 다르다. **중립적인 제안과 사소한 흠보다는 중요한 이슈에 더 신경을 써야 한다.** 스타일에 대한 피드백을 남기는 것을 주저하지는 말되 사소한 일임을 명확히 표시하자.
+
+- 선택적 제안, 원저자에게 맡김, 승인과는 무관 등의 접두어를 사용하여 반드시 필요한 것은 아님을 표시하자.
+
+#### 대충대충 리뷰는 금물
+
+코드를 제대로 보지도 못했는데 리뷰를 승인해야 하는 부담에 시달릴 수 있다. 급한 변경이나 동료로부터의 압박, 얼핏 보기에 쉬운 듯한 변경, 반대로 변경 규모가 너무 큰 리뷰를 마주하면 이런 부담을 느낄 수 있다.
+
+따라서 그의 입장을 고감하여 리뷰를 빨리 마무리하자라고 생각할 수 있지만, 이런 유혹에 넘어가 대충 리뷰한다면 오히려 더 많은 시간을 낭비하게 된다.
+
+#### 웹 기반 리뷰 도구에만 의존하지는 말자
+
+코드 리뷰는 보통 깃허브 PR 인터페이스 같은 전용 UI로 처리한다. 이런 코드 리뷰는 단지 코드만 살펴본다는 점을 잊지 말자. 언제든 변경사항을 체크아웃하고 다운로드해서 로컬에서 실제로 실행해볼 수 있다.
+
+가능하다면 로컬에서 코드를 실행해보고, 테스트를 실행해보자.
+
+#### 테스트 리뷰도 잊지 말자
+
+테스트 코드를 먼저 읽어보고 리뷰를 시작하는 편이 유용할 때도 종종 있다. 테스트 코드는 실제 코드의 동작 방식과 사용 방법을 설명해준다. 코드의 유지보수와 간결함을 위해 테스트를 반드시 확인하자.
+
+#### 어떻게든 결론을 맺어야 한다
+
+개선사항을 너무 오래 질질 끌지는 말자. 리뷰 요청자가 신속히 승인을 받을 수 있게 도와주자. 지나치게 완벽을 추구하지는 말고 변경의 범위를 확장하지 말며 어떤 댓글이나 의견이 중요한지 명확히 묘사하고 서로 동의하지 않는 부분이 곪아 터지지 않도록 주의하자.
+
+**좋은 품질을 추구해야 하지만 고집스런 불통의 자세는 금물이다.**