- Swift 커뮤니티는 WebAssembly(Wasm) 지원을 꾸준히 개발해 왔으며, 이를 바탕으로 장기적인 비전을 제안함
- WebAssembly는 이식성, 보안성, 성능을 중시하는 가상 머신 명령어 집합으로, 다양한 플랫폼에서 실행 가능함
- Swift에서 Wasm을 지원하면 브라우저를 포함한 새로운 환경에서 Swift를 사용할 수 있으며, 클라이언트/서버 애플리케이션 모두에서 활용 가능성 확대됨
보안 및 시스템 인터페이스 특성
- Wasm은 직접적인 시스템 접근 없이 명시적으로 가져온 함수만 실행할 수 있어 보안에 유리함
-
WASI(WebAssembly System Interface) 는 Wasm이 호스트 OS와 상호작용할 수 있도록 표준 API를 제공
- Swift는
wasm32-unknown-wasi 타겟에서 WASI libc를 기반으로 동작하며, C 인터롭을 통해 이미 사용 가능함
- W3C는 Component Model을 통해 Wasm의 타입 시스템과 모듈 연동을 통합 관리하고 있음
-
wit-tool을 통해 Swift 선언에서 .wit 생성 가능, 반대 방향도 지원
주요 활용 사례
-
Swift 매크로를 Wasm으로 컴파일해 어디서나 실행 가능한 바이너리로 배포 가능
- SwiftPM 플러그인, 매니페스트, 매크로 등의 실행을 가상화하여 보안성 강화
- Wasm은 JIT 또는 AOT 컴파일로 최적화된 바이너리를 생성할 수 있어 성능 손실 최소화
- Wasm으로 가상화된 Swift 컴포넌트는 별도 프로세스 없이 실행 가능, IPC 오버헤드 제거
제안된 목표
-
Swift 표준 라이브러리의 WASI 지원 API 범위 확대
-
크로스 컴파일 도구 개선
-
Component Model 통합
- 최신 WASI 사양이 Swift에서도 사용 가능하도록 지원
-
다른 Wasm 컴포넌트와의 인터롭 향상
- Swift에서 Wasm 컴포넌트를 사용하는 경험을 C/C++와 동등하게 만드는 것이 목표
-
Wasm에서의 Swift 디버깅 환경 개선
디버깅 관련 사항
-
Wasm의 디버깅은 제한적, 자체적으로 introspection 기능이 없음
- 두 가지 주요 접근 방식이 존재
- LLDB와 GDB 프로토콜을 지원하는 Wasm 런타임
- Wasm 엔진에 내장된 디버거
-
브라우저 환경과 비브라우저 환경은 서로 다른 디버깅 접근 필요
- Chrome DevTools 등의 도구에서 DWARF 정보를 활용 가능하지만, Swift 메타데이터와 JIT 표현식 평가 기능은 추가 통합 필요
멀티스레딩 및 동시성
- Wasm은 현재 순차적 일관성을 지원하는 원자 연산만 존재
- 스레드 생성은 호스트 환경에 의존
- 두 가지 스레딩 제안 존재:
-
wasi-threads (기존 방식, 일부 도구 및 런타임에서 지원됨)
-
shared-everything-threads (새로운 제안, 향후 표준이 될 가능성 있음)
- Swift는
wasm32-unknown-wasi (단일 스레드), wasm32-unknown-wasip1-threads (멀티스레드) 지원
- 현재는 libdispatch가 wasi-threads를 지원하지 않기 때문에 단일 스레드 기반의 Swift Concurrency 실행기를 사용 중
64비트 주소 공간
- Wasm은 기본적으로 32비트 주소 공간을 사용
-
64비트 메모리 제안(memory64) 은 구현 단계에 있음
- Swift에서 이를 지원하려면 WebAssembly 도구 체인의 협조 또는 Swift 메타데이터 구조 변경 필요
공유 라이브러리
- 두 가지 방식 존재
-
Emscripten 스타일 동적 링크: 비표준적이며 런타임 기능 의존
-
Component Model 기반 정적 링크: 런타임 특수 기능 없이도 사용 가능하나, 런타임 로딩은 불가
- Swift에서 공유 라이브러리를 사용하려면 PIC(Position-Independent Code) 모드로 컴파일하고, 정해진 링크 규약을 따라야 함