[소프트웨어 아키텍처 101] CHAPTER 10, 11. 모놀리식 - 레이어드, 모듈러 모놀리스 아키텍처

지난주에 이 책의 ‘PART2. 아키텍처 스타일’을 시작하면서 아키텍처 스타일의 정의와 어떻게 분류될 수 있는지를 보았습니다. 이번주에는 모놀리식 아키텍처 스타일에 해당하는 ‘레이어드 아키텍처’에 대해 스터디한 내용을 공유하고자 합니다.

💡 ‘내 생각’부분은 스터디때 바로바로 적었던 내용이라 올바른 정보가 아닐 수 있음을 전달드립니다. 또한 스터디 내용을 복습한 것이므로 정확하지 않을 수 있음을 안내드립니다. 추가로 ‘PART2. 아키텍처 스타일’은 아키텍처 스타일을 소개하는 장이기 때문에 스터디 진도, 방향상 넘어가거나 또는 다른 아키텍처로 대체될 수 있습니다.

 

---

 

Chapter 10. 레이어드 아키텍처 스타일

개발자라면 한번쯤 모르고라도 사용해봤을 레이어드 아키텍처 스타일은 단순하고 대중적이면서 비용도 적게 들어 사실상 모든 애플리케이션의 표준 아키텍처라고 볼 수 있다. 시스템을 설계하는 조직은 그 조직의 소통 구조를 그대로 복제한 듯 시스템을 설계할 수 밖에 없다는 8장에서 소개된 콘웨이의 법칙을 떠올려보면, 레이어드 아키텍처는 아주 자연스러운 방법이다.

그러나 소프트웨어 아키텍처는 항상 트레이드 오프가 발생하기 때문에 레이어드 아키텍처를 사용시 발생할 수 있는 안티패턴들이 있다. 만약 빠르게 “개발을 시작해보자”, “도메인이 2~3개 이상되지 않는다” 싶으면 레이어드 아키텍처를 사용하는 건 좋은 선택지가 될 수 있다는 것만 참고하면 좋을 것 같다.

아래는 9장에서 소개된 아키텍처 스타일을 두가지 분류로 나눈 표이다. 이번 스터디에서는 책에서 Chapter로 추가하지 않은 ‘모듈러 모놀리스 아키텍처 스타일’에 대해서도 함께 공부할 예정이므로 모놀리식의 특징이 무엇이 있었는지 복기하자.

	모놀리식	분산형
아키텍처	• 레이어드 아키텍처(10장) • 파이프라인 아키텍처(11장) • 마이크로커널 아키텍처(12장) • 모듈러 모놀리스 아키텍처	• 서비스 기반 아키텍처(13장) • 이벤트 기반 아키텍처(14장) • 공간 기반 아키텍처(15장) • 서비스 지향 아키텍처(16장) • 마이크로서비스 아키텍처(17장)
장점	• 간단한 개발 • 단일 배포로 인한 용이성 • 트랜잭션 단순화	• 독립적 확장성 • 낮은 장애 영향도 • 높은 모듈성
단점	• 확장성 제한 • 유지보수의 어려움 • 높은 장애 영향도	• 초기 개발 비용 • 분산 트랜잭션의 어려움 • 네트워크 지연

 

10.1 토폴로지

9장에서 분산형 아키텍처 스타일의 난제 중 ‘9.2.5 오류 #5: 토폴로지는 절대 안 바뀐다’ 절이 있었는데 9장에서 말하는 토폴로지는 네트워크 장비의 배치를 뜻하는데 10장에서는 어떤 의미일까? 10장 레이어드 아키텍처에서 말하는 토폴로지란 레이어간의 배치와 관계를 의미하는데 이는 곧 물리적 계층화(배포) 관점에서의 다양한 변형을 말한다.

오늘도 한 페이지 - 레이어드 아키텍처의 토폴로지

• 단일 배포 단위 : (프레젠테이션 + 비지니스 + 퍼시스턴스 + 데이터베이스)
• 데이터베이스 분리 : (프레젠테이션 + 비지니스 + 퍼시스턴스) + 데이터베이스
• 프레젠테이션, 데이터베이스 분리 : 프레젠테이션 + (비지니스 + 퍼시스턴스) + 데이터베이스

 

10.2 레이어 격리와 추가

오늘도 한 페이지 - 레이어 격리와 추가

• 레이어 격리는 폐쇄(Close) 원칙과 관련이 있다. 다른 레이어에 대하나 의존성이 제한되어 있으며, 인접한 레이어와만 상호작용하는 특징을 가졌다.
• 레이어 추가는 개방(Open) 원칙과 관련이 있다. 기존 레이어의 내부 구현을 변경하지 않고도 새로운 기능을 추가하여 시스템을 확장할 수 있는 특징을 가졌다.

 

