스트리트 코더 sprint 8 김지수

2026/Street_Coder/tttghost/chapter4.md

@@ -0,0 +1,21 @@
+# 4장 맛있는 테스트
+
+## 논의주제
+요즘도 테스트 코드를 직접 작성하시나요? AI의 발전에 따라 테스트 작성 방식이 어떻게 달라졌는지 궁금합니다.
+저는 평소에 테스트 코드를 거의 짜지 않다가, AI가 발전하면서 AI의 도움을 받아 조금씩 짜보고 개념을 이해해 나가는 정도로 활용하고 있습니다.
+다른 분들은 AI와 테스트를 어떤 비중으로 함께 쓰고 계신지, 그리고 그 과정에서 느낀 장단점이 있다면 함께 이야기해 보면 좋겠습니다.
+
+## 감상평
+13.4에서 "요즘은 자동 테스트가 수동 테스트보다 비용이 더 낮다"는 말이 인상적이었습니다.
+예전에는 자동 테스트를 짤 시간이 아까워서 그냥 손으로 돌려보는 게 빠르다고 생각했는데, 그 시간이 쌓이면 결국 더 비싸진다는 점을 다시 느꼈습니다.
+평소에 테스트에 좀 소홀했는데, 테스트에 대해 다시 생각해볼 만한 계기가 되었습니다.
+
+정규식 부분도 찔렸습니다.
+그동안 그냥 "갖다 쓰는 도구"로만 봤습니다. 필요하면 검색해서 복붙하고, 동작하면 그만이라는 식이었습니다.
+기본 문법이라도 제대로 이해해두면 상황에 맞게 조합하거나 변형할 수 있을 텐데, 그걸 안 해왔다는 것을 깨달았습니다.
+
+## 느낀 점
+테스트를 평소에 안 하다가 막상 짜려고 하니 오히려 거기에 포커스가 쏠려서 본질 개발에 소홀해졌던 경험이 있습니다.
+그래서 거창한 테스트를 한 번에 짜려고 덤비기보다, 작은 테스트를 더 많이 짜보는 습관부터 들여야겠다고 생각했습니다.
+그러다 보면 자연스럽게 근육이 붙을 것 같습니다.
+

2026/Street_Coder/tttghost/chapter5.md

@@ -0,0 +1,31 @@
+# 5장 보람 있는 리팩터링
+
+## 논의주제
+AI가 리팩터링을 상당 부분 대신해주는 시대가 되면서, 개발자가 리팩터링을 바라보는 관점 자체가 달라지고 있다고 느꼈습니다.
+다른 분들은 실무에서 AI에게 리팩터링을 맡기는 비중이 어느 정도이신가요?
+또 "AI에게 맡길 수 있는 리팩터링"과 "사람이 직접 해야 하는 리팩터링"을 나누는 본인만의 기준이 있으신지 궁금합니다.
+
+## 감상평
+제목이 "보람 있는 리팩터링"이라 처음엔 "그럼 보람 없는 리팩터링도 있나?" 싶었는데, 생각해보면 충분히 그럴 수 있겠다 싶었습니다.
+목적 없이 마구잡이로 하는 리팩터링은 오히려 시간만 쓰고 끝나니까요.
+
+리팩터링을 하는 이유는 결국 미래를 위한 것이라는 생각이 들었습니다.
+지금 조금 귀찮아도 나중에 더 간결하고 재사용 가능하게 두는 것, 안 하면 언젠가 터지고 그 피해는 인계받는 사람에게 돌아간다는 점이 와닿았습니다.
+
+책에서는 리팩터링할 때 공통 코드를 추출해서 기존 코드와 새로운 코드 사이에 "중간 교착점"을 만들어가라고 합니다.
+마치 게임에서 중간 세이브 지점을 두는 것과 비슷한 개념으로 받아들였습니다.
+그 연장선에서 인터페이스 설계 이야기도 나오는데, 구현체가 바뀌어도 행동이 정해져 있으니 리팩터링이 훨씬 쉬워진다는 점이 납득됐습니다.
+
+다만 책 내용보다 현실은 조금 더 앞서 나가 있다는 느낌도 받았습니다.
+요즘은 AI가 리팩터링을 꽤 잘 해주고, 심지어 리팩터링의 신뢰를 담보하던 테스트조차 AI가 작성해주는 시대니까요.
+결국 중요한 건 "좋은 코드를 볼 줄 아는 눈"과 "AI에게 잘 지침을 내리는 능력"이라는 생각이 들었습니다.
+
+## 느낀 점
+예전에 코드를 깔끔하게 만들고 싶어서 제가 책임지고 야근하며 리팩터링했던 적이 있습니다.
+결과물은 깔끔해졌고 제 머릿속에도 정리가 확실히 됐지만, 장기적으로 보면 좋은 선택은 아니었다는 생각이 듭니다.
+들인 시간 대비 팀 전체에 돌아간 가치가 그만큼 컸는지 돌아보면 애매했습니다.
+
+이번 장을 읽으면서 다시 정리가 됐습니다.
+리팩터링은 우아한 코드를 짜는 것이 아니라 잘 돌아가는 코드를 만드는 것, 그리고 막연히가 아니라 의도를 가지고 해야 한다는 것.
+특히 "테스트되지 않는 코드를 리팩터링하는 것은 금물"이라는 대목이 인상적이었습니다.
+큰 프로젝트일수록 한 번에 바꾸려 하지 말고 점진적으로 가야 한다는 점도 기억해두고 싶습니다.

2026/Street_Coder/tttghost/chapter6.md

@@ -0,0 +1,21 @@
+# 6장 조사를 통한 보안
+
+## 논의주제
+위협 모델링 파트에서 "한쪽에서 얻은 정보로 다른 곳을 공격한다"는 내용이 인상적이었습니다.
+솔직히 저는 사이트마다 비밀번호를 거의 비슷한 패턴으로 쓰고 있는데, 다른 분들은 사이트별로 비밀번호를 다르게 관리하거나 보안에 특별히 신경 쓰는 부분이 있으신가요?
+
+## 감상평
+보안은 거창한 것이 아니라 정말 작은 것에서 터진다는 점이 계속 반복됐습니다.
+비밀번호를 설정하지 않은 개발자가 많다는 사실, 인적 보안이 약해지는 금요일 같은 포인트까지 짚어주는 걸 보면 결국 사람이 제일 약한 고리인 것 같습니다.
+
+"최소한의 권한만 주도록 설계하라"는 대목에서 찔렸습니다.
+코드에서 접근 제한자는 꼼꼼히 신경 쓰면서, 정작 GitHub PAT는 public 권한으로 마구 만들어 여기저기 쓰고 있었습니다.
+앞뒤가 안 맞는 상태였다는 걸 이번 기회에 깨달았습니다.
+
+은둔 보안(security through obscurity)도 흥미로웠습니다.
+그 자체가 나쁜 것이 아니라 적절히 감춰서 교환하는 것은 괜찮고, 결국 HTTPS나 HTTP/2도 그 연장선에서 발전해왔다는 관점이 새로웠습니다.
+
+## 느낀 점
+이번 장을 읽으면서 가장 먼저 해야 할 일이 생겼습니다.
+쓰지 않는 GitHub PAT 정리, 필요한 권한만 남기기, API 키를 소스에 두지 않기 같은 기본부터 챙겨야겠습니다.
+SQL 인젝션이나 XSS처럼 고전적인 공격도 직접 시도해보면서 "어떻게 뚫리는지"를 몸으로 익혀봐야 방어도 제대로 할 수 있을 것 같습니다.