스트리트 코더 sprint 8 - 권태형

2026/Street_Coder/taehyoung/4.md

@@ -0,0 +1,9 @@
+# 4장
+
+- 논의 주제
+    - 저도 TDD를 예찬하고, 테스트코드를 어떻게 하면 빡빡하게 잘 작성할 수 있을까에 대해서 과거에 집착을 많이 했던 사람의 입장에서 지금 돌이켜 생각해보면, 테스트코드 작성의 너무 좋은 면만 바라본 것은 아닐까 생각됩니다. 분명히 상황에 따라서 내 의도를 정확히 확인해보는 용도로써, 실용적으로 활용했어야 하는 도구였는데, 원론적으로만 바라보고 어떻게 되든 지키려고 했었던 것 같습니다. 돌이켜보면, 잘못된 테스트코드 작성, 의도에 맞지 않는 테스트코드 작성, 불필요한 테스트 코드 작성으로 인해서 병목이되는 부분들이 많았었는데요. 테스트 코드 작성에 대한 단점은 없었는지에 대해서 말해보면 좋을것 같습니다
+- 내 생각
+    - 이전 아카데믹 컨퍼런스에서 틱톡에서는 테스트 코드를 작성하지 않는다고 말씀해주시는 것을 들었던 적이 있었다. 내가 이걸 기억하는 이유는 당시에 나 스스로 테스트 코드는 반드시 작성해야하는 대상으로써, 바라보고 있었기 때문이다. 테스트는 반드시 작성해야한다는 일종의 편견이 있었던 것인데, 그 편견을 깨는 얘기였기 때문이다. 책에 나오는 페이스북의 사례도 비슷한 맥락인데, 테스트를 작성해야할지 말지에 대한 것은 그 회사와 구성원의 철학 혹은 상황에 맞는 적절한 조치, 문화로 보는게 맞지 무조건 정답이 아니라는 뜻이다. 만약에 회사의 철학이 버그가 발생하면 빠르게 고치는 것이라면, 테스트 코드는 오히려 병목이 될 수 있다. 코드 리뷰도 마찬가지인데 무조건 장점만 있는 것은 없다. 어떤 면에서 장점이 있다면, 어떤 면에서는 단점이 있는 것이다. 이를 선택하는 것은 각 구성원들의 선택이다. 선택할 때, 나 그리고 우리팀이 의도하는 바는 무엇인지에 대해서 확실히 정하고 그대로 이행해서 문제가 없으면 된다고 생각한다
+    - 자동화된 테스트가 없이 운영되었기 때문에 수많은 오류와 서버의 다운타임을 겪어야만했다 라고 말하는 내용에 대해서는 그 사람의 경험 하에서는 그렇게 볼 수 있지만, 일반적으로 그렇다고 볼 순 없다고 생각한다. 꼭 자동화된 테스트가 없다는 것 외에도 그 외 다른 요인들도 많기 때문이다. 책에서 말하는 자동화 테스트의 장점은 모두 자동화 테스트를 매우 잘 작성하고, 잘 관리했을 때는 전제로 한다. 만약에 자동화된 테스트 작성 자체부터 제대로 안되었다면? 그렇다면 테스트가 있더라도 수많은 오류와 서버의 다운타임은 겪을 수 있다. 그냥 안된 이유 중하나가 자동화된 테스트가 없었던 것이였는데, 그게 전부라고 생각했던 것은 아닐까? 라는 생각도 든다.
+    - 테스트 코드를 작성할 때 얻는 흔한 장점은 회귀 테스트가 가능하다는 것이고, 리팩토링을 훨씬 더 수월하게 할 수있다는 점이다. 하지만 이 장점들은 모두 테스트 코드를 잘 작성해야하며, 의도에 맞게 작성해야만 회귀테스트도 기대한 대로 할 수 있고, 리팩토링도 가능해진다. 이 사실을 모른채 무작정 테스트 코드를 어떤 형태로도 작성하면 도움이 될 것이다라고 생각한다면, 오히려 이 테스트 코드들 때문에 더 고통 받을 가능성이 크다 예를 들어서, 회귀 테스트의 목적은 새로운 기능을 수정 혹은 추가 했을 때, 이전 기능들이 영향을 받지 않았는지를 확인하기 위한 테스트인데, 애초에 테스트 코드의 커버리지가 내가 인지하는 만큼 채워지지 않았던지 엉뚱한 형태로 작성 되었다면, 내 기대를 충족시킬 수 없다. 리팩토링의 경우에 내가 어떤 테스트를 작성했느냐에 따라 내 리팩토링의 범위가 결정되는데, 단위 테스트 단위로 작성하게 되면, 내 리팩토링의 범위도 단위 테스트의 범위로 줄어들게 된다 이게 내 의도가 맞다면 괜찮지만, 내 리팩토링 의도가 단위 테스트 이상의 통합적으로 비즈니스 로직을 체크해보고 싶은 거였다면, 이 단위 테스트는 아쉽지만 쓸모 없게 된다.
+    - 내 경우 최근에는 테스트 코드를 내 이득을 위해서 작성한다 에 취중 되어있다. 과거의 무작정 테스트 코드 부터 작성하던 습관에서 벗어나서 좀 더 실용적인 관점에서 접근하는 것이다. 내가 생각했을 때, 가장 중요한 것은 현재 내 상황에서, 내가 테스트해야하는 이유는 무엇이고, 자동화된 테스트가 왜 필요한가에 대해서 스스로 답을 할 수 있어야 한다는 것이다. 내가 작업하는 기능이 매우 간단하고, 버그가 좀 나도 핫픽스하면되고, 나혼자 유지보수를 하며, 추후 수정가능성도 높지 않다면 나는 과감하게 테스트 코드를 작성하지 않는 선택을 할 것 같다. 다만, 내가 생각했을 때 어떤 부분이 매우 복잡하고 제대로된 자동화 테스트를 만들지 않으면 테스트하기 매우 곤란한 상황이면서, 나 외 내 동료들도 다같이 꼼꼼하게 봐야하는, 문제가 생기면 큰일 나는 코드라면, 테스트 코드를 오히려 엄청 빡빡하게 모든 경우의수를 꼼꼼이 따져서 작성하지 않을까 생각된다 이렇듯 내 상황과 의도에 따라서 테스트 코드를 작성할 수 있어야 한다고 생각한다

