패턴 저자 : 손영수, 오혜성, 양현철, 정승수
소프트웨어 시스템에 있어서 아키텍처는 소프트웨어의 개발이 진행 되면서 지속적으로 성장해 나가며, 고객의 다양한 요구 사항들을 수용할 수 있도록 변화에 대응할 수 있어야만 한다. 높은 품질을 가지는 소프트웨어 시스템을 개발하기 위해서는 계속 진화하는 소프트웨어 시스템의 아키텍처를 실시간으로 확인할 수 있어야 한다. 그러나 현재 알려진 기본적인 방법들로는 이러한 아키텍처 파악이 매우 힘든 것이 현실이다. 그래서 이번에는 소프트웨어 시스템의 아키텍처를 시각화 할 수 있는 다양한 방법들을 패턴으로서 이야기 하고자 한다.
소프트웨어 시스템의 아키텍처는 다양한 사람들이 참여하여 개발하게 되면 처음 의도와는 다른 방향으로 바뀌어질 가능성이 존재하며, 이에 따라서 원치 않았던 잠재적인 아키텍처의 문제들이 발생하거나 추후 확장 가능한 유연한 아키텍처에서 멀어지는 상황이 발생하게 된다. 이러한 상황을 방지하려면 개발을 진행하고 있는 소프트웨어 시스템의 아키텍처를 자주 살펴보고 문제가 발생될 수 있는 부분들을 개선해나가야만 한다.
이러한 소프트웨어 시스템의 아키텍처를 파악하기 위한 방법들은 일반적으로 클래스 다이어그램을 분석하거나 소스 코드를 분석하여 파악하는 방법들이 존재한다. 그러나 이러한 방법들은 여러 단점들을 가지고 있는데 클래스 다이어그램을 기반으로 분석하는 방법의 경우 너무 넓은 시점에서 소프트웨어 시스템을 분석하기 때문에 정확한 아키텍처를 파악하기도 힘들며, 아키텍처적인 문제들을 해결하기에는 너무 적은 정보를 제공한다. 그리고 코드 기반 분석은 클래스 다이어그램 기반 분석과는 달리 너무 작은 시점에서 소프트웨어 시스템을 분석하기 때문에 아키텍처를 파악하는 것이 힘들고, 분석하는 것도 너무 많은 시간이 걸리게 된다. 이렇게 기존의 쉽게 접할 수 있는 방법들로는 소프트웨어 시스템의 아키텍처를 파악하기란 매우 어렵다고 할 수 있다.
그래서 여기에서는 소프트웨어 시스템의 아키텍처를 보다 간편하게 분석할 수 있도록 도와주는 아키텍처 시각화 기법들을 패턴으로써 정리하여, 해당 시각화들을 구현하기 위한 기본적인 방법들을 소개하고, 각각의 시각화 패턴을 활용한 분석들의 장점과 단점들을 소개할 것이다.
아키텍처 시각화 패턴을 위한 로드 맵
앞서 이야기 했던 아키텍처 분석 방법들은 소프트웨어 시스템을 너무 넓은 범위에서 보거나, 너무 좁은 범위에서만 보기 때문에 다양한 문제들이 발생 하였다. 그렇기 때문에 적절한 수준에서 소프트웨어 시스템을 바라보게 되면, 앞서 이야기했던 방법들에서는 찾을 수 없었던 문제점들을 바로 확인할 수 있게 된다. 이러한 적절한 수준으로 사용할 수 있는 분석 방법은 바로 소프트웨어 시스템의 다양한 Metric 정보(소프트웨어 시스템에 대한 아키텍처적인 수치 정보)와 구성요소(도메인)들의 의존성을 분석하는 것이다. 이 방법을 이용하게 되면 소프트웨어 시스템의 아키텍처에 대한 정보들과 여러 문제점들을 다양한 수치 정보로서 바로 파악할 수 있게 되며, 의존성 분석을 통해 얻은 정보로는 실제 소프트웨어 시스템의 아키텍처적인 의존성을 보여주기 때문에 아키텍처 분석이 더욱 용이해지고, 상호 참조와 같은 아키텍처적인 문제점을 찾기에 용이해진다.
하지만 이러한 Metric 정보와 소프트웨어 시스템의 도메인들의 의존성을 분석하기만 하여서는 직관적이고 명시적인 분석결과를 얻을 수 없으며, 전체적인 분석 또한 빠른 시간 안에 할 수 없다. 그렇기 때문에 이러한 문제들을 해결하기 위해서는 Metric 정보와 도메인들의 의존성을 분석 정보들을 단순히 제공하는 것이 아닌 정보들을 시각화하여 분석 하고자 하는 사람이 쉽게 이해할 수 있는 다양한 Chart를 활용하는 형태로 분석 결과를 제공 해야만 한다.
이러한 아키텍처 시각화 기법을 사용하게 되면 코드 분석이나 클래스 다이어그램 분석에 비하여, 초기 비용(시각화 환경 구성 등)이 많이 필요하지만, 소프트웨어 시스템의 아키텍처를 보다 빠르게 분석할 수 있게 되며 잠재적인 아키텍처적인 문제점들을 미리 예방할 수 있도록 도와주며, 더 나아가 아키텍처를 확장 가능한 아키텍처로 유지할 수 있도록 도와주어, 고객의 요구 사항에 쉽게 대응할 수 있도록 해주게 된다.
이러한 형태로 아키텍처 시각화를 구축하기 위해서는 다음과 같이 패턴들을 적용해야 한다.
- 가) Domain Level Classifier 패턴을 기반으로 소프트웨어 시스템의 도메인들을 분류한다.
- 나) Class Relationship Classifier 패턴을 기반으로 분류된 도메인들 간의 객체 지향적인 의존성들을 모두 분류한다.
- 다) 분류된 도메인들과 객체 지향적인 의존성들을 정보들을 바탕으로 Base Metric Extractor 패턴을 활용하여 소프트웨어 시스템의 품질에 관한 Metric 정보들을 추출한다.
- 라) 구성된 Metric 정보와 의존성 정보들을 바탕으로 아키텍처 시각화(Dependency Chart 패턴, Size of Component Chart 패턴, Robert C Martin Chart 패턴, Pollution Chart 패턴)를 표현한다.
그림1. 소프트웨어 시각화를 위한 패턴언어
<그림 1>은 위에서 소개한 절차를 바탕으로 아키텍처 시각화 패턴을 구성하는 다양한 패턴들간의 관계들을 표현한 패턴 구성도(패턴 맵)이다. 앞으로 시각화 패턴을 구축하는 하위 패턴들부터 시작하여, 구체적인 아키텍처 시각화 방법들이 담긴 패턴들을 소개하는 일종의 하향식 접근을 통해 아키텍처 시각화 패턴에 대해서 이야기 하겠다. 추가적으로 여기에서는 설명을 보다 쉽게 하기 위해서 객체 지향 언어 중 Java을 기반으로 예제들을 설명하겠다.
Linda Rising 아주머니가 보낸준 멜로 인해 AsianPLoP이라는 것이 열린다는 정보를 받았고, 충동적으로 지원을 했습니다. 논문이 accept 되었지만, 정말 운인것 같습니다.
이번 PLoP은 Piggyback 패턴(큰 행사뒤에, 연이어 작은 행사를 여는 패턴 – 참가자들이 쉽게 모이기 하기위한 패턴)의 일환으로, 일본의 가장 큰 소프트웨어 공학 학회인 GRACE와 함께 열렸습니다. 우리나라로 하면 정보처리학회 정도 될듯 합니다.
장소는 소프트웨어 진흥원과 유사한 NII(Nataional Institute of Informatics) 라는 곳(진보쵸)에서 열렸습니다. 참가비및 행사비는 일체 무료였습니다.
제가 참가한 프로그램을 중심으로 AsianPLoP을 소개하고자 합니다. 이번 행사는 영어권, 그리고 일본권으로 나누어 진행이 되었습니다. 일본은 일본인 끼리 진행하는 행사가 되어 버렸고, 반대로 영어권은 말 그대로 영어권 사람들이 모였습니다. 미국, 호주, 인도, 그리고 일본 조금, 한국 조금 이렇게 두가지 그룹으로 나뉘어 저자 워크샾이 진행되었습니다.
역시 언어로 인해 소통의 제약을 받는 것은 일본도 마찬가지 인가 봅니다. 아시아 권의 씁쓸함을 같이 느낄 수 있는 행사였죠.
일전에 AsianPLoP에 대해 소개해 드린적이 있는데요. 운좋게 논문이 Accepted 되어서 가볼려구 합니다.
제가 만든 패턴은 아니구요. 회사의 김성 책임님이 만든 아이디어를 저와 다른 분이 잘 다듬어서 논문으로 제출했고, 통과되었습니다. 개인적으로 영어적인 문제를 많이 해결해 주신, James Chang 님에게 감사드립니다.
마소 (마이크로 소프트웨어 ) 2월호에 “조직을 변화시키는 패턴 이야기“라는 주제로 글을 기고했습니다.
지금까지 블로그를 통해 공개한 Fearless Change 포스트를 거의 그대로 올린겁니다. 이미 저의 블로그를 구독하시는 분에게는 싱거운 자료지만, 자료 공유 차원에서 올립니다. 많은 분들에게 도움이 되었으면 하네요 🙂
물론 기고한 글은 모두 저의 지식이 아니며, Linda Rising의 지식과 다양한 분야의 경험을 가진 저희 EVA팀의 지식으로 만들어진 자료입니다. EVA 팀이 없었다면 이렇게 좋은 자료가 나온다는 것은 불가능했을 겁니다. EVA팀 감사합니다.
Half-Push/Half-Polling의 최종본을 공유합니다. 올해 정말 저에게 값진 선물은 PLoP에 참가해 여러가지 문화를 배울수 있었다는 점입니다. 또한 많은 유명 Architect를 만남으로써, 앞으로의 가야할 길과 협력의 중요성을 크게 깨닫게 되었습니다.
제가 패턴 저자가 되었다는 기쁨은 이루 말할수 없습니다. 다른 학회와 달리 논문만 발표하면 끝이 아닌 학회라, 저자 워크샾때 받았던 피드백으로 논문의 내용을 개선해야 했고, 겨우 겨우 최종본이 나왔습니다. TPLoP이라는 PLoP 저널에 실릴지는 모르겠지만, 최종본을 제출했습니다.
Home Networking이 아파트에 들어가는 것을 이해하지 못하는 서구권 문화 때문에 Office Automtation 으로 예를 바꾸고, 패턴의 Context를 좀더 이해하기 쉽게 하기 위해서 배경지식(Backgroud)과 Context를 좀더 명시적으로 적었습니다.
이 논문이 나오기 까지 많은 분의 노력에 감사드립니다. 결코 저 혼자만의 노력으로 나올 수 없는 논문이었습니다.
I Need Feedback.
이번 PLoP 2009에서 받았떤 저희 Half-Push/Half-Polling 패턴의 저자 워크샾에서 받았던 실제 피드백 내용을 정리했습니다. 몇 개가 더 있지만, 영어적인 문제라 뺐습니다. Eduardo 교수님께서 일일이 잡아주셨습니다. Eduardo 교수님 정말 감사합니다.
이걸 참고하셔서 좀더 피드백을 주시거나, 아래의 리스트와 다른 새로운 피드백을 주시면 감사하겠습니다.
드디어 PLoP에 제출한 논문이 Published Paper List에 올라왔습니다. 이거 감회가 무척 새롭네요. 제 블로그를 통해서 제가 직접 만든 패턴을 소개하다니… 여튼 신선하고 기분 좋은 일입니다 🙂
패턴의 이름은 Half-Push / Half-Polling 입니다. (눈치있는 분은 아시겠지만 작명은 “Half-Sync/Half-Async”에서 얻어왔습니다. 🙂 )
패턴의 주 아이디어는 Upgrade시 일반적으로 사용되는 두가지 기법(Push 방식 과 Polling 방식)을 혼합하여 장점은 살리고 단점은 제거한 패턴입니다.
“패턴을 좀더 쉽게 학습하고 실제 프로젝트에 잘 적용할 방법이 없을까요?” 필자가 강의를 마치고 종종 듣는 질문이다. 부족하지만 필자가 공부한 패턴 지식들과 경험들을 합쳐, 독자 여러분에게 패턴을 학습, 활용하기 위한 시행착오를 조금이나마 줄일 수 있는 지름길을 안내하고자 한다.
손 영수 arload@live.com | 데브피아 Architecture 시삽과 Microsoft MVP로 활동 중이며, 데브피아 소프트웨어 공학 스터디인 Eva팀의 리더이다. 부족한 실력이지만 지식을 나눌 때는 누구보다 ‘부자’라는 자부심을 가지고 지식 나눔에 힘쓰고 있다. Pattern 전도사를 꿈꾸고 있으며, PLoP와 같은 Pattern 학회를 국내에 만들기 위해 힘 쏟고 있다.
요즘은 대학교 학부생의 교과 과정으로 들어갈 정도로 패턴은 많은 이들에게 알려져있다.. 하지만 필자 주위에는 패턴을 잘 활용하여, 성공적으로 프로젝트를 마무리 했다거나 좋은 결과를 보았다는 말보다는, 오히려 많은 불신들과 하소연을 들었다. 왜 이런 상황이 발생했을까? 이 글을 통해 독자들이 패턴에 오해를 풀고, 올바른 시선을 가지길 바라며 글을 적는다.
패턴을 대하기 이전에 마음가짐 – 유연성, 확장성
많은 분들과 패턴을 주제로 애기하다 보면, 패턴에 대한 잘못된 관점을 가진 분들을 종종 만난다. 패턴을 통해, 비약적인 성능 향상, 생산성이 증대 될거라 생각하는 분도 있고 심지어 Silver Bullet (은총알)로 생각하는 분도 있다. 물론 제한적인 도메인 안에서 성능, 생산성 향상을 가져 올 수 있는 패턴도 있지만, 패턴 자체의 목적은 유연성과 확장성에 초점을 맞추고 있다.
초창기 객체 지향(80년대)의 가장 중요시 여기는 패러다임은 “Reuse (재사용)” 이였다. 그래서 Component와 같은 이상적인 패러다임이 나오기도 했다. 마치 Lego와 같이 조립만 하면 만들어지는 Legoware를 꿈꾸어 오면서…
하지만 현재 소프트웨어는 어떠한가? 빈번하게 바뀌는 고객의 요구사항, 몇 명 이서 만들 수가 없을 정도로 거대해진 규모, 길어진 소프트웨어 생명주기를 가진 녀석들이 대부분이다. 그렇기 때문에 소프트웨어가 가져야 할 중요한 설계 방향이 재 사용성 보다는 쉽게 변화를 수용할 수 있는 유연성(Flexibility)과 확장성(Extensibility)이 대두되게 되었다. 만약 여러분이 유연성과 확장성에 초점을 맞춘 설계에 관심이 있다면, 패턴은 좋은 도구가 된다. 하지만, 최적화나 성능 개선이 목적이시라면 패턴보다는 알고리즘을 공부하는 것이 더 낫다.
그리고 패턴을 쉽사리 적용하지 못하는 여러 가지 장벽들이 곳곳에 존재한다. 패턴에 대한 불신들이다. 지면상의 제약으로 이 모든 내용을 언급하기가 한계가 있으니 예전에 필자가 마소 2007년 8월호에 기고한 “미워도 다시 보는 패턴 이야기”를 꼭 읽어보길 권한다. 패턴의 정의, 원칙, 참고할만한 설계구조도 설명하고 있다.
2월 기고에 이은 Framework Engineering Part II를 여러분에게 공개합니다.
Part I에 대한 글에 대한 평이 없어서? 과연 좋은 글을 썼는가 다시 의문을 가집니다. 😦
.NET 진영은 Java 진영보다직접 Framework를 구축하는 일 보다는, 사용하는 일이 더 많으니 그러겠지 하고 혼자 생각하고 있습니다. 🙂
여기서 소개한 툴들과 거의 일대일 대칭이 되는 툴들이 Java 진영에도 있으니 Technic 적인 측면보다, Framework를 구축할때 어떠한 것들을 고려해야 되는지 경험과 프로세스 측면에서 저희들의 부족한 글을 이해해 주시길 부탁드립니다.
많이 부족한 지식이지만 조금이나마 다른 분들에게 도움이 되는 글이였으면 좋겠네요 🙂
이번 글은 지난호에 이어 아래의 주제들중 아키텍쳐에 다 못다한 애기부터 다루었습니다.
Architecture 101 