diff --git "a/10\354\236\245/\354\240\204\355\230\270\354\230\201.md" "b/10\354\236\245/\354\240\204\355\230\270\354\230\201.md"
new file mode 100644
index 0000000..e2c8445
--- /dev/null
+++ "b/10\354\236\245/\354\240\204\355\230\270\354\230\201.md"
@@ -0,0 +1,12 @@
+# 기억하고 싶은 문장들
+"그 사람의 존재로 인해 팀이 전체적으로 나아진다면 책임 개발자다. 그 사람의 존재로 인해 회사가 전체적으로 나아진다면 수석 개발자다. 그 사람의 존재로 인해 업계가 더 발전한다면 최고 개발자다."
+
+"업계에 입문한 초기부터 동료의 성공을 돕는 방법을 고민한다면 후이 스스로 성공을 거머쥘 올바른 습관을 기르는 셈이다."
+
+"직업적 성공은 회사와 팀의 성공에 크게 좌우되며 개인적인 기여만으로는 회사나 팀이 성공할 수 없다. 주변에 있는 이들이 우호적인 태도로 여러분과 뜻을 함께할 때 훨씬 더 많은 것을 성취할 수 있는데 그런 환경을 조성하는 열쇠는 그들의 성공에 투자하는 것이다."
+
+"어떤 프로젝트를 책임지는 유일한 개발자가 되면 자신의 가치가 올라간다는 잘못된 통념이 존재한다. 내가 가진 지식을 똑같이 아는 사람이 별로 없으면 관련 지식이 희소해지면서 더 높은 수요와 가치로 이어질 거라고 생각하는 것이다. 하지만 내가 배운 바에 따르면 코드 소유권을 공유할 때 자신뿐 아니라 팀 전체에도 혜택이 돌아돈다."
+
+# 느낀점
+
+협업을 하고, 조직에 속해있으면서 개인의 성장을 도모하는 가장 좋은 방법은 , 나의 동료를 도와주고 동료의 실력이 높아지도록 하는 것이다. 팀 프로젝트와 큐시즘을 하면서 많이 느낀다. 결국은 함께 자라기가 중요하다.
diff --git "a/8\354\236\245/\354\240\204\355\230\270\354\230\201.md" "b/8\354\236\245/\354\240\204\355\230\270\354\230\201.md"
new file mode 100644
index 0000000..e13be19
--- /dev/null
+++ "b/8\354\236\245/\354\240\204\355\230\270\354\230\201.md"
@@ -0,0 +1,40 @@
+# 기억하고 싶은 문장들
+
+"이러한 코드 품질은 저절로 전파된다. 신입 개발자들이 자신이 본 훌륭한 코드를 모델로 삼아 코드를 작성하기 때문에 긍정적인 피드백 루프가 형성된다."
+
+- 매우 공감하는 부분이다. 최근 코프링으로 개발을 꾸준히 하는데, 현업자의 리뷰와 코드를 보면서 학습하니 실력이 빠르게 느는 것을 느낄 수 있었다.
+
+"소프트웨어의 품질이 뛰어나면 조직이 확장될 수 있고 개발자가 가치를 생산하는 속도가 높아지며, 품질에 대한 투자가 부족하면 신속하게 움직일 수 없다."
+
+- 좋은 코드란 무엇일까? 추상적인 개념이지만... 좋은 코드란 이해하기 쉽고, 다른 개발자가 바로 들어와도 코드 스타일을 이해하여 이어서 개발할 수 있도록 구현하는 것이라 생각한다. 
+
+"자신이 해결하려는 일반적인 문제를 제대로 이해하기 전에 추상화를 너무 일찍 만들면 특정 유스 케이스에 과하게 맞춘 설계가 탄생할 수 있다."
+
+"나쁜 추상화는 단순히 노력을 낭비하는 데 그치지 않고 미래의 개발을 지연시키는 골칫거리가 된다."
+
+좋은 추상화의 조건
+- 배우기 쉽다.
+- 문서가 없어도 사용하기 쉽다.
+- 잘못 사용하기 어렵다.
+- 요구 조건을 충족시킬 정도로 충분히 강력하다.
+- 확장하기 쉽다.
+- 대상 사용자에게 적합하다.
+
+"단순한 것은 하나의 역할을 맡고, 하나의 작업을 수행하고, 하나의 목표르 달성하고, 하나의 개념을 다룬다고 설명한다."
+
+- 슈퍼 메서드를 만들지 말고, 하나의 역할을 하는 여러 메서드를 만드록, 파사드 패턴을 차용해 여러 메서드를 조합하자. 슈퍼 메서드에 비해 낫다.
+
+"테스트는 원래 작성자가 고려한 케이스와 코드를 호출하는 방법을 알려주는 실행 가능한 문서이기도 하다."
+
+"테스트는 원래 코드를 작성한 사람이 갓 만든 코드가 기억에 신선하게 남아 있으 때 직접 작성하는 것이 좋다."
+
+- 리스코프 치환 원칙은 테스트를 통해 검증할 수 있다.
+
+"게을러서 그런 것이든 아니면 더 빨리 배포하기 위한 의도적인 결정이든 상관없이 이런 트레이드오프가 일어날 때마다 코드베이스에는 기술 부채가 쌓일 수 있다."
+
+- 내가 이러고 있는 것은 아닐까...
+
+# 느낀점
+
+코드 품질의 중요성에 대한 챕터이다. 최근 내가 고민하는 부분과 많이 맞닿아 있어 느끼는 점이 많았다. 특히 테스트를 미루는 것과 이로 인해 쌓이는 기술 부채에 관한 내용이 인상 깊었다.
+한 번에 여러 일을 하는 메서드보단, 여러 메서드가 각자 하나의 역할로 하나의 일만 처리하도록 구현하자.
diff --git "a/9\354\236\245/\354\240\204\355\230\270\354\230\201.md" "b/9\354\236\245/\354\240\204\355\230\270\354\230\201.md"
new file mode 100644
index 0000000..a305002
--- /dev/null
+++ "b/9\354\236\245/\354\240\204\355\230\270\354\230\201.md"
@@ -0,0 +1,28 @@
+# 기억하고 싶은 문장들
+
+"안타깝게도 이런 비용을 전부 감당하기는 어렵다. 아주 똑똑하고 재능 있는 개바자라도 떠오르는 신기술에 매료되어서 다음 프로젝트에 그 기술을 도입하기를 꿈꿀 수 있다.앞으로 투입될 유지 보수 비용을 전혀 고려하지 않은 채 아직 대세가 되지 못한 새로운 시스템, 팀원 대다수가 모르는 새로운 언어, 또는 실험적인 인프라를 시도해볼 것이다. 이런 결정은 그 후 이들에게 지속적으로 비용을 부과하고 엔지니어링 효율을 떨어뜨린다."
+
+- 최근 면접에서 들었던 질문이다. 레거시 vs 신기술.. 어찌저찌 대답은 했지만, 레버리지에 관한 내용을 말했으면 더 좋은 답변이 되었을 것 같다.
+
+"반복해서 발생하는 비용에서 시간을 절약하면 가장 중요한 문제에 집중할 수 있는 자유가 생긴다."
+
+"새롭게 추가하는 기술은 시간이 지나면서 조금씩 문제를 발생시키는 게 당연합니다. 어느 순간 정신을 차리고 보면 팀 전체가 운영에 매달리고 있을 것입니다."
+
+"이펙티브 엔지니어는 단순하게 만드는 데 주력한다."
+
+"단순성은 인스타그램 팀이 확장할 수 있었던 핵심 원칙이었다."
+
+"엔지니어링 팀이 간단한 일부터 하는 데 집중하지 않으면 유지 보수 비용이 많이 드는 활동에 에너지를 쏟느라 시간이 지남에 따라 효율이 점점 떨어지거나, 운영 부담이 너무 커져서 아키텍처를 단순화할 수 밖에 없는 상황에 처한다."
+
+"더 많은 부품이 생길 대 발생하는 복잡성이 표준화에서 오는 단순성보다 뛰어난가?"
+
+"간단한 일부터 해야한다. 항상 "적은 운영 부담으로 이 작업을 완료할 가장 간단한 해결책은 무엇일까?" 라고 질문하라."
+
+"시간은 가장 가치 있는 자원이다."
+
+"예기치 못한 큰 실패에 대한 최선의 방어책은 자주 실패하는 것이다."
+
+# 느낀점
+문제를 해결하는 데 집중해야 하는데 그 기술에 집중하는 경우가 많았다. 결국 단순하게 문제를 해결하고, 복잡한 해결책이나 신기술은 정말 필요할 때만 사용하는 것이 좋다는 생각이 들었다.
+그런데 내가 겪었던 거의 모든 문제는 단순하게 해결할 수 있었다.
+대부분의 멋지고 엄청난 기술은 트레이드오프가 컸다.