Architecture / 아키텍처의 종류

✔️ 서론

 

지난 글에서는 아키텍처란 무엇이고 왜 중요한지에 대해 알아보았다.

이번에는 대표적인 아키텍처에는 어떤 것들이 있고, 어떤 상황에서 사용하면 좋을지, 요즘 트렌드가 어떤지에 대해 알아보고자 한다.

---

📚 아키텍처의 종류

 

사실 아키텍처의 종류는 무수히 많은데, 프로젝트의 성향, 상황에 맞춰서 적절한 방식을 선택하는 것이 좋다.

오늘은 그 중 대표적인 아키텍처만 톺아보려고 한다.

 

1) 모놀리식 아키텍처(Monolithic)

 

모놀리식 아키텍처는 모든 기능이 하나의 프로젝트와 하나의 데이터베이스를 공유하는 가장 고전적인 형태의 아키텍처이다.

예를 들어 하나의 서버에 결제, 회원가입, 상품 검색 등 모든 기능이 들어있고, 이를 하나의 프로젝트에서 모두 끌어와 사용하는 형태이다.

 

가장 간단하고 심플한 구조이기에 개인 프로젝트를 하거나 규모가 작은 프로젝트에서 효율적인 방법이다. 때문에 초기 스타트업이나 빠르게 시장에 제품을 출시하는 목적으로 사용하기도 한다.

 

모놀리식 아키텍처의 구조

 

간단한만큼 한계도 명확하다. 이전 글에서 설명했던 '설계 지구력 가설'에서 초반 이후 생산성이 급락하는 대표적인 구조이다. 분명 결제 코드를 수정했는데 회원가입이 잘 되지 않는다던가, 데이터베이스에서 처리하는 데이터가 너무 많아져서 서버 오류가 발생하는 등 처음에는 구조가 간단해서 빠르게 많은 작업을 진행할 수 있지만, 시간이 지나고 코드가 많아질수록 복잡성이 증가하고 유지보수성이 떨어지기 때문이다.

 

장/단점을 요약하자면 아래와 같다.

✅  장점(안정적인 관심사 분리)	❌  단점(수정의 늪과 정체기)
개발, 테스트, 배포가 비교적 쉽고 직관적 하나의 코드베이스만 관리하면 되기 때문에 소규모 팀이나 MVP 단계에서 빠르게 작업이 가능함	코드가 커질수록 모듈 간 의존성이 엉켜 작은 수정이 전체 시스템을 무너뜨리는 사이드 이펙트를 유발함 빌드와 배포 시간이 기하급수적으로 늘어나며, 특정 기능만 부분적으로 확장(Scaling)하는 것이 불가능

 

다만, 최근에는 모놀리식 아키텍처가 가진 단점을 어느정도 상쇄하며 복잡성을 줄인 '모듈러 모놀리스(Modular Monolith)' 방식이 유행하고 있다.

모듈러 모놀리스는 물리적으로는 하나의 서버를 사용하지만, 서로 간섭을 할 수 없도록 모듈로 분리하는 방식이다. 이는 후술할 MSA의 장점(독립성)과 모놀리식의 장점(빠른 배포)을 합친 실용적인 타협안으로 각광받고 있다.

 

모듈러 모놀리스의 구조

 

실제로 글로벌 최대 이커머스 플랫폼인 샵이파이(Shopify)는 오랫동안 거대한 단일 모놀리식 아키텍처 구조로 운영되었는데, 서비스가 커지면서 코드 간 간섭이 심해져 크고작은 문제를 겪고 있었다고 한다. 그렇다고 무작정 MSA 방식으로 전환하기에는 비용과 복잡도가 너무 크다고 판단했고, 이 때 모듈러 모놀리스 방식을 채택했다고 한다.

이를 통해 물리적인 서버는 하나로 유지하되, 코드 레벨에서 비즈니스 경계를 강제하는 리팩토링을 단행했고, packwerk 라는 오픈소스 도구까지 직접 개발하여 모듈 간의 의존성 침범을 빌드 단계에서 차단하는 방식으로 문제를 해결했다고 한다.

