여기서는 책[1]의 2장의 내용을 요약한다. 책에서는 여러 이야기가 있지만, 지금가지의 학문의 분석이 전체를 아우르는 접근 방식으로 환원주의(Reductionism)을 기반으로 하고 있다고 설명하고 있다. 하지만, 복잡계의 국지적 상호작용(Local Interaction)으로도 이를 설명할 수 있음을 보인다.
세포 오토마타와 나사조개 껍질 패턴
책에서는 바다 달팽이의 패턴과 세포 오토마타(Cellular Automata)가 유사한 패턴을 보여 주는 것을 보여 준다.
나사조개[2]
세포 오토마타 (Cellular Automata)[3][4] 자신을 기준으로 위 픽셀 그리고 그 위 픽셀의 좌우 픽셀의 정보를 가지고 자신의 색상을 정한다.
Cellular Automata Rule 30[3]
세포 오토마타의 Rule 22의 초기값을 임의로 한 경우, 책[1]에서는 나사조개와 유사한 모양을 만들어 내는 것을 볼 수 있다. 이 처럼 국소적인 상호작용 (Local Interaction)이 전체 패턴을 만들 수 있다.
Cellular Automata with Random Initial Values[1]
시장의 예
시장의 경우는 간단한 예를 기반으로 환원주의 기반의 경쟁적 균형(Competitive Equilibrium)과 저자의 새로운 모델의 하나인 바자 모델(Bazaar Model)을 비교 한다. 수요 측면에서는 40에 구매하려는 구매자 1명, 20에 구매하려는 구매자 3명을 우선 가정한다. 공급 측면에서는 10에 공급하려는 공급자 2명, 30에 공급하려는 공급자 3명을 가정한다. 이 시장에서의 두 모델을 비교 한다. 우선 경쟁적 균형의 경우는 수요 공급 곡선으로 아래와 같이 나타낼 수 있다.
수요 공급 곡선[1]
위 그럼에서는 가격 형성이 20에 되고, 시장에서의 이득은 40으로 예측 된다.
저자의 바자 모델(Bazaar Model)에서는 공급자와 수요자가 임의로 만나서 구매가가 판매가보다 높으면 매매가 일어 나고 시장을 떠난다는 가정의 모델이다. 이런 한 모델의 경우, 2가지 경우가 발생 할 수 있다. 경쟁적 균형과 유사한 경우는 약 1/3 확률로 일어 난다. 이 때 거래는 구매자 40- 공급자 10 (이득 30) 와 구매자 20- 공급자 10 (이득10) 으로 시장 전체의 이익은 40이 된다. 다른 경유는 약 2/3 확률로 구매자 40- 공급자30(이득 10) + 구매자 20- 공급자10의 경우가 2건 발생한다. 이 때 시장 이득은 전체 30이 된다.
결론
위의 두 경우 모두 국조적인 상호작용(Local Interaction)으로도 전체 시스템의 패턴을 만들어 내는 부분을 주목하여 봐야 한다고 책음 이이기 한다.
참고 문헌
[1] 전체를 보는 방법 박테리아의 행동부터 경제현상까지 복잡계를 지배하는 핵심 원리 10가지, 존 밀러 저/정형채, 최화정 역, 에이도스, 2017년 11월 22일 (A Crude Look at the Whole)
이 책[1]은 복잡계(Complex System) 혹은 복잡적응계(Complex Adaptive System, CAS)의 여러 원리를 설명하는 개요서이다. 여기서는 1장 진실한 장소(True Places)의 내용을 살펴 보고 정리한다. 이 책은 John Miller 교수의 저작으로 산타페 연구소와 관련이 있다. 이 책의 제목은 산타페 연구소의 설립자 중 한 분인 Murray Gell-Mann 교수의 말을 인용[2]한 것이다.
지도의 비유와 환원주의
가장 작은 부분에 대한 세밀한 지도가 있으면 유용한 지도가 있다고 생각할 수 있다. 하지만, 잘 생각해 보면 1:1의 지도를 세세하게 만드는 것은 사실 의미 없다. 오히려, 필요 없애 간소화 하는 것이 중요하다. 이러한 측면에서 전체를 구성하는 요소를 자세하게 세분화 하면 전체를 이해할 수 있다는 기존 과학의 접근 방식으로 표현할 수 있는 환원주의(Reductionism)의 꿈이 옳은지에 대해 책은 의문을 던진다. 책에서는 우리 지식이 불완전한 것이 문제가 아니고, 시스템을 이루는 구성요소에 대해 가능한 모든 것을 알고 있을지라도 그 구성요소가 시스템을 이루었을 어떻게 상호 작용하는지를 전혀 모르기 때문에 이해하지 못한다고 설명하고 있다. 이에 새로운 접근 방법, 즉, 복잡성 과학(Complexity Science)의 필요성을 주장하고 있다.
복잡계 특징
이 장에서 복잡계의 특징을 아래와 간단히 소개하고 있다. 순차적으로 작은 예들을 들어가며, 상세 내용을 설명한다.
단순한 요소 간의 국소적 상화 작용(Local Interaction)으로도 원래 요소들과 상당히 동떨어진 전체적인 특성(Global Pattern)이 쉽게 나타날 수 있다
상호작용하는 시스템은 행위자들 사이에서 피드백 고리(Feedback loop)를 만들고, 시스템의 행동 특성을 바꾼다.
패드백은 행위자들의 이질성(Heterogeneity) 정도에 따라 완화 되기도 하고 격화 되기도 한다.
상호작용 시스템은 내부적으로 소음(Noise)가 많은 편인데, 그런 무작위성(Randomness)이 전체적으로는 놀라운 결과를 낳을 수 있다.
상호 작용 네트워크(Network of interaction)는 복잡계의 본질적인 요소이다.
확실하게 정해진 제한 조건을 가진 시스템도 다른 복잡계와 마찬가지로 단순한 관계식으로 주어지는 스케일 법칙(Scaling laws)을 만족한다.
공통의 행동 특성을 보여주기 시작하는 임계상태로의 자기조직화(Self-organizing into critical states)하여 복잡계 특성을 보여주기 시작한다.
피드백(Feedback)
상호작용(Ineraction)의 주요한 양상으로 피드백을 소개하면서 2가지를 이야기 한다.
음의 피드백: 난로 온도 조절을 위한 온도계
양의 피드백: 마이크와 스피커의 예
주식 시장의 예로 두 가지를 설명하고 있다. 2010년 5월 6일의 주식 폭락의 경우는, 15초간의 위기가 있었지만 피드백을 통해서 5초 동안의 거래 중지로 시장이 원상태로 되돌아 왔다고 한다. 하지만, 2008년 경제 붕괴에서는 행위 주체들은 이성적인 결정을 했지만, 시스템을 무너지게 하였다고 한다. 책에서는 실패의 원인을 환원주의로 설명하는데, 현대 경제 이론에서의 환원주의는 모든 소비자들의 행동을 경제 모델 속 단 한 명의 거대 소비자, 즉 ‘대표 행위자’로 기술하여 해석 하기 때문이라고 주장한다.
이질성(Heterogeneity)
이질적 시스템은 천천히 반응하는 경향이 있는 반면, 동질적인 시스템은 변화가 빠르고 오르내림이 심한 편이다.
무작위성(Randomness)
현대 기업 경영에서는 무작위성은 껴안고 가야할 기회라기 보다는 싸워야할 적으로 생각한다.
복잡계에 대한 연구는 그 반대를 보여 준다. 번식할 대의 오류(변이)(Error, Variation)가 자연선택(Selection)으로 끊임없이 이어진다는 개념에 기초한 다윈의 진화론은 무작위성에 바탕을 두고 있음을 알 수 있다.
무작위성을 받아들이려면 시스템에 대한 통제를 약간 포기해야 한다. 피드백의 원리, 이질성, 무작위성이 잘 맞아 떨어진 효과적인 분권화된 의사결정은 복잡계에서 생겨나는 가장 좋은, 오래되었지만 새로운 아이디어 중 하나이다.
집단지성(Group Intelligence)
집단 지성의 예로, 1940년대 말 카를 폰 프리슈(Karl von Frish). 꿀벌의 의사소통 발견 것으로 설명하고 있다. 특히, 새 벌집을 위한 새로운 장소를 찾기 방법을 상세 예로 들고 있다. 이는 군집의 영속 여부를 결정 짓는 중요한 결정으로 분권화 된 과정으로 그 장소가 선별되고 적절히 조사되면서 중앙에서 내려온 어떤 지시도 없이도 상당히 빨리 가장 좋은 장소를 고르는 방법을 설명한다.
네트워크(Network)
복잡성은 행위자의 상호작용이 있는 시스템에서 생긴다. 연결 방법을 바꾸면 전체를지배하는 새로운 행동이 생기곤 한다. 이렇게 볼 때, 상호 작용의 패턴(즉, 네트워크)이 어떻게 행동에 영향을 미치는지 아는 것이 복잡계를 이해하는 기초일 것이다. 이웃끼리 서로 관대하여 잘 섞여 사는 곳은 동질성을 가진 사람들 끼리 모이는 구역들로 쉽게 분리 된다.
스케일 법칙(Scaling law)
1800년대 말부터 생물학자들은 여러 특성이 적당한비율로 조정되면 단순한 방식에 맞춰진다는 것 발견했다. 이를 복잡계에 적용하면 도시나 회사의 크기, 전쟁으로 인한 사망자 수, 책에서 첫 번째 그리고 두 번째 많이 사용되는 단어 수 등의 예측도 가능하다.
협력(Cooperation)
시스템 속 행위자들은 서로 경쟁(Compete)하거나 협력(Cooperate)한다. 경쟁 세상에서도 경쟁 전략을 약간 변형하여 협력이 이루어지게 하는 방법이 있다. 협력하는 사람은 서로를 알아볼 수 있는 의사소통방법을 개발하면 된다. 비협조자를 만났을 대 발생하는 손실을 최소화 하면서 협력으로 인한 이익을 얻을 수 있다.
자기 조직화의 임계성 원리(Self-organizedcriciality)
책상위에 쌓이는 모래더미의 임계상태로 조직화한다고 설명한다. 여기서, 모든 규모의 사태가 가능한데, 모래 사태의 크기 분포는 스케일 법칙으로 설명하고 있다.
결론
이 장에서 내리는 결론으로는 복잡적응 시스템의 핵심은 (행위자들이) 더 나은 결과를 찾는 것이다라고 이야기 하고 있다. 실재로 복잡계는 최선의 해법(Optimal outcome)을 찾기도 하지만, 여전히 차선의 해법(Suboptimal outcome) 찾을 확률도 있다는 것을 언급하고 있다.
참고 문헌
[1] 전체를 보는 방법 박테리아의 행동부터 경제현상까지 복잡계를 지배하는 핵심 원리 10가지, 존 밀러 저/정형채, 최화정 역, 에이도스, 2017년 11월 22일 (A Crude Look at the Whole)
애자일 서적 등에서 많이 사용되는 설명 방법 중 비유(Metaphor)가 있다. 가치와 원칙 관련한 글에서도 빙하 비유(Iceburg Metaphor)를 소개하기도 했다. 여기서는 여러 서적에서 사용한 정원 가꾸기 비유 관련 내용을 정리해 보려 한다. 정원사, 정원 가꾸기와 같은 비유는 일상에서 접하기 쉬운 내용을 통해서 애자일 이론을 쉽게 이해할 수 있는 설명 방법이기도 하다. 이러한 비유가 좋은 점 중에 하나는 비유는 그곳에서 이어지는 생각의 타래, 즉 더 깊은 이해로 가는 입구이기 때문이다.
창덕궁 후원(Secret Garden of ChangDeokGoong Palace)
"XP Explained"에서의 비유
익스트림 프로그래밍(Extream Programming, XP)은 내가 가장 처음 접한 애자일 개발 방법이었다. 짝 프로그래밍(Paired Programming)에 탐복하고 지금도 정말 익스트림(Extream)하게 개발과 배포를 동시에하는 데브옵스(DevOps)와 같은 맥락의 지속 통합(Continous Integration)의 개념을 소개했던 방법론이었다. 무엇 보다도 프로젝트의 일정과 목표도 중요하지만, 개발자 중심으로 관점을 바꾸게 해준 중요한 방법론이었다.
XP Explained(한국에는 익스트림 프로그램으로 번역[1])은 Manifesto for agile software development의 초기 서명자 중 한명이면서 JUnit으로도 유명한 Ken Beck이 저자인 책이다. 이 책에서는 운전하는 방법에 대한 비유도 있지만, 내가 처음 보았던 정원 가꾸기 비유가 포함되어 있다. 원본의 일부를 잠시 살펴 보면 다음과 같다.
No book of gardening, however complete, makes you a gardener. First you have to garden, then join the community of gardeners, then teach others to garden. Then you are a gardener. So it is with XP. Reading the book won't make you an extreme programmer. That only comes with programming in the extreme style, participating in the community of people who share these values and at least some of your practices sharing what you know with others.
애자일 해지기(Being Agile) 위해서는 책에 있는 이론만 한다거나 읽어서만은 안된다는 것이다. 실재로 실행(Practice)도 하고, 다른 애자일 커뮤니티에 참석하고, 애자일 방법론에 대해서 가르치기도 해야 한다. 그래야, 애자일리스트(Agilist)가 될 수 있다.
소프트웨어 장인정신에서의 비유
소프트웨어 장인정신[2][3]은 애자일 접근방법 중 개발자들의 역량을 강조하면서 나오는 활동 중에 하나이다. 많은 애자일 방법론에서는 훌륭한 동료들과 일하는 것을 강조하지만, 어떻게 훌륭한 개발자가 되는지에 대해서는 이야기 하고 있지 않다. 소프트웨어 장인[3]에서도 정원가꾸기에 비유가 있다. 여기서는 코드 개발하는 것이 정원 가꾸기와 유사하다고 설명하고 있다.
Code is organic, not mechanical. Like a garden, code needs constant maintenance. Look after its soil, Remove weeds, Water it, Remove dead plants, plant new ones, and trim or rearrange existing to make healthy, looking nice and whole. With basic and regular maintenance, the garden will always look great if we neglect it, it will require much more effort to make it look good again. Code is no different. we don’t look after it constantly, the code starts to deteriorate as changes and new features are added. Bad design choices, lack of tests, and poor use of languages and tools will make the code rot faster. Gradually, other parts of the code will also be contaminated up to the point that the whole code base is extremely ill, making it painful and costly to maintain it.
소프트웨어 제품을 만들 때, 계속 새로운 기능만 추가 하는 것이 고객을 만족시키는 일이 아닐 것이다. 잡초도 제거하고 물도 주고, 죽은 화초들은 제거하고 새로운 화초를 심기도 해야 한다. 단순히 코드라고 했지만, 소프트웨어 제품으로 본다면 정말 크고 훌륭하게 관리되어 사람들이 돈을 지불하고 관람하는 식물원과 같은 수준을 고려한다면, 어떻게 관리하여야 할지 생각해 볼일이다.
맨먼스 미신에서의 비유
맨먼스 미신은 후배의 책장에 꼽혀 있던 책으로 처음 접했다. 어디선가 보았던 제목이지만, 잠시 펼쳐 보았을 때에는 저자의 내공이 느껴지는 오래된 책이었다. 역시 다시 검색해 보니, 1975년의 책이다. 한글판은 번역이 된지는 얼마 되지 않았다. 이 책에 포함된 점진적 개발(Incremental Development)에서는 소프트웨어를 살아있는 생물에 비유 했다. 그래서, 구축(Build)하는 것이 아니고 키우는(Grow)한다고 이야기 하고 있다. 오래된 책이지만, 현재에도 통용될만한 지혜를 전달하고 있다고 할 수 있다.
So it must be with our software systems (In other words, software system is similar to complex system such as living things). Some years ago Harlan Mills proposed that any software system should be grown by incremental development. That is, the system should first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit it is fleshed out, with the subprograms in turn being developed into actions.
피플웨어에서의 비유
피플웨어[5]에서는 팀 빌딩을을 농업(Argiculture)로 비유 한다.
We stopped talking about building teams, and talked instead of growing them. The agricultural image seemed right. Agriculture isn’t entirely controllable. You enrich the soil, you plant seeds, you water according to the latest theory, and you hold your breath. You just might get a crop; you might not. If it all comes up roses, you’ll feel fine, but next year you’ll be sweating it out again. That’s pretty close to how team formation works.
농업에서 전체를 통제하지 못한다. 대신, 근간이 되는 토양을 푸엉하게 하고, 씨를 뿌리고, 이론에 따라 물도 주고 가꾼다. 하지만, 어떻게 될지는 숨죽이고 기다리는 수 밖에 없다. 수확이 있을 때도 있지만, 그렇지 않을 때도 있다. 안되었다고, 실망하고 있을수만은 없다. 왜 그랬는지 고민도 해야 하지만, 결국 다시 시도해 보는 것이 정답일 것이다.
매니지먼트 3.0에서의 비유
매니지먼트 3.0[6]에서도 조직관련해서 정원에 비유를 제공하고 있다.
. Living systems grow fast in the beginning and then reach a level of maturity. Mature systems don’t need to be looked after as often as the young systems. . When a garden is not managed, it will simply keep growing but in another direction than what was intended. It’s the same with software systems and teams. . Many growing systems have a certain life expectancy. They have a tendency to wither away and die.
생명체가 가지는 특징을 소프트웨어 혹은 조직이 유사하게 가진다는 것이다. 처음 태어났을 때, 급격히 성장하고 성숙하게 된다는 것이다. 또한, 관리하지 않으면 원하는 방향으로 발전하지 못한다는 것이다. 생명체와 같이 마지막에는 죽음을 맞이한다는 경향을 설명한다.
또한, 개발자와 관리자가 정원사와 같이 해야 하는 활동도 설명하고 있다.
. Seed, feed, and nurture the systems .Young systems need more care than mature ones. .Weed out everything that draws energy away from our healthy growing systems . When the time has come, we recognize when to replace the old with the new.
정원에 있는 식물의 생명 주기를 알고 시기에 맞는 관리를 해주고, 필요한 교체 시점 또한 파악해야 한다는 것을 이야기 한다.
정리하면서...
정원의 비유는 소프트웨어 제품, 소프트웨어 개발 조직에 대해서 이해하기 쉬우면서도 명료하게 특징을 잘 설명해 준다. 하지만, 이 비유만으로 모든 것이 설명되지는 않는다. 기본적으로 애자일 이론들과 더 나아가서는 소프트웨어와 개발 조직이 복잡 시스템(Complex System)임을 이해 해야 한다는 것을 한번 더 깨닫게 한다.
참고 문헌
[1] 익스트림 프로그래밍 (Extreme Programming) - 변화를 포용하라 2판, 켄트 벡,신시아 안드레스 저/ 정지호, 김창준 역, 2006년 7월
아들과 아들 친구에게 방학을 이용해서 Python을 가르쳤다. 벌써 한두해 전이라 컴퓨터는 게임이나 그림 그리는데 관심이 있는 아들은 거의 다 잊었던 것 같다. 지나가 듯, 자신이 배우면 C 언어를 배워야 할 것 같다는 이야기를 한다. 요인 즉은 컴퓨터를 잘아는 친구는 C를 알고 있고, 경시 대회 등의 알고리즘 대회에서는 C여야 한다는 것이 주장의 논지이다.
그러다가, 최근에 아래 기사를 보았다[1]. 주장에 틀린 바는 없으나, 내 생각과 다르니 정리해 보고 나의 입장을 한번 정리해 두는 것도 필요해 보인다.
주장의 요지는?
[1]이 그리 길지 않으나, 읽어 봐도 좋겠다. 요지는 새로운 언어들이 장점은 있지만, 여전히 C를 써야 하는 이유가 있다는 것이다.
우선 C는 C++대비해서 C는 미니멀리즘을 가지고 있다는 것이다. 결국 C++은 새로운 언어 특징을 가지도록 성장하고 변화하고 있어서 복잡하다는 것이다. 물론 나도 Simple is best라는 생각을 가지고 있는 사람이기는 하다. 하지만, C는 예전에 읽기 복잡할 정도로 짧게 간략하게 쓰는 것을 특징으로 가지기도 했다는 측면에서 이 미니멀리즘이 읽기 쉽고 이해하기 쉽게 코딩할 수 있게 한다는 것을 의미하지 않는다는 것을 명심하자. 하지만, C가 가지는 간략함은 C++이나 Java로 계승되고 있지 않나 생각한다.
Java나 C#등은 성능 혹은 메모리 관련 비판을 많이 받는다. 이러한 비판이 있다는 것은 시스템 이식성 혹은 메모리 관리의 간편성등의 장점이 있다는 뜻이기도 하다. 이렇다면, C가 가지는 반대편은 바로 메모리 관리 및 성능일 것이다.
Go는 Google에서 발표 하고 최근에 관심을 많이 받는 언어 중에 하나이다. 컴파일 언어로서 웹서비스나 Commandline Utility, Network Service등을 만드는데 채용되고 있다. 하지만, 글에서는 저수준 디바이스 드라이버, 커널 등에 대한 작업에는 C가 필요하다고 주장하고 있다. 사실이다. 하지만, 이런 작업을 하는 시장의 인력 요구는 얼마나 될까?
그렇다면, 결론은???
나는 여전히 같은 결론이다. 컴퓨터 언어를 알고 그것을 어디에 어떻게 사용할 것인가를 따져 봐야 한다. 자신이 시스템이나 성능에 민감한 시스템을 만드는 사람이라면 C를 알아야 한다. 하지만, 그렇지 않고 자신의 분야가 따로 있고, 그 분야가 Software를 전문으로 하는 분야가 아니라고 해보자. 하지만, 원하는 작업을 위한 존재하는 솔루션이 제품으로 제공되지 않는다고 해보자. 그럼, 그것을 만들어야 할 것이다. 이 때, 이 무엇인가 만들어야 하는 초보자라면 Python을 고려하는 것이 좋을 것이다.
위에서 이야기 한 것 처럼 C를 배우기 마음 먹고 기본 사항을 익힌다고 하자. 그렇다면 거기서 멈출 것인가? 새로운 언어를 배우면서 자신을 확장해야 한다. 그렇지 않는다면, 위와 같은 비판을 한다고 하더라도 공허한 주장일 수 있지 않을까?
UML@Classroom[1]의 Chater 4의 9절에 있는 Information System of a University의 예를 본다. 여기서는 요구 사항에서 Class Diagram을 추출하는것을 살펴 볼 수가 있다. 실제 예에서 볼 수 있는 몇가지 테크닉도 포함하고 있으므로, 참고할 만하다.
여기서 사용하는 절차는 요구 사항에서 클래스(Class)를 추출하고, 각 클래스의 속성을 추출한다. 그리고, 마지막으로 클래스 간의 관계를 설정하며 Class Diagram을 완성한다. 이를 한번에 완성하는 것으로 여기서는 설명하고 있지만, 잘 보면 한번에 나온다기 보다는 몇번의 반복을 통해서 완성 되는것이 맞아 보인다. 우선은 여기서는 최종 결과물만을 가지고 설명한다.
요구 사항
책에 포함되어 있는 요구사항까지 번역하는 것은 효용성이 떨어진다. 물론, 한글로 되어 있는 요구사항에서 이를 추출하는것은 또 다른 이야기가 될 수 있다. 하지만, 책의내용을 이해하기 위해서 번역하는 것도 이해도를 떨어 뜨릴 수 있다. 그러므로, 여기서는 우선 요구 사항을 그대로 두고, 살펴 보도록 하자
.
다음이 책에 있는 영문 요구 사항이다.
A university consists of multiple faculties which are composed of various institutes. Each faculty and each institute has a name. An address is known for each institute.
Each faculty is led by a dean, who is an employee of the university.
The total number of employees is known. Employees have a social security number, a name, and an e-mail address. There is a distinction between research and administrative personnel.
Research associates are assigned to at least one institute. The field of study of each research associate is known. Furthermore, research associates can be involved in projects for a certain number of hours, and the name, starting date, and end date of the projects are known. Some research associates teach courses. They are called lecturers.
Courses have a unique number (ID), a name, and a weekly duration in hours.
클래스 추출
첫째, 우리는 클래스를 식별 시스템 대학에서 발생하는 요소를 식별해야합니다. 이것들은 아래 그림과 같다. 요구 사항 중에서 명사로 되어 있는 것들을 추출하면 된다.
A university consists of multiple faculties which are composed of various institutes. Each faculty and each institute has a name. An address is known for each institute.
Each faculty is led by a dean, who is an employee of the university.
The total number of employees is known. Employees have a social security number, a name, and an e-mail address. There is a distinction between research and administrative personnel.
Research associates are assigned to at least one institute. The field of study of each research associate is known. Furthermore, research associates can be involved in projects for a certain number of hours, and the name, starting date, and end date of the projects are known. Some research associates teach courses. They are called lecturers.
Courses have a unique number (ID), a name, and a weekly duration in hours.
아래 결과에서 보면, 대학(University)은 별도의 Class가 아니다. 이는 잊어 버린 것이 아니라, 의도적으로 포함시키지 않은 것이다. 책에서는 대학을 Class Diagram으로 설명하고 있다. 그래서, 모델의 인스턴스에는 대학 내에서 발생하는 객체 (예 : Vienna University of Technology)에 포함된다고 볼 수 있으므로 제외한다고 보면 된다.
Dean (학과장)의 경우도 Class 추출에서는 자세한 설명이 없지만, 의도적으로 빼 놓고진행한 것으로 보인다. 이는 역할(Role)의 특성이 강한 것으로 보고있다. 즉, Faculty의 속성으로 볼 수 있지만, 결국에는 Class의 관계들을 설명하면서 추가한다.
인식된 Class들
속성 추출 (Identifing Attributes)
이제 속성을 사용하여 클래스를보다 자세히 설명 할 수 있다. 클래스의 속성은 아래 그림에 나타나있다.각 속성은 데이터 유형(Data Type)을 가지고 있다. 아래 요구 사항에 서 보이듯이 추출된 클래스의 속성도 클래스의 특징을 나타내는 명사로 추출 될 수있다.
A university consists of multiple faculties which are composed of various institutes. Each faculty and each institute has a name. An address is known for each institute.
Each faculty is led by a dean, who is an employee of the university.
The total number of employees is known. Employees have a social security number, a name, and an e-mail address. There is a distinction between research and administrative personnel.
Research associates are assigned to at least one institute. The field of study of each research associate is known. Furthermore, research associates can be involved in projects for a certain number of hours, and the name, starting date, and end date of the projects are known. Some research associates teach courses. They are called lecturers.
Courses have a unique number (ID), a name, and a weekly duration in hours.
또한 모든 속성의 공개 여부를 공개(Public)로 설정 했으므로 이 단계에서는 외부에서 볼 수있는 속성과 그렇지 않은 속성을 생각할 필요가 없다. Employee 클래스의 속성 counter는 해당 값이 인스턴스에 속하지 않으므로 클래스 속성으로 정의된다. 이 속성은 Employee 클래스의 인스턴스가 생성 될 때 증가힌다.
연구원(Research Employee)의 프로젝트 참여시간도 속성이 될 수 있지만, 여기서는 포함하지 않고 나중에 관계 연계 시킬 때 최종 처리하기는 한다.
속성(Attributes) 추출
클래스 간의 관계 인지 (Identifying the relationship between classes)
클래스간의 관계를 추출하는 방법을 책[1]에서는 2가지로 설명하고 있다.
일반화(Generalizations)
Associations and Aggregations
Generalization의 관점
결국, Administrative Employee와 Research Associate가 Employee의 더 상세한 구체화 이기 때문에 추상 클래스로 만들수 있다. 그리고, 교수(Lecturer)도 Research Associate의 일종이므로 Generalize된 것이라 볼 수 있다. 특히, 아래 요구사항 중 줄 친 항목들이 이 관계를 설명한다고 볼 수 있다.
A university consists of multiple faculties which are composed of various institutes. Each faculty and each institute has a name. An address is known for each institute.
Each faculty is led by a dean, who is an employee of the university.
The total number of employees is known. Employees have a social security number, a name, and an e-mail address. There is a distinction between research and administrative personnel.
Research associates are assigned to at least one institute. The field of study of each research associate is known. Furthermore, research associates can be involved in projects for a certain number of hours, and the name, starting date, and end date of the projects are known. Some research associates teach courses. They are called lecturers.
Courses have a unique number (ID), a name, and a weekly duration in hours.
Generalization
Associations and Aggregations
이 단계가 마지막 단계로 볼 수있고, 완성된 클래스 다이어그램이 아래와 같다. 줄 친 부분들이 이러한 관계들을 설명한다고 볼 수 있다.
A university consists of multiple faculties which are composed of various institutes. Each faculty and each institute has a name. An address is known for each institute.
Each faculty is led by a dean, who is an employee of the university.
The total number of employees is known. Employees have a social security number, a name, and an e-mail address. There is a distinction between research and administrative personnel.
Research associates are assigned to at least one institute. The field of study of each research associate is known. Furthermore, research associates can be involved in projects for a certain number of hours, and the name, starting date, and end date of the projects are known. Some research associates teach courses. They are called lecturers.
Courses have a unique number (ID), a name, and a weekly duration in hours.
완성된 클래스 다이어그램
결론
책에서의 결과물도 좋은 결과물이기는 하지만, 다른 견해가 있을 수 있다는 단서를 달아 놓고 있다. 즉, 정답은 없을 수 있다는 것이다.
참고 문헌
[1] UML@Classroon: An Introduction to Oject-Oriented Modeling 2015 Springer
역할 기반(Role-based)와 위계 기반(Rank-based)조직에 대한 이야기가 주변에 들리기 시작한 것은 벌써 한 두 해 전이다. 회사 내부에서 이야기가 나오기 시작했고, 외부에서도 Facebook[1]을 통해서 듣게 되어 이에 대해서 알아 두어야겠다고 생각이 들었다. 하지만, 둘에 대한 비교만 있지 정보가 충분하지는 않았다. 많은 사람들이 이에 대해서 글을 쓰기 시작했고, 참고 할 만한 내용들이 있는 것들을 여기에 정리해 본다.
Rank vs Role driven [2]
위계기반(Rank-driven) vs. 역할기반(Role-driven)
아래 표는 두가지 조직 체계를 비교 한 것이다.
Rank-driven
Role-driven
조직 예시
애플(Apple)
구글(Google)
결정과 책임 (Decision & Responsibility)
상사(High-Ranker)
담당자
초점(Focus)
실행(Execution),
혁신(Innovation)
특징
일사분란한 군대적 조직 제조 업에 적합
전문성과 다양성
가장 큰 차이점은 결정과 책임이 어디에 있느냐이다. 모든 것에 대한 결정과 책임이라기 보다는 역할 기반 조직에서 담당자가 책임 져야 하는 역할, 업무, 제품에 대해서 결정권과 책임에 관한 것이다. 요즘과 같이 복잡한 상황에서 상사가 모든 결정을 한다면 결정 시간에 너무 많은 시간이 소요되고 기회를 잃게 되는 경우가 발생할 수 있다. 반대로, 여러 고려 요소로 인해 여러 담당자가 의견이 충돌해서 결정이 되지 않는 경우라면, 이 또한 기회를 놓칠 수 있는 상황이 될 수도 있다.
위계 기반 조직은 실행에 초점을 맞추고 있다. 위의 예와 같이 이해 관계자들의 충돌이 있을 경우, 상위 랭크에 있는 사람이 빠르게 결정을 내리고 실행할 수 있다. 역할 기반 조직은 담당자들의 책임과 아이디어를 통해서 혁신이 일어날 수 있도록 환경을 만들어 주는 것을 목표로 하는 것이 목표이기도 하다.[2]
실제는 어떨까?
이분법적으로 역할 기반 혹은 위계 기반 조직으로 실제 회사를 분류할 수는 없다[3]. 단지, 어느 쪽에 좀 더 치우쳐 있는가가 될 것이다. 위의 내용은 역할과 눈에 보이는 위계에 대해서 중심으로 이야기 했다. 이를 다른 측면으로 보기 위해서 역할 대신 네트워크 측면으로 눈을 돌려 보자. Management 3.0[4]에서는 팀의 설계 측면에서 소통이 네트워크를 따라 흐르기 때문에 기존 결정(Decision-making)을 위한 위계 구조와 정보 흐름을 위한 네트워크가 필요하다고 강조하고 있다.
네트워크와 계층[4]
결국은 팀을 구조화 하기 나름이지만, 사람들이 많아 질 수도록 위계(Hierarchy)가 생기게 된다. 또한, 위계가 있다고 하더라도 네트워크(Network)는 위와 유사한 형태로 생겨나게 되고 이 흐름이 좋을 수록 정보 공유가 원할하게 된다.
정리해 보면...
역할 기반 조직이라는 것은 결국은 위계 보다는 이 네트워크가 활발하게 되게 하고, 위계에서 생기는 권한(Authority) 혹은 의사 결정(Decision-making)권이 위임(Delegation)되어야 하는 것이다. 어느 것이 더 좋은 것인지 가치 판단 보다는 어느 것이 더 적절할 것인지가 맞는 질문이다. 많은 기업들이 급변하는 환경에 적응하기 위해서 창의적인 결과물들을 내기 위한 역할 기반 조직 체계로 가고자 한다. 하지만, 약육강식의 세계에서 역할 기반 조직만으로 살아 남을 수 있을지는 여전히 고민해야 하는 부분일 것이다.
Management 3.0[1, 2]은 기존의 경영/관리에 대해서 Agile의 측면에서 지금가지의 이론(Theory)와 실천(Practice)를 제안한다. 여기서 제안하는 Management 1.0은 사람을 부품으로 보고, 효율적인 운용을 위한 방법을 이야기하고 있지만, 창의성을 필요로 하는 업무를 위해서는 적절치 않았다. 2.0에서는 이를 개선하는 제안들이 있었지만, 여전히 1.0을 기반으로 한 것이다. 3.0은 SW 개발과 같은 팀으로 하는 창의적인 작업이 복잡계(Complexity) 혹은 복잡 적응 시스템(Complex Adaptive System, CAS)과 같다는 이론적(Theoredical) 배경을 가지고 어떻게 조직을 운영과 관리할지에 대한 사고 방식 (Midset)이라고 할 수 있다.
여기서는 책[2]에 설명되어 있는 Managment 3.0과 관련된 이론들을 정리한 Management 3.0의 System Body of Knowledge (SBOK)에 대해 살펴 보고, 이를 실천하기 위한 Mideset의 모델은 Martie에 대해서 살펴 본다. 책의 구조는 이론(Theory)와 실천(Practice, 책에서는 실용으로 번역하고 있다)을 병립하며 설명하고 있다. 크게 보면 복잡계 그리고 SBOK가 큰 이론(Theory)라고 하면, 나머지 6가지 관점(View)의 모델로 관리하는 방법(Practice)를 제안한다. 그리고는 6개의 관점에서 다시 이론과 실행에 대해서 반복해 가며 이야기 한다. 마치 프랙탈을 따르는 듯이 책이 흘러간다.
System Body of Knowledge (시스템 지식 체계, SBOK)
System Body of Knowledge
위의 그림은 Management 3.0에서 기본이 되는 System의 BOK이다. 즉, SW 개발 시스템을 위의 이론들을가지고 이해할 수 있다는 것이다. 즉, SW 개발팀 혹은 Creative한 업무를 하는 팀의 속성을 이해하는 이론(Theory)라고 할 수 있다.
우선 시스템을 받치고 있는 두 다리는 일반 시스템 이론(General System Theory)와 Cybernetics(사비버네틱스, 인공 두뇌학) 그리고 Social Network Theory (사회망 이론)이다. 몸을 차지하고 있는 것은 Chaos Theory (혼돈 이론, 카오스 이론)이다. 팔에는 Game Theory(게임 이론), Dynamic System Theory(동적 시스템 이론) 그리고 Artificial Intelegence (인공 지능)이 자리 잡고 있다. 머리에는 Evolutionary Theory (진화 이론), Cellular Automata(세포 자동자), Dissipative Systems(소산계) 등을 설명하고 있다.
위에 이론들은 수학, 물리학, 생물학 등 다양한 분야의 이론들이지만 결국은 복잡계(Complexity System)을 설명합니다. 이는 Software를 계발하는 팀이 Complex Adaptive System(CAS, 복잡적응계)임을 설명하고, 현상들을 설명하게 되는 것입니다.
SBOK가 마룬 인형과 같이 깔끔하고 예쁜 형태가 아닌 덕지덕지 붙여 놓은 모습인 이유는 여러 가지 이론 들 때문에 틀리고 비판 받을 부분이 많다는 것을 의미하기도 한다. 하지만, 다행히도 우리가 이해하지 못했던 여러 가지 내용들을 설득력있게 설명한다는 부분이 매력적이다. 다른 말로 하면, 여전히 부족하고 다듬과 발전시켜가야 하지만 '동작하는' 소프트웨어 알파 버전 같다는 것이다.
Management 3.0 Model: Martie
Martie: 6 View of Management 3.0
위의 Martie는 Management 3.0의 6가지 측면, 뷰(View)를 설명하는 눈이 6개 달린 귀여운 괴물이다. 현재 버전은 초창기 버전보다는 조금 더 귀엽게 생긴 모습으로 바뀌었습니다.
Energize People: 사람들에게 동기부여(Motivation)하기 위한 이론과 실천에 대한 관점.
Empower Team: 팀에게 권한을 부여하며 위임(Delegation)을 하기 위한 이론과 실천에 대한 관점.
Align Constraint: 팀이 자기 조직화 (Self-organizing)하기 위해 경계(Boundary)를 정하기 위한 이론과 실천에 대한 관점.
Develop Competence: 팀원의 역량(Competence)에 대한 이론과 발전 방법에 대한 관점
Grow Structure: Functional Team, Cross-functional team에 대한 설명, 계층(Hierarchy) 그리고 네트워크(Network)에 대한 이론과 팀의 구조 발전에 대한 실천.
Improve Everything: 변화 관리(Change Management)에 대한 이론과 실천
정리해 보면...
Management 3.0에서는 정말 많은 이론과 실천과 관련된 언급을 하고 있어서 필요한 것을 찾기 쉽지 않다. 그리고, SBOK 혹은 Model에서 볼 수 있 듯이 징그럽게 꿰맨 인형이나 팔이 6개인 괴물과 같아 친숙해 보이지 않을 수 있다. 하지만, 어쩌면 우리가 살아가는 현실에 대한 이해에 대한 상황을 잘 묘사하는 것일 수도 있지 않을까?
Management 3.0의 작가는 마지막에 고백한다. 자신이 책에서 이야기 한 것은 틀렸다 라고.
그래도, 배움을 얻었기 때문에 의미가 있다. 즉, 더 이해하려고 해야 한다. 그리고, 행동해야 한다. 왜?
Experience without theory is blind, but theory without experience is mere intellectual play
임마누엘 칸트가 한말이라고 한다. 우리는 여기서 Exprience를 Practice와 대치해도 큰 문제가 없어 보인다. 즉, 이론 없는 경험은 위태롭고, 경험 없는 이론은 공허하다. 그래서, 애자일을 받치는 2개의 큰 대들보로서, 이론과 실천 병행해야겠다.
"팀이 빠지기 쉬운 5가지 함정" 이 책은 절판된 상태이다. 그래서, 구하려면 헌책을 뒤져야 한다. 예전에 구할 수 있는 가격 보다 일반적으로 더 높다. 이는 구하고자 하는 이는 많이 않을지 몰라도 정말 찾아서 보는 이가 있어서 인지, 실재로 구하려 할 때 실재 가격 보다 더 주고 사야만 했다.
책에서는 새로운 CEO가 보드 멤버들을 만나면서어떻게 팀을 만들어 가는지 이야기를 통해 풀어 낸다. 이야기 속에서는 책에서 말하고자 하는 이런을 설명하고 있다. 여기에서는 공동의 목표를 찾아 내는 것만 아니라 이를 향해 나아가면서 맞이하게 되는 5가지 함정을 이야기 하고 이와 관련된 법칙을 설명한다.
팀을 위기에 빠뜨리는 5가지 함정
책에서는 아래와 같이 5가지 함정을 설명하고 있다.
첫번째 함정
신뢰의 결핍
신뢰의 결핍은 팀원들이 동료의 비판을 기꺼이 받아들일 준비가 되어 있지않을 때 생긴다. 진심으로 서로에게 마음을 열고, 상대방의 실수와 약점을 이야기할 수 없는 팀의 구성원들은 신뢰의 기반을 쌓기가 쉽지 않기 때문이다.
두 번째 함정
충돌의 두려움
신뢰 구축의 실패는 충돌의 두려움을 불러온다. 신뢰가 없는 팀은 상대방의 생각에 대해 거리낌 없이 비판을 하는 논쟁을 벌일 수 없기 때문이다. 그들은 솔직하지 못한 토론과 자기방어적인 수사법에만 의존하게 된다.
세 번째 함정
헌신의 결핍
건전한 충돌의 결핍은 헌신의 결핍을 가져온다. 개방적이면서도 치열한 충돌 속에서 서로의 의견을 조율하지 못한다면, 주어진 결정사항을 진심으로 받아들여 매진하기 어렵기 때문이다. 물론 회의 중에 동의한다는 의사는 얼마든지 꾸며 낼 수 있지만 말이다.
네 번째 함정
책임의 회피
헌신을 다해 팀의 목표에 매진하지 않는 사람은 자기 자신이 결과에 책임지지 않는 것은 물론이고 팀의 목표에 어긋나는 결과를 불러일으킨 동료에게 추궁할 수 없게 된다.
다섯 번째 함정
결과에 대한 무관심
서로에 대한 책임을 묻지 못한다면 다섯 번째 함정에 빠지게 된다. 팀원들이 자신의 경력이나 대외 인지도 등 개인적 욕구를 공동 목표 보다 우위에 놓을 때 결과에 대한 무관심이 발생한다.
팀을 성공으로 이끄는 5가지 법칙
이 함정을 반대로 접근하면 팀워크를 높일 수도 있다는 것이 책에서 설명하는 바다.
첫 번째 법칙팀원 간에 서로를 신뢰한다.
두 번째 법칙논쟁이 벌어졌을 때 거리낌 없이 의견 충돌을 일으킨다.
세 번째 법칙한번 내려진 결정과 실행 계획에 헌신을 다해 노력한다.
네 번째 법칙정해진 계획에 어긋나는 행동을 했을 경우 책임을 묻는다.
다섯 번째 법칙공동의 목표를 이루는 데 초점을 맞춘다.
재미 있는 것 중에 하나는 논쟁에 관한 것이다. 즉, 의견에 대한 충돌 관련이다. 대 부분의 경우 충돌을 일으키게 하는 것이다. 하지만, 결정이 내려지면 거기에대해서는 헌신을 한다는 것이 특이한 것이다. 책에서는 "동의하지 말고 헌신하라"라는 말이 있다.
다른 이야기들
책에서는 여러 도구나 설명을 하는데, 아래 내용들은 인상적이어서 추가로 기술해 둔다.
개인사 알기
책에서는 개인사를 알아서 팀원들이 가까와 지는 다섯가지질문을 가지고 있다.
고향은?
형재관계는?
어린시절 즐겼던 취미는?
자라면서 겪은 가장 큰 시련은?
처음 가졌던 직업은?
이와 같은 질문을 통한 이야기는 팀원들을 가깝게 느끼게 한다. 하지만, 이 것만으로 신뢰 관계가 구축되지는 않는다.
신뢰의 구축
신로의 구축은 장점과 약점 찾기, 그리고 의견 충돌을 통한 결정 내리기가 그 부분을 차지하지 않는가 싶다. 책에서는 이러한 과정을 통해서 팀원을 떠나 보내기도 하고 다시 받아들이기도 하면서 단단해 진다고 이해가 된다.
글에서는 어느 것을 선택하든 능숙도(Fluency)를 심화하고 다음 단계로 갈지 고민해야 한다고 한다. 이 때에는 해당 단계 Zone의 Benefit만 볼 것이 아니라, 투자 해야 하는 Investment도 봐야 한다. 그렇지 않으면, 이것이 부채가 되어 어려움을 만들기 때문이다.
여기서는 SEI의 Architecture 설계 [1]에서 설명하는 품질 속성(Quality Attribute)에 대해서 설명한다. 4.4절에서 설명하는 바와 같이 품질 속성(Quality Attribute)이 품질 속성 시나리오(Quality Attribute Scenario)로 구체화 된다. 이를 그림으로 표현하면 아래와 같다. ISO 25010의 경우는 이름이나 분류가 다른 경우도 있으니, 참고 바란다.
이 후에는 [1]에서 설명하는 Quality Attribute들 중요서 주요한 몇가지를 Quality Scenario 형태로 설명한다.
성능(Performance)
성능은 Software System이 가지는 중요한 Quality 중의 하나이다. 이는 [1]의 8장에서 설명한다. 아래는 설명하는 Quality Attribute의 상세히 설명하는 Quality Scenario가 가져야 하는 내용의 일반적인 셜명이다.
. 다양한 동작 모드(Normal, Emergency, Peak Load, Overload)
반응 (Response)
. 도착한 이벤트의 처리하며 다음 내용을 결정한다. . 자극을 처리한다. . 서비스 수준을 변경한다.
측정 (Response Measure)
. 도착 이벤트의 처리시간/양(Latency, deadline, throughput, jitter, miss rate)
변경 용이성 (Modifiability)
변경 용이성은 개발 측면에서 추가적인 요구 사항에 대해서 변경하기 효율성을 의미한다.
시나리오 항목
입력 가능 값
주체 (Source)
End user, developer, system administrator
자극 (Stimulus)
기능 추가/삭제/변경하라는 지시 혹은 품질 속성, 용량 혹은 기술의 변경
대상(Artifact)
코드, 데이터, 인터페이스, 콤포넌트, 자원, 설정(Configuration)
환경 (Environment)
실행시간, 컴파일 시간, 빌드 시간, 시동 시간, 설계 시간
반응 (Response)
다음 중 하나 혹은 여러가지: . 변경을 수행한다. . 변경을 테스트한다. . 변경을 배포한다.
측정 (Response Measure)
다음 중 비용: . 영향받은 대상의 숫자, 크기, 복잡도 . 노력 . 필요한 시간 . 비용 (직접 비용 혹은 기회 비용) . 이러한 변경을 통해 영향 받는 기능이나 품질 속성 . 새롭게 추가되는 결함
가용성(Availability)
가용성은 Software System이 사용자에게 가용한 시근으로 보통 확률로 많이 표시된다. [1]에서도 MTBF / (MTBF + MTTR)로 설명하고 있다. 여기서 MTBF는 Mean Time Between Failure이고, MTTR은 Mean Time To Repair로 하고 있다. 즉, 시스템을 고치는 시간을 제외한 시스템의 사용 가능 시간(MTBF)의 비율을 나타낸다. 여기서 99%의 경우는 Downtime이 연간 3일 15.6시간이고 Cloud에서 동작하는 시스템은 99.9%를 이야기 하는 경우가 많은데 연 8시간 45초로 매우 낮다. 아래는 가용성에 대한 일반적인 Quality Scenario이다.
시나리오 항목
입력 가능 값
주체 (Source)
. 결함/실패의 원인 [시스템 내부/시스템 외부][사람, HW, SW, 장비, 환경]
자극 (Stimulus)
. 발생 결함 [Omission, Crash, Incorrect Timing, Incorrect Response]
대상(Artifact)
. 가용성을 위해 요구되는 자원[프로세서/통신채널/자료저장소/프로세스]
환경 (Environment)
. 결함 또는 실패 발생의 시스템 상태 [Normal Operation, Start up, Shutdown, Repair mode, Degraded operation]
반응 (Response)
실패 방지. 실패 인지: . 실패를 기록한다. . 사용자 및 다른 시스템을 포함하는 적절한 당사제에게 알린다. 실패 복구: . 정의된 규칙에 따로 오류, 실패를 유발한 이벤트 소스를 비활성화 시킨다. . 시스템 중요도에 따라 결정되는 지정된 간격에서 사용할 수 없게 한다. . 정상 모드 또는 성능 저하 모드에서 계속 작동한다.
측정 (Response Measure)
. 시스템이 사용 가능할 때까지의 시간 간격 . 가용성 시간 (99.999%) . 보수 시간 . 비정상 모드에서 동작시간 간격
기타 Quality Attributes
상호 운영성(Interoperability), 보안성(Security), 시험 용이성(Testability), 사용성(Usability) 뿐만 아니라, 다른 속성도 많다. 이는 설계하려는 Software System의 Domain에 따라 달라지기도 한다. 이야기 한데로, System을 분석하다 보면, 위의 품질 뿐 아니라, 다른 품질 속성이 도입되기도 한다. 여기서는 상세히 다루지 않는다. 필요하면, [1] 혹은 [2]를 참조하기 바란다.
마무리 하며
여기서는 SEI에서 이야기하는 주요 Quality Attribute[1]들에대해서 살펴 보았다. 성능(Performance), 변경 용이성(Modifiability) 그리고 가용성(Availability)를 살펴 보았다. 이외에도 Software System에 따라 다른 Quality Attribute들이 있을 수 있다. 각 Quality Attribute는 Quality Scenario로 표시 될 수 있다. 또한 Quality Attribute들은 때에 따라 Functional Requirement가 될 수 있다.
Quality Attribute를 만족하기 위한 Tactics나 Architecture Style들은 따로 논의 한다. Tactics는 Quality Attribute별로 접근하는 방식을 정리해놓은 것으로 [1]에도 설명이 되어 있다. Architecture Style은 Architecture Pattern이라고도 불리는데, 이는 POSA[3]의 책 시리즈에 잘 설명이 되어 있고, Design Pattern 처럼 종류가 다양하다.
Reference
[1] Len Bass, et. al., "Software Architecture in Practice, Third Edition," Addison Wisely, 2012