10.3 기술 분할 아키텍처와 도메인 분할 아키텍처

8장에서 최상위 아키텍처 분할을 위한 두 가지 방법으로 ‘기술 분할’과 ‘도메인 분할’이 소개되었다. 각 분할의 예시 아키텍처로 ‘레이어드 아키텍처’와 ‘모듈러 모놀리스’가 있었는데 이번 장에서는 각 아키텍처의 특성 등급과 사용 예시에 대해서 소통 주제로 삼아 이야기 해보자.

 

Q1. 레이어드 아키텍처 스타일의 아키텍처 특성을 평가해봅시다. 어떤 특성이 좋고 어떤 특성은 좋지 않을까요?

오늘도 한 페이지 - Q1

 

내 생각

장점

단순성: 레이어드 아키텍처는 대표적인 기술 분할이므로 직관적으로 이해 가능한 레이어를 구성할 수 있는 장점이 있다.

 

단점

‘단순성’을 제외한 모든 특성: 모듈성, Operational(운영 특성)은 모두 분산형 아키텍처 스타일의 장점에 속하므로 레이어드에서는 단점. 무엇보다 레이어드의 가장 큰 단점은 개발 후 배포했을 때 나타난다고 생각하는데 그 중 배포성과 유지보수성이 꼽힐 것 같다. 간단한 변경을 해도 단일 배포 단위 성격상 전체적으로 다시 배포해야 하므로 배포성이 떨어지고, 이로인한 유지보수성 또한 떨어진다.

 

멘토

오늘도 한 페이지 - 레이어드 아키텍처의 특성 평가

💡 책에서 평가하는 레이어드 아키텍처 특성 평가표

책에서는 Simplicity(단순성), Testability(테스트 용이성), Responsiveness(응답성) 세개를 높게 평가하고 있지만 단순성이 높기 때문에 전체적인 비용 측면에서도 강점으로 볼 수 있다.

 

레이어드는 모놀리식이기 때문에 분산 아키텍처보다 복잡하지 않고, 이해하기도 쉽고, 구축하거나 유지보수 비용도 상대적으로 낮다. 그러나 서비스가 커질수록 이러한 장점들은 빠르게 단점으로 바뀔 수 있고 주의가 필요하다.

또한 기술적으로 분할되었기 때문에 높은 Responsiveness(응답성)을 달성할 확률이 높다. 이를 더 높이기 위해서는 캐싱, 멀티스레드 기법을 활용해 응답성을 향상시킬 수 있다. 그러나 이 아키텍처는 싱크홀 안티패턴이 발생할 수 있으며, 본질적으로 도메인 단위로 나뉘어져 있는 아키텍처가 아니기 때문에 특정 도메인에 대해서 scale-up이 필요하거나 병렬처리가 부족하다.

 

Testability(테스트 용이성)이 ⭐️⭐️로 평가되는 이유는, Spring의 모킹(mocking) 또는 스터빙(stubbing) 지원으로 전체 테스트 공수가 덜 들기 때문이다.

 

Q2. 레이어드 아키텍처 스타일은 어떤 경우에 적용할 수 있을까요? 적용되고 있는 예시가 있을까요?

오늘도 한 페이지 - Q2

내 생각

적용 가능한 경우

레이어 별 역할과 책임 분리가 명확이 분할 가능할 때, 데이터 흐름이 위에서 아래로, 아래에서 위로 단방향일 때

 

적용된 예시

• 웹 어플리케이션(클라이언트, 서버 사이드, 데이터베이스)
• OSI 7계층(응용, 표현, 세션, 전송, 네트워크, 데이터 링크, 물리 계층)
• TCP/IP 4계층(응용, 전송, 인터넷, 네트워크 액세스 계층)

 

멘토

오늘도 한 페이지 - 레이어드 아키텍처 적용 예시

 

데이터 흐름이 위, 아래로 흐르기 때문에 ‘컴퓨터 시스템, OSI 7계층, 서버 어플리케이션’에 적용해 볼 수 있다.

 

 

Chapter 11. 모듈러 모놀리스 아키텍처 스타일

💡 1판에서는 아키텍처 스타일 종류로 모듈러 모놀리스 아키텍처가 언급되지 않는데 영문 2판에서는 추가되었다고 하니 국내 서적의 목차와 차이가 있을 수 있습니다.