---

2) 레이어드 아키텍처(Layered Architecture)

레이어드 아키텍처는 보통 웹 개발을 할 때 가장 먼저 접하는 아키텍처라고 한다. 시스템을 역할에 따라 계층별로 나누는데, 보통 3~4개의 층(Layer)로 나뉜다.

 

각 층은 바로 아래층과만 소통할 수 있다. 예를 들어 화면(UI)를 그리는 코드는 반드시 비즈니스 로직(Service) 코드를 거쳐야만 DB에 접근할 수 있다. 덕분에 관심사가 분리되어 있어 코드를 파악하기 좋다.

 

레이어드 아키텍처의 구조

 

다만 위에서 아래로 흐르는 구조다 보니, 결국 모든 층이 가장 밑바닥에 있는 데이터베이스(DB)에 의존하게 된다는 단점이 있다. 즉, DB의 테이블 구조가 바뀌면 위의 비즈니스 로직부터 UI 계층까지 코드를 다 뜯어고쳐야 하는 것이다...

구조적으로는 안정적이지만 하위 계층에 대한 강한 의존성 때문에 변화에 취약하다는 것이 큰 문제인 것이다.

 

장/단점을 요약하면 아래와 같다.

✅  장점(안정적인 관심사 분리)	❌  단점(데이터베이스 중심의 경직성)
프레젠테이션, 비즈니스, 데이터 접근 등으로 역할을 명확히 나누기 때문에 구조를 이해하기 쉽고 협업 시 작업 분할이 용이함 각 레이어는 자신의 역할만 수행하므로 코드 가독성이 높음	상위 레이어가 하위 레이어에 직접 의존하는 구조 특성상 데이터베이스 테이블 구조가 조금만 바뀌어도 비즈니스 로직과 UI 코드까지 고쳐야 하는 파급 효과가 발생

---

3) 마이크로서비스 아키텍처(Microservices Architecture, MSA)

앞서 먼저 나온 마이크로서비스 아키텍처, 통칭 MSA는 하나의 큰 서비스를 독립적으로 배포 가능한 작은 서비스(모듈)들의 집합으로 쪼개어 구축하는 방식이다.

즉, 시스템을 비즈니스 도메인별로 작게 쪼개어 각각 독립적인 서버와 DB를 갖게 하는 것이다. 넷플릭스나 아마존 같은 대기업들이 사용하고 있는 방식이기도 하다.

 

마이크로서비스 아키텍처의 구조

 

결제 서버, 회원 서버, 상품 서버 등이 완전히 분리되어 있다. 이 덕분에 하나의 서버가 트래픽 폭주 등의 이유로 다운되어도 다른 서버에는 영향을 주지 않기 때문에 긍정적인 사용자 경험을 줄 수 있다. 이를 구현하기 위해서 각 모듈별로 프로젝트를 진행하는 편이고, 독립적인 개발과 배포가 가능하여 대규모 조직에 적합한 방식이라고 볼 수 있다.

 

다만, 분산된 서버 간에 통신(API 호출 등)을 해야 하므로 지연 시간이 생기고, 한쪽 DB에는 데이터가 저장되었는데 다른 쪽 DB에는 저장이 안 되는 '데이터 정합성' 문제가 발생한다.

 

데이터 정합성 문제

또, MSA는 서비스를 나누는 순간 단순한 개발을 넘어 거대한 분산 시스템 인프라를 처음부터 구축해야 하므로 비용(장비, 솔루션 라이선스, 개발자의 공수 등)이 굉장히 커지게 된다. 게다가 DB가 여럿이기 때문에 모니터링이 어렵다는 문제가 있다. 모니터링 문제를 해결하기 위해서는 분산 추적 시스템(Jaeger, Zipkin 등)과 중앙 집중형 로그 수집기(ELK 스택, Grafana Loki 등)을 초기에 완벽히 구축해야 한다.(근데 이 시스템을 유지하는 비용도 만만치 않다)

 

