고착에서 빠져나와 창의적 통찰을 얻는 법

트위터에서 질문에 답이나 조언을 드릴 때마다 블로그에 글을 써보려고 합니다. 오늘은 이런 고민을 하는 트친님을 보았습니다.

창의성 연구에 그런 '고착'(한 가지 편견이 굳어져서 다른 생각을 못하는 것)을 막아주는 법들이 나오는데. 몇 가지 알려드릴까요?

— 탐정토끼 (Taehee Kim) (@stelo_kim) September 6, 2021

저는 오래 전부터 많은 창의성 책과 연구를 읽어왔습니다. 창의성 연구들은 이런 문제를 '고착'이라 불러요. 한 가지 편견이 머리에 박히니까, 새로운 생각을 떠올리지 못하는 겁니다.

창의성은 문제를 해결하기 위해 필요해요

옛날 연구 : 다양한 아이디어 떠올리기

그래서 초창기 창의성 연구에서는 '아이디어를 다양하고 많이 떠올리는 게' 중요하다고 생각했습니다. 예를 들어 브레인 스토밍 같은 방법이 있는데요. 생각나는 방법을 검열하지 말고 모두 적어보는 겁니다. 이런 이야기 어디서 들어보시지 않았나요?

성격5요인 중에 개방성이 높은 사람은 이런 걸 잘 합니다. 개방적인 사람들은 빨강 -> 피 -> 육식동물 -> 상어를 연상하거나. 망치를 쓰는 50가지 방법 같은 걸 떠올 릴 수 있습니다. 우리는 보통 이런 게 창의적인 사람이라고 생각하죠!

최신 연구 : 문제해결을 위한 창의성

하지만 요즘 창의성을 연구하는 학자들은 이런 관점에 의문을 품었습니다. 엉뚱한 아이디어가 성공하는 경우도 있지만, 실패하는 경우도 많죠. 그리고 여러 아이디어를 내도 그게 실제로 통하지 않으면 아무 소용이 없습니다.

그래서 학자들은 '문제해결'의 관점에서 창의성을 다시 보기 시작했습니다. 예를 들어 수학 문제를 푼다면 초보자는 잘못된 방법을 쓰고 막히면서 '고착'될 겁니다. 안 되는 방법을 붙잡고 몇 시간 동안 끙끙 거리겠죠. 하지만 숙련된 문제해결자는 다양한 개념을 활용해서 창의적으로 문제를 풀어낼 수 있어요.

창의성의 3가지 경로 : 연결 / 절망 / 모순

그러면 어떻게 해야 고착(fixation)에서 벗어나서, 통찰(insight)을 었을 수 있을까요? 전문가 의사결정 연구의 선구자 게리 클라인씨는 책 [통찰]에서 창의적 통찰은 3가지 경로로 얻을 수 있다고 분류했습니다. 이건 단순히 주관적으로 끌어낸 분류가 아니라 다양한 사례를 일관되게 분류할 수 있는 연구 기법을 통해 정련된 것들이에요.

1. 연결 경로 : 이미 알고 있는 지식을 새로운 방식으로 연결하기
2. 모순 경로 : 모순을 설명하기 위해 새로운 틀을 만들고, 새로운 개념을 배우기
3. 창의적 절망 경로 : 막다른 골목으로 이어지는 잘못된 닻을 버리기

다음 인포그래픽을 한 번 보시죠.

아직 막연하시죠? 이 방법들을 실제 프로그래밍의 사례 속에서 하나씩 이야기해보겠습니다. 이제 매우 많은 방법을 소개드릴텐데요. 카탈로그처럼 생각해주세요. 마지막에 또 이야기하겠지만, 한 번 빠르게 구경해보시고 그 중에 흥미로운 친구만 쏙쏙 뽑아서 써보시면 좋습니다.

익숙한 닻을 버리고, 거리를 두기

닻(Anchor)은 배가 떠내려가지 않게 땅에 걸어두는 아주 무거운 추입니다. 사람 마음에서 닻은 좋은 기준점이 되기도 하지만, 다르게 보면 '고착'의 상징이기도 합니다. 배가 출항해야하는데 항구에 묶여서 못 나간다고 생각해보세요! 그래서 심리학자들은 이런 현상을 두고 '닻 내리기 효과'라는 이름을 붙이기도 했어요.

코딩을 할 때도 비슷한 일을 겪곤 합니다. 당연히 될 것 같은 게 안 되는 거에요. 에러가 나고 안 돌아가는데 이게 왜 안 되는 건지 모르겠습니다. 내가 아는 방법을 계속 써보는데 구현도 안 되고 막힙니다. 막다른 길에 몰립니다. 이걸 창의적 절망이라 합니다.

여기서 빠져나오려면 닻을 버려야 합니다. 거리를 둬야 합니다.

