softwaredesign/wiki/sources/EOS-endnotes-context.md

---
title: EOS 배경 맥락 — 역사, 철학, 비교
tags: [source, EOS, context]
source: Daniel Jackson (2021), Endnotes 1–42, 65–114
updated: 2026-04-30
---

# EOS 배경 맥락 — 역사, 철학, 비교

> EOS 엔드노트의 역사적 기원, 철학적 배경, 관련 분야와의 비교를 정리한다.

## 소프트웨어 설계 vs. 소프트웨어 공학 (Note 5, 8)

### Dijkstra의 "즐거움 문제"

Dijkstra는 두 문제를 구분했다:
- **정확성 문제(correctness problem)**: 프로그램이 명세를 만족하는가 → 수학적 형식화 가능
- **즐거움 문제(pleasantness problem)**: 명세 자체가 적절한가 → "비과학적"이라 간주

Jackson의 반박: 즐거움 문제가 오히려 더 중요하다. 이름을 "설계 문제"로 바꾸고, "구현 문제"와 대비해야 했다. Dijkstra의 분리가 소프트웨어 연구를 버그 제거에만 집중하게 만들었다.

### David Liddle의 정의

> "Software design is the act of determining the user's experience with a piece of software. It has nothing to do with how the code works inside."

설계 = 사용자 경험의 전체 명세. 코드 구조가 아닌 사용자가 경험하는 것이 핵심.

## Alloy 언어 (Note 3)

Daniel Jackson이 설계한 언어 및 분석 도구:
- 관계(relation)에 기반한 단순하고 강력한 논리
- Alloy Analyzer: SAT 솔버로 컴파일, 유한 범위 내 완전 검사 보장
- 설계 탐색 용도: 속성 검증보다 **시나리오 시뮬레이션**이 더 유용
- 최신 버전: 선형 시제 논리(LTL) 포함, 무한 모델 체킹 지원

## 개념 설계와 관련 분야 비교 (Note 14, 44)

### 기존 개념 모델링 분야와의 차이

| 구분 | 전통적 개념 모델링 | EOS 개념 설계 |
|------|------------------|--------------|
| 목적 | 현실 세계 기술(descriptive) | 소프트웨어 설계·발명(inventive) |
| 초점 | 데이터 모델 (ER 다이어그램) | 행동 중심 |
| 개념 정의 | 엔티티-관계 | 이름+목적+상태+행동+운영원칙 |
| 범위 | 전역 데이터 모델 | 개별 개념에 국소화된 미니 데이터 모델 |

### Fowler 분석 패턴과의 차이 (Note 14)

Fowler의 "분석 패턴"은 재사용 가능한 개념 모델 — EOS 개념에 가장 가까운 선행 연구. 차이: 분석 패턴은 구조 중심이고 행동을 코드 레벨로 표현. EOS 개념은 구현 독립적으로 행동을 명세.

### Domain-Driven Design과의 차이 (Note 14)

Evans의 DDD: 문제 도메인 모델을 구현 기반으로 사용.
- **Bounded context**: 다른 영역에서 다른 도메인 모델 허용
- EOS 개념 설계: 각 개념이 자체 데이터 모델을 가짐 → DDD를 더 정밀화

### Abstract Types / Objects와의 차이 (Note 48)

| | 추상 타입 | EOS 개념 |
|--|----------|---------|
| 수준 | 코드 레벨 | 설계 레벨 |
| 상호 참조 | 타입 간 연결 어려움 | 조합(composition)으로 명확히 연결 |
| 의존성 방향 | OOP에서 역전되기 쉬움 | 개념 의존 다이어그램으로 명시적 표현 |

OOP에서의 문제: `Post`가 `Comment`를 포함하는 구조 → 의존성 역전. 개념 설계에서는 `comment`가 `post`에 의존 (올바른 방향).

## 개념의 역사적 기원 (Note 48)

| 개념 | 발명자/기원 | 연도 |
|------|-----------|------|
| **trash** | Apple (Macintosh 팀) | ~1983 |
| **folder/directory** | Multics 프로젝트 (Bell Labs) | 1960s |
| **style** | Larry Tesler, Tim Mott (Xerox PARC, Bravo 편집기) | 1970s |
| **reservation** (레스토랑) | 19세기 대도시 레스토랑 | 1880s |
| **social security number** | 미국 사회보장청 | 1936 |
| **song** (단위 판매) | Apple iPod/iTunes 팀 | 2001 |

개념은 **발명된다** — 자연계에 개와 고양이처럼 존재하는 것이 아니라 누군가가 특정 목적을 위해 창조한 것.

## 개념의 핵심 특성 요약 (Note 48)

