Simple ≠ Easy — 14 원칙의 산소

Rich Hickey의 2011 강연 Simple Made Easy에서 출발. 14 원칙 모두가 complex를 simple로 바꾸는 도구인데, 그 simple이 무엇인가가 정의되지 않으면 모든 원칙이 표류한다. overview의 철학적 root 3개 중 하나. 짧고 강력해서 학습 path Step 2 (3시간 무료 path의 마지막).

한 줄

Simple은 얽힘 없음(structural property), Easy는 친숙함·가까움(cognitive property). 둘은 직교적 차원이라 한쪽이 다른 쪽을 함의하지 않는다. AI 시대에 가장 위험한 함정은 easy를 simple로 착각하는 것 — vibe coding이 그 극단 사례. 14 원칙 모두가 easy의 유혹을 거부하고 simple을 선택하는 도구.

⚛️ 철학

원칙의 왜. 더 깊은 root와의 연결.

Hickey의 가장 강력한 무기는 어원 분리:

핵심 통찰: simple과 easy는 같은 차원이 아니다. 직교적이라서 4사분면이 가능:

• simple + easy
• simple + hard ← 대부분 fundamentals가 여기
• complex + easy ← vibe coding의 함정
• complex + hard

한국어로 옮기면 분리가 더 명료:

• 단순(單純) = 하나(單)의 순수함(純) → simple
• 쉬움(易) = 손쉬움, 변(易)함 → easy

한국어 한자어가 우연히 Hickey의 어원 분리를 정확히 표현. 단순함과 쉬움은 다른 차원이라는 게 한국어 사용자에게는 직관.

이 명제가 root인 이유: 14 원칙 모두가 complex를 simple로 바꾸는 도구. 그런데 simple의 정의가 흔들리면 모든 원칙이 표류한다.

• deep-modules = complex implementation을 simple interface로 처리 → simple
• ubiquitous-language = vocabulary 얽힘(번역 비용) 제거 → simple
• orthogonality = layer 간 얽힘 제거 → simple
• anti-corruption-layer = 외부 시스템 변화의 얽힘을 격리 → simple

모든 원칙의 공통 측정 단위가 simple. 그래서 산소.

다른 root와의 연결:

• information-hiding (Parnas 1972) = 얽힘을 module 안에 격리하는 mechanism. simple의 module-level 운영
• strategic-vs-tactical-programming = simple을 만드는 데 시간 투자(strategic) vs easy를 골라 빠르게 hack(tactical). 같은 명제의 사람-수준 표현

Brooks의 No Silver Bullet과 만나는 자리: Brooks는 essential complexity (도메인 본질)와 accidental complexity (도구·과정에서 생긴 우연 복잡성)를 구분. Hickey의 simple 추구는 accidental complexity 제거가 목표. essential complexity는 simple로도 줄지 않음.

🧱 추상적 작동 구조

4사분면이 핵심 다이어그램:

핵심 움직임:

• SE → SH: 시스템 성장하며 simple은 유지하지만 hard해짐 (학습 곡선)
• CE → CH: easy의 함정 — 누적되며 결국 hard도 됨
• SH → SE: 도구·문서·관습으로 hard를 easy로 옮김 (안전한 방향)
• CE → SH (역방향): refactor가 쉽지 않음 — complex는 한 번 누적되면 풀기 매우 hard

Hickey의 constructs vs artifacts 구분도 핵심:

→ easy한 construct가 simple한 artifact를 만든다고 보장 못 함. 이게 vibe coding 함정의 정확한 모양 — 인터페이스(prompt)가 easy인데 결과(코드)가 complex.

⚠️ 약점/한계

원칙의 적용 한계. 잘못 적용 시 함정.

1. Premature simplification

도메인을 충분히 이해하기 전에 simple하게 만들려다 본질을 놓침. essential complexity를 accidental로 착각. Brooks의 silver bullet 함정의 simple 측 표현.

해결: simple 추구는 도메인 이해 후에 적용. ubiquitous-language 먼저 정착시킨 뒤 simple로 진행.

2. Simple = Minimal 혼동

Hickey 본인이 강연에서 명시: simple과 minimal은 다르다. minimal은 기능을 빼는 것, simple은 얽힘을 푸는 것. minimal한 시스템이 complex할 수 있고, 기능 풍부한 시스템도 simple할 수 있다.

예시:

• minimal: feature 5개만 있는 todo app. 그러나 storage·UI·로직이 얽혀 있으면 complex
• simple but not minimal: feature 50개. 그러나 각 feature가 독립적으로 합쳐짐. 얽힘 없음

→ Unix philosophy ("do one thing well, compose")가 simple but not minimal의 대표.

3. Easy를 영구적으로 거부하는 함정

Easy도 때때로 정당하다. 모든 것을 simple로만 만들면 학습 곡선·진입 장벽·생산성이 비대해짐.

