From 4d132daa965728c20024501ebd29c8be9fa69959 Mon Sep 17 00:00:00 2001 From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com> Date: Sun, 27 Jul 2025 19:39:00 +0900 Subject: [PATCH 1/8] =?UTF-8?q?Create=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\354\265\234\354\204\234\355\235\254.md" | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 "11\354\236\245/\354\265\234\354\204\234\355\235\254.md" diff --git "a/11\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/11\354\236\245/\354\265\234\354\204\234\355\235\254.md" new file mode 100644 index 0000000..4f812bf --- /dev/null +++ "b/11\354\236\245/\354\265\234\354\204\234\355\235\254.md" @@ -0,0 +1,15 @@ +# 11장. 시스템 + +## 인상 깊은 내용 - 높은 추상화 수준, 즉 시스템 수준에서도 깨끗함을 유지하는 방법 + +* **테스트 주도 시스템 아키택처 구축** + + 코드 수준에서 아키텍처 관심사를 분리할 수 있다면, 진정한 테스트 주도 아키텍처 구축이 가능해진다. 그때그때 새로운 기술을 채택해 단순한 아키텍처를 복잡한 아키텍처로 키워갈 수도 있다. + 물리적 구조는 일단 짓기 시작하면 극적인 변경이 불가능한 탓이다. 소프트웨어 역시 나름대로 형체가 있지만, 소프트웨어 구조가 관점을 효과적으로 분리함다면, 극적인 변화가 경제적으로 가능하다. + 다시 말해, '아주 단순하면서도' 멋지게 분리된 아키텍처로 소프트웨어 프로젝트를 진행해 결과물을 재빨리 출시한 후, 기반 구조를 추가하며 조금씩 확장해 나가도 괜찮다는 말이다. + +* **의사 결정을 최적화하라** + 모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다. + 성급한 결정은 불충분한 지식으로 내린 결정이다. 너무 일찍 결정하면 고객 피드백을 더 모으고, 프로젝트를 더 고민하고, 구현 방안을 더 탐험할 기회가 사라진다. + +* **시스템을 설게하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자** From c0ab6120735da30e85e281e6f72e99732dd3c57e Mon Sep 17 00:00:00 2001 From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com> Date: Sun, 27 Jul 2025 19:54:29 +0900 Subject: [PATCH 2/8] =?UTF-8?q?Create=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\354\265\234\354\204\234\355\235\254.md" | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 "12\354\236\245/\354\265\234\354\204\234\355\235\254.md" diff --git "a/12\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/12\354\236\245/\354\265\234\354\204\234\355\235\254.md" new file mode 100644 index 0000000..611b8e9 --- /dev/null +++ "b/12\354\236\245/\354\265\234\354\204\234\355\235\254.md" @@ -0,0 +1,24 @@ +# 12장. 창발성 + +## 인상 깊은 내용 - 켄트 벡의 단순한 설계 규칙 (중요도 순) + +**1. 모든 테스트를 실행한다** + + 결합도가 높으면 테스트 케이스를 작성하기 어렵다. 개발자는 DIP와 같은 원칙을 적용하고 의존성 주입, 인터페이스, 추상화 등과 같은 도구를 사용해 결합도를 낮춘다. 테스트 케이스를 작성하면 설계 품질이 높아진다. + +**리팩터링 (2~4)** + +**2. 중복을 없앤다.** + 소규모 재사용은 시스템 복잡도를 극적으로 줄여준다. + * TEMPLATE METHOD 패턴은 고차원 중복을 제거할 목적으로 자주 사용하는 기법 + +**3. 프로그래머 의도를 표현한다.** + 개발자가 코드를 명백하게 짤수록 다른 사람이 그 코드를 이해하기 쉬워진다. 그래야 결함이 줄어들고 유지보수 비용이 적게 든다. + * 좋은 이름을 선택한다. + * 함수와 클래스 크기를 가능한 줄인다 + * 표준 명칭을 사용한다. 예를 들어, 디자인 패턴은 의사소통과 표현력 강화가 주요 목적이다. + * 단위 테스트 케이스를 꼼꼼히 작성한다. 잘 만든 테스트 케이스를 읽어보면 클래스 기능이 한눈에 들어온다. + +**주의는 대단한 재능이다!!** + +**4. 클래스와 메서드 수를 최소로 줄인다.** From c4a27f11751f87e6fe2d61d1beeffc5531b920cf Mon Sep 17 00:00:00 2001 From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com> Date: Sun, 27 Jul 2025 20:17:02 +0900 Subject: [PATCH 3/8] =?UTF-8?q?Create=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- "\354\265\234\354\204\234\355\235\254.md" | 47 +++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 "\354\265\234\354\204\234\355\235\254.md" diff --git "a/\354\265\234\354\204\234\355\235\254.md" "b/\354\265\234\354\204\234\355\235\254.md" new file mode 100644 index 0000000..9b9b4a9 --- /dev/null +++ "b/\354\265\234\354\204\234\355\235\254.md" @@ -0,0 +1,47 @@ +# 13장. 동시성 + +## 인상 깊은 내용 + +**동시성이 필요한 이유?** + + 동시성은 겨합을 없애는 전략이다. 즉 무엇과 언제를 분리하는 전략이다. + 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 그래서 호출 스택을 살펴보면 프로그램 상태가 곧바로 드러난다. + +**동시성과 관련한 일반적인 미신과 오해** + + * **동시성은 항상 성능을 높여준다.** + 동시성은 때로 성능을 높여준다. 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다. + + * **동서성을 구현해도 설게는 변하지 않는다.** + 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다. + + * **웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다.** + 실제로는 컨테이너가 어떻게 동작하는지, 어떻게 동시 수정, 데드락 등과 같은 문제를 피할 수 있는지를 알아야만 한다. + +**동시성과 관련된 타당한 몇 가지** + + * **동시성은 다소 부하를 유발한다.* + 동시성은 때로 성능을 높여준다. 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다. + + * **동시성은 복잡하다.** + 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다. + + * **동시성 버그는 재현하기 어렵다.** + 진짜 결함으로 간주되지 않고 일회성 문제로 여겨 무시하기 쉽다. + + * **동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다.** + +**동시성 방어 원칙** + * **단일 책임 원칙** + 동시성 코드는 다른 코드와 분리하라 + * **따름 정리: 자료 범위를 제한하라** + 자료를 캡슐화하라, 공유 자료를 최대한 줄여라 + * **따름 정리: 자료 사본을 사용하라** + * **따름 정리: 스레드는 가능한 독립적으로 구현하라** + 독자적인 스레드로, 가능하면 다른 프로세서에서, 돌려도 괜찮도록 자료를 독립적인 단위로 분할하라. + * **라이브러리를 이해하라** + * **실행 모델을 이해하라** + * **동기화하는 메서드 사이에서 존재하는 의존성을 이해하라** + * **동기화하는 부분을 작게 만들어라** + * **올바를 종료 코드는 구현하기 어렵다** + * **스레드 코드 테스트하기** From aa2312d50464fae590c231aa9ec8632a7f6ede70 Mon Sep 17 00:00:00 2001 From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com> Date: Sun, 27 Jul 2025 20:22:03 +0900 Subject: [PATCH 4/8] =?UTF-8?q?Update=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\354\265\234\354\204\234\355\235\254.md" | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git "a/11\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/11\354\236\245/\354\265\234\354\204\234\355\235\254.md" index 4f812bf..3864fb6 100644 --- "a/11\354\236\245/\354\265\234\354\204\234\355\235\254.md" +++ "b/11\354\236\245/\354\265\234\354\204\234\355\235\254.md" @@ -13,3 +13,13 @@ 성급한 결정은 불충분한 지식으로 내린 결정이다. 너무 일찍 결정하면 고객 피드백을 더 모으고, 프로젝트를 더 고민하고, 구현 방안을 더 탐험할 기회가 사라진다. * **시스템을 설게하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자** + +--- + +## 느낀점 + +과거 한 프로젝트에서 기술 스택을 선택하면서 성급한 결정을 내린 적이 있다. 당시에는 장점만을 빠르게 분석한 뒤, 전체적인 리스크나 다른 대안들을 충분히 고려하지 않은 채 선택을 확정지었다. 그 결과, 해당 기술이 프로젝트에 적합하지 않다는 사실을 뒤늦게 깨닫게 되었고, 더 나은 구현 방안을 모색할 기회를 놓친 적이 있다. + +이 경험을 통해 기술 선택 이전의 사전 의사결정 과정이 코딩만큼이나 중요하다는 점을 깨달은 바 있다. 단순히 구현 가능한 수준을 넘어서, 여러 가능성과 리스크를 체계적으로 검토하고 비교하는 것이 얼마나 중요한지를 뼈저리게 배운 경험이다. + +앞으로는 기술 선택 전, 다양한 대안을 탐색하고 의사결정 구조를 명확히 세운 뒤 진행할 계획이다. 충분한 고민과 탐색이 더 나은 결과를 만든다는 교훈을 실천에 옮기고자 한다. From a1183e1b710e5fbe4dec76ae259470768f1a071c Mon Sep 17 00:00:00 2001 From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com> Date: Sun, 27 Jul 2025 20:24:54 +0900 Subject: [PATCH 5/8] =?UTF-8?q?Update=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- "12\354\236\245/\354\265\234\354\204\234\355\235\254.md" | 6 ++++++ 1 file changed, 6 insertions(+) diff --git "a/12\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/12\354\236\245/\354\265\234\354\204\234\355\235\254.md" index 611b8e9..030fac8 100644 --- "a/12\354\236\245/\354\265\234\354\204\234\355\235\254.md" +++ "b/12\354\236\245/\354\265\234\354\204\234\355\235\254.md" @@ -22,3 +22,9 @@ **주의는 대단한 재능이다!!** **4. 클래스와 메서드 수를 최소로 줄인다.** + +--- + +## 느낀점 + +4가지의 단순한 설계 규칙은 앞으로 평생 기억해야 할 원칙이라고 생각해왔던 것들이라, 깊이 공감하며 읽었다. From 455a738bb687f5c22b1a167d6afa5f913bd4f0db Mon Sep 17 00:00:00 2001 From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com> Date: Sun, 27 Jul 2025 20:25:52 +0900 Subject: [PATCH 6/8] =?UTF-8?q?Update=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- "12\354\236\245/\354\265\234\354\204\234\355\235\254.md" | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git "a/12\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/12\354\236\245/\354\265\234\354\204\234\355\235\254.md" index 030fac8..8d3b197 100644 --- "a/12\354\236\245/\354\265\234\354\204\234\355\235\254.md" +++ "b/12\354\236\245/\354\265\234\354\204\234\355\235\254.md" @@ -27,4 +27,6 @@ ## 느낀점 -4가지의 단순한 설계 규칙은 앞으로 평생 기억해야 할 원칙이라고 생각해왔던 것들이라, 깊이 공감하며 읽었다. +4가지의 단순한 설계 규칙은 앞으로 평생 기억해야 할 원칙이라고 생각해왔던 내용들이라, 깊이 공감하며 읽었다. 특히 이러한 규칙들이 모두 개인의 꾸준한 노력과 주의에서 비롯된다는 점에서, “노력은 배신하지 않는다”는 말이 자연스럽게 떠올랐다. + + From c2209b64a8ba6717e7e59124b75f3454c6d8139c Mon Sep 17 00:00:00 2001 From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com> Date: Sun, 27 Jul 2025 20:29:12 +0900 Subject: [PATCH 7/8] =?UTF-8?q?Delete=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- "\354\265\234\354\204\234\355\235\254.md" | 47 ----------------------- 1 file changed, 47 deletions(-) delete mode 100644 "\354\265\234\354\204\234\355\235\254.md" diff --git "a/\354\265\234\354\204\234\355\235\254.md" "b/\354\265\234\354\204\234\355\235\254.md" deleted file mode 100644 index 9b9b4a9..0000000 --- "a/\354\265\234\354\204\234\355\235\254.md" +++ /dev/null @@ -1,47 +0,0 @@ -# 13장. 동시성 - -## 인상 깊은 내용 - -**동시성이 필요한 이유?** - - 동시성은 겨합을 없애는 전략이다. 즉 무엇과 언제를 분리하는 전략이다. - 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 그래서 호출 스택을 살펴보면 프로그램 상태가 곧바로 드러난다. - -**동시성과 관련한 일반적인 미신과 오해** - - * **동시성은 항상 성능을 높여준다.** - 동시성은 때로 성능을 높여준다. 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다. - - * **동서성을 구현해도 설게는 변하지 않는다.** - 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다. - - * **웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다.** - 실제로는 컨테이너가 어떻게 동작하는지, 어떻게 동시 수정, 데드락 등과 같은 문제를 피할 수 있는지를 알아야만 한다. - -**동시성과 관련된 타당한 몇 가지** - - * **동시성은 다소 부하를 유발한다.* - 동시성은 때로 성능을 높여준다. 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다. - - * **동시성은 복잡하다.** - 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다. - - * **동시성 버그는 재현하기 어렵다.** - 진짜 결함으로 간주되지 않고 일회성 문제로 여겨 무시하기 쉽다. - - * **동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다.** - -**동시성 방어 원칙** - * **단일 책임 원칙** - 동시성 코드는 다른 코드와 분리하라 - * **따름 정리: 자료 범위를 제한하라** - 자료를 캡슐화하라, 공유 자료를 최대한 줄여라 - * **따름 정리: 자료 사본을 사용하라** - * **따름 정리: 스레드는 가능한 독립적으로 구현하라** - 독자적인 스레드로, 가능하면 다른 프로세서에서, 돌려도 괜찮도록 자료를 독립적인 단위로 분할하라. - * **라이브러리를 이해하라** - * **실행 모델을 이해하라** - * **동기화하는 메서드 사이에서 존재하는 의존성을 이해하라** - * **동기화하는 부분을 작게 만들어라** - * **올바를 종료 코드는 구현하기 어렵다** - * **스레드 코드 테스트하기** From 142c64f54632c94300c5022283a8f179fb7ab184 Mon Sep 17 00:00:00 2001 From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com> Date: Sun, 27 Jul 2025 20:34:00 +0900 Subject: [PATCH 8/8] =?UTF-8?q?Create=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\354\265\234\354\204\234\355\235\254.md" | 55 +++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 "13\354\236\245/\354\265\234\354\204\234\355\235\254.md" diff --git "a/13\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/13\354\236\245/\354\265\234\354\204\234\355\235\254.md" new file mode 100644 index 0000000..6bd7800 --- /dev/null +++ "b/13\354\236\245/\354\265\234\354\204\234\355\235\254.md" @@ -0,0 +1,55 @@ +# 13장. 동시성 + +## 인상 깊은 내용 + +**동시성이 필요한 이유?** + + 동시성은 겨합을 없애는 전략이다. 즉 무엇과 언제를 분리하는 전략이다. + 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 그래서 호출 스택을 살펴보면 프로그램 상태가 곧바로 드러난다. + +**동시성과 관련한 일반적인 미신과 오해** + + * **동시성은 항상 성능을 높여준다.** + 동시성은 때로 성능을 높여준다. 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다. + + * **동서성을 구현해도 설게는 변하지 않는다.** + 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다. + + * **웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다.** + 실제로는 컨테이너가 어떻게 동작하는지, 어떻게 동시 수정, 데드락 등과 같은 문제를 피할 수 있는지를 알아야만 한다. + +**동시성과 관련된 타당한 몇 가지** + + * **동시성은 다소 부하를 유발한다.* + 동시성은 때로 성능을 높여준다. 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다. + + * **동시성은 복잡하다.** + 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다. + + * **동시성 버그는 재현하기 어렵다.** + 진짜 결함으로 간주되지 않고 일회성 문제로 여겨 무시하기 쉽다. + + * **동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다.** + +**동시성 방어 원칙** + + * **단일 책임 원칙** + 동시성 코드는 다른 코드와 분리하라 + * **따름 정리: 자료 범위를 제한하라** + 자료를 캡슐화하라, 공유 자료를 최대한 줄여라 + * **따름 정리: 자료 사본을 사용하라** + * **따름 정리: 스레드는 가능한 독립적으로 구현하라** + 독자적인 스레드로, 가능하면 다른 프로세서에서, 돌려도 괜찮도록 자료를 독립적인 단위로 분할하라. + * **라이브러리를 이해하라** + * **실행 모델을 이해하라** + * **동기화하는 메서드 사이에서 존재하는 의존성을 이해하라** + * **동기화하는 부분을 작게 만들어라** + * **올바를 종료 코드는 구현하기 어렵다** + * **스레드 코드 테스트하기** + +--- + +## 느낀점 + +처음엔 프론트엔드와 동시성이 어떻게 연결되는지 명확하지 않아 와닿지 않았지만, 관련성을 찾으려 노력하며 읽었다. 직접적으로 적용할 부분은 많지 않았지만, 그래도 시스템의 복잡성과 설계에 대한 이해를 넓히는 데 도움이 된 것 같다. +