ThinkAboutSoftware · tttghost · Apr 16, 2026 · Apr 16, 2026 · Apr 16, 2026 · jongfeel
diff --git a/2026/Street_Coder/tttghost/chapter4.md b/2026/Street_Coder/tttghost/chapter4.md
@@ -0,0 +1,21 @@
+# 4장 맛있는 테스트
+
+## 논의주제
+요즘도 테스트 코드를 직접 작성하시나요? AI의 발전에 따라 테스트 작성 방식이 어떻게 달라졌는지 궁금합니다.
+저는 평소에 테스트 코드를 거의 짜지 않다가, AI가 발전하면서 AI의 도움을 받아 조금씩 짜보고 개념을 이해해 나가는 정도로 활용하고 있습니다.
+다른 분들은 AI와 테스트를 어떤 비중으로 함께 쓰고 계신지, 그리고 그 과정에서 느낀 장단점이 있다면 함께 이야기해 보면 좋겠습니다.
+
+## 감상평
+13.4에서 "요즘은 자동 테스트가 수동 테스트보다 비용이 더 낮다"는 말이 인상적이었습니다.
-13.4에서 "요즘은 자동 테스트가 수동 테스트보다 비용이 더 낮다"는 말이 인상적이었습니다.
+1.3.4에서 "요즘은 자동 테스트가 수동 테스트보다 비용이 더 낮다"는 말이 인상적이었습니다.
-13.4에서 "요즘은 자동 테스트가 수동 테스트보다 비용이 더 낮다"는 말이 인상적이었습니다.
+1.3.4에서 "요즘은 자동 테스트가 수동 테스트보다 비용이 더 낮다"는 말이 인상적이었습니다.
+예전에는 자동 테스트를 짤 시간이 아까워서 그냥 손으로 돌려보는 게 빠르다고 생각했는데, 그 시간이 쌓이면 결국 더 비싸진다는 점을 다시 느꼈습니다.
+평소에 테스트에 좀 소홀했는데, 테스트에 대해 다시 생각해볼 만한 계기가 되었습니다.
+
+정규식 부분도 찔렸습니다.
+그동안 그냥 "갖다 쓰는 도구"로만 봤습니다. 필요하면 검색해서 복붙하고, 동작하면 그만이라는 식이었습니다.
+기본 문법이라도 제대로 이해해두면 상황에 맞게 조합하거나 변형할 수 있을 텐데, 그걸 안 해왔다는 것을 깨달았습니다.
+
+## 느낀 점
+테스트를 평소에 안 하다가 막상 짜려고 하니 오히려 거기에 포커스가 쏠려서 본질 개발에 소홀해졌던 경험이 있습니다.
+그래서 거창한 테스트를 한 번에 짜려고 덤비기보다, 작은 테스트를 더 많이 짜보는 습관부터 들여야겠다고 생각했습니다.
+그러다 보면 자연스럽게 근육이 붙을 것 같습니다.
+
diff --git a/2026/Street_Coder/tttghost/chapter5.md b/2026/Street_Coder/tttghost/chapter5.md
@@ -0,0 +1,31 @@
+# 5장 보람 있는 리팩터링
+
+## 논의주제
+AI가 리팩터링을 상당 부분 대신해주는 시대가 되면서, 개발자가 리팩터링을 바라보는 관점 자체가 달라지고 있다고 느꼈습니다.
+다른 분들은 실무에서 AI에게 리팩터링을 맡기는 비중이 어느 정도이신가요?
+또 "AI에게 맡길 수 있는 리팩터링"과 "사람이 직접 해야 하는 리팩터링"을 나누는 본인만의 기준이 있으신지 궁금합니다.
+
+## 감상평
+제목이 "보람 있는 리팩터링"이라 처음엔 "그럼 보람 없는 리팩터링도 있나?" 싶었는데, 생각해보면 충분히 그럴 수 있겠다 싶었습니다.
+목적 없이 마구잡이로 하는 리팩터링은 오히려 시간만 쓰고 끝나니까요.
+
+리팩터링을 하는 이유는 결국 미래를 위한 것이라는 생각이 들었습니다.
+지금 조금 귀찮아도 나중에 더 간결하고 재사용 가능하게 두는 것, 안 하면 언젠가 터지고 그 피해는 인계받는 사람에게 돌아간다는 점이 와닿았습니다.
+
+책에서는 리팩터링할 때 공통 코드를 추출해서 기존 코드와 새로운 코드 사이에 "중간 교착점"을 만들어가라고 합니다.
-책에서는 리팩터링할 때 공통 코드를 추출해서 기존 코드와 새로운 코드 사이에 "중간 교착점"을 만들어가라고 합니다.
+책에서는 리팩터링할 때 공통 코드를 추출해서 기존 코드와 새로운 코드 사이에 "접점"을 만들어가라고 합니다.
-책에서는 리팩터링할 때 공통 코드를 추출해서 기존 코드와 새로운 코드 사이에 "중간 교착점"을 만들어가라고 합니다.
+책에서는 리팩터링할 때 공통 코드를 추출해서 기존 코드와 새로운 코드 사이에 "접점"을 만들어가라고 합니다.
+마치 게임에서 중간 세이브 지점을 두는 것과 비슷한 개념으로 받아들였습니다.
+그 연장선에서 인터페이스 설계 이야기도 나오는데, 구현체가 바뀌어도 행동이 정해져 있으니 리팩터링이 훨씬 쉬워진다는 점이 납득됐습니다.
+
+다만 책 내용보다 현실은 조금 더 앞서 나가 있다는 느낌도 받았습니다.
+요즘은 AI가 리팩터링을 꽤 잘 해주고, 심지어 리팩터링의 신뢰를 담보하던 테스트조차 AI가 작성해주는 시대니까요.
+결국 중요한 건 "좋은 코드를 볼 줄 아는 눈"과 "AI에게 잘 지침을 내리는 능력"이라는 생각이 들었습니다.
+
+## 느낀 점
+예전에 코드를 깔끔하게 만들고 싶어서 제가 책임지고 야근하며 리팩터링했던 적이 있습니다.
+결과물은 깔끔해졌고 제 머릿속에도 정리가 확실히 됐지만, 장기적으로 보면 좋은 선택은 아니었다는 생각이 듭니다.
+들인 시간 대비 팀 전체에 돌아간 가치가 그만큼 컸는지 돌아보면 애매했습니다.
+
+이번 장을 읽으면서 다시 정리가 됐습니다.
+리팩터링은 우아한 코드를 짜는 것이 아니라 잘 돌아가는 코드를 만드는 것, 그리고 막연히가 아니라 의도를 가지고 해야 한다는 것.
+특히 "테스트되지 않는 코드를 리팩터링하는 것은 금물"이라는 대목이 인상적이었습니다.
+큰 프로젝트일수록 한 번에 바꾸려 하지 말고 점진적으로 가야 한다는 점도 기억해두고 싶습니다.