From 5d2b5074e41bc465898e46c0cbbf7fdc73b9ac65 Mon Sep 17 00:00:00 2001 From: minsung Date: Thu, 30 Apr 2026 16:04:56 +0900 Subject: [PATCH] =?UTF-8?q?feat:=20AI=20=EC=8B=9C=EB=8C=80=20=EA=B0=80?= =?UTF-8?q?=EC=82=B0=EC=A0=81=20=EC=84=A4=EA=B3=84=20=EC=9D=B4=EB=A1=A0=20?= =?UTF-8?q?+=20=EC=96=B8=EC=96=B4=C2=B7=EC=8A=A4=ED=83=9D=20=EC=84=A0?= =?UTF-8?q?=ED=83=9D=20=EA=B8=B0=EC=A4=80=20=EC=B6=94=EA=B0=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - additive-programming: AI 시대 섹션 추가 (blast radius 제한, 검증 용이성, 에이전트 동형성) - language-stack: 신규 개념 페이지 — Scheme 채택 이유, 언어 비교, Rust+Tauri+wgpu 확정 스택 Co-Authored-By: Claude Sonnet 4.6 --- wiki/concepts/additive-programming.md | 32 ++++++++ wiki/concepts/language-stack.md | 101 ++++++++++++++++++++++++++ wiki/index.md | 1 + wiki/log.md | 9 +++ 4 files changed, 143 insertions(+) create mode 100644 wiki/concepts/language-stack.md diff --git a/wiki/concepts/additive-programming.md b/wiki/concepts/additive-programming.md index e482bc3..87e4eee 100644 --- a/wiki/concepts/additive-programming.md +++ b/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]] — 가산적 확장의 핵심 메커니즘: 핸들러 추가 diff --git a/wiki/concepts/language-stack.md b/wiki/concepts/language-stack.md new file mode 100644 index 0000000..edb3f1c --- /dev/null +++ b/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 구축 diff --git a/wiki/index.md b/wiki/index.md index bfd67bd..a148621 100644 --- a/wiki/index.md +++ b/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 — 출처 요약 diff --git a/wiki/log.md b/wiki/log.md index c583d40..da962b8 100644 --- a/wiki/log.md +++ b/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/ 아래 작성