✍️ 필사 모드: 함수형 언어 2026 진영 지도 — Haskell, OCaml, Elm, Gleam, Roc, Unison, Lean 4, F#, Clojure 한 번에 정리하는 메타 서베이

• 프롤로그 — 왜 또 함수형 지도인가
• 1. 함수형이라는 한 단어가 가리는 5개의 다른 우주
• 2. 가문 vs 특성 매트릭스
• 3. ML 가문 — Jane Street가 OCaml을 들고 있는 2026
• 4. Haskell 가문 — 거점은 단단해지고 학습 수요는 줄어든 해
• 5. BEAM 가문 — 가장 활발한 진영, 안에 갈등 축 하나
• 6. Lisp 가문 — Clojure의 enterprise, Racket의 교육, CL의 살아 있는 박물관
• 7. 신생 라인 — Roc, Unison, Lean 4, Koka의 다른 베팅
• 8. 함수형이지만 실용적 — Effect-TS와 fp-ts 합병의 의미
• 8.5. 코드 한 페이지로 보는 5개 가문의 차이
• 8.6. 채용·도구·생태계로 본 가문 점수표
• 9. 2026년 스타트업이 함수형 언어를 고르는 게 합리적인가
• 9.5. 가문별 짧은 채용 가이드 — 6개월 안에 채울 수 있는가
• 9.6. 함수형 언어의 사상이 주류 언어로 흘러간 흔적
• 10. 한 가지를 꼽으면 — 가문별 킬러 기능 한 줄 정리
• 에필로그 — 다음 결정을 위한 체크리스트
• 참고 / References

프롤로그 — 왜 또 함수형 지도인가

이 블로그에는 이미 Erlang/Elixir 액터 모델 글이 있고, Haskell의 모나드를 풀어 쓴 글이 있고, Effect-TS와 Gleam을 다룬 글도 따로 있다. 그런데 그 글들은 전부 "한 가문 안에서 본" 지도였다. 2026년 5월 기준으로 한 번쯤은 위에서 내려다보는 시점이 필요하다. ML 가문이 Jane Street 손에 OCaml 5로 넘어가는 동안, Haskell 가문은 Mercury와 Standard Chartered가 떠받쳐 주고 있고, BEAM 가문에서는 Gleam 1.16이 마이너 단위로 나오고 있으며, 새로 등장한 Roc, Unison, Lean 4, Koka는 각자 다른 베팅을 하고 있다. 한 시점에 진영 전체를 보지 않으면, 어느 언어가 살아 있는지를 잘못 판단한다.

이 글은 한 가문을 깊이 파고들지 않는다. 대신 가문 전체를 같은 자에 두고 비교한다. 같은 6가지 질문을 모든 진영에 던진다.

1. 2026년에 누가 실전에서 쓰는가
2. 무엇이 자라고 있고 무엇이 시들고 있는가
3. 한 가지를 꼽으면 그 언어의 킬러 기능은 무엇인가
4. 채용은 가능한가, 라이브러리는 충분한가
5. 어떤 상황에서 고르는 게 합리적인가
6. 어떤 상황에서 고르면 비합리적인가

핵심 한 줄. 함수형 언어는 "쓰는 사람이 줄어든다"가 아니라 "가문 사이의 비중이 재편된다". 2026년에는 BEAM 가문이 가장 활발하고, ML 가문이 인프라 안쪽에서 조용히 커지며, Haskell 가문은 일부 거점이 더 단단해지는 한편 학습용 수요는 줄고 있다. Elm은 멈췄고, 그 자리에 Roc과 Lamdera가 들어왔다.

가격이나 버전 번호는 자주 바뀐다. 이 글의 숫자는 2026년 5월 기준이다. 구조 자체는 6개월 뒤에도 크게 흔들리지 않을 것이다.

1. 함수형이라는 한 단어가 가리는 5개의 다른 우주

먼저 큰 그림을 잡자. "함수형 언어"라는 표현은 마치 한 부족처럼 들리지만, 실제로는 서로 거의 대화하지 않는 5개 가문이 따로 산다.

ML 가문은 1973년 Edinburgh에서 시작했다. Standard ML, OCaml, ReScript, ReasonML, F# 이 한 줄기. 특징은 strict evaluation, module system, 함수형 + 가벼운 부작용 허용의 실용주의다. Hindley-Milner 타입 추론이 여기에서 나왔다. 학계가 아니라 산업에서 가장 조용히 굴러가는 가문이다.

Haskell 가문은 1990년 Haskell 1.0에서 갈라졌다. Haskell, PureScript, Elm, Idris, Idris2, Agda. 특징은 lazy evaluation, monadic effects, 순수성에 대한 비타협. 학계와 강하게 연결되어 있고, 산업에서는 fintech 일부 거점에 집중되어 있다.

BEAM 가문은 1986년 Ericsson에서 Erlang으로 출발했다. Erlang, Elixir, Gleam이 그 줄기. 특징은 actor model, let it crash, 분산과 fault tolerance. 함수형이지만 가문 안에서 "타입 vs 동적"이라는 또 다른 갈등 축이 있다. 통신·메시징·실시간 시스템에서 가장 강한 진영이다.

Lisp 가문은 1958년 LISP에서 시작한 가장 오래된 줄기. Common Lisp, Scheme, Racket, Clojure, ClojureScript. 특징은 homoiconicity(코드가 곧 데이터)와 REPL 주도 개발. 함수형보다 더 큰 범주이지만 현대 Lisp는 거의 함수형 스타일을 권장한다.

신생 라인은 2010년대 중반 이후 별개로 시작된 줄기. Roc(2022 알파), Unison(2023 베타, 2025 1.0), Lean 4(증명 도구가 시스템 언어로 진화), Koka(MS Research). 특징은 algebraic effects, content-addressable code, dependent types as a tool, memory model 혁신. 산업 채용은 거의 없지만 학계와 일부 마니아층이 적극적으로 쓴다.

