From f85f04f48a0bf7868cd6843d37524b1a171be8fb Mon Sep 17 00:00:00 2001 From: ymkim97 Date: Thu, 30 Apr 2026 21:07:48 +0900 Subject: [PATCH 1/4] chapter 7,8,9 --- 2026/Street_Coder/ymkim97/chapter7_8_9.md | 39 +++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 2026/Street_Coder/ymkim97/chapter7_8_9.md diff --git a/2026/Street_Coder/ymkim97/chapter7_8_9.md b/2026/Street_Coder/ymkim97/chapter7_8_9.md new file mode 100644 index 00000000..741d3581 --- /dev/null +++ b/2026/Street_Coder/ymkim97/chapter7_8_9.md @@ -0,0 +1,39 @@ +# 스트리트 코더 +## 7장 ~ 9장 +--- +## 논의 내용 +* 최근에 어떠한 형태로든 최적화를 진행했던 경험에 대해서 얘기해보면 좋을 것 같습니다. + * p95가 1초대로 꽤 길게 잡히던 API가 있었는데요, Flame graph를 이용해서 시간이 오래 걸리는 지점을 찾아 100~200ms대로 최적화를 했었습니다. DB 쿼리 후 좀 길게 그래프가 구멍이 생겼었는데, 분석해보니 가져오는 row가 너무 많아(몇만 개, ORM 사용중) 조건을 넣어 대상 데이터를 좁히면서 해결되었습니다. + +## Chapter 7 - 자기 주장이 뚜렷한 최적화 +현재 앱이 사용자와 컴퓨터간의 인터랙션 시 가장 적절한 응답 시간을 지칭하는 도허티의 임계를 심각하게 넘는 등의 문제로 최적화하는 것은 필수지만, 섣부른 최적화는 모든 악의 근원이라고 할 정도로 조심하라고 한다. +그 이유는 최적화는 코드에 경직성을 가져와 유지 관리를 더 어렵게 만들 수 있기 때문이다. +이를 피하기 위해서는 해결해야 할 문제가 무엇인지를 올바르게 파악하는 것이 중요하다고 한다. + +회사마다 특정 기간을 잡고 OKR을 설정하여 달성하는 방식이 있을텐데, 이런 목표를 달성하기 위해 최적화가 들어가는 것은 드문 것 같다. +특히 스타트업일수록 새로운 기능들을 만들어내며 끊임없이 새로운 가치를 창출해내느라 바쁘기 때문이라고 생각한다. +시간이라는 유한한 자원 속에서 최적화라는 것은 더더욱 명확한 문제 정의와 해결책이 있어야 진행 가능할 것이다. +이에 따라 저자가 말하는 섣부른 최적화의 위험은 꽤 공감된다. + +이후 책에서는 근본적인 원인을 식별하기 위해 이분법적인 하향식 접근으로 진단하는 것을 시작으로, I/O, 캐시 등 일반적인 엔지니어링 기법들이 소개된다. +특히 스레드 관련은 요즘에도 꽤 많이 사용되기 때문에(코루틴, 가상 스레드 등) 재미있게 읽었다. + +## Chapter 8 - 기분 좋은 확장성 +이번 장에서 말하는 확장성은 OOP의 추상화, 캡슐화 등을 이용한 것이 아니라, 잠금으로 인한 확장성이다. +즉 확장성을 방해하는 잘못된 코드를 제거하는 것이고, 특히 잠금이 성능적으로 이에 포함될 수 있다는 것이다. +멀티 스레딩은 당연한 요즘에는 잠금이 아예 없을 수는 없지만 잠금이 아닌 다른 방법들로도 항상은 아니지만 해결할 수도 있다. +잠금이라는 것은 결국 성능에 크게 영향을 미칠 수 밖에 없기 때문에 꼭 필요한 곳에서만 써야한다는 것에 동의한다. +나는 예전에는 정합성이라는 것을 반드시, 절대적으로 모든 곳에서 지켜야하는 줄 알았다. +그러나 트레이드오프의 영향을 제대로 이해하고, 의도가 명확하다면 불일치를 두려워 할 필요 없이 다른 방법을 이용해도 좋다는 것을 배웠다. + +이후에는 DB 커넥션을 최대한 한 요청에서 짧게 가져야하며, 동시에 커넥션을 필요 이상을 가져오지 않도록 해야한다고 말한다. + +## Chapter 9 - 버그와의 동거 +세상에는 완벽한 프로그램은 없기 때문에 어디에는 버그가 존재한다. +그 이유는 프로그램의 본질적인 예측 불가능성 때문에 소프트웨어 개발이 복잡하기 때문이다. +그렇다면, 버그가 없는 프로그램을 만들기란 불가능하다는 것을 받아들이고, 발견되는 수 많은 버그들 중에서 어떤 것을 수정할지 순서를 잘 결정해야한다. + +책에서는 우선순위와 심각성 두 개를 지표로 두고, 어떤 것을 즉시 고치고, 인턴에게 수정을 지시할지 표를 보여준다. +모든 버그를 다 찾아서 없애면 정말 좋겠지만, 결국 버그를 추적하는 것도 모두 비용이 발생하기 때문이다. +순위가 아래로 내려가면서 고치지 않게 되는 버그들이 생기는데, 흔히 이것들이 지라의 백로그로 가는 것 같다. + From e98e646e3cdd58e0bba9589e0ddb338d90881e61 Mon Sep 17 00:00:00 2001 From: Youngmyung Kim Date: Fri, 1 May 2026 15:11:42 +0900 Subject: [PATCH 2/4] Update 2026/Street_Coder/ymkim97/chapter7_8_9.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- 2026/Street_Coder/ymkim97/chapter7_8_9.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Street_Coder/ymkim97/chapter7_8_9.md b/2026/Street_Coder/ymkim97/chapter7_8_9.md index 741d3581..dc27c304 100644 --- a/2026/Street_Coder/ymkim97/chapter7_8_9.md +++ b/2026/Street_Coder/ymkim97/chapter7_8_9.md @@ -35,5 +35,5 @@ 책에서는 우선순위와 심각성 두 개를 지표로 두고, 어떤 것을 즉시 고치고, 인턴에게 수정을 지시할지 표를 보여준다. 모든 버그를 다 찾아서 없애면 정말 좋겠지만, 결국 버그를 추적하는 것도 모두 비용이 발생하기 때문이다. -순위가 아래로 내려가면서 고치지 않게 되는 버그들이 생기는데, 흔히 이것들이 지라의 백로그로 가는 것 같다. +순위가 아래로 내려가면서 고치지 않게 되는 버그들이 생기는데, 흔히 이것들이 Jira의 백로그로 가는 것 같다. From bc57a4347afeb91d46d6f7d0ae64d10574bc97c9 Mon Sep 17 00:00:00 2001 From: Youngmyung Kim Date: Fri, 1 May 2026 15:11:49 +0900 Subject: [PATCH 3/4] Update 2026/Street_Coder/ymkim97/chapter7_8_9.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- 2026/Street_Coder/ymkim97/chapter7_8_9.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Street_Coder/ymkim97/chapter7_8_9.md b/2026/Street_Coder/ymkim97/chapter7_8_9.md index dc27c304..663592e6 100644 --- a/2026/Street_Coder/ymkim97/chapter7_8_9.md +++ b/2026/Street_Coder/ymkim97/chapter7_8_9.md @@ -6,7 +6,7 @@ * p95가 1초대로 꽤 길게 잡히던 API가 있었는데요, Flame graph를 이용해서 시간이 오래 걸리는 지점을 찾아 100~200ms대로 최적화를 했었습니다. DB 쿼리 후 좀 길게 그래프가 구멍이 생겼었는데, 분석해보니 가져오는 row가 너무 많아(몇만 개, ORM 사용중) 조건을 넣어 대상 데이터를 좁히면서 해결되었습니다. ## Chapter 7 - 자기 주장이 뚜렷한 최적화 -현재 앱이 사용자와 컴퓨터간의 인터랙션 시 가장 적절한 응답 시간을 지칭하는 도허티의 임계를 심각하게 넘는 등의 문제로 최적화하는 것은 필수지만, 섣부른 최적화는 모든 악의 근원이라고 할 정도로 조심하라고 한다. +현재 앱이 사용자와 컴퓨터간의 인터랙션 시 가장 적절한 응답 시간을 지칭하는 도허티 임계(Doherty Threshold)를 심각하게 넘는 등의 문제로 최적화하는 것은 필수지만, 섣부른 최적화는 모든 악의 근원이라고 할 정도로 조심하라고 한다. 그 이유는 최적화는 코드에 경직성을 가져와 유지 관리를 더 어렵게 만들 수 있기 때문이다. 이를 피하기 위해서는 해결해야 할 문제가 무엇인지를 올바르게 파악하는 것이 중요하다고 한다. From 7145113897210dd9668731e79139f991923ae212 Mon Sep 17 00:00:00 2001 From: Youngmyung Kim Date: Fri, 1 May 2026 15:12:01 +0900 Subject: [PATCH 4/4] Update 2026/Street_Coder/ymkim97/chapter7_8_9.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- 2026/Street_Coder/ymkim97/chapter7_8_9.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Street_Coder/ymkim97/chapter7_8_9.md b/2026/Street_Coder/ymkim97/chapter7_8_9.md index 663592e6..e8963655 100644 --- a/2026/Street_Coder/ymkim97/chapter7_8_9.md +++ b/2026/Street_Coder/ymkim97/chapter7_8_9.md @@ -20,7 +20,7 @@ ## Chapter 8 - 기분 좋은 확장성 이번 장에서 말하는 확장성은 OOP의 추상화, 캡슐화 등을 이용한 것이 아니라, 잠금으로 인한 확장성이다. -즉 확장성을 방해하는 잘못된 코드를 제거하는 것이고, 특히 잠금이 성능적으로 이에 포함될 수 있다는 것이다. +즉 확장성을 방해하는 잘못된 코드를 제거하는 것이고, 특히 잠금이 성능과 확장성을 저해하는 주요 요인이 될 수 있다는 것이다. 멀티 스레딩은 당연한 요즘에는 잠금이 아예 없을 수는 없지만 잠금이 아닌 다른 방법들로도 항상은 아니지만 해결할 수도 있다. 잠금이라는 것은 결국 성능에 크게 영향을 미칠 수 밖에 없기 때문에 꼭 필요한 곳에서만 써야한다는 것에 동의한다. 나는 예전에는 정합성이라는 것을 반드시, 절대적으로 모든 곳에서 지켜야하는 줄 알았다.