diff --git "a/2025/Becoming a Better Programmer/hemil0102/14\354\236\245~23\354\236\245.md" "b/2025/Becoming a Better Programmer/hemil0102/14\354\236\245~23\354\236\245.md"
new file mode 100644
index 00000000..e40ef16f
--- /dev/null
+++ "b/2025/Becoming a Better Programmer/hemil0102/14\354\236\245~23\354\236\245.md"	
@@ -0,0 +1,194 @@
+# 논제 
+## 1. CI/CD 구축은 어려운가?! 확실히 구축해놓으면 생기는 이점은 무엇이고 단점은 무엇이라 생각하는가!?
+
+# 대략 중반까지 읽고 감상평 
+## 태도
+어떤 기술을 가르치려는 목적보다는 마인드(태도)에 대한 이야기가 주를 이룬다는 생각을 했습니다. 
+지금은 혼자서 하는 프로젝트가 많고 버전 관리나 데브옵스도 하고 있지 않은 환경이기에, 
+어떤 부분들은 그냥 아 그런가보다라고만 읽고 넘어가게 되지만, 
+그렇다고 완전히 협업이 없는 환경은 아니기에 공감가거나 태도를 고치거나 여러모로 생각이 듭니다. 
+
+## 겸손함
+최근에는 코드를 인수인계 받으면서 관찰과 분석 위주의 업무를 하고 있는데, 
+책에서 이야기하는 겸손함(누구나 완벽하지 않다)라는 관점으로 타인의 코드를 분석하면, 
+왠만한 나의 스타일과 다른 코드도 다 이유가 있으니 일단 받아들이는 작업을 하고 있습니다. 
+한편으로 책을 읽다보니 드는 생각은, 
+레거시나 인수인계한 코드에 대한 작업은, 
+모든 구조를 완벽하게 분석하진 못하더라도... 
+어느정도는 전체적인 부분을 관찰하고 분석한 이후에 수정 작업이 이뤄지면 좋겠다는 생각이 들었습니다. 
+그리고 코드를 작성하면서 마음에 들지 않기 때문에 리팩토링을 중간 중간 하는 편인데, 
+책에서는 너무 잦은 리팩토링을 하다보면 오히려 안좋아지는 경우가 있으니, 
+일단은 코드를 작성하고 한차례 사이클을 돌리고 리팩토링 시작하는게 좋다는 말이 인상 깊었습니다. 
+
+설계 -> 설계 검증 -> 구현 -> 단위테스트 -> 구현 리뷰 -> 설계/구조 개선 
+
+위와 같은 절차를 최대한 지켜내려는 노력을 하는 것이 바람직해보입니다. 
+
+# 14장 소프트웨어 개발이란 
+## 1. 이번 장에서 설명했던 은유 중 어떤 것이 자신과 맞아떨어지는가? 정확하게 자신의 일을 반영하는 은유적 표현은 어떤 것인가? 
+### 알파벳 모양 커스터드 은유가 맞아떨어져 보였다. 무작정 코드를 작성하고 보는 습관이 있는데, 좋은 요리에는 좋은 레시픽 있듯이, 기본이 있는 요리는 레시피를 충분히 숙지하고 기본을 먼저 익힌 다음에 변칙적인 다른 시도를 해보면 좋아보인다는 생각이 들었다. 
+ 
+## 2. 소프트웨어 개발 업무를 비유할 다른 은유적 표현을 찾을 수 있는가? 새로운 은유를 통해 어떤 새로운 통찰을 얻을 수 있는가? 
+### 협업 관점은 많이 나왔으니 다른 관점을 생각해보려고 한다. 꽃을 키우는 것을 은유로 대입해보자. 씨앗을 흙에 심고 햇빛과 물을 주기적으로 주는 것을 꽃 키우기의 핵심이라 생각했는데, 최근에는 대기 순환도 엄청 중요하다는 사실을 깨달았고, 왜 내가 키우는 식물은 빨리 죽는지에 대해 이해가 되었다. 이렇듯 아주 뻔해보이는 어떤 것이라도 이유가 어찌되었거나 가장 기본적인 것을 망각할 수 있는데, 개발 업무도 자신이 당연하다고 생각하는 부분 때문에 대게 문제가 생길 수 있으므로 가급적이면 유저매뉴얼이나 어떤 이력이 있다면 꼼꼼히 읽어두는게 좋다. 어떤 경험은 보수적이라 답답하지만, 어떤 전통은 더 나아가기 위해 후세에 물려지는 것도 있으므로 이력 파악을 잘하는게 좋지 않을까. 
+
+## 3. 알파벳 모양 커스터드를 만드는 방법은 무엇인가? 
+### 기존 커스터드와 다른 점을 비교하여 정리한다. 차이만큼 다른 재료와 조리법이 필요할지 고안해본다. 
+    간단한 실험을 통해 프로토타입을 만들어본다. 괜찮다고 생각이 들면 조금 더 완제품에 가까운 것을 만든다. 
+
+# 15장 규칙 가지고 놀기 
+## 1. 현재 당신의 프로젝트에 적용하고 있는 소프트웨어 개발 절차에 대한 규칙들을 나열해보라. 얼마나 잘 시행되고 지켜지는가? 
+### 코딩 컨벤션과 같은 규칙은 솔직히 지금은 정해진게 없기에 수행하고 있지 않다. 다만 다른 규칙이라면 설계 검증이나, 설계의 절차를 충분히 스스로 설명할 수 있기 전에는 코드를 작성하지 않는다는 규칙을 지키려고 노력한다. 
+
+## 2. 이번 프로젝트의 문화가 이전 프로젝트들과 어떻게 다른가? 일하기에 더 좋아졌는가 아니면 더 나빠졌는가? 규칙에서 다른 점을 찾거나 개선할 수 있는가? 
+### 일전에 부트캠프에서는 변수명이나 코드 리뷰를 통해 가독성이 좋은 코드를 작성했다. 취업한 이후에는 이런 리뷰가 없지만 최대한 스스로 가독성이 좋은 코드를 작성하기 위해 GPT와 같은 생산툴에게 리뷰를 요청한다. 
+    사람과 코드 리뷰를 하면 갈등이 생기기도 하고 피로도도 올라가지만 서로 부딪힌다는 점에서 팀웍을 다질 개기가 된다. 반명에 GPT를 통한 리뷰는 어떨 때는 사람보다 좋은 리뷰를 해주지만, 물어보는 질문 수준이 낮다면 어떨 때는 돌아오는 답변이 뻔하고 계속 같은 말을 할 경우가 있다. GPT를 사용해도 알려준 것을 고민 없이 적용하면 남는 것이 없기에, 사람과 함께 리뷰를 하는 문화는 여전히 필요하다고 생각한다. 
+    
+## 3. 팀이 규칙에 동의할 것이라고 생각하는가? 
+### 사실 팀원에게 규칙을 건네는 과정 자체가 두려운 요소 중의 하나다. 내가 틀렸다는 것이 두렵다기 보다는, 팀원의 스타일이 나와 다를 때 팀원도 자신의 방식을 고수하기에 충분한 생각 없이 거절할 경우가 있기 때문이다. 
+    이 경우가 난해하고 어떻게 해결할 수 있을지는 아직 잘 모르겠다. 
+
+## 4. 코드의 모양, 스타일, 품질이 프로젝트의 코딩 문화에 영향을 미치는가? 팀이 코드에 영향을 미치는가 아니면 코드가 팀에 영향을 미치는가? 
+### 영향을 미친다고 생각한다. 모양, 스타일로부터 발견할 수 있는 것이 다르고, 발견할 수 있는게 다르면 대화의 품질도 달라질거라 생각한다. 
+    닭이 먼저냐 알이 먼저냐와 비슷하다고 생각이 들지만, 나는 팀이 코드에 영향을 조금 더 많이 미친다고 생각한다. 
+    그 이유는 현재 회사에서 일을 하다보니 기존에 나의 코딩 스타일이나 기존에 배운 것을 팀의 문화나 회사의 프로세스로 적용하지 못하는 경우가 많다. 
+    개개인의 장점을 극대화하면 좋다고 생각하는데, 서로의 장점을 파악하면서 일을 해나가는게 더 즐겁다고 생각한다. 
+    
+# 16장 간결하게 하기 
+## 1. 최근에 본 가장 간결한 코드는 무엇인가? 가장 복잡한 코드는 무엇인가? 어떻게 다른가? 
+### 최근에 간결한 코드를 본적이 많지는 않은 것 같지만, 자료 구조를 공부하는데 리스트 추상 자료형으로 함수의 인터페이스를 설계하고, 실제로 작성된 코드를 봤을 때 설계의 의미가 잘 전달되어서 간결하다는 생각이 들었다. 
+    복잡한 코드는 함수 인터페이스를 무시하고, 값을 캡처하는 것이 아니라 글로벌 변수를 그대로 함수 내부 계산에 활용한 케이스가 성의 없는 코드라는 생각이 들었다. 이 경우 코드 해석이 꽤나 힘들다. 
+
+## 2. 코드를 지나치게 복잡하게 만들 수 있는 불필요한 가설의 종류로는 무엇이 있는가? 어떤 가설이 타당한가? 
+### 지금 구현하는 것 외에 미래의 필요한 부분까지 미리 끌어다가 설계할 경우 복잡성이 늘어난다. 가령 서버 구현이 필요한 기능인데 서버가 없어서 로컬 구현만 필요할 경우, 서버가 나중에 구현될거니 서버까지 같이 고려할 수 있겠지만, 서버 개발자가 와서 해도 늦지 않으므로 로컬 구현만 먼저 해본다. 
+
+## 3. 코드 수준의 최적화에 대해서는 많이 다루어졌다. 설계나 구조 수준에서 어떻게 최적화를 할 수 있는가? 
+### 사실 나도 이 부분을 가장 하고 싶지만 어려운 것 같다. 다만 설계 수준의 최적화는 코드 외적으로 설계가 타당한지 논리를 검증하므로써 최적화를 할 수 있다고 생각한다. 
+
+## 4. 코드를 최적화하고 간결함을 유지하는 것이 가능한가? 
+### 가능하다고 생각한다. 데이터의 입출력 인터페이스를 충분히 잘 설계한다면 적어도 내부 코드를 이해하지 못하더라도 갖다 쓸 수 있기에 이정도 간결함은 추구해볼 수 있어보인다. 
+
+## 5. 코드의 '간결함'이 코드를 읽는 프로그래머의 능력에 좌우되는가? 숙련된 코더가 고품질의 코드를 보장하면서도, 유지 보수를 맡은 덜 숙련된 코더에게 그 코드가 '간결'해 보이도록 하기 위해서는 어떻게 해야 하는가? 
+### 어찌보면 이건 능력보다는 성향이 좌지우지하는게 더 크다고 생각이 든다. 평소에 집정리도 잘 안하는 사람이 코드를 잘 정리할거라는 생각은 잘 들지 않는다. 그럼에도 숙련이 되면 나아지기도 하진 않을까? 
+유지보수를 맡은 덜 숙련된 코더에게 간결해 보이도록 하기 위해서는 그 구조를 잘 이해하는게 가장 먼저인 것 같다. 
+
+# 17장 머리 쓰기 
+## 1. 간결한 코드와 멍청한 코드의 차이점은 무엇인가? 
+### 간결한 코드는 설명이 가능하고 멍청한 코드는 설명이 불가능하다. 
+
+## 2. 자신이 멍청한 코드를 작성하지 않았다고 어떻게 확신할 수 있는가? 좋은 코드에 대한 '상식'을 지녔다고 생각하는가? 자신의 대답을 증명해보라. 
+### 사실 확신을 할 수 있는지 잘 모르겠다. 아직은 난 나의 코드가 천재적이라니 더는 변경할 부분이 없다느니 이런 생각을 하진 않는다. 
+다만 좋은 코드를 작성하려는 노력을 계속 한다는 것 자체가 '상식'을 지녔다고 말할 수 있지 않을까? 
+
+## 3. 특정 코드가 별 다른 주의를 기울이지 않는 누군가에 의해 작성되었음을 알려주는 징후는 무엇인가? 
+### 변수명부터 ㅇㅇㅇ1 ㅇㅇㅇ2로 지어졌거나, 한 소스코드 파일에서 여기저기 다른 파일에 의존성을 갖으면서 기능을 구현했거나, 전반적으로 깔끔해보이지 않을 때, 쉽게 가려고 했을 때
+
+## 4. 잘못 작성한 코드를 재작업할 것인지, 아니면 '실용적으로' 기술 부채로 표시해두고 꽁무니를 뺄 것인지 선책하는 결정 요인은 무엇인가? 
+### 이건 어느정도 의지에 달려있다. 시간적인 요소나 회사의 요구사항으로 못한다는 생각이 들기도 하겠지만, 정말 하고 싶다면 해야한다. 안그러면 계속 급류에 휩쓸려 평생 못하게 되지 않을까?  
+기술 부채가 생기는 것은 맞지만 이를 쳐낼 스케줄을 따로 건의해본다던지, 투쟁이 필요하다. 
+
+# 18장 변하지 않는 것은 없다 
+## 1. 어떤 특성이 소프트웨어를 바꾸기 쉽게 만드는가? 당신은 이 특성을 자연스럽게 지니도록 한 상태에서 소프트웨어를 작성하는가? 
+### 역할과 책임이 잘 나누어진 코드가 소프트웨어를 바꾸기 쉽게 만든다. 기능을 삭제하던 추가하던 역할과 책임이 잘 나누어져 있으면 코드도 잘 읽히고 자연스럽다. 
+
+## 2. '코드의 주인은 없다'는 사실과, 다른 사람들보다 특정 인물이 더 경험이 많다는 사실 간의 균형을 어떻게 맞출 것인가? 이 문제는 프로그래머에 대한 업무 할당에 어떤 영향을 주는가? 
+### 경험이 많다는 것은 회사를 꼭 오래다녔다기 보다는, 일을 많이해서 그만한 능력치가 쌓였다는 것을 말하는 것 같다. 그리고 균형을 맞춰야 한다면 어떤 관점으로 균형을 맞추는지가 중요해보인다. 
+단순히 업무량을 N빵하면 경험이 많은 사람은 일을 많이해서 경험이 많고 또 그래서 일을 많이하고 싶어할 수도 있다. 따라서 경험이 많은 사람이 팀에 있다면 어쩌면 다른 사람 업무 할당이 적어질 수도 있다. 
+다만 그만한 내공 서로가 비슷한 내공으로 성장하게 하려면, 할당량이 적어도 그만한 내공을 쌓으려는 노력을 해야한다. 
+
+## 3. 모든 프로젝트는 코드가 자주 바뀌거나, 조금 바뀌거나 두 가지 중 하나에 해당한다. 후자의 경우 코드가 사용되지 않기 때문일 수도 있고, 외부의 모듈에 의한 확장으로 건강하게 설계 되었기 때문일 수도 있다. 단지 사람들이 불쾌함을 피하다보니 변하지 않은 경우일 수도 있다. 이런 종류의 융통성 없는 코드를 얼마나 가지고 있는가? 
+### 융통성이 없는 코드 어떻게 보면 소위 말해 하드코딩한 코드를 가리키는 것일 수도, 어떤 특정한 경우에만 단편적으로 동작하는 코드를 하드코딩이라 하겠다. 
+간단한 샘플 코드를 만들때는 하드코딩으로 동작만 확인을 빠르게 하는 편인데, 왠만하면 주먹구구 만들어진 코드는 사양하는데, 설계가 어렵고 절차가 복잡할 수록 잘못된 길로 갈 경우 하드코딩이 되었던 것 같다. 
+
+## 4. 프로젝트 관리도구가 코드의 변화를 관리하는데 도움이 되는가? 어떻게 개선할 수 있는가? 
+### 음 아직은 그렇다할 프로젝트 관리도구를 사용하고 있지 않다, 이력 관리를 하기 위해 github 도입이 절실하다. GPT는 이력관리보다는 이력파악에 초점이 더 가있기에, github을 사용해서 프로젝트를 만들어보고 싶다. 
+
+# 19장 코드 재사용 사례 
+## 1. 당신의 코드 베이스에는 코드 복제가 얼마나 존재하는가? '복사/붙여넣기'를 한 코드가 얼마나 자주 발견되는가? 
+### 자주 발견되지 않는다. 2번 이상 반복되면 왠만하면 함수나 객체를 통해 합치는 편이다. 
+
+## 2. 여러 코드 영역들이 서로 다른 것이라는 판단을 위해 혹은 서로 통합하지 않아도 된다는 판단을 위해, 서로 얼마나 달라야 하는지를 어떻게 결정할 수 있는가?
+### 음... 각자 지닌 역할과 책임이 상이한지를 확인하면 되지 않을까? 역할과 책임이 같다면 이는 동일한 것이라봐도 무방하다. 
+
+## 3. 종종 책이나 웹사이트에서 코드를 복사하여 적용하는가? '위생적인' 코드를 적용하기 위해 어느 정도의 노력을 들이는가? 무자비하게 레이아웃, 변수명 등을 수정하는가? 테스트를 추가하는가? 
+### 웹사이트 특히 샘플 코드에서 복사하는 경우가 많은 것 같다. 그런데 샘플 코드가 완전히 프로젝트에 들어맞지는 않으므로 구조를 최대한 이해하여 필요한 부분만 반영하려는 노력을 한다. 
+변수명은 정말 심혈을 기울여서 나중에 봐도 마음에 들게 가독성이 좋게 만들어야 하고, 레이아웃과 테스트는 점진적으로 도입하려는 단계이다. 
+
+## 4. 웹에서 코드를 복사했을 때, 그 주변에 실행 출처를 명시하는 주석을 달아야 하는가? 그 이유는 무엇인가? 
+### 오픈 라이센스를 활용하면 다는데, 웹에서 코드 복사한 것마다 출처를 명시하는 주석을 달아놓으면 코드 보는게 너무 복잡할 것 같다. 대신에 이력 관리를 위해서 별도 파일에 명시를 하거나 주석을 한쪽에 몰아 놓는게 나은 것 같다. 
+
+# 20장 효과적인 버전 관리 
+## 1. 버전 관리 도구는 GUI 도구와 커맨드라인 도구를 지원한다. 각각의 장단점은 무엇인가? 둘 다 이용할 줄 아는 것이 중요한가? 그 이유는 무엇인가? 
+### GUI는 편하지만 뭔가 명령어 기반이 아니어서 해당 GUI에대한 능숙도는 늘어나지만 커맨드라인에 대한 이해도는 늘지 않는다. 
+배우는 단계에서는 커맨드 라인을 위주로 사용하고, 또 어떤 에러와 과정들이 오고가는지 로그를 통해 확인하면 좋은 것 같다. 
+숙달이 되었다면 GUI를 활용해도 무방할거란 생각이 든다. 
+
+## 2. 더 간단한 중앙 집중식 버전 관리 도구에 비해 분산형 버전 관리 도구가 가지는 문제점은 무엇인가? 이러한 문제점을 어떻게 피할 수 있는가? 
+### 잘 모르는 내용으로 스킵 
+
+## 3. 적절한 버전 관리 도구를 사용하고 있는가? 다른 버전 관리 도구에는 있지만, 현재 사용하는 버전 관리 도구에는 없는 기능은 어떤 것인가? 
+### github을 사용했다. 다른 버전 관리도구를 사용하지 않아서 모르겠다. 
+
+## 4. 버전 관리 도구를 사용하면 개인 개발 머신을 백업할 필요가 없는가? 
+### 개인 개발 머신을 백업한다는게 무엇인지 이해하지 못함 스킵 
+
+## 5. 동시 작업을 위해 더 안전한 방식은 어느 것인가? 특정 기능을 켜고 끄는 feature-toggle과 동시 작업을 위한 브랜치 중에 어느쪽이 관리와 통합에 부담이 작은가? 
+### 잘 모르는 내용으로 스킵 
+
+## 6. 저장소에 변경사항을 커밋하려는 순간 서로 다른 두 가지 작업을 수행했을 꺠달았다. 커밋을 멈추고 체인지셋을 바꾸어 커밋을 나누어야 하는가? 
+## 아니면 그냥 한 번의 커밋으로 진행해야 하는가? 그 이유는 무엇인가? 다른 버전 관리 도구에서는 이러한 상황에서 어떻게 도움을 주는가? 
+### 잘 모르는 내용으로 스킵 
+
+# 21장 골키퍼 있다고 골 안들어가랴 
+## 1. QA 동료들과 얼마나 밀접하게 업무 관계를 맺고 있다고 생각하는가? 관계가 더 나아져야 하는가? 그렇다면 어떤 방법으로 개선될 수 있는가? 
+### 회사에 QA 팀이 없다. 개발단에서 시퀀스 다이어그램을 그리면서 검증을 하는 절차가 있다. 
+
+## 2. 개발 조직에서 소프트웨어의 품질에 가장 저해가 되는 요소는 무엇인가? 이를 해결하기 위해 무엇이 필요한가? 
+### 요구사항을 제대로 이해하지 않은 채로 개발하는 것이라 생각한다. 코드 작성하기 전에 요구사항과 설계를 먼저 구축하고 검증에서 충분히 가능하다는 생각이 들 때 본격적으로 코드 작업에 들어가면 좋아보인다. 
+
+## 3. 출시 과정이 얼마나 건전한가? 어떻게 개선할 수 있는가? 어떻게 해야 가장 잘 도울 수 있을지 QA팀에게 물어보라. 
+### 아직 과제 하나를 끝까지 해보지 않았다. 그래서 출시가 얼마나 건전한지 잘 모르겠지만, 검증을 아예 안하는 것은 아니고 클라이언트, 개발팀에서 검증을 수행하고 문제점을 해결한다. 
+
+## 4. 소프트웨어의 '품질'에 대해 책임지는 사람은 누구인가? 문제가 생겼을 때 '비난'을 받는 사람은 누구인가? 이 과정이 얼마나 건전한가? 
+### QA가 없으므로 개발자가 해결에 대한 책임을 진다. 비난은 문제를 책임지지 않은 사람에게 발생하겠지만, 아직까지는 문제가 발생했을 때 비난보다는 조금 쪼임?을 당하는 느낌 정도이다. 
+### 대부분 원인 분석을 통해 이성적으로 문제를 해결하려는 편이다. 
+
+## 5. 자신의 테스트 기술이 얼마나 훌륭하다고 생각하는가? 체크인하거나 QA팀으로 넘기기 전에 작업한 코드에 대해 어떤 방법으로 테스트 하는가? 
+### 음 사실 테스트 코드를 도입하고 싶지만 설계적인 리서치를 더 많이하고 있어서 테스트 코드는 못넣고 있다. 그런데 개발하면서 코드를 작성하다보면 논리가 꼬이는 불편함은 직감적으로 감지가 되기때문에, 이런 부분을 시간이 없다면 기록해두고 되도록이면 논리적인 오류를 해결하려는 편이다. 그런데 스스로 문제가 없다고 생각해도 예상 밖의 부분이나 실수로 문제가 발생할 수 있어서, 혼자서만 하는 검증이 늘 좋아보이지는 않는다. 
+
+## 6. 최근에 자신이 쳐놓은 그물을 벗어난 바보 같은 오류가 얼마나 되는가? 
+### 그물을 치지 못했다. 
+
+## 7. QA팀에 넘기는 소프트웨어의 품질을 보장하기 위해 단위 테스트에 더해 어떤 것을 더 개발 과정에 추가해야 하는가? 
+### QA와 일을 해보지 않아 감이 잡히지 않지만, 단위 테스트 내용을 알려주기 보다는 어떤 중요성이 있거나 오류가 자주 나는 곳을 봐달라고 하되 모든 히스토리를 공개하진 않을 것 같다. 
+### 그 이유는 테스트를 조금 더 객관적으로 하려면 모든 정보를 알려주면 오히려 선입견이 생길 수도 있어 보인다. 
+
+# 22장 프리징된 코드의 신기한 사례 
+## 1. 개발 과정에 공식적인 코드 프리징 기간이 있는가? 공들여 관리되고 있는가? 
+### 그런 기간은 공식적으로는 없지만, 그렇다고 배포되자마자 버전업을 하는 것은 아니기에 있는 것도 같다. 
+
+## 2. 프리징 기간에 적용하는 변경 사항이 안전하고 적절한지를 어떻게 확인하는가? 
+### 음... 딱히 안전성을 확인하기보다는 그렇다고 믿음이 생기면 반영이 되는 느낌인데, 자세히는 잘 모르겠다. 
+
+## 3. 빌드의 품질에 책임이 있는 것은 한 개인인가 아니면 팀 전체인가? 적절한 접근 방식은 어느 쪽이며 그 이유는 무엇인가? 
+### 팀 전체라고 생각한다. 혼자서 일하는게 아니라면 작은 소통, 디자인의 변경, 기획의 변경이 모두 품질에 영향을 준다고 생각한다. 
+
+## 4. 프로젝트의 코드 프리징 시점에 도달하기까기 기간이 오래 걸리는가? 이유는 무엇인가? 어떻게 줄일 수 있는가? 
+### 오래 걸리는 것 같다. 애초에 배포 버전 이전에는 만드는대로 나오는 형식이라. 프로세스 정립이 되지 않은 상태라 중구난방인 것 같다. 
+
+# 23장 제발 저를 출시해주세요 
+## 1. 새로운 소프트웨어 출시 버전을 세상에 내보낼 때를 언제 결정하는가?
+### 테스트를 여러번 거치고 모든 문제를 해결할 수는 없지만 어느정도 그래도 문제수가 줄어서 안정화가 되었다면 알려진 문제를 기록하고 출시하지 않을까 싶다.
+
+## 2. 빌드와 출시 절차를 반복 가능하고 신뢰할 수 있게 만들려면 어떻게 해야 하는가? 얼마나 간단한가? 얼마나 자주 빌드를 실패하는가? 
+### 아직 제대로된 출시 경험이 없어서 답변 불가. 
+
+## 3. 출시 버전 생성과 관련해 당신이 겪은 최악의 실패 사례는 무엇인가? 어떻게 하면 피할 수 있었을까?
+### 아직 제대로된 출시 경험이 없어서 답변 불가. 
+
+## 4. 빌드를 간헐적으로 실패하는가? 개발자의 PC와 CI 서버 중에 어느 쪽에서 실패가 발생하는가? 더 나쁜 경우는 어느쪽인가? 
+### 아직 제대로된 출시 경험이 없어서 답변 불가. 
+
+## 5. 빌드 절차와 출시 절차를 만들고 배치하는 작업이 특정인의 일이어야 하는가? 아니면 팀원 모두의 책임인가? 그 이유는 무엇인가? 
+### 팀원 모두의 책임이다. 누구 하나라도 마무리 못하면 출시가 가능한지 잘 모르겠다. 따라서 서로 출시가 잘될 수 있도록 협업하면 좋아보인다. 
+
+