softwaredesign/wiki/sources/EOS-ch4-concept-structure.md

---
title: "EOS Ch4 — 개념의 구조"
tags: [source, EOS]
source: "The Essence of Software, Daniel Jackson (2021)"
chapter: "Ch4 Concept Structure"
updated: 2026-04-30
---

# EOS Ch4 — 개념의 구조

## 핵심 아이디어

개념(concept)은 다섯 가지 구성 요소로 정밀하게 정의할 수 있다: 이름(name), 목적(purpose), 상태(state), 행동(actions), 운영 원칙(operational principle). 이 구조는 개념을 서로 독립적으로 이해·설계·구현할 수 있게 하며, 재사용성의 토대가 된다. Jackson은 *trash*, *style*, *reservation* 세 개념을 예시로 구조를 설명한다.

## 개념 정의의 5요소

| 요소 | 설명 |
|------|------|
| **이름(name)** | 개념 이름과 타입 파라미터 (제네릭) |
| **목적(purpose)** | 개념이 존재하는 이유를 한 문장으로 |
| **상태(state)** | 개념이 기억하는 데이터 구조 |
| **행동(actions)** | 상태를 변경하는 동작과 전제 조건 |
| **운영 원칙(operational principle)** | 목적이 실제로 달성되는 전형적 사용 시나리오 |

운영 원칙은 가장 단순한 시나리오가 아니라, **목적의 성취를 증명하는 최소 시나리오**다.

## 예시 1: trash 개념

Apple이 1982년 Lisa 컴퓨터를 위해 발명한 *trash* 개념.

> **fig. 4.1** (*The original Macintosh desktop, with trash at bottom right (1984).*): 1984년 최초의 Macintosh 데스크탑 화면으로, 흑백 GUI에 "Mac System Software" 창과 "System Folder" 창이 열려 있다. 화면 오른쪽 하단에 줄무늬 패턴의 작은 쓰레기통 아이콘("Trash")이 자리잡고 있다. Finder, System, Imagewriter, Note Pad, Scrapbook, Clipboard 파일 아이콘들이 보이며, 당시 혁신적이었던 WIMP 인터페이스(창·아이콘·메뉴·포인터)의 원형을 보여준다. *trash* 개념이 처음 도입된 역사적 화면으로, 삭제 취소(undeletion)라는 개념적 혁신의 시작점이다.

**목적**: 삭제의 취소(undoing of deletions)를 허용한다.

**상태**: `accessible` (접근 가능한 아이템 집합), `trashed` (삭제됐지만 영구 제거 전 아이템 집합)

**주요 행동**:
- `delete(x)` — x를 accessible에서 trashed로 이동 (전제: x가 accessible에 있을 것)
- `restore(x)` — x를 trashed에서 accessible로 이동
- `empty()` — trashed의 모든 항목 제거

**운영 원칙**:
```
after delete(x), can restore(x) and then x in accessible
after delete(x), can empty() and then x not in accessible or trashed
```

> "The real innovation… is not that you can move things *into* the trash, but that you can then move them *out*."

### Trash 개념의 설계 결함과 수정

- **문제 1**: macOS에 trash가 하나뿐이라, 외장 드라이브의 파일을 지워도 영구 삭제가 안 됨. OS X El Capitan(2015)에서 "즉시 삭제" 액션으로 해결.
- **문제 2**: trash 안 파일을 삭제 날짜순으로 정렬할 수 없었음. OS X Lion(2011)에서 "added date" 정렬로 해결 (folder 개념의 synergy).

## 예시 2: style 개념

Adobe InDesign, Microsoft Word 등 문서 편집 도구의 *style* 개념.

**목적**: 요소들의 일관된 서식(formatting) 적용을 쉽게 한다.

**상태**:
- `assigned: Element -> one Style` (요소에 할당된 스타일)
- `defined: Style -> one Format` (스타일에 정의된 서식)
- `format: Element -> one Format = assigned.defined` (파생 상태)

**주요 행동**:
- `assign(e, s)` — 요소 e에 스타일 s 할당
- `define(s, f)` — 스타일 s의 서식을 f로 정의 (생성 또는 업데이트)

**운영 원칙**: s를 서식 f로 정의하고, e1·e2에 s를 할당한 뒤 s를 f'로 재정의하면, e1과 e2 모두 f'로 변경된다.

