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>
193 lines
11 KiB
Markdown
193 lines
11 KiB
Markdown
---
|
||
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]] — 전체 개요
|