5d2b5074e4
- additive-programming: AI 시대 섹션 추가 (blast radius 제한, 검증 용이성, 에이전트 동형성) - language-stack: 신규 개념 페이지 — Scheme 채택 이유, 언어 비교, Rust+Tauri+wgpu 확정 스택 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
102 lines
3.9 KiB
Markdown
102 lines
3.9 KiB
Markdown
---
|
|
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 구축
|