훌륭한 아키텍처란 (2010 버전)?

훌륭한 아키텍처에 대한 물음에 답하기 위해서 우리는 평가를 해야 하고 평가를 위해서는 기준이 있어야 한다. 너무나 간단한 이야기 같지만 아키텍처 평가 문제는 바로 이 기준이 없거나 애매모호 하다는 사실로부터 시작된다. 아키텍처 평가를 위한 기준이라고 할 수 있는 것을 찾기가 어렵다. 아키텍처 설계 과정에서 수행하는 일련의 의사결정은 옳고 그름에 관한 것이 아니라 얼마나 객관적으로 타당한 것인가에 대한 것이다. 따라서 너무나 일반적인 느낌이 드는 그래서 아무도 이의를 제기하지 못하는 두가지 기준 또는 관점을 생각해 보자. 

 

1. 아키텍처 설계 원칙을 지켰는가?

2. 아키텍처 요건을 만족했는가?

1. 아키텍처 설계 원칙을 지켰는가? 

---

목표 시스템 주변에는 여러 이해관계자들이 있다. 이들은 서로 다른 관심사(concern)를 가지고 시스템을 바라본다. 그들에게 관심사는 근심거리에 해당된다. 그리고 그들의 근심거리를 훌륭한 아키텍트가 해결해 주기를 바란다. 화면이 늦게 뜨는 근심거리를 가지고 있었고, 사용자 정보가 보호되지 않는 근심거리를 가지고 있었고, 프로그램을 고칠 때마다 다른 곳에서 문제가 터지는 근심거리를 가지고 있었다. 이러한 근심거리 들은 많은 경우에 서로 충돌이 되는 경향이 있다. 따라서 아키텍트는 시스템 아키텍처 설계 작업 시 처음부터 끝까지 아키텍처 설계 원칙을 일관되게 준수하려 노력한다. 이러한 노력의 궁극적인 목표는 빠르고 간결하고 유연하고 튼튼한 그리고 정보보호가 가능한 시스템을 만드는 것이다. 요즘은 여기에 사용의 편의성도 중요한 목표로 간주한다. 각 시스템 별로 목표 수준은 대동소이하겠지만 대체로 이러한 목표 범주 안에 있다고 볼 수 있다. 

그럼 이렇게 다양하면서도 이상적인 목표를 달성하기 위해서 아키텍처 설계에서 필요한 설계 원칙은 무엇인가? 그 원칙 속에 뭔가 대단한 비밀이 숨겨져 있을 것 같다. 하지만 그 원칙이란 것은 너무나도 평범해서 여기저기 길거리에서 사람들의 발길에 차이는 존재와도 같은 것이다. SW 엔지니어라면 누구나 잘 알고 있는 그런 것들이다. 이러한 원칙은 아키텍처 설계 이전에 모든 SW 설계에 적용되는 원칙이기도 하다. 대체로 다음 두 가지로 정리할 수 있다. 

- 관심사의 분리(Seperation of Concern) 

- 느슨한 결합과 높은 응집도(Loose coupling, High cohesion)

이 원칙은 관심사의 분리 기준에 근거해서 시스템을 하위 수준(level)으로 분해(decomposition)해 나갈 때 지속적으로 적용된다. 분해 수준에 따라서 관심사도 보다 구체적이거나 제한적이 되는 특성을 가진다. 시스템을 바라볼 때, 서브 시스템을 바라볼 때, 서브-서브 시스템을 바라볼 때, 항상 이곳에는 어떤 관심사가 있으며 이것을 어떻게 나누고 어떻게 모아야 하는가 라는 생각으 흐름이 지속된다. 

