diff --git "a/5\354\236\245/\352\260\225\354\227\260\354\243\274.md" "b/5\354\236\245/\352\260\225\354\227\260\354\243\274.md"
new file mode 100644
index 0000000..fb9185b
--- /dev/null
+++ "b/5\354\236\245/\352\260\225\354\227\260\354\243\274.md"
@@ -0,0 +1,11 @@
+## Ch5. 영웅, 선의 그리고 프로페셔널리즘
+### 기억에 남는 부분
+1. '아니오'라고 말하는 방법 배우기
+빠듯한 개발 일정을 강요하는 프로젝트 매니저의 행동이 프로페셔널하지 않지만, 해당 일정에 대해 '해보겠다'라고 말한 개발자들도 전혀 프로답지 못했다. 이러한 상황에서, 시도해보겠다고 하거나 영웅이 되겠다는 생각을 해서 절대 안된다. 우리는 '아니오'라고 말할 수 있어야 한다.
+2. 대안 제시
+항상 '아니오'라고만 얘기하는 것은 프로다운 태도가 아니다. 모든 '아니오'에는 반드시 하나 이상의 대안들이 따라와야 한다. 최소한 브레인스토밍은 해보아야 한다. 그리고 진척 상황을 계속 공유함으로써 최선의 노력을 다하고 있음을 보여주어야 한다.
+
+### 느낀 점
+책을 읽으며 지금 진행하고 있는 밋업 프로젝트에 대입해서 생각해보았다. 백엔드 개발자로서, 프로페서널하지 못했던 상황이 두 가지 있었다.
+첫 번째로, 대안 제시이다. 데이터들을 정렬해서 보여주어야 하는데, 정렬 기준이 너무 복잡해서 구현이 불가능하다고 말한 적이 있다. 대안 제시 없이 그냥 불가능하다고 말함으로써 기획자는 이걸 대신하기 위한 정렬 방법을 오래 고민해야했다. 구현 가능한 부분은 어디까지이고, 대안을 제시했다면 기획자가 훨씬 편했을 것이라고 생각하고 미안한 부분이다.
+그리고 진척 상황 공유이다. 개발을 진행하면서, 진행 상황의 공유를 받으면 좋겠다고 처음에 기획자가 말했다. 처음에는 알겠다고 했지만, 개발을 하면서 개발자들끼리만 내용을 공유하고 구현하기 바빴다. 책을 읽으면서 진행 상황 공유가 원활히 이루어지지 않고 있다고 생각이 들고, 진행도를 알 수 있도록 내용을 항상 전달해야겠다는 반성을 했다.
\ No newline at end of file
diff --git "a/6\354\236\245/\352\260\225\354\227\260\354\243\274.md" "b/6\354\236\245/\352\260\225\354\227\260\354\243\274.md"
new file mode 100644
index 0000000..0bcfa9d
--- /dev/null
+++ "b/6\354\236\245/\352\260\225\354\227\260\354\243\274.md"
@@ -0,0 +1,14 @@
+## CH6. 동작하는 소프트웨어
+### 기억에 남는 부분
+1. 동작하는 소프트웨어만으로는 부족하다.
+장인은 꾸준히 코드 베이스를 돌보고 두려움 없이 빠르게 리팩토링을 한다. 전체 애플리케이션을 몇 분만에 테스트할 수 있는 자동화 테스트를 구축하고
+활용할 줄 안다. 단위 테스트는 코드가 제대로 구현되었는지 확인하는 가장 좋은 방법이다. 기능 구현 완료에는 단위 테스트 구현 및 테스트 완료까지 포함되어
+있어야 한다.
+2. 레거시 코드
+레거시 없이 백지 상태에서 시작하는 프로젝트는 항상 즐겁다. 오래 전에 떠나버린 개발자가 남겨놓은 코드 위에서 일하는 상황이라면
+개발자가 위축될 수밖에 없다. '처음 발견했을 때보다 더 깨끗하게'를 지속적으로 적용해야 한다. 테스트코드를 작성하고
+메서드와 클래스를 정리하며 변수명을 적합하게 바꾸는 등 점차적으로 코드를 이해하기 쉽고 다루기 편하게 만들어 갈 수 있다.
+회사가 개발자들은 정기적으로 도끼날을 가는 시간이 낭비가 아니라는 사실을 이해해야 한다.
+
+### 느낀 점
+6장 또한 밋업 프로젝트에 대해 생각해보게 하는 주제였다. 이번 프로젝트에서 처음으로 리팩토링 과정을 진행했는데, 개발 구현보다 2배 더 걸렸다. 이 과정을 통해 개발자는 코드 구현보다 리팩토링과 테스트코드 구현에 더 많은 시간과 노력을 들여야한다는 것을 몸소 깨달았고, 2차 기능 개발이 들어가기 전, 코드를 정리해서 다행이라는 생각이 들었다. 하지만 아쉬운 점은, 여전히 모든 케이스에 대해 테스트 코드를 짜지 않은 것이다. 모든 경우에 대해 API가 정상적으로 응답된다는 확신이 아직 없는데, 책을 읽고 2차 기능 개발 전 꼭 작성하고 넘어가야겠다는 다짐을 했다.
\ No newline at end of file