2026/Street_Coder/taehyoung/5.md

@@ -0,0 +1,9 @@
+# 5장
+
+- 논의 주제
+    - 없음
+- 내 생각
+    - 리팩토링에 대해선 크게 할 말이 없다. 코드를 좀 더 구조화해서, 사람이 읽기 좋게, 그리고 유지보수하기 쉬운 형태로 재구성하려는 의도라면 반드시 해야한다
+    - 신뢰 할 수 있는 리팩터링의 비결은 테스트가 아니라, 의도대로 잘 작성된 테스트 이다.
+    - 회사에서 같이 업무하는 입장에서, 리팩토링을 해야하는 이유가 더 우아한 코드를 만들기 위해서라면, 개인적으로 이런 생각을 가진 개발자와는 일하기 쉽지 않을것 같다는 생각이다. 왜 우리가 코드를 작성하고, 리팩토링을 해야하는지, 왜 리팩토링이 필요한지를 다시 한번 생각해봐야한다. 단순히 우아하게 코드를 만드는게 목적이라면 회사가 아닌 개인 프로젝트로 하는게 좋지 않을까 생각된다
+    - 4장에서 얘기한적이 있는 테스트와 더불어서 요즘 들어서 많이 드는 생각은 리팩토링도 그냥 단지 어떤 좋은 것이기 때문에, 현재 나와 회사상황을 고려하기 보다 그 활동자체에 더 힘을 기울이는건 아닐까? 라는 것이다. 어떤 회사에서 이런 리팩토링을 장려하기 위해서, 반드시 본인의 작업 PR을 올리기 전에 리팩토링 커밋을 반드시 올리도록 강제한곳도 있다고 들었는데, 리팩토링을 꼭 해야하는것이고, 좋은 것이다 라는 전제하에 진행되는 것일것 같은데, 뭔가 주객이 전도된 느낌이다.

2026/Street_Coder/taehyoung/6.md

@@ -0,0 +1,9 @@
+# 6장
+
+- 논의 주제
+    - 누구라 보안이 중요하다고 하지만, 생각외로 각 회사마다 사각지대가 있고, 정말 말도 안되게 처리되어있는 경우도 있는 것 같습니다. 보안과 관련된 본인의 인식과 그 인식을 만들어준 사건이 있다면 공유해보면 좋을거 같습니다
+- 내 생각
+    - 보안과 관련된 내 생각은 책에서 정확히 제시를 해주고 있다. 첫째로는 위협모델을 검토하는 것이다. 개발자라면 본인의 설계에서 보안적으로 문제가 될 수있는 부분을 스스로 생각해서 어떤 문제가 발생할 수 있을지 미리 인지하고 대처할 수 있어야한다. 둘째로, 시스템 암호 및 중요한 값들은 별도의 서비스로 관리하는 것이다. 요즘은 이런 SaaS 서비스들 좋은것들이 쓰기 좋게 되어있기 때문에 안쓸 이유가 없다. 특히나 운영환경이라면 적극적으로 활용해야한다 세번째는 최소한의 권한만 주는 것이다. 작은 회사는 예외이겠지만 회사 사이즈가 크면 클 수록 권한의 오남용으로 생길 문제의 영향도가 커진다 불필요한 권한은 절대 부여해선 안된다.
+    - 사실 위 내용에 대해서만 평소에 생각하고 개발하더라도, 사실 개발자가 신경써야할 보안적인 요소는 그렇게 많지는 않다고 생각한다. 책에 나온 XSS 나, SQL 인젝션 경우도 FE 프레임워크가 변변치 않았던 시절이나, ORM을 사용하지 않고, 보안에 취약할수밖에 없었던 시절에는 신경써야할 중요한 보안 위협이였지만, 요즘 세상에서 최신 웹 프레임워크 환경에서 개발하는 과정에서는 사실 위 보안 문제에 대해서는 이미 패치가 되어있는 경우가 대부분이기 때문에, 특히나 내가 보안에 잘 모르고 신경을 덜 쓰고 싶다면, 가능한 많은 사람들이 사용하는 범용적인 웹 프레임워크를 사용하도록 하자ㄹ
+    - 이외에도 보안의 범위는 굉장히 넓어서, 단순히 개발 뿐 아니라, 내부의 문서를 외부에 공개할 때, 어떤 내용을 제거하고 배포할지, 대외비 처리는 어떻게 할지 등등 챙겨야할 부분이 매우 많다. 하지만 업무를 하다보니 이 내용을 다지키려고함에도, 실수하는 경우가 종종 발생하는 것 같은데, 회사의 정책을 잘 확인 후에 행동하는 것이 중요할 것 같다.
+    - 현대의 엔터프라이즈화 되어있는 프레임워크를 씀으로써, 보안적인 위협을 최소화 할 수 있다는 것과 별개로, 책에서 나오는 과거 발생했던 보안사건 사례와 그 보안사건을 막기위해서 발전해온 역사를 배우고, 그 원리를 이해하는 것은 매우 도움이 된다고 생각하고, 이부분도 CS 의 일부로, 성실하고 꾸준히 배워야하는 부분이라고 생각한다