# WASI (WebAssembly System Interface)

## 1. 개요
**WASI(WebAssembly System Interface)**는 WebAssembly(Wasm)가 웹 브라우저라는 제한된 환경을 벗어나 운영체제(OS) 상에서 독립적으로 실행될 수 있도록 설계된 표준 시스템 인터페이스 명세입니다.

본래 WebAssembly는 브라우저의 샌드박스 내에서 실행되도록 설계되었기에, 파일 시스템 접근, 네트워크 통신, 시스템 시계 확인과 같은 OS 수준의 기능(System Call)을 직접 수행할 수 없었습니다. WASI는 이러한 Wasm 모듈이 호스트 OS의 기능을 안전하고 일관되게 사용할 수 있도록 하는 추상화 계층을 제공함으로써, Wasm을 서버 사이드, 엣지 컴퓨팅, 임베디드 시스템 등 범용적인 런타임 환경으로 확장시키는 핵심 역할을 합니다.

## 2. 동작 원리 및 아키텍처
WASI는 애플리케이션과 하위 운영체제 사이에서 중간 매개체 역할을 수행합니다. Wasm 모듈이 특정 시스템 기능을 요청하면, WASI API가 이를 수신하여 해당 런타임(Runtime)이 실행 중인 실제 OS의 시스템 콜로 변환하여 전달합니다.

### 2.1 Capability-based Security (권한 기반 보안)
WASI의 가장 큰 특징은 **권한 기반 보안 모델(Capability-based security)**을 채택했다는 점입니다. 기존 OS는 프로세스가 실행되면 해당 사용자의 모든 권한을 상속받는 방식(Ambient Authority)이었으나, WASI는 모듈이 실행될 때 명시적으로 허용된 자원(파일 핸들, 디렉토리 등)에 대해서만 접근 권한을 부여합니다.

### 2.2 시스템 콜 추상화 구조
WASI는 다양한 OS(Windows, Linux, macOS 등)의 서로 다른 시스템 콜을 하나의 표준 API로 통합합니다.

| 기능 구분 | 기존 OS 시스템 콜 (예: POSIX) | WASI API (추상화 계층) | 비고 |
| :--- | :--- | :--- | :--- |
| 파일 읽기/쓰기 | `read()`, `write()` | `fd_read()`, `fd_write()` | 파일 디스크립터 기반 제어 |
| 파일 경로 탐색 | `open()`, `chdir()` | `path_open()`, `path_cwd()` | 샌드박스 내 경로 제한 |
| 시간 확인 | `gettimeofday()` | `clock_time_get()` | 표준화된 시간 인터페이스 |

## 3. 주요 특징 및 장점
WASI는 기존의 가상 머신(VM)이나 컨테이너 기술과는 다른 차원의 효율성을 제공합니다.

*   **플랫폼 독립성 (Write Once, Run Anywhere):** 특정 CPU 아키텍처나 OS에 종속되지 않는 바이트코드 형태로 컴파일되므로, WASI를 지원하는 런타임만 있다면 어디서든 동일하게 동작합니다.
*   **강력한 격리(Sandboxing):** 기본적으로 모든 자원 접근이 차단된 상태에서 시작하며, 호스트가 허용한 특정 리소스에만 접근할 수 있어 보안성이 매우 높습니다.
*   **경량성 및 빠른 시작 속도:** 프로세스 생성 오버헤드가 극히 적어 밀리초(ms) 단위의 빠른 콜드 스타트(Cold Start)가 가능합니다.
*   **언어 중립성:** Rust, C/C++, Go, Zig 등 다양한 언어로 작성된 코드를 WASI 타겟으로 컴파일하여 실행할 수 있습니다.

### 3.1 WASI vs Docker 컨테이너 비교
WASI는 컨테이너와 유사한 격리 환경을 제공하지만, 구현 계층과 효율성 면에서 차이가 있습니다.

| 비교 항목 | Docker 컨테이너 | WASI (Wasm) |
| :--- | :--- | :--- |
| **가상화 수준** | OS 수준 가상화 (커널 공유) | 프로세스 수준 가상화 (런타임 기반) |
| **격리 방식** | Namespace, Cgroups (Linux 커널) | 소프트웨어 정의 샌드박스 (SFI) |
| **이미지 크기** | 수십 MB ~ 수 GB (OS 레이어 포함) | 수 KB ~ 수 MB (바이트코드만 포함) |
| **시작 속도** | 초 단위 (Cold Start 상대적 느림) | 밀리초 단위 (매우 빠름) |
| **이식성** | OS/아키텍처 종속적 (Multi-arch 빌드 필요) | 완전한 플랫폼 독립적 (단일 바이너리) |

## 4. WASI의 표준화 단계 (Snapshot & Preview)
WASI는 한 번에 완성된 표준이 아니라, 점진적인 'Preview' 단계를 통해 발전하고 있습니다.