1판에서 모듈러 모놀리스의 내용이 없다고 아쉬워할 필요는 없다. ‘모듈러 모놀리스 아키텍처 스타일’에 대해서는 ‘8장 컴포넌트 기반 사고 - 8.2.1 아키텍처 분할’에서 설명되었으니 특징은 설명되었고, 해당 아키텍처가 모놀리식인 것만 알고 있으면 된다. 그래도 우리의 뇌는 반복 학습하지 않으면 영구기억장치에 저장되지 않으니 한번 더 살펴보자.

 

11.1 토폴로지

모듈러 모놀리스는 이름에서도 알 수 있듯 독립적으로 배포 가능한 모듈들을 하나의 배포 단위로 만드는 구조를 갖고 있다. 모놀리식의 단순성의 특징과 분산형의 모듈성 특징을 가진 아키텍처 스타일로 볼 수 있어서 두 종류의 장단점을 모두 지닌 아키텍처라고 생각할 수 있겠지만 결국 모놀리식이므로 트레이드 오프는 있다(자세한 내용은 아래 Q3에서..)

 

오늘도 한 페이지 - 모듈러 모놀리스 토폴로지

 

11.2 모듈 간 통신

같은 모놀리식이여도 레이어드 아키텍처 스타일과 뚜렷하게 다른점은 모듈 간 통신이 존재한다는 점을 꼽을 수 있다. 독립적인 각 모듈이 어떻게 통신하여 하나의 애플리케이션으로 배포되는지 알아보자.

오늘도 한 페이지 - 모듈 간 통신

 

Peer-to-peer Approach

모듈들이 서로 직접 통신하는 방법으로 단순하고 직관적인 구현이 가능하며 통신 지연이 상대적으로 적다는 장점이 있다. 그러나 직접 통신하기 때문에 결합도가 높아질 수 있으며, 모듈이 많아질 수록 의존성 관계가 복잡해질 수 있다.

 

Mediator Approach

모듈 간 통신이 중앙의 중재자(mediator)를 통해 이루어지는 방식으로 모듈들은 서로를 직접 알지 못하고, 중재자만 알고있는 방식이다. 중재자가 메시지를 받아서 적절한 모듈로 전달하는 역할하기 때문에 모듈간 결합도는 감소할 수 있고, 의존성 관리에도 용이해진다. 하지만 중재자가 단일 실패 지점(SPOF, Single Point of Failure)가 되어 통신 지연이 증가할 수 있다.

 

모듈 간 통신이니 분산형 아키텍처에도 적용 가능할까?

당연히 적용 가능하다! 모놀리식이 끝나고 분산형에 들어가게 되면 자세히 다룰 듯 싶지만 ‘모듈성’의 아키텍처 특징 관점으로 분산형 아키텍처에 잠깐만 적용해보자.

 

Peer-to-peer Approach

• 분산형 아키텍처에서는 서비스들이 서로 직접 API를 호출하거나 이벤트를 주고받는 형태로 구현된다.
• ‘9장 아키텍처 스타일 - 기초’ 편에서 언급된 분산형 아키텍처의 공통적인 난제 중 ‘9.2.4 오류#4: 네트워크는 안전하다'를 해결하기 위해서는 서비스간 타임아웃, 회복성 패턴(Circuit Breaker 등)이 필요하다.
• 예시: 마이크로 서비스 아키텍처(MSA)

Mediator Approach

• 서비스 수가 많아질 수록 직접(peer-to-peer) 연결의 복잡성이 증가하므로, 중재자를 통한 통신이 확장성과 관리 측면에서 유리할 수 있다.
• 예시: API Gateway, 메시지 브로커(Kafka, RabbitMQ), 서비스 메시(Service Mesh) 등

💡 Circuit Breaker 란?
9장에서도 멘토님께서 언급하셨던 Circuit Breaker란 무엇이고 어떤 역할을 해줄까? 간단하게 정의를 짚고 가보면, 분산 시스템에서는 네트워크 지연, 서비스 다운타임, 리소스 부족 등 다양한 장애 요소가 있어 서킷 브레이커의 역할이 특히 중요한데 마이크로서비스 아키텍처처럼 여러 독립적인 서비스로 구성된 시스템에서는 서비스 간 의존성 관리와 전체 시스템의 안정성 확보를 위해 필수적인 패턴이다. 주로 장애 격리, 시스템 복원력 향상, 자원 보호, 대체 응답 메커니즘 등의 역할을 한다.

 

Q3. 모듈러 모노리스 아키텍처 스타일의 아키텍처 특성을 평가해봅시다. 어떤 특성이 좋고 어떤 특성은 좋지 않을까요?

오늘도 한 페이지 - Q3

 

내 생각

장점