장/단점을 요약하자면 아래와 같다.

✅  장점(장기적 지구력과 유연성)	❌  단점(극악의 설계 및 통신 복잡도)
서비스를 도메인 단위로 나누어 하나의 서비스가 죽어도 전체 시스템이 마비되지 않음 팀별로 독립적인 개발과 배포가 가능함 트래픽이 몰리는 특정 서비스만 유연하게 확장 가능	분산된 서버간의 통신을 해야 하므로 지연시간이 발생함 한 쪽 DB에는 데이터가 저장되었는데, 다른 DB에는 저장이 안 되는 데이터 정합성 문제가 발생함 초기 인프라 세팅 비용 및 유지보수 비용이 매우 큼

 

MSA가 가진 단점 탓에 요즘에는 이벤트 기반 아키텍처(EDA, Event-Driven Architecture)가 사용되기도 한다.

EDA는 서버끼리 직접 API를 호출하며 기다리는 대신, 중앙의 메신저(Kafka 등)에 이벤트가 발생했다는 알림(Event)만 던지고 자기 할 일을 하는 비동기 방식이다. 모듈간의 결합도를 극단적으로 낮춰 실시간 대규모 트랜잭션 처리에 필수적으로 쓰이는 방식이다.

 

이벤트 기반 아키텍처의 구조

 

EDA 방식은 서버들이 서로의 존재를 몰라도 이벤트를 던지고 받으며 일하기 때문에 결합도가 극단적으로 낮고, 시스템 확장성이 뛰어나다. 다만, 메시지 큐(Kafka 등)라는 복잡한 미들웨어가 추가로 필요하며, 에러가 발생했을 때 데이터가 어디서 어떻게 유실되거나 꼬였는지 전체적인 흐름을 추적(디버깅)하기가 매우 까다롭다.

 

전세계적으로 많이 이용하는 OTT 서비스인 넷플릭스(Netflix)에서 EDA 방식을 사용하고 있다.

넷플릭스는 그 특성상 수억 명의 유저들이 영상을 시청하고, 찜하기를 누르고, 결제를 하는 등의 이벤트를 거의 동시에 진행한다. 이 때 결제 시스템이 일시적으로 느려졌다고 해서 영상 재생 버튼까지 먹통이 되면 안된다. 때문에 중앙에 아파치 카프카(Apache Kafka)를 두고 모든 이벤트를 비동기로 처리하여 유저들의 행동에 대한 알람을 각 서버로 보낸다. 각 서버는 즉시 이벤트를 처리하는 것이 아니라 리소스에 여유가 있을 때 이 이벤트를 처리하여 유저에게는 긍정적인 사용자 경험을 주고 시스템적으로는 초고용량 트래픽 환경에서 무너지지 않는 장애 탄력성을 확보할 수 있는 것이다.

---

4) 클린/핵사고날 아키텍처(Clean / Hexagonal Architecture)

클린/핵사고날 아키텍처는 이름만 다를 뿐 본질적인 사상이 완벽히 똑같은 방식이다. 여기서는 편하게 클린아키텍처라고만 표현을 하도록 하겠다.

클린 아키텍처는 최근 모던 개발에서 가장 주목받는 아키텍처로, "비즈니스 핵심 로직"을 중심에 두고 UI나 데이터베이스 같은 외부 요소는 언제든 갈아끼울 수 있게 완전히 분리하는 방식이다.

 

클린 아키텍처의 구조

 

클린 아키텍처는 레이어드 아키텍처의 단점(DB에 의존)을 의존성 역전(DIP)이라는 기술로 해결한다. 시스템의 정중앙에 '순수한 비즈니스 로직(도메인)'을 두고, UI, DB, API 등은 모두 외부의 플러그인처럼 취급하여 중앙의 로직을 향해 의존하도록 하는 방식이다.

이 방식 덕분에 웹을 앱으로 바꾸거나 MySQL을 MongoDB로 바꾸는 것처럼 DB를 바꿔도 핵심 비즈니스 로직은 전혀 수정할 필요가 없다. 이처럼 비즈니스 로직이 완전히 격리되어 있기 때문에 테스트 코드 작성이 매우 쉬운 편이다.

 

