feat: Essence of Software wiki 컴파일 + raw 원본 추가
raw/book/EssenceOfSoftware_Eng/ — Daniel Jackson (2021) 원본 11개 폴더 추가 wiki/sources/ EOS 챕터별 한국어 페이지 8개: - EOS-overview: 전체 개요, 설계 3수준, 핵심 원칙 - EOS-part1: Ch1-3 동기 (Backblaze/Dropbox 사례, 개념 역할) - EOS-ch4: 개념 구조 (5요소: 이름·목적·상태·행동·운영 원칙) - EOS-ch5: 개념 목적 (좋은 목적 4기준, 미스피트 사례) - EOS-ch6: 개념 조합 (동기화, 시너지, 과잉/과소 동기화) - EOS-ch7: 개념 의존 (의존 다이어그램, 제네릭 개념) - EOS-ch8: 개념 매핑 (다크 패턴, UI 매핑 딜레마) - EOS-part3: 원칙 Ch9-11 (특정성·친숙성·무결성) wiki/index.md Sources 섹션 EOS 8개 등록, wiki/log.md 기록 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
minsung
118
wiki/sources/EOS-ch4-concept-structure.md
Normal file
118
wiki/sources/EOS-ch4-concept-structure.md
Normal file
@@ -0,0 +1,118 @@
|
||||
---
|
||||
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]] — 전체 개요
|
||||
95
wiki/sources/EOS-ch5-concept-purposes.md
Normal file
95
wiki/sources/EOS-ch5-concept-purposes.md
Normal file
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: "EOS Ch5 — 개념의 목적"
|
||||
tags: [source, EOS]
|
||||
source: "The Essence of Software, Daniel Jackson (2021)"
|
||||
chapter: "Ch5 Concept Purposes"
|
||||
updated: 2026-04-30
|
||||
---
|
||||
|
||||
# EOS Ch5 — 개념의 목적
|
||||
|
||||
## 핵심 아이디어
|
||||
|
||||
모든 개념에는 명확한 목적(purpose)이 있어야 한다. 목적은 개념의 설계를 정당화하고, 사용자가 개념을 배울 수 있게 하며, 개념이 제대로 동작하는지 평가하는 기준이 된다. 목적이 불명확하거나 없거나 사용자에게 숨겨진 경우, 개념은 혼란·오용·악용의 원인이 된다. "미스피트(misfit)"는 개념이 맥락에서 목적을 충족하지 못하는 현상이다.
|
||||
|
||||
## 좋은 목적의 기준 4가지
|
||||
|
||||
| 기준 | 설명 |
|
||||
|------|------|
|
||||
| **Cogent (명확)** | 사용자의 이해 가능한 필요를 명확히 표현해야 한다 |
|
||||
| **Need-focused (필요 중심)** | 행동 자체가 아닌 사용자의 필요를 표현해야 한다 |
|
||||
| **Specific (구체적)** | 다른 개념과 구별될 만큼 구체적이어야 한다 |
|
||||
| **Evaluable (평가 가능)** | 운영 원칙이 이 목적을 충족하는지 판단 가능해야 한다 |
|
||||
|
||||
**나쁜 예**: bookmark의 목적 = "페이지를 저장하다" (행동 반복)
|
||||
**좋은 예**: bookmark의 목적 = "나중에 페이지를 쉽게 재방문하기 위해"
|
||||
|
||||
## 목적이 설계 퍼즐을 해결한다: 통화 전환
|
||||
|
||||
*call forwarding* 개념 설계 문제: A→B, B→C로 전환 설정 시 A에 온 전화는 B에 가는가, C에 가는가?
|
||||
|
||||
목적을 분리하면 두 개의 다른 개념임이 드러난다:
|
||||
- **delegate forwarding**: "다른 사람에게 전화를 위임한다" — A→B→C로 두 단계 전환 (연쇄 적용)
|
||||
- **follow-me forwarding**: "내가 다른 장소로 이동했다" — A에서 B 위치로만 전환 (단일 전환)
|
||||
|
||||
하나의 개념에 두 목적을 섞으면 불합리한 동작이 나온다.
|
||||
|
||||
## 목적 없는 개념
|
||||
|
||||
### 수도꼭지 비유
|
||||
|
||||
구식 혼합 수도꼭지(온수·냉수 별도 손잡이): 각 손잡이에 명확한 목적이 없다. 사용자가 원하는 것은 온도와 수량의 조절인데, 두 손잡이는 그 필요에 직접 대응하지 않는다.
|
||||
|
||||
신식 단일 손잡이: 회전 = 온도, 상하 = 수량. 목적과 제어가 1:1 대응한다.
|
||||
|
||||
### 에디터 버퍼
|
||||
|
||||
*editor buffer* 개념: 메모리에 텍스트를 유지하다가 저장 명령으로 디스크에 씀. 이 개념의 목적은 사용자가 아닌 구현의 필요에서 비롯됐다. Apple은 OS X Lion(2011)에서 이 개념을 제거했다. "저장"은 이제 파일에 이름을 붙이는 것이 됐고, "다른 이름으로 저장"도 사라졌다.
|
||||
|
||||
**원칙**: 개념은 내부 구현 메커니즘이 아닌 사용자 필요에서 비롯되어야 한다.
|
||||
|
||||
## 목적이 불명확한 개념: Twitter의 favorite
|
||||
|
||||
Twitter의 *favorite* 개념 문제: 사용자들이 개념을 "나중에 볼 트윗 저장"으로 잘못 이해했다. 실제 목적은 "공개적으로 승인 표시"(like/upvote에 해당). 2018년 Twitter는:
|
||||
- *favorite* → *like*로 이름 변경 (목적과 일치)
|
||||
- *bookmark* 개념 신규 도입 (사적 저장 목적)
|
||||
|
||||
## 기만적 목적: Nanny Scam
|
||||
|
||||
*available funds* 개념과 *cleared check* 개념이 혼동됨. 은행 앱이 수표 처리 전에 일부 금액을 "사용 가능"으로 표시하는 것은 의회 법령에 따른 것인데, 사용자들은 이를 "수표가 청산됐다"고 오해한다. 사기꾼들은 이 개념 오해를 악용해 먼저 "수표 받기" → "초과분 반환 요청" → 수표 부도로 피해를 입힌다.
|
||||
|
||||
## 분명한 목적을 숨기는 설계들
|
||||
|
||||
| 앱/개념 | 표명된 목적 | 실제 목적 |
|
||||
|---------|-----------|-----------|
|
||||
| Facebook *notification* | 사용자에게 알림 | 사용자 참여(engagement) 증가 |
|
||||
| Facebook *tag* | 게시물 검색 편의 | 소셜 그래프 확장 |
|
||||
| Quora 로그인 강제 | "커뮤니티 기여" | 사용자 데이터 수집·광고 타겟팅 |
|
||||
| Direct flight 개념 | 편의성 | 예약 시스템 검색 우선 노출 |
|
||||
|
||||
## 미스피트(Misfits): 목적이 실현되지 않을 때
|
||||
|
||||
소프트웨어 설계는 "형태(form)"를 "맥락(context)"에 맞추는 것이다. 미스피트는 이 맞춤이 실패하는 지점이다. 미스피트는 예측하기 어렵다:
|
||||
|
||||
1. **설계 결함으로 인한 미스피트**: PLGR GPS 기기 — 배터리 교체 후 재부팅 시 좌표가 기기 자신의 위치로 리셋됨 → 오폭 사고. *battery* 개념과 *target* 개념의 상호작용을 설계 시 고려했다면 방지 가능했다.
|
||||
|
||||
2. **맥락 변화로 인한 미스피트**: 팬데믹으로 화상 회의가 일반화되자, *slideshow* 개념의 전체 화면 모드가 화상 회의 앱의 패널을 가리는 문제 발생. Apple Keynote는 "창 모드로 재생" 옵션 추가로 해결.
|
||||
|
||||
3. **구버전에서 작동했던 것이 다시 안 됨**: Apple Numbers의 *range* 개념 — 구버전은 범위 마지막 행 아래에 행 추가 시 범위에 포함됐지만, 새 버전에서는 포함되지 않아 실무에 큰 불편. Microsoft Excel도 동일한 결함.
|
||||
|
||||
**교훈**: 개념 카탈로그에 설계 통찰을 기록해야 버전 업데이트 시 지식이 유실되지 않는다.
|
||||
|
||||
## 핵심 인용
|
||||
|
||||
> "Purposes matter in all aspects of life because they help us set direction, explain ourselves to others, and reach consensus in collaborations."
|
||||
|
||||
> "In software especially, with its capacity for boundless complexity, it's easy to get mired in details and lose track of the big picture. Thinking about purposes helps you draw back and regain your bearings."
|
||||
|
||||
> "Concepts, unlike internal mechanisms, are always user-facing, and must have purposes that make sense not only to the programmer but also to the user."
|
||||
|
||||
## 관련 개념
|
||||
|
||||
- [[EOS-ch4-concept-structure]] — 개념 구조 (purpose가 5요소 중 하나)
|
||||
- [[EOS-part3-principles]] — Ch9 특정성: 목적과 개념의 1:1 대응
|
||||
- [[EOS-ch6-concept-composition]] — 목적 단위로 개념을 분리하면 조합이 쉬워짐
|
||||
- [[EOS-overview]] — 전체 개요
|
||||
136
wiki/sources/EOS-ch6-concept-composition.md
Normal file
136
wiki/sources/EOS-ch6-concept-composition.md
Normal file
@@ -0,0 +1,136 @@
|
||||
---
|
||||
title: "EOS Ch6 — 개념의 조합"
|
||||
tags: [source, EOS]
|
||||
source: "The Essence of Software, Daniel Jackson (2021)"
|
||||
chapter: "Ch6 Concept Composition"
|
||||
updated: 2026-04-30
|
||||
---
|
||||
|
||||
# EOS Ch6 — 개념의 조합
|
||||
|
||||
## 핵심 아이디어
|
||||
|
||||
소프트웨어 앱은 다수의 개념이 조합된 것이다. 개념들은 기본적으로 독립적으로 실행되다가 **동기화(synchronization)**를 통해 연결된다. 동기화는 실행 가능한 동작의 범위를 제한(제거)할 뿐 새로운 동작을 추가하지 않는다. Jackson은 자유 조합·협력 조합·시너지 조합의 세 단계를 구분하며, 과잉·과소 동기화의 위험을 실제 사례로 보여준다.
|
||||
|
||||
## 전통적 조합이 개념에 맞지 않는 이유
|
||||
|
||||
전통적 소프트웨어 컴포넌트는 클라이언트-서비스 형태로 조합된다. 그러나 개념은:
|
||||
- 정의상 **사용자를 향한다** — 한 개념이 다른 개념 뒤에 숨을 수 없다
|
||||
- **자기완결적이어야 한다** — 다른 개념의 내부에 의존하면 독립적 이해와 재사용이 불가능해진다
|
||||
|
||||
## 개념 조합의 메커니즘
|
||||
|
||||
개념들은 기본적으로 독립 실행된다(역 순서로 인터리빙 허용). 동기화(sync)는 한 개념의 행동이 발생할 때 다른 개념의 행동도 함께 발생하도록 묶는다.
|
||||
|
||||
**핵심 성질**: 동기화는 기존 실행 시퀀스를 _제거_만 할 뿐 _추가_하지 않는다.
|
||||
|
||||
## 조합의 3가지 유형
|
||||
|
||||
### 1. 자유 조합(Free Composition)
|
||||
|
||||
개념들이 대부분 독립적으로 동작하며, 최소한의 동기화(주로 데이터 일관성 유지용)만 존재.
|
||||
|
||||
**예시**: Todoist의 *todo* + *label* 조합
|
||||
|
||||
```
|
||||
app todo-label
|
||||
include
|
||||
todo
|
||||
label [todo.Task]
|
||||
sync todo.delete (t)
|
||||
label.clear (t)
|
||||
```
|
||||
|
||||
동기화 하나: 태스크 삭제 시 해당 태스크의 레이블도 자동 제거. 이 동기화가 없으면, 삭제된 태스크가 레이블 검색 결과에 나타나는 이상 동작이 발생한다.
|
||||
|
||||
**"존재 결합(existence coupling)"**: 두 개념이 동일한 객체 집합을 참조한다는 사실만 공유. 나머지는 완전히 독립.
|
||||
|
||||
### 2. 협력 조합(Collaborative Composition)
|
||||
|
||||
동기화가 두 개념을 연결해 어느 개념도 홀로 제공하지 못했던 새 기능을 만든다.
|
||||
|
||||
**예시**: Todoist의 이메일 주소로 태스크 추가
|
||||
|
||||
```
|
||||
app todo-label-mail
|
||||
include
|
||||
todo
|
||||
label [todo.Task]
|
||||
email
|
||||
sync todo.delete (t)
|
||||
label.clear (t)
|
||||
sync email.receive (todo-user, m)
|
||||
todo.add (m.content)
|
||||
```
|
||||
|
||||
*email* 개념의 `receive` 행동과 *todo* 개념의 `add` 행동이 동기화돼, 특정 이메일 주소로 메일을 보내면 자동으로 태스크가 추가된다.
|
||||
|
||||
**협력 조합의 활용 패턴**:
|
||||
- **Logging**: 이벤트 추적 개념과 다른 개념 조합
|
||||
- **Suppression**: 접근 제어 개념이 특정 행동을 차단
|
||||
- **Staging**: 연락처 → 전화번호 → 전화 연결 등 단계 분리
|
||||
- **Notification**: 이벤트 발생 시 알림 트리거
|
||||
- **Mitigation**: 허용되지 않는 동작 방지
|
||||
- **Inference**: 명시적 행동 대신 다른 행동에서 추론(예: 메시지 열면 "읽음" 자동 처리)
|
||||
|
||||
### 3. 시너지 조합(Synergistic Composition)
|
||||
|
||||
더 촘촘한 동기화를 통해 한 개념의 기능이 다른 개념의 목적 달성을 도와 전체 가치가 부품의 합을 초과한다.
|
||||
|
||||
**예시 1**: *todo* + *label* 시너지 — `pending` 레이블을 내장 레이블로 사용
|
||||
|
||||
```
|
||||
sync todo.add (t)
|
||||
label.affix (t, 'pending')
|
||||
sync todo.complete (t)
|
||||
label.detach (t, 'pending')
|
||||
sync label.detach (t, 'pending')
|
||||
todo.complete (t)
|
||||
```
|
||||
|
||||
이제 레이블 쿼리 언어로 "pending AND urgent" 같은 복합 조회가 가능해진다.
|
||||
|
||||
**예시 2**: Gmail의 *label* + *trash* 시너지 — 삭제 시 *deleted* 레이블 자동 부착, 레이블 제거 시 복원.
|
||||
|
||||
**예시 3**: Macintosh의 *trash* + *folder* 시너지 — trash가 folder의 인스턴스로 작동해:
|
||||
- 별도 목록 인터페이스 불필요 (folder의 정렬·검색 재사용)
|
||||
- 복원은 단순히 trash 폴더에서 파일을 꺼내는 것
|
||||
- "date added" 정렬 기능이 삭제 날짜 정렬로 자연스럽게 동작
|
||||
|
||||
**시너지는 완전하지 않다**: trash 폴더는 일반 폴더와 달리 `empty` 버튼이 있고, 여러 볼륨의 파일을 한 폴더에 담는 특수성도 있다.
|
||||
|
||||
## 과잉 동기화(Over-Synchronization)
|
||||
|
||||
동기화가 너무 많으면 사용자의 제어권이 줄어든다.
|
||||
|
||||
**사례 1**: Apple Calendar — 이벤트 삭제 시 초대 거절 알림이 자동 발송됨. 스팸 이벤트 삭제 시 스패머에게 이메일 주소 유효성을 알려주는 역효과. (2017년 수정됨)
|
||||
|
||||
**사례 2**: Tumblr — 게시물 제목 끝에 `?`를 붙이면 자동으로 댓글이 활성화됨.
|
||||
|
||||
**사례 3**: Therac-25 방사선 치료기 — 전자빔 전류 값과 평탄화 필터 위치 동기화 결함으로 과다 조사 사망 사고 발생.
|
||||
|
||||
## 과소 동기화(Under-Synchronization)
|
||||
|
||||
동기화가 부족하면 사용자에게 불필요한 작업을 떠넘기거나 위험한 동작이 허용된다.
|
||||
|
||||
**사례 1**: Google Groups — "가입 허용" 설정과 "그룹 디렉토리 공개" 설정이 연동되지 않아, 가입 요청 페이지 자체에 접근이 불가능했음.
|
||||
|
||||
**사례 2**: Adobe Lightroom 6.2 — 전문 사진가들이 의존하던 가져오기 동기화 옵션을 제거. 사용자 반발로 업데이트 롤백.
|
||||
|
||||
**사례 3**: Zoom — 손 든 참가자가 발언 후 마이크를 껐을 때 손이 자동으로 내려가지 않음 → 손 올린 상태 방치 → 혼란.
|
||||
|
||||
## 핵심 인용
|
||||
|
||||
> "Synchronization is an essential part of software design. Not enough synchronization can lead to inappropriate or confusing behaviors, and miss opportunities for automation; too much can limit the user's options."
|
||||
|
||||
> "Composition offers an opportunity for creative design even when the concepts themselves are familiar. Synergy is often the very essence of a design, bringing unexpected power from the combination of simple parts."
|
||||
|
||||
> "Automation doesn't do new things that you could not previously have done manually; it just makes them inevitable."
|
||||
|
||||
## 관련 개념
|
||||
|
||||
- [[EOS-ch4-concept-structure]] — 개념 구조 (조합 전에 각 개념이 독립적으로 정의됨)
|
||||
- [[EOS-ch7-concept-dependence]] — 조합 내에서 개념들 간의 의존 구조
|
||||
- [[EOS-ch8-concept-mapping]] — 조합된 개념들을 UI에 매핑하는 문제
|
||||
- [[EOS-part3-principles]] — Ch11 무결성: 조합 시 각 개념 명세 유지
|
||||
- [[EOS-overview]] — 전체 개요
|
||||
129
wiki/sources/EOS-ch7-concept-dependence.md
Normal file
129
wiki/sources/EOS-ch7-concept-dependence.md
Normal file
@@ -0,0 +1,129 @@
|
||||
---
|
||||
title: "EOS Ch7 — 개념의 의존"
|
||||
tags: [source, EOS]
|
||||
source: "The Essence of Software, Daniel Jackson (2021)"
|
||||
chapter: "Ch7 Concept Dependence"
|
||||
updated: 2026-04-30
|
||||
---
|
||||
|
||||
# EOS Ch7 — 개념의 의존
|
||||
|
||||
## 핵심 아이디어
|
||||
|
||||
개념들은 본질적으로 독립적이지만, 앱의 맥락 안에서는 **의존(dependence)** 관계가 발생한다. A 개념이 없다면 B 개념을 포함할 이유가 없을 때, "B는 A에 의존한다"고 말한다. 의존 관계를 다이어그램으로 표현하면 앱의 구조를 한눈에 파악하고, 설계·구현·설명의 순서를 결정하는 데 도움이 된다.
|
||||
|
||||
## 개념 독립성 vs. 앱 내 의존성
|
||||
|
||||
모순처럼 보이지만 실제 모순이 아니다:
|
||||
- **개념 독립성**: 각 개념은 다른 개념 없이도 이해·구현 가능하다
|
||||
- **앱 내 의존성**: 특정 앱에서 어떤 개념을 포함할 근거는 다른 개념의 존재에서 비롯된다
|
||||
|
||||
의존성은 개념 자체의 속성이 아니라 **앱 설계 결정의 결과**다.
|
||||
|
||||
## 의존 다이어그램(Dependence Diagram)
|
||||
|
||||
의존 다이어그램은:
|
||||
- 각 개념을 노드로 표현
|
||||
- 한 개념이 다른 개념에 의존하면 화살표로 연결
|
||||
- **주 의존(primary)**: 실선 화살표 — 가장 핵심적인 의존
|
||||
- **부 의존(secondary)**: 점선 화살표 — 부가적 의존
|
||||
|
||||
## BirdSong 앱 예시
|
||||
|
||||
새 울음소리로 새 종을 식별하는 앱 설계:
|
||||
|
||||
**핵심 개념들**:
|
||||
- *q&a*: 커뮤니티가 질문에 답변하도록 지원
|
||||
- *recording*: 오디오 파일 업로드 허용
|
||||
- *upvote*: 개인 평가로 기여도 순위 결정
|
||||
- *identification*: 크라우드소싱 기반 객체-카테고리 할당
|
||||
- *user*: 콘텐츠와 행동 인증
|
||||
|
||||
**의존 구조**:
|
||||
- *upvote* → *q&a* (주): 업보트할 대상(답변)이 있어야 한다
|
||||
- *user* → *q&a* (주): 질문·답변 작성자 인증이 핵심
|
||||
- *user* → *upvote* (부): 이중 투표 방지에도 활용 가능
|
||||
- *recording* → *q&a*: 오디오를 질문에 첨부
|
||||
- *identification* → *recording*: 식별 결과를 녹음과 연결
|
||||
|
||||
**다이어그램이 주는 것들**:
|
||||
|
||||
1. **핵심 개념 식별**: *q&a*는 모든 개념이 직·간접으로 의존. 없으면 앱 자체가 불가능
|
||||
2. **일관된 부분집합**: 의존 화살표가 집합 밖으로 나가지 않는 부분집합만 독립 앱 가능
|
||||
- 가능: {*q&a*, *recording*, *upvote*}
|
||||
- 불가능: {*identification*, *q&a*} — *identification*이 *recording*에 의존하므로
|
||||
3. **개발 단계화**: 일관된 부분집합 순으로 구현하면 언제나 테스트 가능한 상태 유지
|
||||
4. **설명 순서**: 의존 방향대로 설명해야 개념 도입이 자연스럽다
|
||||
- 좋은 순서: *q&a* → *upvote* → *user* → *recording* → *identification*
|
||||
- 나쁜 순서: *upvote* 먼저 → 업보트할 대상이 없어 설명 불가
|
||||
|
||||
## 실제 앱 구조 분석
|
||||
|
||||
### Facebook
|
||||
|
||||
핵심 구조:
|
||||
- *post* (기반 개념)
|
||||
- *comment* → *post*
|
||||
- *reply* → *comment*
|
||||
- *user* → *post* (주), *comment*, *reply*, *tag*, *like* (부)
|
||||
- *friend* → *user* + *post* (포스트 접근 제어 + 사용자 인증 필요)
|
||||
- *tag* → *user* + *post*
|
||||
- *like* → *post* (주), *comment*, *reply* (부)
|
||||
|
||||
### Apple Safari
|
||||
|
||||
핵심 구조:
|
||||
- *url* (기반 개념 — 중앙)
|
||||
- *html* → *url*
|
||||
- *cache* → *url* (속도 향상)
|
||||
- *certificate* → *url* (서버 인증)
|
||||
- *cookie* → *url*
|
||||
- *private browsing* → *cookie*
|
||||
- *bookmark*, *favorite*, *frequently visited*, *reading list* → *url* (상단)
|
||||
|
||||
**Safari 분석 통찰**: bookmark 변형 개념들(*favorite*, *frequently visited*, *reading list*)이 서로 매우 유사하다. 오프라인 읽기와 읽음 표시를 모든 bookmark에 추가하고, 자주 방문한 사이트를 일반 bookmark 폴더로 통합하면 더 시너지적 설계가 가능하다.
|
||||
|
||||
### Apple Keynote
|
||||
|
||||
핵심 구조:
|
||||
- *slide* (기반)
|
||||
- *special block* → *slide*: 제목·본문·슬라이드 번호
|
||||
- *text block* + *shape* → *slide*
|
||||
- *paragraph* → *text block*
|
||||
- *text style* + *shape style*: *style* 개념 인스턴스
|
||||
- *master* → *special block* (기본 서식 제공)
|
||||
- *theme* → *master* + *text style* (스타일 모음)
|
||||
- *layer* → *shape* + *text block*
|
||||
- *animation* → *special block* (주) + *shape*, *text block* (부)
|
||||
|
||||
## 제네릭 개념의 중요성
|
||||
|
||||
의존 다이어그램은 개념들이 **제네릭**으로 표현될 때 가장 유용하다. BirdSong 앱에서 *upvote*는 "새 소리 답변에 좋아요"가 아니라 "기여도에 대한 개인 평가"로 일반화돼야 다른 앱에서도 재사용 가능하다. 제네릭 표현:
|
||||
- 설계 지식의 재사용을 가능하게 한다
|
||||
- 과도한 도메인 특화를 방지해 설계를 단순하게 유지한다
|
||||
|
||||
## 점진적 성장(Growing the Product)
|
||||
|
||||
의존 다이어그램은 앱을 점진적으로 성장시키는 로드맵이다:
|
||||
- **추가**: 새 개념 + 의존 관계 추가
|
||||
- **제거**: 예상보다 덜 유용하거나 결함이 심한 개념 제거
|
||||
- **정제**: 기존 개념 개선
|
||||
- **시너지 발견**: 기존 조합에서 새 가치 도출
|
||||
|
||||
Fred Brooks의 "second-system effect" 경고: 작지만 성공적인 시스템을 대규모로 재설계할 때 과신이 비대하고 불필요하게 복잡한 결과를 낳는다.
|
||||
|
||||
## 핵심 인용
|
||||
|
||||
> "Concepts are freestanding, and independent of one another: a concept can be understood, designed and implemented by itself."
|
||||
|
||||
> "In the context of a software product, dependencies arise—not that one concept relies on another for its correct operation, but because inclusion of one concept may make sense only if another is present."
|
||||
|
||||
> "The dependence diagram gives a succinct summary of a product's concepts and the motivations for including them."
|
||||
|
||||
## 관련 개념
|
||||
|
||||
- [[EOS-ch6-concept-composition]] — 개념 조합의 메커니즘
|
||||
- [[EOS-ch8-concept-mapping]] — 의존 구조가 UI 설계에 주는 시사점
|
||||
- [[EOS-ch4-concept-structure]] — 개념 구조 (독립성의 토대)
|
||||
- [[EOS-part3-principles]] — 특정성·친숙성·무결성 원칙
|
||||
- [[EOS-overview]] — 전체 개요
|
||||
101
wiki/sources/EOS-ch8-concept-mapping.md
Normal file
101
wiki/sources/EOS-ch8-concept-mapping.md
Normal file
@@ -0,0 +1,101 @@
|
||||
---
|
||||
title: "EOS Ch8 — 개념의 매핑"
|
||||
tags: [source, EOS]
|
||||
source: "The Essence of Software, Daniel Jackson (2021)"
|
||||
chapter: "Ch8 Concept Mapping"
|
||||
updated: 2026-04-30
|
||||
---
|
||||
|
||||
# EOS Ch8 — 개념의 매핑
|
||||
|
||||
## 핵심 아이디어
|
||||
|
||||
개념은 사용자 인터페이스의 뒤에서 실행된다. UI 설계는 개념의 행동과 상태를 버튼·뷰 등 물질적 형태로 연결하는 **매핑(mapping)** 설계다. 개념 자체가 단순하더라도 매핑이 잘못되면 사용하기 어렵고, 반대로 복잡한 개념도 훌륭한 매핑으로 이해하기 쉬워진다. 또한 의도적 또는 무의도적 매핑 설계 결함이 다크 패턴을 낳는다.
|
||||
|
||||
## 매핑이란
|
||||
|
||||
UI 설계자는 다음을 결정한다:
|
||||
- 개념의 **행동(action)** → 사용자의 제스처(버튼 클릭, 드래그 등)
|
||||
- 개념의 **상태(state)** → 화면에 표시되는 뷰
|
||||
|
||||
매핑 설계는 개념 설계와 독립적으로 이루어질 수 있어야 한다. 먼저 개념을 설계하고, 그다음 매핑을 설계한다.
|
||||
|
||||
## 단순한 개념도 잘못된 매핑으로 어려워진다
|
||||
|
||||
**Oracle Java 설치 다이얼로그 예시**: "Install"과 "Remove" 두 버튼이 있는 다이얼로그. "Remove"가 기본 선택으로 강조돼 있어 업그레이드하러 온 사용자가 혼란에 빠진다. *install* 개념의 두 운영 원칙(설치 vs. 제거)을 별도 워크플로로 분리했다면 명확했을 것이다.
|
||||
|
||||
**개선 방향**:
|
||||
- 설치와 제거를 별도 탭이나 흐름으로 분리
|
||||
- "Remove"보다 "Uninstall"이 의미를 더 정확히 전달
|
||||
- 업그레이드 프롬프트 후 실행했으므로 설치가 기본값이어야 함
|
||||
|
||||
## 복잡한 개념은 UI에 설명을 내장해야 한다
|
||||
|
||||
**Backblaze 백업 메시지**: "You are backed up as of: Today, 1:05 pm"이라는 메시지는 오해를 낳는다. 더 나은 표현: "Last backup: Today, 1:05pm — This backup included all files saved prior to the scan that began at 12:48pm."
|
||||
|
||||
Apple의 "Do Not Disturb" 개념도 "repeated calls" 옵션 아래에 작은 글씨로 해설 문장을 붙여 의미를 보완한다.
|
||||
|
||||
## 다크 패턴: 의도적 매핑 왜곡
|
||||
|
||||
### change.org 사례들
|
||||
|
||||
1. **서명 수 조작**: 페이지 로드 시 실제 서명 수보다 낮은 숫자에서 시작해 실제 수까지 실시간으로 올라가는 애니메이션 — 가짜 실시간 활동 인상 조작.
|
||||
2. **기부 오해 유도**: 서명 후 나타나는 "기부" 요청이 청원 주최자에게 가는 것처럼 보이지만, 실제로는 change.org의 광고 비용. 개념의 운영 원칙을 숨김.
|
||||
|
||||
### Amazon Prime 사례
|
||||
|
||||
두 버튼("Try Prime FREE" — 노란색, "Continue with FREE One-Day Delivery" — 파란색)이 모두 Prime 가입 액션에 연결됨. 가입 거부 옵션은 훨씬 작은 파란색 링크로 숨겨짐. 두 개의 버튼이 실제로는 하나의 행동을 공유한다는 사실을 매핑이 숨긴다.
|
||||
|
||||
## 복잡한 조합 매핑: Gmail 레이블의 수수께끼
|
||||
|
||||
Gmail은 *label* 개념과 *conversation* 개념을 조합하면서, **레이블은 메시지에 부착하지만 레이블 표시는 대화(conversation)에 표시**한다.
|
||||
|
||||
이 불일치로 인한 이상 현상:
|
||||
- 대화가 "hacking"과 "meetups" 두 레이블을 갖는 것처럼 보임
|
||||
- 그러나 각각의 레이블로는 검색 결과에 나타나지만, 두 레이블을 동시에 검색하면 결과 없음 (두 레이블이 서로 다른 메시지에 부착돼 있기 때문)
|
||||
|
||||
실무적 문제: *sent* 뷰를 보면 내가 보낸 메시지가 포함된 대화 전체가 보이고, 내가 보내지 않은 메시지들도 포함된다. 설계자들이 이 문제를 인지했지만 아직 완전히 해결되지 않았다.
|
||||
|
||||
## 명확하지만 사용하기 어려운 매핑: Backblaze 복원
|
||||
|
||||
파일 버전을 복원하는 흐름: 날짜 범위 설정 → 폴더 트리 로딩(~20초) → 파일 선택 → 다운로드. 손상된 파일의 마지막 정상 버전을 찾으려면 날짜를 하루씩 소급해가며 반복해야 하는데, 매번 폴더 트리가 리셋된다.
|
||||
|
||||
**개선 방향**: Carbonite나 Crashplan처럼 파일의 모든 버전 목록(수정 날짜 포함)을 한 번에 보여주는 방식.
|
||||
|
||||
## 라이브 필터링 딜레마: Apple Mail의 Flag
|
||||
|
||||
플래그된 메시지 목록을 보는 중, 한 메시지의 플래그를 해제하면 그 메시지를 즉시 목록에서 제거해야 할까?
|
||||
|
||||
**직관적 답변(제거)**: 일관성 있어 보이지만 실용적으로 나쁘다. 실수로 플래그 해제 후 메시지를 찾을 수 없게 됨.
|
||||
|
||||
**실제 Apple Mail 동작(유지)**: 플래그가 해제돼도 메시지가 목록에 남아있어, 즉시 재플래그 가능. 뷰를 나갔다 돌아오면 그때 목록이 갱신됨.
|
||||
|
||||
**교훈**: 매핑은 단순한 액션-상태 연결이 아니라 **전형적 사용 시나리오와 사용 패턴**을 고려해야 한다.
|
||||
|
||||
## 모호한 액션 해소: Adobe Lightroom 컬렉션
|
||||
|
||||
*collection* 개념: 아이템이 여러 컬렉션에 동시에 속할 수 있음.
|
||||
|
||||
두 컬렉션이 동시에 선택된 상태에서 한 아이템을 제거하려 하면 어느 컬렉션에서 제거할지 모호하다. Lightroom은 처음에 에러 메시지를 표시하다가, 나중에 선택된 모든 컬렉션에서 동시에 제거하도록 변경했다. 이 문제는 UI 위젯 설계의 한계에서 비롯된다.
|
||||
|
||||
## 비표준 위젯 필요: "없음" 값 입력
|
||||
|
||||
*partial style* 개념: 서식의 일부 속성만 지정하는 스타일. 예: 이탤릭만 지정하고 폰트 크기는 지정 안 함.
|
||||
|
||||
문제: 기존에 설정된 속성을 "설정 안 함(none)"으로 되돌리는 UI 요소가 없다. 3상태 체크박스(on/off/not-set), 값 편집 가능한 드롭다운 등 비표준 위젯이 필요하다. 이 요구는 현재 UI 툴킷의 한계를 드러낸다.
|
||||
|
||||
## 핵심 인용
|
||||
|
||||
> "The design of mappings has been extensively studied by human-computer interaction researchers, and the guidelines that have been developed—mostly at the physical and linguistic levels of design—apply equally well to systems that have been designed with concepts."
|
||||
|
||||
> "Attempts to make the user interface simpler than the underlying concepts may backfire."
|
||||
|
||||
> "The mapping must take into account typical usage patterns, which… may be more complicated than performing a single action."
|
||||
|
||||
## 관련 개념
|
||||
|
||||
- [[EOS-ch6-concept-composition]] — 조합된 개념을 매핑할 때의 복잡성
|
||||
- [[EOS-ch4-concept-structure]] — 개념의 행동·상태가 매핑의 대상
|
||||
- [[EOS-part3-principles]] — Ch9 특정성: 매핑에서의 목적 명확성
|
||||
- [[EOS-part1-motivations]] — Ch2: 설계 3수준 (물리·언어·개념)
|
||||
- [[EOS-overview]] — 전체 개요
|
||||
77
wiki/sources/EOS-overview.md
Normal file
77
wiki/sources/EOS-overview.md
Normal file
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: "The Essence of Software — 전체 개요"
|
||||
tags: [source, EOS]
|
||||
source: "The Essence of Software, Daniel Jackson (2021)"
|
||||
chapter: overview
|
||||
updated: 2026-04-30
|
||||
---
|
||||
|
||||
# The Essence of Software — 전체 개요
|
||||
|
||||
## 핵심 아이디어
|
||||
|
||||
소프트웨어의 복잡도 근원은 "개념(concept)"의 혼재와 뒤엉킴에 있다. 개념을 명확히 분리·정의하고 그 목적(purpose)을 정확히 지정하면, 사용하기 쉽고 설계하기 좋은 소프트웨어를 만들 수 있다. 저자 Daniel Jackson은 Alloy 언어 연구에서 출발해, 소프트웨어 설계의 "개념 수준(conceptual level)"이 물리·언어 수준과 독립적으로 다루어져야 한다는 이론을 제시한다.
|
||||
|
||||
## 책 구조
|
||||
|
||||
| 파트 | 챕터 | 주제 |
|
||||
|------|------|------|
|
||||
| Part I: Motivations | Ch1–3 | 왜 개념 설계인가; 개념의 발견과 활용 |
|
||||
| Part II: Essentials | Ch4–8 | 개념의 구조, 목적, 조합, 의존, 매핑 |
|
||||
| Part III: Principles | Ch9–11 | 특정성, 친숙성, 무결성 원칙 |
|
||||
| Resources | Explorations & Digressions | 심화 주석·참고문헌 |
|
||||
|
||||
## 설계의 3 수준
|
||||
|
||||
저자는 소프트웨어 설계를 세 수준으로 분류한다:
|
||||
|
||||
1. **물리 수준(Physical level)** — 버튼 레이아웃, 제스처, 접근성 등 물리적 속성
|
||||
2. **언어 수준(Linguistic level)** — 아이콘, 메시지, 용어 등 의사소통 관련 속성
|
||||
3. **개념 수준(Conceptual level)** — 사용자가 상호작용하는 행동과 상태의 본질
|
||||
|
||||
개념 수준이 가장 중요하다. 물리·언어 수준의 문제는 종종 사실 개념 수준의 설계 결함에서 비롯된다.
|
||||
|
||||
## 개념(Concept)이란
|
||||
|
||||
소프트웨어는 개념들의 합성으로 이루어진다. 각 개념은:
|
||||
|
||||
- **자기완결적 기능 단위** — 다른 개념과 독립적으로 이해할 수 있다
|
||||
- **목적(purpose)** — 개념이 존재하는 이유
|
||||
- **상태(state)** — 개념이 기억하는 정보 구조
|
||||
- **행동(actions)** — 상태를 변경하는 동작들
|
||||
- **운영 원칙(operational principle)** — 목적이 어떻게 달성되는지를 보여주는 전형적 사용 시나리오
|
||||
|
||||
예시 개념: *trash*, *style*, *reservation*, *label*, *todo*, *email*, *upvote*, *friend*, *bookmark*, *folder* 등.
|
||||
|
||||
## 주요 원칙 요약
|
||||
|
||||
| 챕터 | 원칙 | 핵심 내용 |
|
||||
|------|------|----------|
|
||||
| Ch9 | 특정성(Specificity) | 개념과 목적은 1:1 대응이어야 한다 |
|
||||
| Ch10 | 친숙성(Familiarity) | 기존에 알려진 개념을 재사용하라 |
|
||||
| Ch11 | 무결성(Integrity) | 개념 조합 시 각 개념의 명세를 위반하지 마라 |
|
||||
|
||||
## 책의 목표
|
||||
|
||||
1. 소프트웨어 설계자가 즉시 적용할 수 있는 실용적 기법 제공
|
||||
2. 소프트웨어를 기능 덩어리가 아닌 개념의 체계적 조합으로 바라보는 새 관점 제공
|
||||
3. 소프트웨어 설계가 지적으로 충분한 독자적 분야임을 증명
|
||||
|
||||
## 핵심 인용
|
||||
|
||||
> "A software product—from the smallest app that runs on your phone to the largest enterprise system—is made of *concepts*, each a self-contained unit of functionality."
|
||||
|
||||
> "Clarity is good not only for finding design flaws after the fact. It is also the key to good design in the first place."
|
||||
|
||||
> "The real problem runs deeper. It's in the very essence of how files and folders are named… This is what I call a *conceptual* design issue."
|
||||
|
||||
## 관련 개념
|
||||
|
||||
- [[EOS-part1-motivations]] — Part I: 동기 챕터들
|
||||
- [[EOS-ch4-concept-structure]] — 개념의 구조 정의
|
||||
- [[EOS-ch5-concept-purposes]] — 개념의 목적
|
||||
- [[EOS-ch6-concept-composition]] — 개념 조합
|
||||
- [[EOS-ch7-concept-dependence]] — 개념 의존
|
||||
- [[EOS-ch8-concept-mapping]] — 개념 매핑
|
||||
- [[EOS-part3-principles]] — Part III: 원칙들
|
||||
- [[SDF-overview]] — "Software Design for Flexibility" 개요 (같은 선반)
|
||||
116
wiki/sources/EOS-part1-motivations.md
Normal file
116
wiki/sources/EOS-part1-motivations.md
Normal file
@@ -0,0 +1,116 @@
|
||||
---
|
||||
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의 가산적 프로그래밍 철학과 비교
|
||||
192
wiki/sources/EOS-part3-principles.md
Normal file
192
wiki/sources/EOS-part3-principles.md
Normal file
@@ -0,0 +1,192 @@
|
||||
---
|
||||
title: "EOS Part III — 개념 설계 원칙: 특정성·친숙성·무결성"
|
||||
tags: [source, EOS]
|
||||
source: "The Essence of Software, Daniel Jackson (2021)"
|
||||
chapter: "Part III (Ch9–11)"
|
||||
updated: 2026-04-30
|
||||
---
|
||||
|
||||
# EOS Part III — 개념 설계 원칙: 특정성·친숙성·무결성
|
||||
|
||||
## 핵심 아이디어
|
||||
|
||||
Part III(Ch9~11)는 좋은 개념 설계를 위한 세 가지 핵심 원칙을 제시한다. **특정성(Specificity)**: 개념과 목적은 1:1로 대응해야 한다. **친숙성(Familiarity)**: 새 개념보다 기존 친숙한 개념을 재사용하라. **무결성(Integrity)**: 개념 조합 시 각 개념의 명세가 훼손되지 않아야 한다. 이 세 원칙의 그림 요약은 Ch11 마지막의 Fig.11.5에 도식화돼 있다.
|
||||
|
||||
---
|
||||
|
||||
## Ch9 — 개념 특정성(Concept Specificity)
|
||||
|
||||
### 원칙
|
||||
|
||||
개념과 목적은 **1:1 대응**이어야 한다:
|
||||
- 모든 개념에 정확히 하나의 목적이 있어야 한다
|
||||
- 모든 목적에 정확히 하나의 개념이 대응해야 한다
|
||||
|
||||
이 원칙은 네 가지 위반 유형을 낳는다: 목적 없는 개념, 개념 없는 목적, 중복 개념, 과부하 개념.
|
||||
|
||||
### 목적 없는 개념(Concepts without purposes)
|
||||
|
||||
내부 구현 메커니즘이 사용자에게 노출될 때 발생한다(예: *editor buffer*). 이미 Ch5에서 다루었으므로 Ch9에서는 간략히 언급.
|
||||
|
||||
### 개념 없는 목적(Purposes without concepts)
|
||||
|
||||
명백히 필요하지만 구현되지 않은 개념들:
|
||||
|
||||
- **Email *correspondent* 개념 부재**: 발신자를 고유하게 식별하는 개념이 없어 Apple Mail에서 동일인을 여러 이름으로 검색해야 함. 오픈 이메일 시스템에서 구현이 어렵다는 기술적 제약이 있다.
|
||||
- **백업의 삭제 경고 개념 부재**: 대부분의 백업 유틸리티는 원본 기기에서 삭제된 파일이 30일 후 클라우드에서도 삭제된다. 의도치 않은 삭제를 탐지·경고하는 개념이 없다.
|
||||
- **PowerPoint의 *style* 개념 부재**: Keynote는 최근 추가했지만 PowerPoint는 여전히 없어 일관된 서식 유지가 어렵다.
|
||||
- **Squarespace의 *template* 개념 퇴화**: 버전 7.1에서 템플릿 전환 기능을 제거해, 개념의 핵심 목적(콘텐츠와 시각 설계 분리)이 훼손됨.
|
||||
|
||||
### 중복 개념(Redundant concepts)
|
||||
|
||||
두 개 이상의 개념이 동일한 목적을 서비스할 때.
|
||||
|
||||
**Gmail *category* vs. *label*** 중복:
|
||||
- *category*: 받은 편지함을 Primary/Social/Promotions 등으로 자동 분류
|
||||
- *label*: 이미 메시지 분류를 담당하는 기존 개념. 시스템 레이블(*sent*, *trash*)로도 자동 분류가 가능했다
|
||||
- 결과: 두 개념 간 임의적 제약(카테고리만 탭 할당 가능, 레이블만 받은 편지함 외 분류 가능 등)으로 사용자 혼란
|
||||
|
||||
**Zoom *broadcast* vs. *chat*** 중복:
|
||||
- *chat*: 참가자 간 메시지 교환
|
||||
- *broadcast*: 호스트가 전체 참가자(브레이크아웃 룸 포함)에게 메시지 전송
|
||||
- 두 개념이 같은 목적인데 서로 다른 기능(지속성, 클릭 가능한 링크, 복사 불가 등) 차이가 임의적
|
||||
|
||||
**Apple Mail *filter* vs. *rule*** 중복:
|
||||
- *filter*: 표시할 메시지 부분집합 정의
|
||||
- *rule*: 조건에 맞는 메시지에 액션 적용
|
||||
- 공통 목적(메시지 필터링)인데 기능이 불완전하게 겹침. Gmail은 이를 단일 개념으로 통합.
|
||||
|
||||
### 과부하 개념(Overloaded concepts)
|
||||
|
||||
하나의 개념이 여러 목적을 가질 때. 4가지 원인:
|
||||
|
||||
| 원인 | 설명 | 사례 |
|
||||
|------|------|------|
|
||||
| **False convergence** | 두 목적이 하나라고 착각 | Facebook *friend* = 필터링(봐야 할 것) + 접근 제어(봐도 될 것) |
|
||||
| **Denied purpose** | 설계자가 사용자의 목적을 무시 | Twitter *favorite* = 승인 표시 + 저장(사용자가 원했지만 무시됨) |
|
||||
| **Emergent purpose** | 시간이 지나며 새 목적이 생김 | 이메일 *subject line* = 요약 → listserv 출처 표시 → 대화 그룹화 |
|
||||
| **Piggybacking** | 기존 개념에 새 목적 얹기 | Epson 프린터 드라이버: *paper size* 개념에 *paper feed* 붙이기 |
|
||||
|
||||
### Facebook *like* 개념 분석
|
||||
|
||||
Facebook *like*는 세 목적을 동시에 가진다:
|
||||
1. **감정 반응 전달** (저자, 친구에게)
|
||||
2. **뉴스피드 큐레이션** (사용자 자신에게)
|
||||
3. **광고 프로파일링** (Facebook과 광고주에게)
|
||||
|
||||
일관성 테스트를 통한 복합 목적 판별:
|
||||
- **재표현 가능성**: "게시물에 반응하기"로 통합하기 어려움
|
||||
- **공통 이해관계자**: 각 부분이 다른 집단에 혜택
|
||||
- **공통 미션**: 각 부분의 미션이 다름 (관계 구축 / 콘텐츠 참여 / 광고 수익)
|
||||
- **비충돌성**: "화남(angry)" 반응이 좋아요로 해석되는 모순
|
||||
|
||||
**해결책**: 세 개념으로 분리 — *reaction* + *recommendation* + *profiling*
|
||||
|
||||
---
|
||||
|
||||
## Ch10 — 개념 친숙성(Concept Familiarity)
|
||||
|
||||
### 원칙
|
||||
|
||||
기존에 알려진 개념이 목적을 충족하면, 새 개념을 발명하지 마라. 친숙한 개념을 사용하면:
|
||||
- 사용자가 이미 개념을 알기 때문에 배우는 비용이 없다
|
||||
- 기존 개념의 검증된 설계 지식을 활용할 수 있다
|
||||
- 미스피트 가능성이 줄어든다
|
||||
|
||||
### 성공적 재사용: Twitter *follower*
|
||||
|
||||
Twitter는 *follower* 개념을 소개하면서 이미 알려진 *subscription* 개념임을 명시한다: "Following someone means you've chosen to **subscribe** to their Twitter updates." — 운영 원칙을 직접 제공하며, 기존 개념과의 연결로 학습 부담 제거.
|
||||
|
||||
### 재발명의 실패: PowerPoint *section* vs. Keynote *slide group*
|
||||
|
||||
같은 목적(슬라이드 그룹화)을 위한 두 설계 비교:
|
||||
|
||||
| 측면 | Keynote *slide group* | PowerPoint *section* |
|
||||
|------|----------------------|----------------------|
|
||||
| 기반 개념 | *outline tree* (친숙) | 신규 발명 (생소) |
|
||||
| 중첩 | 6단계까지 가능 | 불가능 |
|
||||
| 생성 방법 | 슬라이드를 오른쪽으로 드래그 | 복잡한 메뉴, 예측 불가 결과 |
|
||||
| 행동 예측성 | 직관적, 예측 가능 | 추가 시 범위 외 슬라이드가 자동 생성되는 등 예측 불가 |
|
||||
|
||||
Keynote가 더 효과적인 이유: 처음부터 새로 만든 것이 아니라 친숙한 *outline tree* 개념을 재사용했기 때문.
|
||||
|
||||
### 확장이 친숙성을 깨뜨린 경우: Lightroom 내보내기 프리셋
|
||||
|
||||
*preset* 개념은 반복 명령의 파라미터를 저장하는 친숙한 개념이다. Adobe Lightroom의 내보내기 다이얼로그는 여기에 "여러 프리셋 체크로 복수 내보내기" 기능을 추가했다. 결과: 프리셋 이름 클릭과 체크박스 클릭이 다른 동작을 함 → 사용자 혼란. 해법: *action* 개념처럼 별도의 "명령 시퀀스" 개념을 분리했어야 했다.
|
||||
|
||||
### 개념 인스턴스는 표준 동작을 따라야 한다
|
||||
|
||||
친숙한 개념의 인스턴스라면, 표준 동작에서 벗어날 때는 명확한 이유가 있어야 하고 그 차이를 사용자에게 분명히 알려야 한다.
|
||||
|
||||
**Apple Contacts 사례**: 왕세자가 어머니를 "Mummy"로 저장 → 이메일 수신자 주소에 "Mummy"가 포함돼 전달됨. *nickname* 개념처럼 비공개로 동작할 것이라는 기대와 달리, Contacts는 *contact* 개념으로 모든 정보를 공유한다. 개념 인스턴스의 동작이 기대와 다를 때 생기는 혼란.
|
||||
|
||||
---
|
||||
|
||||
## Ch11 — 개념 무결성(Concept Integrity)
|
||||
|
||||
### 원칙
|
||||
|
||||
개념들이 조합될 때, **각 개념의 명세(specification)가 위반되지 않아야 한다**. 동기화는 개념의 기존 행동을 제거할 수는 있지만, 개념 명세에 위배되는 새로운 행동을 추가해서는 안 된다.
|
||||
|
||||
### 무결성 위반이란
|
||||
|
||||
동기화가 아닌 방식으로 개념 간 상호작용이 발생해, 한 개념의 행동이 그 개념의 명세와 불일치하는 현상.
|
||||
|
||||
### 명백한 위반: 복수심에 찬 식당 주인
|
||||
|
||||
*reservation* + *review* 조합에서:
|
||||
- 식당 주인이 나쁜 리뷰를 남긴 고객의 예약을 cancel 없이 무효화 → *reservation* 개념의 운영 원칙("예약 후 취소 없으면 자리 보장") 위반 → 무결성 위반
|
||||
|
||||
반면, 나쁜 리뷰 시 cancel 액션을 자동 실행하도록 동기화하는 것은 비윤리적이지만 무결성 위반은 아니다. *reservation* 명세 안에 있는 cancel 액션을 트리거한 것이기 때문.
|
||||
|
||||
### 미묘한 위반: 폰트 서식
|
||||
|
||||
초기 *format toggle* + *typeface* 조합은 작동했다: 이탤릭 적용 시 이탤릭 폰트 파일로 전환, 볼드 적용 시 볼드-이탤릭 파일로 전환 (toggle 명세 유지).
|
||||
|
||||
전문 폰트 등장 이후 문제: Helvetica Light에 볼드를 두 번 적용해도 Light로 돌아오지 않고 Regular가 됨 → *format toggle*의 "두 번 적용하면 원래 상태로 복귀" 운영 원칙 위반.
|
||||
|
||||
- **Apple TextEdit**: 위반 그대로
|
||||
- **Apple Pages**: 숨겨진 매직으로 복귀 동작 구현 → 다른 문제 유발
|
||||
- **Adobe InDesign**: 문자 스타일이 특정 폰트 패밀리에만 적용되는 비표준 동작
|
||||
|
||||
이 문제는 근본적으로 해결되지 않았다. *format toggle* 개념과 더 정교해진 타이포그래피 개념들은 원천적으로 조화가 어렵다.
|
||||
|
||||
### 중대한 위반: Google Drive 동기화
|
||||
|
||||
*synchronization* 개념의 운영 원칙: "한 컬렉션의 변경이 다른 컬렉션에 전파됨. 두 장소의 아이템 복사본은 동일해야 함."
|
||||
|
||||
Google Drive는 `.gdoc` 같은 Google 앱 파일을 로컬 디스크에 저장할 때, **실제 파일 데이터가 아닌 클라우드 링크를 저장**한다. 사용자가 로컬 폴더에서 파일을 이동하면:
|
||||
1. Google Drive 동기화가 클라우드에서도 파일을 삭제
|
||||
2. 사용자는 로컬 디스크의 파일(사실 링크)을 열려고 하지만 클라우드 파일이 이미 없어서 오류
|
||||
|
||||
이것은 *synchronization* 개념과 *cloud app* 개념(문서가 링크로 접근)의 조합이 *synchronization* 명세("복사본이 동일해야 함")를 위반한 무결성 위반이다.
|
||||
|
||||
> "I lost years of work and personal memories that I saved as Google Docs files because of a poor user interface." (피해 사용자의 증언)
|
||||
|
||||
기술적으로 수정 가능한 문제이나 Google이 아직 우선순위를 두지 않고 있다.
|
||||
|
||||
### 세 원칙의 그림 요약 (Fig.11.5)
|
||||
|
||||
- 목적과 개념 사이의 선: 개념이 목적을 충족
|
||||
- 점선: 다른 개념의 간섭으로 충족 불가 (무결성 위반)
|
||||
- 개념 간 선: 조합(composition)
|
||||
- 점선 박스: 앱
|
||||
|
||||
---
|
||||
|
||||
## 핵심 인용
|
||||
|
||||
> "The specificity principle says that concepts should be one-to-one with purposes. This simple rule has some profound implications for concept design."
|
||||
|
||||
> "A good designer knows not only how to invent new concepts, but also when not to invent at all."
|
||||
|
||||
> "When concepts are composed to form an application, they may be synchronized… This synchronization may eliminate certain behaviors of a concept, but can never add *new* behaviors inconsistent with the concept specification."
|
||||
|
||||
## 관련 개념
|
||||
|
||||
- [[EOS-ch4-concept-structure]] — 목적(purpose)과 운영 원칙의 정의
|
||||
- [[EOS-ch5-concept-purposes]] — 좋은 목적의 기준
|
||||
- [[EOS-ch6-concept-composition]] — 동기화 메커니즘 (무결성 원칙의 전제)
|
||||
- [[EOS-ch7-concept-dependence]] — 의존 다이어그램과 최소 제품 선택
|
||||
- [[EOS-ch8-concept-mapping]] — 매핑과 친숙성의 관계
|
||||
- [[EOS-overview]] — 전체 개요
|
||||
Reference in New Issue
Block a user