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

[TaeHyoungKwon]

Closes #652

[github-actions]

우측에 있는 Projects, Milestone, Development를 확인 후 할당 해주세요~! 🙇

[gemini-code-assist]

Code Review

This pull request adds personal reflections and summaries for chapters 7, 8, and 9 of the book 'Street Coder', covering topics such as optimization strategies, scalability, locking mechanisms, and error handling. The review feedback focuses on improving the readability and grammatical correctness of the Korean text, providing several suggestions to break down overly long sentences and correct spacing errors.

[gemini-code-assist]

문장이 너무 길어 의미 파악이 어렵고 가독성이 떨어집니다. 적절한 띄어쓰기와 문장 끊기를 통해 의미를 명확하게 전달하는 것이 좋습니다.

Suggested change

	- 요즘 들어서 드는 생각은 회사의 입장에서 무언가 잘되도록 해야한다는 관점에서는 보수적인 관점에서 최적화를 진행하는게 더 낫다고 생각되는데, 반면에 개인의 역량 향상의 관점에서는 최적화를 진행해보는게 나쁘지 않은 경험이라는 생각이 들었다. 다만, 나쁘지 않은 경험인것과는 별개로 회사에서 고용되는 개발자인 이상 개인의 역량 향상이라는 이익을 위해서, 회사의 자원을 직접적으로 이용하는것은 주객이 전도된 행위라고 생각하기 때문에, 회사의 상황에 맞다면, 최적화를 적극적으로 도입해보되, 실질적인 내 역량향상을 위한 것은 개인적으로 진행하는게 더 낫지 않을까 라는 생각이다
	- 요즘 들어서 드는 생각은 회사의 입장에서 무언가 잘되도록 해야 한다는 관점에서는 보수적인 최적화가 더 낫다고 생각되는데, 반면에 개인의 역량 향상 관점에서는 최적화를 진행해 보는 게 나쁘지 않은 경험이라는 생각이 든다. 다만, 개인의 역량 향상을 위해 회사의 자원을 직접적으로 이용하는 것은 주객전도된 행위라고 생각하기 때문에, 회사의 상황에 맞다면 최적화를 적극 도입하되 실질적인 역량 향상을 위한 활동은 개인적으로 진행하는 게 더 낫지 않을까 하는 생각이다

[gemini-code-assist]

'해결하기위해서는'은 '해결하기 위해서는'으로 띄어 쓰는 것이 한국어 맞춤법 규정에 맞습니다.

Suggested change

	- 이후 내용은 흔히 성능과 관련 있는 CPU, 메모리를 기준으로 I/O 의 비동기 처리와 캐시 등에 대해서 설명이 나온다. 결국에 성능과 관련된 문제를 해결하기위해서는 컴퓨터 구조와 알고리즘 단의 기초적인 컴퓨터 공학의 내용을 깊이 있게 이해해야 함을 다시금 확인할 수 있었다
	- 이후 내용은 흔히 성능과 관련 있는 CPU, 메모리를 기준으로 I/O 의 비동기 처리와 캐시 등에 대해서 설명이 나온다. 결국에 성능과 관련된 문제를 해결하기 위해서는 컴퓨터 구조와 알고리즘 단의 기초적인 컴퓨터 공학의 내용을 깊이 있게 이해해야 함을 다시금 확인할 수 있었다

[gemini-code-assist]

문장이 매우 길고 띄어쓰기 오류가 많아 가독성을 해칩니다. 문장을 적절히 나누고 맞춤법을 수정할 것을 권장합니다.

Suggested change

- 확장성이라는 말은 다양하게 사용될 수 있다. 책에서는 성능의 확장이라는 뜻인 거 같긴 하다. 내 개인적인 자주 접한 확장성은 코드와 관련된 부분이다. 코드개발과 관련해서는 비개발자 기준으론 무조건 좋아할 수밖에 없는 마법의 단어 같은 것인데, 오해를 불러일으키기 쉬운 단어라고 생각한다. 아무래도 확장성의 반대가 축소, 제한 이다 보니 여러가지 경우를 고려할 수 있는 확장성이라는 단어가 마법의 단어로 보일 법하다고 생각한다. 내가 생각하는 확장성을 고려해야할 시점은 도메인 적으로 확장할 것을 예상할 수 있을 때 이다. 즉, 내가 만들려는 서비스가 어떤 특정 방향으로 기획이 확장될 것이라는게 예측이 가능할 때, 한정된 부분에 대해서 확장성을 고려해서 설계할 수 있다. 확장성이라는 단어 때문에 모든 것을 커버 할 수 있을것 같은 기대를 가지게 하지만, 사실 개발자 세계에서의 확장성은 좁은 범위의 도메인을 기존 코드에 영향없이 쉽게 추가 가능하다의 의미에 더 가깝다. 명확한 의사소통을 위해서 확장성 이라는 말을 오남용하기 보다는 구체적으로 의도를 표현해주는게 더 낫다고 생각한다

- 확장성이라는 말은 다양하게 사용될 수 있다. 책에서는 성능의 확장을 의미하는 것 같다. 제가 자주 접한 확장성은 코드와 관련된 부분이다. 비개발자 입장에서는 무조건 좋아할 수밖에 없는 마법의 단어 같지만, 오해를 불러일으키기 쉽다. 확장성의 반대가 축소나 제한이다 보니 여러 경우를 고려할 수 있는 확장성이 매력적으로 보일 법하다. 제가 생각하는 확장성 고려 시점은 도메인 확장이 예상될 때이다. 즉, 서비스 기획의 특정 방향성이 예측 가능할 때 한정된 부분에 대해 확장성을 설계할 수 있다. 확장성이 모든 것을 커버할 수 있을 것 같은 기대를 주지만, 실제로는 기존 코드 영향 없이 기능을 추가하는 좁은 의미에 가깝다. 명확한 의사소통을 위해 구체적으로 의도를 표현하는 것이 더 낫다고 생각한다

