---
id: P-REINFORCE-WIKI-8F93041D
category: Dev
confidence_score: 0.95
tags: ['macro-architecture', 'layered-architecture', "conway's-law", 'hexagonal-architecture', 'design-patterns', 'architecture-principles']
last_reinforced: 2026-05-02
---

# [[Macro-architecture]]

## 📌 Brief Summary
매크로 아키텍처(Macro-architecture)는 코드베이스와 개발 팀의 구조 모두를 형성하는 거시적 수준의 소프트웨어 아키텍처를 의미한다 [1]. 이는 시스템 내부의 세부적인 기계적 설계(Micro-architecture)보다는 전체 시스템의 수평적 분할 및 조직 구조와의 매핑을 다루며, 데브옵스(DevOps), 디렉토리 구성, 툴링과 같은 전반적인 인프라 및 기술 선택을 포괄한다 [2, 3]. 대표적인 예로 프레젠테이션, 비즈니스, 데이터베이스 계층으로 나뉘는 계층형 아키텍처(Layered Architecture)를 들 수 있다 [1].

## 📖 Core Content
* **조직 구조와의 매핑 (Conway's Law 반영):** 매크로 아키텍처는 콘웨이의 법칙(Conway's Law)과 밀접하게 연관되어 있다 [1]. 거시적인 관점에서 계층형 아키텍처(Layered Architecture)의 수평적 분할은 종종 조직 내 특정 그룹과 직접적으로 일치하게 된다 [1]. 예를 들어, 프레젠테이션 계층은 UI/UX 팀(React 개발자)이 담당하고, 비즈니스 계층은 백엔드 팀(Java 개발자)이 담당하며, 데이터베이스 계층은 DBA가 담당하는 식으로 구조화된다 [1].
* **마이크로 아키텍처(Micro-architecture)와의 구분:** 헥사고날(Hexagonal), 어니언(Onion), 클린 아키텍처(Clean Architecture)와 같은 도메인 중심의 패턴들은 매크로 수준의 구조를 설명하는 것이 아니라, 매크로 아키텍처(예: 계층형 아키텍처) 내부의 특정 계층인 '비즈니스 계층'의 내부 설계를 다루는 마이크로(Micro) 패턴 또는 디자인(Design)에 가깝다 [2]. 
* **운영 및 인프라 영역의 포함:** 매크로라는 용어는 단순히 애플리케이션 코드를 넘어서, 데브옵스(DevOps) 환경, 디렉토리의 구성 체계, 툴링, 그리고 데이터베이스(SQL), 마크업(HTML), 데이터(JSON) 처리와 같은 아키텍처 차원의 전환 및 구현 선택을 포괄하는 폭넓은 개념으로 사용된다 [3]. 반면 디자인(Design) 또는 마이크로 영역은 컴포넌트 간의 관계(예: "has-a" 관계)와 같은 시스템 기계장치(system-machinery)에 관한 세부 선택을 의미한다 [3].

## ⚖️ Trade-offs & Caveats
* **조직 구조와의 강한 결합에 따른 경직성:** 매크로 아키텍처가 각 팀의 조직 구조(프론트엔드, 백엔드, DB 등)와 직접적으로 매핑되는 특성상 [1], 새로운 비즈니스 요구사항이나 교차 기능(Cross-functional)이 필요할 때 팀 간의 협업 및 배포 일정을 맞추는 데 유연성이 떨어질 수 있다.
* **패턴 적용 수준의 오해:** 매크로 수준과 마이크로 수준의 패턴을 명확히 구분하지 않고, 마이크로 설계 패턴(예: 클린 아키텍처)을 전체 매크로 아키텍처에 강제로 대입하거나 혼용하려 하면 시스템이 불필요하게 복잡해지는 오버엔지니어링(Overengineering)이 발생할 수 있다 [2, 4].

## 🔗 Knowledge Connections

### Related Concepts