### 4.1 발전 과정
1.  **wasi_snapshot_preview1:** 초기 표준으로, 기본적인 파일 I/O와 시스템 제어 기능을 제공했습니다. 현재 대부분의 런타임이 지원하는 안정적인 버전입니다.
2.  **WASI Preview 2:** 단순한 함수 호출 집합을 넘어 **컴포넌트 모델(Component Model)**을 도입한 단계입니다. 인터페이스 정의 언어인 WIT(Wasm Interface Type)를 통해 모듈 간의 고수준 데이터 타입 교환이 가능해졌으며, `wasi-cloud`와 같이 HTTP, Key-Value store 등 특정 목적에 맞는 인터페이스를 선택적으로 조합할 수 있는 구조로 진화했습니다.

### 4.2 컴포넌트 모델 (Component Model)
컴포넌트 모델은 Wasm 모듈을 더 작은 단위의 '컴포넌트'로 나누고, 이를 조립하여 거대한 애플리케이션을 만드는 방식입니다.

```mermaid
graph TD
    App[Application] --> CompA[Component A]
    App --> CompB[Component B]
    CompA -- "WIT Interface" --> CompB
    CompA --> WASICore[WASI Core API]
    CompB --> WASICore
    WASICore --> Runtime[Wasm Runtime]
    Runtime --> HostOS[Host Operating System]
```

이 모델을 통해 서로 다른 언어로 작성된 컴포넌트들이 마치 하나의 라이브러리처럼 상호운용(Interoperability)될 수 있습니다.

## 5. 활용 사례 및 생태계
WASI는 클라우드 네이티브 인프라의 새로운 패러다임으로 주목받고 있습니다.

*   **서버리스 컴퓨팅 (FaaS):** 빠른 시작 속도와 낮은 메모리 점유율 덕분에 AWS Lambda와 같은 함수형 서비스의 효율을 극대화합니다.
*   **엣지 컴퓨팅:** 리소스가 제한된 엣지 디바이스에서 보안이 유지된 상태로 코드를 실행하는 데 최적입니다. (예: Fastly Compute@Edge)
*   **플러그인 시스템:** 메인 애플리케이션의 안정성을 해치지 않으면서, 사용자가 작성한 외부 코드를 안전하게 실행하는 플러그인 아키텍처로 활용됩니다.

### 5.1 주요 런타임 비교
| 런타임 | 개발 주체 | 특징 | Preview 2 지원 여부 |
| :--- | :--- | :--- | :--- |
| **Wasmtime** | Bytecode Alliance | 표준 준수도가 가장 높으며 산업 표준으로 활용됨 | 매우 높음 |
| **Wasmer** | Wasmer Inc. | 다양한 플랫폼 지원 및 자체 패키지 매니저(WAPM) 제공 | 높음 |
| **WasmEdge** | CNCF | AI/ML 워크로드 최적화 및 클라우드 네이티브 특화 | 높음 |

### 5.2 컴파일 및 실행 예시 (Rust 기준)
Rust 언어를 사용하여 WASI 타겟으로 프로그램을 작성하고 실행하는 과정은 다음과 같습니다.

```bash
# 1. WASI 타겟 추가
rustup target add wasm32-wasi

# 2. WASI 타겟으로 컴파일
cargo build --target wasm32-wasi

# 3. Wasmtime 런타임을 사용하여 실행
# --dir . 옵션은 'Capability-based Security'의 실제 구현 사례로, 
# 런타임이 현재 디렉토리에 대한 접근 권한을 명시적으로 부여받도록 설정하는 것입니다.
wasmtime run --dir . target/wasm32-wasi/debug/hello_wasi.wasm
```

## 6. 한계 및 향후 전망

### 6.1 현재의 제약 사항
*   **네트워킹:** `preview1`에서는 소켓 통신 지원이 매우 제한적이었습니다. `Preview 2`에서 `wasi-sockets`를 통해 개선되고 있으나, 여전히 완전한 TCP/UDP 스택 구현은 진행 중입니다.
*   **멀티스레딩:** Wasm 자체의 메모리 모델 제약으로 인해 공유 메모리 기반의 멀티스레딩 구현이 복잡하며, 표준화 작업이 계속되고 있습니다.

### 6.2 WASI vs POSIX 비교
WASI는 POSIX를 참고했지만, 보안 철학에서 근본적인 차이가 있습니다.

| 비교 항목 | POSIX (Portable OS Interface) | WASI (WebAssembly System Interface) |
| :--- | :--- | :--- |
| **설계 철학** | 하드웨어/OS 간 호환성 중심 | 보안 샌드박스 및 이식성 중심 |
| **권한 모델** | 사용자 기반 권한 (Ambient Authority) | 명시적 권한 부여 (Capability-based) |
| **실행 환경** | 네이티브 OS 프로세스 | Wasm 런타임 가상 머신 |
| **이식성** | 소스 코드 재컴파일 필요 | 단일 바이너리로 모든 플랫폼 실행 가능 |

### 6.3 향후 전망
WASI는 향후 **"클라우드 네이티브의 차세대 표준"**이 될 가능성이 높습니다. 컨테이너(Docker)가 OS 수준의 가상화를 제공했다면, WASI는 프로세스 수준의 초경량 가상화를 제공합니다. 이는 인프라 비용 절감과 보안 강화라는 두 마리 토끼를 잡는 방향으로 발전할 것이며, 특히 AI 모델의 엣지 배포 및 분산 컴퓨팅 환경에서 핵심적인 인터페이스로 자리 잡을 것으로 전망됩니다.