개요

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의 관계들을 설명하면서 추가한다.

속성 추출 (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)의 프로젝트 참여시간도 속성이 될 수 있지만, 여기서는 포함하지 않고 나중에 관계 연계 시킬 때 최종 처리하기는 한다.

클래스 간의 관계 인지 (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. 

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)

아래 표는 두가지 조직 체계를 비교 한 것이다.

가장 큰 차이점은 결정과 책임이 어디에 있느냐이다. 모든 것에 대한 결정과 책임이라기 보다는 역할 기반 조직에서 담당자가 책임 져야 하는 역할, 업무, 제품에 대해서 결정권과 책임에 관한 것이다. 요즘과 같이 복잡한 상황에서 상사가 모든 결정을 한다면 결정 시간에 너무 많은 시간이 소요되고 기회를 잃게 되는 경우가 발생할 수 있다. 반대로, 여러 고려 요소로 인해 여러 담당자가 의견이 충돌해서 결정이 되지 않는 경우라면, 이 또한 기회를 놓칠 수 있는 상황이 될 수도 있다.

위계 기반 조직은 실행에 초점을 맞추고 있다. 위의 예와 같이 이해 관계자들의 충돌이 있을 경우, 상위 랭크에 있는 사람이 빠르게 결정을 내리고 실행할 수 있다. 역할 기반 조직은 담당자들의 책임과 아이디어를 통해서 혁신이 일어날 수 있도록 환경을 만들어 주는 것을 목표로 하는 것이 목표이기도 하다.[2]

실제는 어떨까?

이분법적으로 역할 기반 혹은 위계 기반 조직으로 실제 회사를 분류할 수는 없다[3]. 단지, 어느 쪽에 좀 더 치우쳐 있는가가 될 것이다. 위의 내용은 역할과 눈에 보이는 위계에 대해서 중심으로 이야기 했다. 이를 다른 측면으로 보기 위해서 역할 대신 네트워크 측면으로 눈을 돌려 보자. Management 3.0[4]에서는 팀의 설계 측면에서 소통이 네트워크를 따라 흐르기 때문에 기존 결정(Decision-making)을 위한 위계 구조와 정보 흐름을 위한 네트워크가 필요하다고 강조하고 있다.

네트워크와 계층[4]

결국은 팀을 구조화 하기 나름이지만, 사람들이 많아 질 수도록 위계(Hierarchy)가 생기게 된다. 또한, 위계가 있다고 하더라도 네트워크(Network)는 위와 유사한 형태로 생겨나게 되고 이 흐름이 좋을 수록 정보 공유가 원할하게 된다.

정리해 보면...

역할 기반 조직이라는 것은 결국은 위계 보다는 이 네트워크가 활발하게 되게 하고, 위계에서 생기는 권한(Authority) 혹은 의사 결정(Decision-making)권이 위임(Delegation)되어야 하는 것이다. 어느 것이 더 좋은 것인지 가치 판단 보다는 어느 것이 더 적절할 것인지가 맞는 질문이다. 많은 기업들이 급변하는 환경에 적응하기 위해서 창의적인 결과물들을 내기 위한 역할 기반 조직 체계로 가고자 한다. 하지만, 약육강식의 세계에서 역할 기반 조직만으로 살아 남을 수 있을지는 여전히 고민해야 하는 부분일 것이다.

참고 문헌

[1] 실리콘밸리를 그리다 에어비앤비 유호현, https://www.facebook.com/tyzapzi/videos/701114140250462/UzpfSTEwMDAwMDYzMTU5Njc5NDoyMDY2MTE2MTMzNDE5NDIw/

[2]구글과 애플의 조직문화, 역할 조직과 위계 조직, https://www.midashri.com/blog/rank-and-role

[3] '구글'과 '애플'의 조직 문화는 어떻게 다를까?, https://www.huffingtonpost.kr/svillustrated/story_b_18925876.html?ncid=engmodushpmg00000003

[4] Jurgen Appelo, "Management 3.0- Leading Agile Developers, Developing Agile Leaders," Addison-Wesley (한국어판, 조성빈 역)

더 읽어 보기

위계 조직과 역할 조직, https://brunch.co.kr/@svillustrated/6

대기업 Aaron과 실리콘 밸리 Bryan, https://brunch.co.kr/@svillustrated/12

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)

위의 그림은 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는 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개의 큰 대들보로서, 이론과 실천 병행해야겠다.

References

[1] Management 3.0: The furture of Management and Leadership, https://management30.com/

[2] 매니지먼트 3.0: 새로운 시대, 애자일 조직을위한 새로운 리더십, 위르헌 아펄로 지음, 조승빈 옮김

[4] Martie, https://management30.com/workshops/foundation-workshop/#martie