---
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*: 식별 결과를 녹음과 연결

> **fig. 7.1** (*Concept dependencies for a bird song app. A solid arrow denotes a primary dependence and a dashed arrow a secondary dependence. The core concepts are in bold.*): BirdSong 앱의 개념 의존 다이어그램으로, 5개의 노드(user, upvote, identification, recording, q&a)가 배치돼 있다. q&a는 굵은 테두리(핵심 개념)로 표시되고, 모든 개념이 직·간접으로 q&a를 향해 화살표가 향한다. user→upvote 간에는 점선(부 의존), user→q&a와 upvote→q&a는 실선(주 의존), identification→recording→q&a는 실선 체인으로 연결된다. 다이어그램 하나로 앱의 핵심 개념, 의존 방향, 구현 단계화 순서가 한눈에 드러남을 보여준다.

**다이어그램이 주는 것들**:

1. **핵심 개념 식별**: *q&a*는 모든 개념이 직·간접으로 의존. 없으면 앱 자체가 불가능
2. **일관된 부분집합**: 의존 화살표가 집합 밖으로 나가지 않는 부분집합만 독립 앱 가능
   - 가능: {*q&a*, *recording*, *upvote*}
   - 불가능: {*identification*, *q&a*} — *identification*이 *recording*에 의존하므로
3. **개발 단계화**: 일관된 부분집합 순으로 구현하면 언제나 테스트 가능한 상태 유지
4. **설명 순서**: 의존 방향대로 설명해야 개념 도입이 자연스럽다
   - 좋은 순서: *q&a* → *upvote* → *user* → *recording* → *identification*
   - 나쁜 순서: *upvote* 먼저 → 업보트할 대상이 없어 설명 불가

## 실제 앱 구조 분석

> **fig. 7.2** (*Concept dependencies for Facebook (left) and Apple Safari (right).*): 왼쪽 Facebook 다이어그램: post(굵은 테두리·핵심)를 중심으로 comment→post, reply→comment, user→post(실선)·comment·reply·tag·like(점선), friend→user+post, tag→user+post, like→post(실선)·comment·reply(점선) 구조가 실선과 점선으로 연결된다. 오른쪽 Safari 다이어그램: url(굵은 테두리)을 중앙에 두고, 위에 bookmark·favorite·frequently visited·reading list, 왼쪽에 certificate·cache, 아래에 html→form→autofill, 오른쪽에 cookie←private browsing이 배치된다. 두 앱의 개념 구조적 차이 — Facebook은 소셜 관계 중심, Safari는 URL 중심 — 가 다이어그램으로 명확히 대비된다.

### 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 폴더로 통합하면 더 시너지적 설계가 가능하다.

> **fig. 7.3** (*Concept dependencies for Apple Keynote.*): Keynote 개념 의존 다이어그램으로, slide(굵은 테두리·핵심)가 중앙 하단에 자리잡고 있다. 상단에 theme(부 의존으로 master·text style에 점선), master→special block→slide, text style→paragraph·text block·shape(실선), shape style→shape(점선), layer→shape+text block(점선), animation→slide(실선)·text block·shape(점선), group→shape(점선), comment·presenter note·transition·outline→slide(실선) 구조가 펼쳐진다. Keynote의 복잡한 개념 구조가 slide 하나를 축으로 어떻게 계층화돼 있는지를 시각화한다.

### 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]] — 전체 개요