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-part1-motivations.md

@@ -0,0 +1,116 @@
+---
+title: "EOS Part I — 동기: 왜 개념 설계인가"
+tags: [source, EOS]
+source: "The Essence of Software, Daniel Jackson (2021)"
+chapter: "Part I (Ch1–3)"
+updated: 2026-04-30
+---
+
+# EOS Part I — 동기: 왜 개념 설계인가
+
+## 핵심 아이디어
+
+Part I(Ch1~3)은 왜 소프트웨어 설계의 핵심이 "개념"이어야 하는지를 동기 부여한다. Ch1은 저자의 연구 여정과 문제 의식을, Ch2는 구체적인 개념 예시와 설계 3 수준을, Ch3는 개념이 소프트웨어 설계 전반에서 수행하는 다양한 역할을 설명한다.
+
+## Ch1 — Why I Wrote This Book
+
+### 소프트웨어 설계의 공백
+
+저자는 Alloy(소프트웨어 설계 언어·분석 도구) 연구자로서, 공식 명세보다 설계(design) 자체에 더 흥미를 느꼈다. 설계는 "형태(form)를 맥락(context)에 맞추는" 활동이다(Christopher Alexander).
+
+소프트웨어 공학과 HCI(인간-컴퓨터 상호작용) 연구 모두 설계 자체보다 결함 제거·경험적 방법으로 이동했다. 결과적으로 소프트웨어 설계는 이론적 토대 없이 일화적 경험칙에 의존해 왔다.
+
+### 명료함(Clarity)의 중요성
+
+소프트웨어 개발 성패를 결정하는 것은 언어, 도구, 관리 방법론이 아니다. **무엇을 만들려고 하는지 명확히 아는 것**이다. 설계가 명확하면 코드도 명확하고, 문제도 명확히 진단된다.
+
+### 개념의 기원
+
+1960년대부터 "개념적 모델(conceptual model)"의 중요성은 인정받았다. 그러나 개념적 모델을 사용자의 멘탈 모델로 전달하는 것에만 집중했지, 그 자체를 설계 대상으로 다루지 않았다.
+
+## Ch2 — Discovering Concepts
+
+### 개념이란
+
+> "A software product… is made of *concepts*, each a self-contained unit of functionality."
+
+개념은 앱의 "분자"다. 화학 혼합물처럼 결합되지만, 각 개념의 속성과 행동은 어디에서나 동일하다.
+
+### 예시 1: Backblaze 백업 개념의 오해
+
+저자는 파일이 지속적으로 업로드·복원 가능하다고 가정했지만, 실제 Backblaze의 *backup* 개념은: (1) 주기적 스캔으로 변경 파일 목록 작성 → (2) 목록 기반 업로드 → (3) 스테이징 영역에서 복원 영역으로 이동의 세 단계를 거친다. 멘탈 모델과 실제 개념 간의 불일치가 혼란을 유발했다.
+
+### 예시 2: Dropbox의 unix folder 개념
+
+Dropbox는 이름(name)을 파일 자체의 메타데이터가 아닌, 부모 폴더의 항목(entry)에 귀속시키는 *unix folder* 개념을 사용한다. 이로 인해:
+- 최상위 공유 폴더 이름 변경 → 본인에게만 변경
+- 중첩 공유 폴더 이름 변경 → 모두에게 변경
+- 삭제 시 동작도 이에 따라 달라짐
+
+이것은 버그가 아니라 *개념 설계* 문제다.
+
+### 설계의 3 수준
+
+| 수준 | 내용 | 관심사 |
+|------|------|--------|
+| 물리(Physical) | 버튼, 레이아웃, 접근성 | 인간의 물리·인지 능력 |
+| 언어(Linguistic) | 아이콘, 메시지, 용어 | 문화·언어적 차이 |
+| 개념(Conceptual) | 행동과 상태의 본질 | 개념 구조의 설계 |
+
+개념 수준이 가장 근원적이다. 언어·물리 수준의 문제처럼 보여도 사실 개념 수준의 결함인 경우가 많다.
+
+### 멘탈 모델과 개념 설계
+
+- 사용자의 멘탈 모델이 소프트웨어 실제 개념과 불일치할 때 사용성 문제가 생긴다.
+- 해법은 사용자 교육이 아니라 **단순·유연·명확한 개념을 설계**하고, 사용자 인터페이스가 그 개념을 올바르게 표현하도록 하는 것이다.
+
+## Ch3 — How Concepts Help
+
+### 개념이 앱을 정의한다
+
+앱을 설명하는 가장 좋은 방법은 핵심 개념을 나열하는 것이다. Facebook = *post* + *comment* + *like* + *friend*; Gmail = *email* + *label* + *conversation*; Web = *url* + *html* + *cache* + *bookmark*.
+
+앱 간 차이도 개념으로 설명된다. 문자 메시지 앱은 *conversation* 개념을 쓰고, 이메일은 *mailbox*/*folder* 개념을 쓴다.
+
+### 개념이 제품 차별화 요소
+
+| 앱/서비스 | 핵심 차별화 개념 |
+|-----------|-----------------|
+| Apple Macintosh (1984) | *trash* — 삭제의 취소 |
+| Photoshop | *layer* + *mask* — 비파괴 편집 |
+| VisiCalc (스프레드시트) | *formula* + *reference* |
+| Calendly | *event type* |
+| World Wide Web | *url* — 전역 고유 명칭 |
+
+### 개념이 복잡성을 드러낸다
+
+Photoshop의 *layer*·*mask*, 브라우저의 *certificate*·*private browsing*·*page cache* 같은 복잡한 개념들이 무엇인지 알면, 파워 유저가 되기 위해 무엇을 배워야 하는지 명확해진다.
+
+### 디지털 전환에서의 개념
+
+디지털 전환의 핵심은 새 기술 도입이 아니라 **핵심 비즈니스 개념을 식별·통합·확장**하는 것이다. Apple의 *song* 개념처럼, 개념 하나가 전체 고객 경험을 통합할 수 있다.
+
+### 개념이 관심사를 분리한다
+
+*group* 하나에 모든 기능을 넣는 대신, *group*(멤버십) + *post*(메시지 작성) + *invitation*(초대) + *notification*(알림) + *moderation*(관리) 등으로 분리하면:
+- 설계자가 한 번에 하나의 측면에 집중할 수 있다
+- 팀원들이 병렬로 작업할 수 있다
+- 각 개념을 독립적으로 재사용할 수 있다
+
+### 개념이 안전·보안을 담보한다
+
+보안 설계의 핵심은 *authentication*, *authorization*, *auditing* 등의 개념을 올바르게 설계하는 것이다. 예: two-factor authentication의 *capability* 개념과의 상호작용이 피싱 취약점을 만든다.
+
+## 핵심 인용
+
+> "Concepts characterize individual apps, app classes, and entire product families."
+
+> "Investing in core concepts is less flashy but likely to be more effective."
+
+> "Concepts are the essence of design for safety and security, where picking the right concepts and understanding their implications is paramount."
+
+## 관련 개념
+
+- [[EOS-overview]] — 전체 책 개요
+- [[EOS-ch4-concept-structure]] — 개념 구조 정의 (Part II 시작)
+- [[SDF-ch1-flexibility]] — SDF의 가산적 프로그래밍 철학과 비교