Architecture Pattern VS Architecture Style

 

소프트웨어 아키텍처 설계를 공부하다보니 Architecture Pattern라는 용어와 Architecture Style라는 용어가 혼용되는 것을 보게 되었습니다. 이 둘은 어떤 차이가 있는지, 동의어인지 찾아보고 정리한 내용입니다.

Architectural patterns focus on problem-riented architectural solution, whereas Architectural style focus on structural or behavioral characteristics of related software architectures.

 

아키텍처 패턴은 문제 지향적인 아키텍처 솔루션에 중점을 두는 반면에, 아키텍처 스타일은 관련된 소프트웨어 아키텍처의 구조나 행위 특성에 중점을 둔다고 하는 내용입니다. 뭔가 미묘한 차이가 있는 것 처럼 보입니다.

그런데,

Because the concept of architecture styles is very similar to the concept of patterns, in the field of architecture you can use the terms “styles” and “patterns” synonymously.

 

아키텍처 스타일의 개념과 아키텍처 패턴의 개념이 매우 유사하기 때문에, 이 아키텍처 분야에서는 두 용어를 동의어로 사용할 수 있다고 합니다.

 

저는 이 부분이 헷갈렸고, 아래와 같이 정리를 해보았습니다.

아키텍처 패턴과 아키텍처 스타일의 관계는 실제로 혼란스러울 수 있는 부분입니다. 두 개념이 매우 유사하고, 많은 문헌이나 현업에서 혼용되어 사용되기도 하기 때문입니다.

첫 번째 문단에서 언급된 차이점 (이상적인 구분):

아키텍처 패턴 (Architectural Pattern): 주로 특정 문제(problem-oriented)를 해결하기 위한 검증된 솔루션에 초점을 맞춥니다. 패턴은 특정 문제 상황에서 컴포넌트들의 역할, 책임, 관계, 상호작용 등을 구체적으로 기술합니다. 이 솔루션은 특정 품질 속성을 달성하는 데 도움을 줄 수 있습니다.

예1: MVC 패턴은 사용자 인터페이스와 비즈니스 로직, 데이터 관리의 분리라는 문제를 해결합니다.
아키텍처 스타일 (Architectural Style): 주로 시스템의 구조적 또는 행동적 특징(structural or behavioral characteristics)과 그를 정의하는 제약 조건(constraints)의 집합에 초점을 맞춥니다. 스타일은 아키텍처 패밀리를 정의하는 원칙이나 철학에 가깝습니다. 스타일을 따르면 특정 품질 속성들이 자연스럽게 나타날 수 있습니다.

예2: REST 스타일은 무상태(stateless), 클라이언트-서버, 캐시 가능(cacheable), 계층화 시스템(layered system), 균일 인터페이스(uniform interface) 등의 제약 조건을 갖습니다.

두 번째 문단에서 동의어로 사용할 수 있다고 하는 이유 (실질적인 혼용 및 관점):

밀접한 연관성:

많은 아키텍처 스타일은 그 자체로 특정 유형의 문제에 대한 해결 방식을 내포하고 있습니다. 예를 들어, '계층형 스타일(Layered Style)'은 시스템을 여러 수평적 계층으로 나누는 구조적 특징을 가지며, 이는 동시에 '관심사 분리(separation of concerns)'와 유지보수성 향상이라는 문제를 해결하는 일종의 패턴으로 볼 수도 있습니다.

반대로, 널리 사용되는 아키텍처 패턴은 시스템의 중요한 구조적 특징을 정의하기 때문에 스타일처럼 보이기도 합니다. '마이크로서비스 아키텍처'는 독립적으로 배포 가능한 서비스들로 시스템을 구성하는 패턴으로도 불리지만, 동시에 서비스 간 통신 방식, 데이터 관리 등에 대한 일련의 원칙과 제약을 갖는 스타일로도 간주됩니다.

 

관점의 차이와 추상화 수준:

하나의 아키텍처적 접근법을 설명할 때, 그것이 제공하는 **구조적 원칙과 제약사항에 집중하면 '스타일'**로 표현할 수 있습니다.
동일한 접근법이 **어떤 문제를 해결하고 어떤 이점을 제공하는지에 집중하면 '패턴'**으로 표현할 수 있습니다.
예를 들어 '클라이언트-서버'는 자원 공유와 분산 처리를 가능하게 하는 패턴으로 볼 수도 있고, 클라이언트와 서버라는 두 종류의 컴포넌트와 특정 통신 규칙을 정의하는 스타일로도 볼 수 있습니다.

용어의 진화와 실용적 사용:

소프트웨어 아키텍처 분야에서 이 두 용어는 역사적으로 엄격하게 구분되지 않고 사용되어 온 경향이 있습니다. 특히 "패턴"이라는 용어가 디자인 패턴으로 인해 널리 알려지면서, 아키텍처 수준의 구조적 아이디어에 대해서도 포괄적으로 사용되기도 합니다.
실무에서는 엄밀한 학문적 구분보다는 전달하고자 하는 아키텍처의 핵심 아이디어가 더 중요하기 때문에, 문맥에 따라 두 용어가 혼용될 수 있습니다.

결론적으로, 엄밀히 따지자면 아키텍처 패턴은 '문제와 그에 대한 해결책'에, 아키텍처 스타일은 '구조적 특징과 그것을 정의하는 제약조건들의 집합'에 더 중점을 둡니다. 스타일이 더 큰 틀이나 철학, 또는 아키텍처의 "분위기"나 "모양"을 제시한다면, 패턴은 그 스타일을 구현하거나 특정 문제를 해결하기 위한 구체적인 청사진이나 방법론으로 이해할 수 있습니다.

하지만 많은 경우 이 둘은 서로 밀접하게 연관되어 있고, 하나의 개념이 양쪽의 특성을 모두 가질 수 있기 때문에 맥락에 따라서는 동의어처럼 사용될 수 있는 것입니다. 중요한 것은 "스타일"이든 "패턴"이든 그것이 의미하는 아키텍처적 원리, 구조, 그리고 그것을 통해 얻고자 하는 이점을 이해하는 것입니다. 차이가 있음에도 불구하고 그 경계가 모호하고 많은 개념이 양쪽 특성을 공유하기 때문에 동의어로 사용될 수 있다는 설명이 나오는 것입니다.