---
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* 개념.

**목적**: 삭제의 취소(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'로 변경된다.

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