이렇게만 보면 완벽한 아키텍처처럼 보이지만, 클린 아키텍처를 제대로 구현하기 위해서는 인터페이스(Interface)와 매핑(Mapping) 클래스를 엄청나게 많이 만들어야 한다. 간단한 게시판을 하나 만들기 위해서도 파일이 5~6개는 만들어야 하므로 작은 프로젝트를 진행하는 경우에는 오버엔지니어링(Over-engineering)이 될 수 있다.

 

장/단점을 요약하면 아래와 같다.

✅  장점(프레임워크와 기술로부터의 자유)	❌  단점(오버엔지니어링의 위험)
의존성 역전(DIP)을 통해 외부 기술(DB, 웹 프레임워크, UI)을 플러그인처럼 격리하여 외부 기술이 변경되어도 비즈니스 로직은 영향을 받지 않음 비즈니스 로직이 격리되어 있어 화면이나 DB 없이도 비즈니스 로직만 단독으로 테스트하기 용이함	작은 기능을 하나 추가하기 위해 Interface, Entity, UseCase, Adapter 등 수많은 클래스를 새로 만들고 데이터 매핑을 해줘야 해서 작업량이 큼 단순한 프로젝트에서는 오히려 생산성을 떨어뜨림

---

5) 각 아키텍처별 특성 비교

지금까지 가장 대표적인 현대 아키텍처 패턴들에 대해 알아보았다.

아래는 표를 통해 각 아키텍처별 특징과 트레이드오프 등을 정리해놓은 요약본이다.

아키텍처 종류	초기 비용	유지보수성	물리 구조 (서버/DB)	핵심 트레이드오프	추천 적용 상황
1. 모놀리식 단일 상자 구조	매우 낮음	낮음	단일 프로세스 / 단일 DB	● 초기 개발·배포 속도 최적화   ● 규모 확장 시 결합도·오류 전파 급증	소규모 팀, MVP 개발 및 신속한 비즈니스 검증 단계
2. 레이어드 역할별 계층 분리	낮음	보통	단일 프로세스 / 단일 DB	● 역할에 따른 안정적인 관심사 분리   ● 하위 DB 의존성으로 인한 구조 경직	비즈니스 규칙이 표준적이고 예측 가능한 일반 웹 서비스
3. 마이크로서비스 도메인별 독립 분산	매우 높음	높음	분산 컨테이너 / 개별 DB	● 서비스 단위 개별 확장 & 장애 격리   ● 인프라 오버헤드 & 데이터 정합성 복잡도	대규모 트래픽 분산 처리가 필요한 거대 서비스 및 대규모 조직
4. 클린 아키텍처 도메인 중심 의존성 역전	높음	매우 높음	구조 제약 없음 (코드 격리)	● 외부 기술과 비즈니스 로직 완벽 격리   ● 초기 인터페이스 및 데이터 매핑 코드 급증	도메인 로직이 복잡하고 오랜 기간 유지보수가 필요한 프로젝트
5. 모듈러 모놀리스 칸막이 내부 모듈화	보통	보통~높음	단일 프로세스 / 단일 DB	● MSA급 코드 독립성 + 모놀리식의 배포 편의   ● 엄격한 모듈 규칙 무너질 시 스파게티화	MSA의 높은 인프라 비용과 분산 환경이 부담스러운 중대형 서비스
6. 이벤트 기반 비동기 메시지 기반 통신	높음	높음	메시지 브로커(Kafka 등) 중심	● 비동기 알림을 통한 시스템 간 결합도 최소화   ● 데이터 흐름 추적 및 실시간 디버깅 난해	대용량 실시간 스트리밍 처리 및 분산 시스템 간의 비동기 연동

---

📊 최신 아키텍처의 트렌드

