# 웹어셈블리에서 실행되는 Scheme — Hoot 프로젝트

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

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26512](https://news.hada.io/topic?id=26512)
- GeekNews Markdown: [https://news.hada.io/topic/26512.md](https://news.hada.io/topic/26512.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-02-09T05:37:48+09:00
- Updated: 2026-02-09T05:37:48+09:00
- Original source: [spritely.institute](https://www.spritely.institute/hoot/)
- Points: 2
- Comments: 1

## Topic Body

- **Scheme 코드를 WebAssembly(GC 지원 브라우저)** 에서 실행할 수 있도록 설계된 프로젝트로, Scheme→Wasm **컴파일러와 완전한 Wasm 툴체인**을 포함  
- **GNU Guile 기반**으로 구축되어 있으며, 추가 의존성이 없고 **자급형(toolchain self-contained)** 구조를 가짐  
- Guile REPL 환경에서 **Wasm 인터프리터를 통해 Hoot 바이너리 테스트**가 가능  
- 최신 버전은 **v0.7.0**으로, 릴리스 파일·서명·문서·공식 발표 링크가 제공됨  
- Scheme 언어를 웹 환경으로 확장하려는 시도로, **브라우저 기반 Lisp 생태계 확장 가능성**을 보여줌  

---

### Hoot 개요
- Hoot은 **Spritely Institute**가 개발한 프로젝트로, **Scheme 코드를 WebAssembly(Wasm)** 상에서 실행 가능하게 함  
  - GC(Garbage Collection) 기능을 지원하는 웹 브라우저에서 동작  
  - Scheme 코드를 Wasm으로 변환하는 **컴파일러**와, Wasm 관련 개발을 위한 **완전한 툴체인**을 포함  
- **Guile** 위에 구축되어 있으며, 추가적인 외부 의존성이 없음  
  - 툴체인은 자체적으로 완결되어 있고, **Wasm 인터프리터**를 내장해 Guile REPL에서 Hoot 바이너리를 직접 테스트 가능  

### 배포 및 개발
- 최신 릴리스는 **v0.7.0** 버전으로, 다운로드 파일, 서명, 문서, 공식 발표 링크가 제공됨  
  - 릴리스 파일: `guile-hoot-0.7.0.tar.gz`  
  - 문서 및 서명 파일, 그리고 관련 뉴스 페이지가 함께 제공  
- 개발 버전은 **Codeberg** 저장소에서 접근 가능 (`https://codeberg.org/spritely/hoot`)  

### 관련 자료
- Hoot을 활용한 **인터랙티브 웹페이지 구축** 사례와 **브라우저 내 Scheme 실행** 관련 기사 다수 제공  
  - “Building interactive web pages with Hoot”  
  - “Scheme in the browser: A Hoot of a tale”  
  - “Lisp Game Jam - ‘Wireworld’ - Hoot's low level Wasm tooling in action”  
- **Andy Wingo의 블로그**와 **System Crafters 인터뷰 영상**을 통해 개발자 관점의 추가 정보 확인 가능

## Comments



### Comment 50841

- Author: neo
- Created: 2026-02-09T05:37:48+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46923254) 
- 최근 **Guile**의 개발이 활발해지는 게 흥미로움  
  다만 예전 **Racket** 커뮤니티의 사람들이 많이 옮겨오는 것 같아 아쉬움이 있음  
  커뮤니티가 분리되는 건 슬픈 일이고, Guile은 여전히 Racket보다 **성능**이나 **라이브러리 다양성** 면에서 뒤처지는 느낌임
  - 내 경험상은 오히려 반대였음. Guile이 Racket보다 **시작 속도**가 빠르고, 내가 하는 작업이 대부분 **I/O 중심**이라 Guile이 더 나았음  
    벤치마크는 다르게 나오지만, 직접 확인해볼 필요가 있을 듯함
  - Guile은 현재 **바이트코드 VM + JIT** 구조라 Chez/Racket보다는 느리지만 꽤 빠름  
    60fps로 게임을 돌릴 수 있을 정도이고, GC도 드물게 일어남  
    예전보다 **라이브러리 생태계**도 많이 좋아졌음
  - 예전에 Racket 커뮤니티에서 **‘Missing Stair’ 문제**가 있었다는 블로그 글을 본 기억이 있음  
    ([Missing Stair 위키](https://en.wikipedia.org/wiki/Missing_stair))  
    그 사건 이후 커뮤니티가 분열된 건 어쩔 수 없는 결과로 보임
  - Guile이 주목받는 건 반갑지만 Racket을 과소평가하긴 이름  
    * Guile의 **WASM 작업**은 유망하고, Racket 쪽에서도 Jens Axel Soegaard가 관련 컴파일러를 개발 중임  
    * Racket의 **Chez 기반 재호스팅**은 좋은 선택으로 보이고, 내부 구조도 Guile보다 다루기 쉬워졌을 것 같음  
    * Racket은 여전히 **메타프로그래밍**과 **모듈 시스템**이 강점임  
      예를 들어 [Overeasy](https://docs.racket-lang.org/overeasy/)로 테스트를, [McFly](https://docs.racket-lang.org/mcfly/)로 문서를 인라인으로 작성할 수 있음  
    * Scheme 계열은 여전히 “취업 키워드”를 신경 쓰지 않아도 되는 사람들의 언어로 남아 있음  
      최근 **AI 코드 생성**과 **VC 투자 붕괴** 이후 업계 분위기가 더 어려워진 것도 영향이 있음
  - Guile의 다른 구현체인 **Hoot**(예: V8 위에서 동작)이 벤치마크된 적이 있는지 궁금함

- 프로젝트 자체는 멋지지만, Guile이 아닌 다른 언어를 썼으면 좋겠다는 생각이 듦
  - 그래도 Guile은 **Guix**의 언어이기 때문에 생태계가 풍부함  
    Guix를 통해 **재현 가능한 빌드**를 쉽게 만들 수 있음  
    다만 **디버거**, **매크로 확장기**, **R6RS 표준 라이브러리** 관련 문제는 여전히 남아 있음  
    Racket의 멀티코어 지원은 예전엔 무거웠지만, Guile의 **fibers/futures**와 비교해 지금은 개선된 듯함
  - Guile이 아닌 다른 Scheme 구현을 쓰자는 말이라면, **R6RS/R7RS 표준 문법**을 쓰면 이식은 어렵지 않음

- **WASM으로 컴파일**하는 이런 시도가 다시 나와서 반가움  
  예전엔 열기가 식은 줄 알았는데, 이런 언어들이 늘어나면 **JavaScript를 피할 수 있어서** 좋음

- 이 프로젝트를 보고 미래의 **프로그래밍 언어 방향성**을 생각하게 되었음  
  AI가 주된 코드 작성자가 되면, 언어는 **명확성과 오류 감소** 중심으로 바뀔 것 같음  
  인간에게는 덜 재미있지만, 수정하기 쉬운 코드가 될 것임  
  이런 맥락에서 **Rust** 같은 언어가 상위권을 차지할 듯함  
  다만 **Hoot** 같은 언어가 전문 영역에서도 자리를 잡을 수 있을지, 아니면 **취미용 언어**로 남을지 궁금함
  - 나도 **AI 중심 언어**가 어떤 모습일지 궁금했는데, 아마 **Scheme/Lisp 계열**이 그 방향에 가까울 것 같음

- 정말 멋짐! 혹시 **Cloudflare Workers**에서도 동작할 수 있을지 궁금함

- Guile이 **Windows 지원**을 좀 더 잘했으면 좋겠음

- `repl.wasm`이 1.6MiB라 조금 큰 편 같음. `todo` 예제는 얼마나 될지 궁금함
  - 이 REPL은 가장 작은 바이너리는 아니지만, **gzip 압축 시 339K**로 줄어듦  
    아직 **wasm-opt** 최적화도 적용되지 않았음  
    Hoot은 **AOT 컴파일러**라서 REPL에는 매크로 확장기, 런타임 모듈 시스템, 인터프리터 등 추가 코드가 포함되어 있음  
    실제 예제인 [todo.wasm](https://codeberg.org/spritely/hoot-ffi-demo/)은 566K(압축 시 143K) 정도이며, **가상 DOM diff 알고리즘**도 포함됨  
    추가 최적화로 지역 변수 수를 줄이거나, **stack switching 제안**을 채택하면 크기를 더 줄일 수 있을 것으로 기대함  
    관련 이슈는 [여기](https://codeberg.org/spritely/hoot/issues/193)에 정리되어 있음

- woot (짧은 감탄 표현)

- 이게 바로 **JavaScript**가 원래 지향하던 모습이었음  
  **Netscape**가 C/Java 스타일 문법을 강요하지 않았다면 이런 언어가 되었을지도 모름