feat: AI 시대 가산적 설계 이론 + 언어·스택 선택 기준 추가

- additive-programming: AI 시대 섹션 추가 (blast radius 제한, 검증 용이성, 에이전트 동형성)
- language-stack: 신규 개념 페이지 — Scheme 채택 이유, 언어 비교, Rust+Tauri+wgpu 확정 스택

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

wiki/concepts/additive-programming.md

@@ -72,6 +72,38 @@ Postel의 법칙이 여기 적용된다: "Be conservative in what you do, be lib
 
 **진짜 가산성인지 확인**: "추가만으로" 확장이 이루어지는지 아니면 기존 코드를 수정해야 하는지를 의식적으로 확인해야 한다. 많은 경우 '수정하는 곳'이 숨어있다.
 
+## AI 시대에서의 가산적 프로그래밍
+
+### 왜 더 중요해지는가
+
+AI 코드 생성이 빠를수록 "수정 오염"의 위험이 커진다. LLM은 맥락을 파편적으로 이해하기 때문에, 기존 코드를 수정하도록 지시하면 의도치 않은 부작용을 만들 확률이 높다. 가산적 아키텍처는 AI의 blast radius를 구조적으로 제한하는 메커니즘으로 작동한다.
+
+GitClear(2024) 분석에 따르면 AI 지원 개발 이후 코드 복잡도(churn, coupling)가 오히려 증가했다. 이는 AI가 수정 패턴을 반복 적용할 때 발생하는 현상이며, 추가만 허용하는 구조가 이 문제를 구조적으로 방어한다.
+
+### 검증 부담과 가산성
+
+AI가 코드를 생성하고 아키텍트가 검증하는 워크플로우에서:
+
+- **추가된 코드**: 격리된 변경 → 리뷰 범위가 명확
+- **수정된 코드**: 기존 로직 전체 맥락 추적 필요
+
+가산적 코드는 검증 비용이 낮다. 이는 인간-AI 협업에서 중요한 속성이다.
+
+### AI 에이전트 아키텍처와의 동형성
+
+OpenAI Function Calling, Anthropic Tool Use, MCP 서버 — 모두 기존 LLM 코어를 수정하지 않고 새 도구를 추가하는 구조다. 멀티에이전트 시스템, RAG 파이프라인, MCP 서버 합성이 이미 가산적 아키텍처 원칙 위에 설계되어 있다.
+
+```
+설계 원칙:  아키텍트가 extension point를 정의
+생성 단위:  AI가 그 지점을 채움
+```
+
+이 협업 패턴은 가산적 설계와 구조적으로 일치한다.
+
+### "Vibe Coding" 반론에 대해
+
+"AI 시대에 코드는 버리고 재생성하는 것"이라는 주장은 스크립트 수준에서만 성립한다. 데이터가 쌓이고, 팀이 생기고, 시스템이 복잡해지는 순간 재생성 전략은 불가능해진다. 설계 원칙의 필요성은 규모와 함께 증가한다.
+
 ## 관련 개념
 
 - [[generic-procedures]] — 가산적 확장의 핵심 메커니즘: 핸들러 추가

wiki/concepts/language-stack.md

