-
Notifications
You must be signed in to change notification settings - Fork 5
소프트웨어 아키텍처 the hard parts sprint 6 - 김영명 #627
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
ymkim97
wants to merge
1
commit into
main
Choose a base branch
from
ymkim97-2026-sprint6
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
48 changes: 48 additions & 0 deletions
48
2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter13_14_15.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,48 @@ | ||
| # 소프트웨어 아키텍처 The Hard Parts | ||
| ## 13장 ~ 15장 | ||
| --- | ||
| ## 논의 내용 | ||
| * 분석 데이터 관리에 대해서 어떤 방식을 접해보았는지 의논해보고 싶습니다. | ||
| * 제가 알기로는 현재 회사에서 CDC + BigQuery 형태로 분석 데이터를 관리하고 있는데요, 좀 무거운 쿼리들은 prod reader 보다는 부담없이 해당 기술로 마음껏 볼 수 있어서 꽤 편하다고 느꼈습니다. | ||
|
Comment on lines
+5
to
+6
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 저희 회사에선, DataWareHouse 형태로 Big Query로 조회할 수 있게 구성되어있고, 현재는 AWS Aurora CDC 기능을 통해서 적재하는 것으로 보이는데, 업무와 연관된 부분은 아니다보니, 상세한 내부 동작은 잘 모르겠네요 BigQuery의 경우 주로, PO(기획자)분들이나 운영팀에서 비즈니스 현황 파악 차원에서 확인하시거나, ML 학습용으로 사용하시는거 같고, 개발자 단에서는 잘 사용하진 않는거 같습니다 |
||
|
|
||
| ## Chapter 13 - 계약 | ||
| 소프트웨어 아키텍처에서 계약은 통합점 같은 것들을 기술하기 위해 폭넓게 활용된다. | ||
| SOAP, REST, gRPC, XMLRPC 등 다양한 계약 포맷은 소프트웨어의 설계 프로세스 중 하나다. | ||
| 때마침 회사에서 스터디로 책 “모던 API 아키텍처 설계 전략”을 읽고 있었고, 그 책에서도 API에 대해서 설명하면서 계약에 관한 내용이 나왔었다. | ||
| 따라서 계약이라는 단어가 생소하지 않고 조금 익숙하게 받아들일 수 있었다. | ||
|
|
||
| 계약도 다양한 방식이 있었고, 대부분의 개발자들에게는 REST가 가장 친숙할 것이다. | ||
| 웬만한 서비스에서는 REST로 문제 해결이 가능하기 때문에 REST가 주를 이루는 것이라고 생각한다. | ||
| 물론 회사 내에서 때에 따라 몇가지 계약 방식이 함께 사용될 수도 있다. | ||
| 엄격한 계약과 느슨한 계약도 아키텍처처럼 트레이드오프가 존재한다. | ||
| 엄격한 계약은 계약 충실도 보장, 버저닝, 쉬운 빌드 시점 검증, 우수한 문서화라는 장점이 있는 반면 단단한 커플링과 버저닝이라는 단점이 동시에 발생한다. | ||
ymkim97 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| 느슨한 계약은 고도의 디커플링, 좋은 발전성이라은 장점과 계약 관리, 피트니스 함수의 필요가 단점이 있다. | ||
ymkim97 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| 책에서 나온 컨슈머 주도 계약은 위에서 언급한 “모던 API 아키텍처 설계 전략”에서도 나오는데, 이에 반대가 되는 생산자 계약에 관한 내용은 나오지 않아서 조금 아쉬웠다. | ||
| 생산자 계약과의 트레이드오프도 나왔으면 조금 더 이해가 쉽거나 해당 방식의 언급 이유을 알 수 있었을 것이라고 생각했다. | ||
ymkim97 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ## Chapter 14 - 분석 데이터 관리 | ||
| 해당 챕터는 DA, DE 등에게 좀 더 와닿을 수 있는 챕터라고 느껴졌다. | ||
| 회사의 경쟁력을 평가할 수 있는 것 중 하나가 데이터이기 때문에 분석 데이터와 운영 데이터가 분리되면서 사용된다. | ||
| 책에서 나오는 데이터 웨어하우스, 데이터 레이크, 데이터 메시 방법은 한번씩은 들어봤어도 꽤 생소했다. | ||
| 그래도 그나마 회사에서 CDC(debezium)와 BigQuery를 사용하여 분석 데이터를 분리해내는 방식을 채택하고 있어 분석 데이터를 따로 관리하는 방법 중 하나에 대해서 대략적으로만 알고 있다. | ||
| 운영 데이터와 관련된 쉽지 않은 트레이드오프는 이 책에서 이미 많은 지면을 할애하여 설명하였고 아키텍처와 꽤 연관이 있었지만, 분석 데이터 관리는 운영 데이터 만큼 나에게 메인으로 생각되지는 않고 새로운 개념이 많아 꽤 어렵게 읽혔다. | ||
|
|
||
| ## Chapter 15 - 자신만의 트레이드오프 분석 | ||
| 이번 장은 책을 마무리하면서 다시 한번 책의 전반적인 내용을 요약하듯 조언을 건네는 내용이 보기 좋았다. | ||
| 물론 지금 보았을 때는 바로 적용하고 실천하기에는 나의 경험과 연차가 부족하지만, 언젠가는 도움이 될 것 같다는 느낌이 들었다. | ||
|
|
||
| 2장에서 소개했듯이, 현대 트레이드오프 분석은 다음 3단계를 거친다고 한다. | ||
| * 어느 파트가 서로 관련돼 있는지 확인한다. | ||
| * 어떻게 서로 결합돼 있는지 분석한다. | ||
| * 상호 의존적 시스템의 변경 영향도를 파악함으로써 트레이드오프를 평가한다. | ||
|
|
||
| 책을 읽으면서 예시로 보았던 아키텍처들은 하나같이 모두 통신, 일관성, 조정이라는 차원의 변화에 민감했다. | ||
| 그리고 이 프로세스는 아키텍처에서 반복 설계가 얼마나 중요한지를 잘 나타낸다. | ||
| 어떤 워크플로에 대한 샘플 토폴로지를 만들어보고 그 트레이드오프를 메트릭스 형태로 나타내면, 그때그때 임시로 접근하는 방식보다 더 신속하고 철저한 분석이 가능하다고 한다. | ||
ymkim97 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| 각 패턴을 독립적으로 분석한 다음, 그 특성을 비교하는 매트릭스를 작성하면 결합도와 확장성/탄력성은 직접적인 반비례 관계와 같은 흥미로운 사실을 볼 수 있다. | ||
| 이러한 분석 기법은 반복 아키텍처링의 좋은 예라고 한다. | ||
|
|
||
| 또한 트레이드오프를 검토할 때는 반드시 콘텍스트에 따라 의사 결정을 해야한다고 조언한다. | ||
| 그렇지 않으면 아키텍트가 애써 수행한 트레이드오프 분석이 외부적 요인의 막대한 영향을 받게 될 것이기 때문이다. | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
저도 이번에 책에서 접한게 처음이라 영명님이 회사에서 관리하는 방식을 좀 들어보면 좋을 것 같네요.