Skip to content
Published on

모던 OCaml 2026 — OCaml 5.3 / Multicore / Effect Handlers / Dune / Opam / MirageOS / ReScript / Melange / Jane Street 심층 가이드

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

"OCaml은 산업 언어로서는 항상 다음 분기였다. 그러나 그 다음 분기가 25년째다." — 어느 PL 연구자

이번 글은 2026년 5월 기준 OCaml 생태계의 전체 지도다. 2022년 12월 OCaml 5.0이 Multicore와 Effect Handlers를 가져오면서 "단일 코어 함수형 언어"라는 오랜 약점이 사라졌고, 2025년 1월 5.3까지 안정화되며 산업에서 다시 진지하게 다뤄지기 시작했다. Jane Street은 25년째 OCaml로 트레이딩 시스템을 돌리고, Meta는 Hack과 Flow를 OCaml로 짜고 있으며, Tezos는 XTZ 블록체인의 합의 레이어를 OCaml로 구현해 운영 중이다. 한편 프런트엔드 쪽에서는 ReScript가 BuckleScript의 후계로 자리 잡았고, Melange는 그 컴파일러를 다시 OCaml 본진으로 끌어왔다.

이 글은 OCaml 5.x의 런타임 변화(Multicore, Effect Handlers), Dune/Opam의 도구 표준, MirageOS의 유니커널, JS 컴파일 분기(js_of_ocaml / ReScript / Melange / Reason), 동시성 라이브러리(Eio / Lwt), 웹 프레임워크(Cohttp / Dream), 산업 사례(Tezos / Meta / Jane Street), 학계(KAIST / 京都大学 / Tokyo Tech), 그리고 "누가 OCaml을 배워야 하나"라는 의사결정 가이드까지 13개 챕터로 정리한다.

1. 2026년 모던 OCaml — Multicore의 시대

OCaml은 1996년 INRIA에서 출발한 ML 계열 함수형 언어다. 30년 가까이 산업 언어로서의 "다음 분기"였지만, 2022년 12월 OCaml 5.0의 GA가 한 가지 결정적인 변화를 가져왔다. Multicore 런타임과 Effect Handlers다. 이전까지 OCaml은 단일 스레드 GC를 쓰는, 사실상 단일 코어 언어였다. 5.0 이후로는 도메인(domain) 단위 병렬 실행과 effect 기반 사용자 정의 제어 흐름이 가능해졌다.

2026년 시점에서 OCaml 생태계는 대략 이렇게 정리된다:

  • 컴파일러: OCaml 5.3 (2025-01) — 5.x multicore 라인의 안정화 버전
  • 빌드: Dune (Jane Street + 커뮤니티) — 사실상 표준
  • 패키지: Opam (OCaml Package Manager) — 사실상 표준
  • 유니커널: MirageOS — Anil Madhavapeddy + 케임브리지/Tarides
  • JS 컴파일: js_of_ocaml (전통), ReScript (Hongbo Zhang, 분리됨), Melange (ReScript 컴파일러를 OCaml로 되돌림), Reason (Facebook 신택스)
  • 동시성: Eio (effect 기반, multicore), Lwt (전통, 이벤트 루프), Async (Jane Street)
  • 웹: Cohttp (HTTP 기본), Dream (Rails-like 풀스택), Opium, Httpaf
  • 산업: Jane Street (전 세계 OCaml 1위 채용처), Tezos (XTZ 블록체인), Meta (Hack/Flow), Docker (초기 OCaml로 짜였음), Tarides (MirageOS/Tezos 컨설팅)
  • 학계: KAIST PL lab (한국), 京都大学 PL lab/Tokyo Tech (일본), Cambridge OCaml Labs, INRIA

흥미로운 사실 하나. 2024-2025년 사이 Coq가 Rocq로 리브랜딩되면서 (Coq → Rocq, 별도 글로 다룸), 형식 검증 도구 쪽에서 OCaml 기반 생태계의 위상이 다시 한 번 정리됐다. Rocq의 처리 백엔드도 여전히 OCaml로 짜여 있다. Lean 4가 부상했음에도 불구하고, OCaml은 "PL 연구자가 쓰는 언어"의 자리를 놓치지 않았다.

또 한 가지. 2026년 OCaml은 AI 학습 인프라의 작은 틈새시장에서도 다시 주목받고 있다. Tarides가 발표한 Eio + multicore 벤치마크가 Tokio/Async-std 대비 단일 노드 throughput에서 경쟁력을 보였고, MirageOS 기반 유니커널이 sandboxed code execution 환경의 후보로 거론된다. "OCaml은 죽었다"는 농담은 이제 농담이 아니라 틀린 말이 됐다.

2. OCaml 5.x — Multicore + Effect Handlers (GA 2022.12)

OCaml 5.0은 2022년 12월에 GA됐다. Multicore OCaml 프로젝트는 2014년부터 Anil Madhavapeddy, KC Sivaramakrishnan, Stephen Dolan을 중심으로 케임브리지에서 진행됐다. 약 8년 동안 OCaml 본진에 들어가지 않는 별도 브랜치였다가, 4.14에서 안정화 작업을 거쳐 5.0으로 합쳐졌다.

5.x가 가져온 두 가지 핵심:

1) Domain 기반 병렬화. OCaml은 이제 OS 스레드 위에 도메인(domain)을 만들고, 각 도메인이 독립된 minor heap을 갖는다. Major heap은 공유되지만 GC는 도메인 단위로 동기화된다. 결과는 "진짜 멀티코어 실행". Domain.spawn 으로 새 도메인을 띄우고, Atomic 모듈로 락 없는 원자 연산을 한다.

