Files

minsung 81a4d0a2fe 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>

2026-04-30 15:04:06 +09:00

11 KiB

Raw Blame History

title, tags, source, chapter, updated

title

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는 세 목적을 동시에 가진다:

감정 반응 전달 (저자, 친구에게)
뉴스피드 큐레이션 (사용자 자신에게)
광고 프로파일링 (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 앱 파일을 로컬 디스크에 저장할 때, 실제 파일 데이터가 아닌 클라우드 링크를 저장한다. 사용자가 로컬 폴더에서 파일을 이동하면:

Google Drive 동기화가 클라우드에서도 파일을 삭제
사용자는 로컬 디스크의 파일(사실 링크)을 열려고 하지만 클라우드 파일이 이미 없어서 오류

이것은 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."

11 KiB Raw Blame History Unescape Escape