diff --git "a/13\354\236\245/\354\235\264\354\235\200\355\225\231.md" "b/13\354\236\245/\354\235\264\354\235\200\355\225\231.md"
new file mode 100644
index 0000000..8dc1238
--- /dev/null
+++ "b/13\354\236\245/\354\235\264\354\235\200\355\225\231.md"
@@ -0,0 +1,23 @@
+## 배움의 문화
+
+### ✍🏻 **중요하다고 생각한 부분 정리(+나의 생각)**
+
+"맞는지 틀린지도 모른 채 맹목적으로 테스트를 끼워 맞추는 개발을 시작한지 몇 달 후 70%의 테스트 커버리지에 도달했다. 몇 주가 지나고 고객사는 기뻐하며 계약을 종료했다."
+
+> 목표한 수치에는 도달했지만 코드의 품질과 효율성이 원래 의도한 것인지 아리송한 상황도 많았고, 단순히 그냥 테스트만 작성해야한다는 생각으로만 진행을 한 경우이다. 기존의 클래스와 메서드들이 전체적인 설계 관점에서 올바른지도 전혀 알 수 없었기 때문에 아쉬운 결과로 이어진 것 같다.
+
+관리자들은 개발자들에게 무엇을 언제 어떻게 하라고 일일이 명령할 것이 아니라 개발자들에게 권한을 위임하고 스스로 배움의 문화를 만들어갈 수 있도록 북돋워야 한다.
+
+> 위에서 목표한 수치를 달성하기 위해 무작정 강압적인 환경에서 개발을 하는 것보다 개발자들이 스스로 성장하기 위해 자유로운 분위기가 형성되어야 할 것이다. 즉, 배움의 문화를 형성하고 이를 통해 회사도 혁신적이고 기민해질 것이다.  
+> 책에서는 **북 클럽 가입하기, 테크 런치 진행하기, 그룹 토론회에 참여하기, 업무 교환하기, 그룹 코드 리뷰하기, 코딩 실습하기, 사용할 기술은 가능한 자유롭게 선택하기, 내부 학습 모임을 만들기, 회사에서의 펫 프로젝트 시간을 허용하기, 외부 기술 커뮤니티와 교류하기**를 제안하고 있다.
+
+배움의 문화를 형성하는 여러가지 방법 중 '그룹 코드 리뷰하기'에 대해 더 알아보고자 했다. 특정 코드 부분이 개선의 여지가 많은지 아니면 모법사례로 공표할 만큼 훌륭한지를 놓고서 동료들 간에 논쟁을 하는 것이다.
+
+- 주석은 주관적, 개인적으로 표현되어서는 안 된다.
+- 누가 코드를 작성하느냐는 중요하지 않다.
+- 그룹 코드 리뷰 시간에 커밋 히스토리를 뒤지지 않는다. 비난할 사람을 찾기 위해 과거를 파헤치지 말고 미래를 변화시키는 데 집중한다.
+- 주석은 반드시 객관적이고 생산적이어야 한다. 왜 그것이 엉망인지가 아니라 어떻게 코드를 개선할지를 집중해야 한다.
+- 퍼실리테이터의 도움이 필요할 수도 있다. 퍼실리테이터의 역할은 모두에게 발언권을 주고 누군가를 비난하는 상황이 생기지 않도록 하는 것이다.
+- 큰 진전을 이룰 것이라 기대하지 않는다. 이슈 한 가지에 대해서 너무 오랫동안 이야기되더라도 개발자들이 원한다면 그냥 그렇게 한다.
+
+관리자로부터의 지원이 없더라도 개발자들 스스로 서로 배우고 공유하는 배움의 환경과 문화를 쉽게 만들 수 있다. 장소가 없다면 가까운 카페를 찾아가고, 시간이 없다면 점심 시간이나 업무 전 시간을 이용하자. 열정적인 개발자들에게 좋은 환경을 제공하기만 하면 된다. 그러면 그들 스스로 무엇을 배우고 공유할지 여러 가지 방법을 찾을 것이다.
diff --git "a/14\354\236\245/\354\235\264\354\235\200\355\225\231.md" "b/14\354\236\245/\354\235\264\354\235\200\355\225\231.md"
new file mode 100644
index 0000000..ca3423a
--- /dev/null
+++ "b/14\354\236\245/\354\235\264\354\235\200\355\225\231.md"
@@ -0,0 +1,15 @@
+## 기술적 변화의 실행
+
+### ✍🏻 **중요하다고 생각한 부분 정리(+나의 생각)**
+
+당신을 둘러싼 것들을 바꾸고 싶다면? 동료 개발자, 관리자, 기술 리더와 언성이 높아지는 논쟁을 두려워해서는 안 된다. 당신이 생각하는 내용이 어떤 것이든 말할 수 있는 용기가 있어야 한다. 정직함과 투명함은 소프트웨어 장인이라면 반드시 가져야 할 핵심 가치다. 또한, 자기가 하는 말이 무엇인지 스스로도 제대로 모르면서 다른 사람을 설득할 수는 없다.
+
+> 마지막 말에 많이 공감한다. 우리가 발표를 준비할 때 자료조사를 하고 스토리를 만들고 대본 연습을 반복하여 완벽하게 해내는 것처럼 누군가를 설득하고 무언가를 바꾸기 위해서는 나 먼저 부족함 없이 이해하고 습득하는 것이 중요하다. 물론 모든 내용을 아주 정확하게 이해할 수는 없을 수 있지만 이 과정은 개인 성장에도 큰 도움이 될 것이다.
+
+큰 충돌을 피할 수 있는 가장 쉬운 방법은 점진적인 변화를 제안하는 것이다. 오늘 당장부터 새로운 제안에 맞춘 설계를 모두가 따라야만 한다고 이야기하는 대신, 다음 스프린트부터 당신과 다른 개발자들이 직접 스토리를 골라 새로운 설계를 시도해보자고 할 수 있다. 그 스토리가 끝나면 모두에게 시연을 하고 팀 차원에서 새로운 설계를 수용할지 결정하도록 할 수 있다.
+
+> 모든 팀원들의 방향성을 맞출 수 없겠지만, 의사결정 과정에 사람들이 참여할 수 있게 하는 것이 중요한 것 같다. 동등하게 피드백할 수 있는 과정이 항상 필요하다! 또한, 해당 방식에 대해 주기적으로 피드백을 하고 스크럼을 통해 공유하며 협조적인 분위기를 만들어 내면 아주 좋은 협업 과정이 될 것이다.
+
+소프트웨어 장인은 사람들이 듣고 싶어 하는 말이 아니라 진심을 말하며 자신의 행동에 책임을 지고 프로젝트를 위해 최선이라면 싸우기를 주저하지 않는다.
+
+> 개발자는 단순히 예스맨이 아니라, 자신의 의견과 생각을 분명히 전달하는 자세를 가져야 할 것이다. 그리고 결과를 만들어내는 모든 과정에서의 행동에 대해 책임을 가지고 기술적 능력뿐만 아니라, 직업적 윤리와 진정성을 잃지 않는 태도도 항상 가져야 할 것이다.