# [[모놀리식 아키텍처 (Monolithic Architecture)|모놀리식 아키텍처 (Monolithic Architecture]]

## 📌 Brief Summary
모놀리식 아키텍처는 애플리케이션의 모든 기능과 서비스가 단일 코드베이스로 묶여 하나의 단위로 배포되는 전통적인 소프트웨어 설계 방식입니다 [1, 2]. 소규모 애플리케이션이나 최소 기능 제품(MVP)을 개발하고 배포하는 데에는 비교적 단순하고 유리하지만, 시스템이 커질수록 확장과 유지보수가 어렵다는 한계를 지닙니다 [2]. 구성 요소들이 강하게 결합되어 있어 아주 작은 변경 사항이라도 전체 애플리케이션의 재배포와 전체 시스템 테스트를 요구합니다 [1, 3].

## 📖 일Core Content
* **구조 및 배포 (Structure & Deployment)**
  모놀리식 아키텍처는 모든 기능이 포함된 단일하고 통합된 코드베이스로 구성됩니다 [1, 2]. 이 구조로 인해 업데이트나 변경 사항을 적용할 때 전체 애플리케이션을 다시 배포해야 합니다 [1]. 소규모 애플리케이션의 경우 중앙 집중식 로깅을 통해 디버깅이 쉽고 개발 및 배포가 단순하다는 장점이 있습니다 [2].

* **유지보수 및 테스트 (Maintenance & [[Testing|Testing]])**
  기능들이 긴밀하게 결합(tight coupling)되어 있기 때문에, 시스템 일부분의 작은 변경이 전체 시스템에 영향을 미치거나 버그와 지연의 도미노 효과를 일으킬 수 있습니다 [2, 3]. 따라서 유지보수가 복잡하며, 테스트 시에도 개별 요소가 아닌 전체 시스템 검증이 요구됩니다 [1]. 

* **확장성 및 유연성 ([[Scalability|Scalability]] & Flexibility)**
  시스템 규모가 커짐에 따라 스파게티 코드(spaghetti code)가 될 위험이 증가하며 복잡성을 통제하기 어렵습니다 [1]. 또한, 특정 기능만 확장하는 것이 불가능하여 애플리케이션 전체를 확장해야 하므로 유연성이 떨어집니다 [1]. 외부 시스템 및 기술과의 통합이 더 까다로우며, 팀 간의 병렬 개발과 협업 역시 강한 의존성으로 인해 방해를 받을 수 있습니다 [1].

* **성능 및 비용적 측면 (Performance & Cost)**
  모놀리식 애플리케이션은 모듈화된 컴포넌트 기반 아키텍처가 겪을 수 있는 컴포넌트 간 통신(네트워크 호출 등) 오버헤드나 지연 시간(latency) 이슈가 없습니다 [4]. 따라서 경우에 따라서는 모놀리식 아키텍처가 더 간소화되어 추가적인 관리 리소스와 비용을 절감하는 효과를 낼 수도 있습니다 [4].

## 🔗 Knowledge Connections
- **Related Topics:** 컴포넌트 기반 아키텍처 ([[Component-Based Architecture|Component-Based Architecture]]), [[마이크로서비스 아키텍처 (Microservices Architecture)|마이크로서비스 아키텍처 (Microservices Architecture]]
- **Projects/Contexts:** 제한된 기능만을 가지는 초기 스타트업 프로젝트 또는 최소 기능 제품 (MVP) 구축 [2], 유지보수 및 비용 효율성을 높이기 위해 모놀리식 시스템을 민첩하고 모듈화된 아키텍처로 변환하려는 레거시 시스템 현대화 [5].
- **Contradictions/Notes:** 모놀리식 아키텍처는 확장성과 유연성이 떨어져 현대의 대규모 개발에 불리하다는 것이 주된 시각이지만 [1, 2], 컴포넌트 간의 통신 오버헤드(네트워크 통신 등)가 발생하지 않기 때문에 고속 처리가 중요한 특정 시나리오에서는 오히려 컴포넌트 기반 접근보다 성능상 리소스와 비용이 덜 들고 간소화될 수 있다는 점이 소스에 언급되어 있습니다 [4].

---
*Last updated: 2026-04-25*