정당한 easy 사용처:

• 학습 단계 — 신규 사용자에게는 easy가 entry point
• 1회성 코드 — spike, prototype, throw-away script
• 사용자 onboarding — 첫 만남은 easy로

핵심: easy를 simple로 착각하지만 않으면 easy 자체는 가치. 두 차원 모두 의식하는 게 답.

4. Simple의 측정 어려움

complex는 측정 가능 (cyclomatic complexity, coupling 등). simple은 주관적 판단에 가깝다. 얽힘의 객관 지표가 없음 → 같은 코드를 보고 simple하다 / complex하다 판단이 갈림.

해결: 측정 대신 원칙 따라 판단. deep-modules, orthogonality, ubiquitous-language 같은 구체 원칙이 simple의 조작적 정의.

5. Simple도 과도한 추상화 비용을 만들 수 있다

얽힘을 풀려고 너무 많은 indirection·layer·abstraction을 도입하면, 결과는 simple하지만 easy도 hard도 아닌 무거운 시스템. AbstractFactoryFactoryBuilder 함정.

해결: simple 추구는 deep module과 함께 (작은 표면 + 깊은 내부). 작은 layer 100개는 simple이 아니라 분산된 complex.

🔄 대안 흐름

이 원칙이 적용 안 되는 시나리오와 다른 답.

대안 1 — Easy first 패러다임

핵심 명제: 일단 잘 작동하는 거 만들고, simple은 나중에.

→ Karpathy의 vibe coding 정당한 자리. research/stateless-llm-sdk/fundamentals-lineage|fundamentals-lineage에서 정리한 것처럼, vibe coding 자체가 잘못은 아님 — production에 그대로 가는 것이 잘못.

대안 2 — Worse Is Better (Richard Gabriel, 1989)

simple보다 implementation의 simple을 우선. interface가 좀 거칠어도 implementation이 단순하면 가치 있다는 입장. Unix와 C가 이 철학.

→ Hickey의 simple과 부분 동의. 차이: Hickey는 얽힘 없음이 핵심, Gabriel은 적게 만들기가 핵심.

대안 3 — Embrace complexity (Lisp 진영)

복잡성을 피하지 말고 도구로 다루자. Macros, metaprogramming, reflection. 복잡성을 simple하게 표현하는 도구가 있으면 complex 자체는 문제 아님.

→ Hickey 본인이 Clojure를 만든 사람이라 부분적으로 이 진영. 하지만 Clojure는 immutable + functional로 얽힘을 줄이는 방향. 복잡성 자체를 옹호하지 않음.

대안 4 — 복잡성을 caged하게 (Encapsulated complexity)

Simple/easy 구도를 거부하고, complex but well-encapsulated가 답이라는 입장. Deep module의 정신과 정렬.

→ 사실 Hickey와 충돌하지 않음. Hickey의 simple은 artifact 단위에서. encapsulation은 시스템이 복잡할 수 있지만 각 module은 simple. 둘이 합쳐짐.

💡 인사이트

AI 시대 왜 지금 부활하는가 + 학내 segment 의미.

1. Vibe coding = Complex + Easy의 극단 사례

Karpathy의 vibe coding 원본 명제를 4사분면에 박으면:

• 인터페이스 (prompt) → easy ✅
• 결과 (생성된 코드) → 누적되며 complex 💀
• 사용자 인지 → easy로 오해 (실제는 complex)

이게 Hickey 명제의 가장 명료한 contemporary 사례. 1차 ok, 2차 worse, 3차 garbage 패턴은 complex가 누적되는 속도가 사람의 인지 속도를 추월하는 형태.

research/stateless-llm-sdk/fundamentals-lineage|fundamentals-lineage의 Karpathy reverse는 그가 자기 명제의 함정을 발견한 사례: AI-generated code is awkward and gross = complex가 표면화되는 순간.

2. AI agent도 simple/easy 함정에 빠진다

AI agent가 코드를 짤 때, 매 prompt마다 easy한 답을 선택하는 경향이 있다:

• 새 추상화 필요? → 새 파일 만들기 (easy)
• 기존 module 확장? → 새 method 추가 (easy)
• 결과: 작은 파일 100개, 작은 method 1000개 = simple이 아니라 분산된 complex

이게 deep-modules#약점/한계|deep-modules 노트의 얕은 깊이 함정의 root. AI agent는 각 step에서 easy를 골라 누적적으로 complex를 만든다.

해결: 사람이 simple 측정을 담당. AI에게 얽힘이 늘었는지 매 step 확인 (tdd-as-small-deliberate-steps와 함께).

3. Easy의 비용을 알고 사용하는 게 agentic engineering

