소프트웨어 아키텍처 The Hard Parts 1주차 - 최지윤 #585
Conversation
|
우측에 있는 |
chichoon
added
2026
Software Architecture: The Hard Parts
Summary of ChangesHello @chichoon, 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주차 학습 내용을 정리한 문서입니다. 1장에서는 아키텍처의 기본 개념, 아키텍트의 역할, 데이터의 중요성, 아키텍처 결정 기록(ADR), 그리고 아키텍처의 건전성을 평가하는 피트니스 함수에 대해 다루고 있습니다. 2장에서는 아키텍처 퀀텀의 정의와 마이크로서비스 환경에서의 적용, 그리고 퀀텀 간의 커플링 트레이드오프를 설명하며, 각 개념에 대한 저자의 생각과 논의점들을 함께 제시하고 있습니다. 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
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
| - 데이터는 아키텍처를 넘어서서, 소프트웨어의 모든 것이라고 볼 수 있음 | ||
| - 어떻게 하면 특정 데이터를 효율적, 효과적으로 다룰 수 있는지가 소프트웨어의 목표라고 할 수 있음? | ||
| - 수익과 직결 | ||
| - 운영 데아터: 비즈니스 활동에 사용되는 데이터 (소비자와 직접적으로 연결) |
There was a problem hiding this comment.
'운영 데아터'에 오타가 있는 것 같습니다. '운영 데이터'로 수정하면 내용이 더 명확해질 것입니다.
| - 운영 데아터: 비즈니스 활동에 사용되는 데이터 (소비자와 직접적으로 연결) | |
| - 운영 데이터: 비즈니스 활동에 사용되는 데이터 (소비자와 직접적으로 연결) |
| # 따로 떼어놓기 | ||
|
|
There was a problem hiding this comment.
문서의 첫 부분에 있는 '# 따로 떼어놓기' 제목은 전체 내용과 직접적인 관련이 없어 보입니다. 문서의 명확성을 높이기 위해 이 부분을 제거하고 '## Chapter 02: 아키텍처 퀀텀'으로 시작하는 것이 더 좋을 것 같습니다.
| - 옛날에는 중앙 집중식 체제가 강세였다면, 오픈소스의 대두와 함께 요즘은 마이크로서비스 인프라를 쉽게 구축할 수 있게 된 것처럼 | ||
|
|
||
| ``` | ||
| 논의점: 오픈소스 혁명처럼, 2023년경 챗지피티를 필두로 한 LLM 인공지능의 범람으로 새로운 패러다임이 또 등장하고 있진 않을까? AI와 아키텍처를 긴밀하게 엮을 수 있다면 어떤 부분이 있을지? |
There was a problem hiding this comment.
수동 피트니스 함수에 AI를 도입하여 도움을 받을 수 있을 것 같습니다.
There was a problem hiding this comment.
대략적으로, 제가 기대하는 부분은 아래와 같습니다
- 트레이드 오프 상황에서, AI를 활용해서 의사결정에 도움을 받는 것
- 아키텍쳐 결정 시, 여러가지 안이 있을 때 빠르게 POC(Proof Of Concept)를 만들어서 테스트해볼 수 있는 것
- 아키텍쳐 피트니스 함수 같은 일종의 제약사항으로, AI Agent로 코딩할 때 비결정적인 부분을 결정적으로 활용해볼 수 있는 용도
그 외에도 무궁무진 하지 않을까 생각됩니다(여기서 부턴 상상력과 창의력의 영역..)
| - 개발자들이 아키텍처를 정확하게 이해하고 있지 않거나, 자동화 도구를 사용할 때 발생하는 부작용 등을 방지 | ||
|
|
||
| ``` | ||
| 논의점: 피트니스 함수 등 아키텍처 테스트를 위한 도구를 적절하게 도입한 예시가 있을지? 일단 저희 팀은 모르겠습니다. 별도의 도구 없이 개발자들 간의 합의와 믿음으로 진행되는듯. |
There was a problem hiding this comment.
책에서 나온 ArchUnit 은 공부할 때 한 번 사용해 본적은 있지만 실무에서는 사용하지 않습니다. 다만 적용한다면 의존성 문제와 같이 정적인 부분은 신경쓰지 않아도 되니 좋을 것 같습니다.
|
|
||
| ``` | ||
| 논의점: 피트니스 함수 등 아키텍처 테스트를 위한 도구를 적절하게 도입한 예시가 있을지? 일단 저희 팀은 모르겠습니다. 별도의 도구 없이 개발자들 간의 합의와 믿음으로 진행되는듯. | ||
| 단순 유닛 테스트 기반 CI/CD 자동화도 아키텍처 테스트 도구라고 볼 수 있을지? '아키텍처가 흐트러지는 것을 방지하는' 피트니스 함수의 범위는 어디까지일까? |
There was a problem hiding this comment.
단순 유닛 테스트 기반 CI/CD 자동화도 아키텍처 테스트 도구라고 볼 수 있을지?
CI 단계에 시스템의 구조적 무결성과 아키텍처 특성을 검증한다면 아키텍처 테스트라고 얘기할 수 있을 것 같습니다.
chichoon
requested review from
GeunJuLEE,
TaeHyoungKwon,
benscookie,
dhlee3994,
jongfeel,
tttghost and
ymkim97
| - 옛날에는 중앙 집중식 체제가 강세였다면, 오픈소스의 대두와 함께 요즘은 마이크로서비스 인프라를 쉽게 구축할 수 있게 된 것처럼 | ||
|
|
||
| ``` | ||
| 논의점: 오픈소스 혁명처럼, 2023년경 챗지피티를 필두로 한 LLM 인공지능의 범람으로 새로운 패러다임이 또 등장하고 있진 않을까? AI와 아키텍처를 긴밀하게 엮을 수 있다면 어떤 부분이 있을지? |
There was a problem hiding this comment.
대략적으로, 제가 기대하는 부분은 아래와 같습니다
- 트레이드 오프 상황에서, AI를 활용해서 의사결정에 도움을 받는 것
- 아키텍쳐 결정 시, 여러가지 안이 있을 때 빠르게 POC(Proof Of Concept)를 만들어서 테스트해볼 수 있는 것
- 아키텍쳐 피트니스 함수 같은 일종의 제약사항으로, AI Agent로 코딩할 때 비결정적인 부분을 결정적으로 활용해볼 수 있는 용도
그 외에도 무궁무진 하지 않을까 생각됩니다(여기서 부턴 상상력과 창의력의 영역..)
| - 개발자들이 아키텍처를 정확하게 이해하고 있지 않거나, 자동화 도구를 사용할 때 발생하는 부작용 등을 방지 | ||
|
|
||
| ``` | ||
| 논의점: 피트니스 함수 등 아키텍처 테스트를 위한 도구를 적절하게 도입한 예시가 있을지? 일단 저희 팀은 모르겠습니다. 별도의 도구 없이 개발자들 간의 합의와 믿음으로 진행되는듯. |
There was a problem hiding this comment.
저희 팀도 사례는 없는데, 꼭 필요하다고 느끼지 못해서 그랬던거 같습니다
|
|
||
| ``` | ||
| 논의점: 피트니스 함수 등 아키텍처 테스트를 위한 도구를 적절하게 도입한 예시가 있을지? 일단 저희 팀은 모르겠습니다. 별도의 도구 없이 개발자들 간의 합의와 믿음으로 진행되는듯. | ||
| 단순 유닛 테스트 기반 CI/CD 자동화도 아키텍처 테스트 도구라고 볼 수 있을지? '아키텍처가 흐트러지는 것을 방지하는' 피트니스 함수의 범위는 어디까지일까? |
There was a problem hiding this comment.
단순 유닛 테스트 기반 CI/CD 자동화도 아키텍처 테스트 도구라고 볼 수 있을지?
단순 유닛 테스트 기반 CI/CD의 목적을 생각해보면, 아키텍쳐 레벨보단, 애플리케이션 레벨에서 예상된 비즈니스로직을 체크하는게 목적이기 때문에, 아키텍처 테스트 도구라고 보기엔 힘들지 않을까 라는 생각 입니다
There was a problem hiding this comment.
'아키텍처가 흐트러지는 것을 방지하는' 피트니스 함수의 범위는 어디까지일까?
쉽게 생각하면 애플리케이션 레벨의 비즈니스 로직 외 모두 라고 볼 수 있을거 같습니다
어렵네요 한 페이지를 5번씩 읽은 것 같습니다