diff --git "a/2\354\236\245/\354\230\244\355\230\234\354\204\261.md" "b/2\354\236\245/\354\230\244\355\230\234\354\204\261.md"
new file mode 100644
index 0000000..ff34288
--- /dev/null
+++ "b/2\354\236\245/\354\230\244\355\230\234\354\204\261.md"
@@ -0,0 +1,110 @@
+# 실용주의 접근법
+
+소프트웨어 개발의 모든 차원에 적용가능한 팁과 요령이 있고 이에 대한 장
+
+## 중복의 해악
+
+* 모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을만한 표현 양식을 가져야 한다.
+
+* 어떻게 중복이 생기는가?
+  + 참을성 없는 중복 (나임)
+    - 참을성 없는 중복은 발견하기 쉽고 다루기도 쉬운 형태지만, 나중의 고통을 피하기 위해 훈련과 미연에 시간을 투자할 의지가 있어야 한다.
+  + 개발자간의 중복
+    - 공통 필요 기능이나 데이터는 여러 번 거듭 구현될 가능성이 있다.
+    - 개발자간에 적극적이고 빈번한 소통을 장려하는 것으로 해결
+    - 기존의 것을 찾아내고 또 재사용하기 쉬운 환경을 조성
+
+* 나쁜 코드야말로 많은 주석을 필요로 한다
+
+* 믿을 수 없는 주석은 주석이 전혀 없는 것보다 더 심각한 문제를 만들어 낸다.
+
+## 직교성
+
+* 직교성이란 컴퓨팅에서 독립성이나 결합도 줄이기를 의미
+  + 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다 할 수 있음
+
+* 비직교적인 시스템은 본질적으로 변화와 조정을 하기가 복잡함
+
+* 직교적인 접근법은 재사용을 촉진함
+  + 컴포넌트들에 명확하고 잘 정의된 책임이 할당되어 있다면 구현자들이 미처 생각하지 못했던 방식으로 새로운 컴포넌트와 결합할 수 있음
+  + 시스템이 더 느슨하게 결합되어 있을수록 재설정하고 리엔지니어링하기 쉽다
+
+> 더 변화에 유연한 것과 사용하기 편한 것의 중용이 중요하다 생각하기도 ..
+
+* 프로젝트 팀 구조가 얼마나 직교성을 갖는지 간단히 측정해 볼 수 있는 방법이 있다.
+  + 요청된 개별 변화에 대한 토론에 참여할 필요가 있는 사람의 숫자
+  + 수가 클수록 직교성이 낮음
+  + 직교적인 팀이 더 효율적임이 명백함
+
+* 직교적인 설계를 테스트하는 손쉬운 방법
+  + 특정 기능에 대한 요구사항을 극적으로 변경했을 경우, 몇 개의 모듈이 영향을 받는가?
+  + 직교적인 시스템에서는 답이 '하나'여야 함
+
+> 극적으로 변경했는데 어떻게 하나가 될 수 있지..
+
+* 코드의 결합도
+  + shy code를 작성해라
+  + 불필요한 어떤 것도 다른 모듈에 보여주지 않으며, 다른 모듈의 구현에 의존하지 않는 코드
+
+> '구현을 인터페이스에 노출하지 않기'를 선호합니다
+> 이름도 인터페이스라고 생각해용
+
+* 자신이 작성하는 코드를 항상 비판적으로 검토해 보는 습관을 기르기 바란다
+
+* 단위 테스트는 직교성을 테스트해 볼 수 있는 흥미로운 작업
+  + 여러 모듈을 모킹한다면 낮다고 볼 수 잇음
+
+* 객체지향을 쓰면 더 직교적이냐?
+  + 더 직교적이게 만들 수 있으나, 더 기능이 많아 직교적이지 못한 시스템을 만들기도 쉽다
+  + 절차형 언어로 스파게티 코드를 만들 가능성이 존재한다면, 객체지향 언어로 미트볼 스파게티를 만들 수 있는 것
+
+## 가역성
+
+* 당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다.
+
+* 우리가 개발하는 속도는 요구사항, 사용자, 하드웨어의 변화를 앞지를 수 없다
+
+* 여러분의 코드는 몇 가지 가능한 미래를 지원하는가?
+  + 어떤 미래가 일어날 가능성이 높을까?
+  + 그 미래가 닥쳤을 때, 이를 지원하는 것이 얼마나 어려울까?
+
+## 예광탄
+
+* 요구사항으로부터 최종 시스템의 일부 측면에까지 빨리, 눈에 보이게, 반복적으로 도달하게 해줄 무언가를 찾아야 함
+
+* 예광탄은 항상 목표를 맞추지 못함. 다시 조준하는 과정이 필요
+
+* 프로토타입과 다른 것임. 프로토타입은 어떤 개념을 구현해 보려고 대충 끼워 맞추고 모두 버리고 다시 만듬
+
+* 예광탄 코드 접근 방법은 애플리케이션이 전체적으로 어떻게 연결되는지를 알고 싶고, 어떻게 사용자들이 상호작용하는지 보고 싶고, 아키텍처적 골격을 개발자들에게 제시하고 싶을 때의 방법
+
+## 프로토타입과 포스트잇
+
+* 소프트웨어 프로토타입도 자동차 프로토타입과 같은 이유에서 같은 방식으로 만듬
+  + 위험 요소 분석, 노출 > 바로 잡을 기회
+
+* 프로토타입에서 중요한 것은 생성된 코드가 아닌 배우게 되는 교훈
+
+## 도메인 언어
+
+* 문제 도메인에 가깝게 프로그래밍하라
+  + 더 높은 추상화 수준에서 작업하믕로써 사소한 구현의 세부사항들을 무시하고 도메인의 문제들을 푸는 일에만 정신을 집중할 수 있다.
+
+## 추정
+
+* 누군가 추정치를 묻는다면 중요한 것은 답변이 사용될 상황
+  + 매우 높은 정확도를 원하는가? 큰 그림만을 원하는가?
+
+* 추정치를 기록하는 용기
+  + 추정치를 기록하고 이후 얼마나 정확했는지 비교하자
+  + 잘못되었다면 왜 달라졌는지 원인을 찾자. 이를 통해 다음 추정은 더 정확해질 것
+
+> 회사에서 최근에 추정치를 기록하고 있는데.. 마주볼 시간이 없긴 하네요
+
+* 누군가 추정에 대해 물으면?
+  + 잠시 시간을 내어 더 정확한 추정치를 알려주자 ~
+
+> 개인적으로 사용하고 있는 방법은, 많은 분들이 읽으셨을 '함께 자라기'에서 찾은 방법인데요.
+>
+> 낙관적인 추정과 비관적인 추정을 함께 공유하는 방법입니더
+> 책에서는(미 해군이였나) 이를 어떤 수식으로 계산해서 전달하곤 하는데.. 그건 goozi인 거 같아서..