LabHub

블로그

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

2026-05-16 · 44 분 읽기 · #ocaml#ocaml-5-3#multicore-ocaml#effect-handlers#dune#opam#mirageos#unikernel#js-of-ocaml#rescript#bucklescript#melange#reason#eio#lwt#cohttp#dream#tezos#hack-meta#flow#async#jane-street#deep-dive

한국어English日本語

"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 생태계는 대략 이렇게 정리된다:

흥미로운 사실 하나. 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의 약점:

그래도 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의 주요 변경:

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 파일:

(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의 약점:

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

5. Opam — 패키지 매니저

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

Opam의 핵심 모델:

기본 명령어:

# 새 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의 약점:

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

6. MirageOS — 유니커널

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

유니커널(unikernel)의 컨셉:

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 사용처:

MirageOS의 약점:

그래도 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로 옮긴다.

특징:

# 기본 사용
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의 강점:

약점:

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와 다른 방향으로 진화시킨다. 차이점:

(* 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의 포지션:

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

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

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

Eio의 핵심:

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의 강점:

약점:

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의 강점:

약점:

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의 특징:

대안 웹 프레임워크: 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 노드 구조:

(* 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의 오픈소스 기여:

(* 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의 채용 문화:

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

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

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

한국 — KAIST PL lab:

일본 — 京都大学 / Tokyo Tech:

학계 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을 굳이 배우지 않아도 되는 사람:

학습 경로 추천:

  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

원문 보기: https://www.youngju.dev/blog/culture/2026-05-16-modern-ocaml-2026-ocaml-5-3-multicore-effect-handlers-dune-opam-mirageos-rescript-melange-jane-street-deep-dive

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다