(* domain_demo.ml *)
let count = Atomic.make 0

let worker () =
  for _ = 1 to 1_000_000 do
    Atomic.incr count
  done

let () =
  let d1 = Domain.spawn worker in
  let d2 = Domain.spawn worker in
  Domain.join d1;
  Domain.join d2;
  Printf.printf "final = %d\n" (Atomic.get count)

2) Effect Handlers. Effect는 OCaml 5에서 가장 큰 언어 차원의 추가다. 함수가 effect를 발생(perform)시키면 호출자가 그 effect를 핸들(handle)하거나 위로 전파한다. 결과는 "한 언어 안에서 user-space 코루틴, generator, async/await, exception, dependency injection을 같은 메커니즘으로 표현 가능". 다른 언어가 각각 별도 기능으로 가진 것을 OCaml은 effect 하나로 통합한다.

open Effect
open Effect.Deep

type _ Effect.t += Yield : int -> unit Effect.t

let producer () =
  for i = 1 to 5 do
    perform (Yield i)
  done

let () =
  try_with producer ()
    { effc = fun (type a) (eff : a Effect.t) ->
        match eff with
        | Yield n -> Some (fun (k : (a, _) continuation) ->
            Printf.printf "got %d\n" n;
            continue k ())
        | _ -> None }

Effect의 진가는 Eio(다음 챕터)에서 드러난다. async/await을 별도 키워드 없이 라이브러리 수준에서 구현할 수 있게 된 것이 effect의 핵심 효과다.

5.x의 약점:

  • C FFI 호환성: 5.0 출시 직후 일부 C 바인딩이 multicore 런타임에서 안 됨. 2024년 5.2까지 대부분 정리됨
  • 퍼포먼스 회귀: 일부 마이크로 벤치에서 4.14 대비 단일 스레드 성능이 5% 정도 떨어지는 경우 있음. 5.2에서 대부분 회복
  • Effect의 학습 곡선: 정적 타입에 effect row가 없음(Koka와 달리). 검사 시점에 핸들되지 않은 effect를 잡지 못함 → 런타임에 Unhandled 예외

그래도 5.x는 OCaml의 가장 큰 도약이다. 2026년 현재 신규 프로젝트는 거의 모두 5.x를 쓴다.

3. OCaml 5.3 (2025.1) — 안정화

OCaml 5.1은 2023년 9월, 5.2는 2024년 5월, 5.3은 2025년 1월에 나왔다. 5.x 라인은 분기마다 한 번씩 메이저 업데이트가 도는 cadence를 잡았다.

5.3의 주요 변경:

  • Effect handler의 정적 검사 개선: 5.3에서 effect 키워드가 정식 문법으로 들어왔고(이전엔 라이브러리 수준 type _ Effect.t += ...), 일부 effect를 컴파일러가 inline 처리해 오버헤드 감소
  • GC 튜닝: 멀티 도메인에서 minor GC가 더 잘 동작하도록. 도메인 간 promotion 비용이 5.2 대비 30% 감소
  • Statmemprof 표준화: 메모리 프로파일러가 표준 라이브러리에 들어옴
  • Domain.recommended_domain_count: 시스템에 적절한 도메인 수를 추천하는 API. Eio와 Picos가 이걸 디폴트로 씀
  • 포팅 정리: musl libc, RISC-V 64bit, ARM 32bit big-endian 지원 강화
  • 자잘한 함수 추가: String.starts_with / String.ends_with 가 표준에. In_channel.read_lines 등

5.3은 5.x 라인의 첫 LTS급 안정화 버전으로 간주된다. Jane Street, Tezos, Tarides 모두 2025년 중반에 프로덕션을 5.3으로 옮겼다.

# 2026년 표준 OCaml 설치 (Opam 기반)
opam init -y
opam switch create 5.3.0
eval $(opam env)
ocaml --version
# The OCaml toplevel, version 5.3.0

5.4 / 5.5는 2025년 가을부터 nightly에서 작업 중이다. 주로 effect row type 도입(Koka 스타일)을 둘러싼 RFC가 활발하다. 다만 OCaml 코어 팀은 type system을 보수적으로 진화시키는 것으로 유명해서, 5.5에 effect row가 정식으로 들어갈지는 미지수다.

4. Dune — 빌드 시스템 표준

Dune은 Jane Street이 만든 OCaml 빌드 시스템이다. 원래 이름은 jbuilder였고, 2018년 1.0과 함께 Dune으로 개명했다. 2026년 현재 사실상 모든 OCaml 프로젝트가 Dune을 쓴다. ocamlbuild, oasis, omake는 사실상 레거시다.

Dune의 강점:

  • 선언적 빌드 파일: dune 파일에 S-expression으로 라이브러리/실행파일/테스트를 선언
  • 자동 의존성 추출: ocamlfind / ocamldep 기반 의존성 자동 계산
  • 점진 빌드와 캐싱: 파일 단위가 아니라 모듈/구성 단위로 캐시
  • 단일 폴더 멀티 라이브러리: 한 디렉토리 안에 여러 라이브러리/실행파일 정의 가능
  • Cram / 인라인 테스트: let%test 같은 PPX와 통합
  • Watch 모드: dune build -w 로 파일 변경 감지 빌드
  • 크로스 컴파일: dune build --workspace 로 여러 컴파일러 동시 빌드

