아키텍처 스타일은 크게 모놀리식(전체 코드를 단일 단위로 배포)와 분산형(원격 액세스 프로토콜을 통해 여러 단위로 배포) 두종류라고 볼 수 있습니다.
모놀리식 아키텍처
- 레이어드 아키텍처
- 파이프라인 아키텍처
- 마이크로커널 아키텍처
분산형 아키텍처
- 서비스기반 아키텍처
- 이벤트 기반 아키텍처
- 공간 기반 아키텍처
- 서비스 지향 아키텍처
- 마이크로 서비스 아키텍처
분산 아키텍처 스타일은 모놀리식 아키텍처 스타일에 비해 성능, 확장성, 가용성 측면에서 강력하지만 몇가지 트레이드 오프가 존재 합니다. 분산 아키텍처의 8가지 트레이드 오프를 살펴 보겠습니다.
분산 아키텍처 8가지 트레이드 오프
1.네트워크는 믿을 수 있다는 착각

네트워크의 신뢰도가 높아지고 있지만 분산 아키텍처의 특성상 서비스간의 데이터를 이동하는 네트워크에 의존해야 하는 것이 사실이다. 그래서 네트워크 의존성은 상당히 중요하다. 위에 A서비스와 B서비스는 REST API로 서로 통신을 한다. 근데 B서비스가 네트워크 문제로 인해 A서비스의 데이터가 B에 도달하지 못한다. 그래서 타임아웃이라던지 서킷 브레이커 같은 것을 두게 되는데 이런 것들은 시스템의 신뢰도를 낮추게 된다.
2.레이턴시는 0이다 라는 착각

메서드나 함수를 이용해 다른 컨포넌트를 로컬로 호출을 하면 그 소요 시간은 대게 나노 초 내지 밀리초 단위로 측정이 된다. 하지만 REST 등 원격 프로토콜을 통해서 호출을 하면 서비스 액세스 시간이 밀리초 단위로 측정이 된다. 따라서 원격 프로토콜(분산)을 통한 호출은 로컬 호출(모놀리식)보다 클 수 밖에 없고 그래서 분산 아키의 레이턴시는 0이라고 보기는 어렵다. 아키텍트는 어떠한 분산 아키를 구축하던지 평군 레이턴시를 반드시 알아야 한다. 특히 마이크로서비스는 서비스가 잘게 나눠져 있기 때문에 서비스간 통신량도 만만치 않아 성능 저하에 주범이 될 수 있다.
3.대역폭은 무한하다 라는 착각

대역폭이란 일정한 시간 한번에 갈 수 있는 데이터의 양이다.(예시 : 1차선 도로 대역폭 적음, 8차선 도로 대역폭 좋음)
모놀리식 아키텍처의 경우 비즈니스 요청을 처리하는데 그리 큰 대역폭이 필요하지 않으므로 대역폭 문제가 별로 발생하지 않는다. 하지만 분산 아키텍처의 경우 여러 도메인으로 자잘하게 쪼개 놓음으로 인해 서비스들 간에 데이터 통신이 많아지고 대역폭을 많이 차지하게 된다. 또한 서비스간 호출을 할때 원하는 데이터는 갖고 오는 것이 아니라 불필요한 데이터도 같이 함께 갖고 오기 때문에 상당히 많은 대역폭을 사용하게 된다.
4.네트워크는 안전하다는 착각

모놀리식에서 분산 아키텍처로 옮겨가면서 더 넓은 영역이 악의적인 외부인의 네트워크 공격에 노출이 되고 있습니다. 그래서 보안에 더욱 신경을 쓰게 되는데 이렇게 보안에 신경을 쓰다 보면 반대로 성능이 떨어질 수 있는 위험에 노출이 되기도 합니다.
5.토폴로지는(구조)는 절대 변하지 않는다는 착각

네트워크를 구성하는 모든 라우터, 허브, 스위치, 방화벽, 네트워크, 어플라이언스 등 전체 네트워크 토폴로지가 불변일 거란 가정은 오해이다. 예를 들어 어플리케이션은 아무런 변경을 하지 않았는데 네트워크 장비 업데이트로 인해 서비스 전체의 장애를 일으킬 수도 있다.
6.관리자는 한사람 뿐이다 라는 착각
업무시 우리는 여러사람과 소통을 합니다. 분산 아키에서 중요한 네트워크도 동일 합니다. 여러 사람과 소통을 하고 조율 과정을 거처야 합니다. 그런 부분도 않은 비용이 드는 것이 사실 입니다. 이러한 부분도 놓쳐서는 안됩니다.
7.비용이 0원이라는 착각

우리가 A -> B서비스로 호출을 해서 데이터를 갖고 올 때 발생한 비용을 생각해 보셨나요? 분산 아키의 경우 하드웨어, 서버, 게이트웨이, 방화벽, 신규 서브넷, 프록시 등 리소스가 더 많이 동원 되므로 모놀리식 아키텍처보다 비용이 비쌉니다. 분산 아키텍처 구성시 용량, 대역폭, 레이턴시, 보안 구역 측면에서 현재의 서버와 토폴로지를 철저하게 분석하여 착각의 늪에 빠지 않아야 하겠습니다.
8.네트워크는 균일하다는 착각
위에서 설명하였듯이 네트워크를 위해서는 여러가지 하드웨어 장비를 갖고 구축을 해야 합니다. 우리가 생각했을때 이런 네트워크 장비들이 잘 물려서 돌아 갈 것으로 생각하지만 실상은 그렇지 않을수 있습니다. 예를 들어 주니퍼 하드웨어와 시스코 하드웨어가 딱 맞물려서 작동하면 좋겠지만 실제로 네트워크 패킷이 유실되는 사고도 심심치 않게 발생을 합니다.
또한 분산 아키텍처의 경우 서비스가 다 떨어져 있기 때문에 로그 파악이 어려워 장애시 추척하기가 어려울 수 있습니다. 각 서비스별로 로그의 위치 및 포멧이 제각각이기 때문 입니다. 또한 분산의 경우 무조건 동기식으로 진행하지 않기 때문에 데이터의 일관성 문제도 트레이드 오프로 지적되고 있습니다.

![[소프트웨어 아키텍처] 아키텍처 결정 안티패턴](https://codecampai.com/wp-content/uploads/2026/01/image-18-768x446.jpg)
![[소프트웨어 아키텍처] 체크리스트를 활용한 프로젝트 관리](https://codecampai.com/wp-content/uploads/2026/01/image-25-768x429.jpg)
![[소프트웨어 아키텍처] 아키텍처의 효율적인 협상 원칙](https://codecampai.com/wp-content/uploads/2026/01/image-27-768x419.jpg)
![[소프트웨어 아키텍처] 소프트웨어 개발/배포에 대한 고찰](https://codecampai.com/wp-content/uploads/2026/02/image-34-768x419.jpg)

![[소프트웨어 아키텍처] 마이크로커널 아키텍처란 무엇인가?](https://codecampai.com/wp-content/uploads/2026/01/image-11-768x557.jpg)