Hackers and Painters

1. 핵심 주장: 해커와 화가는 닮았다

• 해커와 화가는 “만드는 사람(Maker)” 이라는 공통 정체성을 가짐

• 작곡가, 건축가, 작가와 마찬가지로 둘 다 좋은 것을 만드는 것 이 목표

• 연구를 하는 것이 아니라, 만드는 과정에서 새로운 기법을 발견하면 부산물로 얻는 것

• 해킹이 차갑고 정밀하며 기계적이라는 통념, 그리고 그림이 원초적 충동의 광적인 표현이라는 통념 — 둘 다 틀림

2. “컴퓨터 과학(Computer Science)“이라는 이름의 문제

• CS는 역사적 우연으로 뭉쳐진 이질적인 분야들의 집합체 (구 유고슬라비아에 비유)

• CS 내부의 세 층위:

  • 수학자 계열: DARPA 연구비를 받기 위해 CS라고 칭함

  • 중간층: 알고리즘 행동 분석 등 컴퓨터의 자연사(natural history)를 연구

  • 해커 계열: 흥미로운 소프트웨어를 만드는 것이 목적, 컴퓨터는 표현 매체

• 수학자, 물리학자, 건축가를 한 학과에 묶어놓은 것과 같은 구조

• “소프트웨어 엔지니어링”도 마찬가지로 오해를 유발하는 명칭

  • 좋은 소프트웨어 디자이너는 엔지니어가 아니라 건축가에 가까움

  • 건축가는 무엇을 할지(what) 를 결정, 엔지니어는 어떻게 할지(how) 를 결정

  • 단, what과 how를 완전히 분리하면 위험 — 구현 방법을 모르고 설계하면 문제 발생

3. 대학·연구소가 해커에게 끼치는 해악

• “과학”이라는 레이블 때문에 해커들이 과학적으로 행동해야 한다는 압박을 받음

• 결과: 아름다운 소프트웨어를 설계하는 대신 논문을 쓰는 방향으로 표류

• 논문 작성의 구조적 문제:

  • 연구는 독창적이어야 하므로 아무도 원하지 않는 영역을 개척하게 됨

  • 연구는 실질적이어야 하므로 복잡하고 다루기 어려운 시스템이 논문 소재로 유리

  • 잘못된 가정에서 출발할수록 더 많은 논문을 쓸 수 있음 (AI 분야의 다수가 이 함정)

• 아름다운 것은 기존 것에 미묘한 조정을 가하거나 아이디어를 새롭게 결합 하는 방식으로 탄생 → 논문으로 전달하기 어려움

• 해커의 성과를 측정하는 외부 지표로 사용되는 것들의 한계:

  • 논문 수, 표준화 시험, 코드 라인 수 — 모두 편의를 위한 대리 지표

  • 실제 디자인 품질 평가는 좋은 디자인 감각이 있어야만 가능

  • 디자인을 알아보는 능력과 자신이 그 능력을 갖췄다는 자신감 사이에는 음의 상관관계가 있을 수도 있음

• 유일한 외부 검증 기준: 시간 (아름다운 것은 살아남고, 추한 것은 버려짐)

4. 해커가 자기 작업을 오해할 위험

• CS 학과에 속해 있으면 “해킹은 이론 컴퓨터 과학의 응용 버전”이라고 믿는 유혹에 빠짐

• 실제로 해커가 계산 이론을 알아야 하는 수준:

  • 시간·공간 복잡도 계산법

  • 튜링 완전성 개념

  • 파서나 정규표현식 라이브러리 작성을 위한 상태 기계(state machine) 개념 정도

  • → 화가가 물감 화학을 알아야 하는 수준과 동일

• 아이디어의 가장 좋은 출처는 “computer”라는 단어가 붙은 분야가 아니라, 다른 Maker들의 세계

• 회화는 계산 이론보다 훨씬 풍부한 아이디어 원천

5. 프로그래밍 방식 — 스케치로서의 코딩

• 대학에서 배운 방식: 컴퓨터에 앉기 전에 종이에 프로그램을 완전히 설계

• 실제 해커의 방식: 코드를 일단 쏟아내고 점진적으로 다듬어 나감 → 이것이 바로 스케치(sketching)

• 글쓰기, 회화, 건축도 동일한 방식으로 작동

• 프로그램은 작성하면서 이해하는 것, 미리 다 생각한 것을 표현하는 도구가 아님

• 이것이 프로그래밍 언어 설계에 주는 함의:

  • 언어는 유연해야(malleable) 함 — 펜이 아니라 연필이어야 함

  • 정적 타이핑은 대학에서 가르치는 방식으로 프로그래밍한다면 유효하지만, 실제 해커는 그렇게 하지 않음

  • 동적 타이핑이 유리: 데이터 표현에 미리 결정하지 않아도 되므로

  • 좋은 언어는 매우 추상적이어야 함 — 가장 변경하기 쉬운 프로그램은 매우 짧은 프로그램

  • 언어는 알고리즘을 표현하기 위해 설계되어야 하며, 컴퓨터가 실행하는 방법을 알려주는 것은 부수적

