소프트웨어 아키텍처 스타일이란?

아키텍처와 그 스타일의 차이를 이해해 보자!

건축 아키텍처와 양식

건축에는 다양한 건축 기법, 즉 건축 양식이 있다. 우리는 특정 양식이 적용된 건축물을 통해 그 양식만의 특별함을 느낄 수 있다. 고딕 양식은 하늘 높이 솟은 뾰족한 첨탑과 화려한 분위기를 자아내는 것이 특징이다. 바로크 양식은 돔과 풍성한 장식물이 그 특징이라고 할 수 있다.

고딕 양식: 하늘에 닿을 듯한 첨탑과 화려한 양식

바로크 양식: 웅장함이 돋보이는 돔과 장식의 양식

위의 그림에서 볼 수 있듯이, 건축물은 양식에 따라 그 형태와 의도가 다르다는 것을 알 수 있다. 로이 필딩(Roy Fielding)은 "Architectural Styles and the Design of Network-based Software Architectures"에서 아키텍처 스타일(양식)을 이해하면 설계의 특징을 쉽게 파악할 수 있다고 주장한다.

그렇다면, 아키텍처 스타일이란 무엇이며, 그것이 아키텍처의 설계를 이해하는 데 있어 왜 그토록 중요한 역할을 하는 것일까? 이 질문에 답하기에 앞서, 우리는 먼저 아키텍처란 무엇인지에 대한 정의가 필요하다.

소프트웨어 아키텍처

소프트웨어 아키텍처란 무엇일까? 나의 개인적인 생각으로는 아직까지도 소프트웨어 아키텍처에 대한 사회적 합의가 부족한 느낌이다. 여기서는 위키피디아가 정의하는 소프트웨어 아키텍처와 로이 필딩의 의견을 살펴보겠다. 다만, 소프트웨어 아키텍처의 정의를 원문 그대로 이해한다는 것은 생각보다 꽤 까다롭기 때문에, 의미가 훼손되더라도 좀 더 핵심적인 부분만 다루겠다(맞다 왜곡이다).

소프트웨어 아키텍처는 시스템을 이해하기 위한 구조와 그 구조를 만들기 위한 규칙이다. -- 위키피디아

소프트웨어 아키텍처는 시스템의 실행시점(run-time) 요소(element)들의 추상(abstraction)이다. -- 로이 필딩

위키피디아는 시스템의 구조와 시스템이 따르는 규칙을 강조했다고 볼 수 있다. 그런데 로이 필딩의 정의는 꽤나 난해한 단어들로 구성되어 있다. 우선 이러한 난해한 단어들의 의미부터 파악해보자.

소프트웨어의 실행시점(run-time)은 시스템의 동작을 의미한다. 요소(element)는 시스템의 부품을 의미한다. 소프트웨어에서의 추상(abstraction)은 외부에서 볼 수 있는 부분, 즉 노출된 인터페이스를 의미한다.

이제 로이 필딩의 난해한 정의를 좀더 쉽게 이해할 수 있는 용어로 대체해서 표현해보면 아래와 같다.

"소프트웨어 아키텍처는 시스템의 부품(element)들의 관찰 가능한 동작(runtime)의 특징(abstraction)이다."

로이 필딩의 이러한 정의를 바탕으로 캐시 시스템의 아키텍처를 정의해 본다면 이렇게 말할 수 있을 것 같다. "이 시스템은 첫 번째 실행 이후, 즉 두 번째 동작부터는 훨씬 빠른 실행 속도를 보여준다. 따라서 이 시스템의 중개서버와 웹서버의 실행시점 보여지는 특징(run-time abstraction)은 캐시 시스템의 특징이므로, 이 시스템의 아키텍처는 캐시 아키텍처이다."

참고로 런타임(run-time)의 의미는 말 그대로 프로그램이 실행될 때를 의미하며, 컴파일타임(compile-time)은 컴파일러가 소스코드를 기계어 혹은 바이트코드로 변환(translate)할 때를 의미한다. 따라서 컴파일타임에는 소스코드의 구조적 특성을 이해할 수는 있어도, 프로그램의 동작 특성을 완벽히 이해할 수는 없다.

그런데 로이 필딩의 아키텍처 정의를 이해하기 위해서는 하나의 요소를 더 고려해야 한다. 하나의 시스템은 그 하위의 시스템들의 조합으로 구성된다. 이러한 하위 시스템은 상위 시스템의 입장에서는 그저 하나의 부품(element)이지만, 분명 그 하위 시스템의 행위적 특징 또한 관찰 가능하다. 따라서 이러한 하위 시스템의 행위적 특징 또한 로이 필딩이 정의하는 아키텍처에 해당한다.

