diff --git "a/4\354\236\245/\354\240\204\355\230\270\354\230\201.md" "b/4\354\236\245/\354\240\204\355\230\270\354\230\201.md"
new file mode 100644
index 0000000..e8b6d73
--- /dev/null
+++ "b/4\354\236\245/\354\240\204\355\230\270\354\230\201.md"
@@ -0,0 +1,21 @@
+#  기억하고 싶은 문장들
+
+"마지막으로 프로그래밍은 소프트웨어 개발 프로세스의한 요소에 불과하기 때문에, 자신의 업무에서 엔지니어링 외적인 병목 요소를 알아내는 것이 중요한 이유에 대해서 살펴볼 것이다."
+
+- 프로그래밍은 소프트웨어 개발 프로세스의 한 부분인데, 난 프로그래밍이 전부인 것 처럼 항상 생각을 해왔음을 다시 깨닫게 해준 문장이다.
+
+"MOVE FAST AND BREAK THINGS(망가뜨려도 좋으니 빠르게 실행하라)."
+
+"개발 주기를 빠르게 반복할수록 무엇이 더 효과적인지 더 많이 배울 수 있다. 그리고 더 많은 것을 만들고 더 많은 아이디어를 시도할 수 있다. 물론 모든 변화가 긍정적인 가치와 성장으로 이어지는 것은 아니다. 페이스북의 초기 광고 제품이었던 비콘은 외부 웹사이트에서 사용자가 한 활동을 페이스북에 자동으로 공개했다. 해당 서비스는 엄청난 논란을 일으키고 중단됐다. 즉, 개발 주기가 반복될 때마다 어떤 변화가 우리를 올바른 방향으로 이끌지 배울 수 있고, 향후의 노력이 훨씬 더 큰 효과를 낼 수 있게 된다."
+
+- 소프트웨어 제품을 만드는 것의 가장 큰 장점은 제품을 고객에게 내보일 수 있는 주기가 매우 짧다는 것이다. 그러므로 빠르게 배포하고 유저의 반응을 살피고, 다시 수정하는 과정을 거치는 것이 중요함을 알게 해주는 문장이었다. 이게 소프트웨어가 가지는 가장 큰 장점이라 생각한다. 다른 산업군은 한번 내보이면, 고객 반응을 살피고 다시 제품을 만들어 내보이는 주기가 매우 길기에 소프트웨어 개발을 하는 입장에서 소프트웨어 제품이 가지는 장점을 잘 활용해야겠다.
+
+"버그를 수정하거나 기능을 개발하는 중인데 문득 똑같은 동작을 반복하고 있다는 것을 깨달았다면 잠시 멈춰라. 그리고 테스트 과정을 더 짧게 만들 수 없을지 잠시 생각할 시간을 가져라. 이렇게 하면 장기적으로 시간이 절약될 것이다."
+
+- 내가 하는 일이 반복적인지, 그렇다면 효율을 높일 수 있는 방법을 찾자.
+이전 프로젝트에서 로그를 계속 서버에 들어가서 봤다.
+프로메테우스와 로키를 추가해 로깅 서버를 팠다면 시각화된 로그로 백, 프론트 관계없이 언제나 로그를 볼 수 잇었을텐데 귀찮다는 이유로 하지 않았다. 처음에 로깅 서버를 추가했다면, 반복적으로 서버에 들어가며 로그를 봤던 시간들을 아낄 수 잇었을텐데 아쉽다. 
+
+
+# 느낀점 
+- 반복 작업을 줄일 수 있는 방법에 대해 꾸준히 고민해야겠다. 반복작업을 줄이는 것이 곧 시간을 더 아끼고 효율적으로 사용할 수 있는 방법이니 레버리지를 높이는 활동이라 생각한다.****
diff --git "a/5\354\236\245/\354\240\204\355\230\270\354\230\201.md" "b/5\354\236\245/\354\240\204\355\230\270\354\230\201.md"
new file mode 100644
index 0000000..9dae956
--- /dev/null
+++ "b/5\354\236\245/\354\240\204\355\230\270\354\230\201.md"
@@ -0,0 +1,26 @@
+# 기억하고 싶은 문장들
+
+"측정하지 않으면 오로지 자신의 직감에 의존할 수 밖에 없고, 직감이 맞는지 확인할 방법은 거의 없다."
+
+- 항상 측정을 안하고 감으로 이랬을거야~ 저랬을거야~ 했던 것 같다.
+
+
+"주당 근무 시간이 그 정도로 늘어나면 추가 근무 시간당 한계 생산력이 급격하게 떨어진다."
+
+- 많이 일하는 것이 일을 잘하는 것도 아니고, 효율적인 것도 아닌데, 그렇다는 이상한 믿음이 있었던 것 같다. 이와 별개로 할 일이 많아 내 시간을 내가 조절하는 상황이 아닌, 일에 치여 많은 시간을 개발에 투자하는 상황도 좋지 않다.
+
+"제품과 목표가 복잡할수록 무엇을 측정하고 무엇을 측정하지 말아야 할지 선택지가 늘어나고, 어디에 노력을 기울일지 어떤 결과를 생산할지 고민할 범위가 넓어진다. 지표는 1) 가장 큰 효과를 내고 2) 실행하기 좋으며 3) 즉각 반응하되 견고한 것으로 정해야 한다."
+
+- 이 부분도 생각치 못하 부분이다. 좋은 지표를 정하고 측정하자! 라는 생각을 했지만, “이런 부분은 측정하지 말아야지!” 이런 생각을 해본 적은 없었다.
+
+"엔지니어링이라는 맥락에서는 시간 경과에 따라 체계적으로 증가할 때 자신을 포함한 팀 전체에 갖아 크고 지속 가능한 효과를 내는 것을 핵심 지표로 삼아야 한다."
+
+"일상적인 업무에 관해서라면 대상을 가리지 않고 최대한 많이 측정하고 계측하는 것이 좋다. 이 두 가지 원칙이 서로 모순되는 것처럼 보일지 모르나 실제로는 서로를 보완하는 역할을 한다. 첫 번째 원칙은 높은 수준에서 전체 활동을 설명하는 데 필요하고, 두 번째 원칙은 자신이 만든 시스템의 현재 상황을 통찰하는 데 필요하다."
+
+"이들은 먼저 시스템의 주요 부분을 계측하고 사이트 사용자 수와 응답 시간은 얼마인지, 트래픽이 어디로 가는지를 보여줄 대시보드를 만들었다."
+
+- 어떤 프로덕트를 개발하든 이런 지표는 미리미리 볼 수 있도록 하는 것이 중요하다. 이번 프로젝트에서도 배포를 하자마자 이런 지표를 볼 수 있도록 로깅 서버를 파야겠다.
+
+# 느낀점
+
+- 이제 새로운 프로젝트를 시작한다. 여러 프로젝트를 진행했지만, 지표를 제대로 측정하겠단 생각을 안해봤다. 이번 프로젝트는 꼭 릴리즈 이후 운영도 하고 싶기에 초기에 측정과 계측을 잘 해두고 싶다.