81a4d0a2fe
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>
78 lines
3.8 KiB
Markdown
78 lines
3.8 KiB
Markdown
---
|
||
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" 개요 (같은 선반)
|