diff --git "a/3\354\236\245/\354\235\264\354\234\240\355\235\254.md" "b/3\354\236\245/\354\235\264\354\234\240\355\235\254.md"
new file mode 100644
index 0000000..6ad3546
--- /dev/null
+++ "b/3\354\236\245/\354\235\264\354\234\240\355\235\254.md"
@@ -0,0 +1,113 @@
+## 3장 기본 두구
+
+ 📌 정리
+
+
+3장은 도구를 단순히 사용하는 것을 넘어서 나만의 작업대를 구축할 것을 강조하는 챕터다.
+일반 텍스트, 셸, 파워 에디팅, 버전 관리, 디버깅, 텍스트 처리, 엔지니어링 일지 각각의 장점을 설명해 주고
+구체적으로 ***어떻게*** 사용해서 나만의 연장(extension)으로 만들지 설명한다.
+이 챕터를 읽고 생각난 세션이 있는데 시청 강추 드립니다.
+[출처: re:COMMIT, 연사: 김영재, 세션: 시야가 넓은 개발자는 무엇이 다를까](https://youtu.be/NLSzp1Y-qLU?si=FER7iAAVALua_f12)
+---
+
+#### 🏷️ 일반 텍스트의 힘
+- 지식을 일반 텍스트로 저장하라.
+> 이 부분을 읽으면서 설정 파일이 생각났습니다.
+> yml, json syntax로 환경 설정 값을 관리하니 읽기도 편하고 변경하기도 편하고..
+
+#### 🏷️ 셸 가지고 놀기
+
+- GUI 환경의 기능은 일반적으로 설계자가 의도한 범위를 넘어설 수 없다
+> 동의하는 게 툴 익스텐션도 제공하는 기능만까지만 사용 가능하니까요! 셀을 가지고 노는 수준이 되면 많은 것들을 자동화할 수 있을 것 같아요.
+> 그러나 저는 아직까진 기존 익스텐션으로도 충분해요
+
+#### 🏷️ 파워 에디팅
+
+##### vim command 정리
+
+| command | 설명 |
+|:-------------------------------------------------------------------------------------:|:---------------------------------------------------------|
+| | 💡 텍스트를 편집할 때 문자, 단어, 줄, 문단 단위로 커서를 이동하거나 내용을 선택하라 |
+| w | 커서를 다음 단어로 이동 |
+| b | 커서를 앞 단어로 이동 |
+| } | 커서를 다음 블록으로 이동 |
+| { | 커서를 앞 블록으로 이동 |
+| V | 라인 전체 선택 |
+| Vj 또는 Vk | 멀티 라인 선택 j(상) k(하) |
+| ve | 단어 선택 (현재 커서 위치서부터 단어 끝까지 선택) |
+| v} | 블록 선택 (현재 커서 위치서부터 블록 끝까지 선택) |
+| | 💡 코드를 편집할 때 반대쪽 괄호로 이동하거나, 함수, 모듈 등 다양한 문법 단위로 커서를 이동하라 |
+| 커서를 괄호에 두고 % | 현재 괄호의 짝이되는 괄호로 이동 |
+| [[ | 파일의 시작 지점으로 이동 |
+| ]] | 파일의 끝 지점으로 이동 |
+| | 💡 특정 줄 번호로 이동하라 |
+| n(n은 라인번호)gg | n번 라인으로 이동 |
+| 1. Vj (멀티라인 선택)
2. : (명령어 입력 모드)
3. sort (i는 Case insensitive sort, !는 역순) | 여러 줄을 선택한 후 가나다순으로 정렬하라 |
+| | 문자열로, 또 정규 표현식으로 검색하라. 이전에 검색했던 것을 다시 검색하라 |
+| /pattern | 정규식 패턴 검색 |
+| n | 패턴에 일치하는 다음 단어로 이동 |
+| :%s/old/new/g | 패턴에 일치하는 모든 old를 new로 변경 |
+| `모르겠음` | 이전에 검색했던 것을 다시 검색하라 |
+| `모르겠음` | 에디터 창을 여러 구역으로 쪼개라. 그리고 각 구역 사이를 이동하라 |
+| control w | 인서트 모드에서 마지막에 입력한 단어 지우기 |
+
+> 상우좌하 이동만 사용하다 다른 명령어도 정리해봤습니다. 자꾸 사용해서 손에 익혀야 겠네요
+
+##### Intellij 단축키 정리
+
+| shortcut | 설명 |
+|:-------------------:|:--------------|
+| control + shift + R | 테스트 실행하라 |
+| F2 | 컴파일 에러 위치로 이동 |
+
+
+##### code 포맷팅
+
+- 변경한 코드의 들여쓰기 indent를 자동으로 맞춰라
+> [spotless](https://github.com/diffplug/spotless) (코드 포맷팅 라이브러리) 사용하고 있습니다.
+
+
+#### 생산성 향상에 도움이 된 툴
+> 제가 사용하고 있는 툴중에 생산성 향상에 도움되는 툴 공유드립니다
+
+1. Raycast
+- 노트북 시스템 뿐만 아니라 노션, 슬랙, 깃, 지라 등 어플리케이션의 기능을 일원화 해주는 툴입니다. 최고입니다.
+2. Perplexity
+- AI기반 검색 엔진 서비스인데 답변 뿐만 아니라 참고 링크와 연관 질문까지 제공해주고 답변 텍스트중에서 드래그로 후속 질문까지 가능합니다.
+- 퍼플렉시티는 어떤 개념을 공부할 때 구글링으로 여러 블로그에서 정보 취합해주는 시간을 줄여줘서 자주 사용하고 있습니다.
+
+
+#### 🏷️ 버전 관리
+
+> 주로 사용하는 명령어
+>> reset, rebase, cherry-pick, stash
+>
+> 다른 명령어도 구경해보자. [docs](https://git-scm.com/docs)
+>
+> 전 회사에서 배포 주기가 일 2회였습니다. 배포 주기가 짧다 보니 코드 롤백도 꽤 빈번하게 발생했어요. 그래서 revert를 자주 사용했습니다.
운영 코드 롤백해본 경험이 없어서 revert 처음 사용하던 날 굉장히 긴장했던 기억이 나네요.
롤백 해보면서 커밋 단위가 롤백 상황에서도 중요하단 걸 느꼈어요. 커밋 단위가 명확하지 않으면 어떤 코드가 롤백된 건지 헷갈리더라구요..
+
+#### 🏷️ 디버깅
+
+- 실마리 찾기
+ - 컴파일 에러 확인
+ - 관련 자료를 모두 모아야 한다.
+ > 버그 리포트를 보고 원인을 단언하고 접근하면 삽질 시간이 증가하더라구요.
+ - 경계 조건과 실제 최종 사용자의 사용 패턴 모두를 철저히 테스트해야 한다
+ > `계약에 의한 설계`가 생각났다.
+ > > Supplier(특정 메서드 구현하여 제공하는 사람)은 Client(메서드 사용하는 사람)이 메서드 호출(사용) 시 모든 입력 조건에 맞게 결과를 보장해야 하는 것이다. 그렇다. 버트란드 마이어가 제시한 DbC는 메서드마다 계약을 부과한다. 계약은 크게 사전 조건(precondition), 사후 조건(postcondition), 사후 조건 안의 페널티(penalty), 불변 조건(Invariant condition)이 있다.
+ 출처: [쿠킴의 레시피 <>](https://kukim.tistory.com/76)
+ >
+ > 사전 조건, 사후 조건에 대한 테스트 케이스를 꼼꼼히 작성해두면 디버깅 단축에 도움이 될 것 같다.
+- 디버깅 전략
+ - 버그 재현하기. 버그를 재현할 수 없다면 어떻게 그 버그를 고쳤다는 것을 확인할 수 있겠는가?
+- 미지의 세계에 온 프로그래머
+ > 이직 후 새로운 코드 파악할 때 아주 도움될 것 같다. 코드의 히스토리를 모르니 모든게 미지의 영역이다.
그래서 무조건 질문하기 바빴는데 아래 팁들을 적극 활용했다면 테스트 케이스도 보완하고 버그 픽스도 더 빨리 했을 듯..
+ - 코드를 고치기 전 실패하는 테스트부터.
+ > 많은 고수 개발자들이 강조하는 버그 재현하기... 실천하자
+ - 릴리즈 사이에서 발생한 문제
+ > 시도해본 적 없는 방식인데 다음 회사에서 시도해봐야겠다.
+ - 소거법
+ - 우리 둘 중 하나가 자신의 실수일 수 있는 일을 시스템의 문제라고 탓하기 시작하면 우리는 그 사건을 떠올리도록 'select가 망가졌어'라는 표현을 사용한다.
+ > 삽질할 때 이 일화를 떠올려야 겠다.
+- 디버깅 체크 리스트 (137p)
+ > 문제 해결 문서 템플릿을 만들어 기록했었는데 디버깅 체크리스트를 추가해야겠다.