The Creative Programmer

1챕터: 창의적인 길 (The Creative Road Ahead)

1.1 창의성이란 무엇인가?

• 심리학자들은 수십 년간 논쟁을 벌여온 결과 약 100가지의 창의성 정의가 존재
• Kaufman & Sternberg의 본질주의적 정의 — 창의적 아이디어의 3가지 조건:
  1. 새롭고 독창적일 것 (novel and original)
  2. 높은 품질을 가질 것 (high quality)
  3. 당면 과제와 관련성이 있을 것 (relevant)
• 이 본질주의적 정의의 문제점: 맥락을 완전히 무시함
• 창의성 연구의 흐름은 맥락적 요소를 고려하는 시스템적 접근으로 이동 중
• 결론: 창의성은 사회적 판결(social verdict) → 내가 아닌 타인이 창의성을 인정함
  • 동료 팀원이 “훌륭한 코드야, 창의적인 방법이야!” 라고 할 때 창의적 프로그래머가 됨
  • 같은 솔루션이 다른 팀에선 진부하게 여겨질 수 있음 → 사회문화적 현상
• 창의성이 인정받지 못한 역사적 사례: 빈센트 반 고흐 — 생전에 파리 살롱에서 지속적으로 거절당함, 사후에 가장 비싼 그림 반열에 오름

창의성의 역사적 기원

• 고대 그리스: 예술(technê)은 규칙 준수 → 화가/조각가는 모방, 시인만 자유
• 기독교 중세 유럽: 창조(creatio ex nihilo)는 신의 영역, 인간은 단순히 ‘만들 뿐’
• 르네상스: 예술가가 스스로를 발명가로 인식하기 시작
• 창의성이 과학적 연구 주제로 자리 잡은 것은 1950년대에 들어서야 가능 — 프로그래밍과 마찬가지로 비교적 새로운 개념

1.2 왜 창의성인가?

• 이유 1 — 고용주가 원하기 때문: 소프트웨어 개발 채용 공고에 거의 항상 “creative”라는 단어 등장; 개발 전문가들 인터뷰에서도 창의성이 비기술적 역량 1위로 꼽힘
• 이유 2 — 문제 해결을 위해: 기존 방법이 실패할 때 창의성이 해결사 역할
  • 예: 웹 앱의 초당 수천 요청 처리 문제 → 메시지 큐잉, 로드 밸런싱, 캐싱, 코루틴 제안 가능
  • 창의적 프로그래머는 문제를 찾는 사람(problem finder) + 문제를 푸는 사람 양쪽
  • Darwin의 비글호 항해 비유: 남미 해안 측량 임무 중 자연선택 이론의 씨앗을 발견 → 문제 도메인 자체가 존재하지 않던 상황에서 발견
• 이유 3 — 재미: 창의적 프로그래머는 자신의 일을 깊이 즐김; 불편한 영역 탈출, 아이디어 연결, 흐름(flow) 상태 경험

창의적 제품 vs. 과정

• 우리는 보통 **결과물(product)**을 칭찬함: 알고리즘, 디자인 패턴, 앱 전체
• **과정(process)**도 창의적일 수 있으나 보이지 않아 평가가 어려움
• Teresa Amabile(1988)이 창안한 Consensual Assessment Technique: 전문가들이 제품의 창의성을 평가하는 방법

1.3 창의성의 레벨

• little-c (everyday creativity): 본인이 이전에 하지 않았던 독창적인 것 → 예: C++11 게임을 GBA로 크로스 컴파일
• Big-C (eminent creativity): 아무도 하지 않았던 독창적인 것 → 예: 486 PC에서 Ruby 3 포팅; Linus Torvalds가 OS 및 버전 관리 도메인 전체를 변환
• 추가 분류:
  • H-creativity: 역사 책에 기록될 발명인가?
  • P-creativity: 개인적 창의성
  • mini-c, Pro-c: little-c와 Big-C 사이의 숨겨진 레이어
• Mark Runco의 비판: “big/little 이분법은 허구 — 현실은 범주적이지 않다”
• 창의성의 수준은 사회적 맥락에 따라 달라짐 → 팀, 회사, 도메인 레벨에서 각각 다르게 평가됨 (동심원 모델)

1.4 창의적 프로그래머가 되기 위한 로드맵

1.4.1 7가지 Creative Programmer 테마

1. 기술적 지식 (Technical Knowledge): 창의적 결과물을 내려면 해당 도메인의 현황을 깊이 파악해야 함; 지식 흐름을 새로운 아이디어로 변환하는 능력
2. 협업/소통 (Collaboration/Communication): 창의성은 고립 속에서 발생하지 않음; 동료가 촉매제 역할; 천재 클러스터(genius clusters), 드림팀 구성법, 팀 창의성 강화 기법 포함
3. 제약 (Constraints): 제약은 창의성을 억제하는 것이 아니라 오히려 자극함; 제약을 불평하는 대신 활용하는 능력
4. 비판적 사고 (Critical Thinking): 아이디어를 많이 생성하는 것이 절반; 나머지 절반은 가장 좋은 아이디어가 남을 때까지 엄격히 걸러내는 것; 발산적 사고와 비판적 평가 사이를 유연하게 전환
5. 호기심 (Curiosity): Csikszentmihalyi에 따르면 호기심과 끈기가 창의성의 가장 중요한 두 성격 특성; 호기심 → 지식 습득 동기 + “왜?“라는 질문으로 이어짐
6. 창의적 마음 상태 (Creative State of Mind): 잦은 방해는 흐름(flow)을 해침; 올바른 마음 상태가 창의적 작업을 크게 향상; 인사이트 프라이밍, “아하!” 순간 증가 방법 포함
7. 창의적 기법 (Creative Techniques): 위 6개 테마 모두에 영향을 미치는 실용적 기법들; 브레인스토밍 비판 + 대안적 기법 탐구

1.4.2 CPPST (Creative Programming Problem Solving Test)

• 저자와 동료들이 7가지 테마 기반으로 설계한 자가 평가 설문
• 소프트웨어 공학과 1·4학년생 대상으로 검증됨, 업계 전문가들도 확인
• 각 질문에 1~5점 부여 (1: 전혀 동의하지 않음 ~ 5: 완전히 동의함)
• 결과를 스파이더 다이어그램으로 시각화 → 단일 점수로 환원 불가 (맥락적 연결 보존 목적)
• 특정 프로젝트 맥락에 따라 점수가 달라지는 것이 정상; 창의적 프로세스 성찰 도구

1.5 이후 챕터 구성 방식

• 각 챕터는 배경 스토리로 시작 (기술 내외부의 창의적 사고 사례)
• 비디오 게임 레퍼런스 적극 활용 → 시각적 예시가 흥미를 높이고 유희적 학습 유발
• 연습문제(Exercise) 포함 → 사고 훈련용, 회고(retrospective) 주제로도 활용 가능
• 각 챕터 말미에 체크리스트 제공 → 요약이지만 단순 스캔으로는 창의성 마스터 불가

2챕터: 기술적 지식 (Technical Knowledge)

2.1 인풋 없이 창의적 아웃풋 없다