다섯 가문이 공유하는 것은 "first-class function, immutable by default, algebraic data type, pattern matching" 정도다. 그 외에는 디자인 가치관도, 커뮤니티 문화도, 채용 시장도 다 다르다. 한 가문에서 잘 통하는 조언이 다른 가문에서는 통하지 않는다.

2. 가문 vs 특성 매트릭스

진영 비교를 한눈에 잡기 위해 6가지 축으로 펼친다.

이 표를 일주일에 한 번씩 다시 본다고 생각하면, 어디가 살아 있고 어디가 박물관에 들어갔는지 감이 잡힌다. 다음 절부터는 가문별로 한 절씩 펴서 본다.

3. ML 가문 — Jane Street가 OCaml을 들고 있는 2026

ML 가문의 2026년 핵심 사건은 단순하다. Jane Street가 프로덕션 서버를 OCaml 5 런타임으로 옮겼다. 2025년 ICFP/SPLASH에서 Yaron Minsky가 발표한 내용이고, 회사 블로그에도 정리되어 있다. 트릴리언 단위 자금이 도는 시스템이 OCaml 5 위에서 굴러간다는 의미다. 이 사건은 ML 가문 전체의 신호다. lazy evaluation 없이도, 모나드 추적 없이도, 실전에서 함수형이 어떻게 산업을 떠받치는지를 가장 잘 보여 주는 사례다.

OCaml은 2026년 5월 기준 5.4.x를 안정 라인으로 쓰고, 4.x LTS 분기는 아직 살아 있다. 5.4는 4.x 시리즈와의 기능 패리티를 처음으로 달성했고, 이제 multicore 런타임에 따라오는 효과 핸들러(Eio)가 일상적으로 사용된다. Jane Street는 자체 컴파일러 분기인 OxCaml을 운영한다. 여기에는 modal types, ownership, parallelism extension이 들어가 있고, OCaml 본가에 일부가 흘러들어 가고 있다. 즉 "Rust의 소유권을 OCaml에 가져온다"는 실험이 산업 현장에서 동시에 진행 중이다.

OCaml의 킬러 기능을 한 가지 꼽으면 module system이다. 다른 함수형 언어가 함수 합성으로 추상화를 한다면, OCaml은 functor(모듈을 받아 모듈을 돌려주는 함수)로 한다. 큰 코드베이스를 정리하기에 이만한 도구가 드물다. Jane Street 같은 회사가 OCaml을 떠나지 못하는 가장 큰 이유다.

**F#**은 .NET 10과 함께 F# 10이 2025년 11월에 릴리스되었다. 큰 새 기능보다는 컴파일 병렬화(ParallelCompilation property), IDE 응답성, 작은 문법 개선에 집중한 릴리스다. 사용처는 흩어져 있다. 영국·북유럽의 금융 회사, 일부 게임 도구, .NET 엔터프라이즈 안쪽의 도메인 모델링. C# 사용자가 함수형 사고를 시도할 때 자연스럽게 만나는 진입로다. Microsoft가 적극 마케팅하지는 않지만, 죽이지도 않는다. 안정적 박물관에 가깝다.

ReScript / ReasonML의 상황은 갈렸다. ReasonML은 사실상 ReScript로 흡수되었고, ReScript는 React 생태계 안쪽에서 매우 좁게 살아남았다. 일본의 일부 회사가 큰 코드베이스를 운영하고, 미국의 일부 스타트업이 쓴다. 다만 2024년 이후 TypeScript의 발전(특히 satisfies, const generics, Effect-TS)이 ReScript의 명분을 줄였다. 새 프로젝트에서 ReScript를 고른다면 강력한 이유가 있어야 한다.

