Files

minsung 78651d5da1 feat: EOS 엔드노트 컴파일 — 형식 의미론 + 배경 맥락 페이지 2개 추가

- EOS-endnotes-formalism: 개념의 수학적 의미론 (상태기계·트레이스·조합·CSP·동적 논리)
- EOS-endnotes-context: 역사·철학·비교 맥락 (Parnas·DDD·Alloy·기입 이론·오버로딩 분류)
- concepts-181-328 (엔드노트+참고문헌+인덱스) 전량 컴파일 완료

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

2026-04-30 16:23:16 +09:00

9.3 KiB

Raw Blame History

title, tags, source, updated

title

EOS 배경 맥락 — 역사, 철학, 비교

EOS 엔드노트의 역사적 기원, 철학적 배경, 관련 분야와의 비교를 정리한다.

소프트웨어 설계 vs. 소프트웨어 공학 (Note 5, 8)

Dijkstra의 "즐거움 문제"

Dijkstra는 두 문제를 구분했다:

정확성 문제(correctness problem): 프로그램이 명세를 만족하는가 → 수학적 형식화 가능
즐거움 문제(pleasantness problem): 명세 자체가 적절한가 → "비과학적"이라 간주

Jackson의 반박: 즐거움 문제가 오히려 더 중요하다. 이름을 "설계 문제"로 바꾸고, "구현 문제"와 대비해야 했다. Dijkstra의 분리가 소프트웨어 연구를 버그 제거에만 집중하게 만들었다.

David Liddle의 정의

"Software design is the act of determining the user's experience with a piece of software. It has nothing to do with how the code works inside."

설계 = 사용자 경험의 전체 명세. 코드 구조가 아닌 사용자가 경험하는 것이 핵심.

Alloy 언어 (Note 3)

Daniel Jackson이 설계한 언어 및 분석 도구:

관계(relation)에 기반한 단순하고 강력한 논리
Alloy Analyzer: SAT 솔버로 컴파일, 유한 범위 내 완전 검사 보장
설계 탐색 용도: 속성 검증보다 시나리오 시뮬레이션이 더 유용
최신 버전: 선형 시제 논리(LTL) 포함, 무한 모델 체킹 지원

개념 설계와 관련 분야 비교 (Note 14, 44)

기존 개념 모델링 분야와의 차이

구분	전통적 개념 모델링	EOS 개념 설계
목적	현실 세계 기술(descriptive)	소프트웨어 설계·발명(inventive)
초점	데이터 모델 (ER 다이어그램)	행동 중심
개념 정의	엔티티-관계	이름+목적+상태+행동+운영원칙
범위	전역 데이터 모델	개별 개념에 국소화된 미니 데이터 모델

Fowler 분석 패턴과의 차이 (Note 14)

Fowler의 "분석 패턴"은 재사용 가능한 개념 모델 — EOS 개념에 가장 가까운 선행 연구. 차이: 분석 패턴은 구조 중심이고 행동을 코드 레벨로 표현. EOS 개념은 구현 독립적으로 행동을 명세.

Domain-Driven Design과의 차이 (Note 14)

Evans의 DDD: 문제 도메인 모델을 구현 기반으로 사용.

Bounded context: 다른 영역에서 다른 도메인 모델 허용
EOS 개념 설계: 각 개념이 자체 데이터 모델을 가짐 → DDD를 더 정밀화

Abstract Types / Objects와의 차이 (Note 48)

	추상 타입	EOS 개념
수준	코드 레벨	설계 레벨
상호 참조	타입 간 연결 어려움	조합(composition)으로 명확히 연결
의존성 방향	OOP에서 역전되기 쉬움	개념 의존 다이어그램으로 명시적 표현

OOP에서의 문제: Post가 Comment를 포함하는 구조 → 의존성 역전. 개념 설계에서는 comment가 post에 의존 (올바른 방향).

개념의 역사적 기원 (Note 48)

개념	발명자/기원	연도
trash	Apple (Macintosh 팀)	~1983
folder/directory	Multics 프로젝트 (Bell Labs)	1960s
style	Larry Tesler, Tim Mott (Xerox PARC, Bravo 편집기)	1970s
reservation (레스토랑)	19세기 대도시 레스토랑	1880s
social security number	미국 사회보장청	1936
song (단위 판매)	Apple iPod/iTunes 팀	2001

개념은 발명된다 — 자연계에 개와 고양이처럼 존재하는 것이 아니라 누군가가 특정 목적을 위해 창조한 것.

개념의 핵심 특성 요약 (Note 48)

발명적(inventive): 개념은 발명된다. 세계에 있는 것을 분류하는 것이 아니다.
진화한다(evolving): 시간이 지남에 따라 설계가 개선된다. trash에서 group 개념까지.
목적 지향적(purposive): 목적 없는 개념 = 개념이 아니다.
행동 중심(behavioral): 행동 없이는 개념 없다. pixel은 개념이 아닐 수 있다.
풍부한 상태(rich states): 상태 구조가 행동을 가능하게 한다. David Wheeler: "모든 문제는 간접 수준을 추가함으로써 해결 가능."
데이터 모델 국소화: 각 개념은 자신의 미니 데이터 모델을 갖는다.
일반적(generic): 타입 변수로 인스턴스화 가능. trash는 파일도, 이메일도.
독립적(freestanding): 다른 개념 없이 정의 가능. 가장 중요한 특성.

