feat: EOS 엔드노트 컴파일 — 형식 의미론 + 배경 맥락 페이지 2개 추가

- EOS-endnotes-formalism: 개념의 수학적 의미론 (상태기계·트레이스·조합·CSP·동적 논리)
- EOS-endnotes-context: 역사·철학·비교 맥락 (Parnas·DDD·Alloy·기입 이론·오버로딩 분류)
- concepts-181-328 (엔드노트+참고문헌+인덱스) 전량 컴파일 완료

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

wiki/index.md

@@ -41,6 +41,8 @@ updated: 2026-04-30
 - [[EOS-ch7-concept-dependence]] — Jackson, Ch7, 개념 의존 다이어그램·BirdSong·Facebook·Safari·Keynote 구조
 - [[EOS-ch8-concept-mapping]] — Jackson, Ch8, 개념→UI 매핑·다크 패턴·Gmail 레이블 이슈·라이브 필터링
 - [[EOS-part3-principles]] — Jackson, Part III (Ch9–11), 특정성·친숙성·무결성 원칙·과부하·중복·무결성 위반
+- [[EOS-endnotes-formalism]] — Jackson, Endnotes 43–44·64, 개념의 수학적 의미론 — 상태기계·트레이스·조합 의미론·CSP·동적 논리
+- [[EOS-endnotes-context]] — Jackson, Endnotes 1–114, 역사·철학·비교 맥락 — Parnas·DDD·Alloy·기입 이론·설계 비판
 
 ## Patterns — 설계 패턴
 

wiki/log.md

@@ -40,6 +40,26 @@ title: Wiki Operation Log
   - `wiki/sources/EOS-part3-principles.md` — Part III (Ch9–11): 특정성(중복·과부하 4유형·Facebook like 분석), 친숙성(Twitter follower·PowerPoint section vs Keynote), 무결성(복수심 식당·font format·Google Drive)
 - `wiki/index.md` Sources 섹션에 생성된 8개 페이지 등록
 
+## 2026-04-30 (5차)
+
+- [EOS 엔드노트 컴파일] raw/book/EssenceOfSoftware_Eng 미컴파일 5개 파일 (concepts-181-328) 전량 정독
+  - 내용: Acknowledgments + 엔드노트(Ch1–11) + 참고문헌 + 개념·토픽 인덱스
+  - `wiki/sources/EOS-endnotes-formalism.md` 신규 생성
+    - 개념의 수학적 의미론: 상태기계·트레이스·전제조건·교착 상태
+    - 객체 분류: asset/name/value 역할, 가변성, 해석 가능성(순열 불변성)
+    - 조합 의미론: CSP 기반, 트레이스 인터리빙, 보존 정리
+    - 운영 원칙의 동적 논리 형식화 (trash/style/reservation 예시)
+    - 생성 입력(gen keyword) 의미론
+  - `wiki/sources/EOS-endnotes-context.md` 신규 생성
+    - 소프트웨어 설계 vs. 공학 (Dijkstra 즐거움 문제)
+    - Alloy 언어 소개, 개념 모델링 분야 비교 (Fowler, DDD, ADT, OOP)
+    - 개념의 역사적 기원 (trash/folder/style/reservation 발명 연대표)
+    - 개념의 8대 특성 요약 (Note 48)
+    - 분리의 원칙, Déjà Vu 재사용 플랫폼, Latour 기입 이론
+    - 오버로딩 4유형, 사회적 오버로딩, 설계 비판 vs. 사용자 테스트
+    - Parnas uses 관계 vs. 개념 의존 비교
+  - `wiki/index.md` Sources 섹션에 2개 페이지 등록
+
 ## 2026-04-30 (4차)
 
 - `wiki/concepts/additive-programming.md` — "AI 시대에서의 가산적 프로그래밍" 섹션 추가

wiki/sources/EOS-endnotes-context.md

