Design and Research

1. 핵심 전제: 디자인 vs. 연구의 차이

• 디자인(Design)

  • 반드시 새로울 필요는 없지만, 반드시 좋아야(Good) 한다

  • 선행 작업을 능가하기 위해 새로운 아이디어를 활용함

• 연구(Research)

  • 반드시 좋을 필요는 없지만, 반드시 새로워야(New) 한다

  • 새로울 뿐 아니라 실제로 풀 가치 있는 문제를 다룸

• 수렴점: 두 경로는 정상(top)에서 만남 — 최고의 디자인은 새로운 아이디어를 쓰고, 최고의 연구는 좋은 디자인이기도 함

• 글의 핵심 질문: 프로그래밍 언어를 연구 주제가 아닌 디자인 문제로 접근하면 무엇이 달라지는가?

2. 사용자 중심(User-Centric) 설계 원칙

2-1. 디자인의 출발점

• 가장 큰 차이: 사용자에게 더 집중함

• 디자인은 항상 두 질문으로 시작: “이것은 누구를 위한 것인가?”, “그들에게 무엇이 필요한가?”

• 좋은 건축가는 자신의 디자인을 먼저 만들고 강요하는 것이 아니라, 먼저 사용자를 연구하고 필요를 파악함

2-2. “원하는 것(Wants)” vs. “필요한 것(Needs)”

• 디자이너는 단순히 고객이 시키는 대로 만드는 ’즉석 요리사’가 아님

• “고객은 항상 옳다”의 진짜 의미: 좋은 디자인의 척도는 사용자에게 얼마나 잘 작동하느냐임 (이론적 원칙이 아무리 훌륭해도 실제로 불편하면 나쁜 디자인)

• 역설의 해답: 사용자를 위해 디자인하되, 사용자가 말하는 것이 아닌 실제로 필요한 것을 설계해야 함

• 비유: 의사는 환자의 증상만 치료하지 않음 → 증상 너머 진짜 원인을 진단하고 치료함

2-3. 어떤 사용자를 선택할 것인가

• 디자인이 최소공통분모를 목표로 할 필요는 없음 — 특정 사용자 그룹을 선택하면 됨

• 초보자 또는 전문가 중 누구를 위한 디자인인지에 따라 ’좋은 디자인’의 기준이 달라짐

• 핵심: 디자이너가 의도한 사용자 그룹 없이는 좋고 나쁜 디자인을 논할 수 없음

3. 디자이너가 사용자여야 하는 이유

• 원칙: 의도된 사용자 그룹에 디자이너 자신이 포함될 때 좋은 디자인이 나올 가능성이 높음

• 자신이 속하지 않는 그룹을 위해 디자인할 때, 그 그룹을 ‘덜 정교한(less sophisticated)’ 존재로 보게 되는 경향이 있음

• 사용자를 낮춰보는 것은 디자이너를 부패시킨다 — 아무리 선의에서 비롯되어도

• 역사적 사례 비교:

• 결론: “바보를 위한 디자인”이라고 생각하면, 바보에게도 좋지 않은 결과물이 나옴

4. 인간을 위한 설계 — 디자인과 연구의 본질적 차이

• 연구에서의 추상화: 인간이 이해하기 쉬운 방식으로 선택하지 않음 → 증명을 짧게 만드는 방식으로 선택 (과학적 아이디어는 ergonomic하지 않아도 됨)

• 예술/디자인에서의 추상화: 모든 것이 사람에 관한 것 — 인간의 신체, 관심사, 한계를 충족해야 함

• 프로그래밍 언어도 인간을 위한 것: 인간의 뇌도 신체처럼 불규칙하고 개성적 → 어떤 아이디어는 쉽게 파악되고 어떤 것은 아님

• 인간의 한계: 세부 사항 처리 용량이 매우 제한적 → 이것이 프로그래밍 언어가 필요한 이유 (기계어를 직접 다룰 수 없으므로)

5. 언어는 완성 프로그램이 아닌 개발 과정을 위한 것

• 언어는 완성된 프로그램의 형식이 아니라 프로그램이 개발되는 매체임

• 핵심 통찰: 언어의 테스트는 완성된 프로그램이 얼마나 깔끔해 보이느냐가 아니라, 완성에 이르는 경로(path)가 얼마나 깔끔했느냐

• 완성된 프로그램에서 우아한 결과를 주는 선택이 우아한 개발 과정을 보장하지 않음

• 예시: 중첩 backquote 매크로 → 완성된 결과물은 아름답지만, 수 시간의 시행착오 끝에 탄생 & 정확한지도 확신하기 어려움

• 두 매체 비유:

  • 대리석(Marble): 완성된 아이디어에 적합한 내구성 있는 매체지만, 새로운 아이디어 개발에는 절망적으로 경직됨

  • 유화(Oil Paint): 초안에서 시작해 완성작으로 점진적으로 발전 가능 — 프로토타입 자체가 최종 결과물이 될 수 있음