간단해 보인다. 하지만 어느 수준이 되었든 대상 시스템을 놓고 바라 보았을 때, 그곳에 놓여 있는 이해관계자들의 관심사를 종합하여 일반화 하고 필요하면 우선순위를 부여하고 그에 따라 시스템을 나누는 것은 제대로 하기 어려운 일이다. 경험이 부족한 아키텍트도 이러한 일을 수행할 수 있다. 하지만 문제는 “관심사를 종합하고 일반화 하고 보다 중요한 것과 그렇지 않을 것을 제대로 분리해 내는” 작업은 쉽지가 않다는데 있다. 더 높은 곳에 올라가면 더 멀리 보이는 것고 같은 이치처럼 아키텍트는 경험이 많을수록 더 정확하게 숨어 있는 의미들을 찾아 낼 수 있다. 

개인적으로 아키텍처를 평가할 때 제일 먼저 확인하는 내용이 바로 이런 부분이다. 대상 시스템에 놓여 있는 다양한 관심사를 종합하고 일반화하여 체계적으로 반영했는가? 라는 질문을 끝없이 던지면서 다른 아키텍트가 작업한 내용을 검토한다. 
 

2. 아키텍처 요건을 만족했는가?

---

 

아키텍처 요건은 품질속성(Quality Attribute)이라는 것이 아키텍처 커뮤니티의 확고부동한 원칙이다. 기능요건 역시 아키텍처 설계에 당연히 영향을 준다. 하지만 기능 요건은 고려 대상일 뿐이며 아키텍트가 궁극적으로 해결해야 할 아키텍처 요건은 품질속성과 품질속성 별로 요구하는 기대치를 만족하는 것이다. 물론 품질속성의 범위나 기대치를 정량화해서 표현하는데 많은 애로사항이 있는 것이 사실이다. 그럼에도 우리는 품질속성 목표를 달성하기 위해 아키텍처 설계를 한다. 

제대로 설계된 아키텍처란 목표 시스템이 요구하는 품질속성 목표를 달성한 아키텍처이다. 성능, 보안, 확장성 등과 같은 품질속성 등이 일반적이다. 요건으로써 품질속성 목표를 달성하기가 쉽지 않은 이유는 다음 두 가지 정도로 본다. 

- 품질요건 간에 서로 부정적인 영향을 주는 관계가 있다. 예, 보안과 성능 간의 관계에서 보안수준을 높이면 성능에 부정적인 영향을 준다. 
 

- 품질속성 목표는 한 번의 설계를 통해서 달성할 수 있는 것은 거의 없고 대부분이 여러 단계의 설계 활동을 통해서, 그것도 설계원칙을 잘 지키면서 마지막 단계까지 왔을 때 품질 목표를 달성할 수 있다. 단순히 어떤 아키텍처 패턴 하나를 잘 적용했다고 품질 목표가 달성되는 것이 아니다. 

 

품질 요건을 만족했는가 측면에서 아키텍처를 평가할 때, 일반적으로 보는 것은 아키텍트가 어떤 접근방법을 사용했으면 그 접근방법에서 실질적인 품질목표로 가는 경로는 무엇인가를 확인한다. 접근방법을 다른 표현으로 아키텍팅 프로세스(아키텍처를 설계하는 절차)라고 거창하게(아니 좀 정확하게) 표현할 수 있다. 하지만 아키텍트 커뮤니티에서는 일반적으로 받아들여지는 아키텍팅 프로세스는 아직 보이지 않는다. 따라서 아키텍팅 프로세스는 개인마다 조직마다 저마다의 프로세스를 가지고 작업을 한다. 그래서 더더욱 이 프로세스를 자세하게 보게 된다. 프로세스는 어떤 작업을 위한 사상과 경험이 녹아 있기 때문이다.

