diff --git "a/5\354\236\245/\355\231\251\353\217\231\354\244\200.md" "b/5\354\236\245/\355\231\251\353\217\231\354\244\200.md"
new file mode 100644
index 0000000..6bd5e1e
--- /dev/null
+++ "b/5\354\236\245/\355\231\251\353\217\231\354\244\200.md"
@@ -0,0 +1,26 @@
+## 5장 영웅, 선의 그리고 프로페셔널리즘
+
+### 중요하다고 생각한 내용과 나의 생각
+
+107
+우리는 프로페셔널하지 못했다. 우리가 왜 그 일을 하는지 스스로 묻지 않았다. 고객이 실제로 무엇을 원하는지 이래하려 하지 않았고, 다른 대안을 제시하지도 않았다. 고객을 만날수도 없기는 했지만, 요구사항에 대해서 질문을 하지도, 실행할 수 없다는 이야기도 하지 않았다. 우리는 그냥 주어진 환경을 있는 그대로 두고, 무작정 일을 밀어 붙였다. 그때는 그것이 프로페셔널이라고 생각했다.
+우리가 노예처럼 일할 때, 영업, 비즈니스 부서 사람들은 항상 정시에 퇴근해 가족과 시간을 보냈다.
+-> 그저 순응하는 것이 아닌 나 자신이 할 수 있는 정도를 파악하고 함께하는 팀원에게 이야기하는 것도 정말 중요하다는 생각이 들었습니다.
+
+114
+개발자들이 일정이 너무 짧다고 이야기를 해도 관리자들이 그냥 흘려 들을 때가 많다. 관리자와 개발자 간에 협상이 되어야 하지만 협상 기술이나 제대로 된 근거 자료가 부족해서 개발자들이 압ㄺ에 그냥 굴복하고 말 떄가 부지기수다
+개발자들은 논쟁하고 싶디 않아서 또는 긍정적인 태도를 보여주고 싶어서 "최선을 다해 노력하겠다"라고 대답해버린다.
+-> 평소에 소통하는 능력을 어느정도 갖추고 있다고 생각하는데 취업시장에서 이러한 점들을 강점으로 어필하면 좋을거 같다는 생각이 들었습니다.
+
+116
+항상 '아니오'라고만 얘기하는 것은 프로다운 태도가 아니다.
+모든 '아니오'에는 반드시 하나 이상의 대안들이 따라와야 한다.
+-> 매우 중요하다고 생각합니다.
+
+118
+무언가 약속은 할 수 없더라도 문제 대응이 어떻게 되고 있는지 진척 상황을 계속 공유해야한다.
+
+122
+최대한 이른 시점에 붉은 깃발을 세워서 뭔사 잘못되고 있음을 지적하고 팀과 다른 사람들로 하여금 현실적인 다른 대안을 찾아 나설 수 있도록 해야 한다.
+-> 현재 진행하고 있는 밋업 프로젝트에서 애자일 방식으로 프로젝트를 진행하고 있는데 불확실성이 큰 요구사항에 대해 살짝 어려울거 같다는 이야기는 했지만, 해보겠다고 했는데, 이런 상황에서 문제가 생긴다면 빠르게 전해야겠다고 생각이 들었습니다.
+-> 혹시 이렇게 할 수 있을지 없을지 잘 판단이 안서는 요구사항에 대해서는 어떻게 대처하는 것이 좋은지 궁금하기도 합니다.
diff --git "a/6\354\236\245/\355\231\251\353\217\231\354\244\200.md" "b/6\354\236\245/\355\231\251\353\217\231\354\244\200.md"
new file mode 100644
index 0000000..9ed8a2f
--- /dev/null
+++ "b/6\354\236\245/\355\231\251\353\217\231\354\244\200.md"
@@ -0,0 +1,25 @@
+## 6장 동작하는 소프트웨어
+
+### 중요하다고 생각한 내용과 나의 생각
+
+126
+전통적인 관리자들과 비즈니스 컨설턴트들이 절차와 문서의 중요성을 아무리 강조하고 싶어하더라도 소프트웨어 프로젝트에는 소스 코드 그 자체만큼 중요한 것은 없다. 나머지는 모두 부차적이다.
+
+128
+코드는 기계장치라기보다는 유기물이다. 코드는 정원처럼 지속적인 유지보수가 필요하다.
+
+130
+나쁜 코드를 다루어야 하는 기업은 경쟁력이 떨어지게 된다.
+
+132
+기술적 부채를 줄이는 것은 기존의 더러운 것을 청소하는 것이다. 이미 깨끗한 상태를 더럽혀서는 안된다. 즉 어떤 상황이든 추가 코드로 인해 기술적 부채가 더해져서는 안 된다. 하지만 이 개발자는 그렇게 해도 된다고 생각하고 있었다.
+-> 해당 개발자처럼 잘못된 이해와 지식에 확신을 가지는 것에 주의해야 겠다는 생각을 했습니다.
+
+133
+빨리 하는 것과 허술한 것은 다르다. 우리의 결정이 어떤 의미이고 어떤 결과를 가져오는지 우리는 잘 이해하지 못할 때가 많다.
+
+137
+테스트하지 않았다면 코드 작성을 완료했다고 할 수 없다. 단위 테스트는 코드가 제대로 구현되었는지 확인하는 가장 좋은 방법이다.
+테스트 주도 개발을 접해보지 못한 보통의 개발자들은 주어진 요구사항에 맞춰 동작할 거라고 '기대만 하는' 상태로 코드를 작성하고는 바로 다음 요구사항의 구현에 들어간다. 즉 제대로 된 테스트 없이 코딩을 마무리한다. 기능 구현이 완료되었다고 할 수 있으려면 반드시 테스트까지 되어야 한다.
+-> 현재 TDD 방식으로 개발을 진행하고 있는데 생각보다 쉽지 않고, 함께하는 팀원은 어려울거 같다고 해서 일단 저만 진행하고 있는데 이 글을 읽고, 다음 스프린트에서 요구사항 정의와 레드 단계의 테스트 코드를 작성하여 팀원도 같이 TDD를 할 수 있게 해야겠다는 확신이 생겼습니다.
+-> 그리고 필자가 작성한 것처럼 테스트 코드를 작성하는 것까지 기능구현의 단계로 생각해여 개발해야 겠다는 생각 또한 들었습니다.