우리는 아키텍처라는 말을 자주 사용합니다. “내가 만든 서비스의 아키텍처는 너무 멋져!”같은 표현을 사용하는 경우도 있죠. 여기서 아키텍처는 무엇일까요. 아키텍처 스타일과는 어떻게 다른가요. 아키텍처 패턴은 또 무엇인가요. 이런 용어들이 혼용되기도 하고 구분하는 게 크게 의미 없을 수도 있습니다. 하지만 알아두면 좋을 거에요. 재밌잖아요!
Introduce - REST
REST를 다들 들어보셨고 논문도 한 번씩 보신 적이 있으실 거예요. 그럼 REST는 무엇인가요? REST를 여러 가지로 이야기할 수 있겠죠. 하지만 이것 하나는 명확합니다. REST는 아키텍처 스타일이에요. REST가 소개된 논문 제목이 기억나시나요? 바로 “Architectural Styles and the Design of Network-based Software Architectures”입니다. REST가 아키텍처 스타일이라는 사실을 알았으니 아키텍처 스타일이 무엇인지 살펴보러 가시죠!
Architectural Style
“An architectural style is a named, coordinated set of architectural constraints.”[1]
아키텍처 스타일을 간단하게 설명하자면 위 문구같이 설명 할 수 있습니다. 이름이 붙어있는 제약사항들의 집합이죠. REST가 대표적입니다. URI를 사용해야 하고, 캐시가 가능해야 하는 등의 제약사항들이 붙어있죠.
아키텍처 스타일을 저 한문장으로 설명할 수는 있지만, 모든 아키텍처 패턴들이 제약사항의 집합인 것은 아닙니다. 로이 필딩의 논문의 Style 챕터[2]를 보시면 더 다양한 아키텍처 스타일에 대한 정의와 사용 사례들을 볼 수 있습니다. 모든 용어가 그러하듯, 사람마다 조금씩 다른 의미로 해석하는 것이 잦습니다. 따라서 이번 글에서는 위에 나와있는 내용으로 정의하고 살펴보세요. 아키텍처 스타일은 1) 이름이 붙어있는 2) 제약사항의 집합입니다.
MSA도 대표적인 아키텍처 스타일입니다. microservices.io의 첫 페이지를 보면 이런 문구가 있습니다.
“Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services”
첫 문장을 읽자마자 우리는 눈치챌 수 있습니다. “이건 아키텍처가 아니라 아키텍처 스타일이구나. 몇가지 규칙이 있겠네?”
아키텍처 스타일은 한가지만 적용해야하는 것은 아닙니다. 그러나 서로 반대되는 스타일들이 있을 수 있고, 잘 맞지 않은 아키텍처 스타일이 있을 수 있습니다. 예를들어 모놀리틱과 MSA를 둘 다 적용하는건 불가능할 수 있습니다.
Architectural Pattern
아키텍처 패턴은 우리가 알고 있는 것들이 많이 있습니다. CQRS나 Repository, DTO, Layered Architecture, Hexagonal Architecture 등이 있습니다. 범위가 다양하지만, 하나하나 살펴보죠.
일단 아키텍처 패턴에 대하여 정의를 내려야 할 것 같습니다.
An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context.[3]
아키텍쳐 패턴이란 주어진 상황에서의 소프트웨어 아키텍쳐에서 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션이다. 아키텍쳐 패턴은 소프트웨어 디자인 패턴과 유사하지만 더 큰 범주에 속한다.
이번 정의는 위키피디아에서 가져왔습니다. 아키텍처 패턴은 우리가 아키텍처라고 부르던 많은 것들이 포함되어 있습니다. 우리가 흔히 알고 있는 PoEAA(엔터프라이즈 애플리케이션 아키텍처 패턴 - Martin Fowler)라는 유명한 책에서 소개하는 것들이 바로 이 아키텍처 패턴이죠. 아키텍처 패턴은 아키텍처를 만들어나가는데 중요한 뼈대 역할을 합니다.
PortAndAdapter(aka 헥사고날)아키텍처를 예시로 들어보죠. 클린 아키텍처의 조상이라고 할 수 있는 PortAndAdapter는 아키텍처 패턴입니다[4]. 외부를 Adapter로 표현하고 Port를 통하여 시스템의 내부와 외부를 분리하는 패턴인 것이죠. 이 자체가 아키텍처라고 볼 수는 없습니다.
여기서 우리는 잠시 헷갈릴 수 있습니다. “분명 아키텍처인데 왜 아키텍처가 아니에요?”라는 의문이 있을 수 있죠. 이는 “헥사고날 아키텍처”라는 이름의 아키텍처 패턴이 있기 때문에 그렇습니다. 솔직히 저도 헷갈립니다.
하지만 헷갈리는걸 싫어하는 사람들도 존재하죠. Greg Young이 대표적입니다. Greg Young은 CQRS를 만들어낸 사람인데요. CQRS는 특정한 상황에 특정한 문제를 해결하기 위한 솔루션입니다. 따라서 CQRS는 아키텍처 패턴입니다. [5] 하지만 몇몇 사람들이 CQRS를 아키텍처라고 부르기 시작했고 Greg Young은 이런 글을 작성하였습니다. 그러니 우리는 CQRS를 아키텍처가 아닌 아키텍처 패턴이라고 불러야하는 것이죠.
이러한 아키텍처 패턴은 Martin Fowler의 POEAA나 POSA를 읽어보시면 다양하게 소개하고 있습니다.
Architecture
그럼 아키텍처는 도대체 무엇일까요? 이에대하여 이야기는 정말로 많지만, 제가 좋아하는 예시를 가져오겠습니다.
Architecture is about the important stuff. Whatever that is [6]
아키텍처는 그 무엇이든 중요한 것이라는 이야기입니다. 이 부분은 Whale이 작성해주신 글을 살펴보면 더 이해하기 쉽습니다. [7] (완전 강추에요!!!!!!!!)
우리는 Greg Young의 글에서 아키텍처가 무엇인지 힌트를 얻을 수 있습니다.
There is only one architecture. It is the one of the system you are talking about. It is its own set of trade offs and decisions that have been made. It is how it works. [8]
아키텍처는 우리의 결정과 트레이드 오프의 집합입니다. 건축 메타포를 가져와서 이야기를 이어나가보죠.
건축 메타포
우리는 건물을 설계하는 사람들입니다. 우리는 어떤 요구사항에 맞추어 건물을 지어야 하죠. 우리는 건축 양식(아키텍처 스타일)을 선택할 수 있습니다. 바로크 건축 양식을 사용할 것인지, 현대 건축양식을 사용할 것인지, 혹은 고전 건축 양식, 르네상스 건축 양식을 사용할 건지 고를 수 있죠. 이렇게 건축 양식을 고르면 그 건축 양식을 도입한 건물들은 특징들을 공유하게 됩니다. 그래서 스타일이라고 부르는 것이죠!
우리는 건물에 복도를 놓을 수도 있습니다. 정원을 꾸밀 수도 있고, 문을 어떻게 배치할 것인지도 선택할 수 있습니다. 하지만 이런것들을 미리 준비해놓은 패턴을 적용하면 좋겠죠. 우리는 방을 “복도” 패턴으로 연결합니다. 방은 “문 없음”패턴으로 방끼리 원활한 상호작용이 되도록 합니다. 이렇듯 패턴을 적용하여 우리의 건물을 체계적으로 꾸밀 수 있죠.
이렇게 우리는 여러 고민 끝에 설계도가 나왔습니다. 우리가 만들 건물의 설계도가 하나 나온 것이죠. 이게 바로 아키텍처입니다. 우리가 열심히 결정하고 트레이드 오프를 조절하고, 패턴을 적용했죠.
어느정도 감이 오시나요? 이 건축 메타포가 마음에 드셨다면 “패턴 랭귀지”라는 책을 추천합니다ㅎㅎ
언어가 그렇듯…
하지만 언어가 그렇듯, 사람마다 쓰이는 뜻은 전부 다릅니다. Layerd Architecture를 아키텍처 패턴으로 보는 사람들도 있고, 아키텍처 스타일로 보는 사람도 존재합니다. (만든 사람이 명확히 해주는게 제일 좋지만요ㅠㅠ)
심지어 MSDN에서는 아키텍처 패턴과 아키텍처 스타일을 같은 용어라고 소개하기도 합니다. [9] 당연하겠지만, 용어를 사용할때마다 정의를 하고 사용하는 것이 좋겠지만, 모든 대화에서 그러기는 불가능합니다. 또한 용어 정의는 매우 주관적일 수 있어서 옮고 그름이 없는 문제입니다. 언어의 목적은 의사소통이며, 언어 자체는 사회적 약속이기 때문이죠.
이 글에서 첨부된 글에서도 용어를 정의하면서 용어가 다르게 쓰일 수 있다는 것을 충분히 설명하고있습니다. 특히 [1]과 [3]은 다양한 관점을 같이 소개하고 있어서 이 주제에 대하여 더 알고싶으시다면 직접 읽어보시는걸 추천합니다.
“아키텍처”라는 단어의 정의는 Whale의 블로그[10]를 참고하시거나 PoEAA를 읽으시면 좋을 것 같네요.
그럼 이만 글을 마치겠습니다.
