# WASM은 컨테이너를 대체하게 될 것

> Clean Markdown view of GeekNews topic #19201. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=19201](https://news.hada.io/topic?id=19201)
- GeekNews Markdown: [https://news.hada.io/topic/19201.md](https://news.hada.io/topic/19201.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-02-13T09:54:11+09:00
- Updated: 2025-02-13T09:54:11+09:00
- Original source: [creston.blog](https://creston.blog/wasm-will-replace-containers/)
- Points: 21
- Comments: 8

## Summary

WebAssembly(WASM)는 "한 번 작성하면 어디서나 실행 가능"한 경험을 제공하며, 일부 영역에서 이미 컨테이너를 대체하고 있습니다. WASM은 JVM과 유사한 개념을 제공하지만 웹 브라우저에서도 실행 가능하여 더 많은 개발자들에게 매력적입니다. WASM은 빠르게 발전하고 있으며, Cloudflare와 같은 플랫폼을 통해 그 잠재력을 미리 경험할 수 있습니다.   
> "2030년이 되면 아무도 쿠버네티스를 기억하지 못하게 될 것"

## Topic Body

> "WebAssembly는 진정한 Write-Once-Run-Anywhere임"   
> "2030년이 되면 아무도 쿠버네티스를 기억하지 못하게 될것"  
  
### 이동성 (Portability)  
  
- 컨테이너는 소프트웨어 개발의 많은 문제를 해결했으며, VM보다 사용성이 뛰어났음  
- 하지만 현재 컨테이너는 복잡한 도구와 프로그램-컨테이너-Linux의 강한 결합으로 인해 다루기 번거로워짐  
- 개발자는 코드 작성과 기능 배포에 집중하고 싶어 하며, Docker 학습은 방해 요소가 됨  
- WebAssembly(WASM)는 이미 일부 영역에서 컨테이너를 대체하고 있으며, "한 번 작성하면 어디서나 실행 가능"한 경험을 제공함  
- 여러 언어를 WASM으로 컴파일할 수 있으며, 시스템 인터페이스 부족이 널리 채택되는 것을 막고 있지만, 이는 곧 해결될 것  
- 현재 WASM의 주요 한계는 파일 접근, 네트워킹 등의 시스템 인터페이스 부족이지만, 이는 시간이 지나면 해결될 문제임  
  
### JVM과의 비교  
  
- WASM이 JVM과 비슷한 "한 번 작성하면 어디서나 실행" 개념을 제공하지만, JVM은 웹 브라우저에서 실행되지 않음  
- 웹 브라우저는 중요한 애플리케이션 배포 대상이며, 이로 인해 많은 개발자가 JVM을 피하게 됨  
- 최근에는 GraalVM, Kotlin Native, Scala Native 등의 정적 바이너리 컴파일러가 JVM의 대안으로 떠오르는 추세임  
  
### 마이크로서비스 (Microservices)  
  
- 마이크로서비스 아키텍처에서는 HTTP, RPC 또는 메시지 브로커를 사용하여 서비스를 연결함  
- 네트워크 통신의 비용과 신뢰성 문제는 주요 단점이지만, 대부분의 기업은 장점이 더 크다고 판단함  
- AWS Lambda와 같은 서버리스 플랫폼이 등장하면서, 마이크로서비스는 개별 함수 단위로 배포할 수 있게 됨  
- Cloudflare Workers는 V8 샌드박스 내에서 실행되며, 네트워크 요청 없이 동일한 런타임에서 함수 호출이 가능함  
- 이는 마이크로서비스의 개발 장점과 모놀리식 아키텍처의 런타임 성능을 동시에 제공함  
- Wasmer 등 다른 업체들도 WASM 기반 솔루션을 개발 중임  
  
### WASM의 도입 (Adoption)  
  
- WASM은 아직 초기 기술이지만 빠르게 발전하고 있으며, 지원도 증가하는 추세임  
- 현재 모든 환경에서 완벽하게 작동하지는 않지만, Cloudflare와 같은 플랫폼을 통해 미래를 미리 경험할 수 있음  
- Python, Ruby, PHP와 같은 동적 언어 사용자라면 WASM의 발전을 기다리면서 Go나 Rust 같은 컴파일 언어를 추가로 학습하는 것이 유리함

## Comments



### Comment 34573

- Author: bus710
- Created: 2025-02-14T15:57:48+09:00
- Points: 2

K8s는 컨테이너를 오케스트레이션 하는 도구인데 wasm 때문에 실효성이 떨어질까요? 도커라면 어느 정도 잠식 되겠지만....

### Comment 34549

- Author: colus001
- Created: 2025-02-14T10:26:54+09:00
- Points: 2

WASM 은 새로운 3D 프린터 같네요. "새로운 세상이 온다" 하는데 막상 쓰는 사람은 별로 없는...

### Comment 34561

- Author: halfenif
- Created: 2025-02-14T12:56:38+09:00
- Points: 1
- Parent comment: 34549
- Depth: 1

> https://madewithwebassembly.com/  
  
여기에 구현 사례 모음이 있는데.  
  
(개인적으로는) 주로 캐드나 이미지처리 같은 분야가 제일 그럴듯 해 보입니다.  
  
예전에 웹에서 고해상도 의료 이미지 구현에 대해 고민을 하던 솔루션 개발팀이 막 생각나고 그렇습니다.

### Comment 34548

- Author: halfenif
- Created: 2025-02-14T10:11:25+09:00
- Points: 2

> 예제로 배우는 WASM  
https://news.hada.io/topic?id=11891  
  
보고 따라 해 봅니다.

### Comment 34547

- Author: jujumilk3
- Created: 2025-02-14T10:10:10+09:00
- Points: 2

2030년에도 k8s는 건재할 것 같습니다

### Comment 34540

- Author: yangeok
- Created: 2025-02-14T09:50:51+09:00
- Points: 1

결국 docker도 wasm도 알아야하게 되는 것인가요 ㅎㅎ 그래두 docker도 기술이 무르익으면서 접근이 쉬워졌으니 wasm도 비슷하게 접근이 쉬워지는 방향으로 가지 않을까 싶어요

### Comment 34487

- Author: clickin
- Created: 2025-02-13T09:59:52+09:00
- Points: 3

결국 wasm 런타임 성능에 얹혀가는 모양새가 되는데 V8이 JVM과 동일한 계층이 되지 않을까요.  
V8 버전에 따라서 WASM 동작이 달리지고 그걸 디버깅하는 미래가 기다리는게 아닐까 걱정됩니다.

### Comment 34485

- Author: neo
- Created: 2025-02-13T09:54:11+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43020684) 
- 시스템 인터페이스 부족이 더 넓은 채택을 막고 있는 주요 요인임. 파일 접근, 네트워킹 등이 시간이 지나면 통합될 것임
  - 그러나 파일 접근, 네트워킹 등을 추가하면 보안 취약점이 생길 수 있음. 이는 Java의 '한 번 작성, 어디서나 실행' 약속을 무너뜨린 요인임
  - WASM은 컨테이너와 다른 문제를 해결함. WASM은 샌드박스 코드 실행에 효율적임
  - WASM은 Functions-as-a-Service 구현 등에서 표준이 될 가능성이 높음
  - 컨테이너는 그 문제를 해결하지 못함. 보안 경계로서 적합하지 않으며, WASM 바이너리보다 무겁고 시작 비용이 큼
  - 컨테이너는 여러 프로세스, 스레드를 실행하고 OS 기본 기능을 사용하는 데 적합함
- WebAssembly는 진정한 '한 번 작성, 어디서나 실행' 경험을 제공함
  - 그러나 외부와 상호작용하면 이야기가 달라짐. 각 V8 런타임은 미묘하게 다른 인터페이스를 가짐
  - Docker의 성공은 POSIX가 이미 확립된 표준이었기 때문임
- PlatformOps(이전의 DevOps, SRE, Ops)는 복잡한 도구와 프로그램-컨테이너-리눅스의 긴밀한 결합으로 인해 약속이 훼손됨
  - 개발자는 코드 작성과 기능 배포를 원함
  - PlatformOps는 문제를 해결하기 위해 고군분투함
- WASM은 컨테이너를 대체하는 솔루션이 아님. 컨테이너는 PHP의 다른 버전을 충돌 없이 실행하는 문제를 해결함
  - WASM은 그 문제를 해결하지 못함
- WASM의 미래는 언제 올 것인가? 8년이 지났지만 안정적이고 사용하기 쉬운 도구 체인이 없음
  - Rust는 2012년에 출시되어 8년 후 안정적이었음
- WASM은 실제 하드웨어에서 실행되지 않음. 가상 머신으로 간주될 수 있음
  - 컨테이너는 실제 하드웨어에서 직접 실행되는 애플리케이션을 패키징함
  - WASM은 런타임이 필요함. 애플리케이션 내에서 실행됨
  - WASM은 JVM과 .NET이 해결하는 '이식성' 문제를 해결함
  - 컨테이너는 애플리케이션과 종속성을 번들로 묶음
  - 기술은 상호 보완적일 수 있음
- Docker 사용법을 배우는 것은 방해 요소가 아님
  - Dockerfile만 있으면 됨
  - WASM 앱은 여전히 Kubernetes가 필요함
  - WebAssembly는 앞으로 5년간 크게 성장하지 않을 것임
- WASM은 또 다른 추상화 계층임. 모든 것을 대체할지는 다른 솔루션과의 절충에 달려 있음