언제 ML 가문이 합리적인가. 첫째, 큰 함수형 코드베이스를 정리해야 할 때(OCaml functor). 둘째, .NET 안에서 도메인 모델을 강하게 잡고 싶을 때(F#). 셋째, JIT/GC 없이 빠른 단일 바이너리가 필요할 때(OCaml의 native compiler). 비합리적인 경우는, "프론트엔드에 ML 가문을 쓰겠다"는 결정을 채용·라이브러리 검토 없이 내릴 때다. ReScript는 이제 매우 좁은 선택이다.

4. Haskell 가문 — 거점은 단단해지고 학습 수요는 줄어든 해

Haskell 가문의 2026년 그림은 두 갈래다. 거점은 더 단단해졌고, 진입자는 줄었다.

거점 쪽에서 가장 눈에 띄는 회사는 Mercury다. Mercury는 30만 개 이상의 사업체에 서비스를 제공하는 미국의 비즈니스 뱅킹 스타트업으로, 2025년 거래 규모가 2,480억 달러였고 매출은 연환산 6.5억 달러 수준이다. 코드베이스는 약 200만 줄의 Haskell이다. Mercury 블로그(blog.haskell.org)에 정리된 글 "A Couple Million Lines of Haskell"이 이 규모를 공식적으로 확인해 줬다. 이 회사가 강조하는 사실은 단순하다. "엔지니어 대부분은 입사 전에 Haskell을 한 줄도 써 본 적이 없다." 즉 Haskell이 더 이상 "천재 박사들의 언어"가 아니라 "일반 개발자가 배워서 쓰는 도구"라는 점을 산업 사례가 입증하고 있다.

Standard Chartered도 여전히 핵심 quant 라이브러리 Cortex를 Mu/Haskell로 유지하고 있다. 650만 줄 규모의 코드베이스가 자산 클래스 전반의 가격·리스크 엔진을 돌린다. 서버사이드 batch부터 데스크탑 GUI까지 같은 언어가 깔린다. Anduril, Juspay 같은 회사도 Haskell을 일부 코어에 쓴다. Well-Typed(Haskell 컨설팅) 2026 1분기 리포트가 이 관계를 다시 확인해 줬다.

GHC는 2026년에도 분기별 릴리스 사이클을 유지한다. GHC 9.x 라인이 안정적이고, 10.x가 RC 단계다. Cabal과 stack은 양립한다. 변화는 컴파일러 내부의 모듈성과 typed Template Haskell, 그리고 linear types의 산업 사용 확대 쪽에 집중되어 있다. Effects 라이브러리는 effectful, polysemy, fused-effects 세 가지로 사실상 정리되었고, 신규 코드는 effectful이 다수다.

Haskell의 킬러 기능을 한 가지 꼽으면 타입으로 부작용을 추적하는 능력이다. 함수 시그니처에 IO 라는 타입이 박히는 순간, 그 함수가 외부 세계를 건드린다는 사실이 컴파일러에 명시된다. 반대로 IO 가 없으면 그 함수는 순수하다. 이 단순한 규칙이 큰 코드베이스의 리팩터링을 거의 무서움 없이 가능하게 만든다.

Elm은 같은 가문에서 가장 복잡한 위치다. 0.19.1이 2019년 이후 사실상 멈춰 있다. Evan Czaplicki는 일부 개인 작업에 집중하고 있고, 공식 저장소의 PR은 매우 천천히 움직인다. 이 공백을 두 가지가 메우고 있다. 첫째는 Lamdera. Elm을 풀스택으로 확장한 상용 분기이고, 서버·클라이언트 동기화와 마이그레이션을 한 모델로 다룬다. 둘째는 elm-pages, gren-lang 같은 커뮤니티 노력이다. 다만 Elm 자체를 새 프로젝트의 기본 선택으로 권하기는 어려워졌다. 유지보수 중인 코드베이스에는 여전히 훌륭하지만, 신규에는 후술하는 Roc이 자연스러운 후속이 된다.

PureScript는 살아 있다. 컴파일러도 활발히 개선되고 Halogen은 여전히 작동한다. 그러나 커뮤니티 안쪽에서도 "새 사람에게는 React를 권하자"는 흐름이 굳어졌다. PureScript는 "JS에 Haskell을 더하고 싶다"는 매우 좁은 요구에만 합리적이다.

Idris2는 dependent types를 산업으로 끌어내려는 가장 진지한 시도다. Edwin Brady의 책 Type-Driven Development with Idris가 여전히 표준 입문서다. 2026년 5월 기준 산업 채용은 사실상 없고, 일부 연구실과 마니아 프로젝트가 굴러간다. 다만 "타입을 명세로 쓴다"는 사상은 다른 언어(Haskell의 linear types, Rust의 const generics, TypeScript의 template literal types)에 흘러들어 가고 있다.

언제 Haskell 가문이 합리적인가. 첫째, fintech의 복잡한 비즈니스 규칙을 타입으로 강제하고 싶을 때. 둘째, 컴파일러·정적 분석기·도메인 DSL을 만들 때. 셋째, 큰 코드베이스를 작은 팀이 안정적으로 관리해야 할 때(Mercury의 핵심 주장). 비합리적인 경우는 "프론트엔드 + Elm + 신규 프로젝트" 조합, 그리고 "타입 박사 한 명에게 의존한 도입"이다.

5. BEAM 가문 — 가장 활발한 진영, 안에 갈등 축 하나

BEAM 가문은 2026년에 함수형 가문 중 가장 활발하다. 이유는 단순하다. 분산과 fault tolerance에 대한 수요가 줄지 않았고, BEAM 만큼 그 문제를 깔끔하게 푸는 런타임이 없다. 다만 안에 갈등 축이 있다. "타입을 쓰겠는가, 동적 그대로 가겠는가"이다.

Erlang은 여전히 살아 있다. WhatsApp 백엔드의 핵심이 Erlang이라는 사실은 2016년 인수 이후 바뀌지 않았다. RabbitMQ, ejabberd, CouchDB는 Erlang으로 돌아가고 이들은 모두 2026년에도 활발히 유지된다. OTP 27, 28이 안정 라인이다. 새로 Erlang을 고르는 팀은 거의 없지만, 기존 Erlang 시스템에서 사람이 빠지지도 않는다. "안정된 영역"이다.

Elixir가 가장 큰 동력이다. 2024년에 José Valim이 set-theoretic types 작업을 본격화했고, 2025년 1.18, 2026년 초 1.19 시리즈에서 점진적으로 타입 추론이 들어오고 있다. 즉 동적 BEAM 언어로 출발한 Elixir가 점진적 타이핑으로 확장되는 중이다. Phoenix LiveView는 2026년 1.x 안정 라인을 유지하고, Phoenix 1.8과 함께 Server-Driven UI의 표준 사례가 되었다. Fly.io가 인프라 일부를 LiveView로 운영하고, Discord는 메시지 라우팅에 Elixir를 사용한다. Pinterest, Bleacher Report, PepsiCo 같은 대형 기업도 일부 서비스에서 Elixir를 유지한다.

Elixir의 킬러 기능을 한 가지 꼽으면 OTP 위의 fault tolerance다. Supervisor 트리, link, monitor, restart strategy. 이 4가지가 결합되면 "한 부분이 죽어도 시스템 전체는 산다"는 보장이 코드 레벨에서 만들어진다. 분산 시스템을 처음부터 신뢰성 있게 짜야 하는 팀에 이만한 도구가 드물다.

Gleam이 BEAM 가문의 신성이다. 2024년 1.0 이후 마이너 단위로 빠르게 진화했고, 2026년 4월에 1.16.0이 나왔다. GitHub star는 21,000을 넘었다. Gleam의 차별점은 정확히 두 가지다. 첫째, 타입 안전한 BEAM 언어라는 자리. Erlang/Elixir가 동적이지만 Dialyzer로 보강하던 자리에 Gleam은 처음부터 정적 타입을 둔다. 둘째, 단순함. 문법이 작고, 매크로가 없고, 매뉴얼이 한 권으로 읽힌다. Elm의 "단순함 우선" 철학을 BEAM 가문이 가져온 셈이다.

2026년 신규 BEAM 서비스를 시작하는 팀이 Gleam을 진지하게 고려한다. 다만 채용 풀은 아직 작고, 라이브러리는 Elixir에 비해 얕다. Erlang/Elixir와의 FFI가 깔끔해서 "Gleam으로 도메인 모델 + Elixir로 인프라"라는 혼합 패턴이 자주 보인다.

언제 BEAM 가문이 합리적인가. 첫째, 메시징·실시간·multiplayer 백엔드. 둘째, 분산 시스템에서 fault tolerance를 코드 레벨에서 보장하고 싶을 때. 셋째, LiveView로 풀스택 단순화를 노릴 때. 비합리적인 경우는 CPU 바운드 계산(Rust나 Go가 낫다), 또는 단일 노드 CRUD(평범한 Rails/Django가 훨씬 빠르게 굴러간다).

6. Lisp 가문 — Clojure의 enterprise, Racket의 교육, CL의 살아 있는 박물관

Lisp 가문은 함수형의 원조이지만 2026년에는 한 진영의 무게로 본다.

Clojure가 사실상 Lisp 가문의 산업 대표다. 2026년 5월 1.12.5가 릴리스됐고, Clojure Documentary가 같은 해 3월에 공개됐다. Rich Hickey, Alex Miller, Stuart Halloway가 모두 출연하는 1시간 30분짜리 영상이다. 이 다큐의 등장 자체가 신호다. "Clojure는 이제 한 챕터를 정리하고 다음 챕터로 넘어가는 언어"라는 점. Nubank가 2020년에 Cognitect를 인수한 이래 Clojure 개발을 후원해 왔고, 자체 코어 시스템도 Clojure와 Datomic으로 굴러간다.

Clojure의 킬러 기능을 한 가지 꼽으면 persistent data structure다. immutable vector/map/set이 O(log32 n) 시간에 갱신을 수행하며, 이 위에 STM과 atom이 깔린다. 이 조합이 "동시성 + 데이터 중심 사고"라는 Lisp의 현대화를 가능하게 했다. enterprise 데이터 파이프라인, fintech 코어, EDM(Event-Driven Microservice)에서 여전히 강하다.

ClojureScript는 살아 있지만 새 프로젝트의 다수는 아니다. shadow-cljs 도구가 안정적이고, re-frame이 표준 상태 관리이지만, TypeScript의 발전 속도가 ClojureScript의 명분을 줄였다.

Racket은 교육과 DSL 연구의 거점이다. How to Design Programs가 표준 입문서이고, 매크로 시스템이 가장 강력하다. 산업 채용은 거의 없다.

Common Lisp는 살아 있는 박물관이다. SBCL은 여전히 빠르고, ASDF/Quicklisp는 동작하며, 일부 회사(특히 그래픽·정원 자동화·우주 산업의 일부 레거시)가 여전히 코어 시스템을 운영한다. 다만 새 프로젝트에서 CL을 고를 합리적 이유는 매우 적다.

언제 Lisp 가문이 합리적인가. 첫째, 데이터 파이프라인 + JVM 생태계 활용 + 함수형 사고가 동시에 필요할 때(Clojure). 둘째, DSL을 강하게 써야 할 때. 비합리적인 경우는 "동적 타입 + 작은 팀 + 정적 분석에 대한 강한 요구". 이때는 Gleam이나 OCaml이 낫다.

7. 신생 라인 — Roc, Unison, Lean 4, Koka의 다른 베팅

신생 라인은 산업 채용은 거의 없지만, 가장 흥미로운 실험이 일어나는 자리다. 네 언어가 각자 다른 베팅을 한다.

Roc은 Elm의 후속이다. 작자가 Richard Feldman이고 그가 이전에 Elm in Action을 썼다. 2026년 5월 기준으로 Roc은 여전히 pre-1.0이다. 마지막 태그 릴리스는 alpha4(2024년 8월)였고, 2026년 안에 0.1.0이 나오는 것이 목표라고 Feldman이 The Changelog 645화 인터뷰에서 말했다. 다만 새 컴파일러가 Advent of Code 2025에서 쓸 만한 수준이 되는 게 즉시 목표였고, 일부 사람들이 이미 실험적으로 사용한다.

Roc의 차별점은 두 가지다. 첫째, platform과 application의 분리. Roc 프로그램은 "platform"(예: web server, CLI, AWS Lambda)이 제공하는 effects만 쓸 수 있다. 즉 어떤 부작용이 가능한지가 platform 단에서 결정된다. 둘째, 빠른 컴파일 + 빠른 런타임. Roc는 morphic solver(static dispatch + monomorphisation의 고도화)를 써서 함수형의 빠른 빌드와 빠른 실행을 동시에 노린다. NoRedInk가 이 작업을 후원해 왔다.

Roc은 아직 production에는 못 쓴다. 다만 Elm을 좋아했던 사람이 "프론트 + 서버 + CLI 한 언어로"라는 꿈을 가지고 있다면 가장 가까운 후보다.

Unison은 1.0이 2025년 11월에 발표되었다. 차별점은 content-addressable code다. 함수의 식별자가 이름이 아니라 AST의 해시다. 같은 함수가 같은 해시를 갖고, 한 번 컴파일한 결과는 코드베이스 전체에서 캐시된다. 즉 "빌드 시간이 거의 0에 가까운 강타입 언어"라는 자리. 또 distributed runtime(Unison Cloud)을 처음부터 염두에 두고 설계되어, 함수를 "다른 머신으로 보내서 실행"하는 게 코드 한 줄로 가능하다.

Unison의 ability system은 algebraic effects를 산업화한 가장 깔끔한 시도 중 하나다. 함수 타입에 어떤 ability를 요구하는지 명시되고, 핸들러가 ability를 해석한다. Haskell의 effects 라이브러리들이 추구하던 것을 언어 차원에서 한 단계 더 단순하게 만들었다.

Unison 1.0이 나왔지만 산업 채용은 여전히 작다. 가장 큰 사용처는 Unison Cloud의 베타 사용자들이고, 일부 데이터 파이프라인과 서버리스 워크로드에 실험적으로 쓰인다. 채용 가능성은 거의 없다.

Lean 4는 진영이 가장 빠르게 바뀐 언어다. Microsoft Research에서 시작했지만 2024년부터 Leonardo de Moura가 Amazon으로 옮겼고, Lean FRO(Functional Reservation Organization)이 별도 비영리로 운영된다. Lean 4의 정체성은 두 가지를 동시에 한다. 첫째, theorem prover. 수학자들이 sphere packing 같은 정리를 형식화하는 데 쓰고 있다. 둘째, systems language. Lean 4 자체가 Lean 4로 작성되어 있고, in-place 함수형이라는 패러다임(immutable처럼 보이지만 reference count로 in-place 갱신을 한다)을 가진다.

2026년 3월에 Mistral이 Leanstral이라는 Lean 4 전용 AI 에이전트를 오픈소스로 공개했다. AI가 코드 정확성을 형식 증명으로 검증한다는 시나리오의 첫 실용 도구다. Lean 4의 산업 사용은 여전히 거의 없지만, "AI 시대에 코드 검증을 형식화한다"는 큰 흐름의 거점이 되고 있다.

Koka는 Microsoft Research의 Daan Leijen이 주도하는 함수형 언어다. 2024년 1월에 3.0이 나왔고, 그 후 마이너 단위로 매월 릴리스가 이어진다. 차별점은 row-polymorphic effect types다. 함수의 타입에 가능한 부작용이 row(집합)로 명시된다. 효과 핸들러로 async, exception, probabilistic programming을 라이브러리 차원에서 정의한다. 또 FBIP(functional but in-place)와 reference counting 기반 메모리 관리도 차별점이다.

Koka의 산업 사용은 거의 없다. 그러나 algebraic effects가 다른 언어로 흘러들어 가는 통로 역할을 한다. OCaml 5의 effect handler가 Koka의 영향을 받았고, Unison의 ability system도 사상적 친척이다.

신생 라인은 언제 합리적인가. 솔직히 2026년 production에는 비합리적이다. 학습용, 사이드 프로젝트, R&D 실험, 그리고 다음 산업 표준의 사상을 미리 흡수하기 위한 정도가 합리적 범위다. 6개월 안에 결과를 내야 하는 팀이 신생 라인을 고르면 실패 위험이 너무 크다.

8. 함수형이지만 실용적 — Effect-TS와 fp-ts 합병의 의미

2025년 말의 큰 사건 하나는 Giulio Canti의 fp-ts가 Effect-TS 조직으로 합류한 것이다. Effect-TS는 사실상 fp-ts v3로 자리매김했고, fp-ts의 추후 개발은 Effect 안쪽에서 이어진다. Effect-TS는 자기 자신을 "Haskell of TypeScript"라 부르지만, 실제로는 ZIO(Scala)나 Cats Effect, IO monad 라이브러리의 TypeScript 판이다.

Effect-TS는 한 가지 큰 의미를 가진다. 함수형 가문에 들어가지 않고 주류 언어에 함수형 도구를 라이브러리로 주입한다는 점이다. TypeScript는 main stream이고, React는 표준이며, Node/Bun이 인프라다. 그 위에 Effect, Schema, Layer, Context, Fiber를 올리면 "함수형 가문의 사상을 빌려 쓰면서도 채용을 포기하지 않을 수 있다."

비슷한 흐름이 다른 언어에도 있다. Rust의 thiserror + anyhow + tokio가 사실상 Result/Either + structured concurrency의 산업 버전이다. Swift는 async/await + Result + actor가 모두 함수형의 아이디어다. Kotlin은 Arrow가 fp-ts와 같은 자리에서 산다. Java는 vavr와 jOOλ가 있고, JEP 466의 stream gatherer도 함수형 패턴을 도입한다. Scala는 처음부터 Cats Effect와 ZIO가 거점이다.

이 흐름의 결론은 명확하다. 함수형 가문을 선택하지 않아도 함수형의 90%를 가져올 수 있다. 한 팀의 입장에서, Haskell을 도입하느라 채용을 좁히는 대신 TypeScript + Effect를 쓰는 게 더 합리적인 경우가 늘었다. 단 Effect-TS는 학습 곡선이 가파르다. fp-ts가 어려웠는데 Effect는 그보다 더 큰 표면적을 가지기 때문이다. 모든 팀에 권하기는 어렵다.

언제 함수형이지만 실용적인 길이 합리적인가. 첫째, 채용을 좁히기 싫지만 함수형 사상은 강하게 쓰고 싶을 때. 둘째, 기존 TypeScript/Rust/Swift 코드베이스에 함수형 패턴을 점진적으로 도입할 때. 셋째, "절반은 명령형, 절반은 함수형"이라는 현실적 절충을 받아들일 때. 비합리적인 경우는 "Haskell의 모든 것을 TypeScript로 재현하려"는 시도다. 그 길은 종종 큰 학습 부담만 남기고 끝난다.

8.5. 코드 한 페이지로 보는 5개 가문의 차이

말로만 비교하면 추상화된다. "같은 일을 5개 가문이 어떻게 다르게 쓰는가"를 코드 한 페이지로 비교한다. 예제는 동일하다. 사용자 ID를 받아 잔액을 조회하고, 없으면 적절한 에러를 돌려준다. 가장 단순한 비즈니스 로직이지만, 각 가문의 사상이 가장 뚜렷하게 드러난다.

OCaml. 명시적 module, Result 타입, 패턴 매칭.

module Balance = struct
  type error = NotFound | Frozen
  type t = { user_id : string; amount : int }

  let find_balance db id : (t, error) result =
    match Db.get db id with
    | None -> Error NotFound
    | Some r when r.frozen -> Error Frozen
    | Some r -> Ok { user_id = id; amount = r.amount }
end

Haskell. monad transformer 또는 effects 라이브러리(effectful 기준).

findBalance :: (Reader Db :> es, Error AppError :> es) => UserId -> Eff es Balance
findBalance uid = do
  db <- ask
  row <- liftIO (Db.get db uid)
  case row of
    Nothing -> throwError NotFound
    Just r | rowFrozen r -> throwError Frozen
    Just r -> pure (Balance uid (rowAmount r))

Elixir. with 구문, 패턴 매칭, 메시지 패싱은 GenServer 내부.

def find_balance(db, uid) do
  with {:ok, row} <- Db.get(db, uid),
       false <- row.frozen do
    {:ok, %Balance{user_id: uid, amount: row.amount}}
  else
    :error -> {:error, :not_found}
    true -> {:error, :frozen}
  end
end

Gleam. exhaustive matching이 강제, Result 표준.

pub fn find_balance(db: Db, uid: String) -> Result(Balance, Error) {
  case db.get(db, uid) {
    Error(_) -> Error(NotFound)
    Ok(row) if row.frozen -> Error(Frozen)
    Ok(row) -> Ok(Balance(user_id: uid, amount: row.amount))
  }
}

Clojure. 동적 + spec 검증, multimethod로 분기.

(defn find-balance [db uid]
  (let [row (db/get db uid)]
    (cond
      (nil? row) [:error :not-found]
      (:frozen? row) [:error :frozen]
      :else [:ok {:user-id uid :amount (:amount row)}])))

다섯 가문이 같은 일을 다섯 가지 방식으로 쓴다. 어느 쪽이 우월하다고 말하기는 어렵지만, 각 가문이 무엇을 강조하는지는 명확하다. OCaml은 모듈로 경계를 그리고, Haskell은 모든 부작용을 타입에 새기고, Elixir는 with로 happy path를 평탄하게 펴고, Gleam은 컴파일러가 모든 분기를 강요하며, Clojure는 동적 + 데이터 중심이다.

8.6. 채용·도구·생태계로 본 가문 점수표

산업적 결정에서 중요한 건 사상이 아니라 채용·도구·생태계다. 같은 자에서 보면 가문 간 격차가 정확히 보인다. 아래는 2026년 5월 기준의 주관적 점수표(5점 만점).

이 표를 절대적 신탁으로 보지 말고 "한 사진"으로 보자. 채용 풀은 LinkedIn 기준 영어권 검색 결과의 상대적 크기, 도구는 LSP/디버거/포매터의 성숙도, 라이브러리는 표준적 작업(HTTP, DB, JSON, 인증)의 충실도, 학습 자료는 책과 공식 문서의 깊이, 컨퍼런스·커뮤니티는 2025-2026 활동 빈도 기준이다.

종합 점수가 높다고 우월하다는 뜻은 아니다. 작은 채용 풀이라도 그 풀이 정확히 맞는 사람들이라면 합리적일 수 있다. Gleam의 채용 풀은 작지만 모이는 사람들의 결이 비슷하고, Haskell의 채용 풀도 작지만 Mercury가 입증했듯이 일반 개발자도 학습 가능하다.

9. 2026년 스타트업이 함수형 언어를 고르는 게 합리적인가

이 질문에 정직하게 답해 보자. 답은 "한 가문은 합리적이고, 한 가문은 비합리적이다". 가문 단위로 나눠야 의미가 있다.

합리적인 경우 1 — Elixir + Phoenix LiveView로 풀스택 단순화. 1-3인 팀이 빠르게 MVP를 만들고, 실시간 기능이 핵심이며, 분산 신뢰성을 처음부터 챙기고 싶다. 이때 Phoenix LiveView는 거의 unfair advantage다. 채용 풀도 작긴 하지만 Ruby on Rails 출신과 호환된다. Fly.io, Felt, Cars Commerce, Brex가 실제로 이 패턴을 운영한다.

합리적인 경우 2 — Haskell로 fintech 코어. 비즈니스 규칙이 복잡하고, 타입으로 invariant를 강제하고 싶고, 작은 팀이 큰 코드베이스를 유지해야 한다. Mercury가 이 패턴의 표준 예시다. 채용은 어렵지만, "Haskell을 처음 쓰는 일반 개발자"를 뽑아도 작동한다는 게 Mercury의 입증된 주장이다.

합리적인 경우 3 — OCaml로 컴파일러·infra 도구. Tezos blockchain, Coq의 일부, Docker for Mac의 일부가 OCaml로 작성되었다. 빠른 단일 바이너리 + 강한 타입 + functor의 모듈화. 인프라 도구에 적합하다.

합리적인 경우 4 — Gleam으로 새 BEAM 서비스. Elixir의 사상을 좋아하지만 정적 타입이 필요한 팀. 2026년에 새 BEAM 프로젝트를 시작한다면 Gleam이 충분히 진지한 후보다. 다만 채용은 매우 좁다.

비합리적인 경우 1 — Elm으로 새 프론트엔드. 2019년 이후 0.19가 멈춰 있고, 채용은 거의 0이며, 라이브러리는 더 늘지 않는다. 유지보수 중인 코드베이스는 잘 굴러가지만 신규는 권하지 않는다. Roc이 1.0에 도달하기 전까지는 React + Effect-TS가 훨씬 합리적이다.

비합리적인 경우 2 — Roc, Unison, Lean 4, Koka로 production. 모두 매력적이지만 2026년에 production에 쓰는 건 위험이 크다. 6개월 안에 결과를 내야 하는 팀이 신생 라인을 고르면 실패 확률이 높다.

비합리적인 경우 3 — PureScript / Idris2로 풀스택. PureScript는 React가 있고, Idris2는 채용이 0이다. 학습용이 아닌 한 권하지 않는다.

비합리적인 경우 4 — Common Lisp로 새 SaaS. 한 명의 천재 엔지니어가 만드는 경우가 아니라면, 일반 팀에 권할 수 없다.

이 결론을 한 문장으로 요약하면. "가문 단위로 보면 함수형은 여전히 합리적 선택이다. 단 모든 진영에 동일한 답은 아니다."

9.5. 가문별 짧은 채용 가이드 — 6개월 안에 채울 수 있는가

스타트업의 첫 6개월에 가장 큰 위험은 사람이다. 그래서 가문 선택은 채용 가능성과 직결된다. 가문별 솔직한 가이드.

• Elixir — Ruby 출신 + ElixirSchool/Pragmatic 코스 완료자 풀이 충분히 두텁다. 6개월 안에 3-5명 풀스택 팀을 모을 수 있다. 단 시니어는 적다.
• Haskell — Mercury가 입증한 패턴이 정답이다. "Haskell 경력자만"이 아니라 "Haskell을 배워 줄 일반 개발자 + 1-2명 시니어". 시니어 채용에 6-9개월 걸린다고 보면 안전하다.
• OCaml — 시니어 채용은 매우 어렵다. Jane Street/Tezos/Coq 커뮤니티 외에는 시장이 얇다. 학습 의지 있는 OCaml 비경험자를 시니어로 키우는 게 더 현실적이다.
• F# — C# 사용자에서 사내 이동이 가장 쉬운 경로. 외부 채용은 좁지만, 사내 C# 개발자를 F#로 옮기는 비용은 작다.
• Clojure — Nubank의 영향으로 라틴 아메리카(특히 브라질) 커뮤니티가 커졌다. 미국 시장은 좁지만 안정적이다.
• Gleam — 채용 풀은 사실상 "BEAM 가문 출신 + Gleam 학습자"다. 즉 Elixir 경험자 채용 → Gleam 사내 학습이 가장 현실적이다.
• Erlang — 채용은 매우 좁지만, 핵심 통신 회사에서 시니어를 빼오는 게 가능하다. 단 그 경력은 비싸다.
• ReScript — 일본·미국 일부 회사 출신을 제외하면 채용은 거의 없다. 사내 학습이 사실상 유일한 길.
• Roc/Unison/Lean 4/Koka — 채용 0. 학습 가능한 일반 개발자를 시니어로 키우는 것 외에는 길이 없다. 1년 이상의 학습 비용을 감수해야 한다.

이 가이드의 핵심은 단순하다. "경력자만 뽑겠다"는 전략은 거의 모든 함수형 가문에서 실패한다. Mercury가 명시적으로 한 말이고, 다른 함수형 회사들도 사실상 같은 패턴이다. 학습 의지 있는 일반 개발자 + 소수의 시니어 + 충실한 사내 교육 자료. 이 조합이 6개월 안에 사람을 채우는 유일한 현실적 길이다.

9.6. 함수형 언어의 사상이 주류 언어로 흘러간 흔적

마지막으로 한 가지 큰 관점 변화를 던지고 가자. 2026년의 진실 중 하나는 **"함수형 언어를 선택하지 않아도 함수형이 이긴 것에 가깝다"**는 사실이다. 주류 언어들이 거의 모두 함수형 사상을 흡수했다.

• Rust의 Result, Option, ownership, pattern matching, match 표현식, ? 연산자, lifetime 추적 — 모두 ML/Haskell 가문에서 왔다.
• Swift의 Optional, Result, async/await, actor, Sendable, if let — Apple이 ML 가문의 사상을 흡수한 결과.
• Kotlin의 Result, sealed class, when 표현식, scope function, Flow — Scala/Haskell의 영향이 짙다.
• TypeScript의 union types, narrowing, discriminated unions, satisfies, as const, template literal types — Haskell 가문의 사상이 점차적으로 도입된 결과.
• Java의 Optional, sealed class, switch expression, pattern matching, record — 함수형 + 객체지향의 융합. 가장 보수적인 언어조차 흡수했다.
• **C#**의 record, pattern matching, Nullable<T>, async/await — F#의 영향이 직접 흐른다.
• Python의 typing.Protocol, match 구문, data classes — 천천히지만 흡수 중.

이 흐름의 의미는 무엇인가. 첫째, 함수형 언어를 안 써도 함수형의 90%를 가져올 수 있다. Effect-TS가 TypeScript에서 한 것은 일종의 "마지막 10%까지 가져와 보자"는 시도다. 둘째, 함수형 가문의 가치는 사상 자체가 아니라 "사상을 강제하는 환경"에 있다. Haskell의 진짜 가치는 모나드가 아니라 "함수 시그니처를 거짓말 못 하게 만드는 컴파일러"이고, Elixir의 진짜 가치는 액터 모델이 아니라 "OTP가 fault tolerance를 강제하는 환경"이다.

이 관점이 정리되면 가문 선택이 명확해진다. 사상만 필요하면 주류 언어 + Effect/Arrow/Cats, 강제가 필요하면 함수형 가문.

10. 한 가지를 꼽으면 — 가문별 킬러 기능 한 줄 정리

마지막으로 가문별 킬러 기능을 한 줄씩 정리한다. 채용·라이브러리·도구는 시간이 지나면 바뀌지만, "이 가문이 다른 가문에 줄 수 있는 가장 큰 선물"은 잘 바뀌지 않는다.

• OCaml — module system과 functor. 큰 코드베이스를 추상화하는 가장 좋은 도구.
• F# — .NET 생태계 위에 함수형 도메인 모델링. C# 사용자의 함수형 진입로.
• Haskell — IO 타입으로 부작용을 추적. 큰 리팩터링을 두렵지 않게 만든다.
• Elm — "단순함이 곧 신뢰성"이라는 명제의 가장 순수한 예. 사상은 살아 있다.
• PureScript — Haskell 사상을 JS에 가져온 진지한 시도. 좁지만 깊다.
• Idris2 — 타입이 명세다. 산업화는 안 됐지만 사상은 다른 언어에 흘렀다.
• Erlang / OTP — Supervisor 트리. 분산 fault tolerance의 표준.
• Elixir — LiveView + OTP. 1-3인 팀의 풀스택 unfair advantage.
• Gleam — 작은 문법 + BEAM. "단순함 우선"이 BEAM 위에서 다시 살아났다.
• Clojure — persistent data structure + REPL. 데이터 중심 사고의 표준.
• Racket — 매크로 + DSL. 교육과 연구의 거점.
• Common Lisp — 런타임 변경. 살아 있는 박물관이지만 가르치는 게 많다.
• Roc — platform/application 분리. "어떤 부작용이 가능한가"를 platform이 정한다.
• Unison — content-addressable code. 이름이 아니라 해시로 식별되는 함수.
• Lean 4 — dependent types + AI. 코드 증명의 산업화 거점.
• Koka — row-polymorphic effects. 부작용을 타입 안쪽에 row로 모은다.
• Effect-TS — 함수형 가문을 안 골라도 함수형 도구를 갖는 길.

에필로그 — 다음 결정을 위한 체크리스트

함수형 언어를 진영 단위로 본 메타 서베이를 마무리하면서, 다음 결정에 쓸 체크리스트와 안티 패턴을 정리한다.

고를 때 체크리스트

• 도메인이 분산·실시간·메시징인가 → BEAM 가문 우선 검토
• 도메인이 복잡한 비즈니스 규칙(fintech, 보험, 회계)인가 → Haskell, OCaml, F# 후보
• 도메인이 컴파일러·정적 분석기·인프라 도구인가 → OCaml, Haskell 후보
• 도메인이 데이터 파이프라인 + JVM 생태계인가 → Clojure 후보
• 도메인이 풀스택 + 1-3인 팀인가 → Elixir + Phoenix LiveView 우선
• 도메인이 신규 BEAM 서비스인가 → Gleam vs Elixir 비교
• 도메인이 학습·R&D인가 → Roc, Unison, Lean 4, Koka 시도 가능
• 도메인이 평범한 CRUD라면 → 함수형 가문을 안 골라도 된다. TypeScript + Effect 또는 그냥 mainstream

안티 패턴

• "Haskell이 멋있어 보여서" 도입 → 채용 좁아짐 + 학습 곡선 + 라이브러리 부족의 삼중고
• "Elm으로 새 프론트엔드" → 2026년에는 비합리적, Roc 1.0을 기다리거나 React로
• "Lisp로 SaaS를 처음부터" → 1인 천재 회사가 아니면 위험
• "한 명의 함수형 박사에 의존한 도입" → 그 사람이 떠나면 팀이 무너진다
• "함수형이라는 이유로 채용 풀을 무시" → 6개월 안에 사람이 모자라면 실패한다
• "Effect-TS를 사상 학습 없이 풀 도입" → 학습 곡선이 fp-ts보다 가파르다
• "Roc, Unison, Lean 4를 production에 도입" → 1.0이 나와도 생태계가 얇다

다음 글 예고

다음 글에서는 이 글에서 짧게 다룬 "함수형이지만 실용적"의 실전을 깊이 다룬다. 주제는 Effect-TS 실전 가이드 2026 — Schema, Layer, Context, Fiber를 한 프로젝트에 도입하는 단계별 절차다. fp-ts에서 Effect로 마이그레이션하는 실제 절차, Schema로 런타임 검증을 하는 방법, Layer로 DI를 깔끔하게 짜는 방법, 그리고 "TypeScript + Effect"가 실제 산업에서 어디까지 갈 수 있는지에 대한 honest take를 다룰 예정이다.

참고 / References

• Gleam programming language — official site
• Gleam Gathering 2026 reflections — Alembic
• Roc programming language — official site
• Richard Feldman on Roc — The Changelog Interviews 645
• Unison — official site
• Unison: A friendly programming language from the future — GitHub
• Jane Street and Docker on moving to OCaml 5 at ICFP/SPLASH 2025 — Anil Madhavapeddy
• Introducing OxCaml — Jane Street Blog
• Oxidizing OCaml: Rust-Style Ownership — Jane Street Blog
• Technology at Jane Street
• A Couple Million Lines of Haskell: Production Engineering at Mercury — blog.haskell.org
• Haskell in Production: Mercury — Serokell
• Haskell in Production: Standard Chartered — Serokell
• Haskell ecosystem activities report: Q1 2026 — Well-Typed
• Elm Software Foundation — Elmcraft
• Elm language — Wikipedia
• Lamdera — Full-stack Elm
• PureScript Halogen — GitHub
• Idris 2 — official site
• The Koka Programming Language
• Daan Leijen at Microsoft Research
• Koka project — Microsoft Research
• Lean 4 — official site
• The Lean 4 Theorem Prover and Programming Language — Microsoft Research
• Clojure documentary trailer — clojure.org
• Clojure 1.12.5 release notes
• Introducing F# 10 — .NET Blog
• What's new in F# 10 — Microsoft Learn
• F# 10 Brings Performance Improvements — InfoQ
• Effect-TS vs fp-ts — Effect Documentation
• fp-ts joins Effect-TS — GitHub
• Why We Love Functional Programming but Don't Use Effect-TS — Harbor
• Elixir set-theoretic types — José Valim blog
• Phoenix Framework — official site
• WhatsApp Engineering on Erlang — Code BEAM talks