Files
softwaredesign/wiki/sources/EOS-ch7-concept-dependence.md
minsung 81a4d0a2fe 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>
2026-04-30 15:04:06 +09:00

6.0 KiB

title, tags, source, chapter, updated
title tags source chapter updated
EOS Ch7 — 개념의 의존
source
EOS
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: 콘텐츠와 행동 인증

의존 구조:

  • upvoteq&a (주): 업보트할 대상(답변)이 있어야 한다
  • userq&a (주): 질문·답변 작성자 인증이 핵심
  • userupvote (부): 이중 투표 방지에도 활용 가능
  • recordingq&a: 오디오를 질문에 첨부
  • identificationrecording: 식별 결과를 녹음과 연결

다이어그램이 주는 것들:

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

실제 앱 구조 분석

Facebook

핵심 구조:

  • post (기반 개념)
  • commentpost
  • replycomment
  • userpost (주), comment, reply, tag, like (부)
  • frienduser + post (포스트 접근 제어 + 사용자 인증 필요)
  • taguser + post
  • likepost (주), comment, reply (부)

Apple Safari

핵심 구조:

  • url (기반 개념 — 중앙)
  • htmlurl
  • cacheurl (속도 향상)
  • certificateurl (서버 인증)
  • cookieurl
  • private browsingcookie
  • bookmark, favorite, frequently visited, reading listurl (상단)

Safari 분석 통찰: bookmark 변형 개념들(favorite, frequently visited, reading list)이 서로 매우 유사하다. 오프라인 읽기와 읽음 표시를 모든 bookmark에 추가하고, 자주 방문한 사이트를 일반 bookmark 폴더로 통합하면 더 시너지적 설계가 가능하다.

Apple Keynote

핵심 구조:

  • slide (기반)
  • special blockslide: 제목·본문·슬라이드 번호
  • text block + shapeslide
  • paragraphtext block
  • text style + shape style: style 개념 인스턴스
  • masterspecial block (기본 서식 제공)
  • thememaster + text style (스타일 모음)
  • layershape + text block
  • animationspecial 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."

관련 개념