소프트웨어 아키텍처 The Hard Parts 1주차 - 김지수 #581
Conversation
tttghost
added
2026
Software Architecture: The Hard Parts
|
우측에 있는 |
Summary of ChangesHello @tttghost, 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장 내용을 요약한 새로운 문서를 추가합니다. 이 문서는 소프트웨어 아키텍처의 핵심 개념들을 다루며, 아키텍처 검증의 자동화 및 수동 검토에 대한 실무적 논의를 제안하여 팀원들의 경험 공유를 장려합니다. 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}
| 하드파트: 어렵다와 단단하다의 뜻 | ||
| 아키텍처 설계는 한번 정해놓으면 쉽사리 바꿀 수 없게 되기에 그만큼 근본적이다. | ||
| 마이크로서비스: 나는 해당하는 부분이 없지만 서버팀에서 서버 설계 시 각 파트별로 나눠서 작업했던 걸 본 기억이 있다 | ||
|
|
||
| 오케스트레이션 | ||
| 여러 서비스 호출의 순서, 성공/실패 판단, 보상 동작까지 하나의 흐름으로 책임지는 중앙 제어 로직 | ||
|
|
||
| 데이터는 모든 것: 데이터 설계가 가장 중요하다. | ||
| 운영데이터와 분석데이터가 있다. | ||
| 운영데이터는 회사 시스템이 돌아가는 데 필요한 데이터다. 정합성, 트랜잭션이 중요 | ||
| 분석데이터는 서비스를 이해, 개선, 판단을 위한 데이터로 트랜잭션과 무관하며 과거 누적 축적형 데이터로 현재 운영에 필요하진 않지만 장기적인 전략 수립 및 의사결정에 중요하게 활용되는 데이터다. | ||
|
|
||
| 아키텍처 거버넌스 | ||
| 시스템이 커져도 방향을 잃지 않게 하는 '기술 헌법'이다. | ||
| 잘못 이해한 경우 = 통제 지옥 | ||
| 잘 이해한 경우 = 자유를 유지하기 위한 최소 규칙 | ||
|
|
||
| 아키텍처 피트니스 함수 | ||
| 관리해주는 함수. 피트니스 클럽은 몸을 관리해주지만 피트니스 함수는 아키텍처를 관리해준다. | ||
| 필연적으로 트레이드오프가 발생할 수밖에 없다. 더 빠르게-더 정확하게, 더 강하게-더 가볍게 등 | ||
| 목표가 하나라면 상관없지만 둘 이상이면 바로 트레이드오프가 발생한다. | ||
|
|
||
| 피트니스 함수와 단위테스트는 비슷하지만 다르다. | ||
| 비슷한 부분은 자동 검증 + 실패 시 즉시 차단이라는 것인데 | ||
| 피트니스 함수는 아키텍처의 특성을 검증하는 것이고 | ||
| 단위테스트는 로직의 정확성을 보는 것이다. 즉 도메인 로직을 본다. | ||
|
|
||
| 코드 위생 도구인 소나큐브는 피트니스 함수의 재료를 턴키 방식으로 제공한다. | ||
| 자바 진영의 아크유닛이라는 도구는 소나큐브와 다르게 경고 수준이 아닌 | ||
| "이 구조는 금지"라는 규칙을 테스트로 정의해 차단할 수 있다. | ||
| 닷넷 진영에도 넷아크테스트(NetArchTest)라는 도구가 있다. | ||
|
|
||
| 피트니스 함수는 대부분 반복/자동화해 사용하지만 간혹 수동으로 실행해야 하는 경우도 있다. | ||
| 민감한 법률 정보가 담긴 시스템은 합법성을 준수해야 하기에 변호사가 직접 검토해야 하므로 자동화할 수가 없다. | ||
|
|
||
| 이런 아키텍처 피트니스 함수가 중요한 이유는 엔터프라이즈 수준의 거버넌스 사례를 볼 때 지속적으로 체크해야 하는 영역이기 때문이다. | ||
| 제로데이 익스플로잇이 발견될 수도 있지만, 지속적인 피트니스 함수로 구조, 의존성, 권한 경계 등을 체크한다면 그 확산과 피해를 최소화할 수 있다. | ||
|
|
||
| 피트니스 함수는 아키텍처 구조를 설계하는 사람에게 단비 같은 존재이다. | ||
| 모든 코드를 직접 많이 볼 수는 없지만(코드의 디테일이 아니라 구조의 방향성을 보기 위함), 피트니스 함수를 통해 프로젝트의 구조와 상태를 검증할 수 있기 때문에 해당 프로젝트의 전반적인 방향성을 잡을 수 있다. | ||
|
|
||
| 하지만 피트니스 함수의 과용은 금물이다. | ||
| 너무 복잡한 피트니스 함수는 오히려 설계 의도를 흐리고, 개발자에게 '무엇을 지켜야 하는지'를 모호하게 만든다. | ||
|
|
||
| 아키텍처와 설계는 구분되어야 한다. | ||
| 아키텍처 결정 - 구조 설계 | ||
|
|
||
| 아키텍처의 기본 원칙을 이해할 때는 How보다 Why가 더 중요하다. | ||
| 아키텍처 개념에 집중하면 구현부에 대한 상세한 이야기는 과감히 건너뛸 수 있다. | ||
| 구현 과정을 일일이 따라가기 시작하면 논의 범위가 지나치게 방대해지기 때문이다. | ||
|
|
||
| 아키텍처의 개념들은 다음과 같이 볼 수 있다. | ||
| 서비스, 커플링, 컴포넌트, 동기통신, 비동기통신, 오케스트레이션, 코레오그래피(오케스트레이션과 반대), 원자성, 컨트랙트(계약) 등이 있다. | ||
|
|
||
| 사가(Saga)는 영웅적인 업적을 기리는 긴 이야기라는 의미에서 유래했다. | ||
| 결제 서비스와 배송 서비스가 있을 때, 결제 서비스는 성공했지만 배송 서비스가 실패한 경우, 오케스트레이션 사가를 통해 결제 취소라는 보상 트랜잭션을 실행하여 사가를 실패 상태로 종료한다. |
There was a problem hiding this comment.
책의 주요 내용을 정리한 부분의 가독성을 높이기 위해 목록(bullet points)을 사용하는 것을 제안합니다. 각 항목을 - 또는 * 로 시작하는 목록 항목으로 만들고, 관련된 내용은 들여쓰기를 통해 하위 목록으로 구성하면 내용을 구조화하고 파악하기 쉽게 만들 수 있습니다.
예를 들어, 데이터에 대한 부분을 다음과 같이 변경할 수 있습니다:
- **데이터**: 데이터 설계가 가장 중요합니다.
- **운영 데이터**: 시스템 운영에 필요한 데이터로, 정합성과 트랜잭션이 중요합니다.
- **분석 데이터**: 서비스 이해, 개선, 판단을 위한 과거 누적 데이터입니다. 트랜잭션과 무관하며 장기적인 전략 수립에 활용됩니다.전체적으로 이런 형식을 적용하면 요약 내용을 더 명확하게 전달할 수 있을 것입니다. 전체 변경 사항을 코드 제안으로 남겨두었으니 참고해주세요.
- **하드파트**: '어렵다'와 '단단하다'는 두 가지 의미를 가집니다.
- **아키텍처 설계**: 한번 정해놓으면 바꾸기 어려워 근본적인 결정입니다.
- **마이크로서비스**: 개인적인 경험은 없지만, 서버팀에서 각 파트를 나눠 설계하는 것을 본 적이 있습니다.
- **오케스트레이션**: 여러 서비스 호출의 순서, 성공/실패 판단, 보상 동작까지 하나의 흐름으로 책임지는 중앙 제어 로직입니다.
- **데이터**: 데이터 설계가 가장 중요합니다.
- **운영 데이터**: 시스템 운영에 필요한 데이터로, 정합성과 트랜잭션이 중요합니다.
- **분석 데이터**: 서비스 이해, 개선, 판단을 위한 과거 누적 데이터입니다. 트랜잭션과 무관하며 장기적인 전략 수립에 활용됩니다.
- **아키텍처 거버넌스**: 시스템이 커져도 방향을 잃지 않게 하는 '기술 헌법'입니다.
- 잘못 이해한 경우: 통제 지옥
- 잘 이해한 경우: 자유를 유지하기 위한 최소한의 규칙
- **아키텍처 피트니스 함수**: 아키텍처를 관리하고 검증하는 함수입니다.
- **트레이드오프**: 목표가 둘 이상일 때 필연적으로 발생합니다. (예: 더 빠르게 vs 더 정확하게)
- **피트니스 함수 vs 단위 테스트**:
- **공통점**: 자동 검증, 실패 시 즉시 차단
- **차이점**:
- 피트니스 함수: 아키텍처 특성 검증
- 단위 테스트: 도메인 로직의 정확성 검증
- **피트니스 함수 도구**:
- **소나큐브(SonarQube)**: 피트니스 함수의 재료를 턴키 방식으로 제공합니다.
- **아크유닛(ArchUnit)** (Java): 경고 수준을 넘어 "이 구조는 금지"와 같은 규칙을 테스트로 정의하여 강제할 수 있습니다.
- **넷아크테스트(NetArchTest)** (.NET): 닷넷 진영의 유사한 도구입니다.
- **피트니스 함수 실행**:
- 대부분 자동화되지만, 수동 검토가 필요한 경우도 있습니다.
- 예: 민감한 법률 정보가 포함된 시스템의 합법성 준수는 변호사가 직접 검토해야 합니다.
- **피트니스 함수의 중요성**:
- 엔터프라이즈 거버넌스에서 지속적인 체크가 필요합니다.
- 제로데이 익스플로잇 같은 보안 취약점 발견 시, 구조, 의존성, 권한 경계 등을 지속적으로 검사하여 피해 확산을 최소화할 수 있습니다.
- 아키텍트가 모든 코드를 보지 않고도 프로젝트의 구조와 상태를 검증하고 방향성을 잡는 데 도움을 줍니다.
- **피트니스 함수 사용 시 주의점**:
- 과용은 금물입니다. 너무 복잡한 함수는 설계 의도를 흐리고 개발자에게 혼란을 줄 수 있습니다.
- **아키텍처 vs 설계**:
- 아키텍처 결정은 구조 설계에 해당하며, 둘은 구분되어야 합니다.
- **아키텍처 원칙**:
- 'How'보다 'Why'가 더 중요합니다.
- 구현 상세보다는 개념에 집중해야 논의 범위가 방대해지는 것을 막을 수 있습니다.
- **주요 아키텍처 개념**:
- 서비스, 커플링, 컴포넌트, 동기/비동기 통신, 오케스트레이션, 코레오그래피, 원자성, 컨트랙트(계약) 등
- **사가(Saga) 패턴**:
- '영웅적인 업적을 기리는 긴 이야기'에서 유래했습니다.
- 예: 결제는 성공했으나 배송이 실패한 경우, 오케스트레이션 사가를 통해 '결제 취소'라는 보상 트랜잭션을 실행하여 일관성을 유지합니다.| ## 논의 주제: 아키텍처 검증의 자동화와 수동 검토 | ||
| 피트니스 함수에서 자동화한 부분(소나큐브, 아크유닛 등)과 수동으로 검토해야 하는 부분이 | ||
| 있다고 나오는데 실무에서 이 두 부분에 대한 경험이 있으신가요? | ||
|
|
||
| 어떤 것을 자동화하였고 어떤 것을 왜 사람이 직접 해야 했는지 궁금합니다. No newline at end of file |
There was a problem hiding this comment.
CI/CD 파이프라인에서 자동수행되는 소나큐브로 정적분석하는 것이 일종의 피트니스 함수를 적용한거라고 가정했을 때, 이부분에 대한 실무 경험은 있습니다 이걸 적용하는 이유는 작성한 코드를 PR 리뷰 시기에 정적분석 결과까지 같이 확인하기 위함으로 하고, 소나큐브에 세팅된 정책에 따라서, 알아서 판단해서 결과를 줄것이고, 이걸 보고 판단해서 수정하는것은 리뷰이(reviewee)의 몫이기 때문에 자동화 해도 문제 없다고 생각 됩니다
그 외 수동으로 검토해야하는 부분은 책에는 민감한 법률정보가 담긴 시스템 사례가 나오는데 실제 실무에서는 적용해본적은 없습니다
자동으로 해도되냐, 수동으로 해야하냐의 차이는 자동으로 했을 때의 영향도가 어떻냐에 따라서 다를것 같네요 (LLM 모델을 통한 바이브코딩을 할 때, yolo모드를 어떤 경우에 쓸것이냐?와 비슷한 맥락에서 이해해볼 수 있을거 같습니다)
jongfeel
left a comment
jongfeel
left a comment
There was a problem hiding this comment.
좋은 감상평과 함께 내용 정리도 잘 해주셨네요.
적어도 내일 까지는 chatper 3를 올려주셔야 리뷰를 해 드릴 수 있는데, 그렇게 해 주실꺼죠? ㅎㅎ
| ## 논의 주제: 아키텍처 검증의 자동화와 수동 검토 | ||
| 피트니스 함수에서 자동화한 부분(소나큐브, 아크유닛 등)과 수동으로 검토해야 하는 부분이 | ||
| 있다고 나오는데 실무에서 이 두 부분에 대한 경험이 있으신가요? | ||
|
|
||
| 어떤 것을 자동화하였고 어떤 것을 왜 사람이 직접 해야 했는지 궁금합니다. No newline at end of file |
There was a problem hiding this comment.
책에도 예시가 나오긴 하지만 수동 검토라는 건 자동화 할 수 없는 부분이라고 보는데
사실 저는 이 부분에서 AI에게 맡기면 해결되지 않을까? 라는 생각도 해봤습니다.
이 책의 번역본 출간 시점이 2022년 10월 1일이고
원서 출간 시점은 2021년 11월 30일 입니다.
ChatGPT가 나오기 전 LLM이 2020~2021년 쯤 유행했으니 이 책을 썼을 시점에는 ChatGPT가 없던 시대였습니다.
그러므로 수동 검토를 사람이 해야 한다고 한거라 생각합니다.
지금 시점이라면 수동 검토가 필요한 부분도 문맥을 이해하고 검토 결과를 내주는 ChatGPT를 사용했겠죠.
만약 이 책의 2nd edition이 나오면 저는 ChatGPT 관련 내용을 추가할 것이라 예상합니다.
그리고 나올 가능성이 높습니다.
왜냐하면 이 책의 전신인 < 소프트웨어 아키텍처 101 > 이 2nd edition으로 < 소프트웨어 아키텍처 The Basic > 으로 나왔기 때문입니다.
There was a problem hiding this comment.
추상화 정도, 회사의 현재 상황에 적절한 아키텍처인지 등 같이 맥락이 포함되는 항목들은 자동화하기 어려운 것 같습니다.
또, "기술 부채"가 미래에 얼마나 치명적일지 예상하여 당장 처리해야 하는지, 전략적으로 남겨둬야 할지 와 같이 수치로 표현 가능하지만 수동 검토가 필요한 케이스도 있을 것 같습니다.
| 분산 아키텍처에 대한 이해도가 한 단계 깊어졌다고 느낀 경험이 있으신지 궁금합니다. | ||
| 예를 들어 처음에는 "기능 단위로 쪼개는 것이 분산 아키텍처지!" 라고 생각했다가, | ||
| 트레이드오프 분석을 거치며 "이 기능들은 오히려 통합하는 편이 좋겠군." 라고 판단하게 된 경우처럼, | ||
| 이와 비슷한 사고의 전환을 직접 경험하신 사례가 있다면 함께 이야기해 보면 좋겠습니다. |
There was a problem hiding this comment.
얘기하신 내용은 도메인 관점에서의 서비스를 얘기하는 것 같은데
꼭 분산 아키텍처여야 할 필요가 없는게
모듈러 모놀리스라는 아키텍처 형태도 있기 때문입니다.
책에 잠깐만 언급되어 있어서 부가적으로 설명을 하면
도메인 관점에서 모듈화를 하고 그걸 모놀리스 형태 내에서 구현하는 방식을 뜻합니다.
우연치 않게 제가 < 헤드퍼스트 소프트웨어 아키텍처 > 책을 읽고 있는데 이 책에 그 내용이 나옵니다.
정말 놀랍게도 < 헤드퍼스트 소프트웨어 아키텍처 > 의 저자도 < 소프트웨어 아키텍처 The Hard Parts > 의 저자와 동일한 마크 리처드와 닐 포드 입니다!
헤드퍼스트 소프트웨어 아키텍처에서 모듈러 모놀리스 관련 챕터 7 정리 내용 링크입니다.
제 생각에는 기능 단위의 분석 통합이라면 결합도와 응집도 쪽에 더 가깝지 않나 하는 생각이 드네요.
어쨌든 아키텍처건 설계건 트레이드오프 관점에서 시야가 점점 넓어지는 건 사실이므로
지식과 경험이 동반된 소프트웨어 시스템의 이해는 훌륭한 개발자가 만들어지는 좋은 방향이라고 생각합니다.
그래서 저도 항상 책을 읽으면서 지식의 폭을 넓히고 실무에서 설계 및 코딩까지 하면서 경험을 쌓는 걸 즐기는 것 같습니다.
네! 곧 감상평 올리겠습니다 ㅎㅎ |
| ## 논의 주제: 아키텍처 검증의 자동화와 수동 검토 | ||
| 피트니스 함수에서 자동화한 부분(소나큐브, 아크유닛 등)과 수동으로 검토해야 하는 부분이 | ||
| 있다고 나오는데 실무에서 이 두 부분에 대한 경험이 있으신가요? | ||
|
|
||
| 어떤 것을 자동화하였고 어떤 것을 왜 사람이 직접 해야 했는지 궁금합니다. No newline at end of file |
There was a problem hiding this comment.
추상화 정도, 회사의 현재 상황에 적절한 아키텍처인지 등 같이 맥락이 포함되는 항목들은 자동화하기 어려운 것 같습니다.
또, "기술 부채"가 미래에 얼마나 치명적일지 예상하여 당장 처리해야 하는지, 전략적으로 남겨둬야 할지 와 같이 수치로 표현 가능하지만 수동 검토가 필요한 케이스도 있을 것 같습니다.
| 분산 아키텍처에 대한 이해도가 한 단계 깊어졌다고 느낀 경험이 있으신지 궁금합니다. | ||
| 예를 들어 처음에는 "기능 단위로 쪼개는 것이 분산 아키텍처지!" 라고 생각했다가, | ||
| 트레이드오프 분석을 거치며 "이 기능들은 오히려 통합하는 편이 좋겠군." 라고 판단하게 된 경우처럼, | ||
| 이와 비슷한 사고의 전환을 직접 경험하신 사례가 있다면 함께 이야기해 보면 좋겠습니다. |
There was a problem hiding this comment.
저의 경우는 실전을 먼저 하고, 이론을 공부하는 느낌을 받았습니다. 느낌상으로 혹은 어설프게 안 상태에서 그냥 사용만 하다가 뭔가 정리가 된 느낌이었습니다.
| ## 논의주제 | ||
| 모듈화 동인을 "찾는다"가 아니라 "맞춘다"고 표현하는 것이 인상적이었습니다. | ||
| 실무에서 아키텍처를 분해하거나 모듈화할 때, 기술적 최적해를 찾는 것과 팀 상황을 고려하는 것 사이에서 어떻게 균형을 맞추셨는지 궁금합니다. | ||
| 예를 들어 "기술적으로는 A가 맞지만 팀 역량상 B로 갔다"거나, "당장은 모놀리식이지만 확장 여지를 남겨뒀다" 같은 경험이 있으신가요? |
There was a problem hiding this comment.
늘 그렇듯 현재의 최적해가 있고, 미래의 최적해가 있고, 리소스적 측면의 최적의 해가 있고, 장애요소나 개발속도 혹은 확장속도를 위한 최적의 해 등등 여러 최적의 해가 있을거 같습니다.
저의 경우, 먼 미래의 최적의 해(장애 최소화, 모듈로 개발 속도 상승 등 여러 이점을 가진 최적의 아키텍처. 이 책에서 말하는 MSA라고 생각)를 찾고, 그 최적의 해를 달성하기 위한 과정 중 현재의 최적의 해를 찾아 적용하는 과정을 많이 했습니다.
예를 들면 MSA를 하고 는 싶지만 현재 불가능한걸 알기 때문에 미래에 MSA를 위한 밑작업 등을 했습니다(https://github.com/ThinkAboutSoftware/AcademicConference/pull/579/files 하단에 개인적인 경험을 작성했습니다).
| 모듈화 동인을 "찾는다"가 아니라 "맞춘다"고 표현하는 것이 인상적이었습니다. | ||
| 실무에서 아키텍처를 분해하거나 모듈화할 때, 기술적 최적해를 찾는 것과 팀 상황을 고려하는 것 사이에서 어떻게 균형을 맞추셨는지 궁금합니다. | ||
| 예를 들어 "기술적으로는 A가 맞지만 팀 역량상 B로 갔다"거나, "당장은 모놀리식이지만 확장 여지를 남겨뒀다" 같은 경험이 있으신가요? |
There was a problem hiding this comment.
기술적 최적해를 찾는 방향으로 하고 나중에 어떻게 변화를 줄지에 대한 고민도 함께 했던 것 같습니다.
보통 아키텍처 결정은 나중에 크게 바뀌는 일이 없기 때문에 현재 맞는 방향으로 했었던 것 같네요.
나중을 위해 뭔가를 한다는 것도 나중에 안하게 될 거라는 가정 없이 하면 리소스 낭비가 되기에
저는 되도록 현재 해결할 수 있는 방법 중에서 가장 좋은 방법을 선택하는 걸로 결정합니다.
| 실무에서 아키텍처를 분해하거나 모듈화할 때, 기술적 최적해를 찾는 것과 팀 상황을 고려하는 것 사이에서 어떻게 균형을 맞추셨는지 궁금합니다. | ||
| 예를 들어 "기술적으로는 A가 맞지만 팀 역량상 B로 갔다"거나, "당장은 모놀리식이지만 확장 여지를 남겨뒀다" 같은 경험이 있으신가요? |
There was a problem hiding this comment.
아무래도 팀 일정에 크게 좌우됐던 것 같습니다...
팀 전체가 빠듯할 때는 팀 상황 (코드 상황) 에 맞춰 타협하는 경우가 대부분이었고 크리티컬한 버그가 발생하지 않는 선에서만 짬짬이 분리작업만 해두었다가 여유가 생기면 다같이 이런저런 시행착오도 겪어보고 모듈화 했다가 합쳐도 보고 최적의 방법을 찾기 위한 여정을...
책 내용이 생각보다 어렵네요.