기본 dune 파일:

(library
 (name my_lib)
 (public_name my_lib)
 (libraries base core lwt cohttp-lwt-unix)
 (preprocess (pps ppx_jane)))

(executable
 (name main)
 (public_name myapp)
 (libraries my_lib))

dune-project 파일:

(lang dune 3.16)
(name myapp)
(generate_opam_files true)

(package
 (name myapp)
 (synopsis "A demo OCaml app")
 (depends
  (ocaml (>= 5.3.0))
  (dune (>= 3.16))
  eio
  cohttp-eio))

Diskuv 사례: Diskuv는 Windows에서 OCaml 개발 환경을 만든 회사다. Dune을 Windows-native로 동작시키는 작업을 주도했고, 2024년 dune 3.14부터 Windows 지원이 1급 시민이 됐다. 이전에는 WSL 없이는 OCaml을 Windows에서 쓰기가 매우 어려웠다. Diskuv의 기여 덕분에 2026년에는 winget install Diskuv.OCaml 한 줄로 설치가 된다.

Dune의 약점:

  • 에러 메시지가 거대한 S-expression: 처음 보면 압도적
  • 외부 빌드 시스템과의 통합이 부족: Bazel/Buck과 직접 연결되지 않음
  • 모노레포 스케일 한계: 거대한 모노레포에서 incremental build가 느려지는 사례 있음. Jane Street은 내부적으로 fork된 dune 변형 사용

대안은 사실상 없다. 2026년 OCaml 신규 프로젝트는 Dune이 정답이다.

5. Opam — 패키지 매니저

Opam은 2012년 OCamlPro와 INRIA가 함께 시작한 OCaml 패키지 매니저다. 이름은 "OCaml Package Manager"의 약자. 2026년 현재 opam-repository에 7,000개 이상의 패키지가 등록돼 있고, 매주 새 릴리스가 들어온다.

Opam의 핵심 모델:

  • Switch: 컴파일러 + 패키지 묶음. 프로젝트마다 별도 switch를 만들 수 있음. opam switch create my-proj 5.3.0
  • Repository: 패키지 메타데이터 모음. 기본은 opam-repository. 사내 저장소 추가 가능
  • Pin: 로컬 디렉토리 또는 Git URL을 직접 패키지로. opam pin add my_lib .
  • Lock 파일: opam lock 으로 정확한 버전 잠금. 2.1부터 1급 기능

기본 명령어:

# 새 switch 만들기
opam switch create my-proj 5.3.0

# 의존성 설치
opam install dune eio cohttp-eio dream

# 로컬 패키지 pin
opam pin add my_lib .

# Lock 파일 생성
opam lock .

# 패키지 검색
opam search effect

opam-repository는 GitHub에 있고, 누구나 PR로 새 패키지 또는 새 버전을 등록할 수 있다. 등록 과정에서 CI가 빌드/테스트를 자동 검증한다. 이게 OCaml 생태계 품질의 큰 기여 요인이다 — 깨진 패키지가 거의 없다.

Opam의 약점:

  • 느림: 의존성 해결이 다른 매니저(Cargo, npm) 대비 눈에 띄게 느림. solver가 OPL/Mancoosi 학술 기반이라 그렇다
  • bytestring solver의 비결정성: 같은 의존성 트리에서도 OS/플랫폼에 따라 다른 버전이 선택되는 케이스
  • 글로벌 상태: switch가 글로벌 상태라 한 머신에서 여러 프로젝트 관리시 혼동. 해결책은 local switch (opam switch create . 5.3.0)

2026년 베스트 프랙티스는 프로젝트마다 local switch + opam lock이다. CI에서 lock 파일을 검사하면 재현 가능한 빌드가 된다.

6. MirageOS — 유니커널

MirageOS는 케임브리지 OCaml Labs에서 Anil Madhavapeddy가 주도한 유니커널 프로젝트다. 2013년 1.0이 나왔고, 2026년 현재 4.x 라인이 안정화돼 있다.

유니커널(unikernel)의 컨셉:

  • 하나의 애플리케이션 + OS 기능을 단일 바이너리로: 일반적인 Linux + 컨테이너 + 앱이 아니라, 앱과 필요한 OS 기능만 골라 단일 이미지로 컴파일
  • 하이퍼바이저 위에 직접: KVM / Xen / Solo5 같은 hypervisor 위에 직접 부팅. 게스트 OS 없음
  • 수 MB 이미지: 보통 5-20MB. 부팅 시간 수십 밀리초
  • 공격 표면 최소화: 일반 OS의 99%를 제거. shell, package manager, 불필요한 시스템 콜 다 없음

MirageOS는 OCaml로 짜인 유니커널을 만든다. 모듈 시스템(functor)을 활용해 "네트워크 스택", "파일 시스템", "TCP/IP" 같은 컴포넌트를 추상화하고, 빌드 시점에 타겟에 맞는 구현체를 주입한다.

(* unikernel.ml *)
open Lwt.Infix

module Main (S: Mirage_stack.V4V6) = struct
  let start s =
    let port = 8080 in
    let cb flow =
      let ip, p = S.TCP.dst flow in
      Logs.info (fun f -> f "client %a:%d" Ipaddr.pp ip p);
      S.TCP.write flow (Cstruct.of_string "hello unikernel\n") >>= fun _ ->
      S.TCP.close flow
    in
    S.TCP.listen (S.tcp s) ~port cb;
    S.listen s
end

