feat: Essence of Software wiki 컴파일 + raw 원본 추가

raw/book/EssenceOfSoftware_Eng/ — Daniel Jackson (2021) 원본 11개 폴더 추가

wiki/sources/ EOS 챕터별 한국어 페이지 8개:
- EOS-overview: 전체 개요, 설계 3수준, 핵심 원칙
- EOS-part1: Ch1-3 동기 (Backblaze/Dropbox 사례, 개념 역할)
- EOS-ch4: 개념 구조 (5요소: 이름·목적·상태·행동·운영 원칙)
- EOS-ch5: 개념 목적 (좋은 목적 4기준, 미스피트 사례)
- EOS-ch6: 개념 조합 (동기화, 시너지, 과잉/과소 동기화)
- EOS-ch7: 개념 의존 (의존 다이어그램, 제네릭 개념)
- EOS-ch8: 개념 매핑 (다크 패턴, UI 매핑 딜레마)
- EOS-part3: 원칙 Ch9-11 (특정성·친숙성·무결성)

wiki/index.md Sources 섹션 EOS 8개 등록, wiki/log.md 기록

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

wiki/sources/EOS-overview.md

@@ -0,0 +1,77 @@
+---
+title: "The Essence of Software — 전체 개요"
+tags: [source, EOS]
+source: "The Essence of Software, Daniel Jackson (2021)"
+chapter: overview
+updated: 2026-04-30
+---
+
+# The Essence of Software — 전체 개요
+
+## 핵심 아이디어
+
+소프트웨어의 복잡도 근원은 "개념(concept)"의 혼재와 뒤엉킴에 있다. 개념을 명확히 분리·정의하고 그 목적(purpose)을 정확히 지정하면, 사용하기 쉽고 설계하기 좋은 소프트웨어를 만들 수 있다. 저자 Daniel Jackson은 Alloy 언어 연구에서 출발해, 소프트웨어 설계의 "개념 수준(conceptual level)"이 물리·언어 수준과 독립적으로 다루어져야 한다는 이론을 제시한다.
+
+## 책 구조
+
+| 파트 | 챕터 | 주제 |
+|------|------|------|
+| Part I: Motivations | Ch1–3 | 왜 개념 설계인가; 개념의 발견과 활용 |
+| Part II: Essentials | Ch4–8 | 개념의 구조, 목적, 조합, 의존, 매핑 |
+| Part III: Principles | Ch9–11 | 특정성, 친숙성, 무결성 원칙 |
+| Resources | Explorations & Digressions | 심화 주석·참고문헌 |
+
+## 설계의 3 수준
+
+저자는 소프트웨어 설계를 세 수준으로 분류한다:
+
+1. **물리 수준(Physical level)** — 버튼 레이아웃, 제스처, 접근성 등 물리적 속성
+2. **언어 수준(Linguistic level)** — 아이콘, 메시지, 용어 등 의사소통 관련 속성
+3. **개념 수준(Conceptual level)** — 사용자가 상호작용하는 행동과 상태의 본질
+
+개념 수준이 가장 중요하다. 물리·언어 수준의 문제는 종종 사실 개념 수준의 설계 결함에서 비롯된다.
+
+## 개념(Concept)이란
+
+소프트웨어는 개념들의 합성으로 이루어진다. 각 개념은:
+
+- **자기완결적 기능 단위** — 다른 개념과 독립적으로 이해할 수 있다
+- **목적(purpose)** — 개념이 존재하는 이유
+- **상태(state)** — 개념이 기억하는 정보 구조
+- **행동(actions)** — 상태를 변경하는 동작들
+- **운영 원칙(operational principle)** — 목적이 어떻게 달성되는지를 보여주는 전형적 사용 시나리오
+
+예시 개념: *trash*, *style*, *reservation*, *label*, *todo*, *email*, *upvote*, *friend*, *bookmark*, *folder* 등.
+
+## 주요 원칙 요약
+
+| 챕터 | 원칙 | 핵심 내용 |
+|------|------|----------|
+| Ch9 | 특정성(Specificity) | 개념과 목적은 1:1 대응이어야 한다 |
+| Ch10 | 친숙성(Familiarity) | 기존에 알려진 개념을 재사용하라 |
+| Ch11 | 무결성(Integrity) | 개념 조합 시 각 개념의 명세를 위반하지 마라 |
+
+## 책의 목표
+
+1. 소프트웨어 설계자가 즉시 적용할 수 있는 실용적 기법 제공
+2. 소프트웨어를 기능 덩어리가 아닌 개념의 체계적 조합으로 바라보는 새 관점 제공
+3. 소프트웨어 설계가 지적으로 충분한 독자적 분야임을 증명
+
+## 핵심 인용
+
+> "A software product—from the smallest app that runs on your phone to the largest enterprise system—is made of *concepts*, each a self-contained unit of functionality."
+
+> "Clarity is good not only for finding design flaws after the fact. It is also the key to good design in the first place."
+
+> "The real problem runs deeper. It's in the very essence of how files and folders are named… This is what I call a *conceptual* design issue."
+
+## 관련 개념
+
+- [[EOS-part1-motivations]] — Part I: 동기 챕터들
+- [[EOS-ch4-concept-structure]] — 개념의 구조 정의
+- [[EOS-ch5-concept-purposes]] — 개념의 목적
+- [[EOS-ch6-concept-composition]] — 개념 조합
+- [[EOS-ch7-concept-dependence]] — 개념 의존
+- [[EOS-ch8-concept-mapping]] — 개념 매핑
+- [[EOS-part3-principles]] — Part III: 원칙들
+- [[SDF-overview]] — "Software Design for Flexibility" 개요 (같은 선반)