diff --git "a/4\354\236\245/\354\204\234\354\244\200\355\231\230.md" "b/4\354\236\245/\354\204\234\354\244\200\355\231\230.md"
new file mode 100644
index 0000000..33cfd9f
--- /dev/null
+++ "b/4\354\236\245/\354\204\234\354\244\200\355\231\230.md"
@@ -0,0 +1,92 @@
+# 실용주의 편집증
+
+> ash island의 paranoid를 들으며 , , ,
+
+> gpt왈
+>
+>편집증(偏執症)은 정신 건강 분야에서 사용되는 용어로, 비합리적이고 근거 없는 의심과 불신을 특징으로 하는 정신 상태를 말합니다. 프로그래밍 맥락에서 '실용주의 편집증'이라는 표현은 코드의 안정성과 신뢰성을 높이기 위해 건전한 의심과 주의를 기울이는 태도를 의미합니다.
+>
+>프로그래머로서 편집증적 접근은 다음과 같은 의미를 가질 수 있습니다:
+>
+>1. 코드 검증: 자신의 코드를 항상 의심하고 철저히 테스트합니다.
+>2. 보안 의식: 잠재적인 보안 위협을 항상 염두에 둡니다.
+>3. 오류 예방: 발생 가능한 모든 오류 상황을 고려하고 대비합니다.
+>4. 지속적인 개선: 코드의 품질을 끊임없이 향상시키려고 노력합니다.
+>
+>이러한 '실용주의 편집증'은 소프트웨어의 품질을 높이는 데 도움이 될 수 있습니다.
+
+우선 단정짓고 가시죠. "우리는 완벽한 소프트웨어를 만들 수 없다."
+
+실용주의 프로그래머는 자기 자신도 믿지 않는다.
+
+
+왜 why? 우리는 완벽한 소프트웨어를 만들 수 없으니까.
+
+<br/>
+
+DBC 이건 어렵네요.
+
+코드를 작성하기 전에 유효한 입력 범위가 무엇인지, 경계 조건인지, 루틴이 뭘 전달한다고 약속하는지, 혹은 더 중요하게는 무엇을 약속하지 않는지 등을 나열하는 것만으로도 도움이 된다.
+
+> 똥코드 작성하기 전에 미리 생각하고 작성하자.
+
+## 죽은 프로그램은 거짓말을 하지 않는다
+
+모든 오류는 정보를 준다.
+
+"오류가 발생할 리 없다"는 생각은 갖다 버리자.
+
+제발 오류 메시지를 잘 읽어보자.
+
+> 생각해보면 라이브러리단에서도 에러 처리할 때 메시지가 명확한 라이브러리가 있는 반면 그렇지 않은 라이브러리들도 있었던 것 같아요.
+>
+> 만드시는 라이브러리가 있다면 오류 처리는 어떻게 해주고 계시나요? 저는 `suspensive` 이 라이브러리의 오류 처리 참고해서 처리 하는 중입니다.
+
+### 잡은 후 그냥 놓아주는 것은 물고기뿐
+
+함수 내부에선 에러를 catch 하고 다시 throw 하지 않는다.
+
+첫번째 이유는 애플리케이션 코드가 오류 처리 코드 사이에 묻히지 않아 가독성을 높혀준다.
+
+두번째 이유는 해당 함수 내부에서 일어나는 모든 예외를 처리해 주어야 하고, 추가된다면 해당 throw에서도 추가해줘야 한다.
+
+> 보통 어떻게 처리하세요?
+
+### 망치지 말고 빨리 멈춰라
+
+읽어보니 이 부분은 적당히 가능한 부분에서는 쓸모가 있어보이더라구요!
+
+죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적다는 듣다보면 맞는 느낌이 드네요.
+
+## 단정적 프로그래밍
+
+"그런 일을 절대 일어날 리 없어" 라는 플래그를 심지 말자.
+
+사실 그런 일이 안 일어났으면 좋겠다는 마음 또는 생각이 아닐까 싶다.
+
+assert는 자바스크립트 브라우저에는 없어서 (web-worker는 있어요) 만들어 사용해야 한다. (토스꺼 보고 뭐,, 스윽)
+
+### 단정과 부작용
+
+하이젠버그적인 문제 메모..
+
+> 개발자 만났을 때 아이스브레이킹 주제 , ,
+
+## 리소스 사용의 균형
+
+아아,, 리소스 해제는 자주 까먹는 부분인데,, clearInterval, unobserve와 같은 거 잘 써야겠네요,, 
+
+## 헤드라이트를 앞서가지 말라
+
+알쓸신잡 +1
+
+짧게 짧게 피드백을 받고, 그걸 통해 앞을 내다보자.
+
+이를테면 테스트 코드, 유저 테스트 등 여러 방법이 있지 않을까?
+
+> 기획이 그렇게 오면 싸워야하나
+
+우리는 미래의 유지 보수를 고려해서 설계해야하지만, 우리가 볼 수 있는 미래까지만 고려해야한다.
+
+> 어느정도 반성을 하게끔 만드는 문장입니다 , , 늘 미래를 바라봤었는데 잘못된 방향이었을 수도 있다는 생각이 드네요.
+