# 빌드와 실행
mirage configure -t hvt   # Solo5 hvt 타겟
make depend
make
solo5-hvt --net:service=tap0 -- ./unikernel.hvt

2026년 MirageOS 사용처:

  • Robur (독일 비영리, MirageOS 메인 컨트리뷰터): TLS proxy, DNS resolver, OpenVPN 등을 유니커널로 운영
  • Tarides (프랑스 OCaml 컨설팅): MirageOS 기반 sandboxed 빌드/실행 환경 연구
  • Tezos: 일부 노드 컴포넌트를 MirageOS로 운영 검토
  • AI sandboxed execution: 2025년부터 LLM이 생성한 코드를 안전하게 실행할 환경으로 MirageOS가 다시 거론됨. 컨테이너보다 격리 강도가 높음

MirageOS의 약점:

  • 생태계 크기: 일반 OCaml 라이브러리를 그대로 못 쓸 때가 많음(POSIX 가정이 깨짐)
  • 디버깅: 일반 OS 도구가 안 통함. gdb 원격 연결 등을 새로 배워야
  • 운영 인력 부족: 유니커널을 운영해본 SRE가 거의 없음

그래도 MirageOS는 OCaml의 가장 독특한 성과 중 하나다. "함수형 모듈 시스템으로 OS를 조립한다"는 아이디어가 실제로 운영 가능한 형태로 동작한다.

7. js_of_ocaml — JS 컴파일

js_of_ocaml(jsoo)은 2010년부터 INRIA의 Jérôme Vouillon이 주도한 OCaml-to-JavaScript 컴파일러다. OCaml bytecode를 입력으로 받아 JavaScript를 출력한다. 즉 OCaml 컴파일러가 바이트코드까지 만들고 나면, jsoo가 그 바이트코드를 JS로 옮긴다.

특징:

  • 전체 OCaml 호환: 표준 라이브러리, Lwt, Effect까지 거의 다 지원. ML 측 의미를 그대로 유지
  • 거대한 출력: 일반적으로 1-3MB의 JS 번들. 표준 라이브러리를 다 포함해야 하기 때문
  • Tree shaking: 5.x 시점에 dead code elimination이 많이 개선됐지만, 여전히 ReScript 대비 출력은 크다
# 기본 사용
ocamlfind ocamlc -package js_of_ocaml -package js_of_ocaml-ppx \
  -linkpkg main.ml -o main.byte
js_of_ocaml main.byte -o main.js

js_of_ocaml의 강점은 **"OCaml 코드를 거의 그대로 JS에서 돌릴 수 있다"**는 점이다. Tezos 블록체인 클라이언트는 OCaml 코드의 일부를 jsoo로 브라우저에서 돌린다. Coq → Rocq의 jsCoq 같은 학술 도구도 jsoo 기반이다.

약점은 번들 크기와 JS 친화성 부족. JavaScript와 직접 상호 운용할 때 OCaml 타입을 JS 객체로 변환하는 작업이 번거롭다. 이 약점을 메우려고 등장한 게 다음 챕터의 ReScript다.

8. ReScript (구 BuckleScript, Hongbo Zhang) — JS 친화

BuckleScript는 2016년 Bloomberg의 Hongbo Zhang(중국 출신, 현재 ReScript Association)이 만든 OCaml-to-JS 컴파일러다. js_of_ocaml과 정반대 철학으로 시작했다: OCaml의 AST를 받아서 사람이 읽을 수 있는 JS를 출력한다. 즉 출력 JS가 입력 OCaml과 1:1 가깝게 매핑된다.

2020년 BuckleScript는 ReScript로 리브랜딩됐다. 이때 큰 결정이 하나 있었다: OCaml 신택스 호환을 끊고, ReScript만의 신택스로 분리한다. OCaml의 ;;, let rec, module 등이 ReScript에서는 다른 형태가 됐다. JavaScript 개발자가 친숙하게 느끼는 방향(중괄호 블록, let/const 비슷한 표기)으로 진화했다.

// ReScript 2026 syntax
let greet = (name) => {
  let msg = `Hello, ${name}!`
  Js.log(msg)
}

let main = () => {
  greet("ReScript")
}

main()

ReScript의 강점:

  • 출력 JS가 작고 깨끗: 사람이 읽을 수 있는 JS. js_of_ocaml 대비 번들 10배 작음
  • TypeScript 호환 강함: genType로 ReScript 타입을 TS 타입으로 export
  • React 친화: 공식 rescript-react 가 React의 1급 시민
  • Hot reload 빠름: 컴파일러가 매우 빨라서 변경-반영 사이클이 짧음

약점:

  • OCaml 분리: ReScript는 더 이상 OCaml이 아님. 의존성 생태계도 분리됨. opam 패키지 못 씀
  • PPX 미지원: OCaml의 강력한 매크로 시스템을 못 씀
  • 소수 시장: TypeScript에 비해 시장 점유율 작음

2024-2025년에 ReScript는 ReScript 11 / 12를 거치며 안정화됐고, 2026년 현재 일본 일부 스타트업(Mercari 일부 팀, 작은 핀테크)과 유럽 작은 회사들에서 운영된다. 한국 채용 시장에서는 거의 보이지 않는다.

9. Melange — ReScript 컴파일러를 OCaml로

Melange는 2022년 Antonio Monteiro가 시작한 프로젝트다. 핵심 아이디어는 단순하다: ReScript가 BuckleScript에서 갈라져 OCaml 호환을 끊었으니, BuckleScript의 OCaml 호환 코어를 다시 OCaml 본진으로 되돌리자.

