기술 요약: 외부 라이브러리 링킹을 통한 WebAssembly의 관리형 언어 지원 도입

문제 정의

WebAssembly(Wasm)는 고성능, 보안성, 이식성을 갖춘 바이트코드 형식으로서 브라우저, 클라우드 컴퓨팅, 에지 환경에서 널리 채택되었습니다. 그러나 현재의 생태계는 C, C++, Rust와 같은 컴파일 언어에 크게 치우쳐 있습니다. 머신 러닝과 데이터 처리 분야를 지배하는 Python, Java, JavaScript와 같은 관리형 언어들은 견고한 통합 메커니즘이 부족한 실정입니다.

관리형 언어를 Wasm에서 지원하는 데 있어 주요 과제는 이들의 복잡하고 고수준인 런타임 환경(예: 인터프리터, 가비지 컬렉터)에 대한 의존성입니다. 기존의 주류 솔루션인 **런타임 네스팅(runtime nesting)**은 외부 언어의 런타임(예: CPython)을 Wasm 바이트코드로 컴파일하여 Wasm 런타임 내부에서 실행하도록 시도합니다. 이 방식은 세 가지 결정적인 한계를 가집니다:

1. 낮은 확장성: 다양한 언어 런타임을 Wasm으로 컴파일하려면 깊은 도메인 전문 지식이 필요하며, 서로 다른 언어 버전에 따라 유지보수가 어렵습니다.
2. 최적화되지 않은 성능: 런타임 네스팅은 "이중 가상 머신" 레이어를 도입하여 컨텍스트 스위칭과 리소스 관리로 인한 상당한 오버헤드를 발생시키며, 이는 느린 실행 속도로 이어집니다.
3. 제한된 기능 호환성: Wasm 형식의 런타임은 python-wasmedge와 같은 기존 솔루션에서 나타나듯, 직접적인 시스템 상호작용에 의존하는 고급 언어 기능이나 네이티브 확장을 지원하지 못하는 경우가 많습니다.

방법론: WALL-E 프레임워크

이러한 한계를 해결하기 위해 저자들은 런타임을 재컴파일하거나 가상 머신을 중첩하지 않고 관리형 언어를 Wasm에 통합하는 WALL-E(WAsm Language Linker via External Library) 프레임워크를 제안합니다.

핵심 개념: 외부 라이브러리 링킹

WALL-E는 관리형 언어 애플리케이션을 고유의 신뢰할 수 있는 런타임에서 실행되는 외부 라이브러리로 취급합니다. Wasm에 네이티브로 지원되는 언어(예: Rust)로 작성된 경량 스타트업 프로그램이 이러한 외부 라이브-브러리를 동적으로 링킹하고 호출하는 클라이언트 역할을 수행합니다. 이 설계는 외부 실행 환경이 신뢰할 수 있다고 가정하며, 보안 경계를 Wasm 샌드박스에서 호스트 배포 제어로 전환합니다.

아키텍처 및 워크플로우

WALL-E는 모든 프로그래밍 생태계에서 지원되는 범용 프로토콜인 HTTP를 활용하는 클라이언트-서버 아키텍처를 채택합니다.

1. 라이브러리 등록:

   • 클라이언트 측: 사용자는 외부 라이브러리 소스 코드와 구조화된 JSON 메타데이터 기술서(언어, 서비스 엔드포인트, 함수 시그니처 및 종속성 명시)를 Library Manager에 제출합니다.
   • 서버 측: Library Manager는 메타데이터를 검증하고 코드에 대한 기본적인 무결성 검사를 수행한 후, 격리된 환경(예: 컨테이너) 내에서 해당 라이브러리를 웹 서비스(예: Python의 경우 Flask, Node.js의 경우 Express 사용)로 자동 배포합니다. 그 후 고유한 서비스 식별자와 네트워크 엔드포인트를 할당합니다.

2. 교차 런타임 호출:

   • 클라이언트 (Wasm): Wasm 모듈(Rust로 컴파일됨)은 대상 라이브러리 ID, 함수 이름 및 파라미터를 포함하는 호출 요청을 준비합니다. 복잡한 타입(예: NumPy 배열)의 경우 바이트 수준 표현을 보존하기 위해 Base64 인코딩을 사용하여 파라미터를 언어 중립적인 JSON 형식으로 직렬화합니다.
   • 서버 (외부 런타임): 요청은 특정 외부 서비스로 라우팅됩니다. 서버의 임베디드 웹 프레임워크는 JSON을 파싱하고, 네이티브 데이터 타입을 재구성하며, 네이티브 런타임 내에서 요청된 함수를 실행합니다.
   • 응답: 실행 결과는 JSON(복잡한 데이터의 경우 Base64 포함)으로 직렬화되어 HTTP를 통해 Wasm 클라이언트로 반환됩니다.

구현 세부 사항

본 프레임워크는 Wasm 런타임으로 WasmEdge(v0.14.0)를, 클라이언트 측 스타트업 프로그램으로 Rust(v1.27.1)를 사용하여 구현되었습니다. WasmEdge의 비동기 기반 HTTP 핸들러 시스템은 호출 게이트웨이 역할을 수행합니다. 시스템은 다른 독립형 Wasm 런타임에서도 구현 가능하도록 범용적으로 설계되었습니다.