@@ -0,0 +1,179 @@
+---
+title: EOS 배경 맥락 — 역사, 철학, 비교
+tags: [source, EOS, context]
+source: Daniel Jackson (2021), Endnotes 1–42, 65–114
+updated: 2026-04-30
+---
+
+# EOS 배경 맥락 — 역사, 철학, 비교
+
+> EOS 엔드노트의 역사적 기원, 철학적 배경, 관련 분야와의 비교를 정리한다.
+
+## 소프트웨어 설계 vs. 소프트웨어 공학 (Note 5, 8)
+
+### Dijkstra의 "즐거움 문제"
+
+Dijkstra는 두 문제를 구분했다:
+- **정확성 문제(correctness problem)**: 프로그램이 명세를 만족하는가 → 수학적 형식화 가능
+- **즐거움 문제(pleasantness problem)**: 명세 자체가 적절한가 → "비과학적"이라 간주
+
+Jackson의 반박: 즐거움 문제가 오히려 더 중요하다. 이름을 "설계 문제"로 바꾸고, "구현 문제"와 대비해야 했다. Dijkstra의 분리가 소프트웨어 연구를 버그 제거에만 집중하게 만들었다.
+
+### David Liddle의 정의
+
+> "Software design is the act of determining the user's experience with a piece of software. It has nothing to do with how the code works inside."
+
+설계 = 사용자 경험의 전체 명세. 코드 구조가 아닌 사용자가 경험하는 것이 핵심.
+
+## Alloy 언어 (Note 3)
+
+Daniel Jackson이 설계한 언어 및 분석 도구:
+- 관계(relation)에 기반한 단순하고 강력한 논리
+- Alloy Analyzer: SAT 솔버로 컴파일, 유한 범위 내 완전 검사 보장
+- 설계 탐색 용도: 속성 검증보다 **시나리오 시뮬레이션**이 더 유용
+- 최신 버전: 선형 시제 논리(LTL) 포함, 무한 모델 체킹 지원
+
+## 개념 설계와 관련 분야 비교 (Note 14, 44)
+
+### 기존 개념 모델링 분야와의 차이
+
+| 구분 | 전통적 개념 모델링 | EOS 개념 설계 |
+|------|------------------|--------------|
+| 목적 | 현실 세계 기술(descriptive) | 소프트웨어 설계·발명(inventive) |
+| 초점 | 데이터 모델 (ER 다이어그램) | 행동 중심 |
+| 개념 정의 | 엔티티-관계 | 이름+목적+상태+행동+운영원칙 |
+| 범위 | 전역 데이터 모델 | 개별 개념에 국소화된 미니 데이터 모델 |
+
+### Fowler 분석 패턴과의 차이 (Note 14)
+
+Fowler의 "분석 패턴"은 재사용 가능한 개념 모델 — EOS 개념에 가장 가까운 선행 연구. 차이: 분석 패턴은 구조 중심이고 행동을 코드 레벨로 표현. EOS 개념은 구현 독립적으로 행동을 명세.
+
+### Domain-Driven Design과의 차이 (Note 14)
+
+Evans의 DDD: 문제 도메인 모델을 구현 기반으로 사용.
+- **Bounded context**: 다른 영역에서 다른 도메인 모델 허용
+- EOS 개념 설계: 각 개념이 자체 데이터 모델을 가짐 → DDD를 더 정밀화
+
+### Abstract Types / Objects와의 차이 (Note 48)
+
+| | 추상 타입 | EOS 개념 |
+|--|----------|---------|
+| 수준 | 코드 레벨 | 설계 레벨 |
+| 상호 참조 | 타입 간 연결 어려움 | 조합(composition)으로 명확히 연결 |
+| 의존성 방향 | OOP에서 역전되기 쉬움 | 개념 의존 다이어그램으로 명시적 표현 |
+
+OOP에서의 문제: `Post`가 `Comment`를 포함하는 구조 → 의존성 역전. 개념 설계에서는 `comment`가 `post`에 의존 (올바른 방향).
+
+## 개념의 역사적 기원 (Note 48)
+
+| 개념 | 발명자/기원 | 연도 |
+|------|-----------|------|
+| **trash** | Apple (Macintosh 팀) | ~1983 |
+| **folder/directory** | Multics 프로젝트 (Bell Labs) | 1960s |
+| **style** | Larry Tesler, Tim Mott (Xerox PARC, Bravo 편집기) | 1970s |
+| **reservation** (레스토랑) | 19세기 대도시 레스토랑 | 1880s |
+| **social security number** | 미국 사회보장청 | 1936 |
+| **song** (단위 판매) | Apple iPod/iTunes 팀 | 2001 |
+
+개념은 **발명된다** — 자연계에 개와 고양이처럼 존재하는 것이 아니라 누군가가 특정 목적을 위해 창조한 것.
+
+## 개념의 핵심 특성 요약 (Note 48)
+
+1. **발명적(inventive)**: 개념은 발명된다. 세계에 있는 것을 분류하는 것이 아니다.
+2. **진화한다(evolving)**: 시간이 지남에 따라 설계가 개선된다. `trash`에서 `group` 개념까지.
+3. **목적 지향적(purposive)**: 목적 없는 개념 = 개념이 아니다.
+4. **행동 중심(behavioral)**: 행동 없이는 개념 없다. `pixel`은 개념이 아닐 수 있다.
+5. **풍부한 상태(rich states)**: 상태 구조가 행동을 가능하게 한다. David Wheeler: "모든 문제는 간접 수준을 추가함으로써 해결 가능."
+6. **데이터 모델 국소화**: 각 개념은 자신의 미니 데이터 모델을 갖는다.
+7. **일반적(generic)**: 타입 변수로 인스턴스화 가능. `trash`는 파일도, 이메일도.
+8. **독립적(freestanding)**: 다른 개념 없이 정의 가능. 가장 중요한 특성.
+
+## 분리의 원칙 (Note 31)
+
+Dijkstra가 1974년 명명한 "concerns의 분리":
+> "어떤 측면을 고립시켜 그 자체의 일관성을 위해 깊이 연구하는 것."
+
+**분리 ≠ 분할정복**: 분할정복은 재조합 가능한 문제를 나누는 것. 분리는 서로 다른 관심사를 독립적으로 다루는 것.
+
+Michael Jackson: 하향식 개발은 개발자가 가장 이해가 부족할 때 (시작 시점에) 가장 결정적인 분해를 강요하기 때문에 보통 실패한다.
+
+## 개념 재사용 플랫폼 (Note 32)
+
+**Déjà Vu** (Santiago Perez De Rosso):
+- 전스택(full-stack) 개념 재사용 플랫폼
+- GUI + 백엔드 서비스 포함한 개념
+- HTML 변형으로 조합 — 최소한의 프로그래밍으로 조합 가능
+- 액션 동기화로 개념 연결
+
+기존 프레임워크의 문제: 너무 작은 컴포넌트(날짜 선택기) 또는 너무 크고 경직된 플러그인.
+
+## Latour의 기입 이론 (Note 65)
+
+Bruno Latour의 "inscription(기입)": 기계는 이전에 수동으로 수행되던 작업을 구현한 것.
+
+소프트웨어 개념에의 적용: 레스토랑 예약, 소셜 미디어 팔로우 등 많은 개념이 원래 인간 프로토콜로 시작해 소프트웨어에 기입된다. 이것은 은유가 아니라 **문자 그대로의 동일한 개념**이다.
+
+## 설계 비판 vs. 사용자 테스트 (Note 38)
+
+**Jackson의 입장**: 경험적 평가는 과대평가되어 있다.
+
+- 사용자 테스트의 한계: 설계 공간 탐색에 너무 비용이 크다. 매개변수화된 설계만 테스트 가능.
+- **전문가 비판(critique)**: 경험과 원칙을 기반으로 설계 탐색 중 평가 — 더 비용 효율적.
+- 제안: 원칙에 기반한 비판 → 사용자 테스트 순서. 한 번에 하나의 개념씩.
+
+Google의 Douglas Bowman (첫 시각 디자이너, 2009 퇴사): "모든 결정을 데이터로만 판단하다 보면 회사가 어떤 대담한 설계 결정도 내리지 못하게 된다."
+
+## 특정성 원칙의 보충 (Note 94-102)
+
+### 오버로딩의 종류
+
+| 오버로딩 유형 | 설명 | 예 |
+|------------|------|-----|
+| **목적 부정(denied purpose)** | 새 목적이 원래 목적을 약화 | Facebook like → recommendation |
+| **창발 목적(emergent purpose)** | 의도치 않은 목적으로 사용 | Twitter star → 읽기 목록 |
+| **거짓 수렴(false convergence)** | 다른 두 개념을 하나로 합침 | Epson 용지 크기 + 급지 방향 |
+| **편승(piggybacking)** | 기존 개념에 무관한 기능 추가 | Photoshop 크롭 + 리샘플링 |
+
+**Photoshop 크롭 사례(Note 101)**: `cropping`에 `resampling`이 편승 → CS6에서 분리. 설계 개선의 좋은 예.
+
+### 사회적 오버로딩 (Note 99)
+
+대학 멘토 제도: 지원/조언 역할 + 승진 평가 역할 → 근본적 이해충돌.
+
+학회 논문 심사: 피드백 제공 목적 + 채택 결정 목적 → 상충.
+
+Kieran Egan: 교육의 세 목적(사회화, 진리 추구, 자아실현)이 근본적으로 양립 불가.
+
+## 무결성 원칙의 보충 (Note 109-110)
+
+### 강건한 멘탈 모델의 조건
+
+de Kleer & Brown (1981): 사용자가 신뢰할 수 있는 멘탈 모델은 **"구조 속 기능 없음(no-function-in-structure)"** 원칙을 만족해야 한다.
+
+= 컴포넌트 행동 설명이 다른 컴포넌트의 기능을 참조하지 않아야 한다.
+
+이것이 개념의 독립성 원칙과 정확히 일치한다.
+
+### 피처 상호작용과 개념 무결성 (Note 110)
+
+통신 피처 상호작용 정의: "피처 A의 존재가 피처 B의 명세를 더 이상 유효하지 않게 만들 때."
+
+이것이 정확히 개념 무결성 위반의 정의와 같다. 다만 개념 설계에서는 이를 허용하지 않는다.
+
+## Parnas의 uses 관계와 개념 의존 (Note 81)
+
+| | Parnas uses 관계 | 개념 의존 |
+|--|----------------|---------|
+| 정의 방식 | 코드에서 추론 (A가 B를 호출하면 의존) | 설계자가 선언 |
+| 의미 | A의 올바른 실행이 B에 의존 | A를 포함하면 B도 포함해야 일관성 있음 |
+| 하위 집합 | 의존에서 도출됨 | 하위 집합이 의존을 정의함 |
+
+Parnas 방법론: "B 없이 A가 포함되는 합리적인 하위 집합이 없는 경우에만 A가 B를 사용하도록 설계하라."
+
+## 관련 페이지
+
+- [[EOS-endnotes-formalism]] — 개념의 수학적 형식 의미론
+- [[EOS-ch4-concept-structure]] — 개념 구조 본문
+- [[EOS-ch6-concept-composition]] — 개념 조합 본문
+- [[EOS-ch7-concept-dependence]] — 개념 의존 본문
+- [[EOS-part3-principles]] — 특정성·친숙성·무결성 원칙 본문

