소프트웨어 아키텍처 패턴

소프트웨어 아키텍처를 패턴화한 것이다.

건물을 세울 때 기초와 토대가 중요하듯, 소프트웨어 역시 아키텍처를 잘 만들어 두고 시작하는 것이 중요하다. 기초 공사가 제대로 되지 않은 소프트웨어에서 지엽적인 기능 추가나 버그 수정이 반복되다 보면 스파게티 코드가 되기 십상이며, 이는 소스 코드의 가독성과 유지보수성을 낮추는 주요 원인이 된다.

소프트웨어 아키텍처 패턴은 소프트웨어의 구성 요소를 연결하는 방법이나 구성 요소 간의 관계 등을 어느 특정한 형태로 구조화함으로써 소프트웨어 설계에서 윤곽을 제시한다. 소프트웨어 아키텍처 패턴별로 주요 지향점은 다르지만, 공통적으로 소프트웨어 아키텍처 패턴을 적용해 개발된 소프트웨어는 그렇지 않은 경우에 비해 퀄리티 면에서 이점을 갖는다.

소프트웨어 아키텍처 스타일과 혼용하는 탓에 혼동하는 사람들이 많다. 엄밀하게 따지면 서로 밀접한 관계가 있는 개념인 것은 맞지만, 동의어는 아니고 관점이 서로 다른 개념이라고 보는 것이 적절하다. '패턴'은 반복된 문제 해결 방법론에 가까운 관점이고, '스타일'은 구조적인 특징이나 제약 조건들을 따지는 관점이기 때문.

2010년대 이후 넷플릭스를 필두로 널리 확산된 MSA(Micro Service Architecture)는 소프트웨어 아키텍처 패턴보다는 소프트웨어 아키텍처 스타일에 더 적절한 개념으로 취급되는 편이다.

Model-View-Controller (모델-뷰-컨트롤러).

애플리케이션을 데이터를 처리하는 모델(Model), 사용자에게 보여지는 사용자 인터페이스(UI)를 담당하는 뷰(View), 모델과 뷰 사이에서 흐름을 제어하는 인터페이스를 담당하는 컨트롤러(Controller)로 분리하는 설계 방식이다. 노르웨이의 컴퓨터과학자 트뤼그베 렌스케우(Trygve Reenskaug)가 최초로 정의하여, PC부터 웹 애플리케이션까지 광범위하게 사용되는 디자인 패턴이다.

모델은 컨트롤러에서 호출이 이루어지면, 연동된 데이터베이스에 저장된 데이터를 저장, 수정, 삭제, 가져오기 등 데이터 비즈니스 로직을 처리한다. 그런 다음 뷰는 컨트롤러를 통해 반환된 모델 반환값을 가지고 화면에 출력하여 사용자 인터페이스(UI)를 구성한다. 이때 모델 반환값은 뷰가 저장하지 않는다. 컨트롤러는 모델, 뷰에 관여하며 이들 사이에서 상호 작용하는 인터페이스를 담당한다. 컨트롤러는 모델에게 데이터 비즈니스 로직을 처리하는 명령을 호출하고 그 반환값을 뷰에 전달하여 출력을 하게 한다.

모델과 뷰는 독립적으로 수행되도록 설계되어 있다. 즉, 서로에 대한 디테일을 몰라도 되고, 이는 모델(데이터베이스) 담당과 뷰(사용자 인터페이스(UI)) 담당이 분업을 할 수 있도록 해줌으로써 코드의 가독성, 체계성, 유지 보수성, 재사용성 측면에서 유리하다. 하지만, 컨트롤러를 통해 모델과 뷰를 간접적으로 이어주어 간접적으로 상호 작용하므로, 컨트롤러의 비중이 지나치게 커져서 그만큼 코드의 라인 수가 많아지는 등의 비효율적인 문제점이 존재한다. 그래서 MVP, MVVM과 같은 디자인 패턴이 나온 이유가 바로 MVC의 문제점을 절충하고 보완하기 위해서이다. #

  자세한 내용은 MVVM 문서를 참고하십시오.

MVP(Model-View-Presenter)패턴은 Presenter가 Model과 View 사이의 모든 의존성을 끊어 주는 구조다. View는 사용자 입력을 받아 Presenter에 전달하고, Presenter는 Model과 비즈니스 로직을 호출한 뒤 결과를 다시 View에 전달해 갱신한다.
안드로이드·웹 SPA에서 광범위하게 사용된다.

MVI(Model-View-Intent) 패턴은 단방향 데이터 흐름을 강조한다. 사용자의 Intent(행동)를 받아 이를 Reducer에서 상태 변환(State)을 수행하고, 오직 한 방향으로 View를 다시 그리는 구조다.
Java/Kotlin 기반 모바일 앱이나 Jetpack Compose·ReactNative에서 주로 채택된다.

Layered(계층형) 아키텍처는 프레젠테이션 → 애플리케이션 서비스 → 도메인 → 인프라(데이터 액세스·외부 시스템)처럼 수평 레이어를 두고, 상위 계층이 하위 계층 인터페이스에만 의존하도록 제한한다. 구조가 단순해 엔터프라이즈 Java/.NET 프로젝트의 기본값으로 널리 쓰이며, 책임이 명확해 트랜잭션·보안 등 횡단 관심사를 AOP·필터로 끼워넣기 쉽다. 반면 레이어가 깊어질수록 호출 스택이 길어 성능 병목이 발생한다.

ECS(Entity-Component-System)은 종래 OOP가 속성과 동작을 함께 담고 있는 것에 비해 각 개체(Entity)는 어떤 속성만을 가지고 있다고 선언만 하고 실제 데이터(Component)는 다른 곳에 저장되며 이 데이터를 처리할 로직(System)은 독립적인 곳에 위치한다.
OOP의 문제인 의존성 문제와 멀티스레딩 및 캐시 효율 저하 문제를 해결하기 위해 등장하였으며 그 특성상 게임에서 주로 사용된다.