14 원칙의 통합 명제 — Complex를 Simple로 관리
14 원칙을 한 줄로 압축하면 complex(얽힘)를 simple로 관리하는 strategic 도구의 모음. AI 시대에 더 강해진 이유는 AI가 complex를 더 빠르게 누적시키기 때문. overview의 대화 후 발견된 통합 통찰. simple-not-easy 인사이트 4의 표를 더 깊게 + Brooks essential/accidental + Two-faced deep module 추가.
한 줄
14 원칙 = 14가지 얽힘에 대한 14가지 풀기 도구. 원칙을 따로 외울 게 아니라 "어떤 얽힘을 푸는가"만 묻기. AI 시대에는 AI agent가 자연스럽게 complex를 누적시키기 때문에 strategic 사람이 14 원칙으로 차단하지 않으면 시스템 통제 불가. 학생의 진짜 자산은 14 원칙 외우기가 아니라 얽힘을 인지하고 답 카탈로그에서 검색하는 능력.
⚛️ Hickey의 어원 — Complex와 Simple의 정확한 정의
simple-not-easy 명제의 핵심:
| 단어 | 어원 | 의미 |
|---|---|---|
| Simple | Latin simplex — one fold/braid (하나의 꼬임) | 얽힘 없음. structural property |
| Complex | Latin complex — braided together (서로 꼬임) | 얽힘이 있음. structural property |
| Easy | Latin adjacent — lying near | 친숙함, 손에 닿는. cognitive property |
| Hard | (영어 native) | 인지적 어려움 |
핵심: simple/complex는 시스템의 구조적 속성. easy/hard는 사람의 인지. 둘은 직교 차원. 한국어 단순(單純) vs *쉬움(易)*이 정확히 표현.
14 원칙 = 14가지 얽힘 풀기 도구
각 원칙이 어떤 얽힘을 푸는가:
| 원칙 | 어떤 얽힘 | 풀어진 결과 |
|---|---|---|
| deep-modules | interface 복잡도 ↔ implementation 복잡도 | 작은 표면 + 풍부한 내부 |
| information-hiding | module 내부 결정 ↔ 외부 사용 | secret 격리 |
| information-leak-vs-abstraction | abstraction 약속 ↔ 실제 동작 | 예측 가능한 contract |
| strategic-vs-tactical-programming | 미래 design ↔ 즉각 동작 | 의식적 strategic 시간 |
| simple-not-easy | (root — 다른 모든 얽힘의 측정 단위) | (메타 원칙) |
| ubiquitous-language | 도메인 vocabulary ↔ 코드 vocabulary | 한 vocabulary 관통 |
| bounded-context | 같은 단어의 서로 다른 의미 | 경계 안 일관성 |
| anti-corruption-layer | 외부 시스템 변화 ↔ 내부 모델 | 외부 격리 |
| orthogonality | layer ↔ layer | 단방향 의존 |
| reversibility | 결정 ↔ 결정 (한 결정이 다른 결정 강제) | Type 2로 변환 |
| tdd-as-small-deliberate-steps | 코드 ↔ 검증 시점 | 매 step verify |
| tracer-bullets | 미지의 architecture ↔ implementation | 작은 end-to-end로 검증 |
| named-ownership | 책임 ↔ 책임자 | owner 명시 |
| ship-and-rollback-as-normal | 배포 결정 ↔ 결정 verdict | 둘 다 normal |
→ 모든 원칙의 통일된 framework. 14개를 외우려 하지 말고 "어떤 얽힘을 푸는가"만 묻기.
🔬 Brooks 명제와의 만남 — Essential vs Accidental Complexity
이 통찰의 더 깊은 root는 Fred Brooks의 No Silver Bullet (1986):
| Complexity 종류 | 정의 | 14 원칙의 역할 |
|---|---|---|
| Essential complexity | 도메인 본질의 복잡성 (수강신청은 정말 복잡한 도메인) | 못 줄임. 인정해야 함 |
| Accidental complexity | 도구·과정·잘못된 design에서 생긴 우연 복잡성 | 14 원칙이 줄이는 대상 |
→ *14 원칙은 accidental complexity 줄이기 도구. essential은 그대로 둠. Brooks의 no silver bullet은 essential은 silver bullet으로 못 잡는다는 뜻이지 accidental도 못 잡는다는 뜻이 아님.
이 구분이 중요한 이유:
- Essential을 줄이려 하면 → 도메인 본질을 잘못 추상화. premature abstraction
- Accidental을 무시하면 → 시스템이 불필요한 complex로 무너짐
*14 원칙이 정확히 accidental의 silver bullet 후보들.
⏱️ 시간에 따른 Complex 누적
Accidental complexity가 시간에 따라 누적되는 속도가 14 원칙 적용 여부의 차이. 누적 누적되면 결국 시스템이 자기 무게에 무너짐.
🤖 AI 시대 — 누적 속도가 폭발
1990s vs 2026 비교:
1990s:
사람 = complex 누적 속도 (느림, 의식적)
사람 = complex 관리 능력 (의식적 노력으로 OK)
→ 14 원칙이 *유용*하지만 *없어도 살 수 있음*
2026:
AI agent = complex 누적 속도 (폭발적, 무의식)
사람 = complex 관리 능력 (그대로)
→ 14 원칙이 *없으면 시스템 통제 불가*
AI agent의 자연 경향 — 매 prompt마다 easy한 답(빠른 hack) 선택:
- deep-modules에서 본 shallow 양산
- orthogonality에서 본 cascading side effect
- tdd-as-small-deliberate-steps에서 본 garbage 누적
→ 모두 같은 패턴: AI가 만드는 accidental complexity. 14 원칙이 AI 시대 complex 관리의 strategic 도구.
🎭 Two-faced Deep Module — 사용자 통찰의 정리
전통적 deep-modules 명제는 one-faced:
User → simple interface → deep implementation
학생이 발견한 명제 — Two-faced:
User (simplex 표면)
↕ user-facing 표면
Harness (deep complex layer)
↕ LLM-facing 표면
LLM (simplex 표면)
**harness가 위쪽 simplex (사용자)와 아래쪽 simplex (LLM) 둘 사이에 끼어 complex 흡수.
왜 LLM도 simplex여야 하는가
simple-not-easy 명제의 시간 전이가 답:
LLM이 산출:
prompt 쪽 → easy (말로 시키기 친숙)
결과 코드 → complex 누적 (1차 ok → 3차 garbage)
↓
일상 사용자가 받음:
처음 → easy (그냥 작동)
변경 시 → hard (내부 complex라 손 못 댐)
= Complex + Hard (4사분면 *최악*)
→ LLM에게 작은 표면 + 명확한 contract만 노출하면 LLM이 easy를 simple과 착각하지 않음. 작은 task의 simple한 결과만 산출. 누적되어도 garbage 안 됨.
이게 sources/key-articles-summary#3. Anthropic — *Effective Harnesses for Long-Running Agents*|Anthropic harnesses의 one-feature-at-a-time과 passes:tests 명제의 정확한 답.
v1.0의 직접 구현
| Layer | 누구의 simplex 표면 | 갇힌 complex |
|---|---|---|
| User-facing | 학생 / 연구원 | "수강신청 검증해줘" 한 줄 |
| harness 내부 | (둘 다 안 봄) | retry / cache / vendor adapter / hooks / sandbox / lifecycle / context budget |
| LLM-facing | LLM agent | SKILL.md frontmatter + ACL로 정제된 학내 vocabulary |
| External | (격리됨) | OpenAI/Anthropic API, 학사 시스템, MCP servers |
Multi-faced로 확장 — 4 face
| Face | simplex 사용자 | 노출되는 표면 |
|---|---|---|
| User-facing | 학생 (당장 쓰는 사람) | 한 문장 명령, 결과 |
| LLM-facing | AI agent | task contract, vocabulary |
| Future-dev-facing | 후배 (도구 수정할 사람) | SKILL.md + ADR — 도구 진화 표면 |
| Operator-facing | 운영자 (배포·롤백) | health check, rollback button |
각 face가 해당 사용자의 simplex 표면. harness가 4 face 모두를 서로 격리하면서 통합. 학내 segment에서 특히 가치 — 졸업 후 후배가 이어받기가 future-dev-facing이 잘 되어야 가능.
🎭 세 가지 시각 — 같은 명제의 다른 면
이 노트의 통합 명제는 세 가지 시각으로 표현 가능. 같은 framework, 다른 강조점.
| 시각 | 표현 | 강조점 | 운영 도구 |
|---|---|---|---|
| Information hiding 측 (Parnas) | 각 layer에서 어떤 secret을 감출지 | What | module 경계 정의, ACL, BC |
| Complex/Simple 측 (Hickey) | 얽힘을 어디서 풀지 | How | 4사분면 측정, complect 제거 |
| Strategic 측 (Ousterhout, Matt) | 사람이 어디에 시간을 쓸지 | Who/Where | 시간 분배, ADR |
세 시각 모두가 같은 14 원칙 framework의 다른 표현. 어느 시각으로 들어가도 같은 답에 도달.
시각별 가장 유용한 자리
| 상황 | 가장 직접적인 시각 |
|---|---|
| 코드를 짜고 layer를 design | Information hiding (무엇을 감출지) |
| 시스템이 왜 깨지는지 분석 | Complex/Simple (어떤 얽힘?) |
| 팀·자기 시간 분배 결정 | Strategic (누가 무엇에) |
| 14 원칙 entry point | 자기에게 직관적인 시각 |
→ 세 시각 중 자기에게 직관적인 곳에서 들어가도 결국 같은 framework에 도달. 모든 시각을 다 가져야 하는 게 아니라, 한 시각으로 깊이 들어가면 다른 시각이 자연 따라옴.
Multi-layer harness에 가장 직접적인 시각
v1.0 같은 multi-layer harness를 만들 때 Information hiding 측 시각이 가장 직접적 운영 도구:
- 각 layer에서 어떤 secret을 감출지 결정
- *Type 2 (reversible)*를 default로ーBezos two types decisions
- 의도적 Type 1 commitment는 adr-as-strategic-mechanism|ADR로 명시적 인지
보강된 명제 (학생의 직관 검증):
Strategic의 영역 = 각 layer에서 어떤 secret을 감출지 결정 + Type 2를 default로 (reversible) + 의도적 Type 1 commitment는 명시적 인지.
이게 14 원칙의 학생 단위 운영 mechanism — student-application-guide와 adr-as-strategic-mechanism이 그 implementation.
💡 학생에게 의미
1. 통합 framework로 14 원칙 보기
원칙을 각자 외우지 말고 얽힘 풀기 도구로:
- 시스템이 깨짐 → "어떤 얽힘?" → 카탈로그 검색
- 문제 카탈로그가 아닌 답 카탈로그
2. AI 시대 학생의 진짜 자산
- ❌ 시간 지나면 잊힘 / AI도 다 앎: framework 문법, lib API, 알고리즘 디테일
- ✅ AI가 못 가짐: 얽힘을 인지하는 감각, 답 카탈로그 검색 능력, trade-off 판단
3. LLM도 simplex 다루기가 가장 깊은 통찰
흔한 함정 — LLM을 지능으로 보고 복잡한 task 한 번에 던지기:
- 결과: LLM이 garbage 누적
- 사용자가 그 garbage를 일상에서 사용 → complex + hard 4사분면
해결 — LLM을 사용자처럼 simplex 단위로:
- 작은 contract + 명확한 success
- 한 번에 한 task
- harness가 둘 사이의 complex 흡수
이게 strategic-vs-tactical-programming의 AI는 tactical executor에 정확히 정합. LLM = simplex 인터페이스를 가진 tactical executor. 인텔리전스가 아니라 작은 task를 받는 작업자.
4. Brooks 정신의 학생 단위 표현
"내 도메인이 정말 복잡한 건가, 아니면 내가 복잡하게 만든 건가?"
이 질문이 모든 결정 앞에 던져야 할 질문. 답:
- 정말 복잡 (essential) → 인정하고 명료하게 표현
- 내가 만든 complex (accidental) → 14 원칙 카탈로그에서 답 찾기
다음으로
이 통합 명제를 적용하는 path는 별 노트에:
- student-application-guide — 학생이 어디서·언제·어떻게 14 원칙을 등장시킬지
- adr-as-strategic-mechanism — strategic 사고를 글로 남기는 도구
관련
- overview — 14 원칙 지도
- simple-not-easy — 어원·산소 (이 노트의 주축)
- deep-modules — Two-faced 응용의 root
- strategic-vs-tactical-programming — complex 관리가 strategic의 핵심
- research/stateless-llm-sdk/software-fundamentals-thesis|software-fundamentals-thesis — Matt thesis (사람-AI 분할)
- research/stateless-llm-sdk/design-principles|design-principles — v1.0 7 원칙 (이 통합 명제의 implementation)
Sources
- No Silver Bullet — Essence and Accident in Software Engineering — Frederick P. Brooks Jr. (1986). Essential vs accidental complexity 원전
- Rich Hickey — Simple Made Easy — simple/complex/easy/hard 어원 분리
- A Philosophy of Software Design — John Ousterhout. Deep modules
- Anthropic — Effective Harnesses for Long-Running Agents — Two-faced deep module의 운영 사례