wiki/sources/EOS-endnotes-formalism.md

@@ -0,0 +1,175 @@
+---
+title: EOS 형식 의미론 — 개념의 수학적 기반
+tags: [source, EOS, formalism]
+source: Daniel Jackson (2021), Endnotes 43–44, 64
+updated: 2026-04-30
+---
+
+# EOS 형식 의미론 — 개념의 수학적 기반
+
+> EOS 본문이 직관적 설명에 집중하는 반면, 엔드노트 43–44, 64는 개념의 수학적 의미론을 다룬다. 이 페이지는 그 기술적 보충 내용을 정리한다.
+
+## 개념의 행동 의미론 (Note 44)
+
+### 상태 기계로서의 개념
+
+개념의 행동은 **상태 기계(state machine)**로 형식화된다.
+
+- **상태(State)**: 개념이 기억해야 하는 것의 집합. 집합과 관계(relation)로 표현
+- **초기 상태**: 모든 집합·관계가 비어 있는 상태
+- **액션**: 전이 관계(transition relation)로 정의됨
+- **결정론(determinism)**: 동일한 상태와 인수에 대해 최대 하나의 후속 상태만 존재
+
+### 트레이스와 상태 함수
+
+**트레이스(trace)** = 가능한 액션 인스턴스의 유한 히스토리
+
+```
+state: Trace → State
+```
+
+상태 함수는 각 트레이스에 그것이 생성하는 상태를 대응시킨다.
+
+```
+state(<create(i0), delete(i0)>) = {accessible: {}, trashed: {i0}}
+state(<create(i0), delete(i0), empty()>) = {accessible: {}, trashed: {}}
+```
+
+### 전이 관계, 전제조건, 교착 상태
+
+액션 `A` (인수 집합 X)의 의미론:
+
+```
+trans(A) ⊆ S × X × S
+```
+
+- **전제조건(precondition)**: 액션이 가능한 (s, x) 쌍의 집합
+- 전제조건이 성립하지 않으면 액션은 실행 불가
+- **교착 상태(deadlock)**: 어떤 상태에서 가능한 액션이 없는 경우 — 설계 결함
+
+### Alloy를 이용한 액션 형식화
+
+```
+pred reserve (u: User, r: Resource) {
+  r in available
+  reservations' = reservations + u -> r
+  available' = available - r
+}
+```
+
+프라임(`'`)은 Electrum 확장의 약식 표기로 액션 후 값을 나타낸다.
+
+## 운영 원칙의 형식화 (Note 43, 44)
+
+### 동적 논리로 표현
+
+기본 형식: `[a]p` = 액션 a 수행 후 술어 p가 항상 성립
+
+복합 액션 연산자:
+- `a;b` — 순차 합성
+- `a*` — 반복 (0회 이상)
+- `a or b` — 선택
+- `not a` — a가 아닌 임의 액션
+
+**trash 개념의 운영 원칙:**
+```
+delete(x) {can restore(x)}
+delete(x); restore(x) {x in accessible}
+```
+
+**reservation 개념:**
+```
+reserve(u, r); (not cancel(u, r))* {can use(u, r)}
+```
+
+**style 개념:**
+```
+define(s, f); assign(e1, s); assign(e2, s); define(s, f') {e1.format = e2.format = f'}
+```
+
+### 운영 원칙 vs. 유스케이스/유저 스토리
+
+| 구분 | 운영 원칙 | 유스케이스 |
+|------|-----------|-----------|
+| 역할 | 개념의 본질 설명 | 기능 전체 기술 |
+| 범위 | 개별 개념 단위 | 시스템 레벨 |
+| 수량 | 핵심 시나리오 1–2개 | 수십~수백 개 |
+| 초점 | 왜 이 개념인가 | 무엇을 할 수 있는가 |
+
+## 객체 분류 (Note 44)
+
+### 역할에 의한 분류
+
+| 역할 | 정의 | 예 |
+|------|------|-----|
+| **자산(asset)** | 고유 가치를 지닌 객체 | 사진, 오디오 트랙, 블로그 포스트, 인증서 |
+| **이름(name)** | 다른 객체를 식별·위치시키는 객체 | 이메일 주소, 도메인 이름, 파일 경로 |
+| **값(value)** | 다른 객체와의 관계에서만 의미를 갖는 객체 | 숫자 80 (나이, 온도, 조회수…) |
+
+### 가변성(mutability)에 의한 분류
+
+- **불변(immutable)**: 개념 간 통신(동기화) 시 공유되는 객체는 반드시 불변이어야 함
+  - 가변 객체가 공유되면 숨겨진 통신 발생 → 앨리어싱 문제
+- 개념 내부에서는 가변 객체 해석 가능
+
+### 해석 가능성(interpretability)에 의한 분류
+
+**비해석(uninterpreted)**: 동등성(equality)만 인식 — 타입 변수처럼 동작
+
+**해석(interpreted)**: 객체의 내부 구조나 값을 활용
+
+**순열 불변성(permutation invariance)으로 형식화:**
+타입 T가 개념 C에서 비해석적이면, T의 임의 순열 p에 대해 p(t)도 C의 트레이스이고 `state(p(t)) = p(state(t))`.
+
+## 조합의 의미론 (Note 64)
+
+### 조합 = 트레이스의 인터리빙
+
+개념들의 조합은 개별 개념 트레이스의 **모든 가능한 인터리빙(interleaving)**이다. 동기화는 허용되는 인터리빙을 제한한다.
+
+동기화 형식:
+```
+sync action1(x)
+     action2(e)
+```
+의미: 모든 트레이스에서 trigger action1의 모든 발생 직후 반드시 response action2가 발생.
+
+### 핵심 정리: 조합은 개념 행동을 보존한다
+
+> "Composing concepts never changes the behavior of any of the constituent concepts."
+
+이것이 개념 이해 가능성의 근거다. 개념은 어떤 맥락에서도 동일하게 행동한다. 위반 시 → 개념 무결성(concept integrity) 위반 (Ch11).
+
+**안전성(safety) vs. 활성성(liveness)**:
+- 조합은 안전성 속성은 보존
+- 활성성은 제한 가능 (예: access control 개념이 다른 개념의 액션을 억제)
+
+### CSP와의 관계
+
+개념 조합의 의미론은 Tony Hoare의 CSP(Communicating Sequential Processes)에서 파생.
+
+차이점:
+| | CSP | 개념 조합 |
+|--|-----|---------|
+| 결정론 | 비결정론적 가능 | 항상 결정론적 |
+| 상태 관찰 | 없음 | 동기화 조건에 상태 사용 가능 |
+| 동기화 | 공유 액션 | trigger/response 쌍 |
+
+## 생성 입력 (Note 64)
+
+액션의 입력에는 두 종류:
+1. **생성 입력(generated input)**: 개념 자체가 생성 — `gen` 키워드로 표시
+2. **제공 입력**: 다른 개념이 제공
+
+```
+add(gen t: Task)           // task는 todo 개념이 생성
+affix(i: Item, gen l: Label)  // item은 외부 제공, label은 label 개념이 생성
+```
+
+트레이스 제약: `gen`이 아닌 입력은 트레이스의 이전 액션에서 생성 또는 출력된 것이어야 한다.
+
+## 관련 개념
+
+- [[EOS-ch4-concept-structure]] — 개념의 5요소 (informal)
+- [[EOS-ch6-concept-composition]] — 개념 조합 전반
+- [[propagation]] — SDF의 전파 모델과 비교 (유사한 수학적 구조)