diff --git "a/\354\261\225\355\204\260_24/\354\203\201\353\262\224.md" "b/\354\261\225\355\204\260_24/\354\203\201\353\262\224.md"
new file mode 100644
index 0000000..f9c5c0c
--- /dev/null
+++ "b/\354\261\225\355\204\260_24/\354\203\201\353\262\224.md"
@@ -0,0 +1,53 @@
+# 챕터 24 지속적 배포
+
+기술환경이 빠르게 변하고 변화의 방향도 예측하기 어려운 상황속에서 제품이 경쟁력을 갖추기 위해서는 시장에 신속하게 출시할 수 있는 능력이 중요하다
+
+출시 후에는 지속적인 배포를 통해 업데이트해야 한다. 빠르게!
+
+코드의 가치는 서브밋 시점이 아니라 고객이 그 기능을 이용할 때 실현된다!
+
+## 지속적 배포 이디엄 @구글
+
+지속적 배포 그리고 애자일 방법론의 핵심 교리는 **작은 변경들을 자주 배포할수록 품질이 높아진다는 것**이다. '빠를수록 안전하다'(faster is safer)라는 말이다
+
+처음에는 신버전 소프트웨어를 자주 출시하는게 위험해보일 수 있지만 오히려 변경사항이 더 많거나 새로운 코드가 많아서 모두 철저하게 테스트 하기 어려울 수 있다. 두 릴리스 사이의 변경이 적을수록 문제를 해결하기 쉽다
+
+## 속도는 팀 스포츠다: 배포를 관리 가능한 조각으로 나누기
+
+유튜브는 거대한 모놀리식 파이썬 애플리케이션 이였고, 릴리스 한번 하려면 모두가 고통 분담해야됐음. 원격 QA팀은 수작업으로 진행하는 50시간짜리 회귀테스트도 거쳐야 한다고 함 ㄷ ㄷ ㄷ
+
+릴리스 비용이 늘고 위험이 커지면 '본능적'으로 릴리스 주기를 늦춰 안정성을 확보할 기간을 늘리려 한다. 
+
+하지만 이렇게 해서 얻는 안도감은 짧은 기간만 유지될 뿐, 멀리 보면 팀의 속도가 느려지고 팀과 고객 모두 좌절시키는 선택임. 답은 비용을 줄이고 규율을 강화하고, 위험에 점진적으로 대응하는 것이다.
+
+당장의 안정을 위한 프로세스 수정에 저항하고 장기적인 아키텍처 개선에 투자해야 하는게 핵심이라고 함. 이유는 눈 앞의 안정만 추구한다면 낡은 개발 프로세스로 회귀하고 쉽다고 함 
+
+> 눈 앞의 안정만 보고 프로세스를 무겁게 하면, 결국 예전 낡은 방식(느린 배포, 비효율적인 협업)으로 되돌아가기 쉽다라는 말 같네요. 긴 수명으로 보고 따졌을 때 득이 더 많다~
+
+## 변경을 격리해 평가하자: 기능 플래그로 보호하기
+
+제곧내
+
+## 기민해지기 위한 분투: 릴리스 열차 갖추기
+
+릴리스 주기를 예측할 수 있도록 두가지 프로세스를 녹여냈다
+
+1. '완벽한 바이너리는 없음'을 인정하기. 소프트웨어는 본디 복잡할 수 밖에 없음을 인정하자 
+> 필리핀의 한 섬에서만 사용하는 독특한 방언 때문에 검색 결과 대신 빈페이지를 보여주는 버그를 수정하는 게 중요한 신기능 출시를 미룰 만큼의 가치가 있는지를 판단해야 했던 구글만이 경험할 수 있는 재밌는 일화를 설명해준게 기억에 남았음
+2. '릴리스 열차 시간에 늦으면 기다리지 않고 출발할 것'이니 릴리스 시한을 지켜라
+> 열차 라는 비유가 찰떡이였음. 릴리스 열차를 놓친 엔지니어는 몇 시간 후 출발 할 다음 열차를 타면 된다~
+
+## 품질과 사용자에 집중: 사용할 기능만 배포하자
+
+코드 모듈화를 통해 우리는 동적으로 설정 가능한 배포 전략을 구사할 수 있음
+
+동적 배포를 활용하면 각 고객에게 의미 있는 코드만 작게 구성한 바이너리 배포 가능, A/B 테스트도 가능~
+
+## 팀 문화 바꾸기: 배포 규율 세우기
+
+'늘 배포하라' 정책은 여러 측면에서 개발자 속도를 높여준주고 개발 프로젝트에 도움이 된다
+
+릴리스 열차가 자주 오면 이전의 '좋은' 상태와의 차이가 적어서 문제가 생겨도 살펴봐야 할 범위가 좁혀지니까~~
+
+> 원점 회귀 쪽 읽다가 생각난건데, 혹시 다들 배포 버전 단위 롤백 정책이 있으신가요? 있다면 어떤식으로 하시고 계시나요~?
+