feat: EOS 전 챕터 Vision 이미지 분석 삽입 (fig. 1.1–11.5, E.1–E.10)

- 9개 wiki 소스 페이지에 총 69개 JPEG 이미지 Vision 분석 결과 삽입
- fig. 2.1–2.8, 3.1, 3.3–3.5: EOS-part1-motivations (Backblaze·Dropbox 설계 결함)
- fig. 4.1, 4.3, 4.5–4.6: EOS-ch4-concept-structure (개념 5요소·상태 기계)
- fig. 5.1–5.10: EOS-ch5-concept-purposes (목적 기준·미스피트 사례)
- fig. 6.1, 6.4, 6.6, 6.9: EOS-ch6-concept-composition (시너지·동기화 문제)
- fig. 7.1–7.3: EOS-ch7-concept-dependence (의존 다이어그램)
- fig. 8.1–8.5, 8.7, 8.10–8.11: EOS-ch8-concept-mapping (UI 매핑·다크 패턴)
- fig. 9.1, 9.3–9.4, 9.6–9.9, 10.1–10.3, 11.1–11.2, 11.4–11.5: EOS-part3-principles
- fig. E.1–E.5: EOS-endnotes-formalism (상태 기계·관계형 모델·Photoshop layer)
- fig. E.6–E.9: EOS-endnotes-context (Bosch·Gmail·nail clipper·Photoshop crop)
- fig. E.10: EOS-part3-principles (Apple Pages '09 부분 스타일)
- 책 표지·챕터 헤더 이미지는 스킵

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

wiki/sources/EOS-ch4-concept-structure.md

@@ -28,6 +28,8 @@ updated: 2026-04-30
 
 Apple이 1982년 Lisa 컴퓨터를 위해 발명한 *trash* 개념.
 
+> **fig. 4.1** (*The original Macintosh desktop, with trash at bottom right (1984).*): 1984년 최초의 Macintosh 데스크탑 화면으로, 흑백 GUI에 "Mac System Software" 창과 "System Folder" 창이 열려 있다. 화면 오른쪽 하단에 줄무늬 패턴의 작은 쓰레기통 아이콘("Trash")이 자리잡고 있다. Finder, System, Imagewriter, Note Pad, Scrapbook, Clipboard 파일 아이콘들이 보이며, 당시 혁신적이었던 WIMP 인터페이스(창·아이콘·메뉴·포인터)의 원형을 보여준다. *trash* 개념이 처음 도입된 역사적 화면으로, 삭제 취소(undeletion)라는 개념적 혁신의 시작점이다.
+
 **목적**: 삭제의 취소(undoing of deletions)를 허용한다.
 
 **상태**: `accessible` (접근 가능한 아이템 집합), `trashed` (삭제됐지만 영구 제거 전 아이템 집합)
@@ -67,8 +69,14 @@ Adobe InDesign, Microsoft Word 등 문서 편집 도구의 *style* 개념.
 
 **운영 원칙**: s를 서식 f로 정의하고, e1·e2에 s를 할당한 뒤 s를 f'로 재정의하면, e1과 e2 모두 f'로 변경된다.
 
+> **fig. 4.3** (*Style concept in Microsoft Word (left) and Apple Pages (right).*): 왼쪽은 Microsoft Word의 "Style" 다이얼로그로, "Normal", "Normal (Web)", "Note Heading" 등 스타일 목록과 선택된 "Normal" 스타일의 단락 미리보기 및 설명(Calibri 폰트, 줄간격 single 등)이 표시돼 있다. 오른쪽은 Apple Pages의 스타일 패널로, "Body" 스타일이 선택되고 Helvetica Neue Regular 11pt 설정이 표시된다. 두 앱 모두 스타일에 서식을 정의하고 요소에 할당하는 *style* 개념의 핵심 구조(이름·서식·할당)를 UI로 구현한 것을 보여준다.
+
+> **fig. 4.5** (*Style concept applied to slide themes in Microsoft PowerPoint (left) and color swatches in Adobe apps (right).*): 왼쪽은 Microsoft PowerPoint의 "Create Theme Colors" 다이얼로그로, Text/Background, Accent 1–6, Hyperlink 등의 색상 역할을 일괄 설정하는 테마 색상 팔레트가 표시되어 있고, 오른쪽 미리보기에 적용 결과가 나타난다. 오른쪽은 Adobe InDesign의 Swatches 패널로, CMYK 값으로 정의된 다수의 색상 견본 목록이 보인다. 두 화면은 *style* 개념이 텍스트 서식을 넘어 슬라이드 테마와 색상 팔레트에도 동일하게 적용됨을 보여준다 — 스타일 수정 시 그 스타일이 적용된 모든 요소가 일괄 변경된다.
+
 ### Style이 아닌 것들
 
+> **fig. 4.6** (*Two concepts that look like style but are not: the Apple color picker (left) and styles in Apple TextEdit (right).*): 왼쪽은 macOS Colors 패널로, "Daniel's Swatches" 목록에 Daniel's Orange, Daniel's Blue, Daniel's Green 세 가지 색상이 나열돼 있다. 오른쪽은 Apple TextEdit의 스타일 선택 다이얼로그로, "really"라는 단어가 Helvetica Oblique 12pt로 서식이 적용된 것을 보여주고, "Document Styles"와 "Favorite Styles" 탭, "Add To Favorites", "Select", "Apply", "Done" 버튼이 있다. 두 UI 모두 스타일처럼 보이지만 *style* 개념의 핵심 기능(기존 스타일 수정 시 할당된 요소 일괄 변경)이 없어 진정한 *style* 개념이 아님을 설명하는 반례다.
+
 - Apple color picker: 색상 수정 불가 → 운영 원칙 실패 → *style* 개념 아님
 - Apple TextEdit의 "style": 스타일을 적용해도 단락에 지속적으로 연결되지 않음 → *style* 개념 아님
 

wiki/sources/EOS-ch5-concept-purposes.md

@@ -32,6 +32,8 @@ updated: 2026-04-30
 - **delegate forwarding**: "다른 사람에게 전화를 위임한다" — A→B→C로 두 단계 전환 (연쇄 적용)
 - **follow-me forwarding**: "내가 다른 장소로 이동했다" — A에서 B 위치로만 전환 (단일 전환)
 
+> **fig. 5.1** (*Call forwarding: a design puzzle (top) and two solutions (below). If A is forwarded to B, and B is forwarded to C, does a call to A get forwarded to B or to C?*): 위 다이어그램은 발신자 → A → B → C 연쇄 전환을 보여주며, A에 온 전화가 B로 가는지 C로 가는지의 설계 퍼즐을 제시한다. 가운데 "delegate forwarding" 다이어그램은 발신자가 A를 건너뛰고 C까지 직접 연결되는 2단계 전환을 보여준다. 아래 "follow-me forwarding" 다이어그램은 발신자가 A를 건너뛰고 B에만 연결되는 1단계 전환을 보여준다. 두 개념의 목적 차이(위임 vs. 위치 이동)가 서로 다른 전환 행동을 정당화함을 시각화한다.
+
 하나의 개념에 두 목적을 섞으면 불합리한 동작이 나온다.
 
 ## 목적 없는 개념
@@ -42,10 +44,14 @@ updated: 2026-04-30
 
 신식 단일 손잡이: 회전 = 온도, 상하 = 수량. 목적과 제어가 1:1 대응한다.
 
+> **fig. 5.2** (*A physical analogy: do faucet controls have purposes?*): 왼쪽은 온수·냉수 두 개의 십자형 손잡이가 달린 구식 혼합 수도꼭지, 오른쪽은 단일 레버 손잡이가 달린 신식 수도꼭지. 구식의 각 손잡이는 "온도"나 "수량"이라는 사용자 목적에 직접 대응하지 않지만, 신식의 단일 레버는 회전(온도)과 상하(수량)로 사용자 목적과 1:1 대응한다. 목적 없는 개념(구식 핸들)이 사용성 문제를 일으키는 물리적 유비로 사용된다.
+
 ### 에디터 버퍼
 
 *editor buffer* 개념: 메모리에 텍스트를 유지하다가 저장 명령으로 디스크에 씀. 이 개념의 목적은 사용자가 아닌 구현의 필요에서 비롯됐다. Apple은 OS X Lion(2011)에서 이 개념을 제거했다. "저장"은 이제 파일에 이름을 붙이는 것이 됐고, "다른 이름으로 저장"도 사라졌다.
 
+> **fig. 5.3** (*Apple file menu: the "save as" action in the old menu (left) reflected the buffer concept, no longer present in the new menu (right).*): 왼쪽은 구 Apple File 메뉴로 New, Open, Save, Save As, Rename, Move To, Revert To 등의 항목이 나열돼 있다. 오른쪽은 새 File 메뉴로 "Save As…"가 사라지고 Close, Save, Duplicate, Rename, Move To, Revert To로 대체됐다. "Save As"의 제거가 *editor buffer* 개념의 소멸을 반영하며, 이제 파일 복사는 "Duplicate"(파일을 복제)로 대체됨을 보여준다.
+
 **원칙**: 개념은 내부 구현 메커니즘이 아닌 사용자 필요에서 비롯되어야 한다.
 
 ## 목적이 불명확한 개념: Twitter의 favorite
@@ -54,6 +60,10 @@ Twitter의 *favorite* 개념 문제: 사용자들이 개념을 "나중에 볼
 - *favorite* → *like*로 이름 변경 (목적과 일치)
 - *bookmark* 개념 신규 도입 (사적 저장 목적)
 
+> **fig. 5.4** (*An unflattering tweet unintentionally endorsed due to a misunderstanding over the purpose of Twitter's favorite concept.*): Andy Ostroy(@AndyOstroy)가 트럼프와 영부인의 관계를 조롱한 트윗 스크린샷으로, 하트 8,221개와 2017년 5월 2일 날짜가 표시돼 있다. 이 트윗에 MELANIA TRUMP가 "liked your Tweet" 알림을 받은 화면이 오른쪽(fig. 5.4의 두 번째 이미지)에 표시된다. 영부인이 *favorite*(하트 클릭)의 목적이 공개 승인 표시임을 인지하지 못하고 "저장"으로 오해해 발생한 실수로, 개념 목적 불명확성의 실제 파급 사례다.
+
+> **fig. 5.5** (*Twitter's response to problems with the "favorite" concept: a new "bookmark" concept, accessible through the share menu (on the right), and the original concept, renamed "like," still represented by a heart icon (on the left).*): 왼쪽은 The Boston Globe 트윗에 하트(좋아요) 94개가 표시된 일반 트윗 화면, 오른쪽은 공유 버튼을 누르면 나타나는 드롭다운 메뉴로 "Send via Direct Message", "Add Tweet to Bookmarks", "Copy link to Tweet", "Share Tweet via…" 항목이 보인다. *favorite* 개념의 목적 혼란을 해결하기 위해 Twitter가 두 개념으로 분리한 결과 — 공개 승인은 *like*(하트), 사적 저장은 *bookmark*(공유 메뉴 내)로 명확히 구분됐다.
+
 ## 기만적 목적: Nanny Scam
 
 *available funds* 개념과 *cleared check* 개념이 혼동됨. 은행 앱이 수표 처리 전에 일부 금액을 "사용 가능"으로 표시하는 것은 의회 법령에 따른 것인데, 사용자들은 이를 "수표가 청산됐다"고 오해한다. 사기꾼들은 이 개념 오해를 악용해 먼저 "수표 받기" → "초과분 반환 요청" → 수표 부도로 피해를 입힌다.
@@ -67,12 +77,22 @@ Twitter의 *favorite* 개념 문제: 사용자들이 개념을 "나중에 볼
 | Quora 로그인 강제 | "커뮤니티 기여" | 사용자 데이터 수집·광고 타겟팅 |
 | Direct flight 개념 | 편의성 | 예약 시스템 검색 우선 노출 |
 
+> **fig. 5.6** (*Image size dialog in Photoshop. If you check the resample box (top left), and change the resolution from 300 to 600, the pixel dimensions double (bottom left). If you change the resolution with the resample box unchecked (top right), the pixel dimensions stay the same but the width and height are halved (bottom right).*): 4개의 Photoshop Image Size 다이얼로그 스크린샷. 왼쪽 상단(Resample 체크됨): 6000×4000px, 20인치, 300 ppi. 왼쪽 하단(해상도를 600으로 변경 후): 12000×8000px로 픽셀 수가 두 배로 증가. 오른쪽 상단(Resample 체크 해제): 동일한 6000×4000px, 300 ppi. 오른쪽 하단(해상도를 600으로 변경 후): 픽셀 수는 그대로지만 인쇄 크기가 10×6.7인치로 절반. Resample 유무에 따라 해상도 변경의 의미가 달라지는 *image size* 개념의 복잡성을 4분할 비교로 시각화한다.
+
+> **fig. 5.7** (*The tagging concept in Facebook: no mention of why you should do this.*): Facebook의 "Who Is in These Photos?" 화면으로, "To tag your friends, review the suggested names and click Save Tags…" 안내문 아래 두 사람의 얼굴 사진과 "Who is this?" 텍스트 박스가 표시돼 있다. 태그를 *왜* 해야 하는지에 대한 설명이 전혀 없다 — "If someone doesn't like a photo, they can untag themselves" 같은 단서는 있지만 태그의 목적(소셜 그래프 확장)은 숨겨져 있다. 기만적 목적의 전형적 예시다.
+
+> **fig. 5.8** (*Quora's disingenuous explanation for why reading posts requires sign-in.*): Quora 로그인 화면으로, "Continue with Google"과 "Continue with Facebook" 버튼 아래 "Why do I need to sign in?" 섹션에 "Quora is a knowledge-sharing community that depends on everyone being able to pitch in when they know something."이라는 설명이 표시돼 있다. 실제 목적(사용자 데이터 수집·광고 타겟팅)을 숨기고 커뮤니티 기여라는 이타적 이유를 내세우는 기만적 목적 표현의 사례다.
+
+> **fig. 5.9** (*A flight reservation app showing non-stop and direct options: note the parenthetic explanation of the direct flight concept next to the checkbox at the bottom left.*): Southwest Airlines 항공편 검색 결과 화면(Boston → Chicago, 2016년 2월 26일). 하단 "Filter My Results" 영역에 "Nonstop"과 "Direct (No plane change, with stops)" 체크박스가 나란히 있다. *Direct flight* 개념에 "(No plane change, with stops)"라는 괄호 설명이 붙어 있어, 환승 없이 논스톱이라는 사용자의 잘못된 기대를 바로잡는다. 기만적 목적이 있는 개념에 대해 UI에서 명시적 설명을 추가해 오해를 방지하는 사례다.
+
 ## 미스피트(Misfits): 목적이 실현되지 않을 때
 
 소프트웨어 설계는 "형태(form)"를 "맥락(context)"에 맞추는 것이다. 미스피트는 이 맞춤이 실패하는 지점이다. 미스피트는 예측하기 어렵다:
 
 1. **설계 결함으로 인한 미스피트**: PLGR GPS 기기 — 배터리 교체 후 재부팅 시 좌표가 기기 자신의 위치로 리셋됨 → 오폭 사고. *battery* 개념과 *target* 개념의 상호작용을 설계 시 고려했다면 방지 가능했다.
 
+> **fig. 5.10** (*A GPS receiver (left) similar to the one that caused the accident in Afghanistan in which the operator unwittingly set the target of a bombing run to his own position, and the warning messages (right) that are now displayed.*): 왼쪽은 DAGR GPS 수신기 실물 사진으로, 현재 위치(MGRS 좌표), 고도, 속도, 날짜 등이 표시된 도트 매트릭스 화면과 F1/F2/F3, PWR/QUIT, BAT/MENU 등의 버튼이 보인다. 오른쪽 상단에는 "DANGER! TARGET POSITION SAME AS YOUR POSITION! RE-CHECK!" 경고, 하단에는 "WARNING! TARGET IS 123.44m FROM YOU!" 경고가 표시돼 있다. 배터리 교체 후 목표 좌표가 자신의 위치로 리셋되는 *battery*·*target* 개념 상호작용 결함을 사후 경고 메시지로 보완한 것을 보여주는 사례다.
+
 2. **맥락 변화로 인한 미스피트**: 팬데믹으로 화상 회의가 일반화되자, *slideshow* 개념의 전체 화면 모드가 화상 회의 앱의 패널을 가리는 문제 발생. Apple Keynote는 "창 모드로 재생" 옵션 추가로 해결.
 
 3. **구버전에서 작동했던 것이 다시 안 됨**: Apple Numbers의 *range* 개념 — 구버전은 범위 마지막 행 아래에 행 추가 시 범위에 포함됐지만, 새 버전에서는 포함되지 않아 실무에 큰 불편. Microsoft Excel도 동일한 결함.

wiki/sources/EOS-ch6-concept-composition.md

@@ -30,6 +30,8 @@ updated: 2026-04-30
 
 개념들이 대부분 독립적으로 동작하며, 최소한의 동기화(주로 데이터 일관성 유지용)만 존재.
 
+> **fig. 6.1** (*A todo app showing the tasks carrying the label "chores."*): Todoist 앱 스크린샷으로, 왼쪽 사이드바에 Inbox, Today, Upcoming, Projects, Labels(chores 3, tech 1, urgent 1, finances 1) 계층이 보이고, 오른쪽 메인 패널에 "chores" 레이블이 선택되어 "shovel snow off driveway (chores, urgent)", "pay estimated taxes (chores, finances)", "install new router (chores, tech)" 세 태스크가 표시돼 있다. *todo* 개념과 *label* 개념이 자유 조합된 결과로, 각 태스크에 여러 레이블이 붙고 레이블 클릭 시 해당 태스크들이 필터링된다.
+
 **예시**: Todoist의 *todo* + *label* 조합
 
 ```
@@ -43,6 +45,8 @@ sync todo.delete (t)
 
 동기화 하나: 태스크 삭제 시 해당 태스크의 레이블도 자동 제거. 이 동기화가 없으면, 삭제된 태스크가 레이블 검색 결과에 나타나는 이상 동작이 발생한다.
 
+> **fig. 6.4** (*A free composition of todo and label concepts. In the diagram (right), the circles on the left represent actions provided to the user, and the black arrow denotes the synchronization.*): 다이어그램은 두 개의 박스(todo, label)가 나란히 있고, 각 박스 왼쪽에는 사용자에게 제공되는 행동(원으로 표시)이, 오른쪽에는 개념 내부 행동(add, delete, complete / affix, detach, find, clear)이 나열돼 있다. todo의 delete와 label의 clear 사이에 굵은 화살표가 하나 연결돼 있다 — 오직 하나의 동기화만으로 두 개념이 연결된 자유 조합 구조를 보여준다.
+
 **"존재 결합(existence coupling)"**: 두 개념이 동일한 객체 집합을 참조한다는 사실만 공유. 나머지는 완전히 독립.
 
 ### 2. 협력 조합(Collaborative Composition)
@@ -65,6 +69,8 @@ sync email.receive (todo-user, m)
 
 *email* 개념의 `receive` 행동과 *todo* 개념의 `add` 행동이 동기화돼, 특정 이메일 주소로 메일을 보내면 자동으로 태스크가 추가된다.
 
+> **fig. 6.6** (*A collaborative composition of todo and email concepts. The diagram describes the synchronization only partially: the arrow from receive to add does not imply that every email.receive leads to a task.add; as the text says, only messages to todo-user are relevant.*): 세 개의 박스(todo, label, email)가 세로로 나열되고, 각 박스 좌우에 행동 목록이 있다. todo-label 간에는 delete→clear 화살표(이전 자유 조합), email.receive→todo.add 화살표가 추가로 표시돼 있다. 세 개념이 두 개의 동기화로 연결된 협력 조합 구조를 보여준다 — receive 화살표는 이메일 수신 이벤트가 todo 태스크 추가를 유발함을 나타낸다.
+
 **협력 조합의 활용 패턴**:
 - **Logging**: 이벤트 추적 개념과 다른 개념 조합
 - **Suppression**: 접근 제어 개념이 특정 행동을 차단
@@ -105,6 +111,8 @@ sync label.detach (t, 'pending')
 
 **사례 1**: Apple Calendar — 이벤트 삭제 시 초대 거절 알림이 자동 발송됨. 스팸 이벤트 삭제 시 스패머에게 이메일 주소 유효성을 알려주는 역효과. (2017년 수정됨)
 
+> **fig. 6.9** (*The original Apple Calendar dialog that unhelpfully always synchronized deleting an event with notifying the sender (left), and the most recent version (right) that fixes the problem by making the synchronization optional.*): 왼쪽은 구버전 다이얼로그로 "Are you sure you want to delete this event? Deleting this meeting will remove it from your calendar and notify the invitees that this event has been deleted. You can't undo this action." — 취소 또는 삭제 버튼만 있어 알림 발송이 강제됨. 오른쪽은 수정된 버전으로 "Delete and Notify"와 "Delete and Don't Notify" 두 버튼이 제공돼 사용자가 알림 여부를 선택할 수 있다. 과잉 동기화(삭제+알림 강제 결합)가 수정된 설계 개선의 전후를 명확히 보여준다.
+
 **사례 2**: Tumblr — 게시물 제목 끝에 `?`를 붙이면 자동으로 댓글이 활성화됨.
 
 **사례 3**: Therac-25 방사선 치료기 — 전자빔 전류 값과 평탄화 필터 위치 동기화 결함으로 과다 조사 사망 사고 발생.

wiki/sources/EOS-ch7-concept-dependence.md

@@ -46,6 +46,8 @@ updated: 2026-04-30
 - *recording* → *q&a*: 오디오를 질문에 첨부
 - *identification* → *recording*: 식별 결과를 녹음과 연결
 
+> **fig. 7.1** (*Concept dependencies for a bird song app. A solid arrow denotes a primary dependence and a dashed arrow a secondary dependence. The core concepts are in bold.*): BirdSong 앱의 개념 의존 다이어그램으로, 5개의 노드(user, upvote, identification, recording, q&a)가 배치돼 있다. q&a는 굵은 테두리(핵심 개념)로 표시되고, 모든 개념이 직·간접으로 q&a를 향해 화살표가 향한다. user→upvote 간에는 점선(부 의존), user→q&a와 upvote→q&a는 실선(주 의존), identification→recording→q&a는 실선 체인으로 연결된다. 다이어그램 하나로 앱의 핵심 개념, 의존 방향, 구현 단계화 순서가 한눈에 드러남을 보여준다.
+
 **다이어그램이 주는 것들**:
 
 1. **핵심 개념 식별**: *q&a*는 모든 개념이 직·간접으로 의존. 없으면 앱 자체가 불가능
@@ -59,6 +61,8 @@ updated: 2026-04-30
 
 ## 실제 앱 구조 분석
 
+> **fig. 7.2** (*Concept dependencies for Facebook (left) and Apple Safari (right).*): 왼쪽 Facebook 다이어그램: post(굵은 테두리·핵심)를 중심으로 comment→post, reply→comment, user→post(실선)·comment·reply·tag·like(점선), friend→user+post, tag→user+post, like→post(실선)·comment·reply(점선) 구조가 실선과 점선으로 연결된다. 오른쪽 Safari 다이어그램: url(굵은 테두리)을 중앙에 두고, 위에 bookmark·favorite·frequently visited·reading list, 왼쪽에 certificate·cache, 아래에 html→form→autofill, 오른쪽에 cookie←private browsing이 배치된다. 두 앱의 개념 구조적 차이 — Facebook은 소셜 관계 중심, Safari는 URL 중심 — 가 다이어그램으로 명확히 대비된다.
+
 ### Facebook
 
 핵심 구조:
@@ -83,6 +87,8 @@ updated: 2026-04-30
 
 **Safari 분석 통찰**: bookmark 변형 개념들(*favorite*, *frequently visited*, *reading list*)이 서로 매우 유사하다. 오프라인 읽기와 읽음 표시를 모든 bookmark에 추가하고, 자주 방문한 사이트를 일반 bookmark 폴더로 통합하면 더 시너지적 설계가 가능하다.
 
+> **fig. 7.3** (*Concept dependencies for Apple Keynote.*): Keynote 개념 의존 다이어그램으로, slide(굵은 테두리·핵심)가 중앙 하단에 자리잡고 있다. 상단에 theme(부 의존으로 master·text style에 점선), master→special block→slide, text style→paragraph·text block·shape(실선), shape style→shape(점선), layer→shape+text block(점선), animation→slide(실선)·text block·shape(점선), group→shape(점선), comment·presenter note·transition·outline→slide(실선) 구조가 펼쳐진다. Keynote의 복잡한 개념 구조가 slide 하나를 축으로 어떻게 계층화돼 있는지를 시각화한다.
+
 ### Apple Keynote
 
 핵심 구조:

wiki/sources/EOS-ch8-concept-mapping.md

@@ -24,6 +24,8 @@ UI 설계자는 다음을 결정한다:
 
 **Oracle Java 설치 다이얼로그 예시**: "Install"과 "Remove" 두 버튼이 있는 다이얼로그. "Remove"가 기본 선택으로 강조돼 있어 업그레이드하러 온 사용자가 혼란에 빠진다. *install* 개념의 두 운영 원칙(설치 vs. 제거)을 별도 워크플로로 분리했다면 명확했을 것이다.
 
+> **fig. 8.1** (*A puzzling dialog in a Java installation process. What does "remove" mean?*): "Install Java 8 Update 281" 다이얼로그로, Oracle Java 로고 아래 "Welcome to Java – Updated License Terms" 제목과 라이선스 변경 안내 문단이 표시돼 있다. 하단에 "Install"(왼쪽, 강조 없음)과 "Remove"(오른쪽, 어두운 배경으로 기본 선택) 두 버튼이 있다. 업그레이드 프롬프트를 클릭해서 설치 프로그램을 실행한 사용자에게 "Remove"가 기본 버튼으로 표시되는 매핑 오류 — 사용자 의도(업그레이드)와 UI 기본값(제거)의 불일치를 보여준다.
+
 **개선 방향**:
 - 설치와 제거를 별도 탭이나 흐름으로 분리
 - "Remove"보다 "Uninstall"이 의미를 더 정확히 전달
@@ -42,10 +44,16 @@ Apple의 "Do Not Disturb" 개념도 "repeated calls" 옵션 아래에 작은 글
 1. **서명 수 조작**: 페이지 로드 시 실제 서명 수보다 낮은 숫자에서 시작해 실제 수까지 실시간으로 올라가는 애니메이션 — 가짜 실시간 활동 인상 조작.
 2. **기부 오해 유도**: 서명 후 나타나는 "기부" 요청이 청원 주최자에게 가는 것처럼 보이지만, 실제로는 change.org의 광고 비용. 개념의 운영 원칙을 숨김.
 
+> **fig. 8.2** (*The petition owner's view of a change.org petition reveals a small deception: signers are shown a lower count (the 683 on the right in the body of the petition) than the actual count visible to the owner (the 698 in the admin bar at the top left).*): "Save Newton's Parks!" 청원 페이지로, 왼쪽 상단 관리자 바에 "698 supporters"가 표시되고, 오른쪽 청원 본문에는 "683 have signed."라고 표시돼 있다. 청원 소유자에게만 보이는 실제 수(698)와 방문자에게 보이는 낮은 수(683)의 차이가 가짜 실시간 증가 애니메이션의 시작점임을 보여준다. 의도적 매핑 왜곡으로 실시간 활동 인상을 조작하는 다크 패턴 사례다.
+
+> **fig. 8.3** (*An invitation to support a change.org petition. Or is it?*): change.org 서명 후 화면으로, "Can you chip in $2 to get this petition on the agenda?" 요청과 함께 겨울 공원 사진, "Become a hero. Join the 1,045 people helping reach the next goal." 문구, "Yes, I'll chip in $2 or more"(강조 버튼)와 "No, I'll share instead" 버튼, PayPal 결제 옵션이 표시돼 있다. 기부금이 청원 주최자가 아닌 change.org 광고비로 사용된다는 사실을 숨기고, 청원을 지원하는 것처럼 오해하게 만드는 기만적 매핑 사례다.
+
 ### Amazon Prime 사례
 
 두 버튼("Try Prime FREE" — 노란색, "Continue with FREE One-Day Delivery" — 파란색)이 모두 Prime 가입 액션에 연결됨. 가입 거부 옵션은 훨씬 작은 파란색 링크로 숨겨짐. 두 개의 버튼이 실제로는 하나의 행동을 공유한다는 사실을 매핑이 숨긴다.
 
+> **fig. 8.4** (*Two buttons, one stacked above the other (and colored yellow and blue on the site itself), for apparently distinct actions of the Amazon Prime concept, but actually both bound to the same action.*): Amazon UK 페이지로, "Daniel N. Jackson, why wait for delivery? Get FREE One-Day Delivery on this order — Start your 30-day free trial of Amazon Prime" 제목 아래 Standard/One-Day/Same-Day Delivery 모두 "FREE"로 표시된 비교 표가 있다. 오른쪽 하단에 "Try Prime FREE"(어두운 강조 버튼)와 그 아래 "Continue with FREE One-Day Delivery / Pay later"(두 번째 버튼)가 나란히 있고, 왼쪽에 작은 링크 "Continue and don't gain Amazon Prime benefits"가 숨어 있다. 두 버튼이 실제로는 같은 Prime 가입 액션에 연결된다는 사실이 매핑으로 숨겨진 다크 패턴이다.
+
 ## 복잡한 조합 매핑: Gmail 레이블의 수수께끼
 
 Gmail은 *label* 개념과 *conversation* 개념을 조합하면서, **레이블은 메시지에 부착하지만 레이블 표시는 대화(conversation)에 표시**한다.
@@ -54,8 +62,12 @@ Gmail은 *label* 개념과 *conversation* 개념을 조합하면서, **레이블
 - 대화가 "hacking"과 "meetups" 두 레이블을 갖는 것처럼 보임
 - 그러나 각각의 레이블로는 검색 결과에 나타나지만, 두 레이블을 동시에 검색하면 결과 없음 (두 레이블이 서로 다른 메시지에 부착돼 있기 때문)
 
+> **fig. 8.5** (*Labeling in Gmail: a conversation with two labels, "hacking" and "meetups."*): Gmail 받은 편지함 화면으로, Primary와 Social 탭 아래 "Alyssa, me 3"라는 대화 항목에 "hacking", "meetups", "javascript" 세 레이블 태그가 표시돼 있다. 레이블이 개별 메시지가 아닌 대화 단위로 표시되기 때문에, 서로 다른 메시지에 부착된 레이블들이 마치 하나의 대화가 두 레이블 모두를 갖는 것처럼 보인다. 이것이 아래 fig. 8.6의 검색 이상 현상의 원인이다.
+
 실무적 문제: *sent* 뷰를 보면 내가 보낸 메시지가 포함된 대화 전체가 보이고, 내가 보내지 않은 메시지들도 포함된다. 설계자들이 이 문제를 인지했지만 아직 완전히 해결되지 않았다.
 
+> **fig. 8.7** (*Filtering on sent messages in Gmail: the sent message is the first of the two.*): Gmail "in:sent" 검색 결과 화면으로, "javascript" 제목의 대화가 펼쳐져 있다. 상단에 "Inbox", "hacking", "meetups" 레이블 태그가 있고, 첫 번째 메시지는 Alyssa P. Hacker가 "to me"로 보낸 "Reminds you of the old days, eh?", 두 번째는 Ben Bitdiddle이 "to Alyssa"로 보낸 "Yes, it does."가 표시된다. 보낸 메시지만 보려 했지만 관련 대화 전체(내가 보내지 않은 메시지 포함)가 표시되는 *label*+*conversation* 조합 매핑의 실용적 문제를 보여준다.
+
 ## 명확하지만 사용하기 어려운 매핑: Backblaze 복원
 
 파일 버전을 복원하는 흐름: 날짜 범위 설정 → 폴더 트리 로딩(~20초) → 파일 선택 → 다운로드. 손상된 파일의 마지막 정상 버전을 찾으려면 날짜를 하루씩 소급해가며 반복해야 하는데, 매번 폴더 트리가 리셋된다.
@@ -70,6 +82,8 @@ Gmail은 *label* 개념과 *conversation* 개념을 조합하면서, **레이블
 
 **실제 Apple Mail 동작(유지)**: 플래그가 해제돼도 메시지가 목록에 남아있어, 즉시 재플래그 가능. 뷰를 나갔다 돌아오면 그때 목록이 갱신됨.
 
+> **fig. 8.10** (*A skillful mapping of the flag concept in Apple Mail: messages with yellow flags are being shown. The flag has been removed from the first message, but the message is still listed.*): Apple Mail 화면으로, 왼쪽 사이드바에 Inbox, VIPs, Flagged(Orange 2, Red 216, Purple, Yellow 5), Drafts 18, Sent, Trash, Archive 등이 나열돼 있고, "Yellow" 폴더가 선택된 상태다. 오른쪽 메시지 목록에는 노란 플래그가 제거됐음에도 여전히 리스트에 남아있는 첫 번째 메시지(ThermoCheck)와 다른 5개의 메시지가 표시돼 있다. 플래그 해제 후 즉시 목록에서 사라지지 않도록 함으로써 실수로 해제했을 때 바로 복구할 수 있도록 한 사려 깊은 매핑 설계를 보여준다.
+
 **교훈**: 매핑은 단순한 액션-상태 연결이 아니라 **전형적 사용 시나리오와 사용 패턴**을 고려해야 한다.
 
 ## 모호한 액션 해소: Adobe Lightroom 컬렉션
@@ -78,6 +92,8 @@ Gmail은 *label* 개념과 *conversation* 개념을 조합하면서, **레이블
 
 두 컬렉션이 동시에 선택된 상태에서 한 아이템을 제거하려 하면 어느 컬렉션에서 제거할지 모호하다. Lightroom은 처음에 에러 메시지를 표시하다가, 나중에 선택된 모든 컬렉션에서 동시에 제거하도록 변경했다. 이 문제는 UI 위젯 설계의 한계에서 비롯된다.
 
+> **fig. 8.11** (*A mapping dilemma for the collection concept in Adobe Lightroom: with two collections showing, selecting a photo for removal does not identify which collection to remove it from.*): Adobe Lightroom 화면으로, 왼쪽 패널에 "Website > American Spaces" 하위에 "Possibles(68)"와 "Selected(33)" 두 컬렉션이 모두 선택(하이라이트)된 상태다. 오른쪽에는 풍경 사진 6장이 그리드로 표시돼 있으며, 두 번째 사진이 선택(흰 테두리)돼 있다. 두 컬렉션이 동시에 선택된 상태에서 사진 삭제를 시도할 경우 어느 컬렉션에서 제거할지 매핑이 결정할 수 없는 모호성 문제를 시각화한다.
+
 ## 비표준 위젯 필요: "없음" 값 입력
 
 *partial style* 개념: 서식의 일부 속성만 지정하는 스타일. 예: 이탤릭만 지정하고 폰트 크기는 지정 안 함.

wiki/sources/EOS-endnotes-context.md

@@ -113,6 +113,12 @@ Bruno Latour의 "inscription(기입)": 기계는 이전에 수동으로 수행
 
 소프트웨어 개념에의 적용: 레스토랑 예약, 소셜 미디어 팔로우 등 많은 개념이 원래 인간 프로토콜로 시작해 소프트웨어에 기입된다. 이것은 은유가 아니라 **문자 그대로의 동일한 개념**이다.
 
+## 작은 설계 결함과 더 큰 고통 (Note 89)
+
+"작은 결함처럼 보이는 설계 문제도 개발자에게는 코드 복잡성이라는 큰 고통을 유발한다." 소프트웨어 설계 결함은 사용자에게 미묘하게 보이더라도, 그것을 구현하거나 유지하는 개발자에게는 심각한 내부 복잡성을 초래한다.
+
+> **fig. E.6** (*트레파닝: 작은 설계 결함의 은유 — Hieronymus Bosch,* The Extraction of the Stone of Madness, ~1494–1516): 원형 패널화. 돌팔이 외과의가 환자 두개골에서 "광기의 돌"을 수술하는 장면 — 왼쪽 수도사는 깔때기 모자를, 오른쪽 여인은 책을 머리에 올리고 있다. Jackson의 인용: 발굴된 두개골의 트레파닝 구멍은 작아 보이지만 그것이 형성될 당시의 극심한 고통을 상기시킨다 — 설계의 작은 결함도 코드에는 엄청난 복잡성과 고통을 남긴다.
+
 ## 설계 비판 vs. 사용자 테스트 (Note 38)
 
 **Jackson의 입장**: 경험적 평가는 과대평가되어 있다.
@@ -125,6 +131,12 @@ Google의 Douglas Bowman (첫 시각 디자이너, 2009 퇴사): "모든 결정
 
 ## 특정성 원칙의 보충 (Note 94-102)
 
+### Gmail label vs. category 혼동 (Note 94)
+
+Google이 label 개념 도움말을 작성하면서 첫 문장에 "categories"를 사용 — label과 category가 실은 중복 개념임을 공식 문서가 스스로 드러낸 비의도적 유머.
+
+> **fig. E.7** (*Gmail 도움말 "Using labels" 화면*): "Labels help you organize your messages into categories – work, family, to do, read later, jokes, recipes, any category you want. Labels do all the work that folders do, but with an added bonus: you can add more than one to a message." — label을 설명하면서 categories로 시작. label과 category가 모두 메시지 분류를 위한 중복 개념임을 구글 공식 문서가 의도치 않게 확인.
+
 ### 오버로딩의 종류
 
 | 오버로딩 유형 | 설명 | 예 |
@@ -136,6 +148,10 @@ Google의 Douglas Bowman (첫 시각 디자이너, 2009 퇴사): "모든 결정
 
 **Photoshop 크롭 사례(Note 101)**: `cropping`에 `resampling`이 편승 → CS6에서 분리. 설계 개선의 좋은 예.
 
+> **fig. E.8** (*손톱깎이: 기능 공유(좌) vs. 기능 분리(우) — Ulrich [145]*): 좌: 일반 손톱깎이 스케치 — 단일 금속 스트립이 스프링(탄성)과 절단날(날카로운 모서리) 두 기능을 겸함. 우: Karl Ulrich가 상상한 "부품당 하나의 기능" 원칙 설계의 손톱깎이 단면도 — 스프링과 날이 분리된 복잡한 기계 구조. 결론: 기계 설계의 과부하는 소형화·비용 절감에 유리하지만, 소프트웨어에서는 이점이 없고 두 직교 개념이 단일 과부하 개념보다 이해하기 쉽다 (Note 98).
+
+> **fig. E.9** (*Photoshop CS5 cropping 인터페이스*): 상단 툴바: Width 6 in, Height 4 in, Resolution [빈칸], pixels/inch. 벽돌 건물·나무 이미지에 크롭 핸들 표시. Resolution 필드의 존재가 핵심 — cropping 개념에 resampling 개념이 편승: 크롭 프레임 설정이 동시에 출력 해상도·치수를 지정하게 되어, 전체 이미지를 선택한 "빈 크롭"도 파일을 변경할 수 있는 반직관적 동작 발생. CS6(2012)에서 두 개념이 분리됨 (Note 101).
+
 ### 사회적 오버로딩 (Note 99)
 
 대학 멘토 제도: 지원/조언 역할 + 승진 평가 역할 → 근본적 이해충돌.

wiki/sources/EOS-endnotes-formalism.md

@@ -35,6 +35,8 @@ state(<create(i0), delete(i0)>) = {accessible: {}, trashed: {i0}}
 state(<create(i0), delete(i0), empty()>) = {accessible: {}, trashed: {}}
 ```
 
+> **fig. E.3** (*trash 개념의 부분 상태 기계 다이어그램*): 3개 상태 — 초기 `{accessible:{}, trashed:{}}`, 좌측 `{accessible:{i0}, trashed:{}}`, 우측 `{accessible:{}, trashed:{i0}}`. 전이: `create(i0)` (초기→좌측), `delete(i0)` (좌측→우측, accessible에서 제거·trashed에 추가), `restore(i0)` (우측→좌측, trashed에서 accessible로 복원), `empty()` (우측→초기, trashed 영구 삭제). 동일 상태·입력에 최대 하나의 후속 상태 — 결정론적 상태 기계.
+
 ### 전이 관계, 전제조건, 교착 상태
 
 액션 `A` (인수 집합 X)의 의미론:
@@ -121,6 +123,8 @@ define(s, f); assign(e1, s); assign(e2, s); define(s, f') {e1.format = e2.format
 **순열 불변성(permutation invariance)으로 형식화:**
 타입 T가 개념 C에서 비해석적이면, T의 임의 순열 p에 대해 p(t)도 C의 트레이스이고 `state(p(t)) = p(state(t))`.
 
+> **fig. E.4** (*style 개념(좌)과 Gmail label 개념(우)의 관계형 데이터 모델*): 좌: `Element --(assigned)--> Style --(defined)--> Format`, 점선으로 `Element --(format)--> Format` 파생 관계. 우: `Conversation --(messages)--> Message --(labels)--> Label`, 점선으로 `Conversation --(displays)--> Label` 파생 관계. 파생 상태(derived state)는 두 기본 관계의 합성 경로로 정의됨 — 스타일 개념에서 Element의 실제 format은 Style을 거쳐 결정되며, Gmail에서 대화의 레이블은 메시지를 거쳐 집계됨.
+
 ## 조합의 의미론 (Note 64)
 
 ### 조합 = 트레이스의 인터리빙
@@ -144,6 +148,8 @@ sync action1(x)
 - 조합은 안전성 속성은 보존
 - 활성성은 제한 가능 (예: access control 개념이 다른 개념의 액션을 억제)
 
+> **fig. E.5** (*Photoshop에서의 layer + mask 개념*): 흑백 사과 이미지 편집 화면. Layers 패널: "Curves 1" 조정 레이어(흰 원 마스크 = 사과 영역만 조정 적용) + "Background" 원본 레이어. 마스크가 Curves 조정을 사과에만 한정 — 원본 픽셀 불변(비파괴 편집). layer 개념 + mask 개념의 시너지 조합: 두 개념 각각의 행동이 조합 후에도 보존되면서 비파괴 로컬 편집이라는 창발적 기능 실현.
+
 ### CSP와의 관계
 
 개념 조합의 의미론은 Tony Hoare의 CSP(Communicating Sequential Processes)에서 파생.

wiki/sources/EOS-part1-motivations.md

@@ -40,6 +40,8 @@ Part I(Ch1~3)은 왜 소프트웨어 설계의 핵심이 "개념"이어야 하
 
 저자는 파일이 지속적으로 업로드·복원 가능하다고 가정했지만, 실제 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* 개념을 사용한다. 이로 인해:
@@ -49,6 +51,16 @@ Dropbox는 이름(name)을 파일 자체의 메타데이터가 아닌, 부모
 
 이것은 버그가 아니라 *개념 설계* 문제다.
 
+> **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 수준
 
 | 수준 | 내용 | 관심사 |
@@ -59,17 +71,27 @@ Dropbox는 이름(name)을 파일 자체의 메타데이터가 아닌, 부모
 
 개념 수준이 가장 근원적이다. 언어·물리 수준의 문제처럼 보여도 사실 개념 수준의 결함인 경우가 많다.
 
+> **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* 개념을 쓴다.
 
 ### 개념이 제품 차별화 요소
@@ -82,10 +104,16 @@ Dropbox는 이름(name)을 파일 자체의 메타데이터가 아닌, 부모
 | 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* 개념처럼, 개념 하나가 전체 고객 경험을 통합할 수 있다.

wiki/sources/EOS-part3-principles.md

@@ -32,6 +32,8 @@ Part III(Ch9~11)는 좋은 개념 설계를 위한 세 가지 핵심 원칙을
 
 명백히 필요하지만 구현되지 않은 개념들:
 
+> **fig. 9.1** (*How lack of a correspondent concept in email leads to arbitrary search results.*): Apple Mail 검색창에 "Claudia Marbach"를 입력한 결과로, People 섹션에 "Claudia Marbach claudiammarbach@gmail.com", "Claudia Marbach (Google Docs) — comments-nore...", "Claudia Jackson Marbach — claudia@lcs.mit.edu", "Daniel Jackson — dnj@mit.edu", "Sender contains: Claudia Marbach" 등 서로 다른 이메일 주소를 가진 여러 항목이 나열된다. *correspondent* 개념이 없어 같은 사람(Claudia Marbach)이 여러 이메일 주소로 분산되고, 심지어 관련 없는 "Daniel Jackson"도 검색 결과에 포함되는 임의적 검색 결과 문제를 시각화한다.
+
 - **Email *correspondent* 개념 부재**: 발신자를 고유하게 식별하는 개념이 없어 Apple Mail에서 동일인을 여러 이름으로 검색해야 함. 오픈 이메일 시스템에서 구현이 어렵다는 기술적 제약이 있다.
 - **백업의 삭제 경고 개념 부재**: 대부분의 백업 유틸리티는 원본 기기에서 삭제된 파일이 30일 후 클라우드에서도 삭제된다. 의도치 않은 삭제를 탐지·경고하는 개념이 없다.
 - **PowerPoint의 *style* 개념 부재**: Keynote는 최근 추가했지만 PowerPoint는 여전히 없어 일관된 서식 유지가 어렵다.
@@ -56,6 +58,8 @@ Part III(Ch9~11)는 좋은 개념 설계를 위한 세 가지 핵심 원칙을
 - *rule*: 조건에 맞는 메시지에 액션 적용
 - 공통 목적(메시지 필터링)인데 기능이 불완전하게 겹침. Gmail은 이를 단일 개념으로 통합.
 
+> **fig. 9.3** (*Apple Mail's filters (top) and rules (below), embody two versions of one concept.*): 상단에 Apple Mail의 필터 바가 표시되고 "FROM▾ Daniel Jackson SUBJECT▾ concept ✕" 조건이 설정돼 있다. 하단에는 룰 편집 다이얼로그로, Description: "Rule", "If any of the following conditions are met:" 아래 "From contains Daniel Jackson"과 "Subject contains concept" 두 조건이 있고, "Perform the following actions:" 아래 "Move Message to mailbox: Concept Design"이 설정돼 있다. 동일한 메시지 필터링 목적을 수행하는 두 개의 다른 UI — 상단의 *filter*(일시적·뷰 한정)와 하단의 *rule*(영구적·액션 포함)이 중복 개념을 이루고 있음을 보여준다.
+
 ### 과부하 개념(Overloaded concepts)
 
 하나의 개념이 여러 목적을 가질 때. 4가지 원인:
@@ -67,6 +71,10 @@ Part III(Ch9~11)는 좋은 개념 설계를 위한 세 가지 핵심 원칙을
 | **Emergent purpose** | 시간이 지나며 새 목적이 생김 | 이메일 *subject line* = 요약 → listserv 출처 표시 → 대화 그룹화 |
 | **Piggybacking** | 기존 개념에 새 목적 얹기 | Epson 프린터 드라이버: *paper size* 개념에 *paper feed* 붙이기 |
 
+> **fig. 9.4** (*Example of denied purpose: using commits for backup. The lower, gray path is a separate 'branch'...*): Git 커밋 히스토리 다이어그램으로, 굵은 검은 선 위에 여러 커밋 점이 일렬로 나열된 주 브랜치가 있다. 중간 지점에서 회색 선이 분기해 "feature setup", "backup just in case", "feature completion" 레이블이 붙은 세 개의 회색 점을 거쳐 다시 주 브랜치로 합류한다. *commit* 개념이 버전 히스토리를 위해 설계됐지만, 사용자가 "backup just in case"와 같이 단순 백업 목적으로 커밋을 남기는 목적 부정(denied purpose) 사례를 시각화한다.
+
+> **fig. 9.6** (*Epson printer driver: paper feed piggybacked onto paper size.*): Epson Stylus Photo R2400 Page Setup 다이얼로그로, Paper Size 드롭다운 메뉴가 열려 있다. "US Letter"를 선택하면 하위 메뉴에 "US Letter (Manual – Front)", "US Letter", "US Letter (Manual – Roll)", "US Letter (Sheet Feeder – Borderless)", "US Letter (Manual – Roll (Borderless))" 등 급지 방식이 포함된 여러 옵션이 나타난다. 종이 크기(paper size) 개념에 급지 방식(paper feed)이 피기백으로 얹혀, 크기 선택 UI에서 급지 방식도 함께 선택해야 하는 과부하 개념 문제를 보여준다.
+
 ### Facebook *like* 개념 분석
 
 Facebook *like*는 세 목적을 동시에 가진다:
@@ -82,6 +90,12 @@ Facebook *like*는 세 목적을 동시에 가진다:
 
 **해결책**: 세 개념으로 분리 — *reaction* + *recommendation* + *profiling*
 
+> **fig. 9.7** (*Shooting with a square aspect ratio: a great feature of mirrorless digital cameras.*): Fujifilm 미러리스 카메라 뷰파인더 화면으로, 여성 피사체를 촬영하는 장면이다. 뷰파인더 상단에 ISO 100, 잔여 702 프레임, RAW L 표시가 있고, 중앙 하단에 정사각형 마스킹 영역이 흰색 테두리로 표시돼 있다. 하단에 A(자동), 초점 모드, F4.0 조리개, AUTO 1600 ISO가 표시된다. *image size/aspect ratio* 개념이 촬영 시 정사각형 크롭 미리보기를 제공하는 기능을 보여주며, 이후 fig 9.8에서 설명될 피기백 문제의 맥락이 된다.
+
+> **fig. 9.8** (*Piggybacking in Fujifilm cameras: Setting image size/aspect ratio (left); setting image quality (middle); choosing 'W' as quality greys out the size option...*): 세 패널로 구성된 Fujifilm SHOOTING MENU 화면이다. 왼쪽 패널은 이미지 크기/비율 설정으로 L:3:2(664), L:16:9(681), L:1:1(702), M:3:2(707) 등 크기와 화면비 조합이 나열된다. 중간 패널은 이미지 품질 설정으로 FINE, NORMAL, FINE+RAW, NORMAL+RAW, RAW 옵션이 표시된다. 오른쪽 패널은 전체 SHOOTING MENU로 IMAGE SIZE 항목이 회색 처리(비활성화)된 상태를 보여준다. RAW 품질을 선택하면 이미지 크기 옵션이 비활성화되는 피기백 설계 — 품질 개념에 크기 제어가 얹혀 있어 사용자가 독립적으로 설정하지 못하는 과부하 개념 문제를 시각화한다.
+
+> **fig. 9.9** (*The like concept in Facebook: the emoticons have tooltips that identify them as 'like,' 'love,' 'care,' 'haha,' 'wow,' 'sad,' and 'angry.'*): Facebook 게시물 하단 반응 영역으로, 7개의 이모티콘이 가로로 나열돼 있다. 왼쪽부터 엄지 위(like), 하트(love), 포옹하는 얼굴(care), 웃는 얼굴(haha), 놀란 얼굴(wow), 슬픈 얼굴(sad), 화난 얼굴(angry) 이모티콘이 표시된다. 하단에 "Like"와 "Comment" 버튼이 있다. Facebook *like* 개념이 단순한 '좋아요'를 넘어 7가지 감정 반응으로 확장된 상태를 보여주며, 동일한 *like* 개념 하에 상반된 감정(like vs. angry)이 공존하는 과부하 개념 문제를 시각화한다.
+
 ---
 
 ## Ch10 — 개념 친숙성(Concept Familiarity)
@@ -95,6 +109,8 @@ Facebook *like*는 세 목적을 동시에 가진다:
 
 ### 성공적 재사용: Twitter *follower*
 
+> **fig. 10.1** (*Barack Obama's Twitter profile shows an extraordinary number of followers (120.8 million) compared to those he follows (602.9 thousand).*): Barack Obama의 Twitter 프로필 페이지로, 파크 장면 커버 사진과 원형 프로필 사진이 표시된다. "Barack Obama @BarackObama"라는 이름 아래 파란색 인증 배지가 있고, "Dad, husband, President, citizen."이라는 바이오와 워싱턴 DC, obama.org, 1961년 8월 4일생, 2007년 3월 가입 정보가 표시된다. 하단에 "602.9K Following"과 "120.8M Followers"가 표시된다. *follower* 개념의 비대칭 구독 관계 — 팔로잉(602.9K)과 팔로워(1억 2080만명)의 극적인 차이가 *subscription* 개념(구독자가 많은 채널)의 재사용으로 자연스럽게 이해되는 사례다.
+
 Twitter는 *follower* 개념을 소개하면서 이미 알려진 *subscription* 개념임을 명시한다: "Following someone means you've chosen to **subscribe** to their Twitter updates." — 운영 원칙을 직접 제공하며, 기존 개념과의 연결로 학습 부담 제거.
 
 ### 재발명의 실패: PowerPoint *section* vs. Keynote *slide group*
@@ -110,10 +126,14 @@ Twitter는 *follower* 개념을 소개하면서 이미 알려진 *subscription*
 
 Keynote가 더 효과적인 이유: 처음부터 새로 만든 것이 아니라 친숙한 *outline tree* 개념을 재사용했기 때문.
 
+> **fig. 10.2** (*Organizing slides in Keynote and PowerPoint. On the left, the Keynote group concept, which reuses the familiar concept of the tree outline; in the middle, the PowerPoint section concept, which is novel and unfamiliar; on the right, some actions on sections whose behavior is unpredictable.*): 세 영역으로 구성된 화면이다. 왼쪽은 Keynote 슬라이드 패널로, 슬라이드 1, 8(concept familiarity), 9, 10(grouping slides - 들여쓰기 그룹화), 11이 트리 구조로 표시된다. 가운데는 PowerPoint의 "concept familiarity" 섹션 아래 슬라이드 8, 9, 10, 11이 나열된다. 오른쪽은 PowerPoint 섹션 메뉴로 "Add Section", "Rename Section", "Remove Section", "Remove Section and Slides", "Remove All Sections" 항목이 표시된다. Keynote는 친숙한 아웃라인 트리로 직관적 그룹화를 제공하는 반면, PowerPoint 섹션은 예측 불가능한 동작을 가진 새로운 개념을 사용함을 대비하여 보여준다.
+
 ### 확장이 친숙성을 깨뜨린 경우: Lightroom 내보내기 프리셋
 
 *preset* 개념은 반복 명령의 파라미터를 저장하는 친숙한 개념이다. Adobe Lightroom의 내보내기 다이얼로그는 여기에 "여러 프리셋 체크로 복수 내보내기" 기능을 추가했다. 결과: 프리셋 이름 클릭과 체크박스 클릭이 다른 동작을 함 → 사용자 혼란. 해법: *action* 개념처럼 별도의 "명령 시퀀스" 개념을 분리했어야 했다.
 
+> **fig. 10.3** (*The export dialog in Adobe Lightroom, which uses an unconventional variant of the preset concept. In addition to selecting a preset by clicking on its name (left), you can also check the box (right); this allows multiple presets to be selected, which allow the same set of photos to exported multiple times, with different settings each time.*): 두 상태의 Adobe Lightroom "Export One File" 다이얼로그가 나란히 표시된다. 왼쪽은 이름 클릭으로 "Export to DNG" 프리셋이 선택된 상태(하이라이트)로, 오른쪽 파라미터 패널이 숨겨져 있다. 오른쪽은 체크박스로 "Export to DNG"를 선택한 상태로, File Settings(DNG), Image Sizing, Output Sharpening 등 파라미터 섹션이 표시된다. 하단에 "Multiple Presets: Selected 1 Preset. Some sections are hidden when presets are checked Learn More..." 메시지가 있다. 이름 클릭(단일 선택)과 체크박스(복수 선택)가 다른 동작을 하는 비표준 확장이 친숙한 *preset* 개념의 직관성을 깨뜨린 사례다.
+
 ### 개념 인스턴스는 표준 동작을 따라야 한다
 
 친숙한 개념의 인스턴스라면, 표준 동작에서 벗어날 때는 명확한 이유가 있어야 하고 그 차이를 사용자에게 분명히 알려야 한다.
@@ -141,16 +161,22 @@ Keynote가 더 효과적인 이유: 처음부터 새로 만든 것이 아니라
 
 ### 미묘한 위반: 폰트 서식
 
+> **fig. 11.1** (*The format toggle concept in the first versions of MacWrite (1984).*): 1984년 MacWrite 워드 프로세서 화면으로, 상단에 Apple 메뉴, File, Edit, Search, Format, Font, Style 메뉴가 있다. Style 드롭다운이 열려 있고, "✓Plain Text ⌘P", "**Bold** ⌘B", "*Italic* ⌘I", "Underline ⌘U", "Outline ⌘0", "Shadow ⌘S", "Superscript ⌘H", "Subscript ⌘L" 항목과 아래에 9~24포인트 크기 선택이 표시된다. 본문에는 "MacWrite is a leading word processor for the Macintosh"라는 텍스트가 굵게, 이탤릭, 크게 서식이 적용돼 있다. 초기 *format toggle* 개념 — Plain/Bold/Italic/Underline 네 가지 속성을 토글로 전환하는 간단하고 직관적인 서식 개념의 원형을 보여준다.
+
 초기 *format toggle* + *typeface* 조합은 작동했다: 이탤릭 적용 시 이탤릭 폰트 파일로 전환, 볼드 적용 시 볼드-이탤릭 파일로 전환 (toggle 명세 유지).
 
 전문 폰트 등장 이후 문제: Helvetica Light에 볼드를 두 번 적용해도 Light로 돌아오지 않고 Regular가 됨 → *format toggle*의 "두 번 적용하면 원래 상태로 복귀" 운영 원칙 위반.
 
+> **fig. 11.2** (*Integrity violation example in TextEdit: bolding once (second line) turns the text from light to bold; bolding again (third line) leaves the text in regular, not light.*): Apple TextEdit 화면으로, 상단에 Helvetica 폰트 패밀리의 변형 목록(Regular, Oblique, Light, Light Oblique, Bold, Bold Oblique)이 드롭다운으로 표시된다. 본문에는 세 줄의 텍스트가 있다: 첫 번째 줄 "sample text in Helvetica Light"(Light 서체), 두 번째 줄 "**sample text in Helvetica Light, bold toggled**"(Bold 서체), 세 번째 줄 "sample text in Helvetica Light, bold toggled again"(Regular 서체). 볼드를 두 번 적용해도 원래의 Light로 돌아오지 않고 Regular가 되는 *format toggle* 무결성 위반 — "두 번 토글하면 원상복귀" 운영 원칙이 전문 폰트 환경에서 깨지는 현상을 명확히 보여준다.
+
 - **Apple TextEdit**: 위반 그대로
 - **Apple Pages**: 숨겨진 매직으로 복귀 동작 구현 → 다른 문제 유발
 - **Adobe InDesign**: 문자 스타일이 특정 폰트 패밀리에만 적용되는 비표준 동작
 
 이 문제는 근본적으로 해결되지 않았다. *format toggle* 개념과 더 정교해진 타이포그래피 개념들은 원천적으로 조화가 어렵다.
 
+> **fig. E.10** (*Apple Pages '09의 부분 스타일 정의 시도*): "New character style" 다이얼로그. 스타일 이름: "Emphasis". 체크박스로 적용할 속성 선택: Font: Magma Light, Size: 12.0 pt, Bold: Off, Italic: Off, Color, Shadow, Ligatures, Capitalization, Superscript, Baseline Shift, Underline, Strikethrough 등. 하단: Deselect All / Select Overrides 버튼. 2009년 Pages의 시도: 일부 속성만 포함하는 부분 스타일(partial style)로 format toggle 무결성 문제 우회. 그러나 폰트 패밀리를 TrueType/OpenType subfamilies로 분해하는 방식이 새로운 문제 유발 — Bold 변형이 없는 Magma Light 같은 subfamily는 볼드 적용이 불가능 (Note 111).
+
 ### 중대한 위반: Google Drive 동기화
 
 *synchronization* 개념의 운영 원칙: "한 컬렉션의 변경이 다른 컬렉션에 전파됨. 두 장소의 아이템 복사본은 동일해야 함."
@@ -165,6 +191,8 @@ Google Drive는 `.gdoc` 같은 Google 앱 파일을 로컬 디스크에 저장
 
 기술적으로 수정 가능한 문제이나 Google이 아직 우선순위를 두지 않고 있다.
 
+> **fig. 11.4** (*Integrity violation in Google Drive: the cloud-app concept breaks the synchronization concept. A user moved files out of his Google drive in order to make space in the cloud, but the files he moved turned out just to be links to files in the cloud that no longer existed.*): 세 단계로 구성된 다이어그램이다. 각 단계는 "Google drive in cloud"(구름 모양), "Google drive on client machine"(직사각형 박스), "Another directory on client machine"(직사각형 박스) 세 영역으로 이루어진다. 왼쪽(초기 상태): 클라우드와 클라이언트 폴더 양쪽에 book.gdoc과 book.pdf 아이콘이 있고, book.gdoc은 점선으로 클라우드 원본을 참조한다. 가운데(파일 이동 후): 클라이언트 Google Drive 폴더는 비어 있고, 다른 디렉토리에 book.gdoc과 book.pdf가 이동해 있다. 오른쪽(동기화 후): 클라우드도 비어 있고, 클라이언트의 다른 디렉토리에만 파일이 남아 있다. *cloud app* 개념(링크로만 저장)과 *synchronization* 개념(동일한 복사본 유지)의 조합이 *synchronization* 명세를 위반해 사용자의 파일을 영구적으로 잃게 만드는 무결성 위반 메커니즘을 단계별로 시각화한다.
+
 ### 세 원칙의 그림 요약 (Fig.11.5)
 
 - 목적과 개념 사이의 선: 개념이 목적을 충족
@@ -172,6 +200,8 @@ Google Drive는 `.gdoc` 같은 Google 앱 파일을 로컬 디스크에 저장
 - 개념 간 선: 조합(composition)
 - 점선 박스: 앱
 
+> **fig. 11.5** (*A pictographic summary of the principles of Chapters 9 to 11. A line between a purpose and a concept indicates that the concept fulfills the purpose; the broken line (for the integrity violation) indicates non-fulfillment, due to the interference of another concept; lines between concepts denote composition; dotted boxes represent applications.*): 세 가지 원칙을 6개의 미니 다이어그램으로 요약한 도식이다. 왼쪽 열 — **특정성(specificity)**: 목적과 개념이 1:1 대응(P1-C1, P2-C2)하는 정상 케이스, 오른쪽에 목적 없는 개념(C2 고립), 개념 없는 목적(P2 고립), 중복 개념(P1이 C1·C2 양쪽 연결), 과부하 개념(C1이 P1·P2 양쪽 연결) 4가지 위반 유형이 표시된다. 가운데 열 — **친숙성(familiarity)**: 다른 앱 A1·A2에서 동일 목적 P1에 동일 개념 C1을 사용하는 정상 케이스와, 다른 앱에서 동일 목적에 서로 다른 개념 C1₁·C1₂를 사용하는 친숙성 위반 케이스. 오른쪽 열 — **무결성(integrity)**: 조합 시에도 각 개념이 목적을 충족하는 정상 케이스와, 한 개념이 다른 개념을 깨뜨려(C2→C1 방향 화살표에 물결선) 목적-개념 연결이 끊기는 무결성 위반 케이스. Ch9-11 세 원칙의 핵심 아이디어가 통일된 시각 언어로 집약돼 있다.
+
 ---
 
 ## 핵심 인용