1. **발명적(inventive)**: 개념은 발명된다. 세계에 있는 것을 분류하는 것이 아니다.
2. **진화한다(evolving)**: 시간이 지남에 따라 설계가 개선된다. `trash`에서 `group` 개념까지.
3. **목적 지향적(purposive)**: 목적 없는 개념 = 개념이 아니다.
4. **행동 중심(behavioral)**: 행동 없이는 개념 없다. `pixel`은 개념이 아닐 수 있다.
5. **풍부한 상태(rich states)**: 상태 구조가 행동을 가능하게 한다. David Wheeler: "모든 문제는 간접 수준을 추가함으로써 해결 가능."
6. **데이터 모델 국소화**: 각 개념은 자신의 미니 데이터 모델을 갖는다.
7. **일반적(generic)**: 타입 변수로 인스턴스화 가능. `trash`는 파일도, 이메일도.
8. **독립적(freestanding)**: 다른 개념 없이 정의 가능. 가장 중요한 특성.

## 분리의 원칙 (Note 31)

Dijkstra가 1974년 명명한 "concerns의 분리":
> "어떤 측면을 고립시켜 그 자체의 일관성을 위해 깊이 연구하는 것."

**분리 ≠ 분할정복**: 분할정복은 재조합 가능한 문제를 나누는 것. 분리는 서로 다른 관심사를 독립적으로 다루는 것.

Michael Jackson: 하향식 개발은 개발자가 가장 이해가 부족할 때 (시작 시점에) 가장 결정적인 분해를 강요하기 때문에 보통 실패한다.

## 개념 재사용 플랫폼 (Note 32)

**Déjà Vu** (Santiago Perez De Rosso):
- 전스택(full-stack) 개념 재사용 플랫폼
- GUI + 백엔드 서비스 포함한 개념
- HTML 변형으로 조합 — 최소한의 프로그래밍으로 조합 가능
- 액션 동기화로 개념 연결

기존 프레임워크의 문제: 너무 작은 컴포넌트(날짜 선택기) 또는 너무 크고 경직된 플러그인.

## Latour의 기입 이론 (Note 65)

Bruno Latour의 "inscription(기입)": 기계는 이전에 수동으로 수행되던 작업을 구현한 것.

소프트웨어 개념에의 적용: 레스토랑 예약, 소셜 미디어 팔로우 등 많은 개념이 원래 인간 프로토콜로 시작해 소프트웨어에 기입된다. 이것은 은유가 아니라 **문자 그대로의 동일한 개념**이다.

## 작은 설계 결함과 더 큰 고통 (Note 89)

"작은 결함처럼 보이는 설계 문제도 개발자에게는 코드 복잡성이라는 큰 고통을 유발한다." 소프트웨어 설계 결함은 사용자에게 미묘하게 보이더라도, 그것을 구현하거나 유지하는 개발자에게는 심각한 내부 복잡성을 초래한다.

> **fig. E.6** (*트레파닝: 작은 설계 결함의 은유 — Hieronymus Bosch,* The Extraction of the Stone of Madness, ~1494–1516): 원형 패널화. 돌팔이 외과의가 환자 두개골에서 "광기의 돌"을 수술하는 장면 — 왼쪽 수도사는 깔때기 모자를, 오른쪽 여인은 책을 머리에 올리고 있다. Jackson의 인용: 발굴된 두개골의 트레파닝 구멍은 작아 보이지만 그것이 형성될 당시의 극심한 고통을 상기시킨다 — 설계의 작은 결함도 코드에는 엄청난 복잡성과 고통을 남긴다.

## 설계 비판 vs. 사용자 테스트 (Note 38)

**Jackson의 입장**: 경험적 평가는 과대평가되어 있다.

- 사용자 테스트의 한계: 설계 공간 탐색에 너무 비용이 크다. 매개변수화된 설계만 테스트 가능.
- **전문가 비판(critique)**: 경험과 원칙을 기반으로 설계 탐색 중 평가 — 더 비용 효율적.
- 제안: 원칙에 기반한 비판 → 사용자 테스트 순서. 한 번에 하나의 개념씩.

Google의 Douglas Bowman (첫 시각 디자이너, 2009 퇴사): "모든 결정을 데이터로만 판단하다 보면 회사가 어떤 대담한 설계 결정도 내리지 못하게 된다."

## 특정성 원칙의 보충 (Note 94-102)

### Gmail label vs. category 혼동 (Note 94)

Google이 label 개념 도움말을 작성하면서 첫 문장에 "categories"를 사용 — label과 category가 실은 중복 개념임을 공식 문서가 스스로 드러낸 비의도적 유머.

