Apply suggestions from code review

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

Author: chichoon

2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/07.md

@@ -24,7 +24,7 @@
   - 컴파일 타임에 라이브러리 코드들이 서비스들에 공유된다
   - 공유 코드의 변경 빈도가 (코드 복사가 필요할 때처럼 변경 빈도가 아예 없는 수준은 아니지만) 꽤 낮을 경우 적합한 기법
 - 라이브러리의 트레이드오프는 라이브러리의 크기가 좌우한다
-  - 단위가 큰 공유 라이브러리 한두개만 사용할 경우, 하나의 통짜 라이브러리만 업데이트하고 관리하면 되기 때문에 각 서비스별 디펜던시 관리가 수월하다 (디펜던시 적음)
+-   단위가 큰 공유 라이브러리 한두 개만 사용할 경우, 하나의 통짜 라이브러리만 업데이트하고 관리하면 되기 때문에 각 서비스별 디펜던시 관리가 수월하다 (디펜던시 적음)
     - 허나 라이브러리 안의 코드가 조금씩 변경되면, 라이브러리 전체에 영향을 미치므로, 라이브러리 업데이트와 함께 테스트 범위가 매우 커진다 (변경 관리 어려움)
   - 단위가 작은 라이브러리 여러 개를 사용할 경우, 한 라이브러리에서 발생한 변경점은 다른 라이브러리나 코드에 큰 영향을 미치지 않으므로 유지보수가 수월하다 (변경 관리 쉬움)
     - 단 서비스 - 라이브러리 간 의존도가 복잡해지며 (한 서비스가 하나의 라이브러리만 바라보는 것이 아니므로) 이것이 나중에는 큰 진흙덩어리 하나가 될 가능성이 있다 (디펜던시 많음)
@@ -42,7 +42,7 @@
 
 ### 공유 서비스
 
-- 공유 라이브러리보다 한 사이즈 큰 기법
+- 공유 라이브러리보다 더 큰 규모의 기법
   - 공용 기능을 묶어 하나의 서비스로 두고, 다른 서비스들이 이를 바라보게 하는 기법
   - 다른 기법 (복제, 라이브러리화) 와 같은 코드 상속보다는, 여러 기능을 조합하여 큰 기능을 만드는 형태
 - 기능을 공유 서비스로 분리할 경우, 해당 기능이 변경되어도 다른 서비스까지 재배포할 일이 없어 간편하다
@@ -64,7 +64,7 @@
   - 오토바이 옆에 붙어있는 사이드카에서 명칭을 따옴
 - 한 서비스 내에 분리가능한 파트 (도메인 관심사와 조금 떨어져있는 파트), 타 서비스와 엮이는 커플링에 해당하는 파트를 사이드카로 분리
   - 타 서비스와 사이드카 파트를 통해 기능을 연결할 수 있다
-  - 사이드카끼리 맞물려 형성한 일종의 그물망을 메시라고 함 (그물망이 영어로 메시임)
+-   사이드카끼리 맞물려 형성한 그물망과 같은 네트워크를 서비스 메시(service mesh)라고 합니다.
 
 ```
 논의점 및 느낀점: 유독 공유 서비스 기법에 대한 단점이 길게 서술된 느낌이 든다. 반면 사이드카 기법은 구축이 복잡한 편이다~ 정도 외엔 장점 위주로 적혀 있는데, 다른 분들은 해당 두 파트를 읽으면서 비슷한 생각을 하셨을지 유독 궁금한 챕터였다.
@@ -78,5 +78,5 @@
 
 - 코드 재사용이 권장되고는 있지만, 무턱대고 재사용할 경우에도 부작용이 발생할 수 있다
   - 하나의 코드에서 너무 많은 업무를 수행하게 되면서, 복잡해질 우려가 있다
-  - 코드의 일부분이 어그러질 경우, 그 코드를 사용하는 모든 곳이 영향을 받는다
+  - 코드의 일부분에 문제가 생길 경우, 그 코드를 사용하는 모든 곳이 영향을 받는다
 - 너무 자주 변경되는 코드보단 변경 빈도가 낮은 코드들이 재사용 성공률이 높다