---
title: "EOS Part I — 동기: 왜 개념 설계인가"
tags: [source, EOS]
source: "The Essence of Software, Daniel Jackson (2021)"
chapter: "Part I (Ch1–3)"
updated: 2026-04-30
---

# EOS Part I — 동기: 왜 개념 설계인가

## 핵심 아이디어

Part I(Ch1~3)은 왜 소프트웨어 설계의 핵심이 "개념"이어야 하는지를 동기 부여한다. Ch1은 저자의 연구 여정과 문제 의식을, Ch2는 구체적인 개념 예시와 설계 3 수준을, Ch3는 개념이 소프트웨어 설계 전반에서 수행하는 다양한 역할을 설명한다.

## Ch1 — Why I Wrote This Book

### 소프트웨어 설계의 공백

저자는 Alloy(소프트웨어 설계 언어·분석 도구) 연구자로서, 공식 명세보다 설계(design) 자체에 더 흥미를 느꼈다. 설계는 "형태(form)를 맥락(context)에 맞추는" 활동이다(Christopher Alexander).

소프트웨어 공학과 HCI(인간-컴퓨터 상호작용) 연구 모두 설계 자체보다 결함 제거·경험적 방법으로 이동했다. 결과적으로 소프트웨어 설계는 이론적 토대 없이 일화적 경험칙에 의존해 왔다.

### 명료함(Clarity)의 중요성

소프트웨어 개발 성패를 결정하는 것은 언어, 도구, 관리 방법론이 아니다. **무엇을 만들려고 하는지 명확히 아는 것**이다. 설계가 명확하면 코드도 명확하고, 문제도 명확히 진단된다.

### 개념의 기원

1960년대부터 "개념적 모델(conceptual model)"의 중요성은 인정받았다. 그러나 개념적 모델을 사용자의 멘탈 모델로 전달하는 것에만 집중했지, 그 자체를 설계 대상으로 다루지 않았다.

## Ch2 — Discovering Concepts

### 개념이란

> "A software product… is made of *concepts*, each a self-contained unit of functionality."

개념은 앱의 "분자"다. 화학 혼합물처럼 결합되지만, 각 개념의 속성과 행동은 어디에서나 동일하다.

### 예시 1: Backblaze 백업 개념의 오해

저자는 파일이 지속적으로 업로드·복원 가능하다고 가정했지만, 실제 Backblaze의 *backup* 개념은: (1) 주기적 스캔으로 변경 파일 목록 작성 → (2) 목록 기반 업로드 → (3) 스테이징 영역에서 복원 영역으로 이동의 세 단계를 거친다. 멘탈 모델과 실제 개념 간의 불일치가 혼란을 유발했다.

### 예시 2: Dropbox의 unix folder 개념

Dropbox는 이름(name)을 파일 자체의 메타데이터가 아닌, 부모 폴더의 항목(entry)에 귀속시키는 *unix folder* 개념을 사용한다. 이로 인해:
- 최상위 공유 폴더 이름 변경 → 본인에게만 변경
- 중첩 공유 폴더 이름 변경 → 모두에게 변경
- 삭제 시 동작도 이에 따라 달라짐

이것은 버그가 아니라 *개념 설계* 문제다.

### 설계의 3 수준

| 수준 | 내용 | 관심사 |
|------|------|--------|
| 물리(Physical) | 버튼, 레이아웃, 접근성 | 인간의 물리·인지 능력 |
| 언어(Linguistic) | 아이콘, 메시지, 용어 | 문화·언어적 차이 |
| 개념(Conceptual) | 행동과 상태의 본질 | 개념 구조의 설계 |

개념 수준이 가장 근원적이다. 언어·물리 수준의 문제처럼 보여도 사실 개념 수준의 결함인 경우가 많다.

### 멘탈 모델과 개념 설계

- 사용자의 멘탈 모델이 소프트웨어 실제 개념과 불일치할 때 사용성 문제가 생긴다.
- 해법은 사용자 교육이 아니라 **단순·유연·명확한 개념을 설계**하고, 사용자 인터페이스가 그 개념을 올바르게 표현하도록 하는 것이다.

## Ch3 — How Concepts Help

### 개념이 앱을 정의한다

앱을 설명하는 가장 좋은 방법은 핵심 개념을 나열하는 것이다. Facebook = *post* + *comment* + *like* + *friend*; Gmail = *email* + *label* + *conversation*; Web = *url* + *html* + *cache* + *bookmark*.

앱 간 차이도 개념으로 설명된다. 문자 메시지 앱은 *conversation* 개념을 쓰고, 이메일은 *mailbox*/*folder* 개념을 쓴다.

### 개념이 제품 차별화 요소

| 앱/서비스 | 핵심 차별화 개념 |
|-----------|-----------------|
| Apple Macintosh (1984) | *trash* — 삭제의 취소 |
| Photoshop | *layer* + *mask* — 비파괴 편집 |
| VisiCalc (스프레드시트) | *formula* + *reference* |
| Calendly | *event type* |
| World Wide Web | *url* — 전역 고유 명칭 |

### 개념이 복잡성을 드러낸다

Photoshop의 *layer*·*mask*, 브라우저의 *certificate*·*private browsing*·*page cache* 같은 복잡한 개념들이 무엇인지 알면, 파워 유저가 되기 위해 무엇을 배워야 하는지 명확해진다.

### 디지털 전환에서의 개념

디지털 전환의 핵심은 새 기술 도입이 아니라 **핵심 비즈니스 개념을 식별·통합·확장**하는 것이다. Apple의 *song* 개념처럼, 개념 하나가 전체 고객 경험을 통합할 수 있다.

### 개념이 관심사를 분리한다

*group* 하나에 모든 기능을 넣는 대신, *group*(멤버십) + *post*(메시지 작성) + *invitation*(초대) + *notification*(알림) + *moderation*(관리) 등으로 분리하면:
- 설계자가 한 번에 하나의 측면에 집중할 수 있다
- 팀원들이 병렬로 작업할 수 있다
- 각 개념을 독립적으로 재사용할 수 있다

### 개념이 안전·보안을 담보한다

보안 설계의 핵심은 *authentication*, *authorization*, *auditing* 등의 개념을 올바르게 설계하는 것이다. 예: two-factor authentication의 *capability* 개념과의 상호작용이 피싱 취약점을 만든다.

## 핵심 인용

> "Concepts characterize individual apps, app classes, and entire product families."

> "Investing in core concepts is less flashy but likely to be more effective."

> "Concepts are the essence of design for safety and security, where picking the right concepts and understanding their implications is paramount."

## 관련 개념

- [[EOS-overview]] — 전체 책 개요
- [[EOS-ch4-concept-structure]] — 개념 구조 정의 (Part II 시작)
- [[SDF-ch1-flexibility]] — SDF의 가산적 프로그래밍 철학과 비교