아키텍트가 사용하는 아키텍팅 프로세스가 충분한 타당성이 있다면 다음은 그 절차를 따라할 때 아키텍트가 어떤 생각을 가지고 있었는가를 보는 것이다. 좀 더 자세하게 말하면 아키텍처 설계 원칙에 입각해서 문제를 해결하기 위한 절차를 하나 둘 밟아 왔는가이다. 이것 역시 타당하다면 최종 결과를 확인해 본다. 성능 목표는 달성했는가? 예를 들어 성능 목표를 달성하긴 했는데 특정 회사의 솔루션을 사용했고, 그 솔루션은 표준이 아닌 그 회사 고유의 방식을 근거로 만든 것이었을 경우, 우리는 성능 목표는 달성했으나 “느슨한 결합”의 설계 원칙을 깬 것이 되고 결국 품질 목표 달성을 제대로 달성하지 못한 것으로 평가해야 한다. 느슨한 결합이라는 단어는 많은 의미를 내포하고 있다. 여기서는 솔루션 벤더 의존성을 가지게 되었으므로 느슨하지 못한 결합이 된다. 느슨한 결합이라는 것은 결합 대상이 되는 개체를 다른 것으로 바꾸어도 크게 영향을 받지 않는다는 의미로 해석한다. 따라서 여기서는 솔루션을 다른 것으로 변경할 수 없는 상태가 되므로 좋은 아키텍처 설계라고 볼 수 없다. 

품질속성에 대한 평가를 받기 위한 최종 단계에 이르기 까지 다양한 설계 활동이 필요한데 매 단계마다 우리는 설계 원칙을 기억하면서 내가 작업한 내용을 바라 보아야 한다. 그 작업은 서로 상반될 수도 있는 다양한 이해관계자들의 관심사가 투영되는 곳이기 때문이다. 이런 이유 때문에 아키텍처 설계는 초기 작업이 매우 중요하다. 논리적인 구분 단위이면서 동시에 물리적인 구분에 영향을 주는 레이어와 파티션을 정의한다던가, 더 작은 컴포넌트(= 아키텍처 요소)로 분해해 나간 다던가, 적용할 기술을 선택한다던가, 관심사를 어떻게 쪼개 내어 분리하여 적용할 것인가 하는 아키텍서 설계 활동에 있어서 큰 그림에서 작은 그림에 도달하기 까지 우리는 끝없이 원칙이라는 잣대를 들이대어야 한다.  관심사는 적절히 잘 분리 되었으며 그것을 반영한 느슨한 결합이라는 원칙을 잘 지켜가고 있는가? 그리고 그 결과는 원하는 수준에 이르렀는가? 이 아키텍처 적용과 관련된 다양한 원칙을 잘 수립했는가?

모두 “예”라고 대답하는 아키텍트 앞에 서 있다면, “당신은 우리 사회에서 존중받아야 할 훌륭한 아키텍트입니다”라고 공손히 이야기해 주어야 한다. 

아키텍트는 이러한 관점에서 다른 시스템의 아키텍처를 판단한다. 매우 추상적이며 애매모호 하다고 말할 수 있다. 하지만 우리 주변에 존재하는 많은 [Software intensive system]시스템이 존재하고 어떤 시스템은 개발자와 운영자를 괴롭혀 왔고 극소수의 시스템은 모두를 행복하게 해 주었다. 분명히 아키텍처의 좋고 나쁨이 존재하고 있으며 소수의 노련한 아키텍트 만이 그것을 판단할 수 있다. 원칙이라는 것은 늘 멀리에 있고 그 원칙을 깨닫기 위해서는 우리는 멀고 험한 지식과 경험으로 가득한 여정이 필요하다. 오랜 여행 끝에 원칙이란 것이 무엇이며 왜 그토록 멀리 있었는지 깨닫게 된다. 어쩌면 원칙이라는 단어의 정확한 의미가 [충분한 경험과 지식의 축적 후에 깨닫는] 원칙이라는 생각이 든다. 그리고 그렇게 멀리 있는 이유는 그 가치를 더욱 더 멀리 비추기 위해서가 아닐까라고 생각해본다.

싫어하지만 거룩한 말씀을 해야 하는 안타까운...
[마흔살 엔지니어]