1. 일단 물리적 거리를 둘 수 있습니다.
   • 문제가 안 풀린다면... 컴퓨터에서 손을 떼세요.
   • 의자에서 일어나 커피라도 마시고 오세요.
   • 산책을 하고 오셔도 좋습니다.
   • 안 풀리는 문제를 붙잡고 있지 말고, 머리에서 문제를 비워버리세요.
   • 명상을 하면서 문제를 가만히 바라보고 있는 것도 좋은 방법입니다.
2. 시간적으로 거리를 둘 수 있습니다.
   • 며칠 동안 다른 일을 하다가 문제를 다시보니... 놀랍게도 해결책이 떠오르신 경험이 있지 않나요?
   • 아니면 자고 일어났더니 문제가 풀리기도 합니다. 왜냐면 사람은 자면서 기억을 정리하고, '익숙하지만 잘못된 방법'을 '까먹기' 때문입니다.
3. 지금 내가 당연하게 생각하는 전제는 뭘까? 믿음이나 가정을 쭉 적어보고 의심해보세요.
   • 이 가정이 틀렸다면? 이 가정이 맞는지는 어떻게 검증할 수 있을까요?
4. TDD에서 쓰는 '당연하게 테스트를 통과하는 구현'을 만들어 보는 것도 숨겨진 가정을 찾기 위한 방법입니다.
   • 예를 들어 서버를 만든다면 DB를 쓰지 말고 바로 response로 하드코딩한 값을 돌려주게 해보세요.
   • 저는 어제 TDD 모임에서 board를 추가하는 테스트를 만들 때. 그냥 보드의 jsx를 하드코딩하고 찾아봤습니다. 그런데 찾을 수 없다고 에러가 나는 거에요!
     • 알고보니 다른 테스트에서 render를 한 번 더 했었는데요. dom 의 상태가 바뀌면서 에러가 난 거였습니다. render를 하나만 남기니까 해결되더라고요. 만약에 기능을 처음부터 제대로 구현했다면, 다른 테스트에 문제가 있다는 걸 모르고 삽질을 했겠죠.
5. 익숙하지 않은 환경을 만드는 것도 방법입니다.
   • 예를 들어 평소에 쓰지 않는 폰트나, 가독성이 떨어지는 폰트로 바꿔보세요. 이러면 같은 글이나 코드도 새롭게 볼 수 있습니다.
   • 전자 문서로 읽던 글을 인쇄해서 읽어보세요.
   • 아니면 글쓰기 책들이 조언하듯이 눈으로만 읽지 말고 소리내어 읽어보세요.

이런 방법을 배워도 써먹지 않으면 소용이 없겠죠. 몇 가지를 골라서 한 번 직접 적용해보면 어떨까요? 앞으로 막히고 답이 보이지 않을 때... 어떻게 해볼지 계획을 세워보세요. 사람은 미리 결심을 하고 계획을 세우면 더 잘 지키게 됩니다.

새로운 틀을 만들고, 새로운 개념을 배우기

하지만 이렇게 익숙한 시선을 버린다고 해도... 그게 끝은 아닙니다. 문제의 원인을 안다고 해결책까지 알게 되는 건 아니니까요. 여전히 답이 안 보이실 수도 있어요.

문제를 해결하려면 새로운 시선을 배워야 합니다. 만약에 누군가에게 배울 수 없다면 직접 해결책을 찾아야해요.

1. 풀이된 예제나 답지를 보면서, 어떤 단계로 문제를 푸는지 분석해봅니다.
   • 다른 사람들은 같은 문제를 어떻게 풀었는지 찾아볼 수도 있죠.
   • 만약 답지나 다른 사람들의 풀이를 찾을 수 없다면, 물어볼 수 있는 사람이나 자료를 찾아보세요.
2. 새로운 책을 읽거나, 낯선 개념을 접해보면 좋습니다.
   • 예를 들어 다른 언어나 프레임워크를 배워보실 수 있죠.
   • Java만 써왔다면 Python이나 Clojure 같은 함수형 언어를 배워보세요.
   • 모놀리식 서비스만 만들어왔다면 마이크로서비스를 접하고, 사이드 프로젝트를 해보세요.
3. 주위를 새로운 사람이나 환경으로 채워봐도 좋습니다. 이직을 할 수는 없어도, 트위터에서 특이한 사람들을 팔로우해보세요.
   • 다른 사람과 같이 짝 프로그래밍을 해보세요. 다른 사람은 나와 다른 시선으로 보고. 내가 보지 못하는 걸 볼 수 있습니다.
   • 코치나 선생님, 현명한 시니어에게 내 코드를 보여주고 멘토링을 받아보세요.
   • 회사에 코드 리뷰를 도입하는 것도 방법입니다.
   • 다만 리뷰해 주는 사람도 자기 사고과정을 분석하고 피드백을 주는 방법을 배우지 않으면 큰 효과가 없을 겁니다...