> **fig. E.7** (*Gmail 도움말 "Using labels" 화면*): "Labels help you organize your messages into categories – work, family, to do, read later, jokes, recipes, any category you want. Labels do all the work that folders do, but with an added bonus: you can add more than one to a message." — label을 설명하면서 categories로 시작. label과 category가 모두 메시지 분류를 위한 중복 개념임을 구글 공식 문서가 의도치 않게 확인.

### 오버로딩의 종류

| 오버로딩 유형 | 설명 | 예 |
|------------|------|-----|
| **목적 부정(denied purpose)** | 새 목적이 원래 목적을 약화 | Facebook like → recommendation |
| **창발 목적(emergent purpose)** | 의도치 않은 목적으로 사용 | Twitter star → 읽기 목록 |
| **거짓 수렴(false convergence)** | 다른 두 개념을 하나로 합침 | Epson 용지 크기 + 급지 방향 |
| **편승(piggybacking)** | 기존 개념에 무관한 기능 추가 | Photoshop 크롭 + 리샘플링 |

**Photoshop 크롭 사례(Note 101)**: `cropping`에 `resampling`이 편승 → CS6에서 분리. 설계 개선의 좋은 예.

> **fig. E.8** (*손톱깎이: 기능 공유(좌) vs. 기능 분리(우) — Ulrich [145]*): 좌: 일반 손톱깎이 스케치 — 단일 금속 스트립이 스프링(탄성)과 절단날(날카로운 모서리) 두 기능을 겸함. 우: Karl Ulrich가 상상한 "부품당 하나의 기능" 원칙 설계의 손톱깎이 단면도 — 스프링과 날이 분리된 복잡한 기계 구조. 결론: 기계 설계의 과부하는 소형화·비용 절감에 유리하지만, 소프트웨어에서는 이점이 없고 두 직교 개념이 단일 과부하 개념보다 이해하기 쉽다 (Note 98).

> **fig. E.9** (*Photoshop CS5 cropping 인터페이스*): 상단 툴바: Width 6 in, Height 4 in, Resolution [빈칸], pixels/inch. 벽돌 건물·나무 이미지에 크롭 핸들 표시. Resolution 필드의 존재가 핵심 — cropping 개념에 resampling 개념이 편승: 크롭 프레임 설정이 동시에 출력 해상도·치수를 지정하게 되어, 전체 이미지를 선택한 "빈 크롭"도 파일을 변경할 수 있는 반직관적 동작 발생. CS6(2012)에서 두 개념이 분리됨 (Note 101).

### 사회적 오버로딩 (Note 99)

대학 멘토 제도: 지원/조언 역할 + 승진 평가 역할 → 근본적 이해충돌.

학회 논문 심사: 피드백 제공 목적 + 채택 결정 목적 → 상충.

Kieran Egan: 교육의 세 목적(사회화, 진리 추구, 자아실현)이 근본적으로 양립 불가.

## 무결성 원칙의 보충 (Note 109-110)

### 강건한 멘탈 모델의 조건

de Kleer & Brown (1981): 사용자가 신뢰할 수 있는 멘탈 모델은 **"구조 속 기능 없음(no-function-in-structure)"** 원칙을 만족해야 한다.

= 컴포넌트 행동 설명이 다른 컴포넌트의 기능을 참조하지 않아야 한다.

이것이 개념의 독립성 원칙과 정확히 일치한다.

### 피처 상호작용과 개념 무결성 (Note 110)

통신 피처 상호작용 정의: "피처 A의 존재가 피처 B의 명세를 더 이상 유효하지 않게 만들 때."

이것이 정확히 개념 무결성 위반의 정의와 같다. 다만 개념 설계에서는 이를 허용하지 않는다.

## Parnas의 uses 관계와 개념 의존 (Note 81)

| | Parnas uses 관계 | 개념 의존 |
|--|----------------|---------|
| 정의 방식 | 코드에서 추론 (A가 B를 호출하면 의존) | 설계자가 선언 |
| 의미 | A의 올바른 실행이 B에 의존 | A를 포함하면 B도 포함해야 일관성 있음 |
| 하위 집합 | 의존에서 도출됨 | 하위 집합이 의존을 정의함 |

Parnas 방법론: "B 없이 A가 포함되는 합리적인 하위 집합이 없는 경우에만 A가 B를 사용하도록 설계하라."

## 관련 페이지

- [[EOS-endnotes-formalism]] — 개념의 수학적 형식 의미론
- [[EOS-ch4-concept-structure]] — 개념 구조 본문
- [[EOS-ch6-concept-composition]] — 개념 조합 본문
- [[EOS-ch7-concept-dependence]] — 개념 의존 본문
- [[EOS-part3-principles]] — 특정성·친숙성·무결성 원칙 본문