diff --git "a/9\354\236\245/\354\235\264\354\203\201\354\241\260.md" "b/9\354\236\245/\354\235\264\354\203\201\354\241\260.md"
new file mode 100644
index 0000000..a0af374
--- /dev/null
+++ "b/9\354\236\245/\354\235\264\354\203\201\354\241\260.md"
@@ -0,0 +1,86 @@
+# 실용주의 프로젝트
+
+실용주의 프로그래머를 다 읽었는데 맨 마지막 챕터에 실용주의 팀에 대한 이야기가 있어 공유드립니다.
+
+"프로그래머는 고양이 같은 면이 있다. 호기심 많고 제멋대로이며, 고집이 세고, 독립적인 데다, 가끔은 인터넷에서 숭배를 받기도 한다."
+
+책은 개인이 더 나은 프로그래머가 되는 여러가지 실용주의 기법들을 소개하고 있습니다.  
+다만, 고양이 같은 프로그래머들이 모인 팀에서도 실용주의 기법은 적용할 수 있으며, 오히려 팀 차원에서 실용주의 기법을 적용할 때 더욱 효율적이라고 합니다.  
+20년이나 된 책이라고 하던데 좋은 내용이 많네요. 아래는 책 내용을 간략하게 요약했습니다.  
+
+### 깨진 창문을 없애라  
+건물의 깨진 창문처럼 자잘한 결점을 그냥 방치하면 금세 폐건물이 되기 쉽습니다.  
+깨진 창문 하나가 무의식적으로 '더러워져도 되는', '관리가 안되는' 건물로 인식하게 만들어 소프트웨어 엔트로피의 가속화를 불러온다는 이야기입니다.  
+이를 방지하기 위해 팀 전체가 제품의 품질에 책임을 지고 지속적으로 관리해야 합니다.  
+
+단, 품질 관리 담당자를 따로 배정하는 것은 오히려 좋지 않고, 품질은 팀원 전체가 제각기 기여할 때만 보장됩니다.  
+
+### 삶은 개구리
+냄비 안에 개구리를 넣고, 물의 온도를 서서히 높이면 개구리는 자신이 익어가는 줄도 모르고 죽을 수 있다고 합니다.  
+프로젝트 개발의 열기 속에서 전체 환경의 변화에 계속 신경 쓰기란 어려운 법입니다.  
+
+팀은 개인보다 삶은 개구리가 되기 쉽다고 합니다.  
+누군가가 문제를 처리하겠거니 생각하거나, 사용자가 요청한 변경 사항을 팀 리더가 이미 동의했겠거니 하고 여기기 때문입니다.  
+
+따라서 모든 사람이 적극적으로 환경 변화를 감시하도록 권장해야 합니다.  
+범위의 확장, 일정 단축, 추가 기능, 새로운 환경 등 무엇이건 간에 애초에 인지하고 있던 것과 다른 것들을 늘 의식할 필요가 있습니다.  
+
+### 지식 포트폴리오를 계획하라
+성공을 원하는 팀이라면 자신들의 지식과 기술에 투자하는 것을 고려해야 합니다.  
+단, 진정 개선하고 혁신하고 싶다면 계획을 세워야 합니다.  
+책에서는 '시간이 나면 그때' 하겠다는 것은 '영원히 하지 않겠다'는 것과 다르지 않다고 말합니다.  
+
+업무를 어떻게 관리하던 간에, 새로운 기능 개발로만 몽땅 채우지는 말고 다른 것도 하라고 합니다.  
+- 구형 시스템 유지 보수
+- 프로세스 회고와 개선
+- 새로운 기술 탐험
+- 학습 및 기술 갈고 닦기
+
+### 팀의 존재를 소통하라
+팀 역시 더 큰 조직의 일부임을 간과해서는 안됩니다. 팀도 나머지 세상과 소통해야 하는 존재입니다.  
+
+외부 사람들에게 무뚝뚝한 팀으로 보이는 것이 최악의 팀이라고 합니다.  
+그런 팀의 회의는 침묵만 가득하고, 문서마다 생김새가 제각각이며, 서로 다른 용어를 사용합니다.  
+
+반면 훌륭한 팀은 모든 사람이 그 팀과의 회의를 기대하게 만듭니다.  
+모든 사람이 만족할 만한 퍼포먼스, 깔끔하며 일관적인 문서, 한 목소리로 이야기하는 팀원이 그 이유입니다.  
+
+훌륭한 팀이 되는 간단한 방법으로는 팀이 담당하는 프로젝트에 이름을 붙여주는 것이 있습니다.  
+그리고 그 이름을 외부 사람들과 대화할 때 거리낌 없이 사용하라고 합니다.  
+팀은 정체성 확립의 기반을 얻을 것이고, 세상은 여러분의 작업과 관련해서 기억할 만한 뭔가를 얻게 됩니다.  
+
+### 반복하지 말라
+중복된 일은 노력을 무위로 돌릴 수 있고, 유지보수를 어렵게 만듭니다.  
+좋은 의사소통을 통해 이를 해소할 수 있습니다.  
+
+'좋은' 이란 '즉각적이고 매끄러운'을 의미합니다.  
+팀 동료에게 질문하면 거의 즉각적으로 대답을 들을 수 있어야 한다고 합니다.  
+질문하거나 상황을 공유하기 위해 다음 회의 시간까지 기다려야 한다면 좋은 의사소통이 아닙니다.  
+
+### 자동화
+일관성과 정확성을 보장하는 확실한 방법은 팀이 하는 일을 자동화 하는 것입니다.  
+코드 스타일, 배포, 테스트 등을 자동화하여 일관된 스타일을 갖추어야 합니다.  
+
+### 멈춰야 할 때를 알라
+각 팀원이 자신의 방식대로 빛날 수 있고, 프로젝트가 가치를 만들어 내기에 좋은 딱 좋을 만큼의 구조만 제공해야 합니다.  
+더 좋은 무언가를 위해 계속 덧칠하려는 욕구를 참아야 합니다.  
+
+---
+
+## 코코넛만으로는 부족하다
+
+어디 책이나 강의나 부트캠프에서 PM 코스 듣고온 것 같은 틀에 박힌 방법론을 사용하는 사람을 본 적 있다.  
+결과는 좋지 못한 것 같다.  
+
+회사에서 TBD를 사용하고 있으며, 실제로 피쳐 플래그를 사용해 빠른 주기로 배포하고 있다.  
+솔직히 개발하는게 좀... 너무 불편한 것 같긴 하다.  
+피쳐 플래그 걷어내고 이러는게 좀...
+
+## 실용주의 시작 도구
+
+테스트를 테스트하라 부분을 읽으면서 회사에서 받은 리뷰가 생각났다.  
+어떤... 숫자를 받아서 가공 후 반환하는 유틸함수였는데, 내가 테스트 코드에 `Math.random()`을 사용해 랜덤한 숫자로 테스트하는 케이스를 작성해두었다.  
+내 의도는 어떠한 숫자가 들어와도 잘 동작하는 함수니까 랜덤한 값으로 테스트하면 그 의미도 더 명확하게 드러나지 않을까? + 고정된 특정 값으로만 테스트한다면 어떠한 숫자가 들어와도 잘 동작한다는걸 테스트할 수 있을까? 였는데...  
+리뷰로 랜덤 값으로 테스트하는 것이 옳은지에 대한 장문의 리뷰를 받았다.  
+요약하자면 대충 빌드타임에 돌리는 테스트는 이미 통과하는 테스트를 계속해서 통과하는지에 대한 테스트니까 랜덤값을 사용하면 안된다 였던 것 같다.  
+틀리는 테스트도 계속해서 틀려야 하겠다.