즉, 하나의 시스템에는 다양한 추상의 레벨(levels of abstraction)이 존재하며, 각각의 추상의 레벨마다 아키텍처가 존재한다고 볼 수 있다. 그렇다면 이 많은 추상 중 로이 필딩이 말하는 아키텍처는 어떤 레벨의 추상을 의미할까? 로이 필딩은 최상위 레벨의 추상(the highest level of abstraction)에 대한 아키텍처만 다루겠다고 말한다.

이제 이 글에서 말하는 아키텍처는 아래와 같이 정의할 수 있겠다.

아키텍처: 시스템의 최상위 레벨 부품(element)의 행위의 특징

소프트웨어 아키텍처와 스타일

로이 필딩은 소프트웨어 아키텍처에도 스타일이 존재한다고 주장한다. 그리고 이러한 아키텍처 스타일들의 특징을 제대로 이해하고 평가할 수 있다면 특별한 이점을 누릴 수 있다고 말한다.

스타일의 특징을 이해하고 평가할 수 있을 때 어떤 이점이 생길까? 먼저 건축 양식에서는 그 양식의 특징을 이해하고 평가할 수 있을 때 어떤 이점이 발생하는지 생각해 보자.

예를 들어 돔 스타일과 돔을 지탱하기 위한 기둥과 벽의 구조는 이미 많이 쓰여왔기 때문에 그 특징과 주의사항을 쉽게 파악할 수 있을 것이다. 따라서 이러한 건축 패턴들을 조합하여 요구사항에 대략적으로 들어맞는 아키텍처를 쉽게 모델링해 볼 수 있으며, 그 모델을 근거로 하여 실제로 건물을 지어보기 이전에 건축물의 설계 모델을 평가해 볼 수 있게 된다.

소프트웨어 아키텍처에서도 스타일을 정의하고 그 특징을 평가할 수 있다면, 건축 분야와 마찬가지로, 이러한 스타일들의 조합으로 설계되는 소프트웨어 아키텍처 모델 또한 미리 평가해 볼 수 있게 된다.

그렇다면 로이 필딩은 왜 이러한 설계 모델의 평가 방안을 고민하게 되었을까? 그는 웹과 관련된 다양한 요구사항의 홍수 속에서 기존의 아키텍처를 해치지 않는 유의미한 요구사항과 제안들을 식별해서 웹 표준을 개선하는 일을 해야만 했다. 이때 로이 필딩은 올바른 표준을 정의하여 전 세계의 수많은 개발자들이 실현 가능성이 낮은 표준에 의해 고통받는 일이 없도록, 구현해 보기 이전에 평가해 볼 수 있는 방안이 필요했다. 웹이라는 인터넷 기술의 규모와 그 파급력을 생각해 보면, 로이 필딩의 이러한 업적은 실로 대단한 일이 아닌가 한다.

소프트웨어 아키텍처 스타일과 제약

스타일을 만들기 위해서는 특정한 규칙을 따라야 하는데, 이러한 규칙을 제약(constraint)이라고 한다. 건축가(architect)는 자신의 아키텍처 스타일이 준수할 제약을 정의하고, 모든 시스템의 요소들이 이를 따르도록 한다. 아키텍처 스타일이 이러한 제약 조건을 잘 만족하도록 정의되면, 이 스타일을 따르는 시스템은 질서를 갖추게 되고 그 스타일만의 가치를 극대화할 수 있게 된다. 따라서 자신만의 스타일을 만들고자 한다면, 따라야 할 제약을 잘 정의해 보자.

이제 우리는 소프트웨어 아키텍처 스타일을 다음과 같이 정의할 수 있다.

"소프트웨어 아키텍처 스타일은 제약의 집합이다."

제약 그리고 설계 원칙

아키텍처 스타일에 가해지는 제약은 따라야 할 규칙들을 가지고 있다. 그런데 이러한 제약을 왜 준수해야 할까? 로이 필딩은 그 이유(rationale)가 원칙을 지키기 위함이라고 한다. 그렇다면 원칙과 제약에는 어떤 차이가 있는걸까?