sources/key-articles-summary#4. Simon Willison — *Not all AI-assisted programming is vibe coding*|Willison의 경계 정의: review/audit 시작 시점이 vibe 아님. 이걸 simple/easy 언어로 옮기면:

vibe coding은 easy의 비용을 모르는 채 사용 agentic engineering은 easy의 비용을 알고 사용

같은 도구(LLM)를 쓰지만, 사용자가 complex가 누적되는지를 의식하면 simple로 다시 끌어올 수 있음. Hickey 명제의 AI 시대 운영 표현.

4. 14 원칙 모두가 simple을 만드는 도구

각 원칙이 어떤 얽힘을 푸는지 정리하면 simple/easy 명제가 산소임이 분명해짐:

→ 14 원칙은 14가지 얽힘에 대한 14가지 풀기 도구. 통일된 framework.

5. 학내 segment에서 easy → simple 학습 path

학내 학생이 v1.0이나 다른 도구를 쓸 때 자연스러운 path:

이 path가 학내 사용자에게 fundamentals 정당화의 가장 강력한 도구. 처음부터 simple을 강요하면 진입 장벽이 높지만, easy로 들어와 비용을 체험하고 simple로 이동하면 체험적 학습. research/stateless-llm-sdk/study-resources-fundamentals|study-resources-fundamentals의 학습 path Step 0-1이 이 체험 단계.

6. 한국어 한자어가 명제를 직관화

한국어 사용자에게는 simple/easy 분리가 직관적:

• 단순(單純)함 — 하나의 순수함, 얽힘 없음 = simple
• 쉬움(易) — 손쉬움, 친숙함 = easy

영어로는 simple과 easy가 일상에서 거의 동의어로 쓰이지만, 한국어로는 단순과 쉬움이 원래부터 다른 단어. Hickey의 명제가 영어 사용자에게는 발견인 게, 한국어 사용자에게는 언어가 이미 알려준 것.

→ 학내 segment에서 이 명제를 한국어로 가르치면 훨씬 빠르게 흡수. v1.0의 ubiquitous language skill이 한국어 도메인 vocabulary를 채택할 때, 단순함 = simple, 쉬움 = easy로 명시적 구분 박기.

7. Simple은 hard, 그래서 strategic 사고가 필요

Hickey의 가장 도발적인 명제: Simple은 easy하지 않다. 만들기 hard하다. 매 결정마다 얽힘이 늘었는지 의식적으로 점검해야 함. 그게 strategic-vs-tactical-programming|strategic 사고의 본질.

AI 시대에 사람이 머물 자리: simple을 만드는 자리. AI는 easy한 답을 매 step에 던져주지만, 그게 simple인지 판단은 사람의 strategic 영역. research/stateless-llm-sdk/software-fundamentals-thesis|Matt thesis의 strategic vs tactical 분할이 simple/easy 차원에서 다시 정확히 표현됨.

다음에 가야 할 자리

이 노트가 호출한 다른 원칙들 — 자연스러운 다음 노트:

• strategic-vs-tactical-programming — simple 만드는 strategic 사고 (Hickey와 Ousterhout의 만남)
• information-hiding — simple의 module-level mechanism (Parnas 1972)
• orthogonality — layer 사이 얽힘 풀기 (simple의 architecture-level 표현)
• ubiquitous-language — vocabulary 얽힘 풀기 (simple의 domain-level 표현)

관련

• overview
• deep-modules — deep module은 simple하지만 easy하지 않다. 이 노트의 가장 직접적 응용
• research/stateless-llm-sdk/software-fundamentals-thesis|software-fundamentals-thesis — Matt thesis (simple을 만드는 게 strategic)
• research/stateless-llm-sdk/fundamentals-lineage|fundamentals-lineage — Hickey가 철학적 root 중 하나로 명시됨
• sources/key-articles-summary|key-articles-summary — 5개 article에서 Hickey 명제와 만나는 지점들

Sources

직접 source

• Rich Hickey — Simple Made Easy (InfoQ, 2011) — 강연 영상 (1시간)
• 같은 강연이 Strange Loop 2011에서 처음 발표됨. archive 다양한 형태로 접근 가능
• 비공식 transcript (검색 필요): matthiasn/talk-transcripts repo 후보

원리의 root와 응용

• Simple Made Easy slides (강연 페이지에서 download)
• Hammock Driven Development — Hickey 후속 강연. simple 만들기 위한 생각의 시간 강조
• Brooks, F.P. (1986). No Silver Bullet — Essence and Accident in Software Engineering. — essential vs accidental complexity 구분의 root
• Gabriel, R.P. (1989). Worse Is Better. — 대안 흐름의 대표

AI 시대 호출

• Matt Pocock — Software Fundamentals YouTube — Hickey 명시적 호출은 안 했지만 정신은 일치
• research/stateless-llm-sdk/fundamentals-lineage — Hickey가 철학적 root 중 하나로 명시