집단 사고(group think)는 성격이 유사한 사람들의 집단이 유무형의 압력으로 인해서 반대 의견이나 세밀한 분석에 대한 고려를 무시한채 비합리적인 의사결정이 이루어지는 현상을 말한다. 집단 사고의 대표적인 예로 케네디 정부의 쿠바 침공의 실패를 든다. 케네디 정부는 쿠바 망명인들을 강도높은 훈련을 통해 당시 소련의 지원으로 군사력을 높이려는 쿠바를 침공하는데 결국에는 100여명에 이르는 사상자와 1천 여명의 포로를 쿠바에 안겨주면서 침공 계획은 수포로 돌아가며 카스트로의 입지를 강화시키는 한편 수천만 달러의 지원금과 포로의 교환이라는 수치스러운 결과를 낳게 된다. 그뿐만 아니라, 이러한 계획 실패에 대한 결과는 국내외의 여론의 질타와 함께 멍청한 계획을 세운 케네디 정부의 몫으로 돌아가게 된다.
당시 케네디 정부 내각은 미국내에서도 머리가 좋은 사람들을 장관이나 주요 요직에 앉혔으며, 이들은 결국 성격이 유사한 집단을 형성했고, 당시 쿠바 침공에 대해서 이러한 결과를 낳게 되리라고는 생각하지 못했던 것이다. 하지만, 여기서 좀더 살펴보면, 당시 회의에 참석했던 사람들은 그러한 침공 계획이 타당하지 않더라도 분위기 상 반대의 의견을 내놓치 못했다는 증언을 한다. 집단 사고는 이와 같이 동질성이 높은 조직원들이 외부와의 고립도가 심할때 발생될 수 있으며, 이는 의사결정에 중요한 역할을 하게 된다. 특히, 고위 간부와 같은 높은 직책의 의사 결정에 이러한 집단 사고에 대한 틀을 깨지 못한다면 역시 실패에 대한 책임의 비난은 면치 못할 것이다.
당시 케네디 정부 내각은 미국내에서도 머리가 좋은 사람들을 장관이나 주요 요직에 앉혔으며, 이들은 결국 성격이 유사한 집단을 형성했고, 당시 쿠바 침공에 대해서 이러한 결과를 낳게 되리라고는 생각하지 못했던 것이다. 하지만, 여기서 좀더 살펴보면, 당시 회의에 참석했던 사람들은 그러한 침공 계획이 타당하지 않더라도 분위기 상 반대의 의견을 내놓치 못했다는 증언을 한다. 집단 사고는 이와 같이 동질성이 높은 조직원들이 외부와의 고립도가 심할때 발생될 수 있으며, 이는 의사결정에 중요한 역할을 하게 된다. 특히, 고위 간부와 같은 높은 직책의 의사 결정에 이러한 집단 사고에 대한 틀을 깨지 못한다면 역시 실패에 대한 책임의 비난은 면치 못할 것이다.
Epidemia de Pánico / Panic Epidemy by Eneas |
집단 지성(collective intelligence)은 집단 사고와 달리 다양한 의견이나 견해를 가진 개개인들이 협력과 경쟁을 통해서 지적 능력을 향상시키는 방법을 말하며, 이는 현재 인터넷 상에서 일어나는 다양한 활동을 그 예로 들 수 있다.
프로젝트 내에서도 역시 이러한 집단 사고와 집단 지성의 현상들은 목격할 수 있다. 특히, 위험 관리나 이슈 관리에 있어서 집단 사고를 목격하는 사례를 들면 대부분이 이러한 영역에 있는 문제들은 혼자서 해결하기 어려운 문제들이다. 이는 어느 한 개인에게 문제 해결에 대한 책임을 돌리기에는 너무나도 어렵지만, 프로젝트 내에서 한정된 자원과 시간이라는 측면에서 특정인이나 몇몇 소수에게 이를 맡기게 된다. 또한, 그러한 문제들은 너무나도 전문적이고 고도의 기술을 요하는 것처럼 위장될 수도 있기 때문에 그러한 특정인이나 소수의 목소리에 대해서 함부로 어떠한 반대 의견이나 반론을 펼치기도 어렵게 들린다. 혹은 그러한 반론을 이야기하는 경우에는 그에 대한 대안을 떠넘기기까지 하는 문화에서 함부로 반대 의견을 피력하기란 여간해서는 용기있는 행동이 아니다. 이러한 프로젝트 상황에서 집단 사고의 방식은 그대로 진행될 수 밖에 없으며, 이는 고스란히 개발하는 작업자나 제일 말단에 위치한 사원들의 수많은 수고와 고생으로 넘어가게 된다. 집단 사고가 일어날 수 있는 환경은 시간이 촉박하다는 이유만으로 일어나기는 힘들다. 정치색이 강한 프로젝트일수록 그러한 현상은 일어나기 쉬우며, 다양한 의견을 수용하려는 자세가 무시되기 쉽다.
집단 사고를 피할 수 있는 방식은 반복(iteration)을 통한 학습 내지 피드백을 통한 보완이라는 장치로 어느 정도는 감쇄할 수 있다. SW가 다른 물리적인 문제와 다른 가장 큰 장점이 바로 이러한 것인데, SW를 한번에 구현하는 방식보다는 반복을 통한 구현 방식을 채택한다면 이러한 집단 사고를 어느 정도 방지할 수 있다. 특히나, 해결하기 어려운 문제일수록 반복의 횟수나 강도를 높임으로써 보다 구체적인 형태의 모습으로 만들어가려는 노력이 필요하다. 물론, 다양한 목소리를 수용할 수 있는 집단 지성의 장치를 보완한다면 그러한 방식은 좀 더 탄력을 받을 수 있다.
집단 사고는 또한 개인의 생각을 방해하거나 훼방하는 결과를 낳을 수 있다. 즉, 특정 문제나 이슈에 대해서 '다함께 생각해보자'라는 결론을 낸 회의에서 정작 이를 생각하는 개인이나 조직이 전혀 없는 경우이다. 집단 사고의 징후는 특정 문제에 대한 반론을 허용하지 않기 때문에 이에 대한 반론을 제기할 필요나 이유가 없게 만들며, 개인적으로는 전체가 사고하고 행동하는 대로 그대로 좇아가게 만드는 결과를 낳게 된다.
인터페이스 명세를 왜 만드는지, 그리고, 그러한 문서가 어떠한 곳에 사용되는지, 지금 만들고 있는 문서 양식에서 수정할 사항은 없는지에 대해서 생각하게 만들지 않고 다른 이들이 하는 것을 참고하여 그저 기계적인 내용만을 채워넣는 행위들은 집단 사고에 이미 노출되어 있다고 보면 된다. (실제로 이미 만들고 있는 문서에 대한 타당성을 제기한다면 이미 합의를 본 내용인데 왜 이제와서 반론을 제기하느냐는 역공을 맞는 경우에 개인이 희생하면서까지 일부러 타당성을 제기할 용기를 없애버린다)
프로젝트를 수행하는 동안 결정론에 입각한 의사결정은 반드시 피해야할 사항들 중에 하나이다. 아키텍처 역시 진화적인 형태로 발전해야 하며, 인터페이스 명세와 같은 설계 문서 역시 구현을 통한 피드백을 받아서 그 내용이 채워져야 한다. 프로젝트에서의 의사결정은 수없이 번복되고 뒤집어질 수 있다는 열린 의사결정을 채택하게 될 때 집단 지성을 통한 다양한 의견을 수용할 수 있으며, 프로젝트는 더 성공에 가까워질 것이다.
프로젝트 내에서도 역시 이러한 집단 사고와 집단 지성의 현상들은 목격할 수 있다. 특히, 위험 관리나 이슈 관리에 있어서 집단 사고를 목격하는 사례를 들면 대부분이 이러한 영역에 있는 문제들은 혼자서 해결하기 어려운 문제들이다. 이는 어느 한 개인에게 문제 해결에 대한 책임을 돌리기에는 너무나도 어렵지만, 프로젝트 내에서 한정된 자원과 시간이라는 측면에서 특정인이나 몇몇 소수에게 이를 맡기게 된다. 또한, 그러한 문제들은 너무나도 전문적이고 고도의 기술을 요하는 것처럼 위장될 수도 있기 때문에 그러한 특정인이나 소수의 목소리에 대해서 함부로 어떠한 반대 의견이나 반론을 펼치기도 어렵게 들린다. 혹은 그러한 반론을 이야기하는 경우에는 그에 대한 대안을 떠넘기기까지 하는 문화에서 함부로 반대 의견을 피력하기란 여간해서는 용기있는 행동이 아니다. 이러한 프로젝트 상황에서 집단 사고의 방식은 그대로 진행될 수 밖에 없으며, 이는 고스란히 개발하는 작업자나 제일 말단에 위치한 사원들의 수많은 수고와 고생으로 넘어가게 된다. 집단 사고가 일어날 수 있는 환경은 시간이 촉박하다는 이유만으로 일어나기는 힘들다. 정치색이 강한 프로젝트일수록 그러한 현상은 일어나기 쉬우며, 다양한 의견을 수용하려는 자세가 무시되기 쉽다.
집단 사고를 피할 수 있는 방식은 반복(iteration)을 통한 학습 내지 피드백을 통한 보완이라는 장치로 어느 정도는 감쇄할 수 있다. SW가 다른 물리적인 문제와 다른 가장 큰 장점이 바로 이러한 것인데, SW를 한번에 구현하는 방식보다는 반복을 통한 구현 방식을 채택한다면 이러한 집단 사고를 어느 정도 방지할 수 있다. 특히나, 해결하기 어려운 문제일수록 반복의 횟수나 강도를 높임으로써 보다 구체적인 형태의 모습으로 만들어가려는 노력이 필요하다. 물론, 다양한 목소리를 수용할 수 있는 집단 지성의 장치를 보완한다면 그러한 방식은 좀 더 탄력을 받을 수 있다.
집단 사고는 또한 개인의 생각을 방해하거나 훼방하는 결과를 낳을 수 있다. 즉, 특정 문제나 이슈에 대해서 '다함께 생각해보자'라는 결론을 낸 회의에서 정작 이를 생각하는 개인이나 조직이 전혀 없는 경우이다. 집단 사고의 징후는 특정 문제에 대한 반론을 허용하지 않기 때문에 이에 대한 반론을 제기할 필요나 이유가 없게 만들며, 개인적으로는 전체가 사고하고 행동하는 대로 그대로 좇아가게 만드는 결과를 낳게 된다.
인터페이스 명세를 왜 만드는지, 그리고, 그러한 문서가 어떠한 곳에 사용되는지, 지금 만들고 있는 문서 양식에서 수정할 사항은 없는지에 대해서 생각하게 만들지 않고 다른 이들이 하는 것을 참고하여 그저 기계적인 내용만을 채워넣는 행위들은 집단 사고에 이미 노출되어 있다고 보면 된다. (실제로 이미 만들고 있는 문서에 대한 타당성을 제기한다면 이미 합의를 본 내용인데 왜 이제와서 반론을 제기하느냐는 역공을 맞는 경우에 개인이 희생하면서까지 일부러 타당성을 제기할 용기를 없애버린다)
프로젝트를 수행하는 동안 결정론에 입각한 의사결정은 반드시 피해야할 사항들 중에 하나이다. 아키텍처 역시 진화적인 형태로 발전해야 하며, 인터페이스 명세와 같은 설계 문서 역시 구현을 통한 피드백을 받아서 그 내용이 채워져야 한다. 프로젝트에서의 의사결정은 수없이 번복되고 뒤집어질 수 있다는 열린 의사결정을 채택하게 될 때 집단 지성을 통한 다양한 의견을 수용할 수 있으며, 프로젝트는 더 성공에 가까워질 것이다.
반응형
'Homo Ware' 카테고리의 다른 글
왜 애자일일까? (0) | 2011.11.04 |
---|---|
공적 영역의 사유화와 사적 영역의 공유화 (0) | 2011.10.19 |
SW 프로젝트와 여행 (0) | 2011.09.30 |
SW 분야 관련 서적들 (해외 서적들) (0) | 2011.09.17 |
개발 프로세스, 논리적인 연결고리가 필요하다. (0) | 2011.09.15 |