소프트웨어 아키텍처 The Hard Parts 1주차 - 이근주 #579
Conversation
Removed a line requesting a final review.
|
우측에 있는 |
Summary of ChangesHello @GeunJuLEE, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! 이 PR은 '소프트웨어 아키텍처 The Hard Parts' 책의 1~3장 내용을 바탕으로, 소프트웨어 아키텍처 설계에서의 트레이드오프 개념과 다양한 아키텍처 스타일(모놀리식, 서비스 기반, MSA)의 특징을 탐구합니다. 특히, 저자의 실제 아키텍처 전환 경험과 이벤트 기반 아키텍처(EDA) 도입 사례를 상세히 공유하며, 이론과 실무를 연결하는 깊이 있는 통찰을 제공합니다. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
GeunJuLEE
added
2026
Software Architecture: The Hard Parts
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
소프트웨어 아키텍처 The Hard Parts 1-3장 내용을 깊이 있게 정리하고, 본인의 경험과 연결하여 훌륭하게 설명해주셨습니다. 특히 아키텍처를 선택하고 발전시켜온 과정과 EDA 도입 경험을 구체적으로 공유해주셔서 다른 사람들에게도 큰 도움이 될 것 같습니다. 전반적으로 내용이 매우 훌륭하며, 리뷰에서는 문서의 가독성을 조금 더 높이기 위한 몇 가지 사소한 제안(용어 통일, 장 제목 형식 일관성, 문장 구조 개선)을 드렸습니다. 공유해주셔서 감사합니다!
| ## 1 ~ 3장 | ||
| --- | ||
|
|
||
| ## chapter 1 - '베스트 프랙티스'가 없다면? |
There was a problem hiding this comment.
문서 전반의 통일성을 위해 장(Chapter) 제목 표기를 chapter 1과 같은 영문 대신 1장과 같이 한글로 수정하는 것을 제안합니다. 43행, 59행의 chapter 2, chapter 3도 함께 수정하면 좋겠습니다.
| ## chapter 1 - '베스트 프랙티스'가 없다면? | |
| ## 1장 - '베스트 프랙티스'가 없다면? |
|
|
||
| #### 여러 아키텍처를 거치며 느낀 점 | ||
|
|
||
| **레이어드 모놀리스**는 전통적이고 빠르게 시작하기에 좋았다. |
There was a problem hiding this comment.
47행 등 다른 곳에서는 '모놀리식'으로 표기되어 있습니다. 용어의 일관성을 위해 '모놀리스'를 '모놀리식'으로 수정하는 것이 좋겠습니다.
| **레이어드 모놀리스**는 전통적이고 빠르게 시작하기에 좋았다. | |
| **레이어드 모놀리식**은 전통적이고 빠르게 시작하기에 좋았다. |
| - 사내에 FDC(financial Data Center)가 존재하고, 매일 bulk로 사내 전체 DB를 조회하여 적재한다. 그리고 매일 배치를 돌려서 누락된 적립이 있는지 확인하고, 존재한다면 노티 이메일을 보내준다. 따라서 | ||
| 재처리가 가능하다. 이것이 운영에서 가장 중요한 포인트였다. |
There was a problem hiding this comment.
이 문장은 여러 절차를 한 번에 설명하고 있어 다소 길고 복잡하게 느껴집니다. 가독성을 높이기 위해 아래와 같이 내용을 분리하여 간결하게 다듬는 것을 제안합니다.
| - 사내에 FDC(financial Data Center)가 존재하고, 매일 bulk로 사내 전체 DB를 조회하여 적재한다. 그리고 매일 배치를 돌려서 누락된 적립이 있는지 확인하고, 존재한다면 노티 이메일을 보내준다. 따라서 | |
| 재처리가 가능하다. 이것이 운영에서 가장 중요한 포인트였다. | |
| - 재처리를 보장하는 운영 환경이 핵심이었습니다. 사내 FDC(Financial Data Center)가 매일 DB 전체를 bulk로 적재하고, 일일 배치가 누락된 적립을 확인하여 알림을 보냅니다. 이 덕분에 안정적인 재처리가 가능했습니다. |
| 1. **서비스 기반 아키텍처는 ‘과도기’인가, ‘최종 형태’인가?** | ||
| 서비스 기반은 MSA로 가기 위한 단계인가? | ||
| 아니면 **조직·트래픽·운영 역량이 맞으면 충분히 ‘최종 형태’**가 될 수 있는가? |
There was a problem hiding this comment.
서비스 기반 아키텍처는 ‘과도기’인가, ‘최종 형태’인가?
- 두가지 모두 가능하지만, 제 주변 기준 현실 사례로는 최종 형태로 밖에 못봤습니다. 즉, 과도기로 시작했더라도, 결국 DB분리의 리스크를 아무도 지고싶지 않아서 그냥 유지하는 것으로 보았습니다
서비스 기반은 MSA로 가기 위한 단계인가?
- 사람마다 기준이 다른데, 위 관점으로 보는 사람도 있는거 같은데, 그렇다면 MSA로 가기 위한 단계로 볼 수 있을거 같네요 but, 위에서 말한대로 제 주변 기준 현실 사례에서는 MSA로 가기위한 단계로 일단 서비스는 분리하고 이후에 DB분리까지 못가는 경우가 있다고 많이 들었습니다
아니면 **조직·트래픽·운영 역량이 맞으면 충분히 ‘최종 형태’**가 될 수 있는가?
- 상황에 따라서, 최종 형태가 될 수 있다고 생각합니다
개인적으로는 서비스 기반 아키텍쳐와 MSA 에 대한 구분 보다는, 왜 서비스 기반 아키텍처를 도입해야만 하는지에 대한 의도가 가장 중요하다고 생각합니다
의도가 있다면 어떤 형태라도 문제없다고 생각하고, 구체적인 의도 없이 그냥 분리한경우라면, 문제라고 생각합니다(면접 때, 지원자분과 얘기를 해보면 생각보다 이런 경우가 많더라고요, 단순히 MSA를 하는게 좋다고 생각해서 일단 서버만 분리해보았다 등..)
저희 팀의 경우엔, 기존에 운영되고 있던 서버 외에 추가로 개발해야할 도메인은 DB는 같이 사용하면서, 별도의 서버를 추가했는데요 그 이유는 아래와 같습니다
- 기존에 운영하던 서비스와 별도의 도메인 개발이 필요했는데, 각 서비스를 운영하는 팀이 다름
- 두 팀간 개발 배포주기를 굳이 맞출 필요가 없었고, 오히려 빠른 개발을 위해서는 팀별로 운영하는게 낫다고 판단함
- DynamoDB를 공유해서 쓰고 있었는데, 트래픽이 그렇게 많지도 않고, 온디맨드 모드로 사용중이였으며, 이미 키설계가 잘 되어있는 상태였기 때문에 DB에 의존성이 있는데 큰 문제가 아니라고 판단함
| 2. **MSA의 장점을 얻기 위해 반드시 필요한 전제는 무엇인가?** | ||
| DB 분리 없이도 MSA를 했다고 말할 수 있는가? |
There was a problem hiding this comment.
MSA의 장점을 얻기 위해 반드시 필요한 전제는 무엇인가?
- MSA를 해야한다 말아야한다의 결정에서 가장 먼저 고려해야할 전제는 장애 격리 라고 생각합니다. 예를 들면, admin의 슬로우 쿼리가 많이 발생해서, 결제쪽에서 에러가 난다, 이벤트 트래픽으로 인해 서버가 죽어서, 고객이 앱에 접속조차 못한다 등
- 그 외에는 여러가지 사유가 있을텐데, 회사의 사정에 맞게 알아서, 판단하면된다고 생각하는데, 기본적으로는 유지보수를 할 수 있는 인원이 반드시 갖춰줘야한다고 생각합니다 개발자는 2 ~ 3명인데 MS가 15~20개? 이러면 안되겠죠
There was a problem hiding this comment.
DB 분리 없이도 MSA를 했다고 말할 수 있는가?
- 일반적으로는 MSA는 DB 분리가 전제 됩니다 그래서, MSA를 적용할 때는 각 MS 마다 분리된 DB들의 정합성과 무결성을 어떻게 맞출 것인가에 대한 고민이 반드시 수반이 됩니다 그래서 DB분리 없이는 MSA를 했다고 말할 수 없습니다(책 내용 기준으론, 서비스 기반 아키텍쳐를 적용했다고 보는게 맞을거 같습니다)
- 그러나, 제 개인적으로는 현재 우리 회사 아키텍쳐가 MSA이냐 아니냐? 그래서 MSA를 해봤냐 안해봤냐를 어떤 특정기준으로 판단하는 것은 의미없는 논쟁이라고 생각하는 편 입니다. 왜냐하면, 사람마다, 회사마다 다 이해하는 수준도 다르고, 기준도 다르기 때문입니다
- 그래서, 제 개인적으로는 MSA를 했냐 안했냐? 로 하는 것보다는 좀 더 추상적으로, 분산 환경에서 서버를 설계하고 운영해보았느냐? 로 말하는게 더 명확하지 않을까 생각되고, 그 기준에선, DB를 각 MS마다 가지냐 안가지냐는 중요한 문제는 아니라고 생각하는 편 입니다(모든 분산 환경에서의 서버들이 DB를 가져야하는 것은 아니기 때문 - ex) aws lambda)
| #### 팀1 컨슘: Timeline 적재 | ||
|
|
||
| 팀1은 이 이벤트를 컨슘해서 | ||
| 결제 건을 Timeline에 적재한다. | ||
| 이 작업은 결제의 성공/실패와 운명을 같이할 필요가 없고, | ||
| 지연되더라도 나중에 따라잡을 수 있기 때문에 | ||
| 비동기 방식이 잘 맞았다. | ||
|
|
||
| #### 팀2 컨슘: 적립 계산 및 반영 | ||
|
|
||
| 팀2는 동일 이벤트를 컨슘한 뒤, | ||
| 자기 정책에 따라 적립 금액을 계산하고 적립을 반영한다. | ||
|
|
||
| 적립은 정책·이벤트·프로모션에 따라 변수가 많고, | ||
| 결제 서비스가 직접 알고 있어야 할 이유가 없다고 판단했다. | ||
| 오히려 결제 플로우에 섞이면 | ||
| 변경 영향 범위만 커진다. | ||
| 그래서 계산과 반영의 책임을 아예 분리했다. |
There was a problem hiding this comment.
[질문]
- 여기서 팀1, 팀2는 결제완료 이벤트 컨슘 이후, 수행해야할 비즈니스 로직을 팀별로 나누어서 책임을 가지도록 하신걸로 이해하면 될까요?
There was a problem hiding this comment.
네 그렇습니다. 좀 더 정확히 말씀드리면
내역의 경우, 예~~전에는 여러 팀(쇼핑, 외부결제, 디지털컨텐츠)에 나눠진 결제 데이터를 각각 조회하여 유저에게 보여줬는데,
내역팀이 만들어면서 카프카로 데이터를 내역팀에 주게 되었고,
적립의 경우, 서비스 파트에서 적립율을 주고, 결제 파트에서 계산 및 적립 요청을 하던 구조였는데,
적립파트에서 적립율 관련 어드민을 신설하여 서비스별 적립율을 작성하고 결제 완전 종료 후, 카프카로 데이터 주면 적립율계산 및 적립 로직을 가져갔습니다.
jongfeel
left a comment
jongfeel
left a comment
There was a problem hiding this comment.
한 회사의 한 도메인에서 오래 개발하기도 했고, 운영 서비스에 대한 고민을 많이 하면서 많은 경험을 한 것이 글에서 느껴지네요.
실무에서의 경험을 많이 쌓았을 때 아마 어떤 방법으로 변경해야 좋을까? 에 대한 고민을 많이 하셨을 것 같습니다.
책을 읽는다고 해서 그 고민이 해결되지는 않겠지만, 다음 번 혹은 그 다음 번에는 시행착오가 줄고 좋은 기법에 대해 팀 내에서 고민하고 적용하는 경험을 더 쌓는다면 분명 책을 읽고 지식을 쌓았던 시간이 헛된 시간이 아닐거라 생각합니다.
회사 일에 대해 계속 여유가 생기셨으면 좋겠는데 올해가 처음이지만 매년 참여해 보시는 건 어떨까요?
| 1. **서비스 기반 아키텍처는 ‘과도기’인가, ‘최종 형태’인가?** | ||
| 서비스 기반은 MSA로 가기 위한 단계인가? | ||
| 아니면 **조직·트래픽·운영 역량이 맞으면 충분히 '최종 형태'** 가 될 수 있는가? |
There was a problem hiding this comment.
책의 저자가 얘기하는 방향이라면 과도기일텐데, 특정 회사의 특정 조직은 최종 형태가 될 수 있다고도 생각합니다.
회사마다 비용과 수익에 따라 서비스 기반 아키텍처가 큰 문제가 없다고 하면 그대로 최종 형태일 수도 있다는 것이죠.
진짜 초기 스타트업이라면 작은 모놀리식도 최종 형태로 굳어져서 그대로 몇 년 동안 운영할 수도 있는 거고요.
책의 내용만 이해한다면 마이크로서비스 아키텍처를 지향해야 하겠지만
그렇지 않은 경우라고 해도 최종 형태로 판단하고 결정해도 문제는 없을 거라고 봅니다.
There was a problem hiding this comment.
책에 따르면 서비스 기반 아키텍처는 확장성 3점, 탄력성 2점이고, MSA는 확장성, 탄력성 모두 5점이라고 되어있습니다.
극단적인 확장성, 탄력성이 필요하지 않다면 서비스 기반 아키텍처도 충분히 최종 형태가 될 수 있다고 생각합니다.
| 2. **MSA의 장점을 얻기 위해 반드시 필요한 전제는 무엇인가?** | ||
| DB 분리 없이도 MSA를 했다고 말할 수 있는가? |
There was a problem hiding this comment.
이것도 역시 책의 내용대로 한다면 서비스 개수 만큼 아키텍처 퀀텀의 개수가 나와야 하고 각 서비스는 아키텍처 특성이 모두 같을 수도 있지만 같지 않게 해야 한다 일 것 같습니다.
정리하면
- 특정 도메인의 비즈니스 요구사항을 처리하는 작은 서비스
- 그 서비스만 사용하는 DB
- 서비스별 아키텍처 특성을 살려 설계
일 것 같네요.
DB의 분리 없이 MSA를 했느냐는 책을 읽었다면 "아니오"라고 해야 맞을 것 같습니다.
이 주제는 이후에 데이터베이스 관련 챕터를 읽고 난 후 논의 주제로 또 나올 것 같아서
이번 모임 때 논의 주제로 해보면 재밌을 것 같기도 합니다.
왜냐하면 나중에 데이터베이스 관련 내용을 읽고 난 후에도 각자 생각의 변화가 있을 것인가? 에 대해 궁금하기 때문이기도 합니다.
There was a problem hiding this comment.
MSA의 장점을 얻기 위해 반드시 필요한 전제는 무엇인가?
가장 중요한건 **현재의 상황(환경)**이겠지만.. MSA를 충분히 운영 가능한 환경(인원, 지원 등)이라면 아래의 요소들이 필수 전제라고 생각합니다.
- 각 서비스가 다른 서비스와 상관없이 독립적인 배포가 가능할 것
- 데이터베이스의 분리
- 이를 위한 명확한 도메인 식별/분리/설계
GeunJuLEE
requested review from
a team,
benscookie,
chichoon,
dhlee3994,
tttghost and
ymkim97
and removed request for
a team
| 1. **서비스 기반 아키텍처는 ‘과도기’인가, ‘최종 형태’인가?** | ||
| 서비스 기반은 MSA로 가기 위한 단계인가? | ||
| 아니면 **조직·트래픽·운영 역량이 맞으면 충분히 '최종 형태'** 가 될 수 있는가? |
There was a problem hiding this comment.
책에 따르면 서비스 기반 아키텍처는 확장성 3점, 탄력성 2점이고, MSA는 확장성, 탄력성 모두 5점이라고 되어있습니다.
극단적인 확장성, 탄력성이 필요하지 않다면 서비스 기반 아키텍처도 충분히 최종 형태가 될 수 있다고 생각합니다.
| 2. **MSA의 장점을 얻기 위해 반드시 필요한 전제는 무엇인가?** | ||
| DB 분리 없이도 MSA를 했다고 말할 수 있는가? |
There was a problem hiding this comment.
MSA의 장점을 얻기 위해 반드시 필요한 전제는 무엇인가?
가장 중요한건 **현재의 상황(환경)**이겠지만.. MSA를 충분히 운영 가능한 환경(인원, 지원 등)이라면 아래의 요소들이 필수 전제라고 생각합니다.
- 각 서비스가 다른 서비스와 상관없이 독립적인 배포가 가능할 것
- 데이터베이스의 분리
- 이를 위한 명확한 도메인 식별/분리/설계
No description provided.