18b46520b8
- 9개 wiki 소스 페이지에 총 69개 JPEG 이미지 Vision 분석 결과 삽입 - fig. 2.1–2.8, 3.1, 3.3–3.5: EOS-part1-motivations (Backblaze·Dropbox 설계 결함) - fig. 4.1, 4.3, 4.5–4.6: EOS-ch4-concept-structure (개념 5요소·상태 기계) - fig. 5.1–5.10: EOS-ch5-concept-purposes (목적 기준·미스피트 사례) - fig. 6.1, 6.4, 6.6, 6.9: EOS-ch6-concept-composition (시너지·동기화 문제) - fig. 7.1–7.3: EOS-ch7-concept-dependence (의존 다이어그램) - fig. 8.1–8.5, 8.7, 8.10–8.11: EOS-ch8-concept-mapping (UI 매핑·다크 패턴) - fig. 9.1, 9.3–9.4, 9.6–9.9, 10.1–10.3, 11.1–11.2, 11.4–11.5: EOS-part3-principles - fig. E.1–E.5: EOS-endnotes-formalism (상태 기계·관계형 모델·Photoshop layer) - fig. E.6–E.9: EOS-endnotes-context (Bosch·Gmail·nail clipper·Photoshop crop) - fig. E.10: EOS-part3-principles (Apple Pages '09 부분 스타일) - 책 표지·챕터 헤더 이미지는 스킵 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
8.1 KiB
title, tags, source, chapter, updated
| title | tags | source | chapter | updated | ||
|---|---|---|---|---|---|---|
| EOS Ch7 — 개념의 의존 |
|
The Essence of Software, Daniel Jackson (2021) | Ch7 Concept Dependence | 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는 실선 체인으로 연결된다. 다이어그램 하나로 앱의 핵심 개념, 의존 방향, 구현 단계화 순서가 한눈에 드러남을 보여준다.
다이어그램이 주는 것들:
- 핵심 개념 식별: q&a는 모든 개념이 직·간접으로 의존. 없으면 앱 자체가 불가능
- 일관된 부분집합: 의존 화살표가 집합 밖으로 나가지 않는 부분집합만 독립 앱 가능
- 가능: {q&a, recording, upvote}
- 불가능: {identification, q&a} — identification이 recording에 의존하므로
- 개발 단계화: 일관된 부분집합 순으로 구현하면 언제나 테스트 가능한 상태 유지
- 설명 순서: 의존 방향대로 설명해야 개념 도입이 자연스럽다
- 좋은 순서: 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 중심 — 가 다이어그램으로 명확히 대비된다.
핵심 구조:
- 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 — 전체 개요