개발자에서 아키텍트로 - 10. 설계 시각화 하기2

10.2 멋진 다이어그램 그리기

훌륭한 다이어그램은 그저 아름다운 그림이 아닙니다. 훌륭한 다이어그램은 아키텍처의 개념적인 토대를 반영한 정확한 모델 입니다. 아키텍트는 상자와 선으로만 그린 다이어그램으로 악명이 높지만, 실상은 추상적으로 그린 수준보다 더 많은 직업이 필요 합니다.

 

다이어그램으로 다양한 설계 아이디어를 보여줄수 있습니다. 다이어그램은 다른 매체보다 사실적으로 아키텍처를 시각화할 수 있습니다. 다이어그램은 멋지게 만들면 모든 사람이 아키텍처에서 더 수월하게 다가올 수 있습니다.

아래처럼 하세요	주의하세요
범례를 만들어서 다이어그램과 연관된 메타모델을 요약한다.	내가 사용하는 용어를 상대가 당연히 알 거라고 단정하지 않는다.(통합 모델링 언어(UML)에서도 함부로 단정하면 안된다.)
구체적인 제목을 붙이고 다이어그램이 어떤 구조를 말하려는지 설명한다.	다이어그램 하나에 모든 내용을 담으려 하지 않는다.
그림에 주석을 붙여서 명료하게 설명한다.	흑백으로 인쇄할 때 주석이 없으질 수 있으니 주의한다.
모든 다이어그램에 일관된 용어를 사용한다.	화려하게 치장하거나 다양한 선과 도형을 사용하지 않는다.
패턴을 시각적으로 보여준다.	설명을 생략하지 않는다.

10.2.1 범례 사용하기

범례를 사용해야 의미 파악이 좋습니다.

 

범례적용전(왼쪽), 범례적용후(오른쪽)

 

위 그림을 보자마자 이 다이어그램은 웹 서비스의 세부 항목들을 다루며, 통신 메커니즘으로 아파치 스리프트를 사용하고 있음을 알 수 있습니다. 이 아키텍처를 받아서 요소별 상세 설계를 진행할 아키텍트는 이런 정보를 원했을 겁니다. 다른 이해관계자는 이 정보를 더 심층적인 대화를 진행할 때의 소재로 활용 할 수 있습니다. 

 

어떤 용어를 사용하든 모든 다이어그램에는 범례가 있어야 합니다. 이 UML은 물론이고 직접 만든 어떤 형태의 다이어그램에서든 마찬가지로 필요합니다. UML을 보는 사람이 모두 UML 표현을 알고 있다고 전제하면 안됩니다. 범례로 이해도를 높여줘야 합니다.

 

10.2.2 패턴 강조하기

이전에 작성했던 내용인데 컴포넌트의 위치를 조금 바꿔봅니다.

 

 

서비스들의 위치를 조금 조정했을 뿐인데 멀티 계층 패턴이라는 사실이 드러났습니다. 이러한 재배치는 그리 의미가 없어 보일수 있지만, 패턴을 보이게 하면 아키텍처에 숨겨진 의도를 상세구현 해야 하는 설계자들이게 전달할 수 있습니다. 예를 들어 REST API가 멀티 계층 패턴이라는 사실을 알고 있따면, 이  API는 데이터 계층에 속한 데이터베이스와는 직접 통신하지 않을 것이라고 예상할 수 있습니다.

 

10.2.3 일관성과 단순함 지키지

다이어그램에서는 점 하나도 의미가 있습니다. 다이어그램 속 요소의 색상, 모양, 방향, 글꼴, 위치가 모두 의미를 가집니다. 보는 사람이 아이디어에 집중할 수 있도록 불피룡한 꾸밈이나 세부사항은 없애야 합니다. 다른 색상이나 모양을 넣고 싶다면, 단순히 다이어그램이 예뻐 보이게 하는 수준이 아니라 다른 아이디어를 강조하기 위해 사용해야 합니다.

 

아이디어를 공유할 땐 일관성이 최고 입니다. 개념적으로 동일한 메타모델을 가진 아이디어가 두개의 다이어그램에 있다면 동일한 모양과 색을 사용해야 합니다. 다이어그램을 그릴 때는 의미 없이 그려 넣는것도 다이어그램을 보는 사람은 색상과 글꼴의 변화에 어떤 의미가 숨겨져 있는지 찾으려고 합니다.

 

다이어그램을 너무 자세히 그려서 보는 사람을 압도하고 혼란스럽게 할 수도 있습니다. 때로는 아이디어를 표현하기 위해 여러 모양의 화살표를 사용하기도 하는데, 화살표가 너무 많아서 의미를 이해하기 어려울 대도 있습니다. 의미를 전달할 수 있는 한, 가장 간단하게 다이어그램을 그려야 합니다.

10.2.4 설명문 넣기

그림은 설명이 함꼐 어울릴 때 가장 보기 좋습니다. 글을 포함하면 뷰의 여러 요소들이 어떻게 결합해 품질 속성을 끌어올리거나 억제하는지, 왜 이렇게 시스템을 설계 했는지 이야기로 풀어서 설명할 수 있습니다. 때로는 다이어그램이 흥미롭지 않습니다. 정작 뭐라도 움직이는 모양을 설명하려면 글을 써야 합니다.

 

아키텍처에 대한 설명은 간단한 표, 텍스트 단락, 글머리 기호, 심지어 내레이션을 포함할 수도 있습니다. 다이어그램은 단지 아키텍처를 설명하는 이야기, 아키텍처가 어디에서 왔는지, 어디로 가고 있는지에 대한 이야기에 시각적으로 도움을 주는 정도라고 생각해 보세요.

10.2.5 직접해보기: 다이어그램 비평하기

• 다이어그램이 어떤 점을 유추할 때 도움이 되나요?
• 다이어그램의 핵심적인 패턴은 무엇인가요? 패턴이 숨겨져 있나요?
• 다이어그램이 내포하는 메타모델은 무엇인가요? 다이어그램이 없어도 그 자체로 이해할 수 있나요?
• 다이어그램은 완성본인가요? 더 단순화해도 여전히 이해할 수 있나요?

아키텍처 명세 언어(ADL)은 특정 모델에 대한 용어를 강제하고 제한함으로써 그림으로 해결하지 못하는 깊이는 분석을 이끌어 냅니다. ADL이 멋지긴 하지만 실무에서 사용할 땐 그리 편하지 않습니다. 단, ADL 자체도 어렵기 때문에 고객이 알기가 어려울수 있습니다. 그래서 정말 필요할 때만 ADL를 사용하라고 말씀드립니다.

 

10.4 마무리

추상적인 아이디어를 공유할 땐 그림을 그리세요. 주저하지 마세요. 스케치를 하면 추상적이었던게 구체적으로 표현되면서 새로운 통찰력이 솟아납니다. 설계 결정이 품질 속성을 어떻게 촉진하는지 설명할 때 시각적인 장치를 이용하면 많은 도움이 됩니다. 이야기와 다이어그램을 통합할수록 소프트웨어 시스템을 보여주는 뷰가 하나씩 나오기 시작 합니다. 모든 뷰는 아키텍처를 보는 창 입니다.