Melange는 BuckleScript의 OCaml-to-JS 백엔드를 fork해서, ReScript와 다른 방향으로 진화시킨다. 차이점:

  • OCaml 신택스 그대로: ReScript의 새 신택스가 아니라 OCaml 신택스 사용
  • Dune 통합: 빌드를 Dune으로. ReScript의 자체 빌더가 아님
  • Opam 통합: 패키지 매니저로 opam 사용. 일반 OCaml 라이브러리를 그대로 쓸 수 있는 경우가 많음
  • Reason 신택스도 가능: Reason(Facebook 신택스)을 frontend로 쓸 수 있음
(* Melange 코드 — OCaml 신택스 *)
let greet name =
  let msg = Printf.sprintf "Hello, %s!" name in
  Js.log msg

let () = greet "Melange"

; dune file for Melange
(melange.emit
 (target output)
 (libraries my_lib)
 (preprocess (pps melange.ppx)))

Melange의 포지션은 명확하다: "OCaml 개발자가 JS를 출력하고 싶을 때". ReScript가 JS 개발자를 끌어들이려고 OCaml에서 멀어진 반면, Melange는 OCaml 개발자가 그대로 프런트엔드까지 같은 언어/도구로 가게 한다.

2024-2025년 Melange는 1.0과 2.0을 거치며 안정화됐다. 2026년 현재 작은 OCaml 풀스택 회사들이 Melange를 쓴다. Tarides가 일부 내부 도구를 Melange로 만들고, Ahrefs(원래 OCaml 회사)도 일부 프런트엔드 Melange로 시도 중이다.

10. Reason — Facebook 신택스

Reason은 2017년 Facebook의 Jordan Walke(React 창시자)가 만든 OCaml 신택스다. 핵심 발상: OCaml의 기능은 다 좋은데 신택스가 JavaScript 개발자에게 너무 낯서니, OCaml의 시맨틱을 그대로 둔 채 신택스만 JS-like으로 바꾸자.

Reason 예시:

/* Reason syntax */
let greet = (name) => {
  let msg = "Hello, " ++ name ++ "!";
  Js.log(msg);
};

let () = greet("Reason");

대응되는 OCaml:

(* OCaml syntax — same semantics *)
let greet name =
  let msg = "Hello, " ^ name ^ "!" in
  Js.log msg

let () = greet "Reason"

Reason은 OCaml로 컴파일되고, 다시 OCaml이 BuckleScript/Melange로 JS로 컴파일된다. 즉 Reason → OCaml AST → JS의 흐름이다.

2017-2020년 사이 Reason은 Facebook 내부에서 빠르게 채택됐다. 그러나 2020년 BuckleScript가 ReScript로 분리되면서 Reason의 입지가 흔들렸다 — ReScript는 자체 신택스를 채택했고, Reason의 자리가 애매해졌다. Facebook도 점점 Reason 사용을 줄였다.

2026년 Reason의 포지션:

  • 여전히 OCaml frontend로 동작: 컴파일러가 살아 있고 Dune이 지원
  • Melange에서 Reason 신택스 가능: Melange 사용자 중 일부가 Reason 신택스로 작성
  • 활발한 신규 채택은 적음: ReScript / 순수 OCaml로 분기됨

Reason은 죽지 않았지만 정점은 지났다. 새 프로젝트라면 Melange + OCaml 신택스가 합리적 디폴트다.

11. Eio — Effect 기반 동시성 (Multicore)

Eio는 OCaml 5의 effect handlers를 활용한 새로운 동시성/IO 라이브러리다. 2022년부터 케임브리지 OCaml Labs와 Tarides가 주도해 개발 중이다. 2026년 현재 1.0 직전 단계로, Eio 0.17 정도가 실사용된다.

Eio의 핵심:

  • Effect 기반: async/await 같은 키워드 없음. 그냥 일반 함수처럼 호출하고, effect로 yield/resume
  • 구조적 동시성: Switch 안에서 fiber를 spawn하면, switch가 끝날 때 모든 fiber가 정리됨. Trio / Kotlin Coroutines 와 같은 철학
  • Multicore 친화: 도메인 풀을 만들고 fiber를 도메인에 스케줄. CPU-bound 워크로드도 진짜 병렬 실행
  • Backend 추상화: Eio_main.run 이 OS에 맞는 백엔드(io_uring on Linux, kqueue on macOS, IOCP on Windows) 선택
open Eio.Std

let fetch url =
  traceln "fetching %s" url;
  Eio.Time.sleep (Eio.Stdenv.clock env) 1.0;
  url ^ " — done"

let () =
  Eio_main.run @@ fun env ->
  Switch.run @@ fun sw ->
  let a = Fiber.fork_promise ~sw (fun () -> fetch "https://a.example.com") in
  let b = Fiber.fork_promise ~sw (fun () -> fetch "https://b.example.com") in
  traceln "%s" (Promise.await_exn a);
  traceln "%s" (Promise.await_exn b)

Eio의 강점:

  • 명시적 IO 자원 전달: env 같은 capability를 통해 IO 자원이 전달됨. 임의의 함수가 임의의 IO를 못 함. 보안과 테스트 용이성
  • 취소가 1급: fiber 취소가 잘 정의됨. Lwt의 약점 중 하나였던 취소 의미 명확화
  • multicore 활용: Lwt는 단일 도메인. Eio는 여러 도메인에 fiber를 분산 가능

