diff --git "a/10\354\236\245/\353\254\270\355\235\254\354\203\201.md" "b/10\354\236\245/\353\254\270\355\235\254\354\203\201.md"
new file mode 100644
index 0000000..3a793fd
--- /dev/null
+++ "b/10\354\236\245/\353\254\270\355\235\254\354\203\201.md"
@@ -0,0 +1,51 @@
+# 10장 팀의 성장에 투자하라
+
+## ⚡️ 기억하고 싶은 혹은 인상 깊었던 내용
+- 개발자로서 더 높은 자리에 오를수록 개인적인 기여보다 주변 사람에게 미친 영향이 효과성을 측정하는 기준이 된다
+- 성공한 회사의 일원이 되면 기여한 바에 비해 더 많은 공을 인정받고 성공하지 못한 회사의 일원이 되면 기여한 바에 비해 더 적은 공을 인정받는다
+- 주변에 있는 모두를 성공하게 만드는 데 무엇보다 집중해야 한다
+
+#### 채용을 모두의 책임으로 만들어라
+- 드롭박스 초창기 개발자는 훌륭한 팀을 만드는 작업이 '전통적인' 소프트웨어 엔지니어링 작업보다 레버리지가 높을 수 있다는 것을 깨달았다
+- 효과적인 면접 절차의 두 가지 목표
+  - 회사에 잘 적응할 것 같은 유형의 지원자를 선별
+  - 지원자가 회사, 회사에서 맡을 업무, 회사의 문화에 매력을 느끼게 한다
+- 면접 절차 개선 전략(p.264)
+
+#### 온보딩 절차를 훌륭하게 설계하라
+- 처음에 좋은 경험을 하면 엔지니어링 문화에 관한 인식이 좋아지고 미래에 영향력을 행사할 능력이 형성되며 팀의 우선순위에 맞게 학습하고 활동할 수 있게 된다
+- 팀의 성공을 향한 투자가 자신의 성공 가능성도 높여준다
+- 팀이 강해지고 커질수록 코드 리뷰가 쉬워지고 버그를 수정할 인원이 더 많아지며 비상 호출 당번과 지원을 맡을 자원이 늘어나고 더 야심 찬 프로젝트에 도전할 수 있는 더 큰 기회가 생긴다
+- 온보딩 절차를 통해 달성할 4가지 목표
+  - 최대한 빠르게 신입 개발자 적응시키기
+  - 팀의 문화와 가치 전달하기
+  - 신입 개발자가 성공에 필요한 폭넓은 기초 지식 접하게 하기
+  - 신입 개발자를 사회적으로 통합시키기
+ 
+#### 코드 소유권을 공유하라
+- 어떤 프로젝트를 책임지는 유일한 개발자가 되면 자신의 가치가 올라간다는 잘못된 통념이 존재한다
+- 시스템에 관해 가장 잘 아는 사람이라는 이유로 관련 문제에 대응하는 것에 꽤 많은 시간을 쏟느라 자유시간을 가지기 어려워질 수 있다
+- 코드 소유권을 공유한다면 누구든 비상 당번을 맡을 수 있고 어떤 문제가 일어나든 책임질 수 있다
+
+#### 사후 분석으로 집단 지성을 구축하라
+- 효과적인 팀은 문제를 겪은 후 '사후 분석을 통해 사건을 분석', '그 일이 왜, 어떻게 일어났는지', '예방하려면 무슨 일을 해야할지'르 기록한다
+- 사후 분석을 방해하는 요소
+  - 출시에 대해 명확한 목표나 지표를 정의하지 않은 경우
+  - 새로운 프로젝트에 대한 부담이 커서 반성할 시간을 내기 여려운 경우
+- 팀이 얻은 교훈을 기록하려면 솔직한 대화가 바탕이 되어야 한다
+- 책임 소재를 따지는 데 집중하지 말고 제품과 팀을 발전시키겠다는 공동의 목표에 대한 공감대가 형성되어야 한다
+
+#### 훌륭한 엔지니어링 문화를 구축하라
+- 개발 주기 반복 속도 최적화
+- 끊임없이 자동화 추구
+- 소프트웨어 추상화 구축
+- 코드 리뷰
+- 존중하는 근무 환경
+- 코드 소유권 공유
+- 자동 테스트 투자
+- 꾸준히 발전하는 문화
+
+## 🫀 느낀 점
+- 코드 소유권을 공유하라 부분이 가장 인상깊었는데, 평소의 나도 프로젝트를 책임지는 유일한 개발자가 가치가 높다고 생각했었다.
+- 하지만 이는 책에서의 말처럼 자유시간을 가지기 어려우며, 함께 코드를 발전시켜갈 사람이 없다는 뜻이다
+- 앞으로 나의 코드를 누구나 쉽게 읽을 수 있는 가독성 있는 코드를 작성하는 것에 더 고민하고, 현재 진행하고 있는 프로젝트의 경우 리드미를 통해 더 쉽게 이해할 수 있는 문서를 작성하는 연습을 해야한다.
diff --git "a/8\354\236\245/\353\254\270\355\235\254\354\203\201.md" "b/8\354\236\245/\353\254\270\355\235\254\354\203\201.md"
new file mode 100644
index 0000000..c6e2432
--- /dev/null
+++ "b/8\354\236\245/\353\254\270\355\235\254\354\203\201.md"
@@ -0,0 +1,40 @@
+# 8장 품질과 실용주의 사이에서 균형을 유지하라
+
+## ⚡️ 기억하고 싶은 혹은 인상 깊었던 내용
+- 소프트웨어 품질은 결국 균형의 문제로 귀결되며, 어떻게 해야 한다고 규정된 하나의 보편적인 원칙은 존재하지 않는다
+
+#### 지속 가능한 코드 리뷰 프로세스를 만들어라
+- 코드 리뷰의 혜택
+  - 설계 결함이나 버그를 초기에 포착한다
+  - 코드 변경사항에 대한 책임감이 강해진다
+  - 좋은 코드 작서업을 배우는 모델로써 도움이 된다
+  - 코드베이스에 관한 실용적 지식을 공유한다
+  - 장기적인 작업 속도가 향상된다
+- 민첩한 코드 리뷰 프로세스
+  - 모니터를 공유하는 오버 더 숄더 리뷰
+  - 페어 프로그래밍
+  - 핵심 기능만 리뷰
+ 
+#### 추상화를 통해 복잡성을 관리하라
+- 올바른 추상화가 엔지니어링 생산성을 어떻게 높이는가
+  - 원래 문제의 복잡성을 이해하기 쉬운 원시 형태로 분해해준다
+  - 애플리케이션 유지 보수에 드는 수고가 줄고 개선사항을 적용하기 쉬워진다
+  - 어려운 문제를 한 번 해결하면 그 해결책을 여러 번 사용할 수 있다(DRY, Don't repeat yourself)
+- 하지만 추상화에 대한 과도한 투자에 대가가 따를 수 있고, 추상화를 형편없이 제작해도 대가가 따른다
+- 오픈 소스를 통해 인기있는 추상화를 찾고 개발이 쉬워지는 이유를 찾아라
+
+#### 테스트를 자동화하라
+- 광범위한 자동 테스트는 새로운 코드의 품질을 검증하고 기존 코드의 변경사항이 회귀 버그를 일으키지 않게 보호함으로써 급증한 오류율을 완화시키고 전체 오류율을 낮춘다
+- 자동 테스트는 코드를 망가뜨릴까 봐 코드 조각을 수정하거나 개선하기를 두려워하는 문화를 바꾼다
+- 레버리지가 높은 테스트, 즉 작성하는 데 든 사간에 비해 많은 시간을 절약해주는 테스트에 집중하는 것이다
+
+#### 기술 부채를 상환하라
+- 부채에 허덕이는 코드는 이해하기 어렵고 수정하기는 더 여려워 개발 주기 반복 속도가 느려진다
+- 기술 부채는 정량화하기 어렵기에 작게 시작해서 점진적으로 풀어나가는 것이 좋다
+- 그러면 작업이 너무 복잡해질 위험이 줄어들고, 기술 부채는 상환활 가치가 있다는 것을 자신과 다른 사람에게 증명할 기회가 된다
+- 기술 부채가 눈에 띌 때마다 무턱대고 상환하기보다 자신에게 주어진 제한된 시간을 레버리지가 가장 높은 부채 상환에 쓰자
+- 즉, 수정하는 데 가장 시간이 많이 드는 코드베이스에서 트래픽이 가장 높은 부분의 코드부터 살펴보자
+
+## 🫀 느낀 점
+- 8장의 코드 리뷰, 추상화, 테스트, 기술 부채 등등 모든 것들에 대한 정답은 없다
+- 반드시 해야한다는 것은 없기에 여러 방법들에 대한 트레이드 오프를 인지하고 각자의 상황에 맞는 최선의 선택을 하는 것이 올바른 방향인 것 같다
diff --git "a/9\354\236\245/\353\254\270\355\235\254\354\203\201.md" "b/9\354\236\245/\353\254\270\355\235\254\354\203\201.md"
new file mode 100644
index 0000000..b8a85c0
--- /dev/null
+++ "b/9\354\236\245/\353\254\270\355\235\254\354\203\201.md"
@@ -0,0 +1,41 @@
+# 9장 운영 부담을 최소화하라
+
+## ⚡️ 기억하고 싶은 혹은 인상 깊었던 내용
+- 인스타그램은 인수될 당시 직원이 단 13명으로 사용자 대 직원이 비율이 300만 대 1이었다
+- 반복해서 발생하는 비용에서 시간을 절약하면 가장 중요한 문제에 집중할 수 있는 자유가 생긴다
+- 확고히 검증된 기술을 선택하고 이미 있는 것들을 만드는 시간 낭비를 피했다
+
+#### 단순하게 운영하라
+- 처음 떠올리는 해결책은 매우 복잡하지만 포기하지 말고 문제를 붙들고 양파처럼 껍질을 더 벗겨내다 보면 종종 매우 우하하고 간단한 해결책에 도달할 수 있다
+- 아키텍처가 너무 복잡하면 다음 몇 가지 측면에서 유지 보수 비용이 발생
+  - 다양한 시스템에 관한 엔지니어링 전문 지식을 습득해야 한다
+  - 복잡성이 증가하면 잠재적 단일 장애점(single point of failure)이 늘어난다
+  - 신입 개발자가 새 시스템을 익히고 이해하기 어려워진다
+  - 추상화, 라이브러리, 도구를 개선하는 데 드는 노력이 여러 시스템으로 분산되어 희석된다
+ 
+#### 빨리 실패하는 시스템을 만들어라
+- 시스템이 느리게 실패하면 코드 오류의 원인이 불분명해져서 어떤 문제가 일어난 것인지 알아내기 어려워진다
+- 빨리 실패하는 시스템은 문제를 더 빨리 더 직접적으로 드러내서 소프트웨어 유지 보수, 디버깅에 드는 시간을 줄이는 데 도움을 준다
+
+#### 기계적인 작업을 꾸준히 자동화하라
+- 이 작업을 수동으로 하는 것, 이 작업을 자동화하기 위한 비용을 선불로 내는 것, 둘 중 어느 쪽을 택했을 때 전체적으로 시간이 더 절약될까를 고민해야한다
+- 자동화가 잘 이루어지지 않는 이유로는,
+  - 시간 부족, 공유지의 비극(자기 차례만 넘길 정도로 수동으로 처리하고 넘김), 자동화 도구 익숙치X, 작업 빈도 과소평가, 장기적으로 시간 절약 체감X
+- 주어진 시간이 제한적이라는 것을 고려해서 우선 메커니즘 자동화에 집중하라
+- 똑똑한 자동 의사 결정이라는 훨씬 더 어려운 문제는 쉽게 달성할 수 있는 목표를 달성한 후에 착수하는 것이 좋다
+
+#### 일괄 처리를 멱등성 있게 만들어라
+- 멱등성 있는 프로세스는 의도치 않은 부작용이 일어날 걱정 없이 필요한 만큼 얼마든지 재시도할 수 있다
+- 멱동성 있게 만들 수 없다면 적어도 일괄 처리를 재시도하거나 재진입할 수 있도록 구성하는 것이 도움이 된다
+- 이는 사용 빈도가 낮은 작업 흐름의 드라이런 실행을 매일 또는 매주 예약해서 사용 빈도가 더 높은 작업 흐름으로 변환하는 강력한 기법을 활용할 수 있다
+- 그러면 무언가 망가졌을 때 더 빨리 피드백을 받을 수 있다
+
+#### 신속하게 대응하고 복구하는 능력을 강화하라
+- 넷플릭스 개발자들은 자체 인프라 내에서 서비스를 무작위로 망가뜨리는 카오스 몽키라는 시스템을 만드는 반직관적인 작업을 했다
+- 이를 통해 아키텍처상 취약점을 찾아내고 빠르게 복구하는 능력을 기른다
+- 우리가 할 수 있는 최선은 '성공을 위한 대본'을 작성하고, 실패 시나리오를 연습하고, 신속하게 복구하는 능력을 기르는 것이다
+
+
+## 🫀 느낀 점
+- 빠르게 실패하는 시스템을 만들어야 한다는 부분이 인상적이었다. 보통의 사람들을 자신이 만든 것이 실패하는 모습을 보고 싶어하지 않아 숨기려고 할 것이다.
+- 하지만 이는 견고한 시스템을 만드는 것에 아무런 도움이 되지 않는다. 여러 실패 시나리오, 일어나지 않을 것 같은 엣지 케이스를 최대한 생각하고 대비한다면 미래에 발생할 더 큰 문제들을 사전에 해결 할 수 있을 것이다.