@@ -0,0 +1,101 @@
+---
+title: 가산적 설계를 위한 언어·스택 선택
+tags: [concept, practice]
+updated: 2026-04-30
+---
+
+# 가산적 설계를 위한 언어·스택 선택
+
+## 핵심 기준
+
+가산적 설계에 유리한 언어의 조건:
+
+- **개방적 확장 메커니즘** — 기존 타입·모듈을 수정하지 않고 새 행동을 추가할 수 있는가
+- **일급 함수** — 컴비네이터 패턴을 자연스럽게 표현할 수 있는가
+- **타입 시스템** — 설계 의도를 코드에 표현하고 컴파일 타임에 위반을 잡는가
+
+## SDF가 Scheme을 사용하는 이유
+
+| Scheme 특성 | 가산적 설계에서의 역할 |
+|-------------|----------------------|
+| 동종성(homoiconicity) | 코드 = 데이터 → 코드를 데이터처럼 조합·변환 가능 |
+| 일급 함수 + 클로저 | 컴비네이터를 자연스럽게 표현 |
+| 동적 타입 | 기존 코드 수정 없이 새 타입 추가 가능 |
+| 매크로 | 언어 자체를 확장 — DSL 구축의 기반 |
+| 최소 문법 | 언어가 설계 의도를 방해하지 않음 |
+
+Scheme은 가산적 원칙을 가장 투명하게 표현하지만 실무 생태계가 빈약하다.
+
+## 실무 언어별 가산적 설계 지원
+
+### 1순위 — 구조적으로 가장 유리
+
+**Clojure** (JVM Lisp)
+- 멀티메서드(multimethod) = SDF 제네릭 프로시저와 거의 동일
+- 프로토콜(protocol) = 기존 타입에 새 행동 추가
+- 불변 데이터 구조가 기본
+- 단점: 학습 곡선이 가파름, AI 생태계 미성숙, JVM 성능 오버헤드
+
+**Haskell**
+- 타입 클래스(typeclass) = 개방적 확장의 교과서적 구현
+- 기존 타입에 새 인스턴스 추가 = 코드 수정 없는 확장
+
+### 2순위 — AI 시대 실용적 선택
+
+| 언어 | 가산적 확장 메커니즘 | AI 생태계 | 비고 |
+|------|---------------------|-----------|------|
+| **Python** | singledispatch, 데코레이터, 프로토콜 | 압도적 | 언어가 강제하지 않음 — 규율 필요 |
+| **TypeScript** | 일급 함수, 컴비네이터, fp-ts | 좋음 | 타입 시스템이 설계 의도 표현 가능 |
+| **C#** | 확장 메서드, 인터페이스 | Semantic Kernel | 엔터프라이즈 스택 |
+| **Rust** | 트레이트(Trait) — 가장 엄밀 | 미성숙 | 학습 장벽 높음, 성능 최강 |
+
+## 요구사항이 스택을 결정한다
+
+언어 선택은 철학이 아니라 **요구사항**에서 출발해야 한다.
+
+### 그래픽 + 멀티플랫폼 요구사항이 있는 경우
+
+```
+요구사항: Vulkan / Metal / WebGPU 지원 + 웹 포함 멀티플랫폼
+→ wgpu (Rust 기반 크로스플랫폼 GPU 추상화)
+→ Tauri (Rust 백엔드 + Web 프론트엔드)
+```
+
+이 요구사항을 동시에 만족하는 스택은 **Rust + Tauri + wgpu**뿐이다. Python, C#, Node.js 모두 wgpu를 직접 지원하지 않는다.
+
+**확정 스택:**
+
+```
+[GPU / 렌더링]     wgpu (Rust)
+[앱 프레임워크]    Tauri
+[프론트엔드]       TypeScript        ← 선택 아닌 필수 (Tauri 구조)
+[AI 통합]          Anthropic API     ← reqwest(Rust)로 HTTP 직접 호출
+[가산적 확장]      Rust Trait        ← 언어 수준에서 설계 원칙 강제
+```
+
+### 일반적인 우선순위
+
+```
+AI 중심 설계     → Python
+백엔드 API 중심  → TypeScript
+엔터프라이즈     → C#
+그래픽 / GPU     → Rust + Tauri + wgpu
+```
+
+## 레이어 분리 원칙
+
+언어 단일화를 추구하면 오히려 발목을 잡힌다. 레이어별로 언어를 분리하고 API로 경계를 정의하는 것이 가산적 아키텍처와 일치한다.
+
+```
+[프론트/PWA]     TypeScript  ← 필수, 타협 불가
+[API 서버]       선택 가능   ← C#, Rust, Python
+[AI 에이전트]    Python or HTTP API
+```
+
+각 레이어는 독립적이고, 수정 없이 교체·추가할 수 있어야 한다.
+
+## 관련 개념
+
+- [[additive-programming]] — 가산적 프로그래밍의 철학적 기반
+- [[combinators]] — 언어 수준 컴비네이터 패턴
+- [[domain-specific-language]] — 언어 확장과 DSL 구축

wiki/index.md

@@ -19,6 +19,7 @@ updated: 2026-04-30
 - [[layered-data]] — 데이터와 프로시저를 여러 독립 계층으로 구성해 기존 코드 수정 없이 단위·의존성·출처 등 메타데이터를 병렬 처리하는 구조 (Ch6 중심)
 - [[propagation]] — 공유 셀로 연결된 자율 전파기들이 부분 정보를 단조적으로 축적·전파하는 다방향 계산 모델 (Ch7 중심)
 - [[domain-specific-language]] — 문제 도메인의 개념을 직접 반영하는 어휘와 구조를 가진 언어로, 컴비네이터부터 완전한 인터프리터까지 구현 스펙트럼을 가짐 (Ch2, Ch4, Ch5)
+- [[language-stack]] — 가산적 설계 관점의 언어 선택 기준, Scheme 채택 이유, AI 시대 실용 스택 (Rust+Tauri+wgpu 포함)
 
 ## Sources — 출처 요약
 

wiki/log.md

@@ -40,6 +40,15 @@ title: Wiki Operation Log
   - `wiki/sources/EOS-part3-principles.md` — Part III (Ch9–11): 특정성(중복·과부하 4유형·Facebook like 분석), 친숙성(Twitter follower·PowerPoint section vs Keynote), 무결성(복수심 식당·font format·Google Drive)
 - `wiki/index.md` Sources 섹션에 생성된 8개 페이지 등록
 
+## 2026-04-30 (4차)
+
+- `wiki/concepts/additive-programming.md` — "AI 시대에서의 가산적 프로그래밍" 섹션 추가
+  - AI blast radius 제한 메커니즘, GitClear 2024 근거, 검증 용이성, AI 에이전트 아키텍처와의 동형성
+- `wiki/concepts/language-stack.md` 신규 생성 — 가산적 설계를 위한 언어·스택 선택
+  - Scheme 채택 이유, 실무 언어별 가산적 확장 메커니즘 비교, 요구사항 기반 스택 결정 원칙
+  - 그래픽/멀티플랫폼 요구 시 확정 스택: Rust + Tauri + wgpu
+- `wiki/index.md` Concepts 섹션에 [[language-stack]] 등록
+
 ## 2026-04-30 (2차)
 
 - [SDF 개념 페이지 일괄 생성] 8개 SDF 소스 페이지를 읽고 2개 이상 챕터에서 반복 등장하는 핵심 개념 8개를 wiki/concepts/ 아래 작성