분리의 원칙 (Note 31)

Dijkstra가 1974년 명명한 "concerns의 분리":

"어떤 측면을 고립시켜 그 자체의 일관성을 위해 깊이 연구하는 것."

분리 ≠ 분할정복: 분할정복은 재조합 가능한 문제를 나누는 것. 분리는 서로 다른 관심사를 독립적으로 다루는 것.

Michael Jackson: 하향식 개발은 개발자가 가장 이해가 부족할 때 (시작 시점에) 가장 결정적인 분해를 강요하기 때문에 보통 실패한다.

개념 재사용 플랫폼 (Note 32)

Déjà Vu (Santiago Perez De Rosso):

전스택(full-stack) 개념 재사용 플랫폼
GUI + 백엔드 서비스 포함한 개념
HTML 변형으로 조합 — 최소한의 프로그래밍으로 조합 가능
액션 동기화로 개념 연결

기존 프레임워크의 문제: 너무 작은 컴포넌트(날짜 선택기) 또는 너무 크고 경직된 플러그인.

Latour의 기입 이론 (Note 65)

Bruno Latour의 "inscription(기입)": 기계는 이전에 수동으로 수행되던 작업을 구현한 것.

소프트웨어 개념에의 적용: 레스토랑 예약, 소셜 미디어 팔로우 등 많은 개념이 원래 인간 프로토콜로 시작해 소프트웨어에 기입된다. 이것은 은유가 아니라 문자 그대로의 동일한 개념이다.

설계 비판 vs. 사용자 테스트 (Note 38)

Jackson의 입장: 경험적 평가는 과대평가되어 있다.

사용자 테스트의 한계: 설계 공간 탐색에 너무 비용이 크다. 매개변수화된 설계만 테스트 가능.
전문가 비판(critique): 경험과 원칙을 기반으로 설계 탐색 중 평가 — 더 비용 효율적.
제안: 원칙에 기반한 비판 → 사용자 테스트 순서. 한 번에 하나의 개념씩.

Google의 Douglas Bowman (첫 시각 디자이너, 2009 퇴사): "모든 결정을 데이터로만 판단하다 보면 회사가 어떤 대담한 설계 결정도 내리지 못하게 된다."

특정성 원칙의 보충 (Note 94-102)

오버로딩의 종류

오버로딩 유형	설명	예
목적 부정(denied purpose)	새 목적이 원래 목적을 약화	Facebook like → recommendation
창발 목적(emergent purpose)	의도치 않은 목적으로 사용	Twitter star → 읽기 목록
거짓 수렴(false convergence)	다른 두 개념을 하나로 합침	Epson 용지 크기 + 급지 방향
편승(piggybacking)	기존 개념에 무관한 기능 추가	Photoshop 크롭 + 리샘플링

Photoshop 크롭 사례(Note 101): cropping에 resampling이 편승 → CS6에서 분리. 설계 개선의 좋은 예.

사회적 오버로딩 (Note 99)

대학 멘토 제도: 지원/조언 역할 + 승진 평가 역할 → 근본적 이해충돌.

학회 논문 심사: 피드백 제공 목적 + 채택 결정 목적 → 상충.

Kieran Egan: 교육의 세 목적(사회화, 진리 추구, 자아실현)이 근본적으로 양립 불가.

무결성 원칙의 보충 (Note 109-110)

강건한 멘탈 모델의 조건

de Kleer & Brown (1981): 사용자가 신뢰할 수 있는 멘탈 모델은 "구조 속 기능 없음(no-function-in-structure)" 원칙을 만족해야 한다.

= 컴포넌트 행동 설명이 다른 컴포넌트의 기능을 참조하지 않아야 한다.

이것이 개념의 독립성 원칙과 정확히 일치한다.

피처 상호작용과 개념 무결성 (Note 110)

통신 피처 상호작용 정의: "피처 A의 존재가 피처 B의 명세를 더 이상 유효하지 않게 만들 때."

이것이 정확히 개념 무결성 위반의 정의와 같다. 다만 개념 설계에서는 이를 허용하지 않는다.

Parnas의 uses 관계와 개념 의존 (Note 81)

	Parnas uses 관계	개념 의존
정의 방식	코드에서 추론 (A가 B를 호출하면 의존)	설계자가 선언
의미	A의 올바른 실행이 B에 의존	A를 포함하면 B도 포함해야 일관성 있음
하위 집합	의존에서 도출됨	하위 집합이 의존을 정의함

Parnas 방법론: "B 없이 A가 포함되는 합리적인 하위 집합이 없는 경우에만 A가 B를 사용하도록 설계하라."

9.3 KiB Raw Blame History Unescape Escape