• 모듈성 : 모놀리식 구조지만 내부적으로 잘 정의된 모듈 경계와 느슨한 결합을 가졌기에 모듈성의 특징을 갖고 있다.
• 확장성 : 큰 장점으로 꼽을 수는 없지만 모듈성의 특징 덕분에 분산형 아키텍처로 리팩토링 할 수 있기 때문에 확장성을 가졌다고 볼 수 있다.
• 단순성 : 모듈성의 특징을 갖고 있다고 해서 분산형 아키텍처는 아닌 단일 배포 단위를 갖고 있기 때문에 단순성의 특징을 갖고 있다.

단점

• 엔지니어링 특성 : 모놀리식 구조이기 때문에 레이어드 아키텍처가 가졌던 단점과 동일한 배포, 테스트의 어려움이 있을 것으로 생각된다.

궁금한 점

오늘도 한 페이지 - 퀀텀 개수

❓ 퀀텀이란 ‘높은 기능 응집도와 동기적 커네이선스를 가진, 독립적으로 배포 가능한 아티팩트’인데 레이어드 아키텍처는 단일 배포 단위를 가진 모듈성 낮은 아키텍처라서 퀀텀 수가 1개인 것인지 궁금합니다.

❗ 1판에서는 “데이터베이스 + 애플리케이션 = 하나의 배포 단위 = 하나의 퀀텀”으로 이야기하고 있었지만 2판에서는 ‘모듈러 모놀리스 아키텍처’ 가 추가되면서 모듈별 여러 운영적 특성을 갖고 있어도 결국 모듈러 모놀리스 아키텍처로써 하나의 배포 단위로 운영되는 것을 하나의 퀀텀이라고 말하는 것 같습니다. 여기서 모듈러 모놀리스의 모듈이 MSA의 각 서비스로 변경된다면 각각의 서비스 개수가 퀀텀 개수로 보면 될 것 같습니다.

 

멘토

오늘도 한 페이지 - 모듈러 모놀리스 아키텍처 특성 평가

💡 책에서 평가하는 모듈러 모놀리스 아키텍처 특성 평가표

책에서는 단순성이 높다고 말하지만 도메인을 분할하는 것 자체가 어려운 일이기 때문에 단순성이 높지 않다고 생각합니다. 다만 책에서는 본질적으로 모놀리식이기 때문에 분산형과 같은 복잡성이 없어서 단순성을 5점을 줬다고 합니다.

 

Maintainability(유지보수성)은 도메인별로 나눴기 때문에 상대적으로 좋은편으로 볼 수 있습니다. 물론 의존성이 있으면 유지보수성이 달라질 수 있으나 보통은 변경사항이 생기면 해당 모듈(도메인)에 대해서만 대응해주면 되긴때문에 유지보수성이 좋은 편입니다.

 

Deployability(배포 용이성)은 모놀리식이기 때문에 위험성때문에 높은 점수를 받지 못했습니다.

모듈화했기 때문에 Scalability(확장성), Elasticity(탄력성) 이 높다고 생각할 수 있지만 결국 모놀리식이기 때문에 특정 부분을 Scale-out하거나 트래픽을 몰렸을 때 대응하기 어려워서 낮은 점수를 받았습니다.

 

한 서비스의 장애가 전체 시스템에 전파되는 모놀리식이기 때문에 Fault tolerance(내결함성, 장애 허용성)는 낮은 점수를 받았습니다.

 

Q4. 모듈러 모노리스 아키텍처 스타일은 어떤 경우에 적용할 수 있을까요? 적용되고 있는 예시가 있을까요?

오늘도 한 페이지 - Q4

 

내 생각

• 적용 가능한 경우 : 내부적으로 명확한 모듈 분리가 가능할 경우, 각 모듈마다 자체 도메인 로직과 데이터 액세스 계층을 가질 경우, 추후 MSA로 전환할 가능성이 있는 프로젝트의 경우
• 적용된 예시 : (뭐가 있을까..)

 

멘토

오늘도 한 페이지 - 모듈러 모놀리스 적용 예시

 

---

 

마무리

레이어드 아키텍처라서 아는 내용이 많이 나올 듯 싶었는데 레이어드 아키텍처만 고려하는 것이 아닌 분산형 아키텍처도 함께 비교할 수밖에 없다보니 포스팅해보고 싶은 인사이트를 얻게됐다. 책 스터디하듯 이론 공부만으로도 포스팅 할 수 있겠지만 웬만하면 진행하고 있는 프로젝트에 적용하여 해보는 것을 목표로 해보려고 한다. 일단 지난주 일요일 스터디도 끝~! 고생하셨습니다!