Worse is Better
1989년 Richard Gabriel의 thesis. 완벽한 design이 단순한 design에 패배하는 이유. SOAP/CORBA가 사라지고 REST/JSON이 살아남은 이유. MCP가 6개월 만에 ecosystem을 잡은 이유의 lens.
1. 철학
Gabriel이 "Lisp: Good News, Bad News, How to Win Big" (1989)에서 두 진영을 대비했다.
The Right Thing (MIT 진영, Common Lisp)
- correctness > simplicity > consistency > completeness
- interface 우선. implementation이 복잡해도 interface는 옳아야 한다
- "올바른 것을 한 번에 만들자"
Worse is Better (New Jersey 진영, Unix/C)
- simplicity > correctness > consistency > completeness
- implementation 우선. interface가 살짝 깨져도 implementation이 단순하면 그게 우선
- "일단 단순하게, 나머지는 나중에"
Gabriel의 핵심 thesis 한 문장:
The Right Thing은 바이러스가 아니다. Worse is Better는 바이러스다.
단순한 design은 빠르게 퍼진다. 퍼지면 critical mass가 형성된다. critical mass가 형성되면 사람들이 그 design을 고치는 데 자원을 투자한다. 결국 시간이 지나며 좋아진다. 완전한 design은 정반대 — 천천히 진화하다 critical mass를 못 이루고 사라진다.
이게 worse design이 better design을 이기는 mechanism이다. 바이러스성이 우월성을 이긴다.
2. 추상 작동 구조
Worse is Better가 ecosystem을 형성하는 mechanism
The Right Thing이 실패하는 mechanism
핵심 비대칭: Worse is Better는 시간을 기회로 본다 (퍼진 다음 고친다). The Right Thing은 시간을 적으로 본다 (처음부터 옳아야 한다). 그러나 ecosystem은 시간 위에서 자란다. 이 비대칭이 결과를 결정한다.
3. 약점
Worse is Better도 trap이 있다.
Trap 1 — 정교화의 부채 처음 단순했던 게 시간이 지나며 복잡함이 추가된다. 그러나 이미 lock-in. 결과는 정리되지 않은 누적 복잡도. POSIX의 수많은 옵션, Unix shell의 quirks가 이 trap의 산물이다. 단순함의 미덕이 원래 미덕에서 과거의 영광으로 변한다.
Trap 2 — 잘못된 design도 단순하면 퍼진다 Worse is Better는 옳음을 보장하지 않는다. 단순함만 보장한다. 단순하지만 전혀 옳지 않은 design도 바이러스성을 가질 수 있다. 초기 PHP가 종종 사례로 인용된다 — 보안과 일관성이 깨진 채로 ecosystem을 잡았고, 결국 거대한 부채로 남았다.
Trap 3 — 정교화가 community 자원에 의존 "퍼진 다음 고친다"는 community가 고칠 의지와 자원이 있을 때만 작동한다. 자원이 부족하면 fragmentation으로 끝난다. Worse is Better는 community가 살아 있다는 전제 하에서만 도달 경로다.
Trap 4 — 충분히 단순하지 않으면 어느 진영도 아닌 회색지대에 빠진다 SOAP는 The Right Thing을 노렸지만 충분히 옳지도 않았고, 충분히 단순하지도 않았다. 결과는 양쪽의 단점만 가진 채 사라짐. 중간이 가장 위험하다.
4. 대안 흐름
The Right Thing 진영이 패배한 사례:
| The Right Thing | Worse is Better | 결과 |
|---|---|---|
| OSI 7-layer (1980s) | TCP/IP | TCP/IP가 ecosystem을 먼저 잡음. OSI는 학술 영역에 남음 |
| SOAP / WSDL / XSD | REST / JSON | REST/JSON 압승. enterprise에서도 마이그레이션 진행 |
| CORBA | gRPC / 소켓 직접 | CORBA 사라짐 |
| Common Lisp | C, Python | C/Python ecosystem 폭증 |
| XHTML strict | HTML5 | HTML5의 오류 허용 파싱이 web을 구함 |
The Right Thing 진영이 이긴 사례 (드뭄):
- 암호 protocol (TLS) — 옳음이 보안에 직결되므로 단순함을 양보 못 함
- ⚠️ AI 추정: 안전성이 bet된 영역에서만 The Right Thing이 유리. 나머지는 거의 다 Worse is Better가 이김
이 패턴이 현재 AI agent ecosystem에 어떻게 적용되는가:
| The Right Thing 후보 | Worse is Better 후보 | 현재 상태 |
|---|---|---|
| Tool 호출용 완전한 schema (SOAP-like) | MCP — JSON-RPC + stdio | MCP가 6개월에 25+ agent 채택 |
| OpenAPI-grade tool spec | agentskills.io SKILL.md (Markdown 한 장) | SKILL.md가 vendor 합의 |
| formal verification skill spec | AGENTS.md (Markdown 한 장) | 20,000+ repo 채택 |
⚠️ AI 추정: MCP는 Worse is Better를 의식적으로 노린 design. JSON-RPC는 단순한 protocol, stdio는 가장 단순한 transport. 정교한 type system이나 schema validation은 의도적으로 minimal. 이게 SOAP의 운명을 반대로 가는 결정적 이유.
5. 인사이트
5.1 MCP가 ecosystem을 잡은 이유는 우월함이 아니라 바이러스성
6개월에 25+ agent에 채택된 건 MCP가 기술적으로 더 나아서가 아니다. spec이 단순해서다. 단순함이 구현체 폭증을 만들고, 구현체 폭증이 critical mass를 만들고, critical mass가 표준을 굳혔다. SOAP/CORBA가 사라진 자리를 MCP가 차지한 방식이 정확히 Gabriel의 mechanism.
5.2 학내 marketplace 결정에 적용
비개발자가 다수인 segment에서 marketplace를 만든다면 — 완벽한 skill spec을 기다리지 말고 Worse is Better한 spec으로 시작해야 한다. 진입장벽 낮은 게 우선. config가 살짝 옳지 않아도 일단 퍼지는 게 옳지만 안 퍼지는 것보다 낫다.
5.3 lock-in을 두려워하지 말 것
일단 퍼지면 community가 고친다. 안 퍼지는 게 더 큰 위험이다. 오히려 lock-in이 community를 모으는 forcing function이다. 이 점은 직관에 어긋나지만 패턴은 일관적이다.
5.4 The Right Thing의 함정 — 오버엔지니어링
agent 표준에서 너무 정교한 spec (formal verification, schema validation, capability negotiation)은 ecosystem 속도를 죽인다. 이건 SOAP의 함정과 같다. 학내 marketplace에서 "skill에 type checking 강제"는 전형적 오버엔지니어링. 일단 Markdown 한 장으로 시작.
5.5 그러나 trap을 의식해야 — 정교화 부채
Worse is Better가 정답이라고 영원히 단순한 게 아니다. 시간이 지나면 정교화 부채가 쌓인다. v1.0에서 단순하게 시작하되, 어디에 정교화가 필요해질지를 예측하는 layer (예: capability flag, version negotiation)는 처음부터 hook으로 박아둔다. 이게 design-principles #4 Orthogonal Layers, #7 Anti-Corruption Layer와 직접 연결.
5.6 가장 위험한 자리는 중간
The Right Thing도 못 되고, Worse is Better도 못 된 spec — SOAP가 그 자리. v1.0에서 어느 한쪽은 분명히 정해야 한다. 중간을 노리면 양쪽의 단점만 가진다. 학내 marketplace는 분명히 Worse is Better 쪽. 망설일 필요 없음.
5.7 바이러스성이 기능보다 중요할 수 있는 segment
비개발자 segment는 특히 그렇다. 기능이 부족해도 접근 가능한 게 우선. 이 segment에서 The Right Thing은 애초에 도달하지 못한다. → segment-application-non-developer-majority에서 더 깊이.
다음 노트로의 연결
이 노트는 ① fundamentals의 시작점이다. 다음 노트 후보:
- protocol-theory-lamport-tanenbaum — protocol = 합의된 약속의 이론적 기반. layer 분리의 원리.
- standardization-political-economy — de facto (MCP) vs de jure (W3C/IETF). 학내 marketplace가 어느 쪽인가.
- postels-law-and-robustness — "보낼 때 엄격, 받을 때 관대". protocol 수명을 늘리는 원리.
각 노트는 독립적이지만, 함께 읽으면 ②③④⑤을 해석하는 완성된 lens가 된다.
참조
- Richard Gabriel, "Lisp: Good News, Bad News, How to Win Big" (1989) — 원본 essay
- "The Rise of Worse is Better" — Gabriel 후속 글
- Tim Berners-Lee, web의 초기 design 결정 — Worse is Better의 사례 (HTTP/HTML이 SGML 진영을 이긴 이유)
- Roy Fielding, REST 박사논문 — SOAP의 trade-off 분석
- MCP spec (2024-11) — JSON-RPC over stdio
- agentskills.io — Markdown 한 장의 skill spec
연결:
-
- tool-vs-mcp-research — MCP가 layer 분리의 사례
- design-principles — #4 Orthogonal Layers · #7 Anti-Corruption Layer
- software-fundamentals-thesis — Matt thesis. 사람=strategic, AI=tactical. 바이러스성 표준은 strategic 결정.