81a4d0a2fe
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>
130 lines
6.0 KiB
Markdown
130 lines
6.0 KiB
Markdown
---
|
|
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]] — 전체 개요
|