diff --git "a/8\354\236\245/\354\203\201\353\262\224.md" "b/8\354\236\245/\354\203\201\353\262\224.md"
new file mode 100644
index 0000000..71d4cab
--- /dev/null
+++ "b/8\354\236\245/\354\203\201\353\262\224.md"
@@ -0,0 +1,65 @@
+
+
+## Topic 45 요구사항의 구렁텅이
+
+요구사항이 표면 위에 놓여 있는 경우는 드물다. 보통은 가정과 오해, 정치의 지층 속 깊숙이 묻혀 있다. 심지어 아예 존재하지 않을 때도 있음
+> 공감됨, 이해관계자들 간에 지식의 간극은 존재하고 주어진 업무 조건, 상황이 비슷한 것도 아니여서 사업부 입장에선 요구사항이 처음에 명확했을지라도 기획팀, 개발팀으로 점점 넘어오면서 타협이 추가되면서 요구사항이 점점 애매해지는 경우도 있고 히스토리를 파악하지 못해서 왜 이렇게 해야되는지 의문인 경우도 있었음(이건 기획 문서에 기재하지 않은게 문제인듯)
+
+자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다.  
+프로그래머는 사람들이 자신이 원하는바를 깨닫도록 돕는 역할을 해야한다.  
+> 신입 개발자들이 요청사항을 받았을 떄 바로 해결책을 구현해 버리는 것이 문제라고 하는데 이건 어쩔수 없는게 아닌가? (그게 왜 문제? 모를 수 있는거지)
+
+우리는 의뢰인의 말을 해석해서 그로 인한 영향을 다시 알려주는 것이다.  
+> 이건 지식과 경험이 동반되는거라 생각. 시스템과 비즈니스 이해도가 적다면 매우 쉽지 않음
+
+요구사항은 피드백을 반복하며 알게 된다.  
+그리고 마지막으로 사용자(의뢰인의 입장)처럼 생각하기 위해 사용자와 함께 일해라  
+
+요구사항을 지나치게 자세히 서술하면 좋지 않다. 좋은 요구사항은 추상적이다.
+별로 설득력 없는 이유라 저 말에 공감은 안됨
+
+
+## Topic 46 불가능한 퍼즐 풀기
+
+생각의 틀을 벗어나지 말고 틀을 찾아라
+> 모든 선입견을 의심하라는 말과 예시가 적절했음.
+
+자신만의 방법에서 빠져나와라.
+> 어떤 문제를 풀지 못하고 오래 잡고 있을 때 토끼굴에서 빠져나올 수 있는 좋은 방법들을 설명해줘서 좋았음  
+> 질문을 스스로에게 던져보는 예시가 좋아서 나열해봄
+
+- 왜 이 문제를 풀고 있는가?
+- 문제를 풀어서 얻는 것이 무엇인가?
+- 풀려고 하는 문제가 특수한 경우에 해당하는가? 특수한 경우를 업앨 수 는 없나?
+- 관련된 문제 중에 여러분이 풀 수 있는 더 간단한 문제는 없나?
+
+
+
+## Topic 47 함께 일하기
+
+> 시스템을 설계하는 조직은 조직의 의사소통 구조를 그대로 본뜬 설계를 만들기 마련이라는 콘웨이의 법칙에 공감했음, 이전 조직도 그랬기에..
+
+> 짝 프로그래밍은 몇몇 회사에서 시행하는 것을 들어봤는데, 몹 프로그래밍은 아직 들은적이 없다. 과연 관리자 입장에서 3명 이상이서 하나의 화면을 보고 일하는게 효율적이라고 생각할 것인가! 여러분들은 어떻게 생각하시는지.. 의견 궁금합니다 
+
+이렇게 함께 일할 떄는 기술적인 면 외에 인간적인 측면도 신경써야 된다.
+- 누가 가장 똑똑한지 겨루지 말자.
+- 소규모로 시작하고 짧게 몇번 해보는 걸로 시작해라
+- 코드만 비판하고 사람을 비판하지 마라.
+- 다른 사람의 관점을 듣고 이해하려고 노력해라. 다른 것은 틀린 것이 아니다.
+- 자주 회고를 해라. 그래서 다음번에 시도하거나 개선할 점을 찾아라.
+
+## Topic 48 에자일의 핵심
+
+애자일 => 기민함 이라는 것은 변화에 대응하는 것, 일을 시작한 이후 맞부딪히는 미지의 것에 대응하는 것
+
+그럼 우리는 무엇을 해야 하나? => 모든 것은 불확실성을 어떻게 다룰 것인가 하는 문제에 달림, 에자일 선언은 피드백을 모으고 그에 맞게 행동함으로써 불확실성을 헤쳐 나가라고 제안함
+
+애자일이 전반적으로 작동하게 하려면 좋은 설계를 만들어야 한다. 좋은 설계는 무언가를 바꾸기 쉽게 하기 떄문
+
+바꾸기 쉽다면 모든 층위에서 아무런 주저 없이 문제를 바로잡을 수 있음 => 이것이 애자일
+
+## 총평
+> 이 장에서 말하고자 하는 것과 비슷한 생각이였고 공감되는 말들이 많아서 좋았음.  
+> 프로젝트 초반 회의에 적극 참여하고 핵심 요구사항에서의 문제점이나 기존 시스템에 발생할 사이드이펙트를 최대한 발견 해내야 한다.  
+> 그리고 요구사항은 언제든지 바뀌기 때문에 그에 맞게 유연하게 변경할 수 있게 설게를 해야한다.  
+> 회사에서 짝프로그래밍까진 이해하는데, 몹프로그래밍은 가능할까? 관리자 입장에서 효율적이라고 생각할지가 의문이다