소프트웨어 아키텍처 The Hard Parts 2주차 - 권태형

[TaeHyoungKwon]

나의 의견 요약

---

논의 주제

3번은 무시해주세요 🙇🏻

---

AI 활용 Action Items

회사 코드베이스에 적용

1. AI 도구들을 활용해서, 현재 회사 코드 베이스의 각 도메인(패키지)별 추상도/불안정도를 측정해서, 메인시퀀스로 부터의 거리를 측정한 결과를 보여주는 그래프 리포트 만들어서 현황 파악해보기

2. 같은 코드베이스에서, 컴포넌트 사이징을 책 의 예제처럼 비중, 문장 수, 파일 수로 정리해서 현황 파악해보기

개인 플젝에 적용

1. 5장에 나오는 일부 피트니스 함수를 AI로 직접 구현하고, pre-commit hook 혹은 빌드시점에 검사하도록 개발해보기

2. 평탄화에 대한 책 내용을 정리해서, CLAUDE.md 에 적어두고, AI Agent가 항상 이 규칙을 지키도록 해보기

[github-actions]

우측에 있는 Projects, Milestone, Development를 확인 후 할당 해주세요~! 🙇

[gemini-code-assist]

Summary of Changes

Hello @TaeHyoungKwon, I'm Gemini Code Assist¹! 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' 책의 4장과 5장에 대한 학습 내용을 정리한 것입니다. 아키텍처 분해 방법론, 컴포넌트 기반 분해 패턴, 그리고 공통 기능 추출과 같은 핵심 개념들을 다루며, 각 주제에 대한 개인적인 생각과 실무 적용 가능성을 탐구합니다. 이 문서는 책의 내용을 요약하고 저자의 인사이트를 공유하여 아키텍처 설계에 대한 이해를 돕는 것을 목표로 합니다.

Highlights

• 아키텍처 분해 방법론 논의: 4장에서는 아키텍처 분해 방법으로 컴포넌트 기반 분해와 전술적 분기를 다루며, 특히 전술적 분기를 먼저 적용하고 리팩토링하는 전략에 대한 논의 주제를 제시합니다. 구심/원심 커플링, 추상도/불안정도의 개념도 포함됩니다.
• 컴포넌트 기반 분해 패턴 심층 분석: 5장에서는 컴포넌트 기반 분해의 구체적인 패턴들을 탐구합니다. 컴포넌트 식별 및 사이징, 공통 도메인 컴포넌트 수집, 컴포넌트 평탄화, 의존성 결정, 도메인 및 서비스 생성 등 각 단계에 대한 상세한 내용과 개인적인 견해가 포함되어 있습니다.
• 공통 기능 추출 시점 및 중요성: 공통 기능을 별도의 클래스나 패키지로 추출하는 기준과 시점에 대한 논의 주제를 제시하며, 재활용도가 높은 유틸리티성 기능이 아니라면 성급한 추상화를 자제하고 코드 변화 패턴이 보일 때 천천히 추출하는 것이 좋다는 개인적인 의견을 공유합니다.
• 실무 적용 및 AI 활용 가능성: 아키텍처 분해 개념들을 실무에 적용하는 방안과 AI를 활용하여 리팩토링하거나 피트니스 함수를 구현하는 가능성에 대한 아이디어를 제시합니다.

🧠 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 Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

소프트웨어 아키텍처 4장과 5장에 대한 요약 및 생각을 정리한 문서를 추가하셨네요. 내용 구성이 잘 되어 있고, 깊이 있는 고민이 느껴집니다. 가독성을 조금 더 높이기 위해 몇 가지 맞춤법 및 띄어쓰기 수정을 제안드렸습니다.

[chichoon]

속도 면에서는 확실한 이점을 챙길 수 있을 것 같긴 한데, 컴포넌트들을 새롭게 만들다시피 해야 하는 컴포넌트 기반 분해에 비해 전술적 분기는 작업자들 간의 소통이나 코드 작성 역량에 따라 (아무래도 기존 코드를 복사해서 깎아내듯 작업하다보니) 찌꺼기 코드나 제대로 공통화되지 않는 부분이 많을듯 하여 후처리 시간이 좀 더 들 것 같긴 합니다

라고 적긴 했지만 사실 컴포넌트 기반 분해도 어찌됐던 간에 완벽하게 서비스별로 잘 분해하는 건 어려울 것 같고

밑에 적어주셨듯이 이런저런 준비 없이 과감하게 시도해볼 수 있다는 점에선 확실히 이점인것 같습니다

[chichoon]

일단 과감하게 다른 화면에서도 사용될 것 같은 기능이라면 일단 추출해두고, 정 사용되지 않는다 싶으면 예외처리나 의존성을 끊고 다시 서비스 하위로 밀어넣는 식으로 작업했습니다

겉보기엔 (기능상으론) 중복코드로 보이지만 사용되는 서비스나 컴포넌트에 따라 내부적으로 서로 다른 예외처리가 되어있을 때가 많아서

그런부분에선 그냥 중복된 코드여도 허용하는게 좋다고 생각합니다

분기가 덕지덕지 발라진 엄청 큰 코드보단 차라리 서비스별로 비슷한 코드가 남아있는게 나은 것 같습니다

[jongfeel]

👍

[jongfeel]

목표가 서비스를 도메인 별로 잘 분리 마이크로서비스를 만들고 싶으면 책의 전략을 가져가면 좋은데
그 마저도 최종 목표는 아니고, 진흙잡탕에서 진흙이라도 좀 건져내서 분리가 목표라면 전술적 분기도 충분히 좋을 수 있다고 봅니다.
책의 설명대로라면 모놀리식 구조는 그대로지만 덩어리를 쪼개는 방식이니까요.

[jongfeel]

저는 중복 코드가 있고 하나의 인터페이스로 뽑을 수 있으면 공통 기능으로 봅니다.
물론 전체 공통 기능은 거의 도메인과 상관 없는 util성 기능일 가능성이 높으므로 도메인 연관성이 있는 공통 코드만 보는 거죠. 책의 설명대로라면 .shared 컴포넌트일 것입니다.

명확하게 중복 코드이면 공통으로 뽑고, 중복이라 생각해서 공통 코드로 추출했는데 이후 복잡성 (새로 if 분기가 추가된다던지)이 생기면 공통 기능 추출은 하지 않는 쪽으로 선택합니다.

[tttghost]

첫 단추를 어떻게 꿰냐가 중요할 것 같습니다.
대부분의 경우는 말씀주신 대로 선 분기 후 리팩토링이 저도 좋다고 생각합니다. 그런데 최초 기반분해를 시작부터 잘 잡고 들어가야 하는 프로젝트를 전술적분기로 가르고 시작하는것은 또 아쉬울 것 같습니다. 조금은 빠르게 어떤방식으로 진행할지에 대한 고민을 하는편이 좋지않을까 합니다.