우선 원칙의 의미를 정의하자. 원칙은 "근본적인 규칙"을 의미한다. 따라서 원칙은 근본적이기에 범용성과 광역성을 가지는 규칙이라고 할 수 있다. 예를 들어, "착하게 살아야 한다"라는 원칙이 있다고 가정해 보자. 이 원칙은 선함이라는 가치를 발현시키기 위한 규칙인데, 구체적인 행동으로 연결시키기에는 다소 미흡한 면이 있다. 이제 원칙을 특정한 가치를 수호하기 위한, 느슨하지만 어디에나 적용할 수 있는 규칙이라고 받아들여보자.

이러한 느슨함의 아쉬움을 달래기 위해, 우리는 좀 더 따르기 쉬운 구체적인 규칙들을 정의할 수 있다. 예를 들어, "욕을 하지 말아야 한다"와 같은 구체적인 규칙을 만든다면 실질적인 행동에 적용도 가능할 것 같다. 다만 욕만 안 했다고 해서 "착하게 산다"라고 말하기 어렵다. 따라서 여러 개의 규칙이 필요할 수 있고, 이러한 구체적인 규칙들의 모음집을 제약이라고 부른다고 생각할 수 있다.

이제 우리는 스타일을 만들기 위해서는 제약이 필요하며, 제약을 지킨다면 원칙을 따르는 것이고, 원칙을 따르면 추구하는 가치를 얻을 수 있다는 것을 이해하게 되었다. 그렇다면 이러한 소프트웨어 설계 원칙(원문에서는 software engineering principle)에는 어떠한 것들이 있을까? 아래와 같은 원칙들이 있다.

범용성(Generality)

모듈성(Modularity)

추상화(Abstraction)

점진성(Incrementality)

관심사의 분리(Separation of Concerns)

변화의 예측(Anticipation of Change)

엄밀성과 형식성(Rigor and Formality)

결론적 고찰(Concluding Remarks)

이러한 설계 원칙들을 충분히 음미하려면 꽤 많은 시간이 필요하다. 언젠가 기회가 된다면 이러한 설계의 대원칙에 대해서도 다루어보도록 하겠다. (로이 필딩 또한 자세히 다루지는 않았다.)

소프트웨어 아키텍처 스타일의 속성

건축 양식 중 고대 그리스 양식에 대해서 생각해 보자. 고대 그리스 양식의 특징은 굵은 기둥과 대칭성이다.

이러한 건축 양식의 특징을 하나의 패턴으로도 볼 수 있다. 따라서 이러한 패턴을 준수하는 건축물이라면 아마도 유사한 특징을 공유할 것이다. 예를 들어 위의 사진에 나오는 건물은 "튼튼함"이라는 특징을 가질 것 같다.

소프트웨어 아키텍처 스타일을 일정한 규칙, 즉 제약을 따르는 패턴이라고 말할 수도 있을 것 같다. 그렇다면 건축 양식의 패턴이 만들어내는 "튼튼함"과 같은 특징이 아키텍처 스타일에서도 드러나지 않을까? (참고로 로이 필딩은 스타일과 패턴이 유사한 면이 있지만 다르다고 주장한다. 자세한 설명은 생략하겠다.)

건축 양식과 마찬가지로 아키텍처 스타일 또한 고유한 특징을 가진다. 즉, 아키텍처 스타일에 설계 제약을 부여하면 어떤 행동적 특징이 자연스럽게 만들어지는데(induce), 이를 속성(property)이라고 한다. 이러한 속성에는 단순성(simplicity), 가시성(visibility), 재사용성(reusability), 고객 체감 성능(user perceived performance) 등 다양하다. 다음 장부터 좀더 상세히 다루도록 하겠다.

맺음말

지금까지 우리는 아키텍처 스타일, 설계 제약, 원칙, 그리고 속성을 살펴보았다. 또한 설계 제약이 스타일에 고유한 특성, 즉 '속성'을 부여한다는 점도 이해하게 되었다. 이제 어떤 설계 제약들이 존재하는지, 그리고 이러한 제약이 아키텍처 스타일에 어떤 속성을 부여하는지 자세히 알아보겠다.

더 나아가, 이러한 설계 제약과 속성들을 바탕으로 어떤 스타일들이 만들어질 수 있는지 탐구할 것이다. 마지막으로 로이 필딩이 고안한 REST 아키텍처 스타일이 근거로 하는 원칙과 이를 지키기 위한 제약과 속성들을 이해하는 시간을 가지도록 하겠다.

2편 끝