> **fig. 4.3** (*Style concept in Microsoft Word (left) and Apple Pages (right).*): 왼쪽은 Microsoft Word의 "Style" 다이얼로그로, "Normal", "Normal (Web)", "Note Heading" 등 스타일 목록과 선택된 "Normal" 스타일의 단락 미리보기 및 설명(Calibri 폰트, 줄간격 single 등)이 표시돼 있다. 오른쪽은 Apple Pages의 스타일 패널로, "Body" 스타일이 선택되고 Helvetica Neue Regular 11pt 설정이 표시된다. 두 앱 모두 스타일에 서식을 정의하고 요소에 할당하는 *style* 개념의 핵심 구조(이름·서식·할당)를 UI로 구현한 것을 보여준다.

> **fig. 4.5** (*Style concept applied to slide themes in Microsoft PowerPoint (left) and color swatches in Adobe apps (right).*): 왼쪽은 Microsoft PowerPoint의 "Create Theme Colors" 다이얼로그로, Text/Background, Accent 1–6, Hyperlink 등의 색상 역할을 일괄 설정하는 테마 색상 팔레트가 표시되어 있고, 오른쪽 미리보기에 적용 결과가 나타난다. 오른쪽은 Adobe InDesign의 Swatches 패널로, CMYK 값으로 정의된 다수의 색상 견본 목록이 보인다. 두 화면은 *style* 개념이 텍스트 서식을 넘어 슬라이드 테마와 색상 팔레트에도 동일하게 적용됨을 보여준다 — 스타일 수정 시 그 스타일이 적용된 모든 요소가 일괄 변경된다.

### Style이 아닌 것들

> **fig. 4.6** (*Two concepts that look like style but are not: the Apple color picker (left) and styles in Apple TextEdit (right).*): 왼쪽은 macOS Colors 패널로, "Daniel's Swatches" 목록에 Daniel's Orange, Daniel's Blue, Daniel's Green 세 가지 색상이 나열돼 있다. 오른쪽은 Apple TextEdit의 스타일 선택 다이얼로그로, "really"라는 단어가 Helvetica Oblique 12pt로 서식이 적용된 것을 보여주고, "Document Styles"와 "Favorite Styles" 탭, "Add To Favorites", "Select", "Apply", "Done" 버튼이 있다. 두 UI 모두 스타일처럼 보이지만 *style* 개념의 핵심 기능(기존 스타일 수정 시 할당된 요소 일괄 변경)이 없어 진정한 *style* 개념이 아님을 설명하는 반례다.

- Apple color picker: 색상 수정 불가 → 운영 원칙 실패 → *style* 개념 아님
- Apple TextEdit의 "style": 스타일을 적용해도 단락에 지속적으로 연결되지 않음 → *style* 개념 아님

## 예시 3: reservation 개념

소프트웨어 이전부터 존재하는 *reservation* 개념.

**목적**: 한정된 자원의 효율적 사용을 관리한다.

**상태**:
- `available: set Resource`
- `reservations: User -> set Resource` (1:다 매핑)

**주요 행동**:
- `reserve(u, r)` — r이 available일 때, u에게 r을 예약
- `cancel(u, r)` — u의 r 예약 취소, r을 available로 반환
- `use(u, r)` — u가 예약한 r 사용

**운영 원칙**: `after reserve(u, r) and not cancel(u,r), can use(u, r)`

### 설계 이슈들

- 자원은 시간대에 종속될 수 있음 (레스토랑 좌석 예약)
- no-show 처리 — 계정 정지 등
- 충돌 예약 방지 (같은 날 밤 두 레스토랑 동시 예약)
- 철도 신호 시스템, 네트워크 RSVP 프로토콜에도 동일 개념 적용

## 개념의 제네릭성

개념 이름 옆의 타입 파라미터(예: `trash [Item]`)는 개념이 제네릭임을 나타낸다. *trash*의 Item은 파일 시스템에서는 파일, 이메일 클라이언트에서는 메시지가 된다. 제네릭성은:
- 재사용을 가능하게 한다
- 개념을 본질로 추출하도록 강제한다

## 핵심 인용

> "A concept definition includes its name, purpose, state, actions and operational principle. The operational principle, showing how the behavior fulfills the purpose, is the key to understanding a concept."

> "Most concepts in widespread use have undergone extensive development and refinement over time."

> "Concepts can be designed and understood independently of one another, simplifying software design by allowing a design to be broken into distinct subproblems."

## 관련 개념

- [[EOS-ch5-concept-purposes]] — 목적(purpose)에 대한 심층 논의
- [[EOS-ch6-concept-composition]] — 개념 조합과 동기화
- [[EOS-part3-principles]] — 특정성·친숙성·무결성 원칙
- [[EOS-overview]] — 전체 개요