4. 같은 문제나 과제를 다양한 방법으로 구현해보세요.
   • 다른 인터페이스나 구조로 리팩토링해보고 장 단점을 따져보세요.
     • 친구나 동료에게 보여주고 의견을 물어봐도 좋습니다.
     • 이렇게 만든 걸 나중에 버려도 됩니다. 통찰을 얻는 것만으로도 충분해요.
   • 기회가 있으면 다른 스타일의 방법론이나 프레임워크, 언어로 구현해보세요. (ex: for문을 map, filter, reduce로)
   • 자동화 테스트를 배워보세요. 테스트가 있으면 망가트릴까 걱정하지 않고, 자유롭게 리팩토링을 할 수 있습니다.
5. 하지만 생각보다 자주 답을 찾을 수 없는 신기한 '모순'과 마주치고는 합니다.
   • 일단 이런 궁금증을 질문으로 적어두세요. 목록을 만들거나 노션 같은 곳에 쌓아두세요.
   • 대부분 계속 새로운 지식을 접하다보면 '우연히' 해법과 마주치게 될 겁니다.
6. 여전히 답을 찾을 수 없다고요? 축하합니다. 이제 새로운 통찰이 필요할 것 같군요.

직접 가설을 세우고 실험하면서 새로운 '틀'을 만들어낼 때가 되었습니다.

적응하고 변화하는 전문가

옛날 학자들은 전문가가 단순히 지식이 많은 사람이라 생각했습니다. 많은 지식과 도구를 가지고 있으니, 문제를 척척 풀어낼 수 있다고 생각한 거죠. "아, 이거 뻔하네. 전에 봤던 문제랑 비슷하네~" 하고 술술 손이 문제를 풀어버리는 천재처럼 생각한 겁니다.

그런데 이런 전문가들은 문제가 있었습니다. 새로운 패러다임이 등장하면 시대에 뒤떨어지고 적응하질 못했습니다. 새로운 문제를 주면 나는 이런 거 해본 적이 없다고 풀질 못합니다.

IT 업계, 특히 요즘 프런트엔드는 빠르게 변하고 있습니다. HTML5와 ES6, 수 많은 툴체인과 프레임워크가 쏟아져 나오고 있죠. 누군가는 여기서 기회를 찾지만, 어떤 회사나 팀은 적응하지 못하고 망해버리기도 합니다.

요즘 학자들은 새로운 전문가를 찾아 나섰습니다. 낯설고 처음 보는 문제에도 빠르게 적응하고 해결하는 전문가들이 있습니다. 새로운 프로그래밍 언어나 프레임워크도 금방 배우고요. '학습'의 달인이자, 전에 보지 못했던 방식으로 문제를 척척 해결하는 전문가들! 그래서 이런 분들의 능력을 '적응적 전문성'이라고 부릅니다.

이런 전문가들은 맹목적으로 최신 기술이나 트렌드만 쫓지 않습니다. 서로 다른 기술의 장, 단점이나 '트레이드 오프'를 파악하고요. 상황에 맞게 필요한 기술을 사용하는 '유연함'을 갖추고 있습니다.

이미 알고 있는 지식 연결하기

세상에 새로운 지식은 없다는 말이 있습니다. 많은 것들이 변하지만, 변하지 않는 것들도 있습니다. 오히려 새로운 기술은 익숙한 기술을 새로운 방식으로 조합하고 있다고 할 수도 있습니다.

HTML과 HTTP는 물리학자 팀 버너스리가 1989년 CERN이라는 연구소에서 만들었습니다. CERN은 힉스입자를 발견했던 거대 강입자 충돌기(LHC)가 있는 곳이기도 하죠. 원래 논문의 참고문헌과 링크를 쉽게 돌아다니고 공유하기 위해 만들었는데. 이제 수 많은 쇼핑몰이며 웹 사이트가 이 레거시 위에서 돌아갑니다.

HTML5가 나오고 이제 HTTP 2.0과 HTTP3.0 이야기도 나오고 있지만... 기본 틀은 아직도 크게 변하지 않았습니다. 그래서 React를 하더라도 여전히 HTML이나 CSS 같은 마크업에 대해 잘 이해해야 합니다.

이런 예시는 끝 없이 많습니다. 기존에 있던 것에서 영감을 받아 새로운 것이 탄생합니다. 생물학을 전공한 앨런 케이는, 세포들이 모여서 복잡한 일을 하는 것에 감명 받고 객체지향 프로그래밍을 만들었습니다. 객체지향 프로그래밍은 DDD에 영향을 줬고, 이제 마이크로서비스가 그 뒤를 이어가고 있죠.

그러면 우리는 익숙한 걸 통해 새로운 것을 이해하고, 조합해서 새로운 걸 만들 수 있을까요?