약점:

  • 아직 1.0 전: API가 깨질 수 있음. 2026년 후반에 1.0 예정
  • 생태계 작음: Cohttp-eio, Dream-eio 같은 변형이 늘고 있지만 아직 Lwt 만큼 많지 않음
  • Effect의 학습 곡선: 디버깅 시 effect 핸들 체인을 따라가는 게 익숙해지기 전엔 어려움

Tarides가 발표한 2025년 벤치마크에서 Eio + multicore가 동일 하드웨어에서 Tokio (Rust async) 대비 비슷한 throughput을 보였다. 단일 노드 IO-heavy 워크로드에서 OCaml이 다시 경쟁 가능해진 결정적 증거다.

12. Lwt — 오래된 동시성

Lwt(Light-weight threads)는 2003년 Jérôme Vouillon이 만든 OCaml의 전통적 concurrent 라이브러리다. 단일 스레드 이벤트 루프 위에서 promise('a Lwt.t)를 합성하는 방식. JavaScript의 Promise와 거의 동일한 모델.

open Lwt.Syntax

let fetch url =
  let* () = Lwt_unix.sleep 1.0 in
  Lwt.return (url ^ " — done")

let () =
  Lwt_main.run
    (let* a = fetch "https://a.example.com" in
     let* b = fetch "https://b.example.com" in
     Lwt_io.printlf "%s / %s" a b)

Lwt의 강점:

  • 성숙: 20년 이상 운영됨. 거의 모든 OCaml 네트워크/IO 라이브러리가 Lwt 버전을 가짐 (cohttp-lwt, irmin-lwt 등)
  • 단일 스레드라 단순: race condition이 없음. JS의 async와 같은 모델
  • 인프라 호환: TLS, SSH, HTTP/2 등 거의 모든 프로토콜이 Lwt에 있음

약점:

  • 단일 도메인: 진짜 멀티코어 활용 못 함. CPU-bound 워크로드는 별도 프로세스로 분리해야
  • promise.bind의 cognitive overhead: let%lwt / let* ppx로 완화됐지만 여전히 명시적
  • 취소가 약함: cancellation의 의미가 명확하지 않음. Eio가 이걸 정정함

2026년 시점에서 Lwt는 레거시 + 안정성, Eio는 신규 + 멀티코어 의 구도다. 새 프로젝트는 Eio를 고려하지만, 기존 운영 시스템(Tezos, Mirage 일부)은 Lwt에 묶여 있고 마이그레이션이 진행 중이다.

Async(다음 챕터): Jane Street 내부에서 만든 동시성 라이브러리. Lwt와 비슷한 promise 기반이지만 별도 코드베이스. Jane Street 생태계 전용으로 봐도 무방.

13. Cohttp / Dream — HTTP / 웹

Cohttp는 OCaml의 기본 HTTP 라이브러리다. Anil Madhavapeddy가 시작했고 MirageOS 생태계의 핵심 컴포넌트. Lwt, Async, Eio 백엔드 모두 지원한다.

open Lwt.Syntax
open Cohttp_lwt_unix

let server =
  let callback _conn req _body =
    let uri = Cohttp.Request.uri req in
    Server.respond_string ~status:`OK
      ~body:(Printf.sprintf "you hit %s" (Uri.path uri)) ()
  in
  Server.create ~mode:(`TCP (`Port 8080)) (Server.make ~callback ())

let () = Lwt_main.run server

Cohttp는 저수준이다. 라우팅, 미들웨어, 템플릿 같은 건 직접 구성해야. 이걸 보완하는 게 Dream이다.

Dream은 2021년 Anton Bachin이 만든 OCaml 웹 프레임워크다. 철학은 "OCaml의 Rails / Flask". 단일 파일에서 라우터, 미들웨어, 템플릿, WebSocket, 세션까지 다 다룬다.

let () =
  Dream.run
  @@ Dream.logger
  @@ Dream.router [
    Dream.get "/" (fun _ -> Dream.html "Hello Dream!");
    Dream.get "/users/:id" (fun req ->
      let id = Dream.param req "id" in
      Dream.html (Printf.sprintf "user %s" id));
    Dream.post "/login" (fun req ->
      let%lwt body = Dream.body req in
      Dream.html (Printf.sprintf "got %s" body));
  ]

Dream의 특징:

  • 단일 파일 시작 가능: 작은 데모는 50라인 안에 풀스택
  • WebSocket / SSE 1급: 둘 다 라이브러리 핵심 기능
  • 세션 / CSRF / Cookies: 보안 기본 갖춤
  • 템플릿 통합: 자체 dream-eml 으로 HTML 템플릿
  • Lwt 기반: 2026년에도 여전히 Lwt. Eio 포팅 작업 중

대안 웹 프레임워크: Opium (Sinatra-like, 가벼움), Httpaf (저수준 고성능 HTTP/1.1), H2 (HTTP/2 구현).

2026년 OCaml 웹 개발 디폴트는 Dream + Cohttp-lwt 또는 **Dream + Eio (포팅 시)**다. 작은 마이크로서비스라면 Opium도 좋은 선택.

14. Tezos (XTZ) — 블록체인의 OCaml

Tezos는 2018년 메인넷이 론칭된 PoS 블록체인이다. 합의 레이어와 노드 전체가 OCaml로 작성됐고, 2026년 현재 시가총액 기준 상위 30위권을 유지한다. XTZ가 티커.

Tezos가 OCaml인 이유는 명확하다 — on-chain 거버넌스가 protocol amendment를 자동으로 적용한다. 새 프로토콜이 제안되면 stakeholder가 투표하고, 통과되면 노드가 자동으로 새 코드를 받아 활성화한다. 이 메커니즘은 타입 안전과 포멀 검증이 필수고, OCaml은 그걸 가장 잘 지원하는 산업 언어다.

Tezos 노드 구조:

  • Shell: 노드 본체. P2P, mempool, RPC 처리. Lwt 기반
  • Protocol: 합의/거버넌스/스마트 컨트랙트 규칙. Functor로 추상화돼 있어서 amendment 시 교체됨
  • Michelson: 스마트 컨트랙트 VM 언어. 스택 기반, 강타입. OCaml로 구현
  • Storage: Irmin (OCaml로 짠 Git-like content-addressable storage)
(* Tezos 코드 스니펫 — Michelson 인터프리터 일부 *)
let step_instr (instr : ('bef, 'aft) Script.instr) (stack : 'bef stack) :
    'aft stack tzresult Lwt.t =
  match instr, stack with
  | Add_int, Item (Int a, Item (Int b, rest)) ->
      return (Item (Int (Z.add a b), rest))
  | Push (ty, v), rest ->
      return (Item (Cast.cast ty v, rest))
  | _ -> fail Bad_stack

Tezos 생태계는 OCaml의 가장 큰 산업 사례다. Nomadic Labs, Marigold, Tarides, TriliTech 같은 회사들이 Tezos 코어 개발에 참여하고, 모두 OCaml 풀타임 채용을 한다.

2024-2025년 Tezos는 Adaptive Issuance (인플레이션 동적 조정), Smart Rollups (Layer 2), Data Availability Layer를 추가하며 진화했다. 2026년 현재는 Quebec → Rio → Seoul 프로토콜 라인으로 진행 중. 프로토콜 amendment 사례 자체가 OCaml 모듈 시스템의 모범 사례로 학계에서 자주 인용된다.

15. Hack (Meta) / Flow (Meta) / Async (Jane Street) — 산업

Hack (Meta): PHP에 점진적 타입과 generics, async을 추가한 언어. 2014년 공개. Meta 내부에서 Facebook 백엔드 대부분을 굴린다. 컴파일러와 타입 검사기가 OCaml로 짜여 있다. HHVM(VM)은 C++이지만, 타입 체커 / 인터프리터 일부 / 정적 분석은 OCaml.

Flow (Meta): JavaScript용 정적 타입 검사기. 2014년 공개. TypeScript와 라이벌이었지만 2020년대 후반 TypeScript 우세로 시장에서 밀렸다. 그럼에도 Meta 내부 JS 코드베이스에는 여전히 Flow가 운영된다. Flow도 OCaml로 짜여 있다. 2026년 현재 Flow의 활발한 외부 채택은 줄었지만, Meta 내부에선 살아 있다.

Async (Jane Street): Jane Street이 만든 OCaml concurrent 라이브러리. Lwt와 비슷한 promise 기반이지만 별도 구현. Deferred.t 가 Lwt의 'a Lwt.t 와 비슷한 역할. Jane Street 코드베이스 전체가 Async 기반이다.

open Core
open Async

let fetch url =
  let%bind () = Clock.after (Time_float.Span.of_sec 1.0) in
  return (url ^ " — done")

let main () =
  let%bind a = fetch "https://a.example.com" in
  let%bind b = fetch "https://b.example.com" in
  printf "%s / %s\n" a b;
  return ()

let () =
  Command.async ~summary:"demo"
    (Command.Param.return main)
  |> Command_unix.run

세 가지 모두 OCaml이 산업에서 실제로 운영된다는 증거다. Hack은 Meta의 트래픽을 받고, Flow는 Meta 내부 JS를 검사하고, Async는 Jane Street의 트레이딩 시스템 전체를 굴린다.

16. Jane Street — 가장 큰 OCaml 회사

Jane Street은 2000년 설립된 양적 거래(quant trading) 회사다. 본사는 뉴욕. 2026년 현재 약 3,000명 직원, 그중 1,500명 이상이 엔지니어다. 전 세계에서 OCaml 채용이 가장 많은 회사.

Jane Street의 OCaml 코드베이스는 약 2,500만 라인으로 추정된다. 모든 트레이딩 시스템, 백오피스, 데이터 파이프라인, 내부 도구가 OCaml로 짜여 있다. C++/Python/Java 같은 다른 언어도 쓰지만 비중은 작다.

Jane Street의 오픈소스 기여:

  • Dune: 빌드 시스템 (위에서 다룸)
  • Core: 표준 라이브러리 대안. OCaml의 stdlib보다 풍부하고 일관된 API
  • Async: 동시성 라이브러리
  • ppx_jane: PPX 메타프로그래밍 모음 (deriving, expect tests, sexp 등)
  • Bonsai: OCaml용 React-like 프런트엔드 프레임워크 (incremental computation)
  • Magic Trace: Intel PT 기반 백트레이스 시각화 도구
  • Memtrace: 메모리 프로파일러
(* Jane Street 스타일 — Core + ppx_jane *)
open Core

let%test_unit "list sum" =
  [%test_eq: int] (List.fold ~init:0 ~f:(+) [1; 2; 3]) 6

type point = { x: float; y: float }
[@@deriving sexp, compare, equal, fields]

let () =
  let p = { x = 1.0; y = 2.0 } in
  printf !"%{sexp: point}\n" p

Jane Street의 채용 문화:

  • OCaml 모르고 입사 가능: 입사 후 회사가 OCaml을 가르침. 인턴/신입 대상 OCaml 부트캠프 운영
  • 인턴이 거대한 비중: 매년 약 200명 이상 인턴. 미국 대학(MIT, CMU, Princeton, Harvard, Stanford)에서 우수 학부생 모집
  • 연봉이 높기로 유명: 신입 패키지 50만-100만 달러 사례가 흔함

Jane Street은 OCaml의 단일 최대 후원자이자, OCaml이 산업에서 진지하게 다뤄지는 결정적 이유다. 만약 Jane Street이 OCaml을 버리면 OCaml 생태계의 자금/인력이 50% 이상 사라질 거란 우스개도 있다.

17. 한국 / 일본 — KAIST PL lab, 京都大学 PL lab

OCaml은 산업보다 학계에서 강하다. 특히 PL(Programming Languages) 연구실에서 핵심 도구다.

한국 — KAIST PL lab:

  • KAIST Programming Languages Laboratory (이광근 교수 외): 정적 분석, 추상 해석, 형식 검증 연구. 도구 구현에 OCaml 사용. Sparrow 분석기 같은 결과물
  • SNU PL lab (허충길 교수 외): 컴파일러 검증(CompCert 활용), Coq/Rocq + OCaml 조합으로 형식 증명 연구
  • POSTECH (강성원 교수 외): 타입 시스템, effect type 연구
  • 한국 산업 OCaml 채용: 거의 없음. Jane Street의 한국 지사는 없으나, 원격으로 한국인 엔지니어가 일하는 사례 존재

일본 — 京都大学 / Tokyo Tech:

  • 京都大学 PL lab (마사미치 쿠수노키 외, 五十嵐淳 그룹): 타입 이론, 의존 타입, gradual typing 연구. OCaml 기반 도구 다수
  • Tokyo Tech (도쿄공업대학, 현 Institute of Science Tokyo): 함수형 프로그래밍 / 모델 검사 연구. OCaml은 표준 도구
  • 東京大学 IPL: PL/SE 연구. Coq/Rocq + OCaml 활용
  • 일본 산업 OCaml 채용: 매우 적음. Ahrefs(분석 SaaS, 원래 OCaml 회사) 일본 원격 채용 일부, Mercari 일부 실험적 사용

학계 OCaml 사용은 두 가지 이유다. (1) ML 시리즈가 PL 연구의 lingua franca, (2) 형식 검증 도구(Rocq, F, Why3, Cubicle 등)가 OCaml로 짜였음*. PL 박사를 한국/일본에서 하면 OCaml을 안 쓸 수 없다.

18. 누가 OCaml을 배워야 하나 — FP / 형식 검증 / 컴파일러

2026년 OCaml은 모두를 위한 언어가 아니다. 채용 시장이 좁고(특히 한국), 라이브러리 생태계가 JavaScript/Python 대비 작다. 그럼에도 반드시 OCaml을 배워야 하는 사람들이 있다.

1) PL / 형식 검증 연구자: 박사 과정이 PL 쪽이면 OCaml은 필수다. Rocq, F*, Why3, CompCert, Tezos 같은 도구가 OCaml로 짜여 있고, 학회 논문(POPL, PLDI, ICFP)의 구현이 대부분 OCaml.

2) 컴파일러 개발자: OCaml은 컴파일러 작성의 표준 언어다. 패턴 매칭, 대수적 자료형, 모듈 시스템이 AST 다루기에 최적. Rust 컴파일러 일부, Haskell 컴파일러 일부도 영감의 일부를 OCaml에서 받았다.

3) Jane Street / Tarides / Tezos 지망: 위 회사에 가고 싶다면 OCaml. 입사 후 배워도 되지만 미리 알면 인터뷰가 유리. 특히 Jane Street 인턴은 OCaml 기본기를 일주일 동안 가르치고 시험한다.

4) Haskell이 부담스러운 함수형 입문자: OCaml은 strict evaluation이고 implicit한 type class가 없다. Haskell 대비 "함수형이지만 보통 언어"에 가깝다. ML 계열 입문에 좋다. 단 한국어/일본어 학습 자료는 Haskell이 더 많다.

5) 형식 검증 / 컴파일러 검증 / 정적 분석에 관심 있는 모든 개발자: 학계가 아니더라도 정적 분석 도구를 만들거나 인터프리터를 만들거나 도메인 특화 언어를 만들고 싶다면, OCaml은 적합한 도구다.

OCaml을 굳이 배우지 않아도 되는 사람:

  • 일반 백엔드 / 웹 개발 (Go / TypeScript / Python이 더 합리)
  • 모바일 앱 (Swift / Kotlin)
  • 머신러닝 (Python + Rust)
  • 한국에서 OCaml 채용을 노린다면 거의 불가능. 학계 또는 원격 외국 회사가 답

학습 경로 추천:

  1. Real World OCaml 2nd ed (Anil Madhavapeddy, Yaron Minsky, Jason Hickey) — 무료 온라인. 2022년 OCaml 4.13 기준이지만 5.x도 대부분 적용됨
  2. OCaml.org tutorials — 공식 튜토리얼, 5.x 기준
  3. Cornell CS 3110 (Michael Clarkson) — 무료 강의 노트. 학부 PL 수업 표준
  4. Effects unleashed (Tarides 블로그 시리즈) — Eio + Effect 학습
  5. Jane Street Tech Blog — 실전 사례 다수

19. 참고 / References

Discuss on Twitter • View on GitHub