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

6.1 KiB

Raw Blame History

title, tags, source, chapter, updated

title

EOS Part I — 동기: 왜 개념 설계인가

핵심 아이디어

Part I(Ch1~3)은 왜 소프트웨어 설계의 핵심이 "개념"이어야 하는지를 동기 부여한다. Ch1은 저자의 연구 여정과 문제 의식을, Ch2는 구체적인 개념 예시와 설계 3 수준을, Ch3는 개념이 소프트웨어 설계 전반에서 수행하는 다양한 역할을 설명한다.

Ch1 — Why I Wrote This Book

소프트웨어 설계의 공백

저자는 Alloy(소프트웨어 설계 언어·분석 도구) 연구자로서, 공식 명세보다 설계(design) 자체에 더 흥미를 느꼈다. 설계는 "형태(form)를 맥락(context)에 맞추는" 활동이다(Christopher Alexander).

소프트웨어 공학과 HCI(인간-컴퓨터 상호작용) 연구 모두 설계 자체보다 결함 제거·경험적 방법으로 이동했다. 결과적으로 소프트웨어 설계는 이론적 토대 없이 일화적 경험칙에 의존해 왔다.

명료함(Clarity)의 중요성

소프트웨어 개발 성패를 결정하는 것은 언어, 도구, 관리 방법론이 아니다. 무엇을 만들려고 하는지 명확히 아는 것이다. 설계가 명확하면 코드도 명확하고, 문제도 명확히 진단된다.

개념의 기원

1960년대부터 "개념적 모델(conceptual model)"의 중요성은 인정받았다. 그러나 개념적 모델을 사용자의 멘탈 모델로 전달하는 것에만 집중했지, 그 자체를 설계 대상으로 다루지 않았다.

Ch2 — Discovering Concepts

개념이란

"A software product… is made of concepts, each a self-contained unit of functionality."

개념은 앱의 "분자"다. 화학 혼합물처럼 결합되지만, 각 개념의 속성과 행동은 어디에서나 동일하다.

예시 1: Backblaze 백업 개념의 오해

저자는 파일이 지속적으로 업로드·복원 가능하다고 가정했지만, 실제 Backblaze의 backup 개념은: (1) 주기적 스캔으로 변경 파일 목록 작성 → (2) 목록 기반 업로드 → (3) 스테이징 영역에서 복원 영역으로 이동의 세 단계를 거친다. 멘탈 모델과 실제 개념 간의 불일치가 혼란을 유발했다.

예시 2: Dropbox의 unix folder 개념

Dropbox는 이름(name)을 파일 자체의 메타데이터가 아닌, 부모 폴더의 항목(entry)에 귀속시키는 unix folder 개념을 사용한다. 이로 인해:

최상위 공유 폴더 이름 변경 → 본인에게만 변경
중첩 공유 폴더 이름 변경 → 모두에게 변경
삭제 시 동작도 이에 따라 달라짐

이것은 버그가 아니라 개념 설계 문제다.

설계의 3 수준

수준	내용	관심사
물리(Physical)	버튼, 레이아웃, 접근성	인간의 물리·인지 능력
언어(Linguistic)	아이콘, 메시지, 용어	문화·언어적 차이
개념(Conceptual)	행동과 상태의 본질	개념 구조의 설계

개념 수준이 가장 근원적이다. 언어·물리 수준의 문제처럼 보여도 사실 개념 수준의 결함인 경우가 많다.

멘탈 모델과 개념 설계

사용자의 멘탈 모델이 소프트웨어 실제 개념과 불일치할 때 사용성 문제가 생긴다.
해법은 사용자 교육이 아니라 단순·유연·명확한 개념을 설계하고, 사용자 인터페이스가 그 개념을 올바르게 표현하도록 하는 것이다.

Ch3 — How Concepts Help

개념이 앱을 정의한다

앱을 설명하는 가장 좋은 방법은 핵심 개념을 나열하는 것이다. Facebook = post + comment + like + friend; Gmail = email + label + conversation; Web = url + html + cache + bookmark.

앱 간 차이도 개념으로 설명된다. 문자 메시지 앱은 conversation 개념을 쓰고, 이메일은 mailbox/folder 개념을 쓴다.

개념이 제품 차별화 요소

앱/서비스	핵심 차별화 개념
Apple Macintosh (1984)	trash — 삭제의 취소
Photoshop	layer + mask — 비파괴 편집
VisiCalc (스프레드시트)	formula + reference
Calendly	event type
World Wide Web	url — 전역 고유 명칭

개념이 복잡성을 드러낸다

Photoshop의 layer·mask, 브라우저의 certificate·private browsing·page cache 같은 복잡한 개념들이 무엇인지 알면, 파워 유저가 되기 위해 무엇을 배워야 하는지 명확해진다.

디지털 전환에서의 개념

디지털 전환의 핵심은 새 기술 도입이 아니라 핵심 비즈니스 개념을 식별·통합·확장하는 것이다. Apple의 song 개념처럼, 개념 하나가 전체 고객 경험을 통합할 수 있다.

개념이 관심사를 분리한다

group 하나에 모든 기능을 넣는 대신, group(멤버십) + post(메시지 작성) + invitation(초대) + notification(알림) + moderation(관리) 등으로 분리하면:

설계자가 한 번에 하나의 측면에 집중할 수 있다
팀원들이 병렬로 작업할 수 있다
각 개념을 독립적으로 재사용할 수 있다

개념이 안전·보안을 담보한다

보안 설계의 핵심은 authentication, authorization, auditing 등의 개념을 올바르게 설계하는 것이다. 예: two-factor authentication의 capability 개념과의 상호작용이 피싱 취약점을 만든다.

핵심 인용

"Concepts characterize individual apps, app classes, and entire product families."

"Investing in core concepts is less flashy but likely to be more effective."

"Concepts are the essence of design for safety and security, where picking the right concepts and understanding their implications is paramount."

6.1 KiB Raw Blame History Unescape Escape