들어가며
인간은 새로운 것을 만들기를 좋아한다. 철학자이자 소설가인 움베르토 에코에 따르면 호모 파베르야말로 인간의 타고난 본성을 가장 잘 표현하는 말이다
호모 파베르는 “창조 행위를 통해 우리의 운명과 환경을 통제하는 인간”이라는 의미다.
1장은 창의성 용어의 유래, 정의를 시작으로 왜 발휘해야 하는지 설명하고 있다.
창의적 프로그래머의 7가지 테마에 대한 개요, 문제해결 테스트 등 방향을 제시해준다.
이 책은 더 나은 개발자로 성장하기 위해 다른 차원에서 접근하고 있다.
우리가 배우고자 하는 내용은 창의력이 뛰어난 개인(팀)이 문제에 접근하는 방법, 그들의 습관과 사고 과정, 더 생산적이고 창의적인 해결책에 도달하는 방법 같은 것
프로그래밍과 같은 기술 분야는 경험이 많다고 해서 꼭 창의적인 결과물을 더 많이 만들어 내는 것은 아니다
이 책의 방식은 문제에 더 창의적으로 접근하는 방법을 가르치는 것이다.
수많은 소프트웨어의 실패를 목격하면서 그 실패가 기술적 능력이라기 보다 기술 외적으로 다른 무언가에 결핍되어 있기 때문이라는 확신을 가지게 됨
창의성이란 무엇일까?
심리학자들은 이 질문에 대해 수십 년 동안 논쟁을 벌여왔음
그 결과 창의성에 대해 100여 가지나 되는 다양한 정의가 제시됨.
모든 의견에서 본질적인 부분을 뽑아 하나의 정의로 요약해보자. 창의성 연구자인 제임스 카우프만과 로버트 스턴버그는 창의성을 다음과 같이 요약하고 있다.
- 참신하고 독창적일 때
- 품질이 우수할 때
- 당면한 과제와 관련이 있을 때
NoSQL 데이터베이스를 문제 해결에 사용하는 것은 질적인 해결책 이지만 독창적인 아이디어라고 할 수 있을까?
우리의 문제가 데이터와 관련이 없다면 NoSQL은 아무런 관련이 없을 수도 있다. 그럼에도 불구하고 개발자들은 NoSQL로 작업해 본 적 없는 상태에서 처음 접하면 참신한 아이디어라고 생각 할 수도 있다 (관점의 차이라는거 아닌가)
창의성에 대한 본질주의자들의 이러한 관점에는 많은 단점이 존재한다.
- 콘텍스트 즉 맥락을 완전히 무시한다.
- 창의성에 관한 연구는 맥락을 고려하면서 더 체계적인 접근 방식으로 점차 바뀌어 나가고 있다.
- 맥략까지 고려한다는 점 때문에 얼핏 복잡한 듯 보일 수 있다.
언제 어떤 것이 창의적이라고 생각하는가?
> 오늘 IOS 17을 업데이트 했는데 핸드폰을 맞대면 연락처가 공유되더라.. 참신했다.. 참신==창의적?
답은 어떤 것을 보고 다른 사람이 창의적이라고 말한다면 그것은 창의적이다.
창의성은 사회적 판단이다. 우리의 프로그래밍 노력이 창의적인 결과물로 이어졌는지는 자신이 아니라 동료들이 결정하게 된다.
나의 결과물을 창의적이라고 스스로 결정할 수는 없다. 사회문화적 현상이기 때문이다.
프로그래밍이나 다른 영역도 마찬가지다. 우리가 작성한 코드를 보고 팀원들이 “코드 잘짯네!” “참신한 해결이다!” 라고 칭찬한다면 순식간에 창의적인 프로그래머가 될 수 있다.
(잘 작성한다는 것은 센스가 좋다는 것 아닌가..? 센스==창의적..?)
하지만 똑같은 코드를 다른 팀이나 회사 사람들이 보면 특별한 것 없는 평범한 코드라고 생각할 수도 있다. 이미 본 적이 있는 코드일 가능성이 있기 때문에
시간과 장소는 창의성에 중요한 영향을 미치게 된다.
내가 할 수 있는 일은 최선을 다하는 것 뿐 나의 결과물이 창의적이라고 선언하는 것은 나의 몫이 아니다.
왜 창의성일까?
많은 습관과 개인의 성격적인 특성이 창의적인 프로그래머가 될 잠재력을 크게 높여주기 때문에 창의성은 중요하다.
창의적인 개발자로 살아야 하는 주된 이유는 무엇일까?
- 간단히 말해 고용주가 요구하기 때문이다. 수년 동안 거의 모든 소프트웨어 개발자 구인 광고에는 “창의적”이라는 단어가 포함되어 있다. 물론 구인 광고가 가능한 한 많은 지원자를 유치하기 위해 인사 부서에서 만든 의미 없는 단어로 부풀려져 있다는 것은 어느정도 인지하고 있다. 하지만 확실히 요즘은 소프트 스킬이 대세다.
내 프로그래밍 작업이 창의적으로 보일 때는 언제인가? 창의적이지 않을 때는 언제인가? 다른 사람의 코드는 언제 창의적이라고 생각하는가? 차이가 있는가?
1. 내가 작성한 코드를 편하게 가져다 쓰는 팀원을 볼 때..? 나름 센스있게 잘 작성했다 라는 느낌이 든다.
2. 그냥 무작정 블로그를 보고 적용한 후 내 입맛대로 수정하지 않았을 때 (하지만 마감기한에 있어 그냥 넘어 갈 때)
3. 내가 충분히 생각할 수 있었을 수도 있는데 인지하지 못하고 있을 때 그런 부분을 볼 때 나는 왜 이생각을 못햇지 !! 짜릿하다..
4. 항상 예전부터 생각했지만 게으르게 하려고..? 최대한 단순하게 생각한다,,?
요즘 창의력이 요구되는 이유는 문제 해결 때문이다. 기본의 방법이 실패할 때 창의력을 발휘하는 것이 해결책이 될 수 있다.
창의적인 프로세스가 어떻게 작동하는지 아는 것만으로도 해결책의 절반은 찾은 셈이다.
웹 애플리케이션이 초당 수천건의 요청을 처리하는 데 어려움이 있다면?
메시지큐, 로드밸런싱, 캐싱, 코루틴을 검토 하자 팀원 누구도 이러한 방법을 제안하지 않는다면 계속 제자리 걸을음 할 가능성이 높고 창의적인 프로그래머는 이러한 틀을 깨트린다.
하지만 때로는 문제 해결만으로 충분하지 않다. 문제가 정의되기는 커녕 아직 발견되지 않은 경우도 있기 때문이다. 이럴 때는 해결 능력이 그다지 효과적이지 않으므로 창의적인 감각에 의존해 문제를 발견해야 한다.
다윈은 문제 해결사가 아니라 문제 발견자였다. 프로그래머로서 우리는 다윈의 사고방식에서 무엇을 배울 수 있을까?
우리의 작업 목록은 보통 작고 잘 정의된(하위) 문제들로 가득 차 있다. 어떻게든 “완료”되어야만 하는 수영 레인의 작업들… 하지만 여정의 어딘가에서 충분한 점들이 모이고 나중에는 그 점들이 서로 연결되어 완전히 새로운 질문이 만들어 질 수도 있다.
고객도 몰랐던 문제를 발견할 수도 있다. 창의적인 프로그래머는 문제 발견자이자 해결사이다.
- 동료의 의견이 중요하기 때문이다.
소프트웨어 개발은 팀 기반의 활동이다. 창의성은 사회적 구성 요소이므로 혼자서는 의미가 없다.
상호 존중에서 비롯되는 심리적 안정감은 모든 사람을 더 편안하게 만들고 팀의 결속력을 높인다. 이는 우리가 배우고 성장할 가능성을 열어주고 다른 사람들 역시 배우고 성장하는 데 도움이 된다.
창의적인 결과물 vs 프로세스
창의적인 작업에 감탄할 때 우리는 대부분 피와 땀과 눈물을 훌린 최종 결과물인 제품에만 감탄하는 사실에 주목하라..
최종 결과물은 영리한 알고리즘이나 새로 고안된 디자인 패턴일 수 있다. 이러한 결과물은 주로 개발자의 감탄을 불러일으킨다. 최종 결과물은 최종 사용자가 창의적이라고 평가할 수 있는 전체 애플리케이션 일 수 있다.
과정도 충분히 창의적일 수 있다. 하지만 이 과정은 대부분 눈에 보이지 않기 때문에 평가하기가 매우 어렵다.
창의적인 프로세스가 창의적인 결과물을 만들어 낼 수도 있다. 여기서 강조하는 것은 결과물이 엉망일 수도 있다는 점이다.
그 반대의 경우도 마찬가지다 창의적인 제품이 기존 프로세스의 결과물일 수 있다.
그렇다면 창의성의 정도는 어떻게 평가할까?
- 창의성은 재미와 같기 때문이다.
창의적인 프로그래머는 자기 일을 깊게 즐긴다. 깊이 파고들고, 안전지대를 벗어나고, 특이한 아이디어를 연결하고, 다른 사람들과 다양한 접근 방식을 논의하고, 흐름에 동참하는 것을 좋아한다.
요컨대 창의적인 프로그래머는 창의적 충돌을 받아들인다.
창의적인 사람들은 대부분 자기 창작물을 통해 자신의 연약한 육체보다 더 오래 살 수 있는 불멸의 존재가 되기를 희망한다.
오랫동안 사라지지 않을 흔적을 이 세상에 남기고자 하는 꿈을 이룬 운 좋은 소수의 사람은 진정한 천재로 칭송받는다. 기술은 시간이 지나도 금방 구닥다리로 여겨지는 만큼, 프로그래머인 우리는 그러한 불멸의 존재가 되고자 하는 열망을 억누르는게 나을 지도 모르겠다..
다양한 수준의 창의성
천재가 아니어도 창의력을 발휘할 수 있다.
- LittileC 또는 일상적인 창의성 : 개인적인 창의성으로서, 이전에 해보지 않은 독창적인 무언가를 하는 것을 의미한다. 예를들어 자신이 가장 좋아하는 게임이 c++로 되어있다면 이것을 휴대용 게임기인 게임보이 어드밴스로 크로스 컴파일 하는 행위가 이에 속한다.
- BigC 또는 저명한 창의성 : 이전에 아무도 해보지 않은 독창적인 작업을 수행하는 것을 의미한다. 예를 들어 루비 3을 486 컴퓨터의 DOS 6.22로 실행하기 위해 포팅하는 것
리누스 토발즈는 BigC 창의성의 대표적인 예이다. 그는 운영체제와 소스코드 버전 관리의 영역을 완전히 바꿨다.
일부 학자들에 따르면 “천재”는 전체 영역을 바꾸는 중요한 창의적인 제품을 담당한다고 한다. 반면에 웹앱에 요청 처리량 문제에 대한 창의적인 해결책을 내놓는다고 해서 그 분야가 전체적으로 바뀌지는 않을 것
물론 이 세상의 모든 것이 그렇듯 분루 체계에 대한 비판이 있을 수밖에 없다. LittleC는 때때로 너무 평범하고 단조로운 것으로 묘사되기도 한다.
BigC의 위대함 때문에 일상의 창의성은 도외시하고 더 거대한 창의성을 발휘하는 것에 압박감을 느낄 수도 있다.
창의성 연구자인 마크 런코는 리틀과 빅의 구분을 완전히 무시하면서 현실은 그렇게 범주화 되지 않는다고 주장한다.
어떤 사람들은 이에 대응해 다른 분류를 제안하게 되는데 역사적 창의성을 뜻하는 H-창의성과 개인적 창의성을 뜻하는 P-창의성으로 구분하는 제안이 있었다.
LittleC와 BigC 사이에는 MiniC와 ProC라는 숨겨진 층이 더 있다는 주장도 있엇다. 미하이 칙센트미하이와 같은 일부 연구자들은 창의적인 천재들을 인터뷰하여 일상에서의 창의성을 위한 사례를 추출하지만, 다른 연구자들은 이것이 오히려 오해를 불러일으킨다고 주장한다. 요컨대, 창의성에 대한 학문적 연구는 다소 혼란스럽다.
프로그래머가 작업하는 다양한 이너 서클의 예시
친한 동료가 창의적이라고 생각한 코드가 팀원들 사이에서 창의적이라는 찬사를 받을 수도 있다.
그러나 다른 팀에서도 이미 똑같은 작업이 이루어졌을 가능성이 있다.
회사 차원에서 본다면 우리의 명성은 갑작스럽게 끝날 수 있다. 창의성은 사회문화적인 것이므로 팀이 바뀌는 순간 창의성에 대한 해석도 달라질 수 있다.
이러한 이너 서클을 염두에 두는 것은 매우 유용할 수 있다. 팀과 회사가 창의적이 되도록 돕는 것은 자기 팀과 회사가 창의적이라고 널리 알리는 것을 의미하지만, 나 자신으로 부터 시작된다.
더 창의적이 되기 위한 로드맵
책은 천재가 되는 방법을 알려주지 않는다. 즉 창의적 유전자와는 거의 관련이 없다.
앤디 헌트의 실용주의 사고와 학습은 손으로 그린 아름다운 마인드맵으로 시작하는데 이 마인드맵은 로드맵을 겸하고 있다. 그의 책은 프로그래밍에서도 좀 더 소프트웨어 측면에 치우쳐있기에, 해당 그림에서 영감을 받아 비슷한 마인드맵을 새로 그려서 연구 보고서에 사용했다.
창의적 프로그래머의 일곱 가지 테마
기술지식
창의적인 무언가를 만드는 사람이라면 누구나 자기 영역에서 일어나는 상황을 잘 파악하고 있어야 한다.
너무 당연한 이야기라서 한 장 전체를 할애하기에 과한 주제처럼 보일 수 있다.
프로그래머가 애초에 프로그래머가 아니라면 창의적인 프로그래머가 될 수 없다. 무언가를 하려면 그 전에 배우는 단계가 선행되어야 한다는 점은 매우 자명하지만, 정보를 소비하고 지속해서 학습하고 인지 편향을 인식하고, 지식을 관리하는 다양한 방법에 관해 하던 일을 잠시 멈추고 생각해 보는 과정은 여전히 유익하다.
창의적인 프로그래머는 꾸준한 지식의 흐름을 새로운 아이디어로 전환하는 방법을 안다.
커뮤니케이션
창의성은 결코 단독으로 발휘되지 않는다. 아이디어를 다듬는 것은 사회적 과정이다.
독창적인 면이 있는 아이디어를 훌륭한 아이디어로 다듬기 위해서는 반드시 피드백이 있어야 한다.
그러한 과정에서 동료들은 촉매제 역할을 할 수 있다. 이 주제를 다루는 장에서는 천재 클러스터의 개념, 드림 팀을 구성하는 방법, 팀의 창의성을 향상하는 기법에 대해 살펴본다.
창의적인 프로그래머는 아이디어, 개인, 팀 간의 미묘한 상호 작용을 항상 인식한다.
제약 조건
모든 종류의 문제를 해결하려면 제약 조건을 고려해야 합니다. 그것이 자체적으로 부과된 것이든 외부에서 부과된 것이든..
일반적인 믿음과는 달리 제약은 창의성을 감소시키는 것이 아니라 오히려 창의성을 촉발하기도 한다. 성가시고 불편한 것으로 보였던 제약 조건을 오히려 장점으로 전환한 결과 갑자기 창의력이 넘쳐난 여러 사례를 살펴본다.
창의적인 프로그래머는 주어진 제약에 대해 불평하기보다는 이를 주의 깊게 살펴보고 활용하는 방법을 안다.
비판적 사고
어떤 일을 이루기 위해 많은 아이디어를 떠올리는 것은 해야 할 일의 전반에 불과한다.
나머지 절반의 최고의 아이디어가 나올 때까지 아이디어를 과감하게 덜어내는 일이다.