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