• Interactive Toplevel(REPL) 예시:

  • 소프트웨어 개발에서 REPL(Read-Eval-Print Loop)은 엄청난 강점

  • REPL이 필요하다면 → 변수 선언 필수 언어와 충돌 발생

  • 강제 타입 선언이 REPL과 비호환 → 강제 타입 선언 언어는 편리하게 프로그래밍하기 어려움

6. Worse is Better — 프로토타입 우선 원칙

• “Worse is Better” 개념: 소프트웨어 세계에서 빠른 프로토타입 공개 후 점진적 개선을 강조[en.wikipedia]​

• 핵심 아이디어: 완성품을 한 번에 만들려 하지 말고, 가능한 빨리 프로토타입을 사용자 앞에 가져가야 함

• 대안(Hail Mary 전략): 프로토타입 없이 한 번의 긴 터치다운 패스로 완성품을 만들려는 시도 → 재앙의 레시피

  • 인터넷 버블 시절 수많은 스타트업이 이 방식으로 자멸

  • 성공한 사례를 들어본 적 없음

• 예술 세계에서의 동일 원칙:

  • 드로잉: 윤곽선을 천천히 따라가는 것이 아니라 대략적인 위치에 빠른 선 몇 개를 긋고 점진적으로 다듬음

  • 금속 활자체: 처음에는 종이에 붓으로 설계

  • 청동 조각상: 왁스로 먼저 모델링

  • 태피스트리: 종이에 먹 워시로 패턴 드로잉

  • 석조 건물: 목재 소재로 소규모 테스트

• 유화의 혁신: 프로토타입(예비 스케치) 자체가 완성작이 될 수 있는 최초의 매체 → 소프트웨어도 동일 가능

• 소프트웨어 원칙: 프로토타입을 완성품으로 발전시킬 수 있을 때 항상 그렇게 해야 함 → 개발 과정에서 얻은 새로운 인사이트를 반영 가능

7. 모랄(Morale)의 중요성

• 핵심 주장: 모랄은 디자인의 핵심 요소인데, 사람들이 충분히 이야기하지 않음

• 그림 교사의 가르침: “그리는 것이 지루하면, 그림도 지루하게 보인다”

  • 예시: 건물의 벽돌을 하나씩 그리다가 지루해져 기계적으로 그리면, 단순히 벽돌을 암시하는 것보다 나빠 보임

• 점진적 프로토타입 개선이 모랄에 좋은 이유: 계속 참여(engaged) 상태를 유지시켜 줌

• 소프트웨어 규칙 (Paul Graham): “항상 작동하는 코드를 유지하라”

  • 1시간 후 테스트 가능한 것을 작성 중이라면 → 즉각적인 보상의 기대가 동기부여로 작용

• 유화의 방식: 흐릿한 스케치로 시작해 점진적으로 다듬음 → 이론상 하루를 미완성으로 끝낼 필요가 없음

  • 화가들의 격언: “그림은 결코 끝나지 않는다, 그냥 작업을 멈출 뿐” — 소프트웨어 개발자에게도 익숙한 개념

• 정교하지 않은 사용자를 위한 디자인이 어려운 이유: 자신이 좋아하지 않는 것에 흥미를 유지하기 어려움

  • “와, 이거 정말 대단해!” 라고 생각해야 함, “멍청이들은 이걸 좋아하겠지”가 아닌

• 결론: 디자인은 인간을 위한 것인데 — 사용자만이 아니라 디자이너 자신도 인간임

8. 디자인은 한 사람의 통제 하에 있어야 한다

• 연구와 디자인의 차이: 연구는 여러 명이 협업 가능하지만, 디자인은 한 사람의 통제 하에 있어야 좋은 결과가 나옴

• 예술에서의 협업:

  • 오페라: 리브레토 작가 + 음악 작가 분리 (true collaboration이 아님)

  • 르네상스: 이탈리아 그림 배경을 북유럽 장인이 담당 (각자 담당 영역이 나뉜 것)

  • “좋은 울타리가 좋은 이웃을 만든다(Good fences make good neighbors)” — Robert Frost

  • 좋은 디자인들을 붙일 수는 있지만, 각 개별 프로젝트 내에서는 한 사람이 통제해야 함

• 협업의 한계: 좋은 디자인은 판단을 신뢰하는 사람의 조언은 매우 가치 있지만, 최종 결정은 한 사람에게 있어야 함

• 왜 연구는 협업 가능하고 디자인은 어려운가?

  • 명확한 답은 없음 (Paul Graham도 확신하지 못함)

  • 가설: 최고의 연구는 좋은 디자인이기도 하며, 그런 연구는 협업으로 이루어지지 않을 수 있음

  • 유명 과학자 중 많은 수가 혼자 작업했으나, 이것이 패턴인지는 불확실

• “디자인 위원회(Design by Committee)“는 나쁜 디자인의 동의어

• 근본적 이유: 좋은 디자인은 **일관성(all of a piece)**이 있어야 함

  • 디자인이 한 사람의 머릿속에 들어가는 아이디어를 표현하면, 그 아이디어는 사용자 머릿속에도 들어감

🔑 핵심 인사이트 요약