[gemini-code-assist]

'이부분이', '될것이기', '결정해야한다' 등 의존 명사와 어미의 띄어쓰기를 수정하면 가독성이 좋아집니다.

Suggested change

	- 잠금과 관련해서는 책의 의견에 동의한다. 잠금은 꼭 필요한 순간에만 사용해야하고, 성능적인 부분에서 크리티컬하다면 더욱 잠금을 거는게 나을지에 대해서 다시 한번 생각해보아야한다. 많은 트래픽이 발생하는 경우에 이부분이 병목이 될것이기 때문이다. 그래서 상황에 따라서 성능을 고려해야할지, 정합성을 고려할지를 판단해서 결정해야한다
	- 잠금과 관련해서는 책의 의견에 동의한다. 잠금은 꼭 필요한 순간에만 사용해야하고, 성능적인 부분에서 크리티컬하다면 더욱 잠금을 거는게 나을지에 대해서 다시 한번 생각해보아야한다. 많은 트래픽이 발생하는 경우에 이 부분이 병목이 될 것이기 때문이다. 그래서 상황에 따라서 성능을 고려해야할지, 정합성을 고려할지를 판단해서 결정해야 한다

[gemini-code-assist]

'맞춰야하는지를'은 '맞춰야 하는지를'로 띄어 쓰고, '상관없다 라고'는 '상관없다고'로 수정하는 것이 자연스럽습니다.

Suggested change

	- NOLOCK 과 관련된 얘기의 결론은 트레이드오프의 영향도를 잘 이해하고 있다면, 불일치가 있더라도, 의도적으로 활용할 수 있음을 말한다. 이 말을 다시 생각해보면, 내가 풀려고 하는 문제가 정말로 정합성을 반드시 맞춰야하는지를 고민해보고 그렇지 않다면, 어떤 방법을 사용하더라도 내가 가진 의도대로 처리할 수 있다면 상관없다 라고 볼 수 있다. 다만 여기서 내 개인적인 의견은 코드 혹은 주석, 티켓 등에 의도를 명확히 표현해주면 더 좋다고 생각한다
	- NOLOCK 과 관련된 얘기의 결론은 트레이드오프의 영향도를 잘 이해하고 있다면, 불일치가 있더라도, 의도적으로 활용할 수 있음을 말한다. 이 말을 다시 생각해보면, 내가 풀려고 하는 문제가 정말로 정합성을 반드시 맞춰야 하는지를 고민해보고 그렇지 않다면, 어떤 방법을 사용하더라도 내가 가진 의도대로 처리할 수 있다면 상관없다고 볼 수 있다. 다만 여기서 내 개인적인 의견은 코드 혹은 주석, 티켓 등에 의도를 명확히 표현해주면 더 좋다고 생각한다

[gemini-code-assist]

'수정하려고한다는', '숨기는게', '인지해야하는', '이부분은' 등 띄어쓰기를 수정하여 가독성을 높일 수 있습니다.

Suggested change

	- 개발자들이 오류가 발생하는 것 자체를 싫어해서, 문제가 딱히 없는 오류들도 모두 수정하려고한다는 말은 매우 공감되는 말이다. 예외랑도 이어지는데, 오류 자체를 숨기는게 좋다고 판단하여서 무조건 예외로 감싸는 경우가 있는데, 실제로 문제가 발생해서 빠르게 인지해야하는 문제를 숨겨버리는 치명적인 문제가 있기 때문에 이부분은 매우 중요하다고 생각한다
	- 개발자들이 오류가 발생하는 것 자체를 싫어해서, 문제가 딱히 없는 오류들도 모두 수정하려고 한다는 말은 매우 공감되는 말이다. 예외랑도 이어지는데, 오류 자체를 숨기는 게 좋다고 판단하여 무조건 예외로 감싸는 경우가 있는데, 실제로 문제가 발생해서 빠르게 인지해야 하는 문제를 숨겨버리는 치명적인 문제가 있기 때문에 이 부분은 매우 중요하다고 생각한다

[gemini-code-assist]

의존 명사 '것'은 앞말과 띄어 쓰는 것이 원칙입니다. ('않은것' -> '않은 것')

Suggested change

	- 디버깅 방법론에 대해서 디버거를 쓰든지, 그 외 다른 방법을 쓰든지 방법론 자체는 크게 중요하지 않은것 같고, 아무튼 간에 빠르게 문제 원인을 파악할 수 있는지 여부에 따라서 가장 본인에게 맞고 효율적으로 쓸 수 있는 것을 쓰면 될 것 같다
	- 디버깅 방법론에 대해서 디버거를 쓰든지, 그 외 다른 방법을 쓰든지 방법론 자체는 크게 중요하지 않은 것 같고, 아무튼 간에 빠르게 문제 원인을 파악할 수 있는지 여부에 따라서 가장 본인에게 맞고 효율적으로 쓸 수 있는 것을 쓰면 될 것 같다

[jongfeel]

👍

[ymkim97]

장애 원인을 못 찾는 일은 없도록 포괄적으로(Exception e) 예외 처리하는 것은 피하면서 400, 500 대 에러를 최대한 잘 구분 지으려고 합니다.