1. 공부를 할 때 항상 전에 배운 것과 연결하려 해봅시다.
   • 새로운 기술을 배우면 공통점과 차이점을 비교해보세요. 서로 장, 단점은 무엇이고 어떤 트레이드 오프가 있는지 찾아보세요. (트레이드 오프가 어떤 뜻인지 모른다면 인터넷을 찾아보세요!)
2. 추상적인 말이나 표현을 보면 구체적인 내 경험을 떠올려보세요. 예를 들어 배포 자동화나 CI/CD에 대한 글을 읽는다면. AWS에 배포하고 환경을 설정하려 삽질했던 경험을 떠올려보세요.
3. 추상적인 개념을 다양한 곳에 적용해보고, 패턴을 찾아보세요.
   • 테스트 자동화, 배포 자동화, script 자동화... 반복적인 타이핑을 자동화할 수 없을까요? Vim이나 단축키를 배워보세요. 뭔가 패턴이 있는데 귀찮게 반복되는 일이라면 자동화할 수 있는 경우가 많습니다.
   • 새로운 곳에 적용해서, 나만의 방법을 만들어보세요. 앞에서 거리두기를 이야기했었죠? 물리적 거리를 두는 방법은 또 뭐가 있을까요?
4. 내가 아는 다른 분야나 지식을 비유해서 적용해보세요.
   • 예를 들어 객체지향을 팀이나 조직에 비유해보면, 동아리를 운영했던 경험이 아키텍처 설계에 통찰을 줄 수도 있습니다.
   • 함수형 프로그래밍은 수학의 카테고리 이론을 적용해서 만들었습니다. 관계형 DB는 집합론을 이용해 만들었습니다.
   • 한 대학 입시 관련 시스템은 택배 시스템에서 아이디어를 얻어서 만들었다고 합니다.
5. 뭘 배울 때마다 노트나, 노션 등에 정리해두고 시간 날 때마다 돌아보세요. "내가 이런 것도 배웠었네? 여기에 써먹을 수 없을까?"라는 통찰이 떠오를 겁니다.
   • 저는 사놓고 쌓아둔 책의 목차를 자주 살펴봅니다. 책을 펼치면 마침 딱 필요했던 지식이 있는 경우도 많았어요.
   • 안키 같은 플래시 카드 앱으로, 몇 달 전에 배운 걸 복습해보셔도 비슷한 효과를 보실 수 있어요.
6. 여러가지를 번갈아가면서 공부해보세요. 뒤섞이면 연결이 더 잘 일어납니다.
   • 예를 들어 프런트와 백엔드를 같이 공부해볼 수 있어요. 저는 백엔드에서 많이 쓰이는 DDD에서 상태 관리를 테스트하는 방법을 찾았습니다. 스벨트 웹과 스벨트 네이티브가 같이 쓸 수 있는 공통 모듈을 만드는 법도 깨달을 수 있었습니다.
   • 또 다른 예로 영어 문법을 공부하다가 프로그래밍 언어를 공부하는데 도움이 되는 통찰을 찾을 수도 있습니다. 코칭을 받는 어떤 분은 CSS를 단어장으로 만들어서 외우고 계세요!

하나씩 적용해보면서 시행착오로 개선해나간다

와, 정말 많은 방법들이 있죠? 이 모든 걸 한 번에 다 배우고 적용하실 수는 없을 거에요. 앞에서도 말씀드렸지만 한 두 가지씩 내 삶에 직접 적용해보세요. 실제로 써보시면 여러 문제가 생길 겁니다. 이런 문제를 해결할 방법을 하나 둘 씩 개발하고 배워보시면 점점 많은 문제를 새로운 방법으로 푸실 수 있을 거에요.

제가 전에 썼던 일일회고 가이드를 참고하셔도 좋겠죠. 매일 꾸준히 회고를 적어보고, 동료나 친구와 공유해보세요.

창의적으로 문제를 해결하는 법에 대해 더 많은 걸 알고 싶으시거나, 연구와 근거가 궁금하시다면, 제가 트위터에 썼던 책 추천 타래를 읽어보세요.

한 때에는 탐정이나 창의적 사고가 궁금해서 관련 책을 많이 읽었어요. 기억 나는 걸로는 [통찰], [틀 안에서 생각하기]나 [지그재그]나 [생각의 재구성] [블라인드 스팟] 같은 책이 추천할 법 하네요.

예를 들어 통찰은 인튜이션 등 전문가의 직관 연구로 유명한 게리 클라인이 쓴 책인데요.

— 탐정토끼 (Taehee Kim) (@stelo_kim) August 9, 2021

그 외에도 궁금하신 게 있으시면 댓글로 적어주세요. 도움이 되셨다면, 멍드립님이 만드신 호메테에서 저를 칭찬해주실 수도 있어요 :)