주요 기여

1. 새로운 개념: 본 논문은 런타임 네스팅의 오버헤드를 피하기 위해 외부 라이브러리 링킹을 사용하여 관리형 언어 지원에 관한 최초의 체계적인 연구를 제시합니다.
2. 프레임워크 설계: WALL-E는 다음과 같은 실질적인 성과를 달성하는 실용적인 프레임워크입니다:
   • 언어 확장성: 런타임을 재컴파일하지 않고도 다양한 언어를 지원합니다.
   • 고성능: 코드를 네이티브 런타임에서 직접 실행함으로써 이중 가상화 오버헤드를 제거합니다.
   • 기능 호환성: 원본 런타임 생태계를 활용하여 폭넓은 언어 기능과 패키지를 지원합니다.
3. 포괄적인 평가: 저자들은 10개의 관리형 언어와 다양한 실제 응용 프로그램을 통해 프레임워크를 검증했습니다.

평가 결과

1. 언어 확장성 (RQ1)

저자들은 The Computer Language Benchmarks Game의 벤치마크와 실제 응용 프로그램을 사용하여 10개의 인기 있는 관리형 언어(JavaScript, Python, Java, PHP, C#, TypeScript, Ruby, R, Scala, Kotlin)를 대상으로 WALL-E를 평가했습니다.

• 통과율: WALL-E는 전체 95.68%(278개 중 266개)의 통과율을 기록했습니다.
• 성공 사례: JavaScript, Java, C#, TypeScript, Ruby, R, Scala, Kotlin은 **100%**의 통과율을 달성했습니다.
• 실패 사례: 실패는 주로 Python(90%)과 PHP(70.97%)에 집중되었는데, 이는 주로 웹 서비스 배포 모델과 호환되지 않는 전역 초기화 패턴(예: __main__ 블록)이나 OS 레벨의 프로세스 관리(예: fork)에 의존하는 스크립트 때문이었습니다.
• 실제 응용 프로그램: 선택된 모든 실제 응용 프로그램(예: Tesseract.js, Elasticsearch, ggplot2)이 성공적으로 배포되었습니다.

2. 실행 성능 (RQ2)

성능은 최첨단 런타임 네스팅 솔루션인 python-wasmedge와 비교되었습니다.

• 속도 향상: WALL-E는 중첩 솔루션 대비 엄청난 속도 향상을 보여주었습니다:
  • 연산 집약적 작업: 평균 647배 향상.
  • I/O 집약적 작업: 평균 500배 향상.
  • 메모리 집약적 작업: 평균 386배 향상.
  • 실제 라이브러리: jsonschema는 689배, markdown은 449배의 속도 향상을 보였습니다.
• 원인: 이러한 성능 이득은 이중 해석 레이어를 제거하고 코드를 네이티브 런타임에서 직접 실행하는 데서 기인합니다.

3. 통신 오버헤드 (RQ3)

저자들은 HTTP 기반 클라이언트-서버 통신으로 발생하는 오버헤드를 분석했습니다.

• 마이크로 벤치마크: 통신 오버헤드(설정, 직렬화, 네트워크, 역직렬화)는 전체 프로세스 시간의 평균 **0.30%**만을 차지했습니다.
• 실제 워크로드: 오버헤드는 여전히 완만했습니다. jsonschema(대용량 페이로드로 인해)의 경우 11.39%, markdown의 경우 **2.5%**였습니다.
• 결론: 통신 비용은 런타임 네스팅을 피함으로써 얻는 실행 시간 절감 효과에 비해 무시할 수 있는 수준입니다.

의의 및 주장

본 논문은 효율적인 다국어 애플리케이션을 가능하게 함으로써 클라우드 및 에지 컴퓨팅에서 WebAssembly의 실용성을 크게 향상시킨다고 주장합니다. WALL-E는 Wasm 실행 환경과 관리형 언어 런타임을 분리함으로써 보안/이식성과 성능/호환성 사이의 트레이드오프를 해결합니다.

저자들은 WALL-E를 다음과 같은 기반 기술으로 포지셔닝합니다:

• 다국어 에지 컴퓨팅: 에지 장치가 중첩된 런타임의 성능 저하 없이 고수준 언어로 작성된 복잡한 로직을 실행할 수 있도록 합니다.
• 클라우드 네이티브 배포: 서버리스 및 마이크로서비스 아키텍처에서 다양한 언어 생태계의 효율적인 통합을 가능하게 합니다.

본 연구는 한계점 또한 인정합니다. 구체적으로 외부 런타임에서 Wasm으로의 콜백을 지원하지 않으며, 신뢰할 수 있는 외부 환경에 의존하므로, 신뢰할 수 없는 제3자 코드 실행보다는 제어된 배포 시나리오에 가장 적합합니다. 그러나 저자들은 이러한 제약에도 불구하고 확장성과 성능의 이점이 많은 실제 사용 사례에서 더 크다고 주장합니다.