From 129df77319ada1ff653519e19400b98fb0c41b64 Mon Sep 17 00:00:00 2001 From: ymkim97 Date: Thu, 19 Feb 2026 18:59:01 +0900 Subject: [PATCH 1/8] chapter 8,9 --- .../ymkim97/chapter8_9.md | 46 +++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md new file mode 100644 index 00000000..1877f261 --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md @@ -0,0 +1,46 @@ +# 소프트웨어 아키텍처 The Hard Parts +## 8장 ~ 9장 +--- +## 논의 내용 +* 코드 재사용 관리 기법인 코드 복제, 공유 라이브러리, 공유 서비스, 사이드카 중 기존 기법에서 어떠한 이유로 다른 기법으로 변경해본 경험이 있으시면 공유하면서 얘기해 보면 좋을 것 같습니다. + * 저의 회사는 현재 공휴일에 대한 데이터 및 날짜 계산이 공유 라이브러리에 있어 매년 수동으로 업데이트를 해줘야 한다는 단점이 있습니다. 따라서 데이터 오너십을 가지는 서비스를 지정하고, 이를 공유 서비스로 옮기려는 계획하고 있습니다(서비스에서는 스케쥴러로 open api를 사용하여 공휴일 db 최신화). + +## Chapter 8 - 재사용 패턴 +서비스를 분해하면서 기존의 공통 코드나 기능을 처리하는데에 있어서도 다양한 방법과 트레이드 오프가 발생한다. +코드 재사용은 소프트웨어 개발에서 상식이기 때문에, 개발자들에게는 꽤나 당연하게 생각되어 코드 중복에 대해서 반응하는 편인 것 같다. +따라서 DRY 원칙 등을 기억하고 실천하려고 한다. +하지만 코드를 공유하거나 복제하는 것 중 하나만이 항상 정답이 아니기 때문에 다양한 기법을 알고 트레이드 오프를 분석해보아야 한다는 것을 배웠다. + +가장 단순한 코드 복제는 다른 공유 기법보다는 절대 우선시 되지 않는 방법이다. +어떻게 보면 독립성의 특성을 보이는 마이크로서비스에 잘 맞는 기법으로 보이지만, 만약 수정 사항이 생긴다면 이 코드를 가지고 있는 모든 서비스를 업데이트 해야한다. +대부분의 서비스에서 필요한 극히 정적인 일회성 코드, 독자적인 일회성 클래스라면 코드 복제 기법을 고려해 볼만 하다. + +가장 일반적인 방법 중 하나인 공유 라이브러리는 우리 회사에서도 잘 쓰여서 친근한 기법이다. +공유 라이브러리는 크기에 따라 디펜던시와 영향을 받는 서비스의 수준이 제각각이다. +공유 라이브러리가 크면 디펜던시는 낮아지고 영향을 받는 서비스는 올라가는 것이다. +책에서는 단위가 큰 공유 라이브러리는 삼가하고 권고하며, 가능한 한 작은 단위, 즉 기능별로 분리된 공유 라이브러리를 만들어 디펜던시 관리보다 변경 관리에 더 신경을 쓰는 편이 낫다고 한다. + +공유 라이브러리를 대신하는 기법은 공유 서비스다. +공유 서비스는 별도로 배포된 서비스 한 곳만 고치면 공유 기능을 필요로 하는 다른 서비스들을 다시 배포하지 않아도 간편하게 변경된 코드를 반영할 수 있다. +하지만 이것 역시 변경 리스크, 성능, 확장성, 내고장성 등 다양한 트레이드 오프가 뒤따른다. + +사이드카와 서비스 메시는 이전에 몇번 들어본 기억이 있지만, 이번 책을 통해서 처음으로 구체적인 의미를 알게 되었다. +사이드카 패턴은 도메인에서 운영 기능을 디커플링하는 좋은 방법일 뿐만 아니라, 특정한 종류의 커플링을 해소할 수 있는 직교적 재사용 패턴이라고 한다. +마이크로서비스 아키텍처는 도메인 중심으로 구성되지만 운영 커플링은 모든 도메인에 두루 적용되므로, 사이드카 패턴을 이용하면 이렇게 아키텍처 레이어를 넘나드는 횡단 관심사를 따로 일관되게 격리할 수 있다. + + +## Chapter 9 - 데이터 오너십과 분산 트랜잭션 +이번 챕터는 특히 요즘 회사에서 마주치는 실제 상황들과 잘 맞아 정말 재미있게 읽었다. +개발 업무를 진행하면서 책에서 나오는 기법들을 나도 모르게 생각하고 어떤 것을 적용하는게 맞는지 고민이었는데, 이번 기회에 더 명확히 장단점을 곱씹어 볼 수 있었다. +단독 오너십은 특별히 신경쓸 것이 없지만, 공통 또는 공동 오너십은 분산 아키텍처에서 결국 해결해야한다. +책에서는 테이블 분할 기법, 데이터 도메인 기법, 대리자 기법, 서비스 통합 기법을 대표적으로 설명한다. +회사에서는 대부분 대리자 기법을 사용하며, 주 도메인 우선 방법으로 담당하는 서비스를 지정한다. + +분산 트랜잭션 절을 읽으면서 BASE 속성을 제대로 배울 수 있게 되었다. +이 용어 역시 어디선가 한번씩은 보았던 기억이 있지만, 이번 책을 읽으면서 훨씬 와닿게 되었다. + +핵심인 최종 일관성 패턴에서는 이벤트 기반 패턴을 주로 사용했어서 비교적 쉽게 읽혔다. +가장 강한 동기화를 제공하는 것은 오케스트레이티드 요청 기반 패턴이지만, 이는 특히 보상 트랜잭션이 필요하기 때문에 복잡성이 증가한다. +해당 부분에 대해서도 더 깊게 호기심이 있지만, 보상 트랜잭션과 트랜잭셔널 사가에 대해서는 12장에서 자세히 다룬다고 하니 기다려보면서 책을 읽어봐야겠다. + + From 19511cc1be2a8025d1f178e511f4ebc93bc21650 Mon Sep 17 00:00:00 2001 From: Youngmyung Kim Date: Thu, 19 Feb 2026 19:38:30 +0900 Subject: [PATCH 2/8] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../ymkim97/chapter8_9.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md index 1877f261..e5314968 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md @@ -3,7 +3,7 @@ --- ## 논의 내용 * 코드 재사용 관리 기법인 코드 복제, 공유 라이브러리, 공유 서비스, 사이드카 중 기존 기법에서 어떠한 이유로 다른 기법으로 변경해본 경험이 있으시면 공유하면서 얘기해 보면 좋을 것 같습니다. - * 저의 회사는 현재 공휴일에 대한 데이터 및 날짜 계산이 공유 라이브러리에 있어 매년 수동으로 업데이트를 해줘야 한다는 단점이 있습니다. 따라서 데이터 오너십을 가지는 서비스를 지정하고, 이를 공유 서비스로 옮기려는 계획하고 있습니다(서비스에서는 스케쥴러로 open api를 사용하여 공휴일 db 최신화). + * 저의 회사는 현재 공휴일에 대한 데이터 및 날짜 계산이 공유 라이브러리에 있어 매년 수동으로 업데이트를 해줘야 한다는 단점이 있습니다. 따라서 데이터 오너십을 가지는 서비스를 지정하고, 이를 공유 서비스로 옮기려는 계획하고 있습니다(서비스에서는 스케쥴러로 OpenAPI를 사용하여 공휴일 db 최신화). ## Chapter 8 - 재사용 패턴 서비스를 분해하면서 기존의 공통 코드나 기능을 처리하는데에 있어서도 다양한 방법과 트레이드 오프가 발생한다. From e26289f8e24ae1d06b0d9b873be472f35508cd76 Mon Sep 17 00:00:00 2001 From: Youngmyung Kim Date: Thu, 19 Feb 2026 19:38:47 +0900 Subject: [PATCH 3/8] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../ymkim97/chapter8_9.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md index e5314968..6208e801 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md @@ -6,7 +6,7 @@ * 저의 회사는 현재 공휴일에 대한 데이터 및 날짜 계산이 공유 라이브러리에 있어 매년 수동으로 업데이트를 해줘야 한다는 단점이 있습니다. 따라서 데이터 오너십을 가지는 서비스를 지정하고, 이를 공유 서비스로 옮기려는 계획하고 있습니다(서비스에서는 스케쥴러로 OpenAPI를 사용하여 공휴일 db 최신화). ## Chapter 8 - 재사용 패턴 -서비스를 분해하면서 기존의 공통 코드나 기능을 처리하는데에 있어서도 다양한 방법과 트레이드 오프가 발생한다. +서비스를 분해하면서 기존의 공통 코드나 기능을 처리하는 데 있어서도 다양한 방법과 트레이드 오프가 발생한다. 코드 재사용은 소프트웨어 개발에서 상식이기 때문에, 개발자들에게는 꽤나 당연하게 생각되어 코드 중복에 대해서 반응하는 편인 것 같다. 따라서 DRY 원칙 등을 기억하고 실천하려고 한다. 하지만 코드를 공유하거나 복제하는 것 중 하나만이 항상 정답이 아니기 때문에 다양한 기법을 알고 트레이드 오프를 분석해보아야 한다는 것을 배웠다. From fec235833aa551b565a03eee437a81610a717184 Mon Sep 17 00:00:00 2001 From: Youngmyung Kim Date: Thu, 19 Feb 2026 19:38:59 +0900 Subject: [PATCH 4/8] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../ymkim97/chapter8_9.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md index 6208e801..5e14e45d 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md @@ -12,7 +12,7 @@ 하지만 코드를 공유하거나 복제하는 것 중 하나만이 항상 정답이 아니기 때문에 다양한 기법을 알고 트레이드 오프를 분석해보아야 한다는 것을 배웠다. 가장 단순한 코드 복제는 다른 공유 기법보다는 절대 우선시 되지 않는 방법이다. -어떻게 보면 독립성의 특성을 보이는 마이크로서비스에 잘 맞는 기법으로 보이지만, 만약 수정 사항이 생긴다면 이 코드를 가지고 있는 모든 서비스를 업데이트 해야한다. +어떻게 보면 독립성의 특성을 보이는 마이크로서비스에 잘 맞는 기법으로 보이지만, 만약 수정 사항이 생긴다면 이 코드를 가지고 있는 모든 서비스를 업데이트해야 한다. 대부분의 서비스에서 필요한 극히 정적인 일회성 코드, 독자적인 일회성 클래스라면 코드 복제 기법을 고려해 볼만 하다. 가장 일반적인 방법 중 하나인 공유 라이브러리는 우리 회사에서도 잘 쓰여서 친근한 기법이다. From 44e2bb523d395f2bf2e9a7242703496124dab668 Mon Sep 17 00:00:00 2001 From: Youngmyung Kim Date: Thu, 19 Feb 2026 19:39:08 +0900 Subject: [PATCH 5/8] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../ymkim97/chapter8_9.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md index 5e14e45d..7a07aac4 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md @@ -13,7 +13,7 @@ 가장 단순한 코드 복제는 다른 공유 기법보다는 절대 우선시 되지 않는 방법이다. 어떻게 보면 독립성의 특성을 보이는 마이크로서비스에 잘 맞는 기법으로 보이지만, 만약 수정 사항이 생긴다면 이 코드를 가지고 있는 모든 서비스를 업데이트해야 한다. -대부분의 서비스에서 필요한 극히 정적인 일회성 코드, 독자적인 일회성 클래스라면 코드 복제 기법을 고려해 볼만 하다. +대부분의 서비스에서 필요한 극히 정적인 일회성 코드, 독자적인 일회성 클래스라면 코드 복제 기법을 고려해 볼 만하다. 가장 일반적인 방법 중 하나인 공유 라이브러리는 우리 회사에서도 잘 쓰여서 친근한 기법이다. 공유 라이브러리는 크기에 따라 디펜던시와 영향을 받는 서비스의 수준이 제각각이다. From 2db476836473fe1f17c08531b92639fdf16afaa5 Mon Sep 17 00:00:00 2001 From: Youngmyung Kim Date: Thu, 19 Feb 2026 19:39:20 +0900 Subject: [PATCH 6/8] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../ymkim97/chapter8_9.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md index 7a07aac4..162c4a8e 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md @@ -18,7 +18,7 @@ 가장 일반적인 방법 중 하나인 공유 라이브러리는 우리 회사에서도 잘 쓰여서 친근한 기법이다. 공유 라이브러리는 크기에 따라 디펜던시와 영향을 받는 서비스의 수준이 제각각이다. 공유 라이브러리가 크면 디펜던시는 낮아지고 영향을 받는 서비스는 올라가는 것이다. -책에서는 단위가 큰 공유 라이브러리는 삼가하고 권고하며, 가능한 한 작은 단위, 즉 기능별로 분리된 공유 라이브러리를 만들어 디펜던시 관리보다 변경 관리에 더 신경을 쓰는 편이 낫다고 한다. +책에서는 단위가 큰 공유 라이브러리는 삼가라고 권고하며, 가능한 한 작은 단위, 즉 기능별로 분리된 공유 라이브러리를 만들어 디펜던시 관리보다 변경 관리에 더 신경을 쓰는 편이 낫다고 한다. 공유 라이브러리를 대신하는 기법은 공유 서비스다. 공유 서비스는 별도로 배포된 서비스 한 곳만 고치면 공유 기능을 필요로 하는 다른 서비스들을 다시 배포하지 않아도 간편하게 변경된 코드를 반영할 수 있다. From fc16746e107e41fc8a43c18a82f9aef8383910c7 Mon Sep 17 00:00:00 2001 From: Youngmyung Kim Date: Thu, 19 Feb 2026 19:39:28 +0900 Subject: [PATCH 7/8] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../ymkim97/chapter8_9.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md index 162c4a8e..8a093b76 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md @@ -32,7 +32,7 @@ ## Chapter 9 - 데이터 오너십과 분산 트랜잭션 이번 챕터는 특히 요즘 회사에서 마주치는 실제 상황들과 잘 맞아 정말 재미있게 읽었다. 개발 업무를 진행하면서 책에서 나오는 기법들을 나도 모르게 생각하고 어떤 것을 적용하는게 맞는지 고민이었는데, 이번 기회에 더 명확히 장단점을 곱씹어 볼 수 있었다. -단독 오너십은 특별히 신경쓸 것이 없지만, 공통 또는 공동 오너십은 분산 아키텍처에서 결국 해결해야한다. +단독 오너십은 특별히 신경쓸 것이 없지만, 공통 또는 공동 오너십은 분산 아키텍처에서 결국 해결해야 한다. 책에서는 테이블 분할 기법, 데이터 도메인 기법, 대리자 기법, 서비스 통합 기법을 대표적으로 설명한다. 회사에서는 대부분 대리자 기법을 사용하며, 주 도메인 우선 방법으로 담당하는 서비스를 지정한다. From 174aea8c3f124011e7c8041bc264e2a7e9a40b89 Mon Sep 17 00:00:00 2001 From: Youngmyung Kim Date: Thu, 19 Feb 2026 19:39:41 +0900 Subject: [PATCH 8/8] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../ymkim97/chapter8_9.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md index 8a093b76..ede9b457 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md @@ -41,6 +41,6 @@ 핵심인 최종 일관성 패턴에서는 이벤트 기반 패턴을 주로 사용했어서 비교적 쉽게 읽혔다. 가장 강한 동기화를 제공하는 것은 오케스트레이티드 요청 기반 패턴이지만, 이는 특히 보상 트랜잭션이 필요하기 때문에 복잡성이 증가한다. -해당 부분에 대해서도 더 깊게 호기심이 있지만, 보상 트랜잭션과 트랜잭셔널 사가에 대해서는 12장에서 자세히 다룬다고 하니 기다려보면서 책을 읽어봐야겠다. +해당 부분에 대해서도 더 깊게 호기심이 있지만, 보상 트랜잭션과 트랜잭셔널 사가에 대해서는 12장에서 자세히 다룬다고 하니 기다리면서 책을 읽어봐야겠다.