6. 수학 선망(Math Envy) 문제

• 과학자들은 수학자가 자신보다 더 똑똑하다고 믿는 경향 → 연구를 최대한 수학처럼 보이게 만들려 함

• 수식이 가득한 페이지는 인상적으로 보임 → 중요한 문제보다 형식화할 수 있는 문제를 선택하게 됨

• 해커가 다른 Maker들(작가, 화가)과 자신을 동일시하면 이 함정을 피할 수 있음

• 작가와 화가는 수학 선망이 없음 — 해커도 마찬가지여야 함

7. 기업에서의 해커 문제

• 대학·연구소는 해커를 과학자로 만들고, 기업은 해커를 엔지니어로 만듦

• 대기업의 기본 구조: 소수의 프로덕트 매니저가 비전을 제시 → 해커는 코드로 번역하는 기술자로 전락

• 이 구조의 이유: 결과의 표준 편차를 줄이기 위함 (뛰어난 해커를 식별하기 어렵기 때문)

• 하지만 진동을 억제하면 높은 지점도 낮은 지점과 함께 사라짐

• 대기업은 훌륭한 제품으로 이기는 것이 아니라 경쟁사보다 덜 나쁨으로써 이김

• 디자인 전쟁에서 대기업을 이기는 법:

  • 프로덕트 매니저가 설계하는 대기업과 디자인 싸움을 벌이면 항상 이길 수 있음

  • 단, 대기업과 정면충돌은 어려움 — 기존 시장은 이미 요새화됨

  • 새로운 시장에서 싸워야 함 → 대담한 디자인 접근법 + 설계와 구현을 같은 사람이 담당

  • Microsoft, Apple, HP 모두 초기에 이 방식으로 성공

8. 스타트업의 강점과 약점

강점

• 설계와 구현을 같은 사람이 담당 → 대기업을 디자인 전쟁에서 이길 수 있음

• 더 빠른 피벗과 사양 변경 가능

약점

• 소프트웨어 작성 외에 할 일이 너무 많음 (Paul Graham의 경우 해킹에 쓴 시간은 전체의 25%)

• 돈이 되는 소프트웨어와 흥미로운 소프트웨어 사이의 괴리

  • 재미있는 작업에 대한 수요 < 일상적인 문제를 해결하는 작업에 대한 수요

  • 가격은 수요와 공급으로 결정 — 좋아하는 일을 하는 것은 경제적으로 불리할 수 있음

9. “낮일(Day Job)” 개념과 오픈소스

• 대부분의 Maker는 커리어 초기에 **낮일(돈을 위한 일)**과 **진짜 작업(사랑으로 하는 일)**을 병행

  • 뮤지션: 레코드 가게에서 일하며 밤에 연주

  • 작가, 화가: 낮일을 하며 창작 활동

• 오픈소스 해킹이 바로 이 모델의 소프트웨어 버전

  • 오픈소스가 올바른 모델인 이유: 다른 Maker들의 방식에 의해 독립적으로 검증된 접근법

• 채용 시 여가 시간에 어떤 소프트웨어를 만드는지가 핵심 평가 기준이어야 함

  • 진정으로 사랑하는 일만 잘할 수 있음

  • 해킹을 사랑한다면 필연적으로 자신만의 프로젝트를 진행하게 됨

10. 해킹을 배우는 법 — 회화에서 배운 교훈

실행을 통한 학습

• 해커는 대학 강의가 아니라 13살부터 직접 프로그램을 만들면서 해킹을 배움

• 화가는 작품의 흔적을 남기므로 연대순으로 보면 학습 과정이 보임 — 각 작품이 이전 작품에서 배운 것을 쌓아 올림

• 해커도 정기적으로 처음부터 다시 시작하는 것이 좋을 수 있음 (몇 년씩 하나의 프로젝트를 붙잡는 대신)

• 과학자의 학습 방식과의 차이:

  • 과학자: 완벽한 재현(검증된 작업)에서 시작 → 점차 독창적 연구로

  • 해커: 처음부터 독창적 작업 (품질은 낮지만) → 점차 품질 향상

  • 즉, 해커는 독창적으로 시작해서 실력을 키우고, 과학자는 잘하는 것에서 시작해서 독창적이 됨

예시를 통한 학습

• 화가에게 미술관이 기법의 참고 도서관이듯, 해커는 좋은 프로그램의 소스코드를 통해 배움

• Benjamin Franklin: Addison과 Steele의 에세이를 요약하고 재현하며 글쓰기를 배움

• Raymond Chandler: 탐정 소설로 동일한 방법을 사용

• 오픈소스 운동의 덜 알려진 혜택: 프로그래밍 학습이 쉬워짐

11. 점진적 개선(Gradual Refinement)

• 그림은 스케치에서 시작해 점진적으로 세부사항이 채워짐

• X선으로 보면 수많은 명화들이 이동된 팔, 수정된 얼굴 특징을 가지고 있음

