softwaredesign/wiki/sources/EOS-part1-motivations.md

---
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) 스테이징 영역에서 복원 영역으로 이동의 세 단계를 거친다. 멘탈 모델과 실제 개념 간의 불일치가 혼란을 유발했다.

> **fig. 2.1** (*Backblaze's backup concept. On the left, what I assumed: (1) I make a change to a file; (2) when the backup runs, the file is copied to the cloud; (3) I can then restore it. On the right, what actually happens: (1) I make a change to a file; (2) a scan runs and adds the file to a list of files for backup; (3) the backup runs, copying to the cloud only those files that were added in the last scan; (4) periodically, backed-up files are moved to a cloud location (5) from where they can be restored.*): 왼쪽 다이어그램은 사용자가 기대하는 단순 2단계 흐름(변경→클라우드→복원)을 보여주고, 오른쪽은 실제 5단계 흐름(변경→스캔→업로드→스테이징→복원)을 보여준다. 두 흐름 간의 괴리가 Backblaze *backup* 개념의 핵심 설계 문제를 시각화한다. 멘탈 모델과 실제 개념이 일치하지 않을 때 사용자가 겪는 혼란의 구조적 원인을 이 다이어그램 하나로 명확히 설명한다.

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

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

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

> **fig. 2.2** (*Sharing a folder in Dropbox. Ava (AA) has shared the folder named Bella Party with Bella (BB). If Bella now changes the name of the folder, will Ava see the change?*): Dropbox UI 스크린샷으로, 위쪽은 Ava(AA) 계정, 아래쪽은 Bella(BB) 계정에서 "Bella Party" 공유 폴더가 "2 members"로 표시된 모습. 동일한 폴더를 두 사용자가 각각의 뷰에서 보고 있음을 보여준다. 이름 변경 시 누구에게 어떻게 전파되는지가 *unix folder* 개념의 핵심 설계 문제임을 이 화면이 예시한다.

> **fig. 2.3** (*Dropbox's folder deletion messages. The folder Bella Party has been shared (top). If that folder is deleted, the message (middle) informs you that the deletion will not be propagated to other users. If the folder Bella Plan contained within it is deleted, a different message (bottom) appears, surprisingly not warning that other users will lose the folder too.*): 위쪽에는 Bella Party 폴더 안에 Bella Plan이 있는 Dropbox UI, 중간에는 "Remove shared folder?" 다이얼로그("다른 멤버에게는 공유가 유지됨" 안내), 아래에는 "Delete folder?" 다이얼로그("Bella Plan을 shared folder 'Bella Party'에서 삭제할까요?" — 다른 사용자가 잃는다는 경고 없음). 역설적으로 영향이 큰 삭제(공유 폴더 내 파일)에서 오히려 경고가 약하다는 개념 설계 결함을 보여준다.

> **fig. 2.4** (*Two possible concepts for folders in Dropbox: in the metadata concept (left), names are labels attached to folders; in the unix folder concept (right), names belong to entries within the parent folder.*): 왼쪽(metadata 개념)에서는 Bella Party, Bella Plan 폴더가 각각 독립적인 이름 레이블을 갖고 Ava와 Bella의 Dropbox에 연결된다. 오른쪽(unix folder 개념)에서는 Ava Dropbox와 Bella Dropbox 최상위 폴더 안에 "Bella Party"라는 항목(entry)이 각각 별도로 존재하고, 그 안의 "Bella Plan" 항목은 공유된 단일 폴더 내에 하나만 있다. 이 구조 차이가 이름 변경과 삭제 동작의 비대칭성을 설명한다.

> **fig. E.1** (*MIT CS 학부생 Dropbox 이해도 조사*): 두 문제("공유 폴더 삭제", "중첩 공유 폴더 삭제")에 대한 정답률을 우수/평균/미흡 그룹별 막대 그래프로 비교. "공유 폴더 삭제": 우수 ~58%, 평균 ~32%, 미흡 0%. "중첩 공유 폴더 삭제": 우수 ~70%, 평균 ~77%, 미흡 ~44%. 역설적으로 중첩 삭제 이해도는 평균 그룹이 가장 높음 — Dropbox의 unix folder 개념이 전문가에게도 직관에 반함을 보여주는 실증 데이터.

> **fig. E.2** (*공유 폴더 삭제 후 Dropbox 앱 경고 메시지*): "You deleted 'Bella Plan' from everyone's account and all devices. If you change your mind, you can move it out of your Trash or restore recently deleted files on dropbox.com." [Don't tell me again 체크박스] [Restore on web] [OK]. 삭제 *후* 표시되는 사후 경고 — 이미 삭제가 실행된 상태. 사전 경고 없이 공유 폴더 삭제가 즉시 적용되는 개념 설계 결함의 증거.

### 설계의 3 수준

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

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

> **fig. 2.7** (*A design issue at the linguistic level: inconsistent interpretation of icons in Google apps and how new icons fixed the problem. On the left, the original icons for opening apps and switching to grid view; on the right the new icons for the same actions, now distinguished.*): 왼쪽의 두 아이콘은 9개의 검정 사각형 배열(Google Apps 메뉴)과 4개의 흰 테두리 사각형 배열(Grid view)로, 시각적으로 매우 유사해 사용자가 두 기능을 혼동하기 쉽다. 오른쪽의 개선된 아이콘은 Google Apps는 9개의 회색 원 배열로, Grid view는 테두리가 있는 6개의 사각형 격자로 명확히 구분된다. 이 변경은 언어(Linguistic) 수준에서 아이콘 일관성 원칙 위반을 수정한 사례다 — 동일한 시각 언어(검정 사각형 격자)가 두 개의 다른 기능에 사용되던 문제를 해소했다.

> **fig. 2.5** (*Levels of interaction design.*): 세 수준을 나란히 아이콘으로 표현: 물리(Physical) = 다 빈치 비트루비우스 인체 그림 + "color, size, layout, type, touch, sound", 언어(Linguistic) = 공사 중 도로 표지판 + "icons, labels, tooltips, site structure", 개념(Conceptual) = 전구 아이콘 + "semantics, actions, data model, purpose". 왼쪽에서 오른쪽으로 "concrete → abstract" 스펙트럼이 표시돼 있어, 세 수준이 구체성에서 추상성으로 이어지는 계층임을 직관적으로 보여준다.

> **fig. 2.6** (*A design issue at the physical level, and a classic example of applying Fitts's Law. Which menu placement allows for more convenient access: the macOS placement (on the left) in which an application's menu bar always appears at the top of the desktop, or the Windows placement (on the right) in which the menu bar is part of the application window?*): 왼쪽은 macOS TextEdit의 메뉴 바가 화면 맨 위 고정된 모습, 오른쪽은 Windows Notepad의 메뉴 바가 앱 창 안에 있는 모습. Fitts의 법칙에 따르면 화면 상단 모서리에 무한히 넓은 영역처럼 작동하는 macOS 방식이 클릭하기 더 빠르다. 물리 수준 설계 원칙이 실제 사용성에 미치는 영향을 보여주는 고전적 예시다.

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

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

> **fig. 2.8** (*The central role of concepts (left) in aligning the user's mental model (top right) and the developer's design model embodied in the code (bottom right). By mapping the concepts carefully to the user interface (middle right), the concepts are not only fully supported but also conveyed implicitly to the user.*): 왼쪽에는 Bella Party/Bella Plan 폴더 구조를 나타내는 "underlying concepts" 다이어그램이, 오른쪽 상단에는 사용자 아이콘("mental model"), 중간에는 Dropbox UI 스크린샷("user interface"), 하단에는 inode 구조체 C 코드("implementation")가 배치돼 있다. 세 요소를 연결하는 점선 화살표가 개념이 중심 매개체로 작동함을 보여준다 — 개념이 사용자의 멘탈 모델, UI, 코드 구현 모두를 정렬하는 핵심 고리라는 Ch2의 핵심 주장을 시각화한다.

## Ch3 — How Concepts Help

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

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

> **fig. 3.1** (*A screenshot of Facebook in which three concepts are evident: post (represented by the message and the associated image), like (represented by the emoticons at the bottom left), and comment (represented by the link on the bottom right).*): Facebook 피드의 단일 게시물 스크린샷으로, Kristin Rehder가 올린 안개 낀 숲 사진이 표시돼 있다. 게시물 하단 왼쪽의 "You and 39 others" 좋아요 이모티콘이 *like* 개념을, 하단 오른쪽의 "3 Comments" 링크가 *comment* 개념을, 게시물 전체(텍스트+이미지 조합)가 *post* 개념을 나타낸다. 하나의 UI 화면에서 세 가지 독립적인 개념이 동시에 식별된다는 점이 "앱은 개념의 조합"이라는 논지를 구체적으로 예시한다.

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

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

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

> **fig. 3.3** (*The text flow concept, in Adobe InDesign, showing this very page spread and its flows. The diagonal lines show the links between the text boxes that comprise a single flow.*): 책의 두 페이지(32–33쪽)를 InDesign 작업 화면으로 보여주는 스크린샷으로, 왼쪽 페이지에는 텍스트 박스들 사이를 잇는 대각선이 표시돼 있다. 이 대각선들이 *text flow* 개념에서 말하는 "연결된 텍스트 박스 체인"을 시각화한다 — 텍스트가 한 박스에서 다른 박스로 자동으로 흘러들어가는 구조다. 오른쪽 페이지에는 Photoshop Layers 패널이 보여, fig. 3.4의 *layer*+*mask* 개념도 같은 페이지 펼침에 담겨 있음을 보여준다.

> **fig. 3.4** (*Layer and mask concepts in Photoshop; an adjustment layer has been added to darken the image, along with a mask that restricts the darkening to the area of the sky.*): 해변에서 뒤돌아 선 여성을 찍은 흑백 사진 위에 Photoshop Layers 패널이 오버레이된 스크린샷. 패널에는 Background 레이어 위에 Levels 레이어, 그 위에 Brightness/Contrast 레이어가 쌓여 있고, 각 레이어에 흑백 마스크 썸네일이 표시돼 있다. 원본 이미지를 직접 수정하지 않고 조정 레이어와 마스크를 추가하여 편집하는 비파괴 편집 구조가 *layer*와 *mask* 개념의 조합으로 구현됨을 보여준다.

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

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

> **fig. 3.5** (*Labels in Gmail. I've entered a search query to show messages with no user-defined labels, but the first item seems to carry such labels ("hacking" and "meetups"). The explanation is that Gmail shows all conversations that contain messages satisfying the query, along with any labels attached to their messages. So a conversation containing one message without labels, and another message with labels, will appear in this search.*): Gmail 검색 결과 화면으로, "has:nouserlabels" 쿼리를 입력했음에도 첫 번째 결과 항목에 "hacking"과 "meetups" 레이블이 표시되어 있다. 이는 Gmail이 *label*을 개별 메시지에, *conversation* 표시를 대화 단위에 적용하기 때문에 발생하는 불일치다 — 레이블 없는 메시지를 검색해도 같은 대화의 다른 메시지에 레이블이 붙어 있으면 그 대화 전체가 결과에 나타난다. 개념의 복잡성이 검색 동작에서 직관에 반하는 결과를 낳는 실제 사례다.

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

디지털 전환의 핵심은 새 기술 도입이 아니라 **핵심 비즈니스 개념을 식별·통합·확장**하는 것이다. 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의 가산적 프로그래밍 철학과 비교