469651
119
189
이미 일전에 포스팅한 바와 같이 작은 사무실하나 오픈해서 사무실 유지비는 조그만한 일을 하면서 벌고 있습니다.
현재하고 있는일은 미국과 한국간의 커뮤니케이션 코디네이팅, 설계, QA 역할을 하고 있고요.
여기에 부과적으로 개발팀의 Agile수행 능력을 향상시키는 교육과 개발 프로세스에 대해 컨설팅을 하고 있습니다.
주당 2일정도 일하고 1달에 사무실 월세와 관리비 정도는 벌고 있지요.
나머지 3일은 저희 회사의 주력업종인 2D 게임 만들기에 투자하고 있습니다.
아마도, 9월정도에는 첫 작품이 나올듯 하네요.
투자금은 조금 넉넉해서 월급가져갈 생각안한다면 1년정도는 시행착오할 정도의 버퍼는 되어 있습니다.
각설하고 최근에 진행했던 Agile 개발팀 교육과 관련한 후기를 정리해봤습니다.
1. 서론
위 그림은 Cynefin 모델입니다.
여기서 부터 출발했습니다. (지난 김창준님의 RT에 참석했을때 배운 모델입니다.)
이 모델은 세상에 존재하는 문제의 유형을 어떤 과정을 거쳐 어떻게 문제를 해결할지 구분한 것입니다.
문제에 대한 구분으로 Simple, Complicated, Complex, Chaotic, Disorder 5가지로 구분할 수 있습니다.
Simple영역에 있는 문제는 인지, 구분, 반응의 3단계 과정을 거쳐 "베스트 프렉틱스"를 만들어 냅니다.
Complicated영역의 문제는 인지, 분석, 반응의 3단계 과정을 거쳐 "굿 프렉틱스"를 만들어 냅니다.
Complex에서는 조사(실험, 탐침), 인지, 반응의 3단계를 거쳐 "창발적인 솔루션"을 만들어 냅니다.
Chaos에서는 행동, 인지, 반응의 3단계를 거쳐 "신기에 가까운 솔루션"을 만들어 냅니다.
Disorder는 어느 영역에도 속하지 않은 문제들입니다.
Chaotic 영역에서 "제한(Limitation)"을 주면 Complex가 됩니다.
Complex에서 "사람(Human)"을 제거하면 Complicated 또는 Simple이 됩니다.
꺼꾸로, Simple이나 Complicated 영역의 문제에 사람을 더하면 Complex가 되고,
Complex에서 제한을 제거하면 Chaos가 됩니다.
김창준님께서는 Effective Enterprise를 예로 들어 설명하셨는데, 제가 다 이해하지 못해서 저는 모든 개발의 기준인 "요구사항"을 예로 들었습니다.
2. 요구사항
* "요구사항"은 무엇으로 이루어 졌는가?
* "요구사항"의 정체는 무엇인가?
2가지 화두로 진행했으며 우리의 토론의 결과와 수 많은 요구사항을 해체한 결과 다음과 같은 결론을 얻었습니다.
a. 요구사항은 기능목록이다.
b. 요구사항은 Spec.을 포함하고 있다.
c. Spec.은 결국 제한조건이다.
이를 다시 Cynefin Model에 대입하자.
놀라운 일이 생겼습니다.
a. 먼저 사람이 참여하고 있기 때문에 개발은 Simple, Complicated 영역에 포함될 수 없다.
b. 요구사항은 제한조건을 포함하고 있기에 Complex 영역에 속하게 된다.
c. 요구사항에 제한조건이 없다면 Chaos 영역에 속하게 된다.
교육받으시는 개발자 분들과의 토론을 통해 위의 Cynefin Model이 맞다는 전제로 요구사항은 Chaos 또는 Complex 영역에 있는 문제라는 사실을 알게 되었습니다.
3. 심화논증
이제 다시 반대로 대입했습니다. Cynefic Model의 특성을 파악했지요.
Complex 영역에 있다면 시험, 실험이 반복되어 창발적 솔루션이 도출되는데 과연 개발이 그러한가? 입니다.
실험에서 우리는 가정을 세우고 그 가정이 맞는지 각종 변수를 바꾸어 가정이 맞는지 틀린지 검증합니다.
그렇다면 개발과정에서 요구사항이 실험에서의 가정이 맞는지 따져야 겠지요.
그 결과, 우리는 요구사항이란 가정과 동일한 특징을 발견했습니다.
a. 가정이 실험결과에 따라 바뀌듯 요구사항은 우리의 경험적으로 바뀌는 특징이 있다.
b. 가정에 실험제한적 요소가 없다면 막막해지듯, 요구사항에 상세한 Spec이 없다면 Chaostic 상태에 빠진다.
c. 가정이 틀리면 수많은 가정이 동시에 따라오듯, 요구사항을 만족하지 못하면 수 많은 요구사항이 추가적으로 발생한다.
또한, 기존의 방법론에서의 접근법은 Completic 또는 Simple 영역의 문제를 해결하는데 만족할지 모르겠지만, Chaostic 또는 Complex 상태의 접근법은 아니다. 따라서, 반복 점진적 방법을 사용하는 Agile은 접근법은 이론적으로 합리적이다.
거기다가, Simple영역에 개발문제가 있다고 가정하더라도 각 영역의 경계선에 있는 Disorder 문제는 어떻게 해야 하는가?에 대한 문제가 그대로 남게된다.
4. 다시 요구사항
따라서, 우리는 계획을 세우고, 진행하면서 무엇을 어떻게 해야하는가?에 대해 약 8시간동안 토론했습니다.
먼저, 요구사항이 맞는지 틀린지 어떻게 검증할 것인가?
우리가 개발 영역의 문제가 대부분 Complex 영역에 있다고 인정한다면 요구사항은 테스트되어야 한다는 의견을 냈습니다. 개발자분들은 동의하셨고 어떻게 테스트되어야 하는가는 2가지 방법을 제안했습니다.
첫째, Mockup을 만들어 보거나 Prototype을 만들어 본다.
둘째, UML 설계를 통해 Use case와 Activity Diagram 을 그려보아서 제대로 그려지는지 확인하는 방법입니다.
요구사항을 검증하고나면 계획은 어떻게 세울것 인가를 같이 고민했습니다.
UML을 Class Diagram과 Sequence Diagram을 그려볼 수 있게 교육을 진행했지요. 아마도 4시간 정도 한것 같았습니다.
먼저 화두는 "뮤비 플레이어 개발"이라는 요구사항을 냈습니다.
이제, 개발자 분들이 다시 물어봅니다. "그건 Chaos한 상태입니다. 제한을 더 주세요."
놀라운 변화였습니다. 어디서 구동할지 어떤 포맷을 지원할지 이야기를 더 해달라는 Feedback이었습니다.
이어 저는 다시 정정했습니다. "이 뮤비플레이는 네비게이션에 내장되어 Avi 포맷만 지원합니다."
이어 USE CASE를 하나그리고 그 USE CASE가 User TEST로 사용이 가능한지 Activity diagram으로 그렸습니다.
* 이 이론은 다음의 모델에 기반합니다.
위의 그림과 조금 상이하지만, 저는 요구사항과 사용자 테스트, 분석/설계와 유닛테스트, 개발로 간단히 그렸습니다.
Activity Diagram을 그리면서 너무 작게 나오거나 크게 나올경우 다시 Use CASE로 올라가 그걸 변경했지요.
적당한 크기가 되자, 다시 Method와 Entity를 구분했고 Entity 구분을 위해 몇가지 이야기가 더 오고갔습니다.
이어 Class Diagram이 완성되고 Sequence Diagram을 완성한 후, 우리는 몇가지 이야기를 더 나누었습니다.
"자 다음시간에는 계획을 같이 할께요." 이 말이 떨어지자, 다들 스스로 그린 그림을 뚫어져라 보시더니, "이게 개발근거군요!"라고 하시더군요. 이어, 제가 맞다고하자. 왜 지금까지 이렇게 교육을 받았는지 알겠다고 했습니다.
그리고 오늘 마지막으로 전체적인 Review와 함께 계획에 대해 교육했습니다.
Function Point와 같은 정형적인 계산방식의 모순을 실증해보기도 했습니다.
예를 들어, 우리가 개발할 시스템에 검색방식이 3가지 인데, 각 각의 방식을 설계한 결과 총 7개의 Method가 도출됐습니다. 그러나 Drag&Drop 검색 방식은 더 구현 난이도가 높았음에도 7개의 Method를 FP에 적용하자, 3가지 모두 같은 점수가 도출되었지요.
결국, 우리는 Planning Poker에 주목하게 되었습니다. 규모를 산정하는데 절대적인 기준치가 아닌, 상대적 기준을 적용했고 이를 다시, 절대적 일정으로 환산하는 방법을 통해 일정을 구할 수 있었습니다.
이후에는 시간관계상 가장 중요한 회고를 말로 떼우며 몇 일간 강행군의 교육을 마쳤습니다.
5. 회고
a. 잘된점 : 처음 문제를 인식하고 동기부여 된 상태에서 교육을 진행할 수 있었음.
b. 잘못된점
- 지나친 긴장으로 굳어진 상태. (아무래도 타사의 대표가 와서 교육한다는게 걸린듯...)
- 편안한 분위기 유도가 잘 안됨.
- 동기부여에 대해 조금 더 노력 필요함.
c. 새로운 사실
- 강요하지 말고 개발자 스스로의 경험에 비춘 판단을 존중하는 성과가 좋았음.
- 기법이 아니라, 주변의 있는 일로 설명
- 역시나, 똑같은 강의를 두번 못함.
* 부연설명-Cynefin 모델에서 문제의 영역이 변화하는 조건에 대한 부연설명.
먼저 인간이 개입되지 않는 문제를 예로 들겠습니다.
인간이 개입되지 않는 문제는 바로 이런류의 문제들입니다.
우리가 기계고장이라 부르는 고장입니다. 2가지 접근법이 필요합니다.
하나는 매뉴얼을 보고 수리해야할 부분을 교체, 수리하는 방법입니다. ==> 이경우 Simple영역으로 분류
또, 다른 하나는 전문가가 살펴보고 분류해서 교체, 수리하는 방법입니다. ==> 이 경우는 Complecated영역으로 분류
하지만, 여기에 사람이라는 인자를 넣으면 조직문제, 문화문제, 인간관계문제, 이혼 등으로 발전합니다.
학자분들께서 이러한 문제를 Complex문제 영역이라고 정의하셨습니다.
(Business 도 결국 인간관계가 바탕이 된다는 전제로 Effective Enterprise라는 새로운 영역의 학문이 나오고 있다고 김창준님께서 소개해주셨습니다.)
여기에 제한조건, 제약조건이 빠지면 이런 문제상태가 됩니다.
전쟁, 화재, 자연재해, 사고 등 일반적인 상식과 법령, 도덕규범이 제거된 상태가 Chaostic상태입니다.
나머지는 Disorder상태로 어디에도 포함될 수 없는 기타 영역입니다.
예를 들어, 개미들 간의 전쟁이 발발하여 한쪽 개미들이 떼죽음을 당하는 문제가 있다고 가정하고 이를 각 영역의 어디에 포함시켜야 할지 고민해본다면 인간이 비포함되어 있지만, 전쟁이라는 상황이므로 저는 Disorder 또는 simple 또는 Complecated영역의 문제로 보겠습니다.
* 예초에 인간의 입장에서는 문제가 아니겠지만, 집안에서 개미들 끼리 전쟁한다면 곤란한 문제가 되지요.
여기에 또하나의 부연설명을 드리자면, 인간은 정형적인 기계적 사고방식을 하는 부품이나 기계가 아니기 때문에 매뉴얼이나 솔루션이 있다고 해서 그걸 들이덴다고 문제가 해결되지 않기 때문입니다.
예를 들어, (이 대목에서 최근에 깨달은 사실이기도 합니다.) 아내와 혹은 아이와 문제가 발생했습니다. 흔히 말하는 불화입니다. (이때는 전쟁과 다르게 최소한 도덕관념, 법률적 제한이 걸린상태이므로 Complex상태가 됩니다.)
이 상황을 해결하기 위해 매뉴얼을 뒤지거나, 가정상담을 받는다고 가정해 보겠습니다.
이렇게 함으로써 이 문제를 단 1방에 해결이 가능할까요?
최근의 저희 집에서의 문제 해결과정을 회고하면 이러한 솔루션 (실버블릿)은 없더군요.
결론부터 말씀드리면, 여러가지 시도를 해보는 수 밖에 없었습니다.
최근에 조심스럽게 내려보는 결론은 인간은 매 시간, 매 분마다 변하는 동물이기 때문이지 않을까요?
예를 들면, 기분이 하루종일 안좋다고 하더라도 필시 하루중 단 몇분은 좋을 때가 있지 않을까요?
즉, 인간이라는 동물은 매뉴얼이나, 솔루션으로 정의될 수 없는 상태이기 때문에 Complex영역에 속하는 문제는 인간이 만들어낸 문제가 아닐까 추정해봅니다.
다시 정리드리자면,
Chaostic = 문제 + 인간문제 - 제한조건
Complex = 문제 + 인간문제 + 제한조건
Complicated = 복잡한 문제 - 인간문제 + 제한조건
simple = 간단한 문제 - 인간문제 + 제한조건
입니다. ^^;;
현재하고 있는일은 미국과 한국간의 커뮤니케이션 코디네이팅, 설계, QA 역할을 하고 있고요.
여기에 부과적으로 개발팀의 Agile수행 능력을 향상시키는 교육과 개발 프로세스에 대해 컨설팅을 하고 있습니다.
주당 2일정도 일하고 1달에 사무실 월세와 관리비 정도는 벌고 있지요.
나머지 3일은 저희 회사의 주력업종인 2D 게임 만들기에 투자하고 있습니다.
아마도, 9월정도에는 첫 작품이 나올듯 하네요.
투자금은 조금 넉넉해서 월급가져갈 생각안한다면 1년정도는 시행착오할 정도의 버퍼는 되어 있습니다.
각설하고 최근에 진행했던 Agile 개발팀 교육과 관련한 후기를 정리해봤습니다.
1. 서론
여기서 부터 출발했습니다. (지난 김창준님의 RT에 참석했을때 배운 모델입니다.)
이 모델은 세상에 존재하는 문제의 유형을 어떤 과정을 거쳐 어떻게 문제를 해결할지 구분한 것입니다.
문제에 대한 구분으로 Simple, Complicated, Complex, Chaotic, Disorder 5가지로 구분할 수 있습니다.
Simple영역에 있는 문제는 인지, 구분, 반응의 3단계 과정을 거쳐 "베스트 프렉틱스"를 만들어 냅니다.
Complicated영역의 문제는 인지, 분석, 반응의 3단계 과정을 거쳐 "굿 프렉틱스"를 만들어 냅니다.
Complex에서는 조사(실험, 탐침), 인지, 반응의 3단계를 거쳐 "창발적인 솔루션"을 만들어 냅니다.
Chaos에서는 행동, 인지, 반응의 3단계를 거쳐 "신기에 가까운 솔루션"을 만들어 냅니다.
Disorder는 어느 영역에도 속하지 않은 문제들입니다.
Chaotic 영역에서 "제한(Limitation)"을 주면 Complex가 됩니다.
Complex에서 "사람(Human)"을 제거하면 Complicated 또는 Simple이 됩니다.
꺼꾸로, Simple이나 Complicated 영역의 문제에 사람을 더하면 Complex가 되고,
Complex에서 제한을 제거하면 Chaos가 됩니다.
김창준님께서는 Effective Enterprise를 예로 들어 설명하셨는데, 제가 다 이해하지 못해서 저는 모든 개발의 기준인 "요구사항"을 예로 들었습니다.
2. 요구사항
* "요구사항"은 무엇으로 이루어 졌는가?
* "요구사항"의 정체는 무엇인가?
2가지 화두로 진행했으며 우리의 토론의 결과와 수 많은 요구사항을 해체한 결과 다음과 같은 결론을 얻었습니다.
a. 요구사항은 기능목록이다.
b. 요구사항은 Spec.을 포함하고 있다.
c. Spec.은 결국 제한조건이다.
이를 다시 Cynefin Model에 대입하자.
놀라운 일이 생겼습니다.
a. 먼저 사람이 참여하고 있기 때문에 개발은 Simple, Complicated 영역에 포함될 수 없다.
b. 요구사항은 제한조건을 포함하고 있기에 Complex 영역에 속하게 된다.
c. 요구사항에 제한조건이 없다면 Chaos 영역에 속하게 된다.
교육받으시는 개발자 분들과의 토론을 통해 위의 Cynefin Model이 맞다는 전제로 요구사항은 Chaos 또는 Complex 영역에 있는 문제라는 사실을 알게 되었습니다.
3. 심화논증
이제 다시 반대로 대입했습니다. Cynefic Model의 특성을 파악했지요.
Complex 영역에 있다면 시험, 실험이 반복되어 창발적 솔루션이 도출되는데 과연 개발이 그러한가? 입니다.
실험에서 우리는 가정을 세우고 그 가정이 맞는지 각종 변수를 바꾸어 가정이 맞는지 틀린지 검증합니다.
그렇다면 개발과정에서 요구사항이 실험에서의 가정이 맞는지 따져야 겠지요.
그 결과, 우리는 요구사항이란 가정과 동일한 특징을 발견했습니다.
a. 가정이 실험결과에 따라 바뀌듯 요구사항은 우리의 경험적으로 바뀌는 특징이 있다.
b. 가정에 실험제한적 요소가 없다면 막막해지듯, 요구사항에 상세한 Spec이 없다면 Chaostic 상태에 빠진다.
c. 가정이 틀리면 수많은 가정이 동시에 따라오듯, 요구사항을 만족하지 못하면 수 많은 요구사항이 추가적으로 발생한다.
또한, 기존의 방법론에서의 접근법은 Completic 또는 Simple 영역의 문제를 해결하는데 만족할지 모르겠지만, Chaostic 또는 Complex 상태의 접근법은 아니다. 따라서, 반복 점진적 방법을 사용하는 Agile은 접근법은 이론적으로 합리적이다.
거기다가, Simple영역에 개발문제가 있다고 가정하더라도 각 영역의 경계선에 있는 Disorder 문제는 어떻게 해야 하는가?에 대한 문제가 그대로 남게된다.
4. 다시 요구사항
따라서, 우리는 계획을 세우고, 진행하면서 무엇을 어떻게 해야하는가?에 대해 약 8시간동안 토론했습니다.
먼저, 요구사항이 맞는지 틀린지 어떻게 검증할 것인가?
우리가 개발 영역의 문제가 대부분 Complex 영역에 있다고 인정한다면 요구사항은 테스트되어야 한다는 의견을 냈습니다. 개발자분들은 동의하셨고 어떻게 테스트되어야 하는가는 2가지 방법을 제안했습니다.
첫째, Mockup을 만들어 보거나 Prototype을 만들어 본다.
둘째, UML 설계를 통해 Use case와 Activity Diagram 을 그려보아서 제대로 그려지는지 확인하는 방법입니다.
요구사항을 검증하고나면 계획은 어떻게 세울것 인가를 같이 고민했습니다.
UML을 Class Diagram과 Sequence Diagram을 그려볼 수 있게 교육을 진행했지요. 아마도 4시간 정도 한것 같았습니다.
먼저 화두는 "뮤비 플레이어 개발"이라는 요구사항을 냈습니다.
이제, 개발자 분들이 다시 물어봅니다. "그건 Chaos한 상태입니다. 제한을 더 주세요."
놀라운 변화였습니다. 어디서 구동할지 어떤 포맷을 지원할지 이야기를 더 해달라는 Feedback이었습니다.
이어 저는 다시 정정했습니다. "이 뮤비플레이는 네비게이션에 내장되어 Avi 포맷만 지원합니다."
이어 USE CASE를 하나그리고 그 USE CASE가 User TEST로 사용이 가능한지 Activity diagram으로 그렸습니다.
* 이 이론은 다음의 모델에 기반합니다.
위의 그림과 조금 상이하지만, 저는 요구사항과 사용자 테스트, 분석/설계와 유닛테스트, 개발로 간단히 그렸습니다.
Activity Diagram을 그리면서 너무 작게 나오거나 크게 나올경우 다시 Use CASE로 올라가 그걸 변경했지요.
적당한 크기가 되자, 다시 Method와 Entity를 구분했고 Entity 구분을 위해 몇가지 이야기가 더 오고갔습니다.
이어 Class Diagram이 완성되고 Sequence Diagram을 완성한 후, 우리는 몇가지 이야기를 더 나누었습니다.
"자 다음시간에는 계획을 같이 할께요." 이 말이 떨어지자, 다들 스스로 그린 그림을 뚫어져라 보시더니, "이게 개발근거군요!"라고 하시더군요. 이어, 제가 맞다고하자. 왜 지금까지 이렇게 교육을 받았는지 알겠다고 했습니다.
그리고 오늘 마지막으로 전체적인 Review와 함께 계획에 대해 교육했습니다.
Function Point와 같은 정형적인 계산방식의 모순을 실증해보기도 했습니다.
예를 들어, 우리가 개발할 시스템에 검색방식이 3가지 인데, 각 각의 방식을 설계한 결과 총 7개의 Method가 도출됐습니다. 그러나 Drag&Drop 검색 방식은 더 구현 난이도가 높았음에도 7개의 Method를 FP에 적용하자, 3가지 모두 같은 점수가 도출되었지요.
결국, 우리는 Planning Poker에 주목하게 되었습니다. 규모를 산정하는데 절대적인 기준치가 아닌, 상대적 기준을 적용했고 이를 다시, 절대적 일정으로 환산하는 방법을 통해 일정을 구할 수 있었습니다.
이후에는 시간관계상 가장 중요한 회고를 말로 떼우며 몇 일간 강행군의 교육을 마쳤습니다.
5. 회고
a. 잘된점 : 처음 문제를 인식하고 동기부여 된 상태에서 교육을 진행할 수 있었음.
b. 잘못된점
- 지나친 긴장으로 굳어진 상태. (아무래도 타사의 대표가 와서 교육한다는게 걸린듯...)
- 편안한 분위기 유도가 잘 안됨.
- 동기부여에 대해 조금 더 노력 필요함.
c. 새로운 사실
- 강요하지 말고 개발자 스스로의 경험에 비춘 판단을 존중하는 성과가 좋았음.
- 기법이 아니라, 주변의 있는 일로 설명
- 역시나, 똑같은 강의를 두번 못함.
* 부연설명-Cynefin 모델에서 문제의 영역이 변화하는 조건에 대한 부연설명.
먼저 인간이 개입되지 않는 문제를 예로 들겠습니다.
인간이 개입되지 않는 문제는 바로 이런류의 문제들입니다.
하나는 매뉴얼을 보고 수리해야할 부분을 교체, 수리하는 방법입니다. ==> 이경우 Simple영역으로 분류
또, 다른 하나는 전문가가 살펴보고 분류해서 교체, 수리하는 방법입니다. ==> 이 경우는 Complecated영역으로 분류
하지만, 여기에 사람이라는 인자를 넣으면 조직문제, 문화문제, 인간관계문제, 이혼 등으로 발전합니다.
(Business 도 결국 인간관계가 바탕이 된다는 전제로 Effective Enterprise라는 새로운 영역의 학문이 나오고 있다고 김창준님께서 소개해주셨습니다.)
여기에 제한조건, 제약조건이 빠지면 이런 문제상태가 됩니다.
나머지는 Disorder상태로 어디에도 포함될 수 없는 기타 영역입니다.
예를 들어, 개미들 간의 전쟁이 발발하여 한쪽 개미들이 떼죽음을 당하는 문제가 있다고 가정하고 이를 각 영역의 어디에 포함시켜야 할지 고민해본다면 인간이 비포함되어 있지만, 전쟁이라는 상황이므로 저는 Disorder 또는 simple 또는 Complecated영역의 문제로 보겠습니다.
* 예초에 인간의 입장에서는 문제가 아니겠지만, 집안에서 개미들 끼리 전쟁한다면 곤란한 문제가 되지요.
여기에 또하나의 부연설명을 드리자면, 인간은 정형적인 기계적 사고방식을 하는 부품이나 기계가 아니기 때문에 매뉴얼이나 솔루션이 있다고 해서 그걸 들이덴다고 문제가 해결되지 않기 때문입니다.
예를 들어, (이 대목에서 최근에 깨달은 사실이기도 합니다.) 아내와 혹은 아이와 문제가 발생했습니다. 흔히 말하는 불화입니다. (이때는 전쟁과 다르게 최소한 도덕관념, 법률적 제한이 걸린상태이므로 Complex상태가 됩니다.)
이 상황을 해결하기 위해 매뉴얼을 뒤지거나, 가정상담을 받는다고 가정해 보겠습니다.
이렇게 함으로써 이 문제를 단 1방에 해결이 가능할까요?
최근의 저희 집에서의 문제 해결과정을 회고하면 이러한 솔루션 (실버블릿)은 없더군요.
결론부터 말씀드리면, 여러가지 시도를 해보는 수 밖에 없었습니다.
최근에 조심스럽게 내려보는 결론은 인간은 매 시간, 매 분마다 변하는 동물이기 때문이지 않을까요?
예를 들면, 기분이 하루종일 안좋다고 하더라도 필시 하루중 단 몇분은 좋을 때가 있지 않을까요?
즉, 인간이라는 동물은 매뉴얼이나, 솔루션으로 정의될 수 없는 상태이기 때문에 Complex영역에 속하는 문제는 인간이 만들어낸 문제가 아닐까 추정해봅니다.
다시 정리드리자면,
Chaostic = 문제 + 인간문제 - 제한조건
Complex = 문제 + 인간문제 + 제한조건
Complicated = 복잡한 문제 - 인간문제 + 제한조건
simple = 간단한 문제 - 인간문제 + 제한조건
입니다. ^^;;