#### [아키텍처/기반 기술]
- [[Layered Architecture]]
  - 연결 이유: 매크로 아키텍처의 가장 전형적인 사례로, 수평적인 스택 분할을 통해 거시적인 아키텍처를 구성하기 때문이다 [1, 2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 매크로 아키텍처가 어떻게 사용자 인터페이스, 비즈니스 로직, 데이터 관리를 분리하여 전체 시스템 구조를 잡는지 이해할 수 있다.
- [[Conway's Law]]
  - 연결 이유: 매크로 아키텍처가 기술적 구조를 넘어 실제 개발 팀(조직 그룹)의 구조와 어떻게 매핑되는지 설명하는 근본 원리이기 때문이다 [1].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 아키텍처의 수평적 슬라이스(예: UI팀, 백엔드 팀)가 조직의 소통 방식 및 역할 분담과 어떤 상호작용을 하는지 파악할 수 있다.

#### [마이크로 설계/구현 패턴]
- [[Hexagonal Architecture]]
  - 연결 이유: 매크로 아키텍처와 대비되는 마이크로 수준의 설계 패턴(비즈니스 계층 내부 구조화)으로 주로 사용되기 때문이다 [2, 3].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 거시적 아키텍처(Macro) 내에서 비즈니스 로직을 외부 시스템(데이터베이스, UI 등)으로부터 분리하고 고립시키는 내부 설계(Micro) 방법을 배울 수 있다.

### Deeper Research Questions

- 매크로 아키텍처(예: 계층형) 내부에 마이크로 패턴(예: 헥사고날 또는 클린 아키텍처)을 중첩하여 사용할 때 경계(Boundary)를 어떻게 설정해야 오버엔지니어링을 피할 수 있는가?
- 콘웨이의 법칙에 따라 매크로 아키텍처가 팀 구조를 반영한다면, 애자일 기반의 크로스펑셔널(Cross-functional) 팀을 운영할 때 매크로 아키텍처는 어떻게 진화해야 하는가?
- 클라우드 네이티브 환경 및 마이크로서비스 아키텍처(MSA) 체제에서 매크로 아키텍처의 범위는 애플리케이션 내부 구조인가, 아니면 서비스 간의 전체 분산 네트워크 구조인가?
- 데브옵스(DevOps) 및 CI/CD 파이프라인의 구성이 매크로 아키텍처의 설계 결정(디렉토리 구조, 툴링 등)에 어떠한 제약이나 영향을 미치는가?
- 아키텍처 스타일(Macro)과 시스템 설계(Micro)의 차이가 실제 프로젝트 유지보수성 및 코드 가독성에 미치는 장기적 영향은 무엇인가?

### Practical Application Contexts

- **Implementation:** 프로젝트 초기 설정 시, 매크로 아키텍처를 기반으로 깃(Git) 레포지토리의 디렉토리 구조, 포트/어댑터 전환 방식, 사용하는 기술 스택(SQL, HTML, JSON 등)을 거시적으로 결정한다 [3].
- **System Design:** 전체 시스템을 Presentation, Business, Database 등 거대한 수평적 단위(Macro)로 나누고, 내부 비즈니스 로직(Micro)에는 클린 아키텍처나 헥사고날 아키텍처를 적용하는 이중 설계를 기획한다 [2, 4, 5].
- **Operation / Maintenance:** 매크로 아키텍처 구조에 맞춰 데브옵스(DevOps) 파이프라인을 구축하여 프론트엔드와 백엔드의 빌드, 배포, 툴링 운영 체계를 격리하여 관리한다 [1, 3].
- **Learning Path:** 시스템의 전체 뼈대와 조직 운영을 이해하기 위해 매크로 아키텍처와 콘웨이의 법칙을 먼저 학습한 뒤, 코드 내부의 세부 구현을 위해 디자인(Micro) 및 패턴(헥사고날 등)을 학습하는 방식으로 접근한다.
- **My Project Relevance:** 개발팀을 구성할 때 프론트엔드 팀, 백엔드 팀 등 기술 기반의 팀 분리가 예정되어 있다면, 이에 자연스럽게 매핑되는 계층형 아키텍처를 매크로 아키텍처로 채택하여 효율을 높일 수 있다.

### Adjacent Topics

- [[Design Patterns]]
  - 확장 방향: 전체 시스템 구조를 다루는 매크로 아키텍처와 달리, 개별 컴포넌트나 클래스 내부의 반복적인 문제를 해결하기 위한 세부 구현 및 행동 메커니즘 학습으로 확장.
- [[DevOps and Tooling]]
  - 확장 방향: 매크로 아키텍처가 요구하는 디렉토리 구성 및 배포 파이프라인이 실제 클라우드나 온프레미스 인프라에서 어떻게 자동화되고 관리되는지 탐구.

---
*Last updated: 2026-05-02*