소프트웨어 아키텍처 The Hard Parts 2주차 - 이근주 #592
Conversation
|
우측에 있는 |
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은 '소프트웨어 아키텍처 기초 2판'의 4장과 5장 내용을 요약하고, 아키텍처 분해 및 컴포넌트 기반 설계 패턴에 대한 저자의 깊이 있는 고찰과 실제 개발 경험을 담은 새로운 문서를 추가합니다. 이는 복잡한 시스템을 설계하고 개선하는 과정에서 발생할 수 있는 고민과 해결책에 대한 통찰을 제공하며, 특히 MSA 전환 과정에서의 전략적 접근 방식에 대한 논의를 제안합니다. 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}
| 분해를 할 때 가장 중요한 것은 장애가 나지 않고, 기존과 얼마나 똑같이 잘 작동하도록 하느냐이다. | ||
| 현재는 기존 어플리케이션을 복제하여 다시 개발하는 것을 하고 있다. | ||
| 다른 분야는 어떨지 모르지만 이정도로 개발하는 정도라면 새로운 프로젝트를 아예 개발하는게 낫지 않을까 라는 생각이든다. | ||
| BE 개발자인 나로써는 api 단위로 새로운 프로젝트에 개발하여 새로운 버전의 api를 타 팀에게 전달할 것이다. |
There was a problem hiding this comment.
'BE 개발자'라는 자격이나 신분을 나타낼 때는 ~로서를 사용하는 것이 문법적으로 올바릅니다. ~로써는 도구나 수단을 나타낼 때 사용됩니다.
| BE 개발자인 나로써는 api 단위로 새로운 프로젝트에 개발하여 새로운 버전의 api를 타 팀에게 전달할 것이다. | |
| BE 개발자인 나로서는 api 단위로 새로운 프로젝트에 개발하여 새로운 버전의 api를 타 팀에게 전달할 것이다. |
| 컴포넌트 도메인 생성 패턴 관련해서는 책을 읽었지만 솔직히 와닿지 않는다. 예를 들면 이 책에서는 "과금 결제"를 "ss.customer.billing.payment"로 되어있는데, 만약 자동결제 혹은 정기결제가 | ||
| 있다면 이건 "ss.customer.billing.auto.pay" 이런 식이 될 것이고, b2c를 하는 회사라면 거의 대부분의 것이 customer 하위에 있을 것이다(최근 결제 수단, 적립, 포인트 충전, 영수증 | ||
| 발급 등등). |
There was a problem hiding this comment.
한 문장이 길어 내용을 파악하기가 다소 어렵습니다. 문장을 나누어 작성하면 가독성이 향상될 것 같습니다. 또한, 'b2c'는 일반적으로 대문자 'B2C'로 표기합니다.
| 컴포넌트 도메인 생성 패턴 관련해서는 책을 읽었지만 솔직히 와닿지 않는다. 예를 들면 이 책에서는 "과금 결제"를 "ss.customer.billing.payment"로 되어있는데, 만약 자동결제 혹은 정기결제가 | |
| 있다면 이건 "ss.customer.billing.auto.pay" 이런 식이 될 것이고, b2c를 하는 회사라면 거의 대부분의 것이 customer 하위에 있을 것이다(최근 결제 수단, 적립, 포인트 충전, 영수증 | |
| 발급 등등). | |
| 컴포넌트 도메인 생성 패턴 관련해서는 책을 읽었지만 솔직히 와닿지 않는다. 예를 들면 이 책에서는 "과금 결제"를 "ss.customer.billing.payment"로 되어있는데, 만약 자동결제 혹은 정기결제가 | |
| 있다면 이건 "ss.customer.billing.auto.pay" 이런 식이 될 것이고, B2C를 하는 회사라면 거의 대부분의 것이 customer 하위에 있을 것이다(최근 결제 수단, 적립, 포인트 충전, 영수증 | |
| 발급 등등). |
| - 나는 새로운 app을 서버에 띄우고, 해당 테이블에 관련된 api를 만들어서 기존 모놀리식에서 해당 테이블을 보는 것이 아니라 신규 api를 보고 기존 모놀리식 코드에서 해당 테이블 보는 코드가 완전 없어졌다면, | ||
| 따로 DB를 분리하는 식이 더 좋지 않을까 라는 생각이 든다. |
There was a problem hiding this comment.
문장이 길고 구조가 복잡하여 이해하기 어렵습니다. 생각을 단계별로 나누어 여러 문장으로 표현하면 전달력이 더 좋아질 것 같습니다.
| - 나는 새로운 app을 서버에 띄우고, 해당 테이블에 관련된 api를 만들어서 기존 모놀리식에서 해당 테이블을 보는 것이 아니라 신규 api를 보고 기존 모놀리식 코드에서 해당 테이블 보는 코드가 완전 없어졌다면, | |
| 따로 DB를 분리하는 식이 더 좋지 않을까 라는 생각이 든다. | |
| - 나는 새로운 app을 서버에 띄우고, 해당 테이블에 관련된 api를 만든다. 기존 모놀리식에서는 해당 테이블을 직접 보는 대신 신규 api를 호출하도록 변경하고, 테이블을 직접 참조하는 코드가 완전히 사라졌을 때 따로 DB를 분리하는 식이 더 좋지 않을까 라는 생각이 든다. |
| 분해를 하다보면 리팩토링 해야할 것이 보이고, 리팩토링은 욕심이 문제다. 리팩토링을 하다보면 고치고 싶은 것이 눈에 계속 보이고, 그것들 중 적당량만 수정한 후, 배포하는 식으로 하며 오류를 잡아야한다. 욕심이 생겨서 계속 수정을 하며 한번에 배포하는 순간, | ||
| 장애는 시작된다. 누군가는 잦은 배포가 잦은 장애를 만든다고 하지만, 난 그렇게 잘게 쪼개서 나가는 것이 경험상 더 안정적이라 생각한다. No newline at end of file |
There was a problem hiding this comment.
문장의 가독성을 높이기 위해 여러 곳의 띄어쓰기와 표현을 수정하는 것을 제안합니다. 예를 들어 해야할은 해야 할로, 잡아야한다는 잡아야 한다로, 난은 나는으로 바꾸면 더 자연스럽습니다.
| 분해를 하다보면 리팩토링 해야할 것이 보이고, 리팩토링은 욕심이 문제다. 리팩토링을 하다보면 고치고 싶은 것이 눈에 계속 보이고, 그것들 중 적당량만 수정한 후, 배포하는 식으로 하며 오류를 잡아야한다. 욕심이 생겨서 계속 수정을 하며 한번에 배포하는 순간, | |
| 장애는 시작된다. 누군가는 잦은 배포가 잦은 장애를 만든다고 하지만, 난 그렇게 잘게 쪼개서 나가는 것이 경험상 더 안정적이라 생각한다. | |
| 분해를 하다 보면 리팩토링 해야 할 것이 보이고, 리팩토링은 욕심이 문제다. 리팩토링을 하다 보면 고치고 싶은 것이 눈에 계속 보이고, 그것들 중 적당량만 수정한 후, 배포하는 식으로 하며 오류를 잡아야 한다. 욕심이 생겨서 계속 수정을 하며 한 번에 배포하는 순간, | |
| 장애는 시작된다. 누군가는 잦은 배포가 잦은 장애를 만든다고 하지만, 나는 그렇게 잘게 쪼개서 나가는 것이 경험상 더 안정적이라고 생각한다. |
GeunJuLEE
requested review from
TaeHyoungKwon,
benscookie,
chichoon,
dhlee3994,
jongfeel,
tttghost and
ymkim97
| ### 논의사항 | ||
|
|
||
| 1. 결국 DB 분리까지 하는 MSA가 목표라면 굳이 이렇게 나눠야하는가? api 단위로 새로 app 띄우는게 빠르지 않을까? | ||
|
|
||
| - 나는 새로운 app을 서버에 띄우고, 해당 테이블에 관련된 api를 만들어서 기존 모놀리식에서 해당 테이블을 보는 것이 아니라 신규 api를 보고 기존 모놀리식 코드에서 해당 테이블 보는 코드가 완전 없어졌다면, | ||
| 따로 DB를 분리하는 식이 더 좋지 않을까 라는 생각이 든다. |
There was a problem hiding this comment.
제 생각에도 책의 주장이 조금 과하다고 생각이 들었습니다. 말씀주신 방법도 상황에 따라 다르겠지만, 하나의 방법이 될 수 있을거 같네요 👍🏻 (답변주신 내용은 일종의 스트랭글러 패턴 같은 느낌이네요)
| - 나는 새로운 app을 서버에 띄우고, 해당 테이블에 관련된 api를 만들어서 기존 모놀리식에서 해당 테이블을 보는 것이 아니라 신규 api를 보고 기존 모놀리식 코드에서 해당 테이블 보는 코드가 완전 없어졌다면, | ||
| 따로 DB를 분리하는 식이 더 좋지 않을까 라는 생각이 든다. |
There was a problem hiding this comment.
방법 자체는 근주님의 방법도 합리적이긴 한데, 그럴 시간이 얼마나 주어지는지는 다른 문제일 것 같긴 합니다.
|
|
||
| ### 정리 | ||
|
|
||
| 컴포넌트를 어떻게 잘 전략적으로 나눌 것인가에 대한 내용이다. 정답은 없지만 감보다는 전략적으로 분석하여 나누라는 것이 요지인것으로 보인다. |
There was a problem hiding this comment.
절대적인것은 없지만 경험에서 오는 차이는 있지않을까 하는 생각이 듭니다.같습니다. 주니어급 개발자 여럿이 전략적인부분을 RnD 하여 나누는 것 보단 경험이 많은 팀장급 개발자가 감은 아니지만 직관적으로 나누는 구간을 더 잘 알지 않을까? 생각이 듭니다.
2026.01.23은 청첩장 모임으로 인해 불참 혹은 늦참 하겠습니다.