From f46d685e0f2ec9a5043ce59c6f9e52d5b0b15038 Mon Sep 17 00:00:00 2001 From: jongfeel Date: Thu, 19 Mar 2026 00:35:17 +0900 Subject: [PATCH 1/7] Add chapter 13 review --- .../jongfeel/Chapter13_Contracts.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter13_Contracts.md diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter13_Contracts.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter13_Contracts.md new file mode 100644 index 00000000..805c6d2c --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter13_Contracts.md @@ -0,0 +1,13 @@ +## Summary + +- https://github.com/jongfeel/BookReview/issues/1641 + +## Review + +- https://github.com/jongfeel/BookReview/issues/1641#issuecomment-4082337757 + +### 후기 + +느슨한 계약이라는게 필요할까? 라는 의문이 들었는데 원래 계약대로 한다고 해도 드러나는 단점은 어쩔 수 없는 처리를 단점으로 드러내는 것 정도라고 보여지기 때문이다. + +컨슈머 주도 계약이라는 것도 중간에 큐나 토픽에 담는걸 생략하다 보니 서비스들 끼리 커플링이 일어나는 걸 언급하는데 함께 설명해 줬다면 좋았을 것 같다. \ No newline at end of file From 7e0fb0ba52334929ac2b44925d2f383afee6ce88 Mon Sep 17 00:00:00 2001 From: jongfeel Date: Thu, 19 Mar 2026 00:35:33 +0900 Subject: [PATCH 2/7] Add chapter 14 review --- .../Chapter14_Managing_Analytical_Data.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter14_Managing_Analytical_Data.md diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter14_Managing_Analytical_Data.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter14_Managing_Analytical_Data.md new file mode 100644 index 00000000..7457e244 --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter14_Managing_Analytical_Data.md @@ -0,0 +1,15 @@ +## Summary + +- https://github.com/jongfeel/BookReview/issues/1643 + +## Review + +- https://github.com/jongfeel/BookReview/issues/1643#issuecomment-4082269164 + +## 후기 및 DPQ + +대용량 운영 데이터 분석의 역사와 함께 현재 분산 환경에서는 어떻게 하는게 좋은지에 대한 내용까지 있다. +사실 14.2 부터는 모르는 내용이고, 용어도 어렵게 느껴지는 것들이 많아서 전체적으로 어려운 챕터에 속한 것 같다. + +DPQ도 느낌은 별도의 운영 데이터를 분석하는 하나의 서비스 처럼 느껴진다. +DPQ 내에도 도메인 로직이 있고 DB도 있으니까 비즈니스 로직의 흐름과 별도의 서비스로 처리를 하고 분석 전용 데이터를 모으는 별도의 서비스로 구성하려는 것으로 이해가 된다. \ No newline at end of file From 5d1a174f3a9ae3aeae0b33a9aaf1341cb11021fe Mon Sep 17 00:00:00 2001 From: jongfeel Date: Thu, 19 Mar 2026 00:35:49 +0900 Subject: [PATCH 3/7] Add chapter 15 review and discussions --- ...ter15_Build_Your_Own_Trade-Off_Analysis.md | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md new file mode 100644 index 00000000..7548c7cb --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md @@ -0,0 +1,24 @@ +## Summary + +- https://github.com/jongfeel/BookReview/issues/1646 + +## Review + +- https://github.com/jongfeel/BookReview/issues/1646#issuecomment-4083228614 + +## 후기 + +아키텍트가 된다는 건 우선 소프트웨어 아키텍처가 무엇인지 그리고 상황에 따른 트레이드오프가 무엇인지 파악하고 결정해야 하는 위치라는 걸 다시 이해하게 되었다. + +나는 AI로 딸깍해서 개발이 다 되는 시대에도 소프트웨어 아키텍처는 중요한 고려사항 중의 하나로 여기고 싶다. +분산 트랜잭션으로 만들어줘, 느린 걸 빠르게 개선해줘와 같은 프롬프트는 계속 지시하는 게 잘못된 것이라는 건 금방 알 수 있다. +바이브 코딩은 내가 원하는 기능을 구현하는 건 문제 없이 할 수 있다. +기능 구현의 문제를 넘어 아키텍처 결정은 필요에 의해서, 그러니까 상황에 따른 판단과 그 결정을 내리는 것인데 그건 해달라고 해서 할 수 있는 영역이 아니다. +물론 아는 사람은 그렇게 지시하겠지만, 일반 바이브 코딩의 한계는 이 시점에서 소프트웨어의 품질 외에 아키텍처 적인 문제 해결의 방법으로 갈라질 것이다. + +## 논의 주제 + +개발자가 직접 코딩하지 않아도 되는 AI 바이브 코딩이 가능한 시기에도 소프트웨어 아키텍처는 필요한가? 에 대한 의문입니다. + +=> 초기 PoC/프로토타입은 아키텍처가 없어도 되거나 AI가 제시해주는 모놀리스 기반의 통합 백엔드 프론트로 해도 문제는 없을 거라 생각합니다. +이제 바이브 코딩을 하는 사용자가 얼마나 소프트웨어 관련 지식을 학습하고 프롬프트로 지시해서 더 잘 만들려고 하는 의지를 가지고 있느냐 없느냐의 차이가 가른다고 봅니다. 여기서 개발자가 살아남아야 하는 이유를 설명할 수 있는데, 코딩 하는 사람이 아닌 서비스를 기획하고 동작하는 소프트웨어로 만들 수 있는 사람을 넘어서 소프트웨어/컴퓨터 공학 지식을 가지고 더 상황에 맞고 아키텍처 특성을 가진 소프트웨어를 만드는 능력을 가지는게 경쟁력이 아닐까 생각합니다. \ No newline at end of file From 8872163dd1cf532e3c1be62247ce59842bd6c28a Mon Sep 17 00:00:00 2001 From: Kim Jong Feel Date: Fri, 20 Mar 2026 12:37:41 +0900 Subject: [PATCH 4/7] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter13_Contracts.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../jongfeel/Chapter13_Contracts.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter13_Contracts.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter13_Contracts.md index 805c6d2c..e54a0618 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter13_Contracts.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter13_Contracts.md @@ -8,6 +8,6 @@ ### 후기 -느슨한 계약이라는게 필요할까? 라는 의문이 들었는데 원래 계약대로 한다고 해도 드러나는 단점은 어쩔 수 없는 처리를 단점으로 드러내는 것 정도라고 보여지기 때문이다. +느슨한 계약의 필요성에 의문이 들었습니다. 엄격한 계약을 따르더라도, 예외적인 상황에 대한 처리는 불가피하며, 이것이 단점으로 드러나는 것은 마찬가지라고 생각하기 때문입니다. -컨슈머 주도 계약이라는 것도 중간에 큐나 토픽에 담는걸 생략하다 보니 서비스들 끼리 커플링이 일어나는 걸 언급하는데 함께 설명해 줬다면 좋았을 것 같다. \ No newline at end of file +컨슈머 주도 계약에서 중간에 큐나 토픽을 생략하여 서비스 간 커플링이 발생하는 점을 언급하고 있는데, 이 내용도 함께 설명해주었다면 더 좋았을 것 같습니다. From c317e5fc2fe4fbad6652562f8d7b0985a517926f Mon Sep 17 00:00:00 2001 From: Kim Jong Feel Date: Fri, 20 Mar 2026 12:37:57 +0900 Subject: [PATCH 5/7] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter14_Managing_Analytical_Data.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../jongfeel/Chapter14_Managing_Analytical_Data.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter14_Managing_Analytical_Data.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter14_Managing_Analytical_Data.md index 7457e244..bda8d215 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter14_Managing_Analytical_Data.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter14_Managing_Analytical_Data.md @@ -11,5 +11,4 @@ 대용량 운영 데이터 분석의 역사와 함께 현재 분산 환경에서는 어떻게 하는게 좋은지에 대한 내용까지 있다. 사실 14.2 부터는 모르는 내용이고, 용어도 어렵게 느껴지는 것들이 많아서 전체적으로 어려운 챕터에 속한 것 같다. -DPQ도 느낌은 별도의 운영 데이터를 분석하는 하나의 서비스 처럼 느껴진다. -DPQ 내에도 도메인 로직이 있고 DB도 있으니까 비즈니스 로직의 흐름과 별도의 서비스로 처리를 하고 분석 전용 데이터를 모으는 별도의 서비스로 구성하려는 것으로 이해가 된다. \ No newline at end of file +DPQ는 별도의 운영 데이터 분석 서비스로 보입니다. DPQ 자체에 도메인 로직과 데이터베이스가 존재하므로, 비즈니스 로직의 주 흐름에서 분리하여 분석용 데이터를 수집하고 처리하는 독립적인 서비스로 구성하려는 의도로 파악됩니다. From cd0868bf580cb6fb2c2c7c7a7554451bcc0d80f0 Mon Sep 17 00:00:00 2001 From: Kim Jong Feel Date: Fri, 20 Mar 2026 12:38:06 +0900 Subject: [PATCH 6/7] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md index 7548c7cb..e26c9aec 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md @@ -14,7 +14,7 @@ 분산 트랜잭션으로 만들어줘, 느린 걸 빠르게 개선해줘와 같은 프롬프트는 계속 지시하는 게 잘못된 것이라는 건 금방 알 수 있다. 바이브 코딩은 내가 원하는 기능을 구현하는 건 문제 없이 할 수 있다. 기능 구현의 문제를 넘어 아키텍처 결정은 필요에 의해서, 그러니까 상황에 따른 판단과 그 결정을 내리는 것인데 그건 해달라고 해서 할 수 있는 영역이 아니다. -물론 아는 사람은 그렇게 지시하겠지만, 일반 바이브 코딩의 한계는 이 시점에서 소프트웨어의 품질 외에 아키텍처 적인 문제 해결의 방법으로 갈라질 것이다. +물론 아는 사람은 그렇게 지시하겠지만, 일반 바이브 코딩의 한계는 이 시점에서 소프트웨어의 품질과 아키텍처 문제 해결 능력에서 드러날 것입니다. ## 논의 주제 From 76662c3796a62f7a3a921d028c3032b032550d55 Mon Sep 17 00:00:00 2001 From: Kim Jong Feel Date: Fri, 20 Mar 2026 12:38:13 +0900 Subject: [PATCH 7/7] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md index e26c9aec..33260b4d 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md @@ -21,4 +21,4 @@ 개발자가 직접 코딩하지 않아도 되는 AI 바이브 코딩이 가능한 시기에도 소프트웨어 아키텍처는 필요한가? 에 대한 의문입니다. => 초기 PoC/프로토타입은 아키텍처가 없어도 되거나 AI가 제시해주는 모놀리스 기반의 통합 백엔드 프론트로 해도 문제는 없을 거라 생각합니다. -이제 바이브 코딩을 하는 사용자가 얼마나 소프트웨어 관련 지식을 학습하고 프롬프트로 지시해서 더 잘 만들려고 하는 의지를 가지고 있느냐 없느냐의 차이가 가른다고 봅니다. 여기서 개발자가 살아남아야 하는 이유를 설명할 수 있는데, 코딩 하는 사람이 아닌 서비스를 기획하고 동작하는 소프트웨어로 만들 수 있는 사람을 넘어서 소프트웨어/컴퓨터 공학 지식을 가지고 더 상황에 맞고 아키텍처 특성을 가진 소프트웨어를 만드는 능력을 가지는게 경쟁력이 아닐까 생각합니다. \ No newline at end of file +이제 바이브 코딩을 하는 사용자가 소프트웨어 관련 지식을 얼마나 학습하고, 이를 프롬프트로 지시하여 더 나은 결과물을 만들려는 의지를 가졌는지에 따라 차이가 발생할 것입니다. 여기서 개발자가 살아남아야 하는 이유를 찾을 수 있습니다. 개발자의 경쟁력은 단순히 코드를 작성하는 것을 넘어, 서비스를 기획하고 동작하는 소프트웨어를 만드는 능력에서 나옵니다. 더 나아가, 소프트웨어/컴퓨터 공학 지식을 바탕으로 주어진 상황에 최적화된 아키텍처 특성을 갖춘 소프트웨어를 설계하고 구현하는 능력이 핵심 경쟁력이 될 것이라고 생각합니다.