diff --git "a/4\354\236\245/\353\260\225\354\203\201\353\262\224.md" "b/4\354\236\245/\353\260\225\354\203\201\353\262\224.md"
new file mode 100644
index 0000000..4342bee
--- /dev/null
+++ "b/4\354\236\245/\353\260\225\354\203\201\353\262\224.md"
@@ -0,0 +1,77 @@
+## 4장 실용주의 편집증
+4장을 읽기전에 내가 생각한 실용주의는 문제 해결과 소프트웨어 개발에 있어 현실적이고 효과적인 접근 방식(끊임없는 학습, 책임감, 도구 잘 다루기 등)을 의미하는 것으로 생각했고 그런 실용주의 의미와 어울리지 않는 편집증이 합쳐진 챕터라서 어떤 의미를 전달하려고 하는 것인가가 궁금했다.
+
+> 읽고 난 후에는 실용주의 편집증을 완벽한 소프트웨어를 만들 수 있다는 망상을 버려라 로 이해했다.
+
+> 4장에서 전달하고자 하는 의미는 자기 자신을 100% 믿지 말고 방어적인 코드를 작성하는 습관을 기르자. 불완전한 시스템, 불가능한 요구사항 속에서 안전하게 살아보자. 인듯하다
+
+### Topic 23. 계약에 의한 설계
+계약은 정직한 거래를 보장하는 최선의 해법 중 하나
+- 자신과 상대편의 권리 및 책임 정의
+
+그럼 소프트웨어 모듈이 서로 소통을 위한 계약을 맺는 것은 무엇일까?
+- DBC (Design By Contract):
+  - 소프트웨어 모듈의 권리와 책임 문서화 + 합의
+  - 책임: 자신이 하는 일이라고 주장하는 것만 하는 프로그램
+  - 루틴(메소드) 책임의 조건
+    - 선행 조건: 호출 쪽 입력 책임
+    - 후행 조건: 자기가 할 것이라 보장하는 것
+    - 클래스(상태) 불변식: 호출자로 제어권이 반환 되는 데이터의 불변식은 참
+    - 정리: 호출자가 루틴의 모든 선행조건을 충족한다면 해당 루틴은 종료 시 모든 후행 조건과 불변식이 참이 되는 것을 보장
+  - Tip 37. 계약으로 설계하라
+- 그럼 DBC는 어떻게 구현?
+  - 작성 가이드
+    - 유효 입력 범위
+    - 경계 조건
+    - 루틴이 뭘 전달한다고 약속하는지
+    - 무엇을 약속하지 않는지 → 해당 부분도 명시해보자
+  - 단정문(assert)으로 계약 검사를 다할 수 있는가 → false
+    - 상속, 오버라이드로 인한 구멍
+
+DBC와 일찍 멈추기(ealry stop, ealry return)는 잘어울림
+
+의미론적 불변식?
+- 어겨서는 안되는 고정된 규칙 (일시적 정책 영향 X)
+- 이를 문서화
+
+> [계약에 의한 설계(Design by Contract)로 견고한 서비스 만들기](https://armadillo-dev.github.io/design/programming/desing-by-contract/)에 간단한 예시와 함께 이 장을 요약해주는 느낌이라 공유합니다.
+
+### Topic 24. 죽은 프로그램은 거짓말을 하지 않는다
+‘있을 수 없는 일’이 발생했을 때 더 망치기 전에 빨리 종료하는게 낫다. 오류 메시지좀 읽어라
+
+일반적으로 죽은 프로그램이 끼치는 피해가 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적은 법이다
+> react errorBoundary와 suspense를 선언적으로 사용하여 전역적, 컴포넌트 단위로 잘 감싸준다면.. 책에서 나오는 슈퍼바이저가 관리하는 효과를 내면서 죽은 컴포넌트에서 나쁘지 않은 UX를 제공할 수 있지 않을까?
+
+> 그리고 예외처리할 때 특별한 이유 없으면 위로 올리지 말자요.. 책에서 나온대로 사고가 난 지점에서 일찍 멈추는게 유리하니까.. 
+
+### Topic 25. 단정적 프로그래밍
+
+`그런 일은 절대 일어날 리 없어` 그만
+- 그런 일이 일어날 리 없다 생각들면 그런 일에 대한 확인 코드 추가해라
+
+tip 39. 단정문(assert)으로 불가능한 상황을 예방하라
+
+단정문이 상태를 바꿀 수 있으면 안된다. 사이드이펙트 유발하면 안됨
+
+진짜 정상 플로우로 흘러갈 수 있다면 해당 예외 처리는 단정(assert) X
+
+### Topic 26. 리소스 사용의 균형
+리소스 할당 해제 관련해서 예제..
+> 저자가 무엇을 의도한 것인지는 알겠는데 유저를 업데이트하는 함수가 파일 오픈에 관여하는게 과연 맞을까에 대해서는 다시 한 번 생각해볼 필요가 있을 듯함
+
+c++나 러스트 같은 언어의 일반적인 스코프 규칙에서는 함수나 블록 종료, 예외 등으로 변수가 스코프를 벗어나면 변수의 메모리가 해제된다.
+> 자바도 try-with-resources 라는걸 지원해주는걸로 앎. try에서 자원 객체 전달해주고 블록 끝나면 자동으로 자원 반납해줌. AutoClosable 인터페이스 구현한 구현체에서만 사용가능 했던걸로 앎. 
+
+`실용주의 프로그래머는 자신을 포함해서 아무도 믿지 않는다.`
+> 띵언
+
+### Topic 27. 헤드라이트를 앞서가지 말라
+불확실한 미래에 대비한 설계를 하느라 진을 빼는 대신 언제나 교체 가능한 코드를 작성하여 대비하면 된다.
+=> 예언하지 말라
+
+헤드라이트 거리에 한계가 있는 것 처럼 우리도 한 두 단계 앞 정도의 미래만 내다볼 수 있다.
+
+미래의 유지보수를 고려해서 설계해야 하지만 볼 수 있는 미래까지만 고려해야 하고, 더 많이 예측하려 할 수록 틀릴 가능성이 높아진다.
+
+> 그러니 좋은 대책은 교체하기 쉽게 만드는 것, 근데 적당히 교체 가능한 코드 작성하는 것도 쉽지 않음..
+