diff --git "a/7\354\236\245/\354\235\264\354\203\201\354\241\260.md" "b/7\354\236\245/\354\235\264\354\203\201\354\241\260.md"
new file mode 100644
index 0000000..7181b2b
--- /dev/null
+++ "b/7\354\236\245/\354\235\264\354\203\201\354\241\260.md"
@@ -0,0 +1,31 @@
+# 코딩하는 동안
+
+## 파충류의 뇌에 귀 기울이기
+- 찜찜한 기분이 든다는 것은 지금까지의 경험을 바탕으로 무의식적으로 오류에 대한 가능성을 느끼고 있다는 것
+- 첫 단추를 잘 꿰어야 미래에 작업에 지장이 없다는 것은 처음 코드를 냄새나게 짜놓으면 나중에 힘들어 진다는 것.
+  - 그래서 저는 개발할때 시작할때 너무 시간을 많이 소모합니다. 다른 분들은 어떻게 하시나요? 내공이 쌓이면 그냥 막힘없이 후딱 개발한게 정답이고 그렇게 되는걸까요?
+ 
+## 우연에 맡기는 프로그래밍
+- 왜 성공하고, 왜 실패하는지에 대한 정확한 원인을 알지 못한다면 본인이 인지하고 개발한 것이 아니라 우연에 맡긴 것이다.
+- 불필요한 state와 effect가 남용되어 뭐 하나 누르면 갑자기 페이지 여기저기서 미친듯이 리렌더링이 되는 경우를 본 적이 있다.
+  - 지금 원하는 결과물을 내놓을지 몰라도, 추후 뭐 하나 건드리면 갑자기 원하는대로 동작하지 않고, 심지어는 어디를 어떻게 손대야할지 감도 안오는 경우가 생길 수 있다.
+- 머머리와 풍성충이 번갈아 당선되는건 우연
+- 경험이 적은 프로그래머에게 코드를 상세히 설명할 수 있는가? 부트캠프 멘티들한테 설명해주려고 리액트 문서 읽은게 많은 공부가 됨
+
+## 알고리즘의 속도
+- 대충 제곱으로 안되게만...
+- 지피티가 알아서 최적화된 알고리즘을 잘 짜주니까 편함
+
+## 리팩터링
+- 밖으로 드러나는 동작은 유지하고 내부 구조를 변경하여 코드를 재구성하는 체계적 기법
+- 리팩터링 앞부분 좀 읽어봤는데 마틴 파울러는 커밋을 엄청 철저하게 잘 나누더라. 리팩터링인것, 아닌것...
+- 리팩터링을 수시로 하기 어려운 이유는 협업하는 다른 직군과 무관하게 오로지 엔지니어만의 영역이기 때문이라고 생각한다.
+  - 디자이너나 기획자한테 리팩토링에 투자할 시간을 확보해야 한다고 하면 이해를 못할지도? 실제로는 지금 리팩터링을 해놔야 다음 작업이 편한 경우도 있는데..
+- 리팩터링을 하고싶어도 테스트코드가 없어서 불안함. 특히, 유틸함수나 커스텀 훅이 아니라 UI에 영향을 줄 수도 있는 리팩터링이라면 더욱 불안함.
+
+## 테스트로 코딩하기
+- 테스트 중요한건 알지... 근데 넘흐 귀찮다. 특히, 제품에 애착이 없다던가, 개발만 하고 유지보수는 내가 안한다던가 그런 경우에는...
+- 코드를 먼저, 테스트는 나중에 시간될때 라는 선택지는 별로 좋지 않은걸까?
+
+## 이름 짓기
+- 리액트에서는 handle, on prefix 사용이 어려운 것 같다.