창의적 방법론은 무엇일까 (서평 : Software Creativity 2.0)
소프트웨어와 창의적 혁신을 화두로 꾸준히 얘기를 해나가고 있으니, 친구가 책 한권을 추천했다. 이 블로그의 태그들 중 가장 많은 게 Software와 Creativity인데 이 책을 한번 읽어보는 게 어떻겠냐고.
번역서가 있어서 도서관에서 대출받을 수가 있었다.
YES24 : 소프트웨어 크리에이티비티 2.0
책을 읽어나가면서 주장하는 내용 즉, 실천적인 결론에서 많은 부분이 닮아있음을 보았다.
소프트웨어를 지적 노동으로 바라보고 이에 따라 창의성을 중시하는 문제 해결 방법을 따라야 한다는 것이 기본 주장이란 점에서 반가운 마음이 앞섰다.
얘기를 풀어가는 방식은 조금 달랐는데 개인적으로 논리적인 전개를 통한 증명을 선호하는 데 비해, 이 책의 저자인 Robert L. Glass는 일화 형태로 사례를 들어 주장하는 방식을 사용했다.
실천적 주장은 비슷하지만, 결론에 도달하는 방식은 매우 다르다고 할까.
개인적으로는 사람의 두뇌의 특성과 지적 사고 방법 등 내적 논리를 만들려고 노력하고 이에 따라 결론을 유도하는 연역적 전개를 선호하는데 Glass 씨의 책은 경험적이고 사례적인 근거에 따라 결론을 유도하는 귀납적 논리 전개를 사용한다.
개인적으로는 주장이란 bottom-up을 통해 구성한 지식 체계를 top-down으로 설명할 수 있어야 좋은 주장이라고 생각한다. 물론 지식 전달의 관점에서는 논리적인 top-down 전개가 더 낫다, 일화를 통한 스토리텔링 방식이 더 낫다는 편견을 가진 건 아니다.
(딱딱한 논리적 전개의 정합성을 많이 의식하기 때문에 이 블로그들 중 상당수가 일반 독자들이 읽기에 재미가 없다는 지적도 많다. 일화 중심으로 가벼운 블로그들의 pageview가 높은 것이 어떻게 보면 당연하다. 좀더 가볍게 블로그를 쓰고 싶으나, 아직 논리적인 탐구들이 단언할 수준의 결론으로 이르지 않은 부분이 많아서 논리적 재구성을 고심하여 쓰다보니 논지들이 설익고 딱딱하다.)
Glass 씨는 딱히 결론을 내리지는 않고 있다. 오랜 소프트웨어 경험에서 나온 직관적 판단과 소프트웨어공학 쪽의 이론 흐름 등을 대비하면서 창의적이고 지적 노동이 소프트웨어 성공의 핵심 요소라는 심증을 사례를 통해 증명하려고 노력한다.
창의성이 중요하다는 것은 여러 가지 사례를 통해 입증하려 했지만, 어떻게 해야 한다는 방향까지 주지는 못했다는 점은 아쉽다.
책의 논점들 중 몇 가지 재미있는 논쟁점들을 뽑아 개인적인 생각을 적어본다.
1항, 2항은 연결된 질문이다. 지식 노동적 성격이 강할수록 사람의 우수성에 의존하게 된다. 예를 들어 CASE 툴이나 4GL 툴들이 지식 노동적 성격을 최소화하고 단순 사무적 노동으로 만들 수 있다면 분명 프로세스가 더 중요해진다.
하지만, 대부분의 소프트웨어는 그렇게 단순하지 않다. 코드가 매우 단순해지고 복잡성이 없는 영역에서는 사무적 성격이 강해진다.
개인적으로는 어디에서나 CASE툴, 4GL, 프레임웍 등 다양한 툴들이 등장하지만 점점 더 사람의 창의와 지적 노동이 필요한 영역이 늘어난다고 본다. 단순 작업을 줄이기 위해 프로그래밍 언어와 툴들이 발전하고 있을뿐이며 아직 업무 설계를 지적 코딩 없이 소프트웨어로 변환해주는 툴들은 만족하기 어려우며, 그러한 툴들은 업무의 변화에 따른 구조적 변화를 쫓아가기 어렵다고 본다. 물론 그것이 가능하다는 과대광고는 많았었고, 계속될 것이다.
즉, 단순 노동과 지적 노동의 비율이 항상 긴장 관계를 유지하고 있지만, 핵심 영역에서는 지적 노동을 없앨 수 없다는 것이다.
3항은 수학과 전산학의 관계에 대해서 문제제기를 하면서 학계는 너무 수학적 정형주의 틀에 전산학을 맞추려는 경향이 있다고 지적한다. 현재 전산학의 많은 부분에서 수학이 사용되고 기반이 되는 것은 분명하다. 다만 소프트웨어를 정형화된 수학 모델에 의해 프로세스화하고 관리할 수 있다고 보는 경향에 대한 우려라고 생각하면 될 것 같다.
4항은 소프트웨어공학을 배척한다기보다는 그 방향에 대해 좀더 목적을 분명히 할 필요가 있다는 점을 지적한다. 좋은 소프트웨어 제품을 만드는 것이 목적인지 프로세스를 잘 지키는 것이 목적인지 가치를 전도시키는 일부 경향에 대한 비판이다.
프로세스가 필요없다고 생각하진 않지만 항상 목적과 결부하여 도입할 필요가 있다. 프로세스를 완벽하게 준수한다고 대단한 소프트웨어 제품이 나오는 것이 아니라면 프로세스는 한계가 큰 것이다.
마지막 5항은 소프트웨어공학의 프로세스들이 오히려 소프트웨어 엔지니어의 재미를 줄인다는 지적과 관련이 있다. 창의적인 문제 해결에 가장 많은 재미가 있는데 이 과정을 정형적으로 관리한다는 것은 맞지 않다는 것이다.
블로그에서 소수로 프로젝트를 하고, 정성적으로 퍼포먼스를 평가해야 한다는 주장을 여러 번 했었는데 Glass 역시 같은 맥락의 주장을 한다. (정성적 평가는 공학자들이 아주 꺼리는 경향이 있다.)
소프트웨어의 창의는 지적 수준이 받쳐줘야 한다는 점도 지적한다. 설계와 개발 단계에서는 논리적 검증이 필요한 영역이라 단순 아이디어가 바로 창의로 이어지기 어렵다는 점이다.
책 내용 중에 일반적인 창의 프로세스를 소프트웨어에도 적용하려는 시도에 대한 언급이 있다. 생각들을 공유하고 심화하는 것은 매우 중요한 과정임이 분명하다. 이 절차들이 의미가 있을지 생각해보자.
원 실험은 Creativity and Innovation in Information Systems Organizations (J Daniel Couger, 1996)이라고 한다.
창의를 위해 정형화된 프로세스적인 뒷받침이 창의적인 조직에 꼭 있어야 하는 것은 아니라고 생각한다. 다만 이러한 창의를 돕는 기교들이 자연스럽게 개인의 창의적인 생각방식과 조직의 회의 방식에 일상적으로 녹아있을 필요가 있다.
번역서가 있어서 도서관에서 대출받을 수가 있었다.
YES24 : 소프트웨어 크리에이티비티 2.0
책을 읽어나가면서 주장하는 내용 즉, 실천적인 결론에서 많은 부분이 닮아있음을 보았다.
소프트웨어를 지적 노동으로 바라보고 이에 따라 창의성을 중시하는 문제 해결 방법을 따라야 한다는 것이 기본 주장이란 점에서 반가운 마음이 앞섰다.
얘기를 풀어가는 방식은 조금 달랐는데 개인적으로 논리적인 전개를 통한 증명을 선호하는 데 비해, 이 책의 저자인 Robert L. Glass는 일화 형태로 사례를 들어 주장하는 방식을 사용했다.
실천적 주장은 비슷하지만, 결론에 도달하는 방식은 매우 다르다고 할까.
개인적으로는 사람의 두뇌의 특성과 지적 사고 방법 등 내적 논리를 만들려고 노력하고 이에 따라 결론을 유도하는 연역적 전개를 선호하는데 Glass 씨의 책은 경험적이고 사례적인 근거에 따라 결론을 유도하는 귀납적 논리 전개를 사용한다.
개인적으로는 주장이란 bottom-up을 통해 구성한 지식 체계를 top-down으로 설명할 수 있어야 좋은 주장이라고 생각한다. 물론 지식 전달의 관점에서는 논리적인 top-down 전개가 더 낫다, 일화를 통한 스토리텔링 방식이 더 낫다는 편견을 가진 건 아니다.
(딱딱한 논리적 전개의 정합성을 많이 의식하기 때문에 이 블로그들 중 상당수가 일반 독자들이 읽기에 재미가 없다는 지적도 많다. 일화 중심으로 가벼운 블로그들의 pageview가 높은 것이 어떻게 보면 당연하다. 좀더 가볍게 블로그를 쓰고 싶으나, 아직 논리적인 탐구들이 단언할 수준의 결론으로 이르지 않은 부분이 많아서 논리적 재구성을 고심하여 쓰다보니 논지들이 설익고 딱딱하다.)
Glass 씨는 딱히 결론을 내리지는 않고 있다. 오랜 소프트웨어 경험에서 나온 직관적 판단과 소프트웨어공학 쪽의 이론 흐름 등을 대비하면서 창의적이고 지적 노동이 소프트웨어 성공의 핵심 요소라는 심증을 사례를 통해 증명하려고 노력한다.
창의성이 중요하다는 것은 여러 가지 사례를 통해 입증하려 했지만, 어떻게 해야 한다는 방향까지 주지는 못했다는 점은 아쉽다.
책의 논점들 중 몇 가지 재미있는 논쟁점들을 뽑아 개인적인 생각을 적어본다.
- 소프트웨어가 지식 노동이냐 사무적 노동(단순 노동?)이냐
- 소프트웨어에 있어 사람의 우수성이 중요하냐 프로세스가 중요하냐
- 응용수학과 이론수학, 그리고 전산학, 소프트웨어공학의 관계. 전산학이 너무 이론수학에 경도되어 발전이 더딘 것은 아닌가?
- 소프트웨어 공학이 적합한지 실무적인 개발 프로세스가 적합한지
- 창의성을 위한 프로세스를 정의할 수 있는가?
1항, 2항은 연결된 질문이다. 지식 노동적 성격이 강할수록 사람의 우수성에 의존하게 된다. 예를 들어 CASE 툴이나 4GL 툴들이 지식 노동적 성격을 최소화하고 단순 사무적 노동으로 만들 수 있다면 분명 프로세스가 더 중요해진다.
하지만, 대부분의 소프트웨어는 그렇게 단순하지 않다. 코드가 매우 단순해지고 복잡성이 없는 영역에서는 사무적 성격이 강해진다.
개인적으로는 어디에서나 CASE툴, 4GL, 프레임웍 등 다양한 툴들이 등장하지만 점점 더 사람의 창의와 지적 노동이 필요한 영역이 늘어난다고 본다. 단순 작업을 줄이기 위해 프로그래밍 언어와 툴들이 발전하고 있을뿐이며 아직 업무 설계를 지적 코딩 없이 소프트웨어로 변환해주는 툴들은 만족하기 어려우며, 그러한 툴들은 업무의 변화에 따른 구조적 변화를 쫓아가기 어렵다고 본다. 물론 그것이 가능하다는 과대광고는 많았었고, 계속될 것이다.
즉, 단순 노동과 지적 노동의 비율이 항상 긴장 관계를 유지하고 있지만, 핵심 영역에서는 지적 노동을 없앨 수 없다는 것이다.
3항은 수학과 전산학의 관계에 대해서 문제제기를 하면서 학계는 너무 수학적 정형주의 틀에 전산학을 맞추려는 경향이 있다고 지적한다. 현재 전산학의 많은 부분에서 수학이 사용되고 기반이 되는 것은 분명하다. 다만 소프트웨어를 정형화된 수학 모델에 의해 프로세스화하고 관리할 수 있다고 보는 경향에 대한 우려라고 생각하면 될 것 같다.
4항은 소프트웨어공학을 배척한다기보다는 그 방향에 대해 좀더 목적을 분명히 할 필요가 있다는 점을 지적한다. 좋은 소프트웨어 제품을 만드는 것이 목적인지 프로세스를 잘 지키는 것이 목적인지 가치를 전도시키는 일부 경향에 대한 비판이다.
프로세스가 필요없다고 생각하진 않지만 항상 목적과 결부하여 도입할 필요가 있다. 프로세스를 완벽하게 준수한다고 대단한 소프트웨어 제품이 나오는 것이 아니라면 프로세스는 한계가 큰 것이다.
마지막 5항은 소프트웨어공학의 프로세스들이 오히려 소프트웨어 엔지니어의 재미를 줄인다는 지적과 관련이 있다. 창의적인 문제 해결에 가장 많은 재미가 있는데 이 과정을 정형적으로 관리한다는 것은 맞지 않다는 것이다.
블로그에서 소수로 프로젝트를 하고, 정성적으로 퍼포먼스를 평가해야 한다는 주장을 여러 번 했었는데 Glass 역시 같은 맥락의 주장을 한다. (정성적 평가는 공학자들이 아주 꺼리는 경향이 있다.)
소프트웨어의 창의는 지적 수준이 받쳐줘야 한다는 점도 지적한다. 설계와 개발 단계에서는 논리적 검증이 필요한 영역이라 단순 아이디어가 바로 창의로 이어지기 어렵다는 점이다.
책 내용 중에 일반적인 창의 프로세스를 소프트웨어에도 적용하려는 시도에 대한 언급이 있다. 생각들을 공유하고 심화하는 것은 매우 중요한 과정임이 분명하다. 이 절차들이 의미가 있을지 생각해보자.
원 실험은 Creativity and Innovation in Information Systems Organizations (J Daniel Couger, 1996)이라고 한다.
- 유추/은유(Analogy/Metaphor)
- 브레인스토밍(Brainstorming)
- 파란 쪽지(Blue Slip)
- 추정(Extrapolation)
- 점진적 추상화(Progressive Abstraction)
- 6하원칙(5W1H)
- 力場분석(Force Field Analysis)
- 평화로운 환경(Peaceful Setting)
- 문제 반전(Problem Reversal)
- 연관/이미지(Association/Images)
- 소망적 사고(Wishful Thinking)
창의를 위해 정형화된 프로세스적인 뒷받침이 창의적인 조직에 꼭 있어야 하는 것은 아니라고 생각한다. 다만 이러한 창의를 돕는 기교들이 자연스럽게 개인의 창의적인 생각방식과 조직의 회의 방식에 일상적으로 녹아있을 필요가 있다.
댓글