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