• 세 가지 도입 사례의 공통점 → 창의성은 창의성을 낳는다 (creativity begets creativity):
  • 세네카: 경쟁 철학 학파를 내면화 → 스토아 철학 저작 탄생
  • 루만(Luhmann): 제텔카스텐 노트와 “대화” → 관련 없어 보이는 도메인 연결
  • 코틀린(Kotlin) 팀 Breslav: 기존 언어들(Java, Scala, C#, Groovy)에서 작동하는 것만 채택 → 실용적이지만 부적합한 창의성 회피
• 모든 창의적 작업은 인풋에서 시작
• 소프트웨어 엔지니어링 전문가 인터뷰에서 창의성 요건으로 기술적 지식이 일관되게 1위
• 창의성 접근 방식 세 가지:
  • 구조주의적 (Structuralist): 기법과 방법론 분석 → 챕터 2
  • 상황주의적 (Situationalist): 사회적 맥락에 따라 달라짐 → 챕터 3
  • 영감주의적 (Inspirationalist): 자유 연상, 유희성, 수평적 사고 → 챕터 4~6
• 비유: 악기 지식 없는 음악가, 드로잉 기법 없는 화가는 창의적 작업 불가 → 프로그래머도 동일; JVM 생태계 없이 Java 창의성 발휘 불가

2.2 지식 수집 (Gathering Knowledge)

2.2.1 인풋 다양화 (Diversify what goes in)

• 다양화의 두 가지 의미:
  1. 주제 다양화: 한 바구니에 달걀 전부를 넣지 말 것
     • 예: Java 개발자라면 Go의 Goroutine, Ruby의 동시성 액터도 공부 → 비교 관점 확보
     • 기술 서적뿐만 아니라 철학, 심리학, 역사도 공부 → 창의적 프로그래머는 도메인 간 연결을 잘함
     • “전문가 1~2개 주제만 요구”하는 직장 관점은 매우 좁고 비창의적
  2. 매체 다양화: 책, 컨퍼런스, 뉴스레터, 블로그(읽기보다 쓰기가 더 좋음), 독서 그룹 등

창의성은 도메인 특수적인가, 일반적인가?

• 한 편: Ruby를 표현하려면 도메인 특화 숙달 필요 (10,000시간, Dreyfus 모델)
• 다른 편: 많은 창의적 기법은 도메인 일반적 (호기심, 아이디어 숙성 등은 원예에도 적용)
• 결론: 둘 다 해당 — 창의성은 도메인 특수적이면서도 일반적

2.2.2 인풋 조절 (Moderate what goes in)

• 독서는 연간 처리 가능한 양이 한정 → 지식 칼로리 섭취량 조절 필요
• RSS 리더 활용 → 광고, 중복 뉴스 차단, 정보 흐름 제어
• 과도하게 구독하면 정보 과부하 → David Allen의 GTD(Getting Things Done) 방식으로 관리

과도한 지식이 창의성을 방해하는가?

• 지식 프라이밍(knowledge priming) 현상: 지식이 주입된 참가자들은 아이디어는 더 많이 생성하나 독창성은 낮음
• 전문가적 확신이 창의적 아이디어를 조기에 거부하게 만듦
• → 챕터 4(제약)에서 나이브함의 효과 탐구

2.3 지식 내면화 (Internalizing Knowledge)

• 핵심: 정보를 자신의 맥락으로 재프레이밍(reframing) 하는 것
• 손으로 쓰는 것이 더 효과적 (Mueller & Oppenheimer 연구: “The pen is mightier than the keyboard”):
  • 장기 기억 저장 가능성 증가
  • 받아쓰기 대신 자신의 말로 재프레이밍하는 경향 → 학습에 더 유익
  • 필기의 촉각 피드백이 뇌의 여러 영역(작업 기억 포함)을 동시에 활성화
• 팀 위키(wiki) 활용: 정규식 스니펫, Bash 스크립트, 코드 패턴 등 팀 공유 지식 베이스로 유용
  • Slack/Discord는 일시적 소통 도구 — 영구적·검색 가능한 지식 베이스 대체 불가
  • 이메일도 지식 베이스로 불충분

디지털 노트 도구 목록

• 단순 파일 구조
• Microsoft OneNote, DEVONthink, Evernote (OCR, 문서 스캔, 클라우드 저장)
• Obsidian, Zettlr (하이퍼링크 강조)
• 마인드맵 소프트웨어
• Markdown 기반 정적 사이트 생성기

벤더 종속 회피

• 외부 지식 베이스는 소프트웨어보다 오래 지속됨 → 사람이 읽을 수 있는 포맷으로 내보내기 기능 중요
• Evernote: 독점 XML 포맷 사용 → 다른 도구로 이전 시 커스텀 스크립트 필요
• 클라우드 저장 노트는 “내 노트가 아닐 수 있음” 위험 존재

2.3.1 지식 관리 (Knowledge Management)

• John C. Maxwell: “You gotta have a system” — 지식 추적 및 아이디어 생성을 위한 일관된 시스템 필요
• 역사적 노트 테이커들: 키케로(편지), 레오나르도 다 빈치(노트북 + 스케치), 마르쿠스 아우렐리우스, 찰스 다윈, 아서 코난 도일, 앨런 튜링, Eric Evans(DDD 창안자)
• Csikszentmihalyi 인터뷰: 창의적 천재들 모두 아날로그 노트 테이킹이 창의적 성공의 촉매라고 응답
• Commonplace Books (공통 노트북): 1685년 John Locke가 체계화; 16~17세기 지식 기록의 가장 인기 있는 방법
  • 아리스토텔레스의 Lyceum 수업에서 사용한 ‘공통 장소’ 개념에서 유래
  • 인용문 복사 후 개인 소견 추가 → 지식 내면화
• 저자의 선호: 아날로그 노트 — 그림 추가, 다양한 펜, 스크랩, 화살표 등 표현 자유도 높음
• 다이어리 vs. 저널 vs. 노트북의 구분 불필요 → 하나의 노트북에 모든 것을 기록해야 영역 간 연결 가능

2.4 지식으로 행동하기 (Acting on Knowledge)

• 수집과 번역의 유일한 목적: 새롭고 실행 가능한 인사이트 생성
  • Novelty = 지식의 비범한 결합
  • Action = 그것을 코드나 출판물 등 유형의 결과로 변환
• Collector’s Fallacy 경계: 흥미로운 것들을 쌓아두기만 하고 다시 보지 않는 함정; 기술 지식은 빠르게 구식이 됨
• 기억력에 의존 금지 → Edward O. Wilson(사회생물학 발명): 사회과학과 생물학 두 분야 광범위한 노트 합성에서 아이디어 탄생

2.4.1 노트북 → 메멕스 → 제넥스

• Memex (Vannevar Bush, 1945년): 개인이 모든 책, 기록, 통신을 저장하고 극도로 빠르게 참조하는 장치; 연상 링크 형태 데이터 저장 → 하이퍼링크의 영감
• 블로깅(2000년대 초): 메멕스 개념의 현실화
• Obsidian: [[link]] 문법으로 노트 간 연결; 백링크 기능으로 다른 노트에서 자신을 가리키는 링크 탐색; 관련 미연결 노트 자동 감지
• Genex (Ben Shneiderman): 메멕스 2.0 — 단순 디지털 도서관을 넘어 창의성 지원 도구; 혁신 창출, 멘토/동료와 대화, 수혜자에게 전파 지원

2.4.2 노트에서 행동으로

• 노트를 쌓기만 하는 것은 무용 → 정기적 검토와 재작업 필요
• David Allen의 GTD(Getting Things Done): 두 가지 모자 — “생각 모자(노트 작성)” + “행동 모자(실행)”
• David Allen의 “Mind Like Water” 태도 (불교적 영감): 행동 중 다른 할 일로 마음이 흐트러지지 않도록; 노트에 적고 잊어라
• Luhmann의 Zettelkasten (제텔카스텐, “슬립 박스”):
  • 번호 기반 인덱스 카드 → 선형 연속 + 분기(branch) 동시 지원 (예: 32 → 33 연속; 32 → 32a 분기)
  • 각 카드에 하나의 아이디어만 담음 → 소프트웨어 설계의 관심사 분리(Separation of Concerns) 원칙 적용
  • 노트를 자신의 말로 작성 → 개인 맥락으로 번역 (복사 절대 금지)
  • 설정 비용이 책 한 권 쓰는 것보다 크지만, 노트가 커질수록 출판이 쉬워짐
  • Zettelkasten = Luhmann의 genex (탁월함 생성기)
• Sönke Ahrens의 스마트 노트 학습 원리: elaboration(정교화), spacing(간격), variation(변형), contextual interference(맥락적 간섭), retrieval(인출)이 학습 과정에서 방해처럼 느껴지나 실제로는 학습 강화

2.4.3 노트 유지보수

• 노트 시스템 = 디지털 정원(digital garden): 성장하는 소프트웨어 비유처럼 아이디어도 성장
• 코드 리팩토링처럼 노트도 정기적 가지치기(pruning) 필요 → William Faulkner: “Kill your darlings”
• 디지털 가드닝도 Dreyfus 모델 적용: 초보자는 엄격한 규칙 필요 → 전문가는 규칙 초월, 맥락과 직관으로 판단
• 공개 vs. 비공개 정원: 공개 노트는 더 명확한 맥락 제공 필요 → 글쓰기 능력 향상; 팀 위키는 동료가 쉽게 이해할 수 있어야 오해·버그 방지

2.4.4 방해에서 행동으로

• 노트는 짧은 방해 후 원래 작업으로 돌아오는 단서 역할도 함
• Chris Parnin & Robert DeLine(2010): 개발자들은 방해받은 작업 재개 시 대부분 다양한 매체에 걸친 노트 작성에 의존
• 임시 노트 (disposable, one-shot): 작업 재개 후 폐기
• 영구 노트 (Luhmann식): 학습을 돕는 노트 → 임시 노트에서 영구 노트로 스킬 진화 필요

2.5 워크플로우 예시

• Harold Jarche의 Seek → Sense → Share 프레임워크:
  • Seeking: RSS, 동료 네트워크 등으로 업데이트 유지; 신뢰받는 큐레이터가 정보 필터링
  • Sensing: 정보 개인화 및 내면화; 반성, 이전 지식과 연결, 실험 포함
  • Sharing: 자원/아이디어/경험 교환 → 타인의 Sensing 인풋 큐레이터가 됨
• 공유는 타인에게만 이롭지 않음 → 리처드 파인만: “가르치는 것이 최고의 학습법”
• 프로그래머는 지식 공유의 선구자지만 대부분 소비만 하고 기여하지 않음 → contributor로 레벨 업 필요

2.5.1 5단계 워크플로우

1. Available information: 전체 지식의 집합체 — 시스템 없이는 관리 불가
2. Curated interests: RSS, 이메일, 위키피디아, 대화, 박물관 등에서 관심사 선별
3. Synthesized thoughts: 관심사를 노트/펜으로 맥락화·고정화 (sensing); 공간적 단서, 다이어그램, 화살표 활용; 이 단계에서 디지털 도구는 학습 촉진에 비효과적
4. Digitized and cross-linked notes: 월 1회 스캔 → Obsidian에 링크 노트로 저장; 3+4단계를 합치면 안 됨 (관심사 분리 위반, 학습 이익 손실)
5. Published work: 링크된 노트를 끌어내 정리·요약; 대부분의 작업은 이전 단계에서 완료; 아이디어는 숙성 필요 — Susannah Conway의 “composting”, 도요타 생산 시스템의 “Nemawashi”

3챕터: 소통과 협업 (Communication)

3.1 협력적 팀워크

• 도입 사례들의 공통점:
  • 아리스토텔레스의 소요학파 (Peripatetics): 열린 토론 → 귀납적·연역적 추론의 기초 형성
  • 피렌체 카메라타 (Florentine Camerata, 16세기 말): 음악가·시인·철학자 모임 → 바흐·모차르트 음악의 간접적 토대; 심포니와 오페라 형성에 기여
  • 파리 아방가르드 운동 (19세기 말): 살롱 거부 → 인상주의, 입체파 등 수많은 -ism 창출; 세잔, 피카소, 반 고흐, 모네 등 집결
  • Extreme Tuesday Club (런던, 2000년대): 애자일·익스트림 프로그래밍 초창기 아이디어 시험대 → CI/CD, DevOps, 칸반, 기술 부채, 마이크로서비스, 목킹 기법 등 탄생

협업의 4가지 핵심 원칙

1. 공유된 문제 보유
2. 서로에게서 배움 (상호 학습)
3. 상호 연결 (interconnected)
4. 비판적 피드백 제공

Symmathesy (심마테시)

• Gregory Bateson의 시스템 사고: “진화는 맥락 안에 있다 — 주체(개인)에 있지 않다”
• Nora Bateson이 신조어 창안 → sym(“함께”) + mathesi(“배우다”)
• 정의: 상호작용을 통한 맥락적 상호 학습으로 구성된 살아있는 학습 시스템
• 카메라타 = 심마테시의 전형적 사례
• 에코 챔버 효과 주의: 비슷한 생각의 사람들끼리만 모여 공유 내러티브를 강화하면 살아있는 시스템이 생명 유지 장치에 연결된 상태가 됨
• 개인의 창의적 작업 개선에 소셜 피드백이 필수 (Shneiderman의 genex도 사회적 프로세스로만 정제됨)

3.1.2 드림팀 (Dream Teams)

• 이질적인 구성원들이 잘 소통하는 팀이 개인보다 창의적 문제 해결 가능성 높음
• 카메라타 같은 집단의 효과:
  • 더 큰 문제를 더 빠르게 식별·해결
  • 정서적 참여 증가
• Great teams make great people (Jessica Kerr): 뛰어난 팀원보다 팀 환경이 먼저
  • 단, 닭이 먼저냐 달걀이 먼저냐의 문제 → 둘 다 상호작용

3.2 집단의 지리학 (Collective Geography)

• Csikszentmihalyi: “개인의 창의적 힘은 미미하다” — 아인슈타인도 Akademie Olympia 토론 그룹이 있었음
• 창의적 성공을 높이려면 → 고성취자들에게 둘러싸이는 것이 답

3.2.1 리퀴드 네트워크 (Liquid Networks)

• Steven Johnson의 “Where Good Ideas Come From” 핵심 개념:
  • 고체(Solid): 아이디어가 굳어있는 상태 → 혁신 정체
  • 액체(Liquid): 새로운 연결 가능 → 최적의 창의적 환경
  • 기체(Gas): 아이디어가 너무 변덕스러워 정착 불가
• 초기 수렵채집인 = 기체 상태; 정착하여 도시 형성 → 액체 네트워크 등장 → 아이디어 ‘전파(spill over)’ 가능해짐
• 혁신이 지리적으로 클러스터링되는 이유 설명
• Dean Simonton: 중세 일본 연구 → 외부 문화 영향에 대한 국가적 개방성이 여러 분야에서 성취와 양의 상관관계
• Seth Godin: “아이디어는 다른 세계들이 충돌할 때 나온다”
• 개인 지식 시스템과의 연결: 같은 아이디어만 반복하는 노트 = 고체화; 너무 희귀한 독창적 아이디어 = 기체화 → 두 극단 사이의 액체 상태 유지가 이상적
• 글로벌리즘·인터넷으로 지리적 한계 일부 극복 가능, 그러나 여전히 저명 기업·연구소는 인재를 유인

3.2.2 창의성은 전염된다

• Albert Einstein: “Creativity is contagious”
• 연구 결과: 창의적 동료들에 둘러싸이면 우리 자신도 더 창의적이 됨
• 대학 간 해커톤 실험: 같은 공간의 다른 팀들에게서 영감을 받아 자신의 해결책에 적용

3.3 기술 수용 곡선 (Technology Adoption Curve)

• 혁신 확산 이론 (Rogers, 1962): 혁신자(Innovators) → 얼리어답터(Early Adopters) → 초기 다수(Early Majority) → 후기 다수(Late Majority) → 지각 수용자(Laggards)
• 창의적 프로그래머는 혁신자 또는 얼리어답터 구간에 있는 것이 이상적
• ThoughtWorks 기술 레이더: 기술·도구·플랫폼·언어를 ADOPT/TRIAL/ASSESS/HOLD 4단계로 분류하여 팀의 기술 수용 지점을 가이드
• 외로운 선구자의 문제: 너무 일찍 도입하면 동료들의 저항; 창의적 아이디어의 시간 기반 맥락 중요
• Time Warp (시간 왜곡): 일부 개발자들이 구식 기술에 집착하여 팀 진보를 방해

3.4 소셜 부채 (Social Debt)

• 기술 부채(Technical Debt)와 유사 개념 → Damian Tamburri가 창안
• 소셜 부채(Social Debt): 잘못된 소통·협업 패턴이 누적되어 발생하는 팀 기반 문제
• 커뮤니티 냄새(Community Smells): 코드 냄새(Code Smells)처럼 팀 사회적 문제를 명명하여 논의 가능하게 만듦

주요 커뮤니티 냄새 목록

• Cognitive Distance: 팀원들 간의 지식·가치관·실무 차이가 소통을 어렵게 만드는 상황
• Black Cloud: 팀 내외 정보 과부하로 좋은 아이디어가 유실됨
• Lone Wolf: 타인의 의견 없이 독자적으로 커밋하는 개발자
• Unlearning: 구형 직원들이 새 기술 습득을 거부하여 지식 손실 발생
• Cookbook Development: 새 기술·아이디어 적응 거부
• Institutional Isomorphism: 다른 팀들에 동일한 프로세스·프레임워크 강제 → 유연성·사기·협업 저하
• Hyper-Community: 지나치게 변동성 높은 사고 환경 → 버그 많은 소프트웨어
• DevOps Clash: 개발팀과 운영팀의 엄격한 분리(지리적 포함) → 문화 충돌·신뢰 부재
• Informality Excess: 프로토콜 전무한 과도한 비격식 → 낮은 책임감
• Power Distance: 권한이 낮은 팀원들이 권한자와의 거리를 인식·수용하여 지식 공유 저해
• Disengagement: 검증되지 않은 가정과 참여 부족으로 제품이 출시 준비가 됐다고 착각
• Priggish Members: 불필요하게 까다롭고 정밀한 구성원들이 지연·좌절 유발
• Newbie Free-Riding: 신입이 팀에 무임승차 (쌍 프로그래밍으로 완화 가능)

3.4.4 소셜 부채 탈출 방법

• 공유 책임(Shared Responsibility): Christopher Avery의 Responsibility Process — 부정/정당화/비난 상태 탈출 → 문제에 집단적 책임 직면
• 페어 프로그래밍(Pair Programming):
  • Lone Wolf, Unlearning, Cookbook Development, Newbie Free-Riding 냄새 완화
  • 장기적 효과: 인사이트 촉진, 코드 품질 향상, 행복감·자신감 증가
  • 행복 → 창의성 강화 → 행복의 강화 피드백 루프
  • Csikszentmihalyi: “많은 사람에게 행복은 새로운 것을 만들고 발견하는 데서 온다”
• “Communication is the key factor to reduce social debt” — Gemma Catalino(2021)
• 아키텍트의 역할: 커뮤니티 목자(shepherd)로서 암묵적 문제를 명시적으로 드러내는 책임; 단, 이 책임은 팀 전체가 공유해야 함

3챕터 핵심 요약

• 집단 창의성이 개인 창의적 노력을 크게 향상 → 다양하지만 같은 방향을 보는 공동체 참여
• 창의적 클러스터는 특정 지역에 유기적으로 집결하는 경향 → 인공적 조성은 어려움
• 아이디어 확산에는 시간이 필요 → 혁신 수용 곡선 이해
• 상호 학습(mutual learning): 가르치는 쪽도 배우는 쪽도 모두 이익
• 여러 도메인·그룹에 걸쳐 아이디어 교차 수분(cross-pollinate)
• 창의성은 시스템적 현상 → 부분들의 합 이상
• 진정한 비판적 피드백 제공·환영 → 에코 챔버 효과 방지
• 네트워크 상태 파악: 고체(정체)/기체(과도한 변동)/액체(이상적 확산)
• 소셜 부채를 식별하고 커뮤니티 냄새에 이름 붙이는 것이 해결의 시작

4챕터: 제약 기반 사고 (Constraint-Based Thinking)

4.0 도입부

• Eumenes(파피루스 공급 차단), Cézanne(하나의 캔버스에 두 시점 고집), id Software(NeXT 컴퓨터 도입) 공통점 → 제약이 급진적·혁신적 발명의 촉매
• DOOM 팀: 일반 IBM PC 대신 $100,000+ 투자한 NeXT 컴퓨터 사용 → 1년 만에 완성, 첫 해 수백만 달러 수익
• Goethe: “거대한 일을 하려는 자는 자제력을 보여야 한다. 장인은 구속 속에서 처음 드러난다. 오직 법칙만이 자유를 줄 수 있다”

4.1 제약 기반 사고

• 제약은 창의성에 필수적으로 중요 → “제약 없음 = 창의성 없음”
• 제약의 두 종류
  • 자기부과(self-imposed): Cézanne이 스스로 하나의 캔버스를 고집한 것처럼 의도적으로 선택
  • 외부부과(forced): 주어진 것과 함께 일하거나 우회책을 찾아야 함

4.1.1 그린필드 vs 브라운필드

• 그린필드(greenfield) 프로젝트: 새 기술 선택 자유, 기존 시스템 없음 → 처음엔 재밌지만 제약 없어 지루함 유발
• 브라운필드(brownfield) 프로젝트: 기존 레거시 코드와 함께 작업 → 제약 때문에 더 창의적 행동 유발
• 인터뷰된 개발자들: “제약 없는 문제는 결국 지루해진다”
• 교육 현장 문제: 학생들에게 깔끔하게 정의된 그린필드 문제만 제공 → 현실 제약 다루는 법을 못 배움
• Adam Barr(MS 베테랑): 실제 오픈소스 프로젝트를 학교에서 활용해야 한다고 주장

4.1.2 제약의 분류법

• Jon Elster(노르웨이 정치 이론가)의 분류:
  • 우연적(incidental): 내재적·부과적 제약 → 선택하지 않았지만 혜택이 있음
  • 본질적(essential): 자기부과 제약 → 창의적 혜택을 위해 스스로 선택
  • 하드 제약: 재료적·기술적·재정적 제약
  • 소프트 제약: 관습(conventions)

4.2 내재적 제약 (Intrinsic Constraints)

• 문제 자체의 속성에서 발생하는 제약 → 피할 수 없고 우연적(incidental)
• 화가에게 캔버스·물감이 제약이듯, 프로그래머에게 코드 자체가 내재적 제약

4.2.1 하드웨어 내재적 제약

• DOOM 팀: NeXT 컴퓨터 도입으로 당시 IBM PC의 내재적 제약을 거부
• Monkey Island(LucasArts):
  • EGA(Enhanced Graphics Adapter): 고정된 16색 팔레트, 64KB 메모리
  • Mark Ferrari: 디더링(dithering) 기법 발명 → 체커보드 패턴으로 더 넓은 색 범위 착시 구현
  • CRT 모니터의 픽셀 블렌딩으로 효과 증폭
  • 디더링 그래픽 압축 → 더 큰 장면·캐릭터 아트 가능
  • Mark: “모든 극단적인 제한이 극도로 창의적인 환경을 만들었다”

4.2.2 소프트웨어 내재적 제약

• 소프트웨어 개발 생태계에 내재된 제약: 키보드 입력, 컴파일, 실행 등
• 프로그래밍 언어 선택 → 자기부과 제약(본인이 선택) 또는 부과 제약(타인이 결정)
• 예: 임베디드 OS의 네이티브 스레드 미지원 → 코루틴 형태의 그린 스레드(Go, Lua, PHP)로 창의적 해결

4.3 부과된 제약 (Imposed Constraints)

• 이해관계자(클라이언트, 매니저 등)로부터 부과되는 제약
• 예: 예산, 시간, 효율성, 특정 기술 스택 강제
• 내재적 제약과 차이: 부과 제약은 심리적 저항감 유발 → 팀 사기에 영향
• 실제 사례들:
  • Oracle SQL 저장 프로시저에 묶인 프로젝트 → SQL Developer로 PL/SQL 유닛 테스트 발견
  • VB6 레거시 시스템 → SimplyVBUnit으로 단위 테스트 도입
  • Hibernate ORM의 복잡성 → 첫 레이어를 DB에 직접 직렬화 → 놀랍도록 잘 동작
• 핵심: 부과 제약을 부정적으로 보지 말고 “제약은 억제가 아니다(A constraint isn’t necessarily a restraint!)”

4.4 자기부과 제약 (Self-Imposed Constraints)

• Michael Mose Biskjaer(창의 프로세스 제약 연구자): 자기부과 제약은 본질적(essential) → 창의적 혜택을 위해 자발적으로 선택
• 1920년대 이후 아방가르드 운동들이 장애물·“트립와이어”·명령·무작위 자극 등을 스스로 설정 → 창의 프로세스 점화
• Igor Stravinsky: “인간 활동은 스스로 한계를 부과해야 한다. 예술은 통제될수록, 제한될수록, 다듬어질수록 더 자유롭다”
• Biskjaer의 자기결속 두 카테고리:
  1. 생산성 향상: 집중 루틴, 방해 앱 차단(예: macOS Serene 앱)
  2. 창의 프로세스 변환: 새로운 창의적 기회 열기 → 더 독창적 결과물
• Jan Schoonhoven(네덜란드 Zero-movement): 페인트와 감정을 배제하고 판지·기하학적 반복만 사용 → 작품이 소더비에서 £780,450에 낙찰, 우편배달부였음

4.4.1 열정적인 픽셀 아티스트

• Thimbleweed Park(2017): Mark Ferrari, Ron Gilbert, Gary Winnick 공동 제작
  • Monkey Island 이후 27년 만에 1987년 게임처럼 보이도록 의도적으로 디자인
  • 포토샵으로 해상도 감소·안티앨리어싱 꺼서 “8-bitish” 구현 → 자기부과 제약
  • Kickstarter에서 $626,250 모금(목표의 거의 2배), 15,623 후원자
• Mark Ferrari: “픽셀 아트는 하드웨어에서 비롯된 조잡한 기술에서 게임을 초월한 예술 운동으로 진화했다”
• 레트로 게임 부활: Ion Fury(Duke Nukem 3D Build 엔진), DUSK(Quake 스타일), Project Warlock
• Brian Provinciano(Vblank Entertainment): PS4 게임을 40년 된 MS-DOS로 포팅 → 1.44MB 플로피 디스크에 압축

4.4.2 제한이 창의적 해결책으로 이끌게 하라

• Basecamp: 대부분의 주요 제품 작업에 6주 예산이라는 불가능해 보이는 자기부과 예산 설정
• “덜 만들기, 기능 줄이기, 설정 줄이기” → 고수익 회사로 성장
• 전략 이름: “예산 위에서 소프트웨어 출시(shipping on a budget)” vs 마감 위에서
• DHH(Basecamp 공동창업자): “제약은 가끔 아프다 — 그때가 바로 작동하는 걸 아는 순간이다”

4.4.3 게임보이와 제약

• 닌텐도 게임보이(1989): Gunpei Yokoi의 철학 → “낡은 기술로 횡적 사고(Lateral Thinking With Withered Technology)”
  • 최신 기술보다 재미와 게임플레이 우선 → 배터리 최대 30시간 지속
• SEGA 게임기어: 더 강력하다고 광고했지만 서두른 Master System 하드웨어 재활용 → 6개 AA배터리로 5시간도 안 됨
• 게임보이 게임들의 창의적 트릭들(Wario Land):
  • 스프라이트 최대 수 우회 → 배경의 일부로 코인 처리
  • 멀티스프라이트 보스로 스프라이트 크기 제한 우회
  • 팔레트 스와핑으로 적 변형·피격 표현
  • GB 렌더 루프 타이밍 활용 → 시각적 워프 효과

4.4.4 제한된 (판타지) 콘솔

• PICO-8(Lexaloffle Games, 2015): 브라우저에서 실행되는 Lua VM, 1980s 판타지 콘솔
  • 스펙: 128×128 픽셀, 16색, 32KB 카트리지, 최대 256개의 8×8 스프라이트
  • 철학: “PICO-8의 가혹한 제한은 창의적인 환경을 위해 신중하게 선택됨”
  • Celeste(2018): 게임잼에서 단 4일 만에 PICO-8으로 제작
• ZX Spectrum Next(2017): 1982 ZX Spectrum 호환 8비트 컴퓨터, FPGA 기술로 최대 28MHz
  • 목표: “새 세대의 창의적 침실 코더를 장려”
  • 카세트 테이프로 게임 출시 가능

4.4.5 제한된 프로그래밍 언어

• Go 언어: Rob Pike 설계 → 언어 사양이 프로그래머 머리 속에 다 들어올 만큼 작게
  • map(), filter(), reduce() 없음 → for {} 루프만 존재
  • while {}, do {} 없음
  • 예외(exceptions) 없음 → 함수 레벨 명시적 에러 처리 강제
  • Stack Overflow 2020: Go = 5번째 사랑받는 언어
  • Go의 자기부과 제약으로 탄생한 창의적 프로젝트: PhotoPrism, Navidrome, Gitea, Drone, Hugo, Listmonk 등

4.4.6 크랙 인트로와 데모씬

• 크랙 인트로 → 인터랙티브 예술 경험으로 진화(불법적 부분은 사라짐)
• 데모씬(demoscene): 코딩 대회에서 인트로 바이너리를 64KB(또는 4KB)로 제한
  • 2020년 핀란드 유네스코 무형문화유산 등재, 2021년 독일도 등재 → 최초의 디지털 서브컬처 문화유산 등재

4.5 스위트 스팟 찾기

• Michael Mose Biskjaer의 제약 스위트 스팟: 과소 제약과 과잉 제약 사이의 역 U자 곡선
  • Csikszentmihalyi의 플로우(flow) 개념과 유사
  • Y축: 영감 수준(너무 낮음 → 아이디어 없음; 너무 높음 → 혼돈)
  • X축: 제약 수준
  • 스위트 스팟 도달법: 자기부과 제약으로 x 증가; 제약 제거/무시로 x 감소

4.5.1 적절한 제약으로 추상화 능력 향상

• Cruz Izu(호주 컴퓨터과학자)의 추상화 분류(Egg Cartons 문제로 설명):
  • 레벨 0(브루트 포스): 모든 가능한 해를 테스트
  • 레벨 1(특수 케이스 처리): 문제 공간 조정 → N<6 또는 N=10이면 -1
  • 레벨 2(패턴 발견): 손으로 예시 풀어 패턴 발견
  • 레벨 3(수학적 추상화): 루프 없이 수학 모델로 표현 (n%8로 결정)
  • 유닛 테스트 선작성 = 자기부과 제약 → 패턴 자동 발견 유도

4.5.2 달콤함인가 쓴맛인가

• 제약 스위트 스팟이 항상 즐거운 건 아님 → 창의성은 고통스러울 수 있음
  • Van Gogh(조현병·양극성 장애), Virginia Woolf(자살), Strindberg(정신 질환)
• 공포 관리 이론(Terror Management Theory): 창의성이 실존적 불안 관리에 중요한 역할 → 죽음을 생각하면 창의성 증가; 창의성은 실존 불안에 대한 저항력 증가
• Memento mori(죽음을 기억하라): 꽃·해골·모래시계로 상징
• 경고: 창의적 집착은 정신 건강에 해로울 수 있음 → “일은 그냥 일”

4.6 실제에서 제약 다루기

4.6.1 발산적 사고 (Divergent Thinking)

• Paul Torrance의 TTCT(Torrance Test of Creative Thinking): 창의성 측정 도구
  • 한계: 발산적 사고만 측정 → 현대 창의성 정의의 작은 부분집합
  • 컴퓨팅 교육 연구자 대부분이 여전히 이에 집착 → 브레인스토밍 이상의 창의성 필요
• 발산적 사고 = (부과된) 제약 기반 사고 → 주어진 원에서 가능한 한 많은 독창적 그림 그리기
• Black Stories 카드게임(Holger Bösch): 제약 속에서 독창적 원인 추론 → 18개 이상의 회사에서 출판, 21가지 버전
• 많은 기술 인터뷰에서 발산적 사고 기법으로 창의성 평가

4.6.2 순진함과 제약

• 과잉 제약 → 탐구할 가치 있는 아이디어 거부 → 순진함(naivety)이 해법
• Caterina Moruzzi: 순진함 = 창의성의 핵심 특성 → 자발성, 무의식 처리, 도메인 규범 도전, 경직된 사고 구조로부터 독립

4.6.3 순진한 시인 (Hilde Domin)

• 독일 시인 Hilde Domin: 문학 권력 투쟁을 모른 채 6년간 순진하게 지속 → 독일어권 최고 시인 중 하나가 됨
• 교훈: 제약에도 나이브하게 지속하면 돌파구 가능

4.6.4 순진한 제임스 본드 (GoldenEye)

• GoldenEye(Rare, 1997): 팀 대부분이 개발 경험 전무 → 불가능한 것을 몰랐기에 시도
  • 신체 부위별 피격 반응, 저격 소총, 듀얼 웨폰, 반사 매핑, 4인 분할화면 멀티플레이 → 모두 FPS 장르 표준이 됨
  • 8백만 카피 판매, N64 Top3 게임
  • Martin Hollis: “우리가 뭘 못 하는지 아무도 몰랐다”
  • 멀티플레이: 발매 6개월 전 추가, 거의 포함 안 될 뻔 → 제약(낮은 폴리곤 맵)으로 부분 해결
  • GoldenEye 없었다면 Half-Life 같은 대작 FPS도 없었을 것

4.6.5 순진한 알고리즘 구현

• 전문가들의 함정: 실제로 거의 발생하지 않을 문제를 미리 걱정 → 과잉 엔지니어링
  • 캐싱 이중 레이어 추가, 불필요한 의존성 생성, 테스트 없는 로드 밸런싱
• 항상 순진한 접근(naive approach) 먼저 → 단순하고 읽기 쉬운 코드
• 피보나치 예시:
  • 순진한 재귀 → 단순하지만 큰 수에서 성능 폭발
  • 메모이제이션/꼬리 재귀로 최적화 → 더 복잡하지만 성능 개선
  • 교훈: 항상 순진한 접근으로 시작 → 그 후 개선 고려

4장 요약

• 제약 분류: 내재적·부과 제약(우연적), 자기부과 제약(본질적)
• 하드웨어 내재적 제약 → 창의적 이점으로 활용 가능
• 레거시 코드에서도 현대적 모범 사례 적용 가능
• 확인된 제약은 절대 숨기지 말 것 → 팀·소프트웨어·클라이언트에 영향
• 아이디어를 “불가능하다”고 너무 빨리 묵살 금지
• 제약 스위트 스팟 존재 → 과잉 자기부과 제약 주의
• 내면의 아이의 순진한 흥분 → 어려운 제약 돌파에 도움
• 발산적 사고 활용 가능하나 창의성 테스트로만 취급 금지

5챕터: 비판적 사고 (Critical Thinking)

5.0 도입부

• 소크라테스(끝없는 질문, “모르는 것을 알라”) vs 소피스트(모른다고 인정하지 않음)
• 루이 파스퇴르: 미생물 발효 증명 → 19세기 편협한 사고 타파 (그러나 사생활 노트 공개로 표절·속임수 밝혀짐)
• Grove Street Games의 GTA 트릴로지 리마스터: AI 업스케일러 100,000개 에셋 미검토 → 출시 즉시 혹평
• 공통점: 비판적 사고의 정도 차이(또는 완전한 결여)

5.1 창의적 비판 사고

• 창의적 사고만으로는 부족 → 창의적 사고 + 비판적 사고 모두 필요
• 창의적 사고의 역할: 독창적 아이디어 생성, 아이디어 검증/거부, 적시 조정, 피드백 해석, 인지 편향 극복

5.2 창의적 프로세스

• Graham Wallas(1921)가 처음 정의한 5단계:
  1. 참여(Participate): 90% 땀과 준비, 10% 통찰 → 즉각적 영감 없음
  2. 잠복(Incubate): 거리 두기로 무의식이 가속 → 산책, 달리기, 휴식
  3. 조명(Illuminate): 1단계 없이는 발생 불가 → 포스트잇 항상 지참
  4. 검증(Verify): 효과 있는지? 가치 있는지? 없으면 버리고 재시작
  5. 발표/수용(Present/Accept): 동료들에게 발표·수용되어야 진정한 창의적 결과물
• 순차적 프로세스가 아닌 재귀적 프로세스 → 1~4단계 사이를 오갈 수 있음
• TDD 사이클과 유사: 빨강(1-3단계) → 초록(4단계) → 리팩토링(1-3단계)

5.2.1 비판적으로 검증하기

• Csikszentmihalyi: 통찰 후에는 연결이 맞는지 비판적으로 확인해야 함
• 프로그래머 버전: 유닛 테스트 실행, 브레이크포인트로 메모리 검사, 코드 단계별 실행
• “Don’t ASS-ume! 넌 U와 ME를 ASS로 만들 것이다” → 가정하지 말고 항상 확인
• Camerata(동료 그룹)의 비판적 피드백: 인지 편향 극복에 도움

5.2.2 집중 사고 (Focused Thinking)

• 집중 사고 = 분석적 문제 해결 → 점진적·의식적 프로세스
• 코드 라인, 메서드, 인수, 예외 등 세부 사항에 집중
• 장점: 저수준 문제 해결에 탁월
• 단점: 지름길 유혹, 전체 맥락 상실, 잘못된 결정 가능

5.2.3 확산 사고 (Diffuse Thinking)

• Barbara Oakley(공학 교수): 아이디어 발상 단계 = 확산 모드 사고
  • Coursera “Learning How to Learn” 강좌에서 소개
  • 핀볼 기계 비유: 집중 = 밀접한 범퍼 사이 핀볼; 확산 = 모든 방향으로 튀는 핀볼
• 큰 그림을 보며 문제에서 일시적으로 거리 두기
• Jonathan Schooler의 마음 방황(mind-wandering): 외부 환경에서 주의가 분리되는 일상적 경험
  • 창의적 성능 향상을 측정했지만 → 과도한 마음 방황은 부정적 기분과 상관관계
• Daniel Kahneman의 두 사고 모드와 연결:
  • System 1: 빠르고 본능적·감정적 → 잘못된 판단 유발
  • System 2: 느리고 신중·논리적

5.2.4 확산 사고와 집중 사고 결합

• Schooler: 마음챙김(집중 증가)과 마음 방황(확산 촉진) 사이의 아리스토텔레스적 중도
• Linus Pauling: “좋은 아이디어는 많이 내고 나쁜 것을 버리면 된다” → 확산(많은 아이디어) + 집중/비판(나쁜 것 제거)
• Jonas Salk: 확산·집중 사고를 영리하게 결합 → 소아마비 백신 개발, 특허 포기로 전 세계 저렴한 치료 제공
• Robert Sternberg의 창의성 정의: “창의성 = 아이디어 세계에서 저가 매수·고가 매도 결정”
  • 너무 많은 확산 → 실현 안 되는 이상한 아이디어
  • 너무 많은 집중 → 터널 비전·투기적 일반화
• 정신 진동(mental oscillation): 집중과 확산 모드 사이를 자주 전환 → 집중 모드 과잉 = 인지 터널링

5.3 창의성은 목표가 아닌 수단

• 창의성이 항상 긍정적인 것은 아님 → 극도로 “창의적”이지만 완전히 쓸모없는 솔루션 가능
• 인터뷰이 명언: “창의성은 수단이지 목표가 아니다(Creativity is the means, not the goal)”
• 창의성을 위한 창의성의 위험: 미학에 눈이 멀어 투기적 일반화(speculative generality) 도입
• 소프트웨어 장인정신(Software Craftsmanship) 매니페스토의 문제: 기능보다 미학에 불균형적 강조
• 단, 창의적 코딩(creative coding)에서는 창의성이 목표: Processing/p5.js로 자기 표현
  • “창의적 프로그래머 ≠ 창의적 코더, 그러나 창의적 코더는 창의적 프로그래머 가능”

5.4 일반적인 비판 사고 오류들

• Descartes도 송과선이 신의 의지로 동물 영혼을 전달한다는 이상한 아이디어 보유 → 위대한 사상가도 사고 오류 가능
• Steven Pinker의 인지 편향 → Kahneman의 System 1 오용에서 대부분 발생

5.4.1 언어 간 충돌

• Nischal Shrestha의 연구: 언어 학습 시 전이(transfer) 발생
  • 촉진(facilitation): Java 지식이 Kotlin 학습에 도움
  • 간섭(interference): Java 개발자가 JavaScript의 프로토타입 상속·비동기 함수형 프로그래밍에 어려움
  • 자연어도 동일: 스페인어 “embarazada”(임신) ≠ 영어 “embarrassed”(창피함)

5.4.2 가용성 편향 (Availability Bias)

• 쉽게 떠오르는 것 → 더 맞는 것으로 착각
• 닌텐도 3DS + 케이스 = €110, 3DS가 €100 더 비쌈 → 대다수가 케이스 €10이라고 틀리게 답함 (정답: €5)
• Kahneman의 System 1 오남용

5.4.3 무지와 의도적 발견 (Deliberate Discovery)

• Dan North(2010): 의도적 발견(Deliberate Discovery) 개념 제시
  • 프로그래머는 끊임없이 가정을 만들고 대부분 틀림
  • 확증 편향(confirmation bias): 기존 믿음과 가치를 지지하는 방향으로 상황 해석
  • 예상치 못한 일(NullPointerException 등) → 진짜 학습 발생
  • “우발적 발견” → “의도적 발견”으로 전환 필요
• Socratic “thoroughly conscious ignorance”(Maxwell): 진정한 과학 발전의 전주곡
• 무지의 다차원성: 기술적 무지, 다른 기술 무지, 동료 지식 무지, 클라이언트 소망 무지 등

5.4.4 자기 귀인 편향 (Self-Serving Bias)

• 성공 → “내가 해냈다!” / 실패 → “내가 안 했다!”
• 창의성은 시스템적 → 자신만큼 시스템도 자신에게 영향을 줬음
• Christopher Avery의 공유 책임 모델로 극복 가능

5.4.5 최신 기술 편향

• CV와 기술 스택에 최신 프레임워크 추가에 집착 → 거대한 리팩토링 시도
• “React, Redux, GraphQL을 끼워 넣었다!” → 최종 사용자는 코드 미학에 관심 없음

5.4.6 앵커링 편향 (Anchoring Bias)

• 처음 접한 정보(닻)에 지나치게 의존 → 이후 판단이 초기 정보에 편향
• 해결책: 여러 정보 출처로 교차 검증 → 검증, 검증, 검증

5.4.7 프로그래밍 초보자의 오해 목록

• Teemu Sirkiä와 Juha Sorva의 연구: 100개 이상의 일반적 프로그래밍 오해 식별
  • “문자열 변수 연결 시 int로 자동 변환될 것이다”
  • “이 루프의 박싱 효과가 성능 문제 원인이다 — 측정 없이 알 수 있다”
  • “while 루프는 조건이 false가 되면 즉시 멈춘다”
• 일부 오해는 깊이 뿌리박혀 있어 증명 후에도 의심 지속 → “학습 해제(unlearning)“가 학습만큼 시간 소요
• JDK API 메서드 암기보다 가정을 심문하는 법 가르치는 것이 중요

5.4.8 편견을 통찰로 전환

• “우리 기술에서는 이게 불가능하다” → 먼저 이해하기, 이전에 시도됐는지 확인
• 틀림을 증명하는 것 = 오만으로 비침 → 오해를 먼저 해소
• 뇌의 투쟁-도주 반응(fight-or-flight) → 빠르지만 틀린 판단 생성
• 최선: 상대방 입장이 되어보기, 페어 프로그래밍

5.5 과도한 자기 비판

• Julia Cameron의 베스트셀러 『The Artist’s Way』: 내면의 창의 비평가 극복법
• 내면의 “Nigel”(스턴한 영국인 인테리어 디자이너): 작업 즉시 “나쁘다, 유치하다, 조잡하다” 비난
• Darya Zabelina와 Michael Robinson의 연구: 자기비판적 개인 = 낮은 창의적 독창성
• Cameron의 창의적 회복 도구:
  1. 아침 페이지(Morning Pages): 매일 아침 기상 직후 의식의 흐름 글쓰기 (최소 15분)
     • Nigel이 비판하기 전 내면의 흐름을 끌어냄
  2. 예술가와의 날(Artist’s Date): 몇 시간 동안 영감을 얻는 자기만의 여행
• “창의적 자원은 고갈되는 만큼 의식적으로 채워야 한다”

5.6 타인의 비판적 사고가 중요한 이유

• Caterina Moruzzi: 창의성 개발자 본인뿐 아니라 주변 사람들의 이해도 중요
• 창의성 = 사회문화적 판결 → 누군가가 창의적이라고 인정해야 창의적으로 인정받음
• 타인의 비판적 평가·검증 = 내 작업의 수용에 필수적
• 핵심 메시지: 비판적 사고를 자신의 작업으로 제한 말고 타인의 창의적 작업에도 피드백 제공
• 피드백 줄 때: 어떻게 받아들여질지 먼저 고려; 받을 때: 열린 마음 유지

5장 요약

• 창의 프로세스의 5단계: 참여 → 잠복 → 조명 → 검증 → 발표/수용 (비선형·재귀적)
• 비판적 사고(검증)는 창의 프로그래머의 필수 요소
• 단계에 따라 다른 사고 모드 필요: 확산 + 집중, 아이디어 없을 때 모드 전환
• 소프트웨어 문제 해결에서 창의성은 보통 목표가 아닌 수단
• 단, 자기표현·탐구·플레이에서는 창의성이 목표 가능
• 많은 비판적 사고 오류 인식 → 극복 도움
• 자신과 타인의 창의적 작업 모두에 비판적 사고 적용
• Socrates처럼 “모르는 것을 알라”

6챕터: 호기심 (Curiosity)

6.0 도입부

• Herodotus(최초의 역사가): 지중해를 두려움 없이 여행하며 세계 역사 기록
  • 단순히 그리스 시각이 아닌 페르시아 제국 시각도 포함
  • Cicero: “역사의 아버지(Father of History)”
• Csikszentmihalyi: 호기심과 끈기 = 창의적 성공을 위한 가장 중요한 두 가지 성격 특성
• 호기심 없이는 배우거나 무언가를 만들 동기 없음; 끈기 없이는 작업을 효과적으로 완성할 기회 없음

6.1 (챕터 개요)

이 챕터의 주요 다룸 내용:

• 고정 마인드셋과 성장 마인드셋이 창의성에 미치는 영향
• 호기심을 유지하기 위한 다양한 동기 유형
• 다중 잠재성(multipotentiality) 개념
• 제너럴리즘 vs 스페셜리즘 토론

6.2 경이감과 방랑벽 키우기

• Darwin의 사례: 포괄적 호기심 = 가장 좋은 종류의 호기심
• 호기심 → 동기의 1차 원동력
• 창의 프로그래머 시작법: 먼저 관심사 키우기 → 그래야 5장의 참여(Participate) 단계에서 흥미로운 경험·정보 생성

6.2.1 고정 마인드셋과 성장 마인드셋

• Carol Dweck(심리학자·사회학자)의 수십 년 연구:
  • 고정 마인드셋: “재능과 능력은 고정됨” → 창의적이거나 아니거나
    • 타인을 질투하거나 오만·경멸 → 좌우명: “똑똑한 사람이 성공한다”
  • 성장 마인드셋: “재능과 능력은 노력으로 계발 가능” → 아직 창의적이지 않을 뿐
    • 좌우명: “사람은 더 똑똑해질 수 있다”
• 실제로 흑백이 아닌 그 사이 수많은 회색 존재
• 컴퓨팅 학생들 연구: 컴퓨팅에는 성장 지향적이지만 창의성 마인드셋은 가장 고정적 → 우려스러운 결과
• 성장 마인드셋 개입 효과: 단일 학기로는 평균 마인드셋 유의미한 변화 어려움 → 지속적 재투자 필요

6.2.2 믿는 것이 행동이다

• Dweck: 성장 마인드셋 = “새로운 모험의 여권” → “창의성으로의 자유 통행증”
• “20년 연구에서 자신에 대한 관점이 삶의 방식을 심오하게 영향 미침”
• Leonardo da Vinci: “장애물은 나를 짓누를 수 없다. 모든 장애물은 굳건한 결의에 굴복한다”
• 어려운 일 극복에서 탁월함과 평범함의 차이 = 자신을 믿는 능력

6.2.3 컴포트 존에서 벗어나기

• 저자 연구: 창의적인 소프트웨어 공학 학생들 = 비창의적 학생보다 더 자주 컴포트 존 탈출
  • Amabile의 합의 평가 기법(CAT)으로 창의성 평가
  • 더 창의적 프로젝트 = 정적 코드 분석 도구가 더 많은 코드 품질 문제 발견 → 탐험적 코딩의 부산물
• 디자인 학생과 공학 학생 협업 연구: “파트너가 더 많이 탐색하게 만들었다”
  • 공학 학생이 디자인 학생과 페어링 → 통제 그룹보다 자기 보고 창의성 높음
• 컴포트 존 탈출 예시: 다른 개발 팀으로 이동, 발표 도전, 새 기술 탐구

6.3 호기심 지속하기

• Darwin: 5년간의 비글호 여행에서 방대한 정보 수집 → 23년 후 『종의 기원』 완성 → 끈기 필수
• 끈기 없이는 수집한 노트 연결·재작업·검토가 불가능

6.3.1 끈기와 그릿 (Grit)

• Angela Duckworth: 그릿(grit) = 열정 + 끈기의 특별한 조합 = 성공의 비밀
  • 성장 마인드셋과 동일하게 과학적 증거로 뒷받침 가능
  • 그릿 ↑ = 학업 성취 ↑, 프로그래밍 성적 ↑ (Wolf & Jia 연구)
  • 그릿과 성장 마인드셋은 호기심·끈기의 명확한 징후
• Einstein: “내가 더 영리한 게 아니라 문제와 더 오래 있을 뿐이다”
• Bill Gates의 사례: 허가된 컴퓨터 시간 다 쓴 후 시스템 글리치 악용, 권한 박탈 후에도 해킹 지속
  • Traf-O-Data(실패)에도 포기 안 하고 결국 Harvard 중퇴 후 Microsoft 창업
  • MS 채용 시 가장 끈기 있는 후보 선발

6.3.2 의지력은 고갈되는 자원

• Roy F. Baumeister(사회심리학자): 의지력 = 유한한 자원
  • 매일의 작은 결정들이 의지력 소진 → 하루 끝엔 의지력 부족으로 과식 등 행동
  • 자아 고갈(ego depletion): 성능 통제 상실, 충동 통제 상실
• Freud, Kant: 엄격한 일일 스케줄 → Einstein·da Vinci: 매일 같은 옷 착용 → 결정 수 줄이기
• 의지력 = 근육처럼 훈련으로 강화 가능

6.4 동기 (Motivation)

• 내재적 동기와 외재적 동기의 관계:
  • 초보자에게는 외재적 동기(경쟁·돈) → 창의성 방해 / 경험자에게는 → 촉진
  • 시간이 지남에 따라 내재적 열정 프로젝트도 외재적 동기 부스트 필요
• 직문: “급여 없이도 여전히 열정적으로 코딩 문제를 풀겠는가?”
• 현직에서 내재적 동기 찾기 → 단조로운 작업 대처에 도움

6.5 다중 잠재성 (Multipotentiality)

• 진정으로 창의적인 사람 → 단일 분야로 호기심 제한하지 않음
• Sigmund Freud: 정신분석의 아버지 + 아마추어 고고학자 → 고고학이 “마음 발굴” 아이디어 제공
• Nora Bateson(시스템 사상가): 단일 분야 호기심 제한 = 정신적 단일경작(mental monocropping) → 인지 건강에 독성

6.5.1 여러 진정한 소명

• Leonardo da Vinci: 화가·해부학·생리학·공학·생물학·비행기 설계 등 → 폴리매스(polymath) 원형
• Emilie Wapnick: 다중 관심 가진 사람을 **“멀티포텐셜라이트(multipotentialite)”**로 명명
  • 현대 사회는 전문성을 높이 평가하며 다중 관심자를 소외시킴
• 멀티포의 강점:
  • 아이디어 합성: 창의성은 도메인 경계에서 발생
  • 빠른 학습: 제너럴리스트는 초보에 익숙하고 새것을 잘 배움
  • 적응력: 다양한 상황에 다양한 접근 방식 활용
  • 큰 그림 사고: 스페셜리스트가 터널 비전에 빠질 때 더 넓은 시각 유지
  • 관계 및 번역: 다양한 분야 친숙도로 전문 지식 연결·번역 쉬움
• Shunryu Suzuki: “초보자의 마음에는 많은 가능성이 있다. 전문가의 마음에는 거의 없다”
• David Epstein의 책 『Range: Why Generalists Triumph in a Specialized World』에서도 제너럴리즘 옹호
• 인증(certification)의 위험: 전문화 강요, 회사 이익 위주 → 개인의 커리어보다 CV 채우기

6.6 세렌디피티적 발견

• 세렌디피티(serendipity): 찾지 않은 것을 발견하는 것 → 공학적으로 (부분적으로) 가능
• Newton의 사과·Archimedes의 목욕 → 신화이지만 우연한 만남이 통찰에 기여하는 것은 사실
• Steven Johnson의 “액체 네트워크”: 즉흥적 대화(물 마시는 기회 등)가 회의실보다 더 사고 자극

6.6.1 우연히 만나는 방법

• Wikipedia의 “랜덤 기사” 링크, Obsidian의 “랜덤 노트 열기”
• DEVONthink의 See Also 패널 → 연결되지 않은 관련 문서 제안
• Discuvver(구 StumbleUpon 대안): 매주 무작위 유용한 사이트 발송
• 알고리즘 추천의 함정: Amazon, Reddit 등 → 이미 아는 것의 더 많은 것을 피드
• 다양성이 세렌디피티 촉진 → 다양한 출처로 구성된 정보 소비

6.6.2 경험에 대한 개방성

• Big Five 성격 특성 중 경험에 대한 개방성(openness to experience) → 창의성과 작지만 양의 상관관계
• 단, Big Five 모델: 이론적·방법론적 기반 취약 → 참고용
• 경험에 대한 개방성 부족 = 호기심과는 거리 멀음

6.7 재미에 대하여

• 인터뷰된 프로그래머들: 창의적인 소프트웨어 개발자는 재미를 통해 동기 부여됨
• 플로우(flow, Csikszentmihalyi) 상태와 연결 → 재미는 창의적 몰입의 핵심 요소
• “재미는 창의적 탐구의 자연스러운 부산물”

6장 요약

• 고정 마인드셋과 성장 마인드셋은 창의성에 영향 → 성장 마인드셋 개발 가능
• 창의성도 기술처럼 학습 가능하다는 것을 믿으면 창의성 발현
• 비판적 피드백을 가치 있는 선물로 받아들이기 → 성장 마인드셋의 핵심 특성
• 그릿과 끈기: 창의성에 필수적이며 적극적으로 키울 수 있음
• 컴포트 존에서 벗어나기 → 새로운 경험과 도메인 탐구
• 자기표현으로서의 창의적 코딩과 문제 해결로서의 창의적 프로그래밍 간의 경계 인식
• 세렌디피티 공학: 다양한 정보원과 열린 탐구로 증진 가능
• 호기심과 끈기를 항상 쌍으로 → 창의적 성공의 핵심 비결

7챕터: 창의적 마인드 상태 (Creative State of Mind)

7.1 올바른 창의적 기분 만들기

• 아르키메데스(목욕), 앙리 푸앵카레(버스·산책), 올리버 쌍둥이(게임 개발) 사례는 공통적으로 의식적 사고와 이완을 교대하는 창의적 상태를 보여줌
• 창의성은 의도적인 준비 없이 저절로 생기지 않음 → “아하!” 순간도 이전의 의식적 노력이 전제됨
• 푸앵카레의 이론: 창조는 의식적 작업 → 무의식적 작업 → 다시 의식적 작업 순으로 이루어짐
• 인터뷰한 개발자들은 창의적 상태를 두 가지로 구분
  • 개인적 상태: 창의적 흐름(flow), 생산성 도구, 아하 순간, 샤워 중 떠오르는 생각
  • 집단적 상태: 자유와 유연성을 촉진하는 환경의 영향

7.2 딥 워크의 흐름 (The Flow of Deep Work)

7.2.1 최적 경험 (Flow)

• 심리학자 미하이 칙센트미하이가 정의한 “최적 경험(optimal experience)” = 몰입(Flow)
• 몰입의 9가지 원칙:
  1. 명확한 목표가 있음
  2. 모든 활동 후 즉각적인 피드백이 따라옴
  3. 도전과 기술 사이의 균형이 존재
  4. 행동과 인식이 하나가 됨
  5. 산만함이 의식에서 사라짐
  6. 실패를 두려워하지 않음
  7. 자의식이 거의 없음
  8. 시간 감각이 무너짐
  9. 활동 자체가 목적이 됨 (자기목적적, autotelic)
• 몰입 달성 3가지 조건: 현실적인 목표, 도전에 맞는 기술 수준, 활동에 대한 완전한 집중
• 기술이 너무 높으면 지루함 → 기술이 너무 낮으면 불안감
• 칙센트미하이 연구: 참가자의 54%가 일 중에 몰입 경험, 여가 시간엔 18%만 경험
• 몰입은 통제 가능하며 전문가나 영적 지도자만의 전유물이 아님
• 더 많은 몰입 = 더 많은 창의성
• 최근 연구: “즐거운 탐구(joyous exploration)“가 호기심과 창의성을 연결하는 몰입과 연관됨

7.2.2 딥 워크 (Deep Work)

• 컴퓨터과학 이론가 캘 뉴포트 정의:
  • 얕은 작업(Shallow Work): 인지적 요구가 낮은 물류적 작업
  • 깊은 작업(Deep Work): 인지적 한계를 밀어붙이는 가치 창출 작업
• 딥 워크 vs. 몰입 비교:
  • 딥 워크는 몰입 상태를 유발하기에 적합한 활동이지만, 자동으로 몰입을 보장하지는 않음
  • 몰입은 충만한 경험에 관한 것이고, 딥 워크는 오랜 집중을 가능하게 하는 부분
• 딥 워크가 점점 희귀해지면서 동시에 경제적으로 더욱 가치 있어지는 역설
• 딥 워크 시작 방법: 좋은 관행을 단순한 습관으로 만들기
  • 의지력은 유한한 자원 → 습관이 무의식으로 내려가면 에너지 절약
  • 매일 조금씩 딥 워크를 실천하고 점차 시간을 늘림
• 주의력 관리가 창의성을 포함한 삶의 모든 측면을 향상시키는 핵심 (Winifred Gallagher)

7.2.3 이동 중 딥 워크와 몰입

• 인터뷰한 개발자들: 어려운 문제를 자동차 안에서 해결, 출근 후엔 타이핑만 하면 됨
• “생각하는 부분이 창의적인 부분이고, 타이핑은 그것을 꺼내는 것”
• 창의적 마인드를 촉진하는 활동: 산책, 샤워, 수영
• 고대 그리스 철학자 소요학파(Peripatetics): 토론하고 생각하며 걷는 것을 즐겨 학파 이름으로 삼음
• 임마누엘 칸트: 쾨니히스베르크를 벗어나지 않으면서 규칙적 산책으로 유명 → “쾨니히스베르크 시계”라는 별명
• 니체: 하루 8~10시간 독일 흑림 산책, 걷기가 철학의 중심 → “가만히 앉아있는 것은 성령에 대한 죄”
• 실증 연구(Oppezzo & Schwartz): 산책이 창의적 아이디어 창출을 촉진, 산책 중 및 직후 모두 효과
• 창의적 작업의 최적 장소는 매우 주관적, 강요는 금물

7.2.4 산책에 대한 지원 부족

• 대부분 고용주는 책상 앞에 앉아 있는 모습만 “생산적”으로 간주
• 사고 산책(thought walks) 은 종종 의심의 눈초리를 받음
• 창의적 자유에 대한 기여 요소: 독립성, 자율성
  • 심리학자 조이 길퍼드: 독립성을 창의성의 특성으로 언급
  • 마크 런코: 독립성과 발산적 사고의 양의 상관관계 발견
• 복잡한 문제 대부분은 컴퓨터나 회의실이 아닌 체육관, 자동차, 산책 중에 해결됨

7.3 방해(Interrupt) 다루기

• 창의적 마인드는 CPU 인터럽트처럼 작동 → 외부/내부 아이디어에 의해 예기치 않게 중단됨
• 컨텍스트 전환 후 다시 궤도에 오르기까지 약 20분의 쿨다운 시간 필요
• 연구(379명 개발자): 중대한 방해 없이 작업을 완료할 때 가장 생산적이라고 느낌
• 창의적 작업에서의 컨텍스트 전환은 루틴 작업 전환보다 더 비용이 큼

7.3.1 방해 인식 높이기

• 방해 패턴 관리를 위한 3가지 기회 (Meyer 등 연구):
  • 도구를 통한 소급 분석: Pomodoro 앱, 시간 추적 소프트웨어, Fitbit 등
  • 컨텍스트 전환 줄이기: 사고 방식 변경이 필요한 전환 최소화
  • 목표 설정: 자기 모니터링과 결합한 목표 설정
• 포모도로 기법: 약 25분 작업 + 5~10분 휴식의 인터벌 반복, 4번 후 긴 휴식

7.3.2 방해 대비 준비

• 가장 단순하면서 가장 중요한 해결책: 기록(Write stuff down)
• Felienne Hermans의 조언(『The Programmer’s Brain』):
  • 방해 받기 전에 현재 정신 모델을 기록
  • 문법/공백 신경 쓰지 말고 머릿속을 화면이나 종이에 빠르게 덤프
  • 이것이 복귀 속도를 크게 높임
• 메모는 충분한 컨텍스트를 포함해야 나중에 해독 가능
• 소설 작가들의 조언: 깨끗한 상태로 하루를 마치지 말 것 → 다음 장의 몇 문장을 미리 써두면 다음 날 출발이 빠름

7.3.3 주의해야 할 방해 유형

• 외부 방해(Slack, WhatsApp 등)보다 자발적 작업 전환이 더 파괴적
• 연구: 이메일 하나를 열고 부분적으로 읽는 데만 평균 5번의 자기 방해 발생
• 자기 방해 1회당 약 1초의 추가 비용 소요
• 시간대(아침/오후)에 따라 방해의 영향이 다름 → 개인별 차이 존재
• 방해가 무조건 나쁜 건 아님: 같은 프로젝트 동료와의 아이디어 교환, 버그 트리아지는 생산적 전환
• DND(Do Not Disturb) 불빛 시스템: 실제 현장에서 관리직의 무시로 실패한 사례

7.3.4 마음챙김이 집중력 향상

• 조너선 스쿨러: 집중력은 의지력처럼 훈련 가능한 근육
• **마음챙김(Mindfulness)**이 주의력 향상에 효과적
• 89개 논문의 메타분석: 마음챙김과 창의성 사이의 통계적으로 유의미하지만 약한 상관관계
• 마음챙김 유형에 따라 효과 차이: 통찰(insight) vs. 발산적 사고 / 관찰 vs. 인식하며 행동
• 마음챙김은 창의적 성공을 보장하지 않지만 주의력 향상에 기여

7.4 창의적 통찰 유발하기

• 창의적 프로세스 5단계: 참여 → 배양 → 조명 → 검증 → 발표/수용
• 통찰은 갑자기 나오는 것이 아닌 점진적(progressive) 과정
• 잭 런던: “영감을 기다리지 말라, 곤봉을 들고 쫓아가라”

7.4.1 혼자 vs. 함께

• 점 수집(Collecting dots)은 타인과 함께 → 점 연결(Connecting dots)은 혼자
• 데이터 → 정보 → 지식 → 통찰 → 지혜의 진화 과정
• 지식 전달 시 충분한 숨 쉴 공간 필요 → 각자의 속도로 새 정보를 소화하도록
• 100% 페어 프로그래밍은 내향적인 사람에게 부담, 간헐적 페어 프로그래밍 권장
• 개인 시간(me-time)이 없으면 아하-에어레브니스(aha-erlebnis, 통찰의 순간)가 거의 발생하지 않음
• 모든 개발자가 90%의 땀보다 10%의 조명만을 강조하는 경향이 있음

7.4.2 수면과 통찰

• 수면 중 해마가 낮 동안의 인상을 연결하고 재생 → 창의성 촉진
• 신경과학자 매트 윌슨: “수면 중에 이미 배운 것들에 대해 의미를 만들고 새로운 연결을 구축”
• 행동과학자 Simone Ritter의 연구: 수면 중 향기 노출로 과제 재활성화 → 창의적 해결력 향상 (오렌지-바닐라 향이 효과적)
• 결론: 수면 중 이전에 연관되지 않았던 정보들이 연결될 수 있으며, 어느 정도 능동적으로 유발 가능

7.4.3 자극제에 대한 참고 사항

• 프로그래머들의 커피 사랑 → 커피의 이중 효과:
  • ① 커피 기계로 걷는 물리적 이동 자체가 연결 유발
  • ② 카페인이 집중적 주의(focused attention) 향상
• 그러나 커피 과다 섭취는 확산적 사고(diffuse thinking) 모드를 방해
• 사이코스티뮬런트가 수렴적 사고는 강화하지만 발산적 사고는 감소시킴
• 아이디어 발상 단계에서는 맑은 정신이 최선

7.5 기업의 창의적 마인드 상태

7.5.1 환경적 창의성

• 개방형 사무실 vs. 폐쇄형 사무실의 딜레마:
  • 개방형: 우발적 창의성 촉진 → 실제로는 소음이 방해
  • 폐쇄형: 딥 워크 촉진 → 고립감과 단절
• 최적 해결책: 긴 복도 + 폐쇄형 소그룹 공간의 조합 (Cal Newport 제안)
  • MIT 빌딩 20 사례: 서로 다른 부서가 공유하며 학제 간 토론과 단독 집중 모두 가능
  • Bell Labs 사례: 복도를 지나치기만 해도 아이디어가 전파됨
• 이상적인 공간 유형 (Katja Thoring 연구):
  • 개인 집중 공간
  • 협업 공간
  • 제작/실험 공간
  • 전시 공간
  • 발표/공유 공간
  • 이탈/휴식/이완 공간
  • 특이한/놀이 공간
  • 가상 공간
  • 배양·반성 공간
• 창의적 환경의 조건: 사회적·자극적·매력적·편안·건강·안전·놀라움·유연·접근 가능·장난기·넓음·아늑함 등

7.5.2 창의적 작업장 (워크숍)

• 아틀리에/워크숍의 물리적 환경이 창의적 결과물에 직접적 영향
• 개념 1+1=3 (symmathesy, Nora Bateson): 전체의 합이 부분의 합보다 큼
• 예술가 Joke Raes: 환경이 바뀌면 작업도 바뀜, 우연성과 즉흥성의 중요성
• 실리콘밸리 차고(garage) 신화: 실험하고 정체성을 형성하는 창의적 워크숍의 역할
• 개발자들도 자신만의 사적 워크숍/아틀리에를 만들 것을 권장

7.5.3 창의적 안전지대로서의 작업장

• 창의적 직장은 실험하고, 실수하고, 다시 시도할 수 있는 환경이어야 함
• 자유로운 근무 시간, 화이트보드, 아이디어페인트 등 물리적 요소도 중요
• 자유와 제약 사이의 균형이 창의성의 최적 조건

7장 핵심 요약

• 데스크 앞에서 직접 풀리지 않을 때, 자리를 벗어나 두뇌를 비울 것
• 무의식의 신호를 무시하지 말 것
• 팀 내에서 몰입의 흐름을 존중하는 방식을 합의할 것
• 작업을 딥 워크/얕은 작업으로 분류하고 공간 선택
• 메모 없이 산책하지 말 것
• 방해 패턴에 대한 인식이 창의적 주의력 향상에 기여
• 방해가 잦을 경우 현재 생각을 먼저 덤프 후 대응
• 잘 자는 프로그래머 = 창의적인 프로그래머

8챕터: 창의적 기법 (Creative Techniques)

8.1 창의적 도구상자 채우기

• 마르쿠스 아우렐리우스(조감적 시각으로 로마 재정 위기 해결), 나보코프(인덱스 카드), 애자일 회고(스프린트 레트로스펙티브)의 공통점 → 창의적 기법으로 장애물 극복 및 새 통찰 생성
• 창의적 기법은 기술적 지식과 마찬가지로 창의적 장애물 극복의 기본 요건
• 코딩은 예술(무에서 유를 창조)과 글쓰기(구조화된 방식으로 의미 전달) 양쪽과 유사
• 프로그래머는 자신이 생각하는 것보다 더 많은 창의적 기법을 이미 알고 있음

8.2 예술가의 도구상자

8.2.1 예술 기반 학습 (Art-Based Learning)

• 문화사 연구자 Jeroen Lutters가 도입한 4단계 프로세스:
  1. 관련 질문을 자신에게 던지고 작품을 선택
  2. 예술이 말하게 놔두기 → 주의 깊게 관찰, 영감에 열린 자세
  3. 현재 세계에서 분리되어 모든 가능성을 바라봄
  4. 이해와 의미를 개인 이야기로 변환 → 새로운 지식과 잠정적 답변 생성
• 앙리 푸앵카레의 무의식 이론과 유사: 질문 → 무의식이 작동 → 해결
• 자유 연상적 사고가 핵심

8.2.2 예술가처럼 훔치기 (Steal Like an Artist)

• 오스틴 클레온의 10가지 조언 (프로그래밍에도 적용):
  1. 예술가처럼 훔쳐라
  2. 자신이 누구인지 알기 전에 시작하라
  3. 읽고 싶은 책을 써라
  4. 손을 사용하라
  5. 사이드 프로젝트와 취미는 중요하다
  6. 좋은 작업을 하고 공유하라
  7. 지리는 더 이상 우리의 주인이 아니다
  8. 친절하게 대하라
  9. 지루해져라 (끈기와 몰입)
  10. 창의성은 빼기다 (제약)
• 좋은 훔치기: 존중, 연구, 다수에게서 훔치기, 크레딧, 변환, 리믹스
• 나쁜 훔치기: 격하, 훑기, 하나에서만 훔치기, 표절, 모방, 베끼기
• GitHub Copilot 사례: 오픈소스 코드를 라이선스 무시하고 학습 → 나쁜 훔치기의 예
• 프로젝트 의존성을 정기적으로 스캔하고 올바르게 크레딧 부여 권장 (Node.js: license-checker 등)

8.2.3 휴식의 힘 (Time Off)

• 그래픽 디자이너 Stefan Stagmeister: 7년마다 1년간 안식년 → 새로운 영감 흡수
• 세 가지 구분:
  • 직업(Job): 돈을 위한 9-5 일
  • 커리어(Career): 사다리 오르기
  • 소명(Calling): 내적으로 충족되는 것
• 7년 중 1년 = 12.5% → Google의 20% 타임이나 3M의 15% 룰보다 적음
• 창의적 에너지 재충전과 새 아이디어를 위해 정기적으로 의도적 휴식 필요

8.3 작가의 도구상자

8.3.1 블라디미르 나보코프의 도구상자

• 다른 예술가를 연구하라: 경쟁자의 작품 연구, 현존하는 세계의 재창조 능력 필요
• 세계에서 영감 받기: 일상의 것들을 소프트웨어 개념으로 연결 (예: 우편 시스템 → RabbitMQ, Kafka)
• 단순하지만 정교한 코드 쓰기: “세상을 기만하는 단순성” → 의도를 명확히 전달하는 코드
• 스타일과 구조가 구현 아이디어보다 중요 → Go 언어 프로그래머들에게 특히 공감됨
• 디테일에 집중하라: 나보코프는 한 단어도 편집 없이 두지 않음 → Red-Green-Refactor 반복
• 처음부터 시작하지 않아도 됨: 인덱스 카드처럼 코드를 분리해 원하는 부분부터 구현
• Kill your darlings: 가차 없이 나쁜 코드를 삭제하고 다시 작성

8.3.2 제프 다이어의 도구상자

• 공개 장소에서 코딩하지 말 것: 집중력 방해
• 자동완성 및 IDE 단축키 마스터하기: 생산성 도구로 창의적 사고를 위한 공간 확보
• 일기 또는 노트 유지: 상세한 컨텍스트와 함께 기록
• 막히면 다른 일 하기: 무의식적 처리의 추가 이점
• 매일 습관 만들기: 글쓰기/코딩은 인내에 관한 것 → 점차 본능이 됨
• 스티븐 킹: 매일 10,000단어 작성

8.3.3 앤 라못의 도구상자

• 자신만의 고유한 이야기 쓰기: 이전 프로그래밍 언어 경험을 현재 문제에 독창적으로 적용
• 그냥 앉아서 시작하기: 매일 같은 시간에 앉아 무의식을 창의적으로 훈련
• 가짜로 하지 말 것: 코드를 읽을 미래의 동료도 독자 → 그들을 불필요한 군더더기로 속이지 말 것
• 주변에 도움 요청: 비전문가의 시각이 전문가가 놓친 단순한 해결책을 발견할 수 있음
• 단계별로(bird by bird) 작성: 목적지보다 여정에 열려 있기
• 완벽주의 버리기: 완벽주의는 “억압자의 목소리” → 형편없는 첫 초안(shitty first draft)을 허용

8.4 프로그래머의 도구상자

8.4.1 안나 보브코프스카의 7가지 기법

1. 순진한 질문하기: 숨겨진 가정과 암묵적 지식 발견
2. “만약에(What if…)” 질문: 숨겨진 결과의 연쇄 탐구
3. “나는 더 창의적일 수 있을 것이다, 만약…” 문장 완성: 개인적 장애물 이해
4. Lunette 기법: 다양한 추상화 수준에서 문제 바라보기 (코드 줌인/줌아웃)
5. 역 브레인스토밍(Reverse Brainstorming): 먼저 비판하고 그 다음 개선점 도출
6. 중국 사전 기법: 비정형적 분류 방식으로 프로젝트 관련 사항의 비전형적 분류 생성
7. “그들을 초대하자” 기법: 창의성 패턴 상상 (“만약 리누스 토발즈를 초대한다면?”)

8.4.2 추가 기법들

• 상상력 발산: 알 수 없는 제약과 가정을 발견하기 위해 자유롭게 상상
• 양파 껍질 벗기기(Why를 반복): 반복적인 “왜?” 질문 → 대화 혹은 독백
• 소리 내어 생각하기(자기 주도적 발화): 시각적 처리 능력 향상에 효과적
• 러버 덕 디버깅: 문제를 다른 존재(동료, 예술 작품, 고양이, 러버 덕)에게 설명하면 해결책이 나타남
• Triple Nickels: 소그룹이 개별적으로 아이디어 작성 → 5분마다 오른쪽으로 전달 → 이전 아이디어에 추가 빌드업
• 코드 카타(Code Kata): 반복적인 코드 재작성으로 근육 기억 형성
  • 프로덕션 코드베이스에서도 가능한 빠른 해결책 아이디어 발상 도구
• 애자일 레트로스펙티브 기법들 (외부에서도 활용 가능):
  • 체크인(Check-In), Mad-Sad-Glad, 5 Whys, 온도 계측 등
• 비전문가와 논의하기: 부모, 자녀, 비개발자 친구, 고객의 비기술적 시각에서 단순한 해결책 발견

8장 핵심 요약

• 프로그래머는 자신이 알고 있는 것보다 많은 창의적 기법을 이미 알고 있음
• 스타일과 구조는 내용만큼 중요함
• 막히면 다른 일을 하고, 이후 새로고침된 정신으로 돌아오기
• 코드 편집기를 깊이 습득할 것 → 가장 중요한 창의적 도구 중 하나
• 개인 프로그래밍 역사를 활용할 것 (이전 언어 경험 → 새 언어 빠른 습득)
• 완벽주의와 도그마적 자아를 경계할 것

9챕터: 창의성에 대한 최종 생각 (Final Thoughts on Creativity)

9.1 모두가 창의적일 수 있다

• 찰스 다윈: 심각한 불안 장애를 겪으면서도 진화론이라는 거대한 기여를 남김 → 창의성은 완벽한 조건을 요구하지 않음
• 강화 학습 루프: 더 창의적인 프로그래머가 될수록 더 창의적으로 되는 법을 배움
• 창의성 모범 사례의 위험성: 단순히 처방된 행동(예: 마음챙김)만 따른다고 창의성이 생기지 않음 → 시스템 사고, 부분 사고 금지
• 나보코프 수많은 인터뷰에서: “누구든 할 수 있었다, 단지 내가 그 시간 그 자리에 있었을 뿐”
• 아인슈타인: “내가 그렇게 똑똑한 것이 아니라, 단지 문제를 더 오래 붙잡고 있을 뿐”
• 대부분의 천재들은 특별히 지능이 높거나 사회적이지 않았음 → 헌신, 근면, 호기심만이 공통점
• 심리학자 캐롤 드웩: 고정 마인드셋(fixed mindset)은 성장 마인드셋(growth mindset)으로 바꿀 수 있음
• 창의성은 학습 가능한 기술 → Elixir나 Scala 프로그래밍처럼, Unix CLI 숙달처럼 익힐 수 있음
• 창의성은 렘브란트, 반 고흐, 리누스 토발즈, 스티브 잡스만의 것이 아님
• 창의성은 복잡하며 개념들이 고도로 상호 연결되어 있음 → 근육처럼 훈련하고 성장시킬 수 있음

9.2 창의성에 대한 진화하는 관점

• 나이가 들수록 새로운 관점에 열리기가 어려워지지만, 동시에 비판적 사고가 향상됨
• 신경과학자 Daniel J. Levitin: 성격은 평생에 걸쳐 여러 번 변할 수 있음
• Big Five 성격 검사 (개방성, 성실성, 외향성, 친화성, 신경성) 결과는 나이에 따라 크게 달라짐
• 창의성 인식도 경험에 따라 진화
• 창의성에 대한 인식은 학생 연도별로도 차이 발생:
  • 마지막 학년 학생들은 1학년 학생들보다 동료에게 피드백을 덜 요청
  • 개인주의가 시간이 지날수록 강화되는 경향
• CPPST(창의적 프로그래밍 문제해결 테스트) 분석: 7가지 창의성 도메인을 3가지 상위 구조로 재분류 가능 → 능력, 마인드셋, 상호작용

9.3 창의적이지 않아도 될 때

• 무용가 겸 안무가 Twyla Tharp의 『The Creative Habit』: 창의성을 거의 신성한 헌신으로 묘사 → 지나치게 완벽주의적
• 지로 오노(97세 스시 장인 사례): 장인 정신의 극단적 헌신 → 은퇴 = 사회적 고립 및 인지적 쇠퇴 증가
• 완벽주의 추구의 3가지 문제:
  1. 완벽주의는 번아웃과 우울증으로 쉽게 이어짐
  2. 거대한 Big-C 창의성만을 가치 있다고 보면 작은 일상적 창의성이 무시됨
  3. 장인 정신에 집착하면 고객이 원하는 제품 개발을 소홀히 함 → 창의성은 수단이지 목적이 아님
• 창의적 마인드는 창의적이지 않을 때를 알아야 한다
  • 때로는 덜 요구되는 작업을 실행하며 배터리를 재충전하는 것이 필수
  • 창의성을 과도하게 요구하면 지속적 손상이 생길 수 있음
  • “오버드라이브”에 너무 오래 머물면 안 됨

9장 핵심 요약

• 창의성은 태어날 때부터 정해진 것이 아닌 후천적으로 학습 가능한 기술
• 경험이 쌓일수록 창의성에 대한 관점도 진화함
• 완벽주의와 과도한 창의적 헌신은 오히려 창의성을 방해
• 창의적이지 않아도 될 때를 아는 것 자체가 창의적 역량
• 모든 창의성 개념은 상호 연결되어 있으므로 시스템적으로 사고해야 함