• 프로그램도 같은 방식으로 작동해야 함

  • 사양이 처음부터 완벽할 것이라는 기대는 비현실적

  • 사양이 즉석에서 변경될 수 있는 방식으로 프로그램을 작성해야 함

• 성급한 설계(premature design)의 위험 = 성급한 최적화(premature optimization)만큼 위험

  • 프로그램이 무엇을 해야 하는지를 너무 일찍 결정하지 말 것

• 대기업은 이 방식을 따르기 어려움 → 스타트업의 또 다른 강점

12. 아름다움에 대한 집착

• 레오나르도 다빈치의 사례 (Ginevra de Benci 초상화):

  • 배경의 노간주나무 잎 하나하나를 정성스럽게 그림

  • 얼마나 많은 사람이 볼 것인가에 상관없이 최선을 다함

  • 보이지 않는 세부 사항들이 합쳐져 압도적인 전체를 만들어냄

• 위대한 소프트웨어도 마찬가지: 아무도 볼 것 같지 않은 내부 코드도 아름다워야 함

• 해커가 단순한 구현자가 아닌 창조자라면 영감(inspiration)을 고려해야 함

• 작업 사이클 관리:

  • 해킹과 회화 모두 작업 사이클이 있음 (흥분 → 무기력 반복)

  • 흥분될 때 힘든 작업, 무기력할 때 쉬운 작업을 배치해 흐름을 유지

  • 버그 수정을 쉬운 작업으로 저축해두는 전략: 완전히 제약된 문제 → 해결되면 무조건 이긴다는 확신

13. 협업 모델 — 회화 공방에서 배우는 법

• 과거의 위대한 미술 작품 다수는 여러 손의 협업으로 제작됨

  • 베로키오 공방에서 레오나르도는 조수였고, 「그리스도의 세례」 중 천사 하나를 그림

  • 미켈란젤로는 시스티나 천장화를 혼자 그린 것으로 유명 — 당시에도 특별한 사례로 여겨짐

• 회화 협업의 원칙: 같은 부분을 두 사람이 절대 함께 작업하지 않음

  • 주인공은 마스터가, 배경과 기타 인물은 조수가 담당

• 소프트웨어 협업에의 적용:

  • 코드를 명확하게 정의된 모듈로 분리하고, 각 모듈에 명확한 소유자를 지정

  • 모듈 간 인터페이스는 프로그래밍 언어만큼 신중하게 설계

  • 3~4명이 소유자 없이 같은 코드를 해킹하면 → 버려진 공유 공간처럼 황폐해지고 기술 부채 누적

14. 공감(Empathy)의 중요성

• 대부분의 소프트웨어는 인간 청중을 위해 만들어짐 → 해커도 화가처럼 공감 능력이 필수

• 공감은 훌륭한 해커와 그냥 좋은 해커를 구분하는 가장 중요한 차이

• 일부 해커는 매우 영리하지만 공감 능력이 사실상 독아론자(solipsist) 수준 → 훌륭한 소프트웨어 설계 불가

• 공감 능력 측정 방법: 기술적 질문을 비전문가에게 설명하는 능력 관찰

• 소프트웨어가 해야 할 일 중 하나: 스스로를 설명하는 것

  • 사용자는 준비 없이 소프트웨어에 접근하며, 매뉴얼을 읽지 않음

  • 사용자가 짐작하는 대로 작동해야 함

  • 1985년 오리지널 매킨토시 = 이것을 제대로 구현한 거의 유일한 사례

• 코드도 사람이 읽기 위한 것:

  • “프로그램은 사람이 읽기 위해 작성되어야 하고, 기계가 실행하는 것은 부수적이다” — SICP

  • 6개월 후 자신의 코드를 이해 못하는 것은 공감 부재의 증거

  • 코드를 읽기 쉽게 만드는 것은 주석을 많이 다는 것이 아님 — 언어 자체가 알고리즘을 표현하도록 설계되어야 함

• 공감 부재는 지능과 연관되는 오해가 있지만, 실제로는 상관관계 없음

  • 수학·자연과학에서 공감 없이도 잘할 수 있기 때문에 스마트함과 공감 부재가 잘못 연결됨

15. 해킹의 위상과 미래

• 해킹이 지금 당장 회화만큼 “쿨해” 보이지 않는 이유: 명성에는 긴 시간 지연(time lag)이 있음

  • 회화가 지금 높은 평가를 받는 것은 500년 전 위대한 작업 덕분

  • 당시 사람들은 그 작품들이 지금만큼 중요하다고 생각하지 않았음

• 그러나 한 가지는 확실함: 지금이 해킹의 황금기(glory days)

  • 대부분의 분야에서 위대한 작업은 초기에 이루어짐

  • 1430~1500년 회화, 셰익스피어의 연극, 뒤러의 판화, 오스틴의 소설 — 모두 새로운 매체 등장 초기의 폭발적 탐구

  • 새로운 매체가 등장하면 첫 두 세대가 대부분의 가능성을 탐구함

• 해킹이 얼마나 쿨해질지는 우리가 이 새로운 매체로 무엇을 할 수 있느냐에 달려 있음

핵심 인사이트 요약 (빠른 참조)