diff --git a/2026/Street_Coder/taehyoung/7.md b/2026/Street_Coder/taehyoung/7.md new file mode 100644 index 00000000..4dfde7b5 --- /dev/null +++ b/2026/Street_Coder/taehyoung/7.md @@ -0,0 +1,8 @@ +# 7장 + +- 논의 주제 + - 없음 +- 내 생각 + - 요즘 들어서 드는 생각은 회사의 입장에서 무언가 잘되도록 해야한다는 관점에서는 보수적인 관점에서 최적화를 진행하는게 더 낫다고 생각되는데, 반면에 개인의 역량 향상의 관점에서는 최적화를 진행해보는게 나쁘지 않은 경험이라는 생각이 들었다. 다만, 나쁘지 않은 경험인것과는 별개로 회사에서 고용되는 개발자인 이상 개인의 역량 향상이라는 이익을 위해서, 회사의 자원을 직접적으로 이용하는것은 주객이 전도된 행위라고 생각하기 때문에, 회사의 상황에 맞다면, 최적화를 적극적으로 도입해보되, 실질적인 내 역량향상을 위한 것은 개인적으로 진행하는게 더 낫지 않을까 라는 생각이다 + - 필요 없는 코드는 꼭 컴파일 작업에 불필요하기 때문에 없애야한다는 측면 말고도, 코드를 읽고 도메인 파악을 하는 목적에서도 애매하게 있는 것 보다도 그냥 없는게 인지적으로도 훨씬 좋다고 생각한다 + - 이후 내용은 흔히 성능과 관련 있는 CPU, 메모리를 기준으로 I/O 의 비동기 처리와 캐시 등에 대해서 설명이 나온다. 결국에 성능과 관련된 문제를 해결하기위해서는 컴퓨터 구조와 알고리즘 단의 기초적인 컴퓨터 공학의 내용을 깊이 있게 이해해야 함을 다시금 확인할 수 있었다 diff --git a/2026/Street_Coder/taehyoung/8.md b/2026/Street_Coder/taehyoung/8.md new file mode 100644 index 00000000..3a92ec2e --- /dev/null +++ b/2026/Street_Coder/taehyoung/8.md @@ -0,0 +1,8 @@ +# 8장 + +- 논의 주제 + - 없음 +- 내 생각 + - 확장성이라는 말은 다양하게 사용될 수 있다. 책에서는 성능의 확장이라는 뜻인 거 같긴 하다. 내 개인적인 자주 접한 확장성은 코드와 관련된 부분이다. 코드개발과 관련해서는 비개발자 기준으론 무조건 좋아할 수밖에 없는 마법의 단어 같은 것인데, 오해를 불러일으키기 쉬운 단어라고 생각한다. 아무래도 확장성의 반대가 축소, 제한 이다 보니 여러가지 경우를 고려할 수 있는 확장성이라는 단어가 마법의 단어로 보일 법하다고 생각한다. 내가 생각하는 확장성을 고려해야할 시점은 도메인 적으로 확장할 것을 예상할 수 있을 때 이다. 즉, 내가 만들려는 서비스가 어떤 특정 방향으로 기획이 확장될 것이라는게 예측이 가능할 때, 한정된 부분에 대해서 확장성을 고려해서 설계할 수 있다. 확장성이라는 단어 때문에 모든 것을 커버 할 수 있을것 같은 기대를 가지게 하지만, 사실 개발자 세계에서의 확장성은 좁은 범위의 도메인을 기존 코드에 영향없이 쉽게 추가 가능하다의 의미에 더 가깝다. 명확한 의사소통을 위해서 확장성 이라는 말을 오남용하기 보다는 구체적으로 의도를 표현해주는게 더 낫다고 생각한다 + - 잠금과 관련해서는 책의 의견에 동의한다. 잠금은 꼭 필요한 순간에만 사용해야하고, 성능적인 부분에서 크리티컬하다면 더욱 잠금을 거는게 나을지에 대해서 다시 한번 생각해보아야한다. 많은 트래픽이 발생하는 경우에 이부분이 병목이 될것이기 때문이다. 그래서 상황에 따라서 성능을 고려해야할지, 정합성을 고려할지를 판단해서 결정해야한다 + - NOLOCK 과 관련된 얘기의 결론은 트레이드오프의 영향도를 잘 이해하고 있다면, 불일치가 있더라도, 의도적으로 활용할 수 있음을 말한다. 이 말을 다시 생각해보면, 내가 풀려고 하는 문제가 정말로 정합성을 반드시 맞춰야하는지를 고민해보고 그렇지 않다면, 어떤 방법을 사용하더라도 내가 가진 의도대로 처리할 수 있다면 상관없다 라고 볼 수 있다. 다만 여기서 내 개인적인 의견은 코드 혹은 주석, 티켓 등에 의도를 명확히 표현해주면 더 좋다고 생각한다 diff --git a/2026/Street_Coder/taehyoung/9.md b/2026/Street_Coder/taehyoung/9.md new file mode 100644 index 00000000..a350b785 --- /dev/null +++ b/2026/Street_Coder/taehyoung/9.md @@ -0,0 +1,8 @@ +# 9장 + +- 논의 주제 + - 각 사람의 취향과 경험에 따라서, 평소에 예외 설계를 어떤 식으로 하는지 얘기해보면 좋을 것 같습니다 +- 내 생각 + - 고쳐야할 버그의 우선순위를 정하는 작업은 너무나 당연하다고 생각하고, 특히나 심각성을 제일 우선기준으로 가져가는것은 피해를 최소화해야한다는 관점에서 특히나 당연하다고 생각한다 + - 개발자들이 오류가 발생하는 것 자체를 싫어해서, 문제가 딱히 없는 오류들도 모두 수정하려고한다는 말은 매우 공감되는 말이다. 예외랑도 이어지는데, 오류 자체를 숨기는게 좋다고 판단하여서 무조건 예외로 감싸는 경우가 있는데, 실제로 문제가 발생해서 빠르게 인지해야하는 문제를 숨겨버리는 치명적인 문제가 있기 때문에 이부분은 매우 중요하다고 생각한다 + - 디버깅 방법론에 대해서 디버거를 쓰든지, 그 외 다른 방법을 쓰든지 방법론 자체는 크게 중요하지 않은것 같고, 아무튼 간에 빠르게 문제 원인을 파악할 수 있는지 여부에 따라서 가장 본인에게 맞고 효율적으로 쓸 수 있는 것을 쓰면 될 것 같다