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-ch7-concept-dependence.md

@@ -0,0 +1,129 @@
+---
+title: "EOS Ch7 — 개념의 의존"
+tags: [source, EOS]
+source: "The Essence of Software, Daniel Jackson (2021)"
+chapter: "Ch7 Concept Dependence"
+updated: 2026-04-30
+---
+
+# EOS Ch7 — 개념의 의존
+
+## 핵심 아이디어
+
+개념들은 본질적으로 독립적이지만, 앱의 맥락 안에서는 **의존(dependence)** 관계가 발생한다. A 개념이 없다면 B 개념을 포함할 이유가 없을 때, "B는 A에 의존한다"고 말한다. 의존 관계를 다이어그램으로 표현하면 앱의 구조를 한눈에 파악하고, 설계·구현·설명의 순서를 결정하는 데 도움이 된다.
+
+## 개념 독립성 vs. 앱 내 의존성
+
+모순처럼 보이지만 실제 모순이 아니다:
+- **개념 독립성**: 각 개념은 다른 개념 없이도 이해·구현 가능하다
+- **앱 내 의존성**: 특정 앱에서 어떤 개념을 포함할 근거는 다른 개념의 존재에서 비롯된다
+
+의존성은 개념 자체의 속성이 아니라 **앱 설계 결정의 결과**다.
+
+## 의존 다이어그램(Dependence Diagram)
+
+의존 다이어그램은:
+- 각 개념을 노드로 표현
+- 한 개념이 다른 개념에 의존하면 화살표로 연결
+- **주 의존(primary)**: 실선 화살표 — 가장 핵심적인 의존
+- **부 의존(secondary)**: 점선 화살표 — 부가적 의존
+
+## BirdSong 앱 예시
+
+새 울음소리로 새 종을 식별하는 앱 설계:
+
+**핵심 개념들**:
+- *q&a*: 커뮤니티가 질문에 답변하도록 지원
+- *recording*: 오디오 파일 업로드 허용
+- *upvote*: 개인 평가로 기여도 순위 결정
+- *identification*: 크라우드소싱 기반 객체-카테고리 할당
+- *user*: 콘텐츠와 행동 인증
+
+**의존 구조**:
+- *upvote* → *q&a* (주): 업보트할 대상(답변)이 있어야 한다
+- *user* → *q&a* (주): 질문·답변 작성자 인증이 핵심
+- *user* → *upvote* (부): 이중 투표 방지에도 활용 가능
+- *recording* → *q&a*: 오디오를 질문에 첨부
+- *identification* → *recording*: 식별 결과를 녹음과 연결
+
+**다이어그램이 주는 것들**:
+
+1. **핵심 개념 식별**: *q&a*는 모든 개념이 직·간접으로 의존. 없으면 앱 자체가 불가능
+2. **일관된 부분집합**: 의존 화살표가 집합 밖으로 나가지 않는 부분집합만 독립 앱 가능
+   - 가능: {*q&a*, *recording*, *upvote*}
+   - 불가능: {*identification*, *q&a*} — *identification*이 *recording*에 의존하므로
+3. **개발 단계화**: 일관된 부분집합 순으로 구현하면 언제나 테스트 가능한 상태 유지
+4. **설명 순서**: 의존 방향대로 설명해야 개념 도입이 자연스럽다
+   - 좋은 순서: *q&a* → *upvote* → *user* → *recording* → *identification*
+   - 나쁜 순서: *upvote* 먼저 → 업보트할 대상이 없어 설명 불가
+
+## 실제 앱 구조 분석
+
+### Facebook
+
+핵심 구조:
+- *post* (기반 개념)
+- *comment* → *post*
+- *reply* → *comment*
+- *user* → *post* (주), *comment*, *reply*, *tag*, *like* (부)
+- *friend* → *user* + *post* (포스트 접근 제어 + 사용자 인증 필요)
+- *tag* → *user* + *post*
+- *like* → *post* (주), *comment*, *reply* (부)
+
+### Apple Safari
+
+핵심 구조:
+- *url* (기반 개념 — 중앙)
+- *html* → *url*
+- *cache* → *url* (속도 향상)
+- *certificate* → *url* (서버 인증)
+- *cookie* → *url*
+- *private browsing* → *cookie*
+- *bookmark*, *favorite*, *frequently visited*, *reading list* → *url* (상단)
+
+**Safari 분석 통찰**: bookmark 변형 개념들(*favorite*, *frequently visited*, *reading list*)이 서로 매우 유사하다. 오프라인 읽기와 읽음 표시를 모든 bookmark에 추가하고, 자주 방문한 사이트를 일반 bookmark 폴더로 통합하면 더 시너지적 설계가 가능하다.
+
+### Apple Keynote
+
+핵심 구조:
+- *slide* (기반)
+- *special block* → *slide*: 제목·본문·슬라이드 번호
+- *text block* + *shape* → *slide*
+- *paragraph* → *text block*
+- *text style* + *shape style*: *style* 개념 인스턴스
+- *master* → *special block* (기본 서식 제공)
+- *theme* → *master* + *text style* (스타일 모음)
+- *layer* → *shape* + *text block*
+- *animation* → *special block* (주) + *shape*, *text block* (부)
+
+## 제네릭 개념의 중요성
+
+의존 다이어그램은 개념들이 **제네릭**으로 표현될 때 가장 유용하다. BirdSong 앱에서 *upvote*는 "새 소리 답변에 좋아요"가 아니라 "기여도에 대한 개인 평가"로 일반화돼야 다른 앱에서도 재사용 가능하다. 제네릭 표현:
+- 설계 지식의 재사용을 가능하게 한다
+- 과도한 도메인 특화를 방지해 설계를 단순하게 유지한다
+
+## 점진적 성장(Growing the Product)
+
+의존 다이어그램은 앱을 점진적으로 성장시키는 로드맵이다:
+- **추가**: 새 개념 + 의존 관계 추가
+- **제거**: 예상보다 덜 유용하거나 결함이 심한 개념 제거
+- **정제**: 기존 개념 개선
+- **시너지 발견**: 기존 조합에서 새 가치 도출
+
+Fred Brooks의 "second-system effect" 경고: 작지만 성공적인 시스템을 대규모로 재설계할 때 과신이 비대하고 불필요하게 복잡한 결과를 낳는다.
+
+## 핵심 인용
+
+> "Concepts are freestanding, and independent of one another: a concept can be understood, designed and implemented by itself."
+
+> "In the context of a software product, dependencies arise—not that one concept relies on another for its correct operation, but because inclusion of one concept may make sense only if another is present."
+
+> "The dependence diagram gives a succinct summary of a product's concepts and the motivations for including them."
+
+## 관련 개념
+
+- [[EOS-ch6-concept-composition]] — 개념 조합의 메커니즘
+- [[EOS-ch8-concept-mapping]] — 의존 구조가 UI 설계에 주는 시사점
+- [[EOS-ch4-concept-structure]] — 개념 구조 (독립성의 토대)
+- [[EOS-part3-principles]] — 특정성·친숙성·무결성 원칙
+- [[EOS-overview]] — 전체 개요