아키텍처 스타일과 아키텍처 패턴

아키텍처를 공부하다가 아키텍처 스타일과 아키텍처 패턴의 차이를 궁금해 하는 건 누구나 거쳐가는 과정인 것 같다.

실제로 쓸 일이 없거나 딱히 관심이 없으면 사실 스타일이고 패턴이고 알 필요 없겠지만

아키텍처를 내 생각만으로 만드는 것과 그 동안 수많은 설계자들의 수 없는 고민을 거쳐 나온 문제 해결의 지혜를 이용하는 것과 얼마나 차이가 있을까.

(하하 이제 밑의 내용을 보지 않을 수 없다)

그런데 아키텍처 스타일과 아키텍처 패턴의 사용 용도가 정말 다른 걸까? 굳이 차이를 이해해야 하는 건가?

우선 정의를 보자.

아키텍처 스타일 (Architectural Style): 요소와 관계 타입과 더불어 어떻게 사용되는지에 대한 제약사항 집합을 가지는 표준 (Bass, Clements, and Kazman 2003)

아키텍처 패턴 (Architectural Pattern): 소프트웨어 시스템을 위한 근본적인 구조적 조직 스키마의 표현 (Buschmann et al. 1996, p. 12)

패턴은 특정 설계 컨텍스트에서 일어나는 반복되는 설계 문제를 서술하며 잘 증명된 해결을 위한 일반적인 스키마를 보여준다. 해결 스키마는 구성 컴포넌트들과 그들의 책임과 관계 그리고 그들이 콜라보하는 방법을 설명한다.

여기서 아키텍처 패턴의 중요한 점은 문제와 컨텍스트뿐만 아니라 해결책에 초점을 맞추고 있다는 것이다. 

반면 아키텍처 스타일은 아키텍처 접근 방법에 집중하고 언제 스타일이 유용하고 안 유용한지 약간 더 경량화된 가이드라인을 제공하며 이렇게 표현하면 엄청 직관 적이다.

Architecture Pattern: {problem, context} -> architecture approach

Architecture Style: architecture approach

용어의 유래

아키텍처 스타일

1990년 Mary Shaw가 많은 시스템들 중 그가 찾은 반복되는 아키텍처 컨셉을 서술하였고 "소프트웨어 아키텍처를 위한 설계 언어의 요소" 또는 "설계 이디엄"이라고 불렀다. 

1992년 Dewayne Perry와 Alexander Wolf가 Mary Shaw와 같은 의미로 반복되는 아키텍처 컨셉을 찾으며 "architectural style"이란 말을 처음을 사용하면서 지속적으로 사용이 되어 일반화되었다. 

아키텍처 패턴

1996s년 Frank Buschmann과 그의 동료들이 소프트웨어 아키텍처와 디자인 패턴 간 연결을 만들어 냈다. 그가 쓴 책인 'Pattern-Oriented Software Architecture Volume 1: A System of Patterns' (일명 POSA)에서 처음으로 "architectural pattern"이란 말을 사용했다.

디자인 패턴, 아키텍처 패턴 모두 사실 1970년대 Christopher Alexander의 패턴 정의에 기반하고 있다. 

"a three-part rule, which expresses a relation between a certain context, a problem, and a solution" (Alexander 1979, p. 247)

"패턴은 세 가지 규칙으로 특정 컨텍스트, 문제, 해결책 간 관계를 표현한다."

벌써 30년이 지났지만 아직 이 정의는 유효하고 새롭게 만들어지고 있는 패턴들도 여전히 이 세 가지 의미는 가지고 간다. 

그럼 소프트웨어 아키텍처 문서에 스타일이나 패턴을 사용하는 것을 어떻게 기술 할 수 있을까?

이 부분이 중요하다고 생각한다.. 어떤 패턴을 사용하는지도 아키텍트의 설계 결정에 들어 가는데 그럼 그 패턴을 선택한 설계 근거가 명확해야 함은 물론이고, 스타일이나 패턴은 '사용해야지!' 해서 시스템에 바로 적용 되는 것이 아니다. 

스타일과 패턴은 언제 어떻게 사용되는 걸까?

아키텍트는 설계 시작점으로 이 두 가지를 사용할 수 있다. 두 가지 모두 일반적인 해결책을 제공하기 때문에 필수적으로 아키텍트의 개정과 인스턴스화가 필요하다. 

아마도 설계 문서에서는 어떤 패턴을 사용했는지가 서술 될 것이다. 그 다음 왜 사용을 하는지 근거가 서술된다. 이를 테면 패턴인 경우 패턴이 다루는 문제와 컨텍스트가 시스템에서의 문제, 컨텍스트와 얼마나 비슷한가, 스타일이면 왜 이 스타일이 필요한지 설명해야 한다.

[출처]

Clements, Paul, et al. Documenting software architectures: views and beyond. Pearson Education, 2002.