이 책은 독서모임을 통해서 추천받아서 읽게 되었다. 창의성과 프로그래밍 관계를 생각해보게 해준 고마운 책이다. 이 책 덕분에 한동안 흥미지수가 떨어진 코딩을 확 끌어올릴 수 있었다.
창의성은 사회적 판단이다
P26
창의성은 사회적 판단입니다. 여러분의 프로그래밍 노력이 창의적인 결과물로 이어졌는지는 여러분이 아니라 여러분의 동료들이 결정합니다. …
이 책에서 주장하는 창의성을 설명하는 부분이다. 보통 "창의성" 이라고 말하면, 대부분은 무언가 '연결' 하거나 '새로운 결과물 생성' 을 말한다. 이 책에서는 '사회적 판단' 이라고 단언하고 있다. 내가 아무리 독창적이고, 천재적이라고 해도 주변 동료나 업계에서 인정하지 않으면 그것은 창의적인 결과물이 아니다. 역으로 내가 대충했지만, 창의적이라고 인정받는다면, 그것은 창의적인 결과물이다.
공감 x 판단의 독자성 => 창의성
창의성하면, 나도 모르게 방구석에서 혼자 골돌히 고민하다가 걸작을 만드는 어떤 사람이 떠오른다. 이유는 매스미디어를 통해서든 뭐든간 학습받은 것이겠지 책에서 사회적으로 인정받는 것이 창의성은 맞으나, 창의적인 사람이 되기 위한 것은 조금 다르다고 생각한다. 사회적이기만 하면 안되고 고독하게 밀고 나가는 점도 있어야 한다고 생각한다. 나의 주장을 뒷받침하는 근거가 아래 설명할 논문이다.
"공감, 판단의 독자성, 창의적 인성의 관계" 이라는 논문에서는 공감 , 판단의 독자성 그리고 창의적 인성 에 대해서 관계성을 분석하고 있다. 내용을 설명하기 전에 단어 뜻이 궁금할 수 있으므로, 배경지식을 작성하고 넘어가겠다.
-
판단의 독자성 : 창의적 인성 중 ‘판단의 독자성’은 다른 사람에게 의존하지 않고 스스로 해결하며, 주위의 평가나 인정으로부터 벗어나고자 하는 특성으로써, 다른 사람의 입장에서 생각하는 ‘공감’과는 관련이 없다고 볼 수 있다
- 창의적인 인물은 호기심이 많고, 탐구심이 있으며, 실패를 두려워하지 않으며, 미적 특성을 높이 평가하며, 개방적 사고 경향성이 있으며, 남들과 다른 의견을 내는 것을 두려워하지 않는 판단의 독자성이 있다 -
창의적인 인성 과 공감의 관계 : 창의성이 높다는 것은 자신의 아이디어를 개발하고, 남과 다른 점을 두려워하지 않는다는 것이고, 공감이 높다는 것은 다른 사람의 입장을 이해하고, 그의 감정을 공유하는 것이다. 창의적인 사람은 남과 다른 점을 두려워하지 않으면서도 타인의 입장을 이해하고 공유하는 공감능력도 높을 수 있지만, 공감능력이 높다고 모두 창의적이지는 않을 것이다.
이 논문에서의 연구주제는 다음 3 가지이다.
1) 창의적 인성 수준별 공감에 차이가 있는가?
2) 공감과 창의적 인성의 관계는 어떤가?
3) 공감과 판단의 독자성 수준별 창의적 인성에 차이가 있는가?
창의성을 판단한 기준은 KEDI 창의적 인성검사(Creative Personality Scale) 에서 개발한 검사가 있는 것 같다. 이것들을 기준으로 판단했다고 한다.
우리가 이 논문에 대해서 기억해야하는건 결론만 알면 된다.
결론
이 논문의 결론은 "창의적 인성과 공감은 서로 유의미한 상관관계가 있으며, 공감과 판단의 독자성이 높은 사람들이 가장 창의적 인성이 높다." 이다.
이 논문까지 읽고 다시 생각을 해보면,
결과물은 결국 사회적 평가를 받는다. 그렇지만 그 평가받는 결과물을 내놓기 위해서는 독자적이고 개성적인 판단이 들어가야 창의적이다. 그래서 사회에 대해서 이해와 공감을 바탕으로 자신의 의견을 구축하는 것이 "창의" 라고 생각한다.
4 장의 종이로 계란 살리기 프로젝트에서 얻은 창의적 경험
P27
여러분이 작성한 코드를 보고 팀원들이 “코드 잘짰네! 참신한 해결책인걸?” 이라며 칭찬한다면, 여러분은 순식간에 창의적인 프로그래머가 될 수 있습니다.
…
또한 해당 분야의 미술 전문가 중 누구도 반 고흐의 그림이 감동적이고 획기적이라고 인정하지 않았다면 우리는 그를 창의적인 천재로 간주하지 않았을 것입니다.
Exersice
언제 어떤 것이 창의적이라고 생각하나요? 이 질문에 대해 몇 분간 깊이 생각해 보세요. 여러분이 생각해 낸 아이디어가 매우 창의적이라고 생각했던 적이 있나요? 언제가 마지막이었나요?
'A4 용지 4 장과 풀' 만 이용해서 5층에서 계란을 깨지지 않고 떨어뜨리는 방법을 고안했던 창의적 공학설계 수업에서 했던 활동이 제일 창의적이라고 생각이 든다. 윤재건 교수님의 창의적 공학설계이였다.
이 책의 중반부에 나오는 "제약 조건" 과도 연관이 있다. A4 용지 4 장과 풀만 사용해서 계란을 살리는 프로젝트. 이것 자체가 제약조건이다. 그리고 그 안에서 문제를 푸는 과정이다. 이런 제한된 환경이 오히려 문제 해결에 새로운 실마리를 생각하도록 했다.
나의 경우를 이야기하면, 나는 정말 우연히 풀었다. 아이디어를 얻은 곳은 영화 블랙호크다운 2002 년도 영화이다. 기본적으로 내가 전쟁영화를 좋아한다. 이 영화가 우연히 보고 있었고, 헬리콥터가 떨어지는 장면에서 번뜩이는 생각이 들었다. 저 헬기는 뭐길래 천천히 떨어지는 것일까? 회전익의 특성상 날개가 프로펠러처럼 돌면서 떨어진다. 그것을 동일하게 만들면 되겠다고 생각했고, 그렇게해서 그 학기에서 나만 해당 문제를 풀 수 있었다. 그거 덕택인지 아니면 나머지 시험을 잘봐선지는 모르지만 설계과목은 A+ 받음
이런 경험 이후 깨달은 점은 "각각의 경험들이 소중하다." 라는 것이다. 이 이야기는 스티브 잡스의 명연설과 맥락이 비슷하지 않을까?
스탠포드에서 스티브 잡스 연설: "Connecting the dots"
4장 : 제약조건
p137
제한된 프로그래밍 언어
Go 언어 사양의 공간을 '프로그래머의 머릿속에 모든 것을 담을 수 있을 만큼만' 작게 유지하도록 설게되었습니다.
루프를 구성하는 유일한 방법은 for {} 루프이고 while 이가 do {} 도 없습니다. 그 이유는 시스템 수준이 아닌 함수 수준에서 오류 처리를 명시적으로 하기 위해서 입니다.
고의 언어 제약 조건 때문에 지루하다고 여겨질 수 있지만, 오히려 그것이 새로운 흥미를 불러일으킵니다. 또한, 고는 스스로 부과한 제약 조건으로 인해 창의성을 자극하기도 합니다.
이 책에서 가장 가치있다고 느꼈던 부분이 "4장: 제약조건" 이다.
개발을 하다보면, 매순간 제약조건이 있다. 이것은 개발뿐만 아니다. 기계공학의 거의 대다수의 예제 & 연습문제를 보면, 제약조건을 최우선적으로 확인해야한다. 예를들면, 구체적인 물체를 부피를 무시한 질점으로 대체하기도 한다. 공기저항은 무시한다든가 또는 재료의 변형률을 특정 상수로 고정한다든지...
개발에서도 코딩테스트를 보면 느낄 수 있다. 1초 내로 실행되는 조건과 같이 말이다.
그 조건이 있었기에, 완전탐색으로 풀지 않고, 다른 정수론 개념을 가져와서 문제를 푼다. 그것이 최초로 나타난 문제풀이인 시점에는 창의적일 것이다. 우리가 푸는 다양한 코딩테스트의 문제풀이는 어느 순간 창의적인 아이디어였을 것이다. 그 옛것을 익히는 과정이 코딩테스트의 공부과정 아닐까 싶다.
개발에서 적용할만한 제약조건
p139
Exercise
다음에 창작의 틀에 갇혔을 때는 기존의 제악 조건에 얽매이지 말고 스스로 더 많은 제약 조건을 부과해 보세요. 예를 들어 루프를 사용하지 않고 코드를 작성해야 한다면 어떨까요? 아니면 클라이언트-서버 통신 없이 작성한다면 어떨까요? 아니면 데이터베이스에 질의하지 않아야 한다면요? 상상 속의 제약 조건을 적용해 보면 실제 문제에 대한 아이디어가 한두 가지 떠오를 것입니다. 심지어 구현할 필요도 없습니다.
최근에 소트웍스 앤솔러지: 객체지향 체조원칙 - 블로그글 라는 재미있는 원칙을 봤다.
- 한 메서드에 오직 한 단계의 들여쓰기만 한다.
- Why? : 메서드의 들여쓰기가 여러개 있다는 뜻은 하나의 메서드에서 여러개의 동작을 할 확률이 높다는 뜻이다. 형식적인 규칙으로 들여쓰기를 기준으로 잡은 것이다. - else 키워드를 쓰지 않는다.
- Why? : else 를 사용이 반복되면, 개발자의 메모리가 과부하 걸린다. if - else 가 추가된 코드를 읽어 내려가면 갈수록 상위의 조건들을 외우고 있어야 한다. 이럴 때, Refactoring.Guru: 전략 패턴 이 유용하다. - 모든 원시값과 문자열을 포장(wrap) 한다.
- Why? : 가독성과 변경 가능성에 유연한 대응이 가장 클 것이다. 포장된 객체는 그 자체로 의미를 지닌다. 다른 개발자로 하여금 두 번 생각할 필요없이, 정의 그 자체로 의미를 파악할 수 있다. 변경 가능성도 마찬가지다.
- 이부분은 성능과도 연관이 있어서 조금 생각할 필요는 있는 것 같다. 원시값은 바로 스택영역에 저장될 것이다. 하지만 객체의 경우, 스택 영역에 메모리 주소가 저장되고, 힙 영역에 데이터(여기서 데이터는 인스턴스를 의미한다.)가 저장될 것이다 당연히 힙 메모리에서 바로 처리하는 것보다 성능상 느릴 수 있다. 그러므로, 이 원칙은 트레이드오프의 영역이라고 생각한다. - 한 줄에 점을 하나만 찍는다.
- 이 원칙은 The Law of Demeter(디미터의 법칙) 과 연관이 있다.
- 디미터 법칙을 장려하는 논문 링크 Object-Oriented Programming: An Objective Sense of Style - 줄여쓰지 않는다.
- 모든 entity를 작게 유지한다.
- 2개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
- 일급 컬렉션을 쓴다.
- 이미 내장된 문법을 예시로 들면 다음과 같다.
- List: Dart -List<E>/ Swift -[Int]
- Set: Dart -Set<E>/ Swift -Set<T>
- Map: Dart -Map<String, E>/ Swift -[String: Int] getter/setter/property를 쓰지 않는다.
여기 있는 규칙을 맹신할 필요는 없다. 하지만, 이 법칙이 나오게된 맥락과 의도는 정말 중요하다고 본다
: 유지보수성 & 가독성
참고자료
