Antigravity Agent
161 lines
23 KiB
Markdown
161 lines
23 KiB
Markdown
---
|
|
category: Unified
|
|
tags: [auto-consolidated, technical-documentation]
|
|
title: [[Software Architecture]]
|
|
last_updated: 2026-05-02
|
|
---
|
|
|
|
# [[Software Architecture]]
|
|
|
|
## 📌 Brief Summary
|
|
소프트웨어 아키텍처(Software Architecture)는 시스템을 추론하고 구축하는 데 필요한 청사진이자 기본적인 구조들의 집합으로, 소프트웨어 요소와 이들 간의 관계, 그리고 환경과 설계 원칙을 포함합니다 [1, 2]. 이는 시스템 구현 후 변경 비용이 매우 높기 때문에 시스템 개발 초기에 내려져야 하는 가장 전략적이고 핵심적인 결정의 집합입니다 [2, 3]. 적절한 아키텍처 패턴을 채택함으로써 시스템은 확장성, 유지보수성, 보안 및 내결함성과 같은 주요 품질 속성(Quality Attributes)을 확보하고 비즈니스 목표를 달성할 수 있습니다 [4-6].
|
|
|
|
---
|
|
|
|
소프트웨어 아키텍처는 시스템의 근본적인 구조와 청사진을 의미하며, 소프트웨어 요소와 그들 간의 관계 및 속성을 정의하는 거시적인 설계 규율입니다[1], [2], [3]. 이는 시스템의 확장성, 유지보수성, 성능, 보안 등의 품질 속성을 보장하기 위한 뼈대 역할을 하며, 개발 프로젝트 관리와 의사소통의 기준이 됩니다[4], [5], [6]. 아키텍처는 초기 설계 단계에서 결정되고 한 번 구현되면 변경 비용이 매우 높으므로, 비즈니스 목적과 트레이드오프(Trade-off)를 고려한 신중한 선택이 필수적입니다[7], [3].
|
|
|
|
## 📖 Core Content
|
|
* **소프트웨어 아키텍처의 본질 및 범위**
|
|
소프트웨어 아키텍처는 시스템이 요구하는 기능적 요구사항과 성능, 신뢰성, 확장성, 보안 등의 비기능적 요구사항(품질 속성)이 구조적으로 어떻게 실현되는지에 초점을 맞춥니다 [5, 7]. 이는 거시적인 시스템 구조를 정의하는 반면, 소프트웨어 디자인 패턴은 개별 컴포넌트나 클래스 내부의 특정 문제를 해결하는 미시적인 솔루션이라는 점에서 차별화됩니다 [8-10]. 아키텍처는 시스템 구조뿐만 아니라, 그러한 구조적 선택을 이끈 아키텍처 결정(Architectural Decisions)과 그에 대한 근거(Rationale)의 집합을 모두 포함합니다 [11].
|
|
|
|
* **아키텍처 결정 및 평가 방법론**
|
|
적절한 아키텍처 패턴은 단순한 유행이 아니라 명확한 품질 요구사항을 기반으로 선택되어야 합니다 [6]. ISO/IEC 25010과 같은 품질 모델을 이용해 기능 적합성, 성능 효율성, 호환성 등을 우선순위화합니다 [6, 12]. 이후 ATAM(Architecture Tradeoff Analysis Method)과 같은 방법론을 통해 시나리오 기반으로 각 구조의 장단점(Trade-offs)과 리스크를 면밀히 분석하고, 프로토타이핑을 통해 조기 검증을 수행합니다 [13-15]. 이러한 모든 설계 결정 사항은 ADR(Architecture Decision Record)을 통해 맥락과 대안, 결과를 꼼꼼히 문서화하여 향후 시스템이 진화하더라도 의사결정의 근거를 보존해야 합니다 [16-18].
|
|
|
|
* **주요 아키텍처 패턴 및 특성**
|
|
현대 소프트웨어 공학에서 활용되는 대표적인 패턴은 다음과 같습니다.
|
|
* **계층형 아키텍처(Layered Pattern):** 프레젠테이션, 비즈니스, 데이터 계층 등 수평적으로 책임을 분리하여 유지보수성과 테스트 용이성을 높이는 가장 고전적이고 친숙한 모델입니다 [19, 20].
|
|
* **클라이언트-서버 및 P2P(Client-Server & P2P):** 중앙 서버가 자원과 데이터 제어를 전담하는 클라이언트-서버와 달리, P2P는 모든 노드가 클라이언트이자 서버 역할을 동시에 수행하여 중앙 서버의 병목과 단일 장애점(SPOF)을 제거합니다 [21-23].
|
|
* **마이크로서비스 아키텍처(Microservices Pattern):** 애플리케이션을 작고 독립적으로 배포 가능한 비즈니스 도메인 서비스들의 집합으로 분할하여(주로 '서비스당 데이터베이스' 원칙 사용), 빠른 배포 파이프라인과 극대화된 수평적 확장성을 제공합니다 [24-26].
|
|
* **이벤트 기반 아키텍처(Event-Driven Pattern):** 상태 변화(이벤트)를 비동기적으로 생산하고 소비하는 구조로, 극단적으로 낮은 결합도(Loose Coupling)와 대용량 트래픽의 실시간 처리에 최적화되어 있습니다. 브로커(Broker)와 메디에이터(Mediator) 토폴로지로 나뉩니다 [27-29].
|
|
* **마이크로커널 아키텍처(Microkernel Pattern):** 최소한의 핵심 기능을 담은 코어 시스템에 특화된 플러그인 모듈들을 결합하여 유연한 기능 확장성을 제공합니다 [30, 31].
|
|
* **도메인 중심 아키텍처(Hexagonal, Clean, Onion):** 의존성 방향을 내부의 비즈니스 로직으로 향하게 만들어 데이터베이스, UI 등 기술적 세부사항으로부터 핵심 도메인을 완벽히 격리하는 의존성 역전을 실현합니다 [32].
|
|
* **공간 기반 아키텍처(Space-Based Pattern):** 관계형 데이터베이스의 병목을 없애기 위해 메모리 내 데이터 그리드(In-memory Data Grid)를 분산 공유하여 동시성과 대규모 부하를 처리합니다 [33, 34].
|
|
|
|
---
|
|
|
|
* **아키텍처의 본질과 원칙**
|
|
소프트웨어 아키텍처는 "모든 것은 트레이드오프다(Everything is a trade-off)"와 "어떻게(how)보다 왜(why)가 더 중요하다"는 두 가지 근본 법칙을 따릅니다[7]. 아키텍처 설계는 단순한 기술적 트렌드가 아니라 시스템이 해결해야 할 비즈니스 목적, 부하 프로필, 그리고 ISO/IEC 25010과 같은 표준 기반의 품질 요구사항(성능 효율성, 호환성, 상호작용 능력 등)에 맞춰 결정되어야 합니다[8], [9].
|
|
* **아키텍처 패턴(Architecture Pattern) vs 디자인 패턴(Design Pattern)**
|
|
아키텍처 패턴과 디자인 패턴은 흔히 혼용되나 적용 범위가 다릅니다. 아키텍처 패턴은 마이크로서비스, 계층형, 이벤트 기반 아키텍처 등 전체 시스템의 구조와 컴포넌트 간 상호작용을 다루는 거시적(Macro-level) 솔루션입니다[10], [11], [3]. 반면, 디자인 패턴(예: 싱글톤, 팩토리 패턴)은 단일 모듈이나 클래스 내에서 발생하는 반복적인 문제를 해결하는 미시적(Micro-level) 솔루션입니다[12], [3].
|
|
* **핵심 아키텍처 활동 (Core Architecture Activities)**
|
|
아키텍처 설계는 네 가지 반복적인 핵심 활동을 포함합니다[13]. 요구사항을 수집하고 아키텍처에 유의미한 영향을 미치는 요소를 파악하는 '분석(Analysis)', 도출된 요구사항을 바탕으로 설계를 창조하는 '합성/설계(Synthesis)', ATAM(Architecture Tradeoff Analysis Method) 등의 기법을 이용해 설계가 요구사항을 충족하는지 평가하는 '평가(Evaluation)', 그리고 환경 변화에 맞춰 시스템을 유지보수하고 적응시키는 '진화(Evolution)'입니다[13], [14], [15].
|
|
* **조직 구조와 콘웨이의 법칙 (Conway's Law)**
|
|
아키텍처 결정은 조직의 형태와 불가분의 관계를 맺습니다. "시스템 설계는 조직의 통신 구조를 모방하게 된다"는 콘웨이의 법칙에 따라, 소프트웨어 아키텍처는 기술적 요구뿐만 아니라 개발 팀의 규모, 역량, DevOps 성숙도 등 조직적 맥락과 완벽히 부합해야 성공적으로 유지될 수 있습니다[16], [17].
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
소프트웨어 아키텍처 결정에는 "모든 것은 트레이드오프(Everything is a trade-off)"라는 제1법칙이 존재하며 완벽한 아키텍처는 없습니다 [3, 14].
|
|
* **분산 시스템의 복잡성과 비용:** 마이크로서비스(MSA)나 이벤트 기반 아키텍처는 뛰어난 자율성과 확장성을 주지만, 분산 트랜잭션 처리(Saga 패턴 등 적용 필요), 네트워크 지연, 비동기 디버깅, 다중 데이터베이스 간의 데이터 최종 일관성(Eventual Consistency) 등 막대한 운영 및 설계 복잡성을 야기합니다 [35-37].
|
|
* **서버리스(Serverless)의 제약:** 서버리스는 인프라 관리 부담을 줄이고 사용량만큼만 비용을 지불하지만, 벤더 종속(Vendor Lock-in) 문제와 함께 일정 시간 비활성화 시 발생하는 콜드 스타트(Cold Start) 지연 시간 문제가 있어 실시간 응답이 필수적인 서비스에는 치명적일 수 있습니다 [38-40].
|
|
* **오버 엔지니어링의 위험:** 작은 규모의 팀이나 단순한 CRUD 애플리케이션에 트렌드라는 이유만으로 MSA를 도입하면 오히려 생산성이 하락할 수 있습니다 [41, 42]. 이 경우 철저히 모듈화된 단일 배포 단위인 모듈형 모놀리스(Modular Monolith)를 채택하는 것이 확장성을 열어두면서 운영 복잡도를 낮추는 훌륭한 대안이 됩니다 [43, 44].
|
|
* **아키텍처 부식(Erosion):** 초기 설계와 실제 구현 코드 사이에 괴리가 생기며 기술 부채가 누적되는 아키텍처 부식 현상이 일어날 수 있으므로, 지속적인 컴플라이언스 체크와 엄격한 ADR 관리가 요구됩니다 [45].
|
|
|
|
---
|
|
|
|
* **성능(Performance) vs 유연성 및 확장성(Flexibility & Scalability)**
|
|
모놀리식이나 계층형(Layered) 아키텍처는 초기 개발이 빠르고 하나의 코드베이스에서 관리되므로 특정 환경에서는 성능적 이점이 있으나, 시스템이 커질수록 잦은 변경과 부분적인 확장이 불가능해지는 한계가 있습니다[18], [19]. 반대로 마이크로서비스 아키텍처(MSA)나 이벤트 기반 아키텍처(EDA)는 구성 요소를 분리하여 유연성과 수평적 확장성을 극대화하지만, 서비스 간 네트워크 통신 오버헤드, 복잡한 디버깅, 분산 데이터 일관성(Eventual Consistency) 관리라는 막대한 운영 복잡성 비용을 치러야 합니다[20], [21], [22].
|
|
* **아키텍처 침식 (Architecture Erosion)**
|
|
소프트웨어 개발 수명 주기가 진행됨에 따라, 의도했던 아키텍처와 실제로 구현된 아키텍처 간의 격차가 벌어지는 '아키텍처 침식'이 발생할 수 있습니다[23]. 이는 기술 부채의 축적, 아키텍처 규칙 위반, 지식의 증발 등으로 인해 발생하며, 결과적으로 시스템의 성능을 저하시키고 유지보수 비용을 기하급수적으로 증가시킵니다[24].
|
|
* **의사결정의 지연과 분석 마비 (Analysis Paralysis)**
|
|
잘못된 아키텍처를 선택할 것에 대한 두려움으로 인해 설계 결정을 미루는 안티패턴(Anti-pattern)이 발생할 수 있습니다. 이는 개발 진행을 방해하므로, 적절한 피드백 수용과 함께 "마지막 책임 순간(last responsible moment)"에 결정을 내리고, 프로토타이핑을 통해 조기에 리스크를 검증해야 합니다[25], [26].
|
|
|
|
## 🔗 Knowledge Connections
|
|
### Related Concepts
|
|
|
|
#### [아키텍처 설계 사상 및 패러다임]
|
|
- [[마이크로서비스 아키텍처 (Microservices Architecture)]]
|
|
- 연결 이유: 현대 엔터프라이즈급 확장성과 애자일한 조직 구조를 지원하는 핵심 아키텍처 패턴입니다 [46, 47].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 독립적인 배포 파이프라인 구성, 도메인 분리, 서비스 간 비동기 메시징 기반 협업, 그리고 마이크로서비스 섀시 및 API 게이트웨이 등의 분산 컴포넌트 전략.
|
|
|
|
- [[이벤트 기반 아키텍처 (Event-Driven Architecture)]]
|
|
- 연결 이유: 시스템의 결합도를 극한으로 낮추고 실시간 데이터 스트리밍과 높은 동시성을 처리하기 위해 활용되는 아키텍처입니다 [28, 48].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브로커(Choreography) 방식과 메디에이터(Orchestration) 방식의 통제 수준 차이, 큐(Queues)와 스트림(Streams)을 활용한 이벤트 관리 메커니즘과 상태 회복.
|
|
|
|
- [[헥사고날 아키텍처 (Hexagonal Architecture / Ports and Adapters)]]
|
|
- 연결 이유: 비즈니스 핵심 로직을 데이터베이스 및 프레임워크와 같은 기술적 세부사항으로부터 완벽히 보호하는 아키텍처 지침입니다 [32, 49].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 포트(Port)와 어댑터(Adapter)를 이용한 의존성 역전 원칙, 뛰어난 테스트 용이성, 그리고 클린 아키텍처 및 어니언 아키텍처와의 구조적 상호작용.
|
|
|
|
#### [아키텍처 의사결정 및 검증 도구]
|
|
- [[ATAM (Architecture Tradeoff Analysis Method)]]
|
|
- 연결 이유: 아키텍처가 품질 요구사항에 얼마나 잘 부합하는지 평가하고 트레이드오프를 체계화하는 평가 방법론입니다 [13, 14].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 시스템의 민감도와 잠재적 리스크를 시나리오 기반으로 도출하여, 아키텍처 결정이 조직의 비즈니스 목표에 미치는 영향을 객관화하는 절차.
|
|
|
|
- [[ADR (Architecture Decision Records)]]
|
|
- 연결 이유: 아키텍처 결정 사항을 문서화하여 시스템 구조의 유지보수성과 맥락 보존을 지원하는 도구입니다 [16, 17].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 의사결정 당시의 기술적·비즈니스적 배경, 거절된 대안 및 예상 결과를 기록함으로써, 조직의 구조 변경이나 인력 교체 시에도 '설계 의도'가 변질되는 아키텍처 부식(Erosion)을 방지하는 원리.
|
|
|
|
### Deeper Research Questions
|
|
|
|
- 분산 아키텍처(마이크로서비스) 환경에서 데이터베이스가 개별 분리됨에 따라 발생하는 분산 트랜잭션 및 최종 일관성(Eventual Consistency) 문제를 Saga 패턴과 CQRS를 활용하여 어떻게 효과적으로 제어할 수 있는가? [28, 36]
|
|
- 콘웨이의 법칙(Conway's Law)이 조직 구조(팀 크기, 데브옵스 숙련도)와 아키텍처 패턴 결정에 어떠한 영향을 미치며, 성공적인 마이크로서비스 이전을 위해 선행되어야 할 조직적 변화는 무엇인가? [42, 50]
|
|
- 대규모 트래픽을 처리하는 시스템에서 이벤트 기반 아키텍처의 이벤트 스트리밍(예: Kafka)과 공간 기반 아키텍처(Space-Based)의 인메모리 데이터 그리드(IMDG) 방식을 병합(Hybrid)하여 성능을 최적화하는 전략과 그 한계는 무엇인가? [34, 51, 52]
|
|
- 클린 아키텍처 또는 헥사고날 아키텍처의 의존성 규칙이 초기 개발 비용을 상승시킴에도 불구하고 엔터프라이즈 장기 유지보수 및 보안 경계(Security Boundaries) 형성에서 얻는 트레이드오프의 경제적 가치는 어떻게 증명할 수 있는가? [32, 53, 54]
|
|
- 빈번히 변동하는 부하(Burst Workload)를 가진 애플리케이션에 대해, 콜드 스타트를 극복하기 위한 서버리스(Serverless)와 모듈형 모놀리스(Modular Monolith)를 혼합 적용하는 전략적 분기점(Tipping Point)은 어디인가? [55-60]
|
|
|
|
### Practical Application Contexts
|
|
|
|
- **Implementation:** 비즈니스 핵심 로직과 인프라의 결합도를 낮추기 위해 코드베이스 구현 시 헥사고날 아키텍처의 포트(인터페이스)와 어댑터를 적용하여 독립적인 단위 테스트가 가능하게 설계함 [49, 61, 62].
|
|
- **System Design:** C4 모델 등 가벼운 다이어그램 도구를 통해 각 컴포넌트 간 관계와 제약사항을 시각화하고, ATAM을 통해 극단적인 로드(예: 10분 내 사용자 두 배 증가) 시나리오에 대한 시스템 병목을 평가 후 적절한 분산 패턴을 적용 [13, 14, 63].
|
|
- **Operation / Maintenance:** 서킷 브레이커(Circuit Breaker) 패턴을 도입해 마이크로서비스 통신 중 발생하는 연쇄 장애를 격리하고, ADR을 위키에 보관해 새롭게 합류한 데브옵스 팀원들의 온보딩 속도를 높임 [16, 37, 64].
|
|
- **Learning Path:** 단순한 계층형 아키텍처(N-Tier)로 시작하여 시스템 설계의 기초와 관심사의 분리를 배운 뒤, 점진적으로 도메인 주도 설계(DDD)와 비동기 메시지 패싱(EDA), 최종적으로 분산 클라우드 네이티브 패턴(MSA, Serverless) 순으로 확장 학습 [44, 65].
|
|
- **My Project Relevance:** 기한과 자원이 한정된 초기 스타트업 MVP 프로젝트에 마이크로서비스를 무리하게 도입하기보다, 우선 모듈형 모놀리스 혹은 단일 서버리스 기능으로 빠르게 시장 검증을 수행하고 향후 확장을 대비한 모듈 분리(Clean Architecture 적용)를 수행함 [66, 67].
|
|
|
|
### Adjacent Topics
|
|
|
|
- [[도메인 주도 설계 (Domain-Driven Design, DDD)]]
|
|
- 확장 방향: 마이크로서비스 패턴에서 각 서비스를 식별하고 책임을 격리하는 논리적 경계(Bounded Context)를 정의하기 위한 비즈니스 모델링 기법의 연계 탐구 [26].
|
|
- [[소프트웨어 디자인 패턴 (Software Design Patterns)]]
|
|
- 확장 방향: 전체 아키텍처 수준이 아니라 각 계층이나 모듈 내부에서 반복되는 코딩 수준의 구현 문제(객체 생성, 구조, 행위)를 재사용 가능한 방식으로 해결하는 원리 이해 [8].
|
|
|
|
---
|
|
*Last updated: 2026-05-02*
|
|
|
|
---
|
|
|
|
### Related Concepts
|
|
|
|
#### [관계 유형 A: 아키텍처 설계 및 평가 프레임워크]
|
|
- [[ATAM (Architecture Tradeoff Analysis Method)]]
|
|
- 연결 이유: 아키텍처를 시스템의 비즈니스 목표와 품질 속성에 비추어 체계적으로 평가하기 위해 SEI에서 개발한 방법론입니다[27], [28].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 추상적인 요구사항 대신 구체적인 '시나리오'를 활용하여 아키텍처의 트레이드오프(Trade-offs)와 민감점(Sensitivity points), 잠재적 리스크를 분석하는 원리를 이해할 수 있습니다[27], [28].
|
|
|
|
- [[ADR (Architecture Decision Record)]]
|
|
- 연결 이유: 복잡한 시스템 개발에서 아키텍처에 관한 주요 결정 사항을 문서화하는 핵심 도구입니다[29], [30].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 초기 결정의 맥락, 선택 이유, 대안 및 리스크를 명확히 기록하여 시간이 지나거나 팀원이 변경되더라도 아키텍처의 개념적 무결성을 유지하고 아키텍처 침식을 방지하는 방법을 배울 수 있습니다[25], [29].
|
|
|
|
#### [관계 유형 B: 주요 아키텍처 패턴 유형]
|
|
- [[마이크로서비스 아키텍처 (Microservices Architecture)]]
|
|
- 연결 이유: 거대한 모놀리식 구조를 비즈니스 도메인별로 작고 독립적인 서비스로 분할하는 현대 소프트웨어 생태계의 대표적 패턴입니다[31], [32].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 독립적인 배포 및 확장성의 이점과 함께, 분산 트랜잭션 처리(Saga 패턴 등) 및 서비스 간 결합도를 낮추는 고급 설계 원칙을 이해할 수 있습니다[33], [22].
|
|
|
|
- [[이벤트 기반 아키텍처 (Event-Driven Architecture)]]
|
|
- 연결 이유: 상태 변화(이벤트)를 중심으로 컴포넌트가 비동기적으로 상호작용하여 시스템 처리량과 실시간 반응성을 극대화하는 패턴입니다[34], [35], [22].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컴포넌트 간 극단적인 느슨한 결합(Loose Coupling)을 이루는 방식과, 이벤트 흐름을 제어하는 브로커(Broker) 및 메디에이터(Mediator) 토폴로지의 설계상 차이를 깊이 파악할 수 있습니다[36], [37].
|
|
|
|
### Deeper Research Questions
|
|
|
|
- 모놀리식 아키텍처에서 마이크로서비스 아키텍처로의 마이그레이션 시 발생하는 분산 데이터의 '최종 일관성(Eventual Consistency)' 문제를 보완하기 위해 Saga 패턴은 어떻게 동작하며 어떤 한계가 있는가?
|
|
- 조직의 의사소통 구조가 소프트웨어 시스템 구조를 결정한다는 '콘웨이의 법칙(Conway's Law)'은 팀 규모와 DevOps 환경을 고려한 실제 아키텍처 설계 단계에 어떻게 적용될 수 있는가?
|
|
- 이벤트 기반 아키텍처(EDA) 설계 시 워크플로우 제어를 위해 '브로커(Broker)' 토폴로지와 '메디에이터(Mediator)' 토폴로지를 결정짓는 구체적인 비즈니스 요구사항과 트레이드오프 기준은 무엇인가?
|
|
- 소프트웨어 수명 주기 동안 발생하는 '아키텍처 침식(Architecture Erosion)'을 식별하고 예방하기 위한 자동화된 분석 기법 및 리팩토링 전략은 무엇이 있는가?
|
|
- 비즈니스 로직을 외부 기술 스택으로부터 완전히 분리하는 클린 아키텍처(Clean Architecture)나 헥사고날 아키텍처(Hexagonal Architecture)는 의료나 금융 같은 고보안·고규제 도메인에서 어떤 구조적 이점을 극대화하는가?
|
|
|
|
### Practical Application Contexts
|
|
|
|
- **Implementation:** 아키텍처 패턴의 원칙(예: 헥사고날 아키텍처의 포트와 어댑터)에 따라 코드 베이스의 패키지 구조를 분리하고, 비즈니스 로직과 외부 데이터베이스 인터페이스의 의존성을 역전시켜 기술 교체가 용이한 코드를 구현합니다.
|
|
- **System Design:** 트래픽의 스파이크 현상이나 데이터 처리량(ISO 25010 기반 성능 효율성) 등을 예측하여, 단일 배포가 유리한 모듈형 모놀리스로 시작할지 처음부터 높은 확장성의 피어-투-피어(P2P) 또는 마이크로서비스를 채택할지 결정하는 청사진을 설계합니다.
|
|
- **Operation / Maintenance:** ADR(Architecture Decision Record)을 지속적으로 업데이트하여 시스템 변화 내력을 투명하게 관리하며, 분산 아키텍처의 경우 서킷 브레이커나 분산 로깅 등을 운영 환경에 도입하여 장애 격리와 복구 능력을 강화합니다.
|
|
- **Learning Path:** 가장 기본이 되는 계층형 아키텍처(Layered Architecture)의 원리를 이해한 후 -> 디자인 패턴과 도메인 주도 설계(DDD)를 학습하고 -> 마이크로서비스, 서버리스 등의 분산 아키텍처 설계로 넘어가며 -> 마지막으로 ATAM을 통해 여러 아키텍처의 장단점을 평가하는 역량을 기릅니다.
|
|
- **My Project Relevance:** 현재 진행 중인 프로젝트의 팀 규모, 예산, 예상 트래픽(Context)을 분석하여, 오버엔지니어링(예: 무리한 MSA 도입)을 피하면서도 향후 비즈니스 확장에 대비할 수 있는 구조적 뼈대를 선택하는 데 직접적인 기준이 됩니다.
|
|
|
|
### Adjacent Topics
|
|
|
|
- [[도메인 주도 설계 (Domain-Driven Design)]]
|
|
- 확장 방향: 마이크로서비스 아키텍처 등에서 서비스를 분할하는 논리적 기준인 '바운디드 컨텍스트(Bounded Context)'를 설정하고 비즈니스 규칙을 중심에 두는 상세한 도메인 모델링 기법으로 이해를 확장합니다.
|
|
- [[서버리스 컴퓨팅 (Serverless Computing)]]
|
|
- 확장 방향: 개발자가 서버 인프라를 전혀 관리하지 않고 이벤트 트리거에 따라 함수 단위로 코드가 실행 및 과금되는 클라우드 네이티브 아키텍처의 최전선 기술로 시야를 넓힙니다.
|
|
- [[소프트웨어 설계 패턴 (Software Design Patterns)]]
|
|
- 확장 방향: 아키텍처가 시스템의 뼈대라면, 객체 생성, 구조, 행위 등 컴포넌트 내부에서 발생하는 반복적 문제에 대해 유연하게 대응할 수 있는 미시적인 설계 도구(GoF 디자인 패턴 등)로 학습을 전개합니다.
|
|
|
|
---
|
|
*Last updated: 2026-05-02*
|