--- 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 구축