오라일리(O'Reilly Software Architecture Survey)는 매년 혹은 주기적으로 전 세계 수천명의 소프트웨어 엔지니어, 아키텍트, 기술 리더들을 대상으로 실무에서 사용하는 프레임워크, 도구, 아키텍처 패턴을 전수 조사하여 발표하는 리포트가 있다.

이를 분석하여 현시대의 아키텍처 트렌드를 어느정도 알아볼 수 있었는데, 주요 데이터를 표시하면 아래와 같다.

 

📊 글로벌 소프트웨어 아키텍처 패턴 채택 비율

출처: O'Reilly Software Architecture Survey 실무자 조사 데이터 기반 통계

🧩 마이크로서비스 아키텍처 (MSA) 45%

 

🧱 레이어드 아키텍처 (Layered) 28%

 

📦 모놀리식 / 모듈러 모놀리스 17%

 

🌪️ 이벤트 기반 아키텍처 (EDA) 10%

 

* 실무 환경에서는 여러 패턴을 혼용(하이브리드)하여 사용하는 경우가 많으므로, 본 지표는 기업의 메인 시스템 구조를 기준으로 한 대표적 통계치입니다.

 

다만, 이 데이터는 완전히 정확한 통계가 아니며, 본 통계 지표는 글로벌 IT 지식 플랫폼 O'Reilly Media에서 전 세계 아키텍트들을 대상으로 조사한 Software Architecture Survey 데이터를 기반으로 재구성된 내용이다.

 

통계를 보면 현재 백엔드 생태계에서 MSA가 절반에 가까운 큰 비중을 차지하고 있지만, 최근에는 MSA의 비용적 한계를 느끼고 모듈러 모놀리스나 비동기 이벤트 기반 구조로 선회하는 하이브리드 트렌드가 강해지고 있는 듯 보인다.

 

하지만 이 통계에서 MSA가 비중이 높든, 모듈러 모놀리스가 비중이 높든 그런 것은 사실 큰 상관이 없다. 우리는 우리가 진행하는 프로젝트에 가장 알맞는 아키텍처를 선택하면 되기 때문이다. 중요한 것은 유행이 아니라 내 프로젝트의 규모와 팀 역량에 맞는 트레이드오프를 선택하는 것이기 때문이다. 이전 글에서도 말했 듯, 아키텍처의 본질은 결국 '가장 멋진 구조'가 아니라 '가장 경제적인 의사결정'이기 때문이다.

[출처]
오라일리 공식 리포트 및 설문 가이드 페이지:O'Reilly 아키텍처 트렌드 및 설문조사 메인 페이지
오라일리 미디어 및 플랫폼 메인 링크:O'Reilly Media 공식 홈페이지

---

✒️ 결론

오늘은 지난 시간에 이어서 아키텍처의 종류와 특징, 트렌드에 대해 알아보았다.

iOS에 대한 공부만 했던 탓에 내가 알고 있던 아키텍처라곤 MVC, MVVM, CleanArchitecture, Viper, MVI 등등... 이런 모바일 관련 아키텍처 밖에 몰랐는데, 실상은 더 많고 다양한 아키텍처가 있음을 알 수 있었다.

 

각 아키텍처가 저마다의 장/단점을 가지고, 세계의 많은 개발자들이 각 아키텍처의 단점을 줄이기 위해 얼마나 창의적이고 다양한 방식을 사용하는지 알게되자 뭔가 눈이 뜨이는 기분이었다. 그동안 같은 아키텍처만 사용해봤다보니 틀에 박힌 구조만 생각했었는데, 어떻게 하면 더 효율적일지, 어떻게 하면 더 프로젝트에 적합한 방식인지를 고민하는 과정이 왜 중요한지 알게된 것 같다.

 

아키텍처에 대한 정리를 3개의 글로 끝내려고 했는데, 생각보다 아키텍처라는 개념이 가진 깊이가 너무 깊어서 과연 다음 글로 마무리를 할 수 있을까 걱정이다. 필요하면 글의 수를 더 늘리겠지만, 일단 다음 글은 클린 아키텍처를